What about taking a play from the Gentoo Portage book? Something similar to the package masking ~arch keyword might do the trick:
Add an extra tag to the POM schema which indicates whether or not the POM is stable. Add a tag in the settings file which indicates whether or not you want to use unstable dependencies. Modify the dependency download code to fail on unstable downloads unless the settings file indicates otherwise. This way, you can use the same repository for both camps of users. Thoughts? Kris On Sat, 2005-07-09 at 00:39 -0700, Michal Maczka wrote: > John Casey wrote: > > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > >I think that such a drastic step will only serve to completely > >marginalize maven 2.x, and alienate users. Who would convert to using m2 > >if they first had to re-request uploads for the 10 dependencies they > >have?? > > > I hope that m2 users will help you to get this problem fixed. > > >While I agree that the repository information we currently have > >is inadequate and incomplete, such is life. When have you ever worked on > >a product revision/rewrite where you *didn't* have to deal with bad > >data? > > > In my build system?? Never! That's too high risk to take. I would only > change the build system if I would be certain that if will > not deceive me as I have to many problems to deal with elsewhere. > > >The answer is *never* to blow away everything you know and replace > >it with only the things you know to a perfect degree...you'd be > >re-creating your datastore with every new major version. > >Also, to address your assertion about Maven 2.x's readiness for > >production - perhaps you noticed the -alpha-3 notation we've used on the > >latest release? ;) This software isn't perfect yet, and neither is the > >data it relies on...but we're working on it, and it *will* get better. > > > > > > > But you are aiming at 2.0 release real soon: in August, do not you? > I personally would keep maven in alpha stage as long as repository is > not ready for public use even if the m2 code will be prefect > and ready for prime time as you simply cannot use m2 without reliable > repository. > This gives a full right to use the current strategy for improving the > repository data. > > >Obviously, having naked poms isn't a good idea, but it will help users > >trying to migrate from maven 1.x (where they couldn't use the > >transitivity of dependencies anyway), and as these users attempt to trim > >their own dep lists, they can help us fix these bad poms. We cannot > >adopt the strategy of only putting perfect metadata into the repository, > >since our users need access to such a wide spectrum of libraries. > >Initially, for upgrading users, it will be better to have *some* access > >to these artifacts rather than clogging the MAVENUPLOAD project with > >re-requests. > > > > > I am complete agreeing with you. > I am just linking 2.0 release (which gives clear signal to users: __it > is production ready__) with readiness of the repository for the > demanding (normal?) users > and not just for those brave early adopters, which are generally fans > of maven and will use it anyway. > Once m2 final relases will get the label of being not reliable as its > repository is constantly changing this is what can be actually > the factor (just hypothesis) which "marginalize maven 2.x, and alienate > users" > as it is very difficult to change such negative image after "bad press", > which you will surly have. > I am just feeling that missisng poms in the repository give more > motivation to provide good ones then naked ones as they give the false > impression > that data in the repository is OK. I do hope to have time to help you to > clean you poms I am using. And I am hoping that your community will > really help you to get it fixed asap. > > just my 2 cents > > regards > > Michal > > > > > ---------------------------------------------------------------------- > Zamachy w Londynie: FOTO RAPORT >>> http://link.interia.pl/f18a1 > > > --------------------------------------------------------------------- > 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]
