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 <[email protected]>:
+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 <[email protected]
>:
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 <[email protected]>
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 <[email protected]>
wrote:
On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz
<[email protected]>
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
--
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: [email protected]
For additional commands, e-mail: [email protected]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
