Yes it would hurt. A build then becomes dependent on the certlist in order for it to function.
In such a way, a cert list becomes directly equivalent to a <repository> definition in a pom.xml file. We do not allow <repository> definitions in pom files for a good reason. certlists is just another name for the same thing. By all means I see repository managers being able to use certlists... but these would be applied at the repository manager level and not at the "settings.xml" or at the "pom.xml" level. If you need a specific certlist in order to build correctly, then I do not think we should allow your new artifacts into central... and now certlists are a dead duck Just my opinion, Stephen 2009/9/28 Albert Kurucz <albert.kur...@gmail.com> > Filtering is already used for another Maven feature. > To avoid ambiguity, we should better call the one what I defined: > repository-skinning or repository-certification. > Do you think this new feature would hurt the repo or any Maven user? > > On Sun, Sep 27, 2009 at 11:27 PM, Albert Kurucz <albert.kur...@gmail.com> > wrote: > > It is not necessary to create a new repo and it is not necessary to > > modify anything on Central or the policies how it is managed. Mess > > could be cleaned up virtually if I could attach a filter. > > > > In the ~/.m2/settings.xml for example, I should be able to add a list > > of repository addresses and for each of this repositories (which list > > could include the Central repo) I should be able to setup a URL of the > > filter which I would wanna use. > > > > Filter format could be for example the nexus repository index format. > > One example is here: > > http://repository.codehaus.org/.index/ > > > > My Maven client software should effectively hide artifacts from > > repositories (not only from Central) which artifacts have no reference > > on my selected filter index. > > > > Maven users have different needs, so they would sign up to different > > filters. Users would never loose faith of Central repo for its > > content. Only the index providers could be blamed for the garbage or > > for the missing artifacts, but this is highly unlikely, because they > > will maintain their index files by automated processes. > > > > It would be courteous from the current Maven Central maintainers if > > they provide a filter, which reflects the requirements what was > > originally made to get into Central: > > http://maven.apache.org/guides/mini/guide-central-repository-upload.html > > (but lots of things got in, which do not comply to this). > > > > > > > > > > On Sun, Sep 27, 2009 at 6:45 PM, Brett Porter <br...@apache.org> wrote: > >> > >> On 27/09/2009, at 5:15 AM, Jason van Zyl wrote: > >> > >>> Not having a super high quality central repository actually makes our > >>> commercial efforts a lot harder. If I was devious I would have agreed > with > >>> Brett and would make a completely clean central repository as our plans > >>> require intact repositories. But we don't have a clean repository and > trying > >>> to make a separate one would be a disaster for general use. You have to > live > >>> with what's there and Sonatype will actually invest in cleaning up the > >>> generally available repository. We already have with efforts like this: > >>> > >>> http://nexus.sonatype.org/oss-repository-hosting.html > >> > >> Given this comment, I think you might have misunderstood my post on dev@ > ... > >> I was of the opinion that clean going forward makes sense, past stuff is > >> still available, but working on ways to make Maven understand metadata > >> changes so that you can actually fix things that go wrong. Some related > >> themes have come up in this thread over the weekend, but I'll try and > follow > >> up on dev@ later with something more concrete. > >> > >> - Brett > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
