Ryan I think that a great point. When you state one has a dependency on a branch of a project, as opposed to a stable release of a project, then you might encounter times that building your code against a snapshot from that branch might break your build. That is the reason why following a branch means you must sync often, and try to follow HEAD as closely as possible.
We are addressing this exact problem at my work. We have many projects that are dependent on a branch my group is responsible for. That code is fluctuating because it isn't stable yet. In the past people would grab our jar file in an ad hoc manner, meaning they would grab some release point of our branch that does not match with HEAD. As a result many people saw bad things happen. And it was all derived from not taking a build jar from HEAD but at some prior point in the branches time. As a result, I'm not sure why one would need to keep track of all the different timestamp version of a snapshot branch, when it is constantly changing. We probably post a new SNAPSHOT 10 times a day, consequently we are going to be having artifact bloat. -----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]
