On Oct 23, 2011, at 1:52 PM, Mark Struberg wrote: > 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! >
I wasn't suggesting dropping the capability because that will potentially lead to non-deterministic results. Any change would have to provide at least the same amount of safety. > 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. More succinctly it is the case where an artifact is available from multiple remote repositories. You could add repositories elements, or change your settings.xml > > > 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! > The problem can also present itself as a local build failure. The artifact with a GAV taken from a public source may not be the same as an internally patched version for example. Building something that depends on the publicly available artifact will work fine if that's what you download first, but something that depends on the patched version may not. This is the primary reasoning behind the repository being incorporated into the identity. > 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. This is essentially the same as the case above. People patch crappy artifacts and corresponding metadata and retrieve those from one location, and then change the location. What you have is not same, at least in most cases with Java.net. > > 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. > We should not disable this feature, the repository being incorporated into the identity is paramount. If we can arrive at a place where we think the contents from one location can be determined to be the same as another we might be able to consider them equivalent at some level. The checksum might be enough, I haven't thought about it that long. > 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] > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham
