Please attach an example project that we can use for testing.
I also suspect that this will be very different for WTP 1.5, since they have changed these settings.

Attached test project. This project was created with eclipse 3.1.2 (WTP 1.0) and managed with the Maven 2.x Extension for Eclipse. It has 3 dependencies on jstl, standard and commons-lang, none of which are copied to WEB-INF/lib when you perform a "Run -> Run on Server" operation.

For these dependencies to be correctly copied, the maven 2 extension would have to create entries in .settings/.component like the ones that I have manually written (and commented) there.

Hello,

I am using Eclipse 3.2 RC2 with the latest (also RC2) Callisto update site modules (Web Standard Tools Version: 1.5.0.v200604030005-eYe38P_OHPq8Dcd) and Maven plugin 0.0.6

and having the same issue.

Resolving this request would really boost dev cycle.

Regards,
Borut

From http://blogs.unixage.com/blojsom/blog/adam.kruszewski/?month=5&year=2006

I have hacked a little eclipse plugin to do the dirty work for me, and by "dirty work" I mean linking maven resolved dependencies directly into "src/main/webapp/WEB-INF/lib", which results in double classpath entries in project but at last WTP publish the application with all the libraries. Now I can use maven within Eclipse for every project type I could dream of. If you want to obtain the plugin just point the update manager to http://adam.kruszewski.name/eclipse/, it contributes a property page for every project so you can tune it for your needs (the sources are also available but they are not elegant nor pretty – you ware warned!) http://adam.kruszewski.name/eclipse/libcopy-src.zip

I've been stepping through the WTP code, and have as a result raised this improvement request:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=154165

I wonder if someone who is much more familiar with the Eclipse extensibility framework could have a look and see whether there is anything that can be done without an alteration to WTP. Questions I immediately have are:

• What happens if two plugins use the org.eclipse.wst.server.core.moduleFactories extension point, both declaring they are for the same type of project? Is there any way for a plugin to specify "use me, not that other one"?

• Can the Maven plugin use this extension point without making the whole plugin dependent on the WTP project at runtime? As obviously this extension point would only get used if you had already installed WTP.

I'm afraid I'm very green when it comes to the Eclipse plugin framework.

The way I work around this is to add a m2 builder which calls war:inplace
Then, every time my project builds, maven gets invoked and copies the jars out to the correct location.

With all due respect, this issue has been open for a year. It is the most popular issue open. Your discussion with Rob Frost on the Eclipse bug broke off a month ago with no resolution. I wasted a week or so trying to solve this problem a few months ago, and now there is a relatively simple way to get what I, at least, want - namely that dependencies int he POM with scope "compile" and "runtime" will be included in the WEB-INF/lib folder when WTP publishes a WAR.

Whether that happens by putting WTP putting containers in WEB-INF/lib and M2Eclipse setting up the containers on a scope basis from the POM, or by M2Eclipse setting in memory attributes on individual classpath entries, is largely academic to me. The reality is that WTP doesn't support the latter approach and isn't going to in the near future.

What's more, it isn't a hack to do it; whether Maven dependencies are in a single classpath container or separated into different classpath containers by scope is largely a matter of preference unrelated to WTP, and can be made optional. After that the functionality is all on WTP's side.

If you can give me a steer as to how you would like me to work on this, which does not involve touching the WTP or JDT code, great, fire away. Otherwise I'll carry on, as I'd rather produce a tactical solution that works on Monday, even if it gets superseded, than wait another year whilst you try and get a change made to Eclipse.

OK, worked it out - you mean mark the Maven classpath container for deployment to WEB-INF/lib in the .classpath file, and then put a "nondeploy" attribute on all the test and provided scope jars.

The separate classpath container solution seems more elegant to me, I have to say, but I'll do it your way.

> [Scope specific classpath container] approach will cause more troubles then benefits it would give

Can I ask why? Not that I don't believe you, I'm just interested. I rather agree with Tomasz that a visual way of seeing which dependencies are in which scope would be nice generally.

I am concerned with keeping multiple containers in sync. For example, when entry changes scope, it may appear in bot containers for some period of time and that would break the JDT compiler. Such kind of corner cases will be difficult to work around.

