Eclipse hickup with enforcer rules of pom-fiji > 7.2.0

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Eclipse hickup with enforcer rules of pom-fiji > 7.2.0

Stephan Saalfeld-2
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
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse hickup with enforcer rules of pom-fiji > 7.2.0

Jay Warrick
Not sure if this helps... but once when I had issues with maven through eclipse once, I believe I found once that eclipse was running a different version of maven than what I would run at the command line. I think you can have the run be a bit more verbose and it will print you out some information about the maven version being used. Probably not it but might be worth checking.

In general though, I find fewer issues running maven from command line vs through eclipse. Often not sure exactly why.

Cheers,

Jay

> On Mar 18, 2015, at 10:33 PM, Stephan Saalfeld <[hidden email]> 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
> [hidden email]
> http://imagej.net/mailman/listinfo/imagej-devel


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse hickup with enforcer rules of pom-fiji > 7.2.0

Jay Warrick
Sorry for all the uses of "once". I had just woken up :-)

> On Mar 19, 2015, at 5:50 AM, Jay Warrick <[hidden email]> wrote:
>
> Not sure if this helps... but once when I had issues with maven through eclipse once, I believe I found once that eclipse was running a different version of maven than what I would run at the command line. I think you can have the run be a bit more verbose and it will print you out some information about the maven version being used. Probably not it but might be worth checking.
>
> In general though, I find fewer issues running maven from command line vs through eclipse. Often not sure exactly why.
>
> Cheers,
>
> Jay
>
>> On Mar 18, 2015, at 10:33 PM, Stephan Saalfeld <[hidden email]> 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
>> [hidden email]
>> http://imagej.net/mailman/listinfo/imagej-devel
>
>
> _______________________________________________
> ImageJ-devel mailing list
> [hidden email]
> http://imagej.net/mailman/listinfo/imagej-devel


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse hickup with enforcer rules of pom-fiji > 7.2.0

Curtis Rueden
In reply to this post by Stephan Saalfeld-2
Hi Stephan,

Do you know about this [, do you have an idea what it is[

Probably, this started happening because of this change:

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 <[hidden email]> 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
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse hickup with enforcer rules of pom-fiji > 7.2.0

Stephan Saalfeld-2
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 <
> [hidden email]> 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
> > [hidden email]
> > http://imagej.net/mailman/listinfo/imagej-devel
> >


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse hickup with enforcer rules of pom-fiji > 7.2.0

Mark Hiner
Hi Stephan,

>Wait, mpicbg-trakem2-1.2.3-SNAPSHOT is the project that I am building

>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

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.

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.

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.

I will look into ways of obtaining the reactor's parent pom locally[1], so that we can build submodules directly.

Best,
- Mark

On Thu, Mar 19, 2015 at 12:53 PM, Stephan Saalfeld <[hidden email]> 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 <
> [hidden email]> 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
> > [hidden email]
> > http://imagej.net/mailman/listinfo/imagej-devel
> >


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse hickup with enforcer rules of pom-fiji > 7.2.0

Stephan Saalfeld-2
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 <
> [hidden email]> 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 <
> > > [hidden email]> 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
> > > > [hidden email]
> > > > http://imagej.net/mailman/listinfo/imagej-devel
> > > >
> >
> >
> > _______________________________________________
> > ImageJ-devel mailing list
> > [hidden email]
> > http://imagej.net/mailman/listinfo/imagej-devel
> >


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse hickup with enforcer rules of pom-fiji > 7.2.0

Curtis Rueden
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 <[hidden email]> 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 <
> [hidden email]> 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 <
> > > [hidden email]> 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
> > > > [hidden email]
> > > > http://imagej.net/mailman/listinfo/imagej-devel
> > > >
> >
> >
> > _______________________________________________
> > ImageJ-devel mailing list
> > [hidden email]
> > http://imagej.net/mailman/listinfo/imagej-devel
> >



_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse hickup with enforcer rules of pom-fiji > 7.2.0

Jay Warrick
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 <[hidden email]> 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 <[hidden email]> 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 <
> [hidden email]> 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 <
> > > [hidden email]> 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
> > > > [hidden email]
> > > > http://imagej.net/mailman/listinfo/imagej-devel
> > > >
> >
> >
> > _______________________________________________
> > ImageJ-devel mailing list
> > [hidden email]
> > http://imagej.net/mailman/listinfo/imagej-devel
> >


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse hickup with enforcer rules of pom-fiji > 7.2.0

Mark Hiner
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]

On Thu, Mar 19, 2015 at 3:51 PM, Jay Warrick <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <
> [hidden email]> 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 <
> > > [hidden email]> 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
> > > > [hidden email]
> > > > http://imagej.net/mailman/listinfo/imagej-devel
> > > >
> >
> >
> > _______________________________________________
> > ImageJ-devel mailing list
> > [hidden email]
> > http://imagej.net/mailman/listinfo/imagej-devel
> >


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel



_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse hickup with enforcer rules of pom-fiji > 7.2.0

Jay Warrick
Thanks Mark for the clarification.

Best,

Jay

On Mar 26, 2015, at 9:32 AM, Mark Hiner <[hidden email]> wrote:

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]

On Thu, Mar 19, 2015 at 3:51 PM, Jay Warrick <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <
> [hidden email]> 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 <
> > > [hidden email]> 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
> > > > [hidden email]
> > > > http://imagej.net/mailman/listinfo/imagej-devel
> > > >
> >
> >
> > _______________________________________________
> > ImageJ-devel mailing list
> > [hidden email]
> > http://imagej.net/mailman/listinfo/imagej-devel
> >


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel


_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel




_______________________________________________
ImageJ-devel mailing list
[hidden email]
http://imagej.net/mailman/listinfo/imagej-devel