Maven 2.x Source Plugin

No-Forking mojos for use within a POM instead of CLI

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0.3
  • Fix Version/s: 2.1
  • Labels:
    None
  • Environment:
    ALL
  • Patch Submitted:
    Yes
  • Number of attachments :
    3

Description

The exiting jar at test-jar mojos will always cause a lifecycle fork and generate-sources. This can cause all kinds of undesired side effects when using the source plugin with a pom, instead of CLI. I propose a simple fix (patch attached) to extend these two mojos in no-forking mode. I can't think of a better name for them.

This behaviour is similar to the difference between assembly:assembly and assembly:attached.

Issue Links

is duplicated by

Bug - A problem which impairs or prevents the functions of the product. MSOURCES-31 forking lifecycle of source:jar goal results in release-plugin error

  • Blocker - Blocks development and/or testing work, production could not run
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MSOURCES-37 CLONE -maven-source-plugin causes generate-sources phase to execute twice

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. MSOURCES-8 maven-source-plugin causes generate-sources phase to execute twice

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Improvement - An improvement or enhancement to an existing feature or task. MSOURCES-57 jar-no-fork should be changed to something more meaningful

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ben Tatham added a comment -

My previous patch was a bit premature. This one actually does what it says. I didn't realize that maven plugin javadoc annotations were inherited!

Show
Ben Tatham added a comment - My previous patch was a bit premature. This one actually does what it says. I didn't realize that maven plugin javadoc annotations were inherited!
Hide
Permalink
Dennis Lundberg added a comment -

Are you saying that the "generate-sources" phase will be run twice?
Because SourceJarMojo has

@phase package (which also includes generate-sources)
and
@execute phase="generate-sources"

Show
Dennis Lundberg added a comment - Are you saying that the "generate-sources" phase will be run twice? Because SourceJarMojo has @phase package (which also includes generate-sources) and @execute phase="generate-sources"
Hide
Permalink
Ben Tatham added a comment -

Yes, exactly. When run from an <execution> in a pom, instead of from the cmd line, the generate-sources phase gets run twice. In my case, it causes xdoclet to run twice, which causes other problems.

Show
Ben Tatham added a comment - Yes, exactly. When run from an <execution> in a pom, instead of from the cmd line, the generate-sources phase gets run twice. In my case, it causes xdoclet to run twice, which causes other problems.
Hide
Permalink
Steinar Bang added a comment -

I was recently bitten by this bundle's forking behaviour:
http://comments.gmane.org/gmane.comp.jakarta.turbine.maven.user/78251

My problem was that I used dependency:copy to copy in some artifacts (jar source attachments into an eclipse source plugin), and then used antrun:run to rename some of the copied in files. Then dependency:copy was called two times more, putting artifacts in with their original names.

And then my two problems were:
1. what caused the forking?
2. what could I do to get a workaround?

The cause was this config to create source attachments for all jar and test jar projects in the company super POM:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>jar</goal>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>

The workaround was moving all dependency:copy executions from the generate-sources phase to the generate-resources phase (which isn't triggered by the forked maven-sources-plugins executions), and of cours also move antrun:run from process-sources to process-resources.

Show
Steinar Bang added a comment - I was recently bitten by this bundle's forking behaviour: http://comments.gmane.org/gmane.comp.jakarta.turbine.maven.user/78251 My problem was that I used dependency:copy to copy in some artifacts (jar source attachments into an eclipse source plugin), and then used antrun:run to rename some of the copied in files. Then dependency:copy was called two times more, putting artifacts in with their original names. And then my two problems were: 1. what caused the forking? 2. what could I do to get a workaround? The cause was this config to create source attachments for all jar and test jar projects in the company super POM: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-source-plugin</artifactId> <executions> <execution> <goals> <goal>jar</goal> <goal>test-jar</goal> </goals> </execution> </executions> </plugin> The workaround was moving all dependency:copy executions from the generate-sources phase to the generate-resources phase (which isn't triggered by the forked maven-sources-plugins executions), and of cours also move antrun:run from process-sources to process-resources.
Hide
Permalink
Brian Jackson added a comment -

It's been two years, can this patch be released already?

Show
Brian Jackson added a comment - It's been two years, can this patch be released already?
Hide
Permalink
Ben Tatham added a comment -

I agree – add it already. But perhaps I'm biased.

Show
Ben Tatham added a comment - I agree – add it already. But perhaps I'm biased.
Hide
Permalink
Paul Gier added a comment -

Fixed, thanks for the patch!

Show
Paul Gier added a comment - Fixed, thanks for the patch!
Hide
Permalink
Klyuchnikov Eugene added a comment -

I've used 2.1 version, but the generate-sources phase is still running twice.

Show
Klyuchnikov Eugene added a comment - I've used 2.1 version, but the generate-sources phase is still running twice.
Hide
Permalink
Paul Gier added a comment -

Did you change the goal from "jar" to "jar-no-fork"?

Show
Paul Gier added a comment - Did you change the goal from "jar" to " jar-no-fork "?
Hide
Permalink
Bob Fields added a comment -

Still an issue with plugin version 2.1.2 and maven 2.2.1: If the maven-source-plugin is declared as a <plugin> in a parent pom, generate-sources is executed multiple times in all children, actually causing an infinite loop in our case (MDA code generator project). If declared as <pluginManagement> and referenced in all child projects, it is only executed once. I was using jar-no-fork and test-jar-no-fork. This is an annoyance (we have about a hundred children) but manageable.

Show
Bob Fields added a comment - Still an issue with plugin version 2.1.2 and maven 2.2.1: If the maven-source-plugin is declared as a <plugin> in a parent pom, generate-sources is executed multiple times in all children, actually causing an infinite loop in our case (MDA code generator project). If declared as <pluginManagement> and referenced in all child projects, it is only executed once. I was using jar-no-fork and test-jar-no-fork. This is an annoyance (we have about a hundred children) but manageable.

People

  • Assignee:
    Paul Gier
    Reporter:
    Ben Tatham
Vote (5)
Watch (4)

Dates

  • Created:
    Updated:
    Resolved: