[MSOURCES-13] No-Forking mojos for use within a POM instead of CLI

[jira-importer]

Ben Tatham opened MSOURCES-13 and commented

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.

---

Affects: 2.0.3

Attachments:

• nofork.patch (7.56 kB)
• nofork.patch (3.15 kB)
• project-still-running-twice-generate-sources-phase.zip (2.11 kB)

Issue Links:

• MSOURCES-31 forking lifecycle of source:jar goal results in release-plugin error
  ("is duplicated by")

• MSOURCES-37 CLONE -maven-source-plugin causes generate-sources phase to execute twice
  ("is duplicated by")

• MSOURCES-8 maven-source-plugin causes generate-sources phase to execute twice

• MSOURCES-57 jar-no-fork should be changed to something more meaningful

5 votes, 5 watchers

[jira-importer]

Ben Tatham commented

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!

[jira-importer]

Dennis Lundberg commented

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"

[jira-importer]

Ben Tatham commented

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.

[jira-importer]

Steinar Bang commented

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.

[jira-importer]

Brian Jackson commented

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

[jira-importer]

Ben Tatham commented

I agree -- add it already. But perhaps I'm biased. :)

[jira-importer]

Paul Gier commented

Fixed, thanks for the patch!

[jira-importer]

Klyuchnikov Eugene commented

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

[jira-importer]

Paul Gier commented

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

[jira-importer]

Bob Fields commented

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.