maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Gier <pg...@redhat.com>
Subject Re: a cleaned up central repository?
Date Fri, 02 Oct 2009 12:57:47 GMT
Why would everyone need to use both repos?  If the legacy repository is done 
correctly, the vast majority of users would never need to hit it, or even know 
about it at all.

Note that this idea is different than creating a new clean repository.  This 
would be a new repository just for the garbage.  Most artifacts would stay where 
they are.

Just as an example, in the jboss repo I found someone had mixed up the main jar 
with the javadoc jar.  So Maven was trying to use the javadocs on the classpath. 
  Stuff like this is unusable, and should be removed from the repository IMO.

Stephen Connolly wrote:
> if we have a second repo at all that means that anyone not using a 
> repository manager will hit both repos for every artifact (which is bad)
> 
> IMHO, central is what it is, all we can do is add metadata to help paint 
> over the crayon scribbles on the wall from when the children were 
> growing up ;-)
> 
> -Stephen
> 
> Sent from my [rhymes with tryPod] ;-)
> 
> On 1 Oct 2009, at 18:39, Paul Gier <pgier@redhat.com> wrote:
> 
>> What about creating a new legacy repository for deprecated artifacts?  
>> Stuff that we don't want in the main repository could be moved to a 
>> new legacy repo. This way we effectively deprecate these artifacts, 
>> but it does not require any POM or metadata changes.  Anyone that 
>> needs to use the deprecated artifacts, could then just add the legacy 
>> repo to their repo manager or a profile in settings.xml.
>>
>> Jason van Zyl wrote:
>>> On 2009-09-25, at 5:13 AM, Petar Tahchiev wrote:
>>>> Hi all,
>>>>
>>>> I also like the idea about deprecating artifacts, or whole directory 
>>>> structure.
>>>> A step forward would be to create a maven-dev-approved repositories or
>>>> artifacts.
>>> Exactly, this is all part of providing better information over time. 
>>> There is no big bang cleanup that makes it all better. That is just a 
>>> pipe dream. We just have to incrementally and diligently clean up 
>>> what we have. Maven Central is a great resource and it needs some TLC 
>>> but not cleansing.
>>>> Imagine you are using an outside repository that is really messed up
>>>> (or worse - anyone can put anything any time).
>>>> What maven the team could do is setup a ground base of rules, so that
>>>> if you want your repository to be
>>>> maven-dev-compliant you must follow them. Later if you are using
>>>> artifacts from repositories that are not
>>>> maven-dev-compliant, there could be a message warning you.
>>>> To me it doesn't really make sense to create a new repository without
>>>> improving the process of using the repositories.
>>>> Otherwise, as Brian pointed, we will end up with a new repository,
>>>> which has the same data, and no one is using the old repo.
>>>>
>>>> Cheers, Petar.
>>>>
>>>> Because without it doesn't really make
>>>> sense creating new repository and
>>>>
>>>> 2009/9/25 Stephen Connolly <stephen.alan.connolly@gmail.com>:
>>>>> +1 to adding deprecation metadata.
>>>>>
>>>>> -1 to having a plugin... the deprecation warnings should come from
>>>>> maven core itself... ok we can add a plugin for [2.0.x,2.2.1] support
>>>>>
>>>>> Also if we are adding deprecation metadata, there are a number of
>>>>> other little bits of metadata that should be added, e.g. version
>>>>> comparison scheme (since OSGI rules are different from Maven 2.x
>>>>> rules, we will need a way to flag which rules apply... I see this as
>>>>> being a rule applied to a groupId or at best a groupId:artifactId...
>>>>> if you want to change your version comparison rule halfway through,
>>>>> change the groupId or the artifactId)
>>>>>
>>>>> -Stephen
>>>>>
>>>>> 2009/9/25 Anders Kristian Andersen 
>>>>> <anders.kristian.andersen@gmail.com>:
>>>>>> I think it is TOTAL important we keep the contract:
>>>>>> *** This is a long standing rule that we do not remove or change
the
>>>>>> contents of central ***
>>>>>>
>>>>>> Therefore a way out could be to start making deprecated tags in the
>>>>>> directories.
>>>>>> Then we could come up with a  *** 
>>>>>> maven-deprected-dependency-plugin *** that
>>>>>> could warn users against various bad / deprecated / moved artifacts.
>>>>>>
>>>>>> Consider a director xxxx with pom.xml and other files.
>>>>>>
>>>>>> adding a file called deprecated.xml could deprecate the directory

>>>>>> / parts of
>>>>>> the files etc.
>>>>>>
>>>>>> then running
>>>>>>
>>>>>> mvn deprected-dependency:check
>>>>>> would list usage
>>>>>>
>>>>>> This could be combined with options / tools in archiva could help

