I would suggest changing the project currentVersion to 2.1-SNAPSHOT, and your dependency versions to SNAPSHOT. snapshot dependencies are handles differently, and always look for a newest version.
-----Original Message----- From: Randy Xu [mailto:[EMAIL PROTECTED] Sent: Monday, January 10, 2005 10:23 AM To: Maven Users List Subject: Re: Stale subproject jar files in repository First of all Dion, kudos to you and your book. It seems like it'll be because of people like you that Maven is really taking off. Now then, to my question. I have three subprojects: * app-lib * app-jms (depends on lib) * app-gui (depends on lib and jms) Everything in the project versions in lock-step. The entire project is one version - defined in the top-level project.xml. Currently it is 2.1-dev (we'll strip the dev for production release). So in project.xml: <currentVersion>2.1-dev</currentVersion> In app-jms, I would define app-lib as a dependency: <dependency> <groupId>com.sknt.picasso</groupId> <artifactId>xenon-lib</artifactId> <version>${pom.currentVersion}</version> <type>jar</type> </dependency> This would require the jar to be in the local repository, requiring running 'install' The other way of doing it I just tested is to use maven.jar.override and define in project.properties: maven.jar.app-lib = ${maven.multiproject.basedir}/app-lib/target/app-lib-${pom.currentVersio n}.jar In either case, I believe the behavior is the same. So we'll be working on our current version for several months, so the filenames won't change. It seems that app-jms will not recompile as long as it sees the same filename for app-lib present, even if someone has changed some of the classes in app-lib. For example, if someone mistakenly took away a method in a class, I want app-jms to output an error. I'm not sure that it does. What should the correct behavior be? And if it's not what I described, what needs to be done to make it so? Thanks. -Randy Dion Gillard wrote: >If the classes have changed and not the version, then there's a >problem. A version is not supposed to change (unless it's a SNAPSHOT). > >Give us a concrete example and we can talk it out, > >e.g. > >A version=SNAPSHOT - no dependencies >B version=2.5 - depends on A v 1.2 >C version=1.0 - depends on B v2.5 > >if you run multiproject:install on those, B will use the version of A >in the local repository, NOT the version installed (A-SNAPSHOT.jar). > > > >On Sun, 09 Jan 2005 17:33:47 -0500, Randy Xu <[EMAIL PROTECTED]> wrote: > > >>Actually, it seems to me that there is a stale dependency problem even >>when you do run multiproject:install. It seems that Maven only checks >>to see that the version tag (and hence filename) is the same. I don't >>see it recompiling subprojects even when I believe that classes within >>dependency subprojects have been recompiled. >> >>Any easy solution to this? >> >>-Randy >> >>Dion Gillard wrote: >> >> >> >>>Dependencies always come from the local repository. If you don't put >>>the updated dependencies there, the dependent projects will use what's >>>there. >>> >>> >>>On Sun, 09 Jan 2005 15:25:20 -0500, Randy Xu <[EMAIL PROTECTED]> wrote: >>> >>> >>> >>> >>>>Would not running multiproject:install mean that changes to subprojects >>>>are not propagated to other subprojects? >>>> >>>>So: >>>> >>>>1) app-gui depends on app-lib >>>>2) I change app-lib >>>>3) I run multiproject:artifact instead of multiproject:install >>>> >>>>app-gui will use the stale app-lib.jar in the repository? >>>> >>>>-Randy >>>> >>>>-------------------------------------------------------------------- - >>>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
smime.p7s
Description: S/MIME cryptographic signature
