> 1) defined rules for what an "acceptable" artifact is > 2) gating central with those rules Any time when I referred to http://maven.apache.org/guides/mini/guide-central-repository-upload.html as a requirement, I always had a bad feeling. Why? Requirement is what you can verify against, but this mini howto is not a requirement then. Rules need to be defined in software. Could someone write a unit test?
> 3) extensible repository metadata support in Maven (this keeps coming up for > a variety of reasons) Extending metadata is good as long as creating/using that metadata is optional, like at #5. > 4) the ability to revise metadata without impacting historical builds (SCMs > move, people make mistakes with dependency scopes, we need to rewrite > locations, deprecation, rules for "acceptable" change, etc). Going back in history of multiple projects cannot be done reliable based on SCMs. It could be done only if attached sources are full and buildable. This would make the repo a kind of SCM: diff only between releases, details hidden, but OK. > 5) a way to identify all the artifacts that are marked "acceptable" to have > a cleaner build How do you mark "acceptable" when it is not always means the same for everyone? I have proposed in the original thread a solution, based on multiple index files, which index files would represent the output of CAs. If I configure in my Maven settings file (by URL) which index file I want to use, my Maven should be blind to any other artifacts on the repo. Allowing AND and OR operations on this cert lists would be a bonus. It is interesting, that the Central itself could store these (cert list) index files packaged in artifacts. Some index files should be for the public some for limited use. As a client of Central give me a choice which one I sign up to. Acceptance criteria cannot be the same for everyone. On Wed, Sep 30, 2009 at 12:20 AM, Brett Porter <[email protected]> wrote: > Ok, I did a poor job of expressing what I was getting at. > > On 25/09/2009, at 2:02 PM, Jason van Zyl wrote: > >> >> What's matters is improvement of the process going forward. > > Agreed, I see that as a pre-requisite. > >> As people move forward with improved submissions from projects then the >> older submissions of dubious quality will naturally fall out of use. > > That may not happen in any sort of feasible timeframe. There is some very > old stuff out there that isn't getting new releases in a hurry. As you > traverse a dependency tree, it's nearly impossible not to hit the rough > spots like early commons-logging releases, velocity vs velocity-dep, > plexus:plexus-utils vs org.codehaus.plexus:plexus-utils and so on. > > On 25/09/2009, at 2:11 PM, Brian Fox wrote: > >> Who would _want_ to deploy their stuff >> to the "old" repo? No one. The hurdle to get to the new repo would be >> the same as putting the checks on the current repo for all new >> artifacts. > > I agree - I'm not saying we allow anyone to deploy to the "old" one - but it > would be nice to have a way in Maven to say "only use stuff that meets the > criteria", and let that drive further clean up efforts. > > Maybe it's not a separate repository, but just a trigger to only accept > artifacts "marked" in some way. > > But I don't think just doing new stuff is enough - we need a way to reliably > correct existing artifacts, and prepare for the future when the bar moves > again. > > This is the steps I saw towards it: > 1) defined rules for what an "acceptable" artifact is > 2) gating central with those rules > 3) extensible repository metadata support in Maven (this keeps coming up for > a variety of reasons) > 4) the ability to revise metadata without impacting historical builds (SCMs > move, people make mistakes with dependency scopes, we need to rewrite > locations, deprecation, rules for "acceptable" change, etc). > 5) a way to identify all the artifacts that are marked "acceptable" to have > a cleaner build > > Does that make any sense? > > - Brett > > --------------------------------------------------------------------- > 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]