>>>>>> too.
>>>>>>
>>>>>> best regards
>>>>>> Anders Kristian Andersen
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 25/09/2009, at 06.11, Brian Fox wrote:
>>>>>>
>>>>>>> This has already been done once in history, between M1 and M2
and 
>>>>>>> look
>>>>>>> how we still have that mess to deal with all the time. Doing
this
>>>>>>> again serves no one well, making sure new data coming in is clean
is
>>>>>>> more productive for everyone. 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.
>>>>>>>
>>>>>>> On Thu, Sep 24, 2009 at 8:37 PM, Brett Porter <brett@apache.org>

>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Moving over to dev...
>>>>>>>>
>>>>>>>> So here's a thought - why don't we create a "new" central

>>>>>>>> repository?
>>>>>>>>
>>>>>>>> - a new repository with strict acceptance rules regarding
POMs,
>>>>>>>> signatures,
>>>>>>>> ownership, etc.
>>>>>>>> - if there's a new metadata format needed (recently discussed),

>>>>>>>> this
>>>>>>>> would
>>>>>>>> use it
>>>>>>>> - validated artifacts could be moved over and requests to
the old
>>>>>>>> rewritten
>>>>>>>> (in the same way we maintained the maven1 repo)
>>>>>>>> - default Maven can ship with both repositories enabled,
but a 
>>>>>>>> "best
>>>>>>>> practice" would be to turn old central off (or better, use
a 
>>>>>>>> repository
>>>>>>>> manager that doesn't access it / only access it for acceptable

>>>>>>>> artifacts)
>>>>>>>>
>>>>>>>> The main issue is finding a way to overcome confusion when
an 
>>>>>>>> artifact is
>>>>>>>> changed - you want "old" builds to keep using the same one
it 
>>>>>>>> always did,
>>>>>>>> but new builds to use the new one (and cope with potential

>>>>>>>> revision of
>>>>>>>> metadata without breaking builds). This is the sort of thing

>>>>>>>> that could
>>>>>>>> be
>>>>>>>> built into Maven in a new version and the new repo format
only 
>>>>>>>> accessible
>>>>>>>> from that version.
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Brett
>>>>>>>>
>>>>>>>> On 25/09/2009, at 12:52 PM, Albert Kurucz wrote:
>>>>>>>>
>>>>>>>>> Jason and Brian, thanks for the explanations.
>>>>>>>>> Understood, the policy of not removing anything from
Maven Central
>>>>>>>>> serves a purpose.
>>>>>>>>>
>>>>>>>>> I wish there would be another publicly Maven repository,
which is
>>>>>>>>> maintained with rules enforced. This repo could even
have a rule
>>>>>>>>> (additional to the old and unenforced rules) that only
Maven built
>>>>>>>>> projects can enter, maybe even more restriction: only
the 
>>>>>>>>> designated
>>>>>>>>> Continuous Integration server can upload to it.
>>>>>>>>> This pure Maven repo would not be able to compete with
Maven 
>>>>>>>>> Central
>>>>>>>>> regarding size or the number of artifacts, but some OSS
developers
>>>>>>>>> might prefer to use from and supply to this one instead
of the 
>>>>>>>>> big and
>>>>>>>>> ugly.
>>>>>>>>>
>>>>>>>>> On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox <brianf@infinity.nu>

>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz
>>>>>>>>>> <albert.kurucz@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Requirements for the POMs are defined as:
>>>>>>>>>>>
>>>>>>>>>>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html

>>>>>>>>>>>
>>>>>>>>>>> I call the artifact corrupt (regarding Maven
Central 
>>>>>>>>>>> Compliance) if
>>>>>>>>>>> the POM of the artifact does not fulfills the
above 
>>>>>>>>>>> requirements.
>>>>>>>>>>> There are corrupt ones have made it to the Central,
because 
>>>>>>>>>>> the guard
>>>>>>>>>>> was sleeping.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Correct, but changing them is not an option because
it will
>>>>>>>>>> destabilize builds. This is a long standing rule
that we do 
>>>>>>>>>> not remove
>>>>>>>>>> or change the contents of central.
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------

>>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------

>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------

>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------

>>>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> Regards, Petar!
>>>> Karlovo, Bulgaria.
>>>> - - - - - - - -
>>>> | Author @ Manning Publications.
>>>> | CEO @ Phamola
>>>> | BGJUG-Bulgarian Java User Group Leader.
>>>> | Apache Maven Developer.
>>>> | Apache Jakarta PMC member.
>>>> | Jakarta Cactus Lead Developer.
>>>> | Codehaus Plexus Developer
>>>> | Blogger: http://weblogs.java.net/blog/paranoiabla/
>>>> - - - - - - - -
>>>> Public PGP Key at:
>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611

>>>>
>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>> Thanks,
>>> Jason
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> ----------------------------------------------------------
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message