I have a related question to SNAPSHOTs, now that we have a thread on this. I notice that SNAPSHOT jar file names substitute the version for the word SNAPSHOT. How does this behavior work for projects that have multiple branches?
Our Platform project at work has many branches to it, there is a v1.0 branch, a v1.1 branch, and a v2.0 branch. The 1.0 branch is stable, no new changes are going in it (unless they are bug fixes). The 1.1 and 2.0 branches are not stable yet. So in our Maven repository we would ideally have platform-1.0.jar (stable) platform-1.1-SNAPSHOT.jar (not stable) platform-2.0-SNAPSHOT.jar (not stable) but in reality the SNAPSHOT versions lose the version number so I end up with something like platform-1.0.jar (stable) platform-SNAPSHOT.jar (for 1.1) platform-SNAPSHOT.jar (for 2.0) The relevant portions of the project.xml files for the projects are <project> <groupId>qrs</groupId> <id>platform</id> <currentVersion>2.0-SNAPSHOT</currentVersion> ... </project> When I jar:install-snapshot goal, I get the platform-<timestamp>.jar, and a platform-SNAPSHOT.jar (which are the same). I've just lost the version though! I should have platform-2.0-SNAPSHOT.jar. I can change the project.xml to look like <project> <groupId>qrs</groupId> <id>platform-2.0</id> <currentVersion>SNAPSHOT</currentVersion> ... </project> but that seems to go against Maven policies. Any suggestions here? -----Original Message----- From: Sonnek, Ryan To: 'Maven Developers List' Sent: 12/19/2003 4:12 PM Subject: RE: new maven goal I see your point. My original impression was that people were wanting to have every snapshot from the projects' inception on the remote repo. I could see a maven continuous integration server running and providing snapshot artifacts for a month or so. Maybe I could modify this plugin to keep archives of snapshots by date or a certain number. Now I have 2 scenerio questions to ask you. 1. How would your developer know which snapshot worked and which snapshot didn't? It's still going to be a hassle and problematic to guess which snapshot to rollback too. 2. If you're depending on SpicyJMX-SNAPSHOT, that suggests to me that you are integrating with current features and will use a stable release when one is finished. That means that your developers will NEED to use the "broken" new snapshot and fix the incompatibilities as your dependency changes them. Ryan -----Original Message----- From: Ryan Hoegg [mailto:[EMAIL PROTECTED] Sent: Friday, December 19, 2003 5:57 PM To: Maven Developers List Subject: Re: new maven goal Scenario: (all projects mentioned below are fictitious.. blah blah) I am working on jFnord, an open source project with at least three other active developers. I am the primary developer of FnordJMX, which depends on the SNAPSHOT version of SpicyJMX. I go on a three week holiday for Christmas. SpicyJMX developers release a few new SNAPSHOTs. The other jFnord developers try to work on the CVS version, and it fails to build. In this case, I think resolving snapshots is the best course of action. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net Sonnek, Ryan wrote: >Understood. I think that this plugin is strictly for developers use on >their local respository, and any files on the remote repository must be >handled with great care. > >Although, I personally question the usefulness of having multiple archived >snapshots on the remote repository. If you are developing an application >with a SNAPSHOT dependency, you are essentially on the bleeding edge anyways >and putting yourself at risk of suffering changes from the other project >(versus waiting for a stable release). I honestly don't see when you would >want to use the "resolve-snapshots" goal to change from a SNAPSHOT release >to a TIMESTAMPED release. IMO, you should be using the snapshot OR an >official release. > >Ryan > > > --------------------------------------------------------------------- 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]
