Maven 3, _maven.repositories and *lastUpdated

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Maven 3, _maven.repositories and *lastUpdated

Stefan Eder
  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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven 3, _maven.repositories and *lastUpdated

Jason van Zyl-5
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

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




Reply | Threaded
Open this post in threaded view
|

Re: Maven 3, _maven.repositories and *lastUpdated

Mark Derricutt
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 <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> 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
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven 3, _maven.repositories and *lastUpdated

Jason van Zyl-5

On Oct 23, 2011, at 1:17 PM, Mark Derricutt wrote:

> 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.

The GAV itself being a unique identifier, or GUID-like, could only be true if all artifacts came from a single source. This is not the case in practice.

Peter, Paul and Mary could knowingly, or unknowingly, rebuild a library with a given GAV. If all three variants are available under different conditions you potentially have a problem. So if you use a repository manager at work and pull one variant, and then go home and pull from Maven Central, you could potentially have something different. We erred on the side of caution.

A simple change, which is better than disabling this feature, would be to consider the checksum too. I'm just guessing here, but I think that's what users intuitively expect: if it comes from somewhere different but the checksum is the same it's fine, but if it is actually different than what I currently have fail, or at the very least warn me. This would not be hard to change.

>
> 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 <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> 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
>>
>>
>>
>>
>>

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




Reply | Threaded
Open this post in threaded view
|

Re: Maven 3, _maven.repositories and *lastUpdated

Mark Struberg
In reply to this post by Mark Derricutt
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 <[hidden email]>
> To: Maven Users List <[hidden email]>
> 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 <[hidden email]> 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: [hidden email]
>>  > For additional commands, e-mail: [hidden email]
>>  >
>>
>>  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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven 3, _maven.repositories and *lastUpdated

Jason van Zyl-5

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 <[hidden email]>
>> To: Maven Users List <[hidden email]>
>> 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 <[hidden email]> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

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




Reply | Threaded
Open this post in threaded view
|

Re: Maven 3, _maven.repositories and *lastUpdated

Mark Derricutt
In reply to this post by Mark Struberg
Wait - your not SERIOUSLY calling out Maven Central as being a quality
repository?  It's certainly much better now with the excellent work
oss.sonatype.org is providing, but there's still so much broken meta-data
and missing jars and cruft floating around central.

Back to the topic tho - I wouldn't so much be opposed to this behavior if
maven actually told the user this is whats happening, rather than its
current behavior of just saying "artifact not found".  I've had numerous
people question their sanity on IRC, around work and elsewhere the confusion
of artifacts being in their local repository, but not being found.

If Maven said something like:  "The {GAV} artifact was found in your local
repository, but came from the undeclared repository "xxx", either configure
this in your pom, or in your "yyy" mirror."

Was there some reason why only the repository "id" is stored in the
_maven.repositories file, and not the URL to it?  If two projects had
"jboss", and "JBoss" as ids pointing to the same URL, I'd expect them to
work, but I suspect because maven doesn't track that level, then it
wouldn't?

Mark

--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

On Mon, Oct 24, 2011 at 6:52 AM, Mark Struberg <[hidden email]> wrote:

>  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.netrepo and you downloaded such artifacts from there, then you were basically
> doomed for the rest of your ~/.m2/repository life ;)
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven 3, _maven.repositories and *lastUpdated

Mark Struberg
> If Maven said something like:  "The {GAV} artifact was found in your local
Such kind of warning would make a lot of sense. Could you please file an issue? txs!

> Was there some reason why only the repository "id"

I guess it's mainly because of the 'mirror' sections to allow repo managers.

Also in company environments it sometimes happens that server URLs get moved but the content actually remains the same.

I fear there is no perfect solution. If e.g. 2 projects use the same repo-id and point to different URLs, then this would also cause inconsistency. But I think this problem is more theoretic than practically relevant. Lets keep it with Simon&Garfunkel: there are 50 ways to leave your lover (or crash your system)...


LieGrue,
strub



----- Original Message -----

