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.htmlIt 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/ ChicagoSubject: 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.propertiesmade 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 assumptionsabout what modules versions should be used and it could lead to somenasty 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
