Community
Participate
Working Groups
There was a discussion on this issue here : http://dev.eclipse.org/mhonarc/lists/tycho-user/msg03717.html The current eclipse-repository type definition : http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-maven-plugin/src/main/resources/META-INF/plexus/components.xml#n277 Basically, if the target folder for an 'eclipse-repository' project has been populated with various files, it can deleted by a maven plugin whose goal is executed afterwards provided it also calls 'initialize'. This is because as part of the initialize phase, the 'eclipse-repository' type calls maven-clean-plugin. I'm aware that the clean during the initialize phase is there so that generated content doesn't just accumulate. Please refer to the mailing list thread for a more detailed explanation of the issue. I've attached the sample project I used to reproduce this issue. (Run it with 'mvn clean install javadoc:aggregate'). bar (foo.bar), and baz (foo.baz) are eclipse-plugin projects, foo-feature (foo.feature) is an eclipse-feature that lists the two plugins, and releng is an eclipse-repository that lists foo.feature in the category.xml.
Created attachment 226465 [details] multi-module project
I noticed this too when I did mvn install followed by mvn site I was wondering why the repository files were missing then I noticed "maven-clean-plugin" was being executed in the logs.
*** Bug 400987 has been marked as a duplicate of this bug. ***
Another report: http://stackoverflow.com/questions/7485331/javadocaggregate-deletes-product-target-folder
Perhaps an implementation of "eclipse-tycho-clean-plugin" which will delete the legacy build content from output folder prior to each build should be created and http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-maven-plugin/src/main/resources/META-INF/plexus/components.xml#n292 be replaced to use that plugin instead.
me too generating javadoc (clean package javadoc:aggregate) we lost p2 repository
Any news about this annoing bug?
the underlying problem is that the javadoc plugin forks a complete maven lifecycle http://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html "Invokes the execution of the lifecycle phase generate-sources prior to executing itself." the general design issues in maven with forked lifecycles are described on http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle+Planning From a first glance it looks like these issues have not been adressed in maven core yet. What can we do? 1. If it's possible to find out at runtime whether we are currently executing the mojo inside a forked lifecycle, don't clean. Not sure how/if we can determine if we are being called in a forked lifecycle 2. move the clean to a later phase (as late as possible). this might make the problem with javadoc go away as it only forks the lifecycle up to phase generate-sources, but will not fix the problem for other plugins forking lifecycles with later phases 3. provide a "-Dtycho.repository.clean=false" configuration parameter . This parameter would have to be commandline only because desired behaviour depends on the goals executed, so it can't be configured in general in pom.xml
this would be the fix for the rrot cause in maven-javadoc-plugin: https://jira.codehaus.org/browse/MJAVADOC-369
(In reply to comment #8) > What can we do? The best solution would be to have the output of eclipse-repository correctly overwrite previous output, so that it doesn't matter if the build was triggered as mvn clean install or as mvn install. However this is difficult for aggregating output formats, like the publishing results. Without the workaround to include clean in the default lifecycle of eclipse-repository [1], the publishing results of a mvn install call would be added to the results of the previous mvn call, so that you'd for example have two product UIs with different timestamps in the build result. This is clearly not desired. The simple solution - just delete whatever is there before publishing something - does not work because there are multiple build steps that publish (e.g. product and category.xml), and if we'd delete before publishing, half of the results would be missing in the end. So we'd need to make sure that only the first publishing step clears existing content. For extensibility reasons, the publishing steps cannot know if they are always the first publishing step. So we need a way to find this out. I can imagine the following solution: 4. Have the ModuleMetadata/ArtifactsRepository check the last-modified timestamp of the index files of the repositories, and treat them as non-existing if they are older than the point in time when the build started. This should be technically sound, and yield the desired behaviour without explicit clean call. The only open question to me is how to find out when the Maven build started. Either Maven already stores this somewhere, or we have Tycho remember the start time in afterProjectsRead. [1] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-maven-plugin/src/main/resources/META-INF/plexus/components.xml#n286
(In reply to comment #10) > The only open question to me is how to find out when the Maven build started. > Either Maven already stores this somewhere, or we have Tycho remember the start > time in afterProjectsRead. There is a special Maven property for this: maven.build.timestamp [1] [1] https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Available_Variables
Eclipse Tycho is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse/tycho/issues/ instead. If this issue is relevant to you, your action is required. 0. Verify this issue is still happening with latest Tycho 2.4.0-SNAPSHOT if issue has disappeared, please change status of this issue to "CLOSED WORKFORME" with some details about your testing environment and how you did verify the issue; and you're done if issue is still present when latest release: * Create a new issue at https://github.com/eclipse/tycho/issues/ ** Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience) ** In the GitHub description, start with a link to this bugzilla ticket ** Optionally add new content to the description if it can helps towards resolution ** Submit GitHub issue * Update bugzilla ticket ** Add to "See also" property (up right column) the link to the newly created GitHub issue ** Add a comment "Migrated to <link-to-newly-created-GitHub-issue>" ** Set status as CLOSED MOVED ** Submit All issues that remain open will be automatically closed next week or so. Then the Bugzilla component for Tycho will be archived and made read-only.