> From: Mark Derricutt <[hidden email]>
> To: Maven Users List <[hidden email]>; Mark Struberg <[hidden email]>
> Cc:
> Sent: Sunday, October 23, 2011 11:03 PM
> Subject: Re: Maven 3, _maven.repositories and *lastUpdated
>
> Wait - your not SERIOUSLY calling out Maven Central as being a quality
> repository?  It's certainly much better now with the excellent work
> oss.sonatype.org is providing, but there's still so much broken meta-data
> and missing jars and cruft floating around central.
>
> Back to the topic tho - I wouldn't so much be opposed to this behavior if
> maven actually told the user this is whats happening, rather than its
> current behavior of just saying "artifact not found".  I've had
> numerous
> people question their sanity on IRC, around work and elsewhere the confusion
> of artifacts being in their local repository, but not being found.
>
> If Maven said something like:  "The {GAV} artifact was found in your local
> repository, but came from the undeclared repository "xxx", either
> configure
> this in your pom, or in your "yyy" mirror."
>
> Was there some reason why only the repository "id" is stored in the
> _maven.repositories file, and not the URL to it?  If two projects had
> "jboss", and "JBoss" as ids pointing to the same URL,
> I'd expect them to
> work, but I suspect because maven doesn't track that level, then it
> wouldn't?
>
> Mark
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven
> Wilson,
> Porcupine Tree
>
> On Mon, Oct 24, 2011 at 6:52 AM, Mark Struberg <[hidden email]> wrote:
>
>>   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.netrepo and you downloaded such artifacts from there, then you were
> basically
>>  doomed for the rest of your ~/.m2/repository life ;)
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven 3, _maven.repositories and *lastUpdated

Stefan-2
Hi guys,

Currently, we're migrating our Archiva to Nexus and I happened to
observe the builds used by different teams lately.
> I fear there is no perfect solution. If e.g. 2 projects use the same
> repo-id and point to different URLs, then this would also cause
> inconsistency. But I think this problem is more theoretic than
> practically relevant.
Turns out, that there are projects where people have declared our
snapshots repository with id "internal" which is naturally assigned to
the internal repo -  maybe because the credentials for both are the
same. So here's an example from practice.

And if I can advocate for keeping this feature - I like it a lot,
because we have certain devs, who sometimes build projects locally and
forget to deploy them, which results in broken builds. Also, this
feature helped me convince the management, why to upgrade to maven 3.

Cheers,
Stefan




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven 3, _maven.repositories and *lastUpdated

Jason van Zyl-5
In reply to this post by Mark Derricutt
I wasn't implying anything about the quality of Maven Central. It's orthogonal to this argument which is to say the GAV could only work as a unique identifier if there was one source, or all sources were identical. The quality of the contents is irrelevant.

The quality of the content is a driving factor in creating variants which I think is your point.

jvz

On 2011-10-23, at 5:03 PM, Mark Derricutt <[hidden email]> wrote:

> Wait - your not SERIOUSLY calling out Maven Central as being a quality
> repository?  It's certainly much better now with the excellent work
> oss.sonatype.org is providing, but there's still so much broken meta-data
> and missing jars and cruft floating around central.
>
> Back to the topic tho - I wouldn't so much be opposed to this behavior if
> maven actually told the user this is whats happening, rather than its
> current behavior of just saying "artifact not found".  I've had numerous
> people question their sanity on IRC, around work and elsewhere the confusion
> of artifacts being in their local repository, but not being found.
>
> If Maven said something like:  "The {GAV} artifact was found in your local
> repository, but came from the undeclared repository "xxx", either configure
> this in your pom, or in your "yyy" mirror."
>
> Was there some reason why only the repository "id" is stored in the
> _maven.repositories file, and not the URL to it?  If two projects had
> "jboss", and "JBoss" as ids pointing to the same URL, I'd expect them to
> work, but I suspect because maven doesn't track that level, then it
> wouldn't?
>
> Mark
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>
> On Mon, Oct 24, 2011 at 6:52 AM, Mark Struberg <[hidden email]> wrote:
>
>> 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.netrepo and you downloaded such artifacts from there, then you were basically
>> doomed for the rest of your ~/.m2/repository life ;)
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven 3, _maven.repositories and *lastUpdated

Jason van Zyl-5
In reply to this post by Stefan-2
There are no plans to remove it. Only the to try and make it more convenient if possible and make the error messages little more clear.

jvz

On 2011-10-23, at 5:37 PM, Stefan <[hidden email]> wrote:

> Hi guys,
>
> Currently, we're migrating our Archiva to Nexus and I happened to observe the builds used by different teams lately.
>> I fear there is no perfect solution. If e.g. 2 projects use the same repo-id and point to different URLs, then this would also cause inconsistency. But I think this problem is more theoretic than practically relevant.
> Turns out, that there are projects where people have declared our snapshots repository with id "internal" which is naturally assigned to the internal repo -  maybe because the credentials for both are the same. So here's an example from practice.
>
> And if I can advocate for keeping this feature - I like it a lot, because we have certain devs, who sometimes build projects locally and forget to deploy them, which results in broken builds. Also, this feature helped me convince the management, why to upgrade to maven 3.
>
> Cheers,
> Stefan
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven 3, _maven.repositories and *lastUpdated

