[ImageJ-devel] Eclipse hickup with enforcer rules of pom-fiji > 7.2.0
Mark Hiner
hiner at wisc.edu
Thu Mar 26 09:32:57 CDT 2015
Hi all,
>looks like you can check the install/version of maven that eclipse is
using by going to the menu Eclipse > Preferences > Maven > Installations
Thanks Jay. To clarify the history here:
1) We made a custom Maven enforcer rule that ensures no SNAPSHOT
dependencies/parents are used, ever.
2) We then relaxed this restriction to allow SNAPSHOT couplings between
modules in multi-module builds[1].
3) Eclipse used to simply ignore Maven enforcer rules - but Curtis made
some updates to make this possible.
4) Stephan then discovered that our enforcer rule fails in Eclipse because
each submodule is built individually, and our rule required building from
the aggregator itself.
Anyway! I pushed a tentative fix to the scijava-maven-plugin to allow
building individual submodules, and added a branch to trakEM2[2] with some
instructions on how to test this locally. Using this change I'm able to
import the trakEM2 projects into Eclipse with no enforcer failures.
This release will probably go into Fiji this week, at which point I can
delete the trakEM2 branch. Just wanted to put it out there so interested
parties could try it.
Best,
Mark
P.S. for a reminder why we're doing this, see [3]
[1] http://books.sonatype.com/mvnex-book/reference/multimodule.html
[2] https://github.com/trakem2/TrakEM2/tree/test-enforcer
[3] http://imagej.net/Reproducible_builds#Reproducible_builds
On Thu, Mar 19, 2015 at 3:51 PM, Jay Warrick <warrick at wisc.edu> wrote:
> Hard for me to follow if you guys have solved this one or now but, Re: the
> potential of a maven version discrepancy between Eclipse and the CLI, it
> looks like you can check the install/version of maven that eclipse is using
> by going to the menu Eclipse > Preferences > Maven > Installations
>
> Only now just found this now and I see it is a different install than I
> use at the command line. Looks like you can point it to a particular
> install though to make sure they are the same.
>
> Cheers,
>
> Jay
>
> On Mar 19, 2015, at 1:50 PM, Curtis Rueden <ctrueden at wisc.edu> wrote:
>
> Hi Stephan,
>
> To reword Mark's explanation:
>
> The current behavior is a bug, which happens when you try to build _only_
> the submodule, rather than building at the top level of the multi-module
> project.
>
> It is triggered in Eclipse because Eclipse's project configuration runs
> each submodule's build separately, in some sense.
>
> Mark said he would change the scijava-maven-plugin's use of the word
> "dependency" in the case of parent POM linkage, since a parent POM is not a
> "dependency" in Maven terms. (This is what he meant by "consider it
> reworded" -- like a genie saying "It's as good as done!")
>
> We will also be exploring how to solve this bug in general, such that it
> _does_ become possible to build only a submodule of a multi-module project,
> without the enforcer throwing a tantrum.
>
> Regards,
> Curtis
>
> On Thu, Mar 19, 2015 at 1:36 PM, Stephan Saalfeld <
> saalfelds at janelia.hhmi.org> wrote:
>
>> Hi Mark,
>>
>> > It is fine that mpicbg-trakem2 is a SNAPSHOT. The (P) indicates that a
>> > SNAPSHOT parent is making things unhappy. If the object was not allowed
>> to
>> > be a SNAPSHOT you would see a (V). But it is misleading to call it a
>> > dependency.. consider it reworded.
>> >
>>
>> Sorry, I didn't get this. Could you reword please ;) (I mean,
>> seriously, I didn't get it)? A trial:
>>
>> The complaint is that pom-trakem2, which is mpicbg-trakem2's parent is
>> at a SNAPSHOT-version?
>>
>> > For SNAPSHOT-coupled multi-module builds, the contract is that SNAPSHOTS
>> > are allowed as long as everything is built from the top-level. If you
>> built
>> > from a submodule, Maven could resolve the SNAPSHOT parent remotely,
>> which
>> > would then not be guaranteed to match the parent in your multi-module
>> > project.
>> >
>>
>> I guess I got it.
>>
>> > Eclipse is problematic because it splits each submodule out to the same
>> > level as the parent pom, and resolves each individually, thus causing
>> > RequireReproducibleBuilds to fail.
>> >
>>
>> That sounds like a perfect explanation. But since Eclipse is the
>> primary development platform, that should definitely work. I actually
>> think that it is more important that builds build in Eclipse without red
>> x-es than that builds are reproducible. I am reverting to
>> pom-fiji-7.2.0 in the meantime to give myself peace of mind.
>>
>> > I will look into ways of obtaining the reactor's parent pom locally[1],
>> so
>> > that we can build submodules directly.
>> >
>>
>> Thanks a lot!
>>
>> Best,
>> Stephan
>>
>>
>> > [1] https://github.com/scijava/scijava-maven-plugin/issues/12
>> >
>> > On Thu, Mar 19, 2015 at 12:53 PM, Stephan Saalfeld <
>> > saalfelds at janelia.hhmi.org> wrote:
>> >
>> > > Hi Curtis and Jay,
>> > >
>> > > I upgraded to Luna with the same effect. 7.2.0 works, 8.0.0 triggers
>> > > the unspecific complaint as show in the OP.
>> > >
>> > > Run As > Maven build... + Debug Output
>> > >
>> > > says:
>> > >
>> > > [INFO] Property 'imagej.app.directory' unset; Skipping copy-jars
>> > > [INFO]
>> > >
>> ------------------------------------------------------------------------
>> > > [INFO] Reactor Summary:
>> > > [INFO]
>> > > [INFO] Aggregator project for Albert Cardona's TrakEM2 software suite
>> > > SUCCESS [ 5.098 s]
>> > > [INFO] jars/VectorString.jar ............................. SUCCESS [
>> > > 8.813 s]
>> > > [INFO] mpicbg-trakem2 .................................... SUCCESS [
>> > > 8.074 s]
>> > > [INFO] plugins/TrakEM2_.jar .............................. SUCCESS
>> > > [ 28.727 s]
>> > > [INFO] jars/T2-NIT.jar ................................... SUCCESS
>> > > [ 14.724 s]
>> > > [INFO] jars/T2-TreelineGraph.jar ......................... SUCCESS
>> > > [ 13.202 s]
>> > > [INFO]
>> > >
>> ------------------------------------------------------------------------
>> > > [INFO] BUILD SUCCESS
>> > > [INFO]
>> > >
>> ------------------------------------------------------------------------
>> > > [INFO] Total time: 01:19 min
>> > > [INFO] Finished at: 2015-03-19T13:45:46-05:00
>> > > [INFO] Final Memory: 250M/3444M
>> > > [INFO]
>> > >
>> ------------------------------------------------------------------------
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > But the error mark (red x) persists on all mudules' pom files with the
>> > > unspecific error message.
>> > >
>> > > Next test, running Maven build... in mpicbg-trakem2-1.2.3-SNAPSHOT, or
>> > > any of the other modules where the error manifests leads to more
>> > > informative output:
>> > >
>> > >
>> > > The following dependencies either are SNAPSHOT versions (V), contain
>> > > SNAPSHOT parents (P), or contain SNAPSHOT dependencies (D):
>> > >
>> > > (P) sc.fiji:mpicbg-trakem2:1.2.3-SNAPSHOT
>> > >
>> > > [INFO]
>> > >
>> ------------------------------------------------------------------------
>> > > [INFO] BUILD FAILURE
>> > > [INFO]
>> > >
>> ------------------------------------------------------------------------
>> > > [INFO] Total time: 3.043 s
>> > > [INFO] Finished at: 2015-03-19T13:48:20-05:00
>> > > [INFO] Final Memory: 33M/1930M
>> > > [INFO]
>> > >
>> ------------------------------------------------------------------------
>> > > [ERROR] Failed to execute goal
>> > > org.apache.maven.plugins:maven-enforcer-plugin:1.3.1:enforce
>> > > (enforce-rules) on project mpicbg-trakem2: Some Enforcer rules have
>> > > failed. Look above for specific messages explaining why the rule
>> failed.
>> > > -> [Help 1]
>> > > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
>> > > execute goal
>> > > org.apache.maven.plugins:maven-enforcer-plugin:1.3.1:enforce
>> > > (enforce-rules) on project mpicbg-trakem2: Some Enforcer rules have
>> > > failed. Look above for specific messages explaining why the rule
>> failed.
>> > > at
>> > >
>> > >
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
>> > > at
>> > >
>> > >
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>> > > at
>> > >
>> > >
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>> > > at
>> > >
>> > >
>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
>> > > at
>> > >
>> > >
>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
>> > > at
>> > >
>> > >
>> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>> > > at
>> > >
>> > >
>> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
>> > > at
>> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
>> > > at
>> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
>> > > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
>> > > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
>> > > at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
>> > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> > > at
>> > >
>> > >
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> > > at
>> > >
>> > >
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> > > at java.lang.reflect.Method.invoke(Method.java:606)
>> > > at
>> > >
>> > >
>> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>> > > at
>> > >
>> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>> > > at
>> > >
>> > >
>> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>> > > at
>> > >
>> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
>> > > Caused by: org.apache.maven.plugin.MojoExecutionException: Some
>> Enforcer
>> > > rules have failed. Look above for specific messages explaining why the
>> > > rule failed.
>> > > at
>> > >
>> org.apache.maven.plugins.enforcer.EnforceMojo.execute(EnforceMojo.java:209)
>> > > at
>> > >
>> > >
>> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
>> > > at
>> > >
>> > >
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>> > > ... 19 more
>> > > [ERROR]
>> > > [ERROR]
>> > > [ERROR] For more information about the errors and possible solutions,
>> > > please read the following articles:
>> > > [ERROR] [Help 1]
>> > >
>> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
>> > >
>> > >
>> > >
>> > > Wait, mpicbg-trakem2-1.2.3-SNAPSHOT is the project that I am building,
>> > > not a dependency thereof---and it is at a SNAPSHOT version---yes,
>> > > because I am in development cycle---that should work---no?
>> > >
>> > > Thanks for your help,
>> > > Stephan
>> > >
>> > >
>> > >
>> > > On Thu, 2015-03-19 at 12:18 -0500, Curtis Rueden wrote:
>> > > > Hi Stephan,
>> > > >
>> > > > > Do you know about this [, do you have an idea what it is[
>> > > >
>> > > > Probably, this started happening because of this change:
>> > > >
>> > > >
>> > >
>> https://github.com/scijava/pom-scijava/commit/5e6bddae9fcc965722c0fce1e2996c2e49b60411
>> > > >
>> > > > Which in general is a _good_ thing because it's better for Eclipse
>> to
>> > > tell
>> > > > you than for Jenkins to tell you later after you pushed to master.
>> > > >
>> > > > If there are enforcer issues, they should be addressed, or if
>> > > unaddressable
>> > > > the enforcer can be squelched so that CLI and Jenkins also do not
>> > > complain.
>> > > >
>> > > > The weird thing here is that your Eclipse is complaining but our
>> CLI is
>> > > > not. Jay may be on to something about a Maven version discrepancy.
>> Why
>> > > are
>> > > > you still on Kepler? You could try upgrading to Luna—I know of at
>> least
>> > > one
>> > > > annoying Maven-related bug that was fixed. You could also try using
>> the
>> > > Run
>> > > > As > Maven build... and specifying the "Debug Output" option (which
>> > > passes
>> > > > the -X flag to Maven), and see if that tells you anything
>> interesting.
>> > > >
>> > > > Regards,
>> > > > Curtis
>> > > >
>> > > > On Wed, Mar 18, 2015 at 10:33 PM, Stephan Saalfeld <
>> > > > saalfelds at janelia.hhmi.org> wrote:
>> > > >
>> > > > > Hi ImageJ developers,
>> > > > >
>> > > > > Eclipse complains
>> > > > >
>> > > > > Some Enforcer rules have failed. Look above for specific messages
>> > > > > explaining why the rule failed.
>> > > > >
>> > > > >
>> > >
>> (org.apache.maven.plugins:maven-enforcer-plugin:1.3.1:enforce:enforce-rules:validate)
>> > > > >
>> > > > > in my TrakEM2 master for each module. No further information
>> (neither
>> > > > > above nor below) is provided.
>> > > > >
>> > > > > A terminal `mvn clean install`, however, succeeds without
>> complaints.
>> > > > > So I assume that this is an Eclipse specific quirk. I have Kepler
>> > > > > Service Release 1 installed.
>> > > > >
>> > > > > Do you know about this [, do you have an idea what it is[, and do
>> you
>> > > > > know how to fix it]]]?
>> > > > >
>> > > > > Thanks in any case,
>> > > > > Stephan
>> > > > >
>> > > > >
>> > > > > _______________________________________________
>> > > > > ImageJ-devel mailing list
>> > > > > ImageJ-devel at imagej.net
>> > > > > http://imagej.net/mailman/listinfo/imagej-devel
>> > > > >
>> > >
>> > >
>> > > _______________________________________________
>> > > ImageJ-devel mailing list
>> > > ImageJ-devel at imagej.net
>> > > http://imagej.net/mailman/listinfo/imagej-devel
>> > >
>>
>>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagej.net
> http://imagej.net/mailman/listinfo/imagej-devel
>
>
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagej.net
> http://imagej.net/mailman/listinfo/imagej-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20150326/9fad0bd8/attachment-0001.html>
More information about the ImageJ-devel
mailing list