NOTICE! This is a static HTML version of a legacy Fiji BugZilla bug.

The Fiji project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Bug 574 - Build.sh does not generate SNAPSHOT targets for modules
Build.sh does not generate SNAPSHOT targets for modules
Status: RESOLVED FIXED
Product: Fiji
Classification: Unclassified
Component: Other
unspecified
PC Linux
: P3 normal
Assigned To: ImageJ Bugs Mailing List
Depends on:
Blocks:
 
Reported: 2013-03-05 14:56 CST by Stephan Saalfeld
Modified: 2013-07-07 09:18 CDT
2 users (show)

See Also:

Description Stephan Saalfeld 2013-03-05 14:56:53 CST
Calling Build.sh in my brand new fiji checkout does not generate the SNAPSHOT target of the mpicbg submodule.  Instead it works with an old version that it is getting from I-do-not-know-where.  I deleted the contents of the target directory in modules/mpicbg/mpicbg, the I deleted the directory $HOME/.m2/repository/mpicbg/mpicbg/0.6.0-SNAPSHOT/ and called mvn directly in modules/mpicbg---no success.  I end up with fiji complaining about a method signature that I have changed but apparently doesn't make it into the library used by Fiji.  What can I do?
Comment 1 Curtis Rueden 2013-03-05 16:05:27 CST
> Instead it works with an old version

Which version? Is it '20120621'?

Grepping all the POMs for usages of '<artifactId>mpicbg</artifactId>, I see that one project (src-plugins/Fiji_Archipelago/pom.xml) hardcodes that old version instead of using '${mpicbg.version}' (which is currently set to '0.6.0-SNAPSHOT' in the toplevel Fiji POM, as it should be):    

Could you try changing the Fiji_Archipelago version of mpicbg to '${mpicbg.version}' and see if it fixes your build? Maven's classpath resolution (understandably) gets rather arbitrary when multiple versions of the same dependency exist in the build tree. Off the top of my head, I think it prioritizes release versions of snapshot versions, which would explain why '20120621' gets chosen rather than '0.6.0-SNAPSHOT'.

You may also find the following goals useful for analyzing what is happening on the classpath during a Maven build:

    mvn dependency:tree

Or to get really serious:

    mvn -X dependency:resolve > deps-log.txt

> version that it is getting from I-do-not-know-where.

As you probably know, Fiji's own Maven release artifacts live at:

    http://maven.imagej.net/content/repositories/releases/

And non-Fiji release artifact dependencies are at:

    http://maven.imagej.net/content/repositories/thirdparty/

And our Maven snapshot artifacts are at:

    http://maven.imagej.net/content/repositories/snapshots/

So it is certainly getting the old artifact from one of those locations. Using the maven-dependency-plugin goals mentioned above, you can discover more specifically where the problem is, then fix accordingly.
Comment 2 Johannes Schindelin 2013-03-05 20:26:59 CST
I changed a couple of things in the 'master' branch. Please give them a try, if things still do not work, I need the output of "sh -x Build.sh verbose=1 clean && sh -x Build.sh verbose=1".
Comment 3 Johannes Schindelin 2013-07-07 09:18:48 CDT
Closing idle ticket.