On 2009-10-30, at 4:39 PM, Benjamin Bentmann wrote:
Brian Fox wrote:
I think we have to also consider that 2) is what Maven does now.
(Benjamin thinks it might be 3 but I seem to recall repos added along
the way stick around forever)
I was trying to check what Maven 2.x actually does and ca
On 2009-10-30, at 3:13 PM, Brian Fox wrote:
I think 2) and 3) require a lot of discussion. So really I think it
boils
down to are we going to really make 1) the way it works? Otherwise
I think
we are also obliged to look at the models in P2 and OBR because it
probably
doesn't make sense t
It is going interesting to see lots/logs of warnings when we starting
using 3.0 :-)
-Dan
On Fri, Oct 30, 2009 at 4:12 PM, Paul Benedict wrote:
> I created MNG-4421 to track this issue:
> http://jira.codehaus.org/browse/MNG-4421
>
> Paul
>
> On Fri, Oct 30, 2009 at 5:15 PM, Brian Fox wrote:
>> Y
Brian Fox wrote:
I think we have to also consider that 2) is what Maven does now.
(Benjamin thinks it might be 3 but I seem to recall repos added along
the way stick around forever)
I was trying to check what Maven 2.x actually does and came up with this
POM snippet:
org.sonat
I created MNG-4421 to track this issue:
http://jira.codehaus.org/browse/MNG-4421
Paul
On Fri, Oct 30, 2009 at 5:15 PM, Brian Fox wrote:
> Yeah deprecated in 3.x. However we'll always have to support them when
> resolving things from the repo since that's cast in stone for projects
> already rele
Yeah deprecated in 3.x. However we'll always have to support them when
resolving things from the repo since that's cast in stone for projects
already released. We should not support them for projects being built
with 3.x though.
On Fri, Oct 30, 2009 at 1:34 PM, Paul Benedict wrote:
> Yes, I agree
> I think 2) and 3) require a lot of discussion. So really I think it boils
> down to are we going to really make 1) the way it works? Otherwise I think
> we are also obliged to look at the models in P2 and OBR because it probably
> doesn't make sense to re-invent another mediation and reconciliati
Yes, I agree. Providing warnings is a simple incentive to push people
away from their use.
Paul
On Fri, Oct 30, 2009 at 12:31 PM, Paul MERLIN wrote:
> Le vendredi 30 octobre 2009 18:21:22, Jason van Zyl a écrit :
>> On 2009-10-30, at 10:17 AM, Paul Benedict wrote:
>> > I was reading the Introduc
Le vendredi 30 octobre 2009 18:21:22, Jason van Zyl a écrit :
> On 2009-10-30, at 10:17 AM, Paul Benedict wrote:
> > I was reading the Introduction to the POM page. It says:
> >>> These variables are all referenced by the prefix "project.".
> >>> You may also see references with pom. as the prefix,
On 2009-10-30, at 10:17 AM, Paul Benedict wrote:
I was reading the Introduction to the POM page. It says:
These variables are all referenced by the prefix "project.".
You may also see references with pom. as the prefix, or the
prefix omitted entirely - these forms are now deprecated and
shoul
I was reading the Introduction to the POM page. It says:
>> These variables are all referenced by the prefix "project.".
>> You may also see references with pom. as the prefix, or the
>> prefix omitted entirely - these forms are now deprecated and
>> should not be used.
Will these old-style uses
There are three primary variants of how the artifact resolution can
work with respect to repositories where RS is the set of remote
repositories that will be used for artifact resolution:
1) RS is what's available in the effective POM. Easy.
2) RS is collect from inspecting metadata transitiv
Txs Benjamin!
I don't think it is that different, because my real problem is that I cannot
distinguish between those artifacts because of that.
So the problem of _retrieving_ those artifacts (and detecting problems within
them) maybe can be solved by storing them in a different way?
In other w
Yes, these things tend to degrade. Please stay on topic.
This can be another discussion but I separated and layered the local
repository implementation some time ago to allow for:
1) snapshot only local repositories
2) per project local repositories
And there are still fundamental issues wit
It's a great new. Thanks Dennis for the initiative.
> 2. Which issues do we include?
>
> Here's a list of the issues currently scheduled for the above releases:
>
> http://jira.codehaus.org/browse/MSHARED-102
> http://jira.codehaus.org/browse/DOXIA-354
> http://jira.codehaus.org/browse/DOXIA-355
>
Hi,
I have a multimodule project and it fails during release:perform with new
javadoc plugin.
I'm working on a simple project to open an issue, but let me explain the issue
in case someone can tell me if there is something wrong in my configuration.
Say my project is composed of:
Parent
- m
If I understand your comments om MSHARED-120 correctly, the Changes
Plugin should not be affected by this, because the previous 2.1 version
of the plugin uses Doxia 1.0-alpha-11.
Vincent Siveton wrote:
> Hi Dennis,
>
> For the changes plugin, we probably need to release before
> maven-reporting-i
In general I think this could be handy, but I'm mostly thinking from
the angle of separating things needed BY the build from things needed
FOR the build. Ie separating Maven and plugin dependencies from the
project being built's dependencies. Specifically to handle things like
blocking GPL artifact
Everybody can vote, and you are encouraged to do so if you have tested the
release. Even though officially only PMC votes count to determine the result,
every other vote is appreciated as additional feedback. See
http://www.apache.org/foundation/voting.html.
Cheers,
-Lukas
Tony Chemit wrot
Mark Struberg wrote:
But in my local repo, all the artifacts from those repositories gets merged to
a single big landfill.
That seems to be a completely independent issue, isn't it? The question
I originally raised was about what repositories ought to be considered
during dependency resolut
Le Tue, 13 Oct 2009 10:09:34 -0400,
John Casey a écrit :
Hi guys,
I'd like to know if I can vote with you ? or is it reserved to people with
credentials on svn ?
> +1
>
> Arnaud HERITIER wrote:
> > Hi,
> >
> > We solved 2 issues:
> > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId
+1
Arnaud
On Fri, Oct 30, 2009 at 12:29 AM, Olivier Lamy wrote:
> +1
>
> --
> Olivier
>
> 2009/10/30 Benjamin Bentmann :
> > Hi,
> >
> > if some of you have a déjà vu while regarding the mail title, that's
> fine...
> > my previous attempt at making our release processes smoother failed due
> t
Reading the original proposal again, I've an idea:
The structure of the local repository should become:
>
> ~/.m2/repository
> |-- cache
> |-- remote
> | |-- apache.snapshots
> | |-- central
> | |-- codehaus.snapshots
> | `-- ...
> `-- workspace
> |-- default
> |-- workspace1
> `-- ...
>
> The
Thanks Stephen!
Wasn't aware that Brett had the same idea a long time ago.
Found it now:
http://markmail.org/thread/wqi43wiwbj43vwq6
It would be a good amount of work, but since this seems to pop up regulary, we
may think about it for m3.
LieGrue,
strub
- Ursprüngliche Mail
> Von:
This was a proposal about a year or two back IIRC there were other
more pressing issues and nothing much happened since.
The proposal was part of the "make repository access thread-safe" for
people using maven on CI systems, or running builds in parallel from
the CLI
-Stephen
2009/10/30 Mark
Hi!
Just make a step back and look at the repository problematic from a bit
different perspective.
I'm working for a few companies and even different projects in those companies
use different sections in their poms.
But in my local repo, all the artifacts from those repositories gets merged to
Thanks Dennis for the initiative. Unfortunately it comes at a bad time for me, I'm
afraid I won't be able to help much in the next weeks (new job, new country, new
home...) but I fully endorse your plan of action. See my comments below.
Dennis Lundberg wrote:
Hi all
I think it's about time
27 matches
Mail list logo
