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.

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

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

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.

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.

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.

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

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

this

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.

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.

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.

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?

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.

• 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.

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

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.

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).

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.

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

http://personales.ya.com/abelmuino/tmp/org.maven.ide.eclipse_0.0.11.20070731-0000.jar

However, it is non official and unsupported.

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

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 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 ...

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 sa