Before we go ahead and drop this feature again, I just like to make sure that all people understand _why_ this got implemented the way it is!
If you have lots of projects locally and some projects need an additional repository x, then you just add this repo-x to the <repositories> section of your projects pom. While building your project some artifacts will get downloaded. Let's say you have the repository.jboss.org added to your project and did download JBoss Arquillian. After a build, the arquillian artifacts will then be available in your local repository. Let's assume you then start another project but you don't add the repository.jboss.org. The old maven behaviour was that you still have access to all artifacts in your local repo. So your project will build just fine locally, but if you push your project to github and another person tries to build this project he would get an error because he cannot resolve the arquillian artifacts! Another problem did arise with the java.net maven repo and other repos which contain broken artifacts. This repo historically had a _very_ bad quality, serving broken artifacts, wrong md5 sums, etc. Most of those artifacts also have been available on maven.central - but with a checked and confirmed quality! So back in the days if one project enabled the java.net repo and you downloaded such artifacts from there, then you were basically doomed for the rest of your ~/.m2/repository life ;) Because even other projects which didn't have the java.net repo enabled would now fail. Benjamin, did I forget any other important point? I think if we disable the repo separation now, we should aim to not default back to our original behaviour which also caused lots of problems. LieGrue, strub ----- Original Message ----- > From: Mark Derricutt <[email protected]> > To: Maven Users List <[email protected]> > Cc: > Sent: Sunday, October 23, 2011 7:17 PM > Subject: Re: Maven 3, _maven.repositories and *lastUpdated > > Hrm - this should exactly like the behavior that the newer Aether library > -already- solves, as has done for months when you drop in the newer version. > > I know this post is more about disabling the feature, but ignoring it makes > WAY more sense IMHO. If, as you say - "Artifact A downloaded from X is not > the same thing to Maven 3 as A downloaded from Y" then the entire GAV is a > lie as it DOESN'T actually identify an artifact. > > Mark > Still wanting that 3.0.4 release... > > -- > "Great artists are extremely selfish and arrogant things" — Steven > Wilson, > Porcupine Tree > > > On Sun, Oct 23, 2011 at 6:19 AM, Jason van Zyl <[email protected]> wrote: > >> The artifacts have an identity. It matters where the artifacts were >> downloaded from. Artifact A downloaded from X is not the same thing to > Maven >> 3 as A downloaded from Y. This can happen when you flip your settings.xml > to >> go from using a repository manager to using Maven Central directly for >> example. >> >> There is currently no way to turn that off. But you can vote for the >> issue[1]. >> >> [1]: http://jira.codehaus.org/browse/MNG-5181 >> >> On Oct 22, 2011, at 10:05 AM, Stefan Eder wrote: >> >> > With Maven 3 dependency resolution may fail for artifacts, which have >> once been fetched from a remote repository, even so they are available >> within the local repository. >> > Guess there is a good reason for that and I would like to understand > it >> and I would like to know if there is a way to switch this behaviour off. >> > >> > Thanks, Stefan >> > >> > >> > --------------------------------------------------------------------- >> > 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 >> --------------------------------------------------------- >> >> In short, man creates for himself a new religion of a rational >> and technical order to justify his work and to be justified in it. >> >> -- Jacques Ellul, The Technological Society >> >> >> >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