Stefan-2
Yes, the log messages definitely need improvement - I've seen colleagues
with little maven experience getting really confused. Mark's proposal
looks fine.

As I recall someone mentioned that it would be nice to be able to turn
it off (in the spirit of making it more convenient) - to which I cannot
fully agree. I'm afraid once people find how to turn it off they'll be
tempted to just turn it off when they see the error.

Cheers,
Stefan

On 24.10.2011 г. 00:49 ч., Jason van Zyl wrote:

> There are no plans to remove it. Only the to try and make it more convenient if possible and make the error messages little more clear.
>
> jvz
>
> On 2011-10-23, at 5:37 PM, Stefan<[hidden email]>  wrote:
>
>> Hi guys,
>>
>> Currently, we're migrating our Archiva to Nexus and I happened to observe the builds used by different teams lately.
>>> I fear there is no perfect solution. If e.g. 2 projects use the same repo-id and point to different URLs, then this would also cause inconsistency. But I think this problem is more theoretic than practically relevant.
>> Turns out, that there are projects where people have declared our snapshots repository with id "internal" which is naturally assigned to the internal repo -  maybe because the credentials for both are the same. So here's an example from practice.
>>
>> And if I can advocate for keeping this feature - I like it a lot, because we have certain devs, who sometimes build projects locally and forget to deploy them, which results in broken builds. Also, this feature helped me convince the management, why to upgrade to maven 3.
>>
>> Cheers,
>> Stefan
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven 3, _maven.repositories and *lastUpdated

Mark Derricutt
In reply to this post by Jason van Zyl-5
This should probably move to the dev list, but if we're considering POM
changes in a future Maven version, should a <repository> element become
become part of the dependency declaration?

Altho if we're going that far I'd also like to see <repositories/> actually
be REMOVED from the pom, and moved to ~/.m2/settings.xml along side the
mirrors, with the <repository/> part of the GA(R)V being required -if- the
artifact is from a custom declared repository.  This would certainly speed
up a lot of builds that (#(*$#(* declare N-repositories in the pom causes
maven to walk thru each of them when trying to find something.

--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

On Mon, Oct 24, 2011 at 10:45 AM, Jason van Zyl <[hidden email]> wrote:

> I wasn't implying anything about the quality of Maven Central. It's
> orthogonal to this argument which is to say the GAV could only work as a
> unique identifier if there was one source, or all sources were identical.
> The quality of the contents is irrelevant.
>
> The quality of the content is a driving factor in creating variants which I
> think is your point.
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven 3, _maven.repositories and *lastUpdated

Jason van Zyl-5
In reply to this post by Stefan-2
Personally, I don't think I'd be in favor of ever turning it off.

jvz

On 2011-10-23, at 6:10 PM, Stefan <[hidden email]> wrote:

> Yes, the log messages definitely need improvement - I've seen colleagues with little maven experience getting really confused. Mark's proposal looks fine.
>
> As I recall someone mentioned that it would be nice to be able to turn it off (in the spirit of making it more convenient) - to which I cannot fully agree. I'm afraid once people find how to turn it off they'll be tempted to just turn it off when they see the error.
>
> Cheers,
> Stefan
>
> On 24.10.2011 г. 00:49 ч., Jason van Zyl wrote:
>> There are no plans to remove it. Only the to try and make it more convenient if possible and make the error messages little more clear.
>>
>> jvz
>>
>> On 2011-10-23, at 5:37 PM, Stefan<[hidden email]>  wrote:
>>
>>> Hi guys,
>>>
>>> Currently, we're migrating our Archiva to Nexus and I happened to observe the builds used by different teams lately.
>>>> I fear there is no perfect solution. If e.g. 2 projects use the same repo-id and point to different URLs, then this would also cause inconsistency. But I think this problem is more theoretic than practically relevant.
>>> Turns out, that there are projects where people have declared our snapshots repository with id "internal" which is naturally assigned to the internal repo -  maybe because the credentials for both are the same. So here's an example from practice.
>>>
>>> And if I can advocate for keeping this feature - I like it a lot, because we have certain devs, who sometimes build projects locally and forget to deploy them, which results in broken builds. Also, this feature helped me convince the management, why to upgrade to maven 3.
>>>
>>> Cheers,
>>> Stefan
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven 3, _maven.repositories and *lastUpdated

Mark Derricutt
In reply to this post by Mark Struberg
Raised as http://jira.codehaus.org/browse/MNG-5185

Mark

--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

On Mon, Oct 24, 2011 at 10:15 AM, Mark Struberg <[hidden email]> wrote:

> > If Maven said something like:  "The {GAV} artifact was found in your
> local
> Such kind of warning would make a lot of sense. Could you please file an
> issue? txs!