zDev - M2E - OSS
  1. zDev - M2E - OSS
  2. MNGECLIPSE-823

Resources are missing from target/clases and/or target/test-classes

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.9.5
    • Fix Version/s: 0.14
    • Component/s: None
    • Labels:
      None
    • Global Rank:
      13128

      Description

      In the project properties there is a Maven page where you can specify the list of goals/phases to invoke when the project is cleaned and when a resource changes.
      The problem is the on-clean goals aren't always being invoked.

      1) Make sure Eclipse is set to build projects automatically.
      2) Open up a pom file, make a change and save it.
      3) The project is automatically rebuild due to the change. In the progress view you see a message about it cleaning.
      4) After the clean completes, Maven is not invoked.

      If you have excluded="**" in the resource dirs entry in the .classpath file (as the m2eclipse plugin will do for you) after the clean described above you will see that none of the resource files have been copied.

        Issue Links

          Activity

          Hide
          Eugene Kuleshov added a comment -

          David, first of all please note that "goals executed on project clean" is referring to the manual invocation of "Project / Clean..." action. Please also make sure to invoke Maven / Update project configuration action on your projects. If after that "Project / Clean..." does not trigger invocation of the specified goals for you, then can you please create a test project and attach it to this issue, so we will be able to reproduce this. Thanks.

          Please note that exclusion of resurces is added there for a reason. I've added entry about that to the project FAQ about that.

          Also note we can't guarantee that things are going to work after you manually edit project settings, simply because we can't know if your changes are compatible with Maven expectations. But things can be brought back to the proper state by executing Maven / Update project configuration action.

          Show
          Eugene Kuleshov added a comment - David, first of all please note that "goals executed on project clean" is referring to the manual invocation of "Project / Clean..." action. Please also make sure to invoke Maven / Update project configuration action on your projects. If after that "Project / Clean..." does not trigger invocation of the specified goals for you, then can you please create a test project and attach it to this issue, so we will be able to reproduce this. Thanks. Please note that exclusion of resurces is added there for a reason. I've added entry about that to the project FAQ about that. Also note we can't guarantee that things are going to work after you manually edit project settings, simply because we can't know if your changes are compatible with Maven expectations. But things can be brought back to the proper state by executing Maven / Update project configuration action.
          Hide
          dbarri added a comment -

          Hi Eugene. Ummm, I think you're misunderstanding me. I'm not manually changing the .classpath nor do I have any problem with the excludes="**". That makes sense to me.

          My problem is making changes to the POM (not talking about changes to project structure such as source dir etc), it triggers a clean and then doesn't invoke Maven.

          I've attached a sample project like you asked. When you add it to Eclipse, run test.MNGECLIPSE_823.App. It should say the version is 0.0.1-SNAPSHOT.
          This is good, this means its working properly.

          To reproduce the bug open up the pom.xml file (I'm using the generic XML editor) and paste this it:
          <dependencies>
          <dependency>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
          <version>4.4</version>
          <scope>test</scope>
          </dependency>
          </dependencies>

          Then run the app again. You will see it says that the version is null. This is because the change to the pom file is triggering a clean and the resources aren't being copied after the clean.

          Even if you click "Update Project Configuration" (which I hope you don't expect us to press every time we update the pom :S) it still says the version is null.

          Show
          dbarri added a comment - Hi Eugene. Ummm, I think you're misunderstanding me. I'm not manually changing the .classpath nor do I have any problem with the excludes="**". That makes sense to me. My problem is making changes to the POM (not talking about changes to project structure such as source dir etc), it triggers a clean and then doesn't invoke Maven. I've attached a sample project like you asked. When you add it to Eclipse, run test.MNGECLIPSE_823.App. It should say the version is 0.0.1-SNAPSHOT. This is good, this means its working properly. To reproduce the bug open up the pom.xml file (I'm using the generic XML editor) and paste this it: <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.4</version> <scope>test</scope> </dependency> </dependencies> Then run the app again. You will see it says that the version is null. This is because the change to the pom file is triggering a clean and the resources aren't being copied after the clean. Even if you click "Update Project Configuration" (which I hope you don't expect us to press every time we update the pom :S) it still says the version is null.
          Hide
          igorfie added a comment -

          Looks like JavaBuilder cleans output folders not only during clean build but in many other cases too (classpath change being one of them). Looks like m2e needs to register CompilationParticipant via compilationParticipant JDT extension point in order to reliably detect when javaBuilder cleans output folders.

          In the mean time, the workaround is to run Project->Clean...

          Show
          igorfie added a comment - Looks like JavaBuilder cleans output folders not only during clean build but in many other cases too (classpath change being one of them). Looks like m2e needs to register CompilationParticipant via compilationParticipant JDT extension point in order to reliably detect when javaBuilder cleans output folders. In the mean time, the workaround is to run Project->Clean...
          Hide
          quorg added a comment -

          I may be a victim of exactly what you describe Igor. In my case it's even a bit worse:

          • If I have "Build automatically" turned on, even after doing Project->Clean... the resources first show up but then vanish again.
          • If I manually disable the Java Builder for the project, the resources remain.
          • If I disable "Build automatically" and start Project->Clean.. the resources remain, too. (As soon as I turn on Build automatically again, the resources disappear again, though)

          Do you think this behaviour might be related to your comment?

          Show
          quorg added a comment - I may be a victim of exactly what you describe Igor. In my case it's even a bit worse: If I have "Build automatically" turned on, even after doing Project->Clean... the resources first show up but then vanish again. If I manually disable the Java Builder for the project, the resources remain. If I disable "Build automatically" and start Project->Clean.. the resources remain, too. (As soon as I turn on Build automatically again, the resources disappear again, though) Do you think this behaviour might be related to your comment?
          Hide
          igorfie added a comment -

          fixed.

          Show
          igorfie added a comment - fixed.
          Hide
          igorfie added a comment -

          Kay, the solution to this problem should cover all cases when Java builder cleans output folders. It will be available in the next 0.9.6 dev build. Please open new JIRA with sample project and steps to reproduce if you still see the problem.

          Show
          igorfie added a comment - Kay, the solution to this problem should cover all cases when Java builder cleans output folders. It will be available in the next 0.9.6 dev build. Please open new JIRA with sample project and steps to reproduce if you still see the problem.
          Hide
          igorfie added a comment -

          Rolling back as attempted fix caused endless build cycle (MNGECLIPSE-839), very likely for the same projects that had disappearing resources.

          Show
          igorfie added a comment - Rolling back as attempted fix caused endless build cycle ( MNGECLIPSE-839 ), very likely for the same projects that had disappearing resources.
          Hide
          Eugene Kuleshov added a comment -

          Need to postpone

          Show
          Eugene Kuleshov added a comment - Need to postpone
          Hide
          Eugene Kuleshov added a comment -

          Committed fix to the trunk. There is now option to skip Maven compiler (so it won't change classes managed by JDT, which could trigger a recursive build), turned on by default. You can restore old behavior from the Maven page in the project properties dialog.

          For existing projects you may need to go to Maven page in project properties and set option to skip Maven compiler to on.

          This will go into the dev build, that should be released today or tomorrow. Please give it a try and comment here if you still experiencing this issue.

          Show
          Eugene Kuleshov added a comment - Committed fix to the trunk. There is now option to skip Maven compiler (so it won't change classes managed by JDT, which could trigger a recursive build), turned on by default. You can restore old behavior from the Maven page in the project properties dialog. For existing projects you may need to go to Maven page in project properties and set option to skip Maven compiler to on. This will go into the dev build, that should be released today or tomorrow. Please give it a try and comment here if you still experiencing this issue.
          Hide
          Eugene Kuleshov added a comment -

          The current fix does not respect plugin configuration declared inside executions. Need to revisit.

          Show
          Eugene Kuleshov added a comment - The current fix does not respect plugin configuration declared inside executions. Need to revisit.
          Hide
          Brian Fox added a comment -

          The fix for this is a custom lifecycle definition for projects that see this. It needs to be documented.

          Show
          Brian Fox added a comment - The fix for this is a custom lifecycle definition for projects that see this. It needs to be documented.
          Hide
          Neale Upstone added a comment -

          I'm experiencing this problem. It really makes m2e unworkable, and without an explanation of the above comment, I don't have a workaround either.

          Can you expand on what "custom lifecycle definition" is for these projects (which seems to be all of mine).

          Personally, I'd just rather have the exclude ** dropped and let eclipse compile it.

          Show
          Neale Upstone added a comment - I'm experiencing this problem. It really makes m2e unworkable, and without an explanation of the above comment, I don't have a workaround either. Can you expand on what "custom lifecycle definition" is for these projects (which seems to be all of mine). Personally, I'd just rather have the exclude ** dropped and let eclipse compile it.
          Hide
          Fred Bricon added a comment -

          Custom lifecycle management is described here : https://docs.sonatype.org/pages/viewpage.action?pageId=2949459

          For projects used in WTP, you would typically use something like :

          <profiles>
          	<profile>
          	  <id>m2e</id>
          	  <activation>
          		<property>
          		  <name>m2e.version</name>
          		</property>
          	  </activation>
          	  <build>
          		<plugins>
          		  <plugin>
          			<groupId>org.maven.ide.eclipse</groupId>
          			<artifactId>lifecycle-mapping</artifactId>
          			<version>0.10.0</version>
          			<configuration>
          			  <mappingId>customizable</mappingId>
          			  <configurators>
          				<!-- remove javaConfigurator in EAR pom.xml -->
          				<configurator id='org.maven.ide.eclipse.jdt.javaConfigurator' />
          				<configurator id='org.maven.ide.eclipse.configuration.wtp.configurator' />
          			  </configurators>
          			  <mojoExecutions>
          				<mojoExecution>org.apache.maven.plugins:maven-resources-plugin::resources,testResources</mojoExecution>
          			  </mojoExecutions>
          			</configuration>
          		  </plugin>
          		</plugins>
          		<pluginManagement>
          		  <plugins>
          			<plugin>
          			  <groupId>org.apache.maven.plugins</groupId>
          			  <artifactId>maven-resources-plugin</artifactId>
          			  <version>2.4.3</version>
          			</plugin>
          		  </plugins>
          		</pluginManagement>
          	  </build>
          	</profile>	
          </profiles>
          

          When using a custom lifecycle mapping such as this one, if you're using other m2eclipse configurators (such as Seam, JSF ... from JBoss Tools IDE), you'd have to explicitely add them to the <configurators> list in your pom.xml.

          Regards,

          Fred Bricon

          Show
          Fred Bricon added a comment - Custom lifecycle management is described here : https://docs.sonatype.org/pages/viewpage.action?pageId=2949459 For projects used in WTP, you would typically use something like : <profiles> <profile> <id>m2e</id> <activation> <property> <name>m2e.version</name> </property> </activation> <build> <plugins> <plugin> <groupId>org.maven.ide.eclipse</groupId> <artifactId>lifecycle-mapping</artifactId> <version>0.10.0</version> <configuration> <mappingId>customizable</mappingId> <configurators> <!-- remove javaConfigurator in EAR pom.xml --> <configurator id='org.maven.ide.eclipse.jdt.javaConfigurator' /> <configurator id='org.maven.ide.eclipse.configuration.wtp.configurator' /> </configurators> <mojoExecutions> <mojoExecution>org.apache.maven.plugins:maven-resources-plugin::resources,testResources</mojoExecution> </mojoExecutions> </configuration> </plugin> </plugins> <pluginManagement> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-resources-plugin</artifactId> <version>2.4.3</version> </plugin> </plugins> </pluginManagement> </build> </profile> </profiles> When using a custom lifecycle mapping such as this one, if you're using other m2eclipse configurators (such as Seam, JSF ... from JBoss Tools IDE), you'd have to explicitely add them to the <configurators> list in your pom.xml. Regards, Fred Bricon
          Hide
          Jon Vaughan added a comment - - edited

          Fred,

          Your post was linked to from https://issues.sonatype.org/browse/MNGECLIPSE-1068 as a possible solution, so I am trying to understand what you are describing.

          My situation is that I have a WAR project with several dependent jar projects, published via WTP, and I find that the jar projects occasionally turn up without copied resources.

          I don't understand the bug, so I don't understand whether the custom lifecycle detailed here is appropriate to my situation, and whether it should be in the war pom, all the jar poms etc.

          Also your comment about "<!-- remove javaConfigurator in EAR pom.xml -->" makes me suspicious that in fact this isn't going to solve my problem at all.

          If you could post any more detail it would be very much appreciated

          Thanks

          Jon

          EDIT:

          Still really struggling with this not working, some aggressive googling turned up some related notes which I am going to try:
          http://maven.40175.n5.nabble.com/Problem-launching-WTP-on-Tomcat-server-td138161.html

          Show
          Jon Vaughan added a comment - - edited Fred, Your post was linked to from https://issues.sonatype.org/browse/MNGECLIPSE-1068 as a possible solution, so I am trying to understand what you are describing. My situation is that I have a WAR project with several dependent jar projects, published via WTP, and I find that the jar projects occasionally turn up without copied resources. I don't understand the bug, so I don't understand whether the custom lifecycle detailed here is appropriate to my situation, and whether it should be in the war pom, all the jar poms etc. Also your comment about "<!-- remove javaConfigurator in EAR pom.xml -->" makes me suspicious that in fact this isn't going to solve my problem at all. If you could post any more detail it would be very much appreciated Thanks Jon EDIT: Still really struggling with this not working, some aggressive googling turned up some related notes which I am going to try: http://maven.40175.n5.nabble.com/Problem-launching-WTP-on-Tomcat-server-td138161.html
          Hide
          Igor Fedorenko added a comment -

          Generic lifecycle mapping has been removed as part of lifecycle mapping rework described in https://docs.sonatype.org/display/M2ECLIPSE/Project+build+lifecycle+mapping. Project are expected to either work in m2e or fail fast and with clear message. Please open new jira issues if there are still cases when resources go missing from target/classes or target/test-classes folders.

          Show
          Igor Fedorenko added a comment - Generic lifecycle mapping has been removed as part of lifecycle mapping rework described in https://docs.sonatype.org/display/M2ECLIPSE/Project+build+lifecycle+mapping . Project are expected to either work in m2e or fail fast and with clear message. Please open new jira issues if there are still cases when resources go missing from target/classes or target/test-classes folders.

            People

            • Assignee:
              Unassigned
              Reporter:
              Deleted User
              Last Updated By:
              Igor Fedorenko
            • Votes:
              23 Vote for this issue
              Watchers:
              24 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Date of First Response:

                Time Tracking

                Estimated:
                Original Estimate - 3h Original Estimate - 3h
                3h
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 4h
                4h