Taylor, Please note that we only using Maven dependency resolution from Maven plugin. In runtime dependencies are resolved by OSGi container and required plugins are resolved by our own custom resolver.
Note that from Maven point of view version 1.0.0 is bigger then 1.0.0-SNAPSHOT, but from OSGi point of view version 1.0.0 is less then 1.0.0.SNAPSHOT. Though both Maven and OSGi allow similar version specifications. For example you can write: Require-Bundle: org.terracotta.modules.modules_common;bundle-version="[1.0.0,2.0.0)" Also note that we can't use versions like 1.0.0-SNAPSHOT in Bundle-Version and Require-Bundle attributes of module's manifest.mf because OSGi prohibit that. We need to workaround that somehow because this is a major issue with current dependency resolution. If we won't specify versions at least for l1.configbundles.default modules, then we leave chance that module from version 2.5 can be picked up when using tc.jar from version 2.6. So, I believe those versions need to be explicit. I created jira issue CDV-435 as per Steve request. You can reproduce dependency management issues using standalone kit. To do that run tcbuild dist_maven to deploy everything to the local Maven repository and then pass -Dtc.tests.configuration.modules.url=<path to local maven repo> regards, Eugene Taylor Gautier wrote: > Yes, according with Better Builds With Maven, Maven reloads SNAPSHOTS > daily, unless given a -U parameter. > > Also, the version range check is specified as: > / > "What this means is that, while the nearest dependency technique will > still be used in the case of a > conflict, the version that is used must fit the range given. If the > nearest version does not match, then > the next nearest will be tested, and so on. Finally, if none of them > match, or there were no conflicts > originally, the version you are left with is [1.1,). This means that > the latest version, that is greater > than or equal to 1.1, will be retrieved from the repository. > > The notation used above is set notation, and table 3-2 shows some of > the values that can be used. > > Table 3-2: Examples of version ranges > Range Meaning > (,1.0] Less than or equal to 1.0 > [1.2,1.3] Between 1.2 and 1.3 (inclusive) > [1.0,2.0) Greater than or equal to 1.0, but less than 2.0 > [1.5,) Greater than or equal to 1.5 > (,1.1),(1.1,) Any version, except 1.1 > / > Finally, note that not specifying a version will, as I understand it, > find the nearest closest match. > > Taylor Gautier wrote: >> Hmm, this article seems to indicate Maven checks on every >> build...doesn't seem to match my experience though I am fairly >> certain it does check. >> >> http://www.developer.com/lang/article.php/3510331 >> >> Taylor Gautier wrote: >>> Here's some reading for anyone interested: >>> >>> http://maven.apache.org/guides/mini/guide-naming-conventions.html >>> http://maven.apache.org/maven-conventions.html >>> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html >>> http://maven.apache.org/guides/mini/guide-releasing.html >>> >>> It doesn't cover SNAPSHOT naming if anyone can find that please >>> point it out. Please note that not all sub-projects will switch to >>> snapshot, only those that are being worked on. When they are >>> released, they switch back. >>> >>> Jason can probably fill us in here, but there is both a way to >>> publish SNAPSHOTS with a unique name (I believe the date is >>> appended) as well as a way to specify ranges in the version >>> dependency. I can't find that stuff just now... >>> >>> Generally speaking, it's not normal to depend on a SNAPSHOT >>> build...as for "upgrading" between SNAPSHOT builds, this is another >>> area where I had intended to do more research, maybe someone has an >>> answer - but I believe Maven does check - maybe not every build, >>> maybe every day or something for new SNAPSHOTs. Or maybe I am mistaken. >>> >>> >>> Geert Bevin wrote: >>>> Seems indeed a process that should be possible to automate for >>>> release. I agree with Juris that doing this manually at each release >>>> is asking for trouble. It's too easy for one to slip through without >>>> being updated properly. >>>> >>>> I have another question though (not sure if this has been covered >>>> already). Imho we should always replace the -SNAPSHOT suffixes, even >>>> when nightly builds are made. Otherwise, people will never be able to >>>> automatically upgrade between snapshots. So, -SNAPSHOT should ideally >>>> be replaced by the SVN revision number and some prefix/suffix >>>> indicating that this is a nightly build. Thinking further along those >>>> lines, I'm wondering if the version dependencies shouldn't be a bit >>>> more flexible. Depending on exact versions is frustrating since it >>>> means that all references will always have to be updated when newer >>>> releases come out. I'm not sure what the possibilities are, and if >>>> the required information is available through Maven repositories, but >>>> I think that it might be interesting to be able to do something like >>>> this: >>>> >>>> >=2.0.3 >>>> foo 2.0.3 or later >>>> >>>> =2.0* >>>> any foo 2.0.x >>>> >>>> <=2.0.2 >>>> foo 2.0.2 or previous >>>> >>>> =2.0.1 >>>> foo 2.0.1 exactly >>>> >>>> On 26 Sep 2007, at 00:57, Alex Miller wrote: >>>> >>>> >>>>> Automate! >>>>> >>>>> ----- Original Message ----- >>>>> From: "Juris Galang" <[EMAIL PROTECTED]> >>>>> To: [email protected] >>>>> Sent: Tuesday, September 25, 2007 5:52:46 PM (GMT-0600) America/ >>>>> Chicago >>>>> Subject: Re: [tc-dev] versions and modules >>>>> >>>>> Because we have to scan for references to SNAPSHOTs each time we have >>>>> to do a release. People are bound to forget. >>>>> >>>>> On Sep 25, 2007, at 3:44 PM, Steven Harris wrote: >>>>> >>>>> >>>>>> It won't be all modules. only the ones that have changed. A released >>>>>> module should >>>>>> have no dependencies on snapshots. Why do you think it is iffy? >>>>>> >>>>>> On Sep 25, 2007, at 3:33 PM, Juris Galang wrote: >>>>>> >>>>>> >>>>>>> Feels kinda iffy that we have to go through and un-SNAPSHOT our >>>>>>> modules every release/code-freeze time. >>>>>>> >>>>>>> We could bring back the snapshot repository to simplify things; but >>>>>>> that would mean we'd be locked in a mode where the user is either >>>>>>> working with snapshots or not - though I think this might not be a >>>>>>> bad thing; >>>>>>> >>>>>>> Eugene pointed out however that some users could find it useful to >>>>>>> mix-and-match --- question is: would this be the more common use >>>>>>> case? >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sep 25, 2007, at 2:09 PM, Eugene Kuleshov wrote: >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I had somehow lengthy discussion with Juris about config modules, >>>>>>>> versions and dependency resolution. >>>>>>>> >>>>>>>> Recently added default modules that are specified in >>>>>>>> tc.properties >>>>>>>> made whole picture little more messy, especially if take Maven into >>>>>>>> the >>>>>>>> equation. >>>>>>>> >>>>>>>> To summarize, DSO configuration modules that are used at runtime >>>>>>>> can >>>>>>>> come from several places: >>>>>>>> >>>>>>>> -- l1.configbundles.default entry in tc.properties: >>>>>>>> l1.configbundles.default = >>>>>>>> excludes-config;guimodels-config;jdk15-preinst-config;spring- >>>>>>>> config;standard-config >>>>>>>> >>>>>>>> -- modules declared in tc-config.xml >>>>>>>> <modules> >>>>>>>> <module name="clustered-ehcache-1.3" version="1.0.0"/> >>>>>>>> </modules> >>>>>>>> >>>>>>>> -- transitive dependencies listed in manifest.mf of any other >>>>>>>> module. >>>>>>>> Foe example for clustered-hibernate-3.1.2 we currently have: >>>>>>>> Bundle-SymbolicName: org.terracotta.modules.clustered- >>>>>>>> hibernate-3.1.2 >>>>>>>> Bundle-Version: 1.0.0 >>>>>>>> Require-Bundle: org.terracotta.modules.modules_common, >>>>>>>> org.terracotta.modules.clustered-cglib-2.1.3 >>>>>>>> >>>>>>>> If you think about above examples, they leave lots of assumptions >>>>>>>> about what modules versions should be used and it could lead to >>>>>>>> some >>>>>>>> nasty issues at the runtime. >>>>>>>> >>>>>>>> For some reason I thought it been agreed that we should always >>>>>>>> explicitly specify all versions and also use -SNAPSHOTS between >>>>>>>> releases, but it doesn't seem like it been changed in existing >>>>>>>> modules, >>>>>>>> except that tcbuild is adding -SNAPSHOT suffix to the nightly build >>>>>>>> jars >>>>>>>> deployed to maven repo. >>>>>>>> >>>>>>>> So, above configuration snippets should be changed as the >>>>>>>> following: >>>>>>>> >>>>>>>> l1.configbundles.default = >>>>>>>> excludes-config,1.0.0-SNAPSHOT;guimodels-config,1.0.0- >>>>>>>> SNAPSHOT;jdk15-preinst-config,1.0.0-SNAPSHOT;spring-config,1.0.0- >>>>>>>> SNAPSHOT;standard-config,1.0.0-SNAPSHOT >>>>>>>> >>>>>>>> Bundle-SymbolicName: org.terracotta.modules.clustered- >>>>>>>> hibernate-3.1.2 >>>>>>>> Bundle-Version: 1.0.0-SNAPSHOT >>>>>>>> Require-Bundle: >>>>>>>> org.terracotta.modules.modules_common;bundle- >>>>>>>> version="1.0.0.SNAPSHOT", >>>>>>>> >>>>>>>> org.terracotta.modules.clustered-cglib-2.1.3;bundle- >>>>>>>> version="1.0.0.SNAPSHOT" >>>>>>>> >>>>>>>> note that we can't use "-" for SNAPSHOT suffix in the bundle >>>>>>>> version, >>>>>>>> because OSGi prohibits that, so we may need some mapping in our >>>>>>>> module >>>>>>>> jar resolver code. >>>>>>>> >>>>>>>> Then at release/code freeze time someone will have to do a quite >>>>>>>> verbose operation and change all those versions to the release >>>>>>>> versions. >>>>>>>> >>>>>>>> Any thoughts? >>>>>>>> >>>>>>>> regards, >>>>>>>> Eugene >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> tc-dev mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> tc-dev mailing list >>>>>>> [email protected] >>>>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev >>>>>>> >>>>>> _______________________________________________ >>>>>> tc-dev mailing list >>>>>> [email protected] >>>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev >>>>>> >>>>> _______________________________________________ >>>>> tc-dev mailing list >>>>> [email protected] >>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev >>>>> >>>>> _______________________________________________ >>>>> tc-dev mailing list >>>>> [email protected] >>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev >>>>> >>>> >>>> -- >>>> Geert Bevin >>>> Terracotta - http://www.terracotta.org >>>> Uwyn "Use what you need" - http://uwyn.com >>>> RIFE Java application framework - http://rifers.org >>>> Music and words - http://gbevin.com >>>> >>>> _______________________________________________ >>>> tc-dev mailing list >>>> [email protected] >>>> http://lists.terracotta.org/mailman/listinfo/tc-dev >>>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> tc-dev mailing list >>> [email protected] >>> http://lists.terracotta.org/mailman/listinfo/tc-dev >>> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> tc-dev mailing list >> [email protected] >> http://lists.terracotta.org/mailman/listinfo/tc-dev >> > ------------------------------------------------------------------------ > > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev > _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
