maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: a cleaned up central repository?
Date Thu, 01 Oct 2009 18:20:16 GMT
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


Mime
View raw message