For visualizing part, one can probably contribute a label decorator, or special model for Project Explorer that would do some fancy stuff.

OK, thanks. I see the problem.

Are you happy for me to have a go at getting the WTP thing working?

Sure. Hack away. I am not really using WTP on a daily base and can only verify correctness from the point of JDT.

I have a proposal that needs discussion. As this Eclipse issue makes clear we may have some time to wait before Projects in a classpath container are handled by WTP.

As such I suggest giving the user the option for POM entries that resolve to projects in the workspace simply to be ignored by the M2Eclipse plugin, so that the user can then handle them in the standard Eclipse and WTP way (making them a dependent project and a J2EE module). Happy to produce a patch to this effect. So long as it's only an option it should be OK, shouldn't it? (The other possibility would be to add them as a required project on the build path and then do a check for WTP and if it is present add them as a J2EE module; this would have the advantage of making the user's life easier, though it would be a touch more complicated to code.)

Then when WTP has developed a bit (and hopefully abandoned the .component file!) this option could be removed and we could return to the more elegant everything in the Maven2 Classpath Container model.

I've attached an initial effort. Sorry it took so long, I had forgotten Sunday was a write off due to family commitments.

It's a tactical solution which is intended to be as non-invasive as possible. No dependency on WTP naturally. Fairly limited.

What it does:
1) Adds the WTP dependency attribute to the Maven2 Dependencies classpath container in any project that has packaging "war"
2) Adds the non-dependency attribute to any entry in that container that does not have scope "compile" or "runtime" or blank
3) Leaves out any dependencies in the POM that exist as projects in the filesystem IF WTP is loaded, the project has packaging "war" and the WTP natures. This is so that the project can be added as a J2EE Module Dependency without

What it doesn't do:
1) Doesn't attempt to handle EARs
2) Doesn't automatically add client workspace projects as J2EE Module Dependencies
3) Doesn't add WTP natures and facets on Maven Enable
4) Doesn't prevent test classes and resources being published
5) Assumes that client jar projects will exist in separate projects in the workspace as is the WTP norm

The thinking is that the user is responsible for ensuring that the war project is a WTP Dynamic Web Project and for adding any client workspace projects to it as J2EE Module Dependencies via the GUI. The user is also responsible for editing the relevant org.eclipse.wst.common.component files to prevent test classes and resources being published (irritatingly there is no GUI way of doing this provided by WTP).

As I say, limited, but at least it is now possible, with a little intervention, to use the M2Eclipse plugin in conjunction with WTP to control the dependency management for wars and publish them via WTP, which was my initial goal.

Next objectives - I'd like to handle "what it doesn't do" 2 & 4, at a minimum, and have a look at 3 depending on how much support there is in the WTP project for turning an existing project into a dynamic web project. I'd also like to be a bit cleverer about when the plug-in does and doesn't do things.

In order to do that I will unavoidably have to use WTP classes, but obviously it is deeply undesirable to have the M2Eclipse plugin dependent on the whole of WTP. So I'm going to look into creating an extension point and a child plug-in to handle WTP specific things.

Long term this is probably all unnecessary - as is mentioned here, hopefully eventually it can all be controlled with attributes on the classpath without needing to know about WTP at all. But not yet, and it's difficult to know how long it will be, so it seems worthwhile to me to have a crack at getting something going now.

Hello Everybody,
if you still strugle with WTP support, i supose to give thirty party to handle resolved dependencies by their needs.
I think that Classpath container should be extendable by extension point defined in maven core plugin.

A wtp project or any other project that need handle its classpath in different way, they will just implement extension point of maven. And maven will ask defined extension points who is responsible for certain project and that implementation will be finally used.
This behaviour could be really simple, will not brake core plugin, and give more adventages.

BTW:
Solution i have seen in patch is quit unstandard. If you do not what to be depend on certain plugin, you should create another one a put all non standard dependencies there. To be able to do that you need to define extension point in original plugin to be aware of your extension.

I was developing & playing with "automatically add client workspace projects as J2EE Module Dependencies", right now it +- works for me, but i would like to discuss with you how to deal with wtp like projects, because not everybody can use WTP2.0, so there should be still support for WTP1.5 also in any bad way, but it should be there!

Using extension points we can fulfill both supports and it will not split comunity as well.

What do you think about my proposal?

Robert, Andrej... have you managed to move forward on this issue?
I noticed that the patch has not been commited and it no longer applyies cleanly against latest SVN.

I'm willing to work on a solution for Eclipse 3.3 / WTP 2.0, but I won't like to step over someone else's work.

Hi Abel,
currently i have created extension point for that and all necessarily thinks, but implementation of extension point is not finished, i would like to based it on the Robert patch. But anyway Eugene is boss and i am as the same volunteer as you are and i think we should more discuss with someone responsible for real solution, for example by skype and then create tasks and distribute what to do, what do you think?

Very quick review of my changes:

• Introduced very stupid extension point for wtp 1.5 and wtp 2.0.
  Wtp 1.5 support (Inspirated by LibCopy)
  Wtp 2.0 support (inspirated by previous patches)

-Extended add dependency actions
-Fixed bugs in MAVEN_HOME resolving for global configuration
-Build on the top of my previous patches for DownloadSource code (due to possible conflicts) and add patch for tree layout in search dialog for depedencies (because these changes i am using)
-Better source attachement base for dependencies that has source code only in parent module. Such as spring.jar artifact contains also java source for artifact spring-aop.jar.

Andrej, please note that it is very time consuming and in result practically impossible to apply patches that are built on something or fixing multiple bugs, even if there is no conflicts. Your patch is conflicting with my workspace, hence I can't apply it.

Please read correspond page on the project wiki. http://docs.codehaus.org/display/M2ECLIPSE/How+To+Contribute+Patches

This patch against latest SVN adds attributes to the Maven2ClasspathContainer and the managed jars with the appropriate scope. It's basically Robert Elliot's patch with a couple of changes.

Currently, the attributes are only added for war projects, and only if the WTP nature (2.0 version) is found (the project must be a dynamic web project).

For testing, use the updated eclipse project (in teh original one the packaging=war was missing from the pom). With the project as-is, testing to deploy will fail. Once the Maven2 plugin is enabled on the project, after refresing the webapp the JSP page displays properly.

Remember that the WTP WebContent folder must match the maven webapp folder (by now, this must be done manually).

It would be great if someone could verify this and we could have the changes committed.

I would vote for treating support for other WTP versions as different JIRA issues. Then we can think if an extension point is needed to handle different WTP flavors.

Sorry, I uploaded the wrong project. This (MNGECLIPSE-105-test-project.zip) is the updated version. Fee free to delete teh duplicated mngeclipse-test.zip.

Note: The "mylyn-context.zip" is teh task context used by the Mylyn plugin... it was attached when using the JIRA connector before I noticed... I'll look into avoiding that in the future (unless project owners think sharing Mylyn contexts is OK).

I'm uploading a version of the org.maven.ide.eclipse with the patch applyied to simplify testing.
It will be available in a few minutes from http://candy4appfuse.sourceforge.net/tmp/org.maven.ide.eclipse_0.0.11.20070707-0122.jar

Is patch MNGECLIPSE-105-wtp2.0.patch currently working? I mean excluding provided, test and system scoped artifacts from deploying to WEB-INF/lib.

After patching i got new BuildPathManager.java file with following lines (249-256):

// Check the scope & set WTP non-dependency as appropriate
List attributeList = new ArrayList();
String scope = a.getScope();
if (Artifact.SCOPE_PROVIDED.equals(scope) 
    || Artifact.SCOPE_TEST.equals(scope) 
    || Artifact.SCOPE_SYSTEM.equals(scope)) {
  attributeList.add(JavaCore.newClasspathAttribute(CLASSPATH_COMPONENT_NON_DEPENDENCY, ""));
}

But attributeList variable i never used/read in rest of this file.

Yes, there seems to be an error. I'll look into it when I find the time.

Attached a fixed patch. Now attributes are correctly added.
For testing against an existing m2eclipse project, please disable m2eclipse support and re-enable it.

Hello Abel,

Could you please kindly post the jar with the latest patch?
Thanks a lot!

I've uploaded the plugin to: http://personales.ya.com/abelmuino/tmp/org.maven.ide.eclipse_0.0.11.20070731-0000.jar

However, it is non official and unsupported.

I have been reading a lot on the dependency resolution issues with the M2Eclipse plugin and the Eclipse WTP. It seems that this solutions is the one that is being recommended, but does anyone know it this is the case and if so is there any estimate as to when it would be included or released as a bug fix on the update site?

Sorry about delay with reviewing this patch. Unfortunately I can't apply it because of the massive refactorings in the code. Can you please merge from trunk and recreate this patch?

Also, I have one comment about implementation based on fragments of your patch. I don't think it is necessary to check for any wtp natures and everything should be based on the stuff you have in pom.xml

I won't be able to update the patch before October 12th. After that date, I'll try to find the time for merging it against latest SVN.

If anybody interested: I have patched release version (0.0.11.20070916-2300) with patch from Abel.

Note: I did it explicitly against the release and not against the trunk because I actually needed exactly that: released version of m2eclipse with minimal changes.

I am interested by this patched version. Could you put a patched jar on a web server, like Abel did ?

I hope Abel will have the time to reintegrate his patch with the lastest SVN, a lot of people are waiting on this bug. I am really surprised that it is not targeted for 0.12 release, as it is a must to have for all J2EE developers ...

I'll try to look at this patch this week.

Eugene, I have attached an improved patch, again against the 0.0.11 release.

What it does:
1. Adds the non-dependency attribute to any entry in that container that does not have scope "compile" or "runtime" or blank

2. Leaves out any dependencies in the POM that exist as projects in the filesystem IF WTP is loaded, the project has packaging "war" and the WTP natures. This is so that the project can be added as a J2EE Module Dependency via WTP specific UI.

3. The patch of Abel also added the WTP dependency attribute to the Maven2 Dependencies classpath container in any project that has packaging "war". My patch does NOT do it. The reason: if m2eclipse does it automatically then there is no way to switch this off. WTP UI can already handle this anyway.

For my projects there is a single remaining issue: I am getting a WTP warning for a "utility" project: Classpath entry org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER will not be exported or published. Runtime ClassNotFoundExceptions may result.

After poking around WTP 2.0.1 I'd say we have to leave with it. You can "quick fix" it but the fix introduces the error message (instead of warning). Quickfixing the error brings the warning back.

I still consider it a bit dirty approach. Ideally a new plugin needed, that knows about both WTP and m2eclipse, but the patch is a path of the least resistence at the moment.

Alex, what happens if attribute is added to the project entry? Will that include project properly? If not, then it need to be reported and fixed in WTP, because project configuration should work without manual editing. I.e. we import Maven project and should be able to deploy it without tweaking trough WTP UI.

Also, can you please open a bug report on WTP about that warning/error issue. The deal with their classpath attribute was that it would pickup any containers or jars without special complaints.

> ... because project configuration should work without manual editing

The problem with this (and the reason why I did not include part of Abel's patch) is that if m2eclipse does everything for that behind the scenes then there is no way to switch this off. WTP has already some UI to handle this, so m2eclipse does not need anything special.

A better way is to have maybe a special contex command (and an option for "import maven project") to WTPfy the project. The command will then simulate manual work of setting various WTP-specific properties. (Needless to say it make m2eclipse too dependent on WTP so as I mentioned it is better to have couple of extension points in m2eclipse and then a separate plugin that knows about WTP and m2eclipse).

> what happens if attribute is added to the project entry

When you add it using WTP UI the project becomes a part of WebAppLibraries classpath container. That is the reason why it is removed from the "Maven dependecies" classpath container: if it is in both places then you get classpath errors about duplicate entries.

I do not know (did not check) what happens if I remove it from WTP UI but keep it in the "Maven dependecies" classpath container with the correct attribute: most likely it will work, but again, this way a developer can't control this: adding it via WTP UI will produce a classpath error about duplicate entries, but removing it via WTP UI will NOT exclude it from deployment.
Well, the problem (and the reason for item 2 in the list of what patch does) is that

Also, can you please open a bug report on WTP about that warning/error issue. The deal with their classpath attribute was that it would pickup any containers or jars without special complaints.

> Also, can you please open a bug report on WTP about that warning/error issue.
> The deal with their classpath attribute was that it would pickup any containers
> or jars without special complaints.

I will do it, but the situation is a bit tricky here:
Basically you get the error in the utility project because the validator does not know that the "Maven dependecies" classpath container in the web project pulls all the dependecies from the utility project so the dependecies will be available.

There is an extension point in JST to specify which classpath containers to ignore during the validation, but at least in some post where the extension point was mentioned it is stated that the very same ext. point also controls whether or not the container will be visible for selection in the WTP UI. Plus the ext. point is static in the sense that it is just a container name, you cannot change its behavior per project (say, ignore for the utility project but check in the web project).

> if m2eclipse does everything for that behind the scenes then there is no way to switch this off.
I recall being able to manage it through the UI. It just defaults to deploying maven dependencies.

In my opinion, maven dependencies should be managed by the maven container (including projects in the workspace). I can't see why I would use maven and not want it to manage my builds, in eclipse or in the command line. It's made for that.

BTW, I see Alex is doing a good job with the patch, and I still don't have all the free time I need for jumping again into this issue. So I'll vote for getting the existing patch into head.

(In reply to comment #48)
> > ... because project configuration should work without manual editing
> The problem with this (and the reason why I did not include part of Abel's
> patch) is that if m2eclipse does everything for that behind the scenes then
> there is no way to switch this off.

That was the idea. So, why do you need to switch that off?
I don't think special wizards are really good idea because when importing multiple projects or even project hierarchy you don't really know project types or even could get a good mix of them.

> WTP has already some UI to handle this, so m2eclipse does not need anything special.

Can you please explain in little more details why it has to be edited/tweaked in WTP UI?

> I do not know (did not check) what happens if I remove it from WTP UI but keep
> it in the "Maven dependecies" classpath container with the correct attribute:
> most likely it will work, but again, this way a developer can't control this:
> adding it via WTP UI will produce a classpath error about duplicate entries,
> but removing it via WTP UI will NOT exclude it from deployment.

Sure. But since it is a Maven project all dependency management and packaging is driven by Maven, so there is no point to tweak it, because in that case you'll have different configuration between the command line and IDE.

> Basically you get the error in the utility project because the validator does
> not know that the "Maven dependecies" classpath container in the web project
> pulls all the dependecies from the utility project so the dependecies will be
> available.

Their verifier should be able to check all the entries from any given classpath container to see what is included (marked with their entry attribute).

(In reply to comment #49)
> In my opinion, maven dependencies should be managed by the maven container
> (including projects in the workspace). I can't see why I would use maven and not
> want it to manage my builds, in eclipse or in the command line. It's made for
> that.

That is exactly my point.

(In reply to comment #46)
> Eugene, I have attached an improved patch, again against the 0.0.11 release.

It doesn't apply. Can you please recreate it against version from the trunk?

(In reply to comment #50)
> > > ... because project configuration should work without manual editing
> > The problem with this (and the reason why I did not include part of Abel's
> > patch) is that if m2eclipse does everything for that behind the scenes then
> > there is no way to switch this off.
>
> That was the idea. So, why do you need to switch that off?

I guess you would never know for what kind of projects m2eclipse will be used.
For me: I see sometimes strange results when WTP deploys my web project after the dependencies are changed (strange in the sense that some required jars are missing from WEB-INF/lib). I do not know which component/plugin fails, but at least I have a definitive set of manual actions to fix it. One of actions is temporary switch off deployment of Maven classpath container.

> I don't think special wizards are really good idea because when
> importing multiple projects or even project hierarchy you don't
> really know project types or even could get a good mix of them.

Well, that is why I mentioned a separate plugin. WTPS and m2eclipse are quite often used in combination, so it might deserve its own plugin. It is even cleaner than putting tome WTP specific code into m2eclipse, however small that code is.

> > WTP has already some UI to handle this, so m2eclipse does
> > not need anything special.
> Can you please explain in little more details why it has to be
> edited/tweaked in WTP UI?

Above I have explained why I need it edited at all. WTP has already UI for it. m2eclipse does not need to do anything.

> > I do not know (did not check) what happens if I remove it
> > from WTP UI but keep it in the "Maven dependecies" classpath
> > container with the correct attribute: most likely it will
> > work, but again, this way a developer can't control this:
> > adding it via WTP UI will produce a classpath error about
> > duplicate entries, but removing it via WTP UI will NOT
> > exclude it from deployment.
> Sure. But since it is a Maven project all dependency management
> and packaging is driven by Maven, so there is no point to tweak
> it, because in that case you'll have different configuration
> between the command line and IDE.

Two things here:
1. The deployment configuration IS different between IDE and the command line: after all the deployment process is completely different in IDE and in command line.

2. More importantly: I did check if it would work. It did not: a jar file from the utility project was NOT deployed. I did not try to debug WTP to see why it is the case but most likely it is because the utility project is not selected in the WTP UI "J2EE Module Dependencies". Even more, selecting it, applying the changes, closing project properties dialog and opening it again shows that the setting is NOT preserved. I have a way to make the dialog preserve it, but then there is an error "Build path contains duplicate entry: 'UtilityProject' for project 'WebProject'" (one is coming from maven and another from WTP).

The only way to make it work for now is to do what the patch does (does not include UtilityProject in the maven dependencies classpath container for WTP web project). Then I can safely select UtilityProject in WTP UI, and everything works. Since I anyway have to manually select the project there I do not see any problem to manually select the maven dependencies classpath container as well: it least it is consistent. Plus requires minimal changes to m2eclipse: basically one additional check.

> > Basically you get the error in the utility project because the
> > validator does not know that the "Maven dependecies" classpath
> > container in the web project pulls all the dependecies from
> > the utility project so the dependecies will be available.
> Their verifier should be able to check all the entries from
> any given classpath container to see what is included
> (marked with their entry attribute).

It does this. The problem is the validator is running on per-project basis. So in the context of the utility project it just does not know that the dependencies from the maven classpath container can be ignored completely because they are anyway (via magic of m2eclipse) available in the context of web project. Anyway, it is for WTP to resolve...

OK, this is the patch applied against the trunk (revision 305)

I've committed last patch to trunk. Though after playing with it for a little I see only limited usefulness of such integration, which his very unfortunate.

(In reply to comment #52)
> For me: I see sometimes strange results when WTP deploys my web project after
> the dependencies are changed (strange in the sense that some required jars are
> missing from WEB-INF/lib). I do not know which component/plugin fails, but at
> least I have a definitive set of manual actions to fix it. One of actions is
> temporary switch off deployment of Maven classpath container.

I don't think that is a good enough reason to force user to configure packaging twice: in maven's pom.xml and then in wtp. At minimum that is error prone.

> Well, that is why I mentioned a separate plugin. WTPS and m2eclipse are quite
> often used in combination, so it might deserve its own plugin. It is even
> cleaner than putting tome WTP specific code into m2eclipse, however small that
> code is.

I am fine with that and it doesn't seem it can be avoided anyways.

> Two things here:
> 1. The deployment configuration IS different between IDE and the command line:
> after all the deployment process is completely different in IDE and in command
> line.

I am not sure what you mean. It should be the same web application that have same dependencies between command line and the IDE, otherwise you practically have two separate application and will never know what you actually testing.

> 2. More importantly: I did check if it would work. It did not: a jar file from
> the utility project was NOT deployed. I did not try to debug WTP to see why it
> is the case but most likely it is because the utility project is not selected in
> the WTP UI "J2EE Module Dependencies". Even more, selecting it, applying the
> changes, closing project properties dialog and opening it again shows that the
> setting is NOT preserved. I have a way to make the dialog preserve it, but then
> there is an error "Build path contains duplicate entry: 'UtilityProject' for
> project 'WebProject'" (one is coming from maven and another from WTP).

Sounds like a bug in WTP resolver. Dependency (project in this case) is coming from classpath container that have WTP's attribute set it should be packaged properly. Please fill a bug to WTP for that.

Also, can you please attach test projects here that would allow to reproduce this issue. I think they would be useful for those who wan to play with this.

> Since I anyway have to manually select the project there

That is the key point. You should not have to do anything manually. If WTP require you to do so we have an issue (same configuration in two places) that need to be reported to WTP.

maven_projects.jar is a test case for the patch.

Actually it contains only maven stuff (projects), no eclipse specific files

This is "complement" for maven_projects.jar.
It can be extrected on top of the maven structure.
There are 3 eclipse projects plus some WTP specific settings

> I've committed last patch to trunk. Though after playing with
> it for a little I see only limited usefulness of such integration,
> which his very unfortunate.

Maybe it is because (quoting you): "I am not really using WTP on a daily base and can only verify correctness from the point of JDT."

> Also, can you please attach test projects here that would allow
> to reproduce this issue. I think they would be useful for those
> who wan to play with this.

OK, I have attached two files: eclipse_structure.jar and maven_projects.jar.

maven_projects.jar contains 3 maven projects (no eclipse specific stuff). maven_projects.jar contains eclipse specific files (plus WTP settings) so you do not have to create them yourself. You can try and play with it and with m2eclipse version without my patch. Of course you need WTP as well: that is the whole point of the patch. Try to deploy it. Try to make it work. I would be extremely surprised if you manage it: no matter what I have tried I always ended up with either TestCore.jar missing from WEB-INF/lib or duplicate classpath entry error, or something like that. Moreover, you will also get servlet-api-2.4.jar in WEB-INF/lib: definitely not a nice thing.

Now try to do it with patched m2eclipse. If you do it right (and yes you need to do something manual, in WTP UI: namely, you have to check both TestCore and Maven Dependencies in TestWeb's properties/J2EE Module Dependencies), then you should be able to successfully deploy TestWeb using WTP.

I'd say that the successful deployment is quite useful.

Now, for the rest:

> I don't think that is a good enough reason to force user
> to configure packaging twice: in maven's pom.xml and then
> in wtp. At minimum that is error prone.

Well, it is error prone. I can agree if it were done automatically it would have been really nice. The thing is: it is impossible now with WTP. I will file bugs for WTP, but you never know when they would be resolved, if at all. We can come back to this discussion later, when the bugs are fixed but meanwhile we have a working (albeit imperfect) solution.

> > Well, that is why I mentioned a separate plugin. WTPS and
> > m2eclipse are quite often used in combination, so it might
> > deserve its own plugin. It is even cleaner than putting
> > tome WTP specific code into m2eclipse, however small that
> > code is.
>
> I am fine with that and it doesn't seem it can be avoided anyways.

This can be handled outside of discussing this issue. Another thing that can be resolved by a separate plugin is that it can also build WTP module definitions from pom.xml files (currently I have to do it by hand).

> > 1. The deployment configuration IS different between IDE and
> > the command line: after all the deployment process is completely
> > different in IDE and in command line.
> I am not sure what you mean. It should be the same web application
> that have same dependencies between command line and the IDE,
> otherwise you practically have two separate application and
> will never know what you actually testing.

Well, we can get quite close to this from the point of web application content (for example, what exactly goes to WEB-INF/lib), but the actual deployment process (the code that copies the files around and starts an application server for example) IS different. Also the logic of deciding what exactly to copy and where IS different:

1. For maven: just take a target war file or a target webapp directory and copy it.
2. For WTP: OK, let's go to the module definition... Hmmm, we need to copy that directory to here, and this one, and... Oh, we have another module. Let's build a jar file using the module's definition. And so on.

That is what I meant by "The deployment configuration IS different" above.

Alex, is your latest patch usable on the 0.12 release?

Thanks

> Alex, is your latest patch usable on the 0.12 release?

It is included, but I did not chek it. I will try to do it tomorrow.

Eugene, please let us know why you're removing all new comments in this issue!

I didn't removed new comments. Just wanted to cleanup this issue, so it will be easier to read for those who haven't been following this issue from the beginning. If you want to see those comments you can still look trough Change History tab.

The initial functionality been implemented. I will create separate issues to close other gaps in the WTP integration.