eclipse .classpath generation is wrong

Fred, please see the following FAQ entry about resource excludes. http://docs.codehaus.org/display/M2ECLIPSE/Project+FAQ#ProjectFAQ-excludes

You may have to run "Maven / Update project configuration" and in some cases also recreate your JUnit launch configuration if you have updated from the older versions of m2eclipse.

If you have specific issues with resource excludes, please attach sample test project and provide steps required to reproduce your issue.

Eugene,

I have just stumbled across the problem. I have read the FAQ and I understand what you are tying to accomplished. However, the chosen solution leads to several issues:

1. the WTP publisher does not clean up removed resources. For example: consider a resource src/main/resources/i18n-foo.properties. Once published on a server the resource will go to the correspond WEB-INF/classes directory. The application will run just fine. Next, delete the file from the package explore and publish to update the server. WTP reports that the server is in sync. However, the resource is still present in the WEB-INF/classes deploy directory. In other words the deploy directory is out of sync. So one will think that this is a problem of WTP but it is not. If the exclude filter (explained in the FAQ above) is removed, then everything works just fine. The WTP publish works correctly.
2. Secondly, in the FAQ is said:

   Actually project resource folder doesn't really need to be added to the buildpath (Maven Builder is going to work without it)

   I see the point. However this is the point from the Maven tools and Maven tools only. What about third party tools that expect this resources to be on the class path and they expect the JDT to report it as a non-Java resource. This is show-stopper to me.

3. Finally, the FAQ says:

   it been considered convenient and look better in the Package Explorer.

   How so. Take a look at the pictures attached :

   with the exclude filter	without the exclude filter.

   Obviously the first picture is quite more elaborated, takes more space and breaks the eclipse presentation concept. So how is that statement in the FAQ true I do not understand.

In regards to #2, if resource folder is added into the JDT buildpath, JDT wuld be processing these resources, hence we won't be able to provide resource filtering that would match Maven CLI build. I think that issue with 3rd party tools need to be handled separately. The problem is that tools are making assumptions, e.g. if it is in a buildpath it need to be deployed, which is not necessary the case for the Maven projects. So, since the original report wasn't related to the WTP I recommend to create separate issue, provide a test project that would allow to reproduce this and copy your steps up there.

In regards to #3, the note in the FAQ is simply suggesting that it is better to have resource folder look like you see it now comparing to not have resource folder in the buildpath at all. Unfortunately we don't have control on how resource folders are rendered in the "Package Explorer" view, however it might be possible to handle that in the "Project Explorer" view, so if you are interested, please submit a separate enhancement request for that.

In regards to the project description, since reporter haven't provided requested information and because it is implemented like that by design, I think it makes sense to close this issue. Anyone have objections to that?

Okay, so after searching through JIRA, found that a similar issue is discussed in MNGECLIPSE-784. The issue described in #1 seems to be already logged in MNGECLIPSE-1199, MNGECLIPSE-573.

Issue #3 is a entirely personal preference.

As far as the issue #2 goes I can create a validator that issues a warning whenever necessary resource are excluded from the class path. Then it will be the up to the user to decide what to do. So to me the problem is solved. However, i would adviced to work with the JDT team and come up with a better solution. The current implementation is a hack that cause to much trouble.

In any case I am all about closing the issue.