Op Tue, 27 Aug 2013 20:34:07 +0200 schreef Stephen Connolly
:
On Tuesday, 27 August 2013, Robert Scholte wrote:
Op Tue, 27 Aug 2013 10:59:08 +0200 schreef Stephen Connolly <
stephen.alan.conno...@gmail.com>:
On 27 August 2013 09:46, Stephen Connolly
wrote:
On 27 August 2013 09:00, Jörg
On Tuesday, 27 August 2013, Robert Scholte wrote:
> Op Tue, 27 Aug 2013 10:59:08 +0200 schreef Stephen Connolly <
> stephen.alan.conno...@gmail.com>:
>
> On 27 August 2013 09:46, Stephen Connolly
>> wrote:
>>
>> On 27 August 2013 09:00, Jörg Schaible >> >wrote:
>>>
>>> > And since this would be
Op Tue, 27 Aug 2013 10:59:08 +0200 schreef Stephen Connolly
:
On 27 August 2013 09:46, Stephen Connolly
wrote:
On 27 August 2013 09:00, Jörg Schaible
wrote:
> And since this would be for a new Maven, we need only concern
ourselves
> that the contract of the new Maven's classpath and pro
Hi Stephen,
Stephen Connolly wrote:
> On 27 August 2013 10:55, Jörg Schaible
> wrote:
>
>> Hi Stephen,
>>
>> In consequence this will also implicitly drop (transitive) dependency
>> manipulations with profiles.
>>
>>
> Yes, a "good thing" in my opinion ;-)
Definitely, although I'd love to adju
On 27 August 2013 10:55, Jörg Schaible wrote:
> Hi Stephen,
>
> In consequence this will also implicitly drop (transitive) dependency
> manipulations with profiles.
>
>
Yes, a "good thing" in my opinion ;-)
> However, all makes sense now to me - thanks for explaining.
>
Just my vision... I don
Hi Stephen,
Stephen Connolly wrote:
> On 27 August 2013 09:46, Stephen Connolly
> wrote:
>
>> On 27 August 2013 09:00, Jörg Schaible
>> wrote:
>>
>>> > And since this would be for a new Maven, we need only concern
>>> > ourselves that the contract of the new Maven's classpath and property
>>> >
On 27 August 2013 09:46, Stephen Connolly
wrote:
> On 27 August 2013 09:00, Jörg Schaible wrote:
>
>> > And since this would be for a new Maven, we need only concern ourselves
>> > that the contract of the new Maven's classpath and property behaviour is
>> > correct... thus we don't have to preser
On 27 August 2013 09:00, Jörg Schaible wrote:
> Hi Stephen,
>
> Stephen Connolly wrote:
>
> > On 26 August 2013 08:27, Jörg Schaible
> > wrote:
> >
> >> Hi Stephen,
> >>
> >> Stephen Connolly wrote:
> >>
> >> [snip]
> >>
> >> > It's better than that... I am not sure if I said it earlier or not,
Hi Stephen,
Stephen Connolly wrote:
> On 26 August 2013 08:27, Jörg Schaible
> wrote:
>
>> Hi Stephen,
>>
>> Stephen Connolly wrote:
>>
>> [snip]
>>
>> > It's better than that... I am not sure if I said it earlier or not, so
>> > I will try to say it now.
>> >
>> > When we get the next format,
On 26 August 2013 09:06, Arnaud Héritier wrote:
> I think it doesn't work if you have several level of inheritance in
> different projects and you don't republish all intermediate artifacts
> Let's imagine you have projectA <-- inherit <-- projectB <-- inherit <--
> projectC
> If all of them are
I think it doesn't work if you have several level of inheritance in
different projects and you don't republish all intermediate artifacts
Let's imagine you have projectA <-- inherit <-- projectB <-- inherit <--
projectC
If all of them are in SNAPSHOT for now if you change projectA and republish
it,
On 26 August 2013 08:27, Jörg Schaible wrote:
> Hi Stephen,
>
> Stephen Connolly wrote:
>
> [snip]
>
> > It's better than that... I am not sure if I said it earlier or not, so I
> > will try to say it now.
> >
> > When we get the next format, there are probably actually three files we
> > want to
Hi Stephen,
Stephen Connolly wrote:
[snip]
> It's better than that... I am not sure if I said it earlier or not, so I
> will try to say it now.
>
> When we get the next format, there are probably actually three files we
> want to deploy:
>
> foo-1.0.pom (the legacy 4.0.0 model)
> foo-1.0-build
On Fri, Aug 23, 2013 at 4:11 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> If you make the strategy a component provided by sisu, then a build
> extension could provide an alternative implementation for the project that
> the extension is defined in.
>
Interesting. So that wou
If you make the strategy a component provided by sisu, then a build
extension could provide an alternative implementation for the project that
the extension is defined in.
I presume the strategy is something you only want to apply to a project's
handling of its dependencies. If another project con
On Fri, Aug 23, 2013 at 1:25 PM, Baptiste Mathus wrote:
> Well, you might still be able to put put that kind of configuration inside
> or inside some plugin configuration block?
>
Hmm, yeah I suppose I could sneak it in like that, but it wouldn't be
pretty... A patch wouldn't be accepted in th
Well, you might still be able to put put that kind of configuration inside
or inside some plugin configuration block?
Le 23 août 2013 21:14, "Phillip Hellewell" a écrit :
> Wow, I had no idea about this whole issue with being unable to move forward
> with the POM. This is a really tough problem
XML allows different namespaces to be used together. Theoretically, you
should be able to introduce your own elements into the POM under another
namespace. The problem, however, will be the validation of the schema. I
bet the POM validator doesn't ignore elements from other namespaces. If it
did, i
Wow, I had no idea about this whole issue with being unable to move forward
with the POM. This is a really tough problem. I just didn't even think
about that because I'm used to working with XML parsers that don't even do
schema validation.
So I guess I'm pretty much stuck, because I can't put m
I haven't seen this proposal before, I can't find anything about it on our
wiki[1]
Benson started a page[2] in the past, but that doesn't cover it all.
Would be nice to collect these kind of info
Robert
[1]
https://cwiki.apache.org/confluence/pages/listpages-alphaview.action?key=MAVEN
[2]
On 23 August 2013 15:57, Robert Scholte wrote:
> I fully agree with Stephen, and it made me realize something:
>
> The pom is all about build instructions. *When* (let's say 'when' instead
> of 'if' ;) ) there's a newer pom model, it requires at least a newer
> version of Maven (4+) to build that
I fully agree with Stephen, and it made me realize something:
The pom is all about build instructions. *When* (let's say 'when' instead
of 'if' ;) ) there's a newer pom model, it requires at least a newer
version of Maven (4+) to build that project.
However, if the project is deployed to a re
On 23 August 2013 05:30, Mark Derricutt wrote:
> On 23/08/2013, at 3:50 PM, Domi wrote:
>
> Should maven not have a Concept to support multiple schema versions?
>
>
> In theory it does, by way of the DTD declaration, you can specify which
> DTD you're currently using, but support for that POM ve
On 23/08/2013, at 3:50 PM, Domi wrote:
> Should maven not have a Concept to support multiple schema versions?
In theory it does, by way of the DTD declaration, you can specify which DTD
you're currently using, but support for that POM version would mandate a
minimum version of Maven for the bu
Should maven not have a Concept to support multiple schema versions?
Am 23.08.2013 um 05:08 schrieb Mark Derricutt :
> On 23/08/2013, at 2:52 PM, Phillip Hellewell wrote:
>
>> On Thu, Aug 22, 2013 at 10:16 AM, Stephen Connolly
>> wrote:
>>> Beware the changing of the pom schema is a thorn
On 23/08/2013, at 2:52 PM, Phillip Hellewell wrote:
> On Thu, Aug 22, 2013 at 10:16 AM, Stephen Connolly
> wrote:
>> Beware the changing of the pom schema is a thorny subject... at present
>> we are still stuck trying to decide how to evolve to the next schema
>> (whatever that is) without b
On Thu, Aug 22, 2013 at 10:16 AM, Stephen Connolly
wrote:
> Beware the changing of the pom schema is a thorny subject... at present
> we are still stuck trying to decide how to evolve to the next schema
> (whatever that is) without breaking *everything*
How does the addition of a new optional
Beware the changing of the pom schema is a thorny subject... at present
we are still stuck trying to decide how to evolve to the next schema
(whatever that is) without breaking *everything*
On 22 August 2013 16:54, Phillip Hellewell wrote:
> On Wed, Aug 21, 2013 at 8:21 PM, Mark Derricutt
On Wed, Aug 21, 2013 at 8:21 PM, Mark Derricutt wrote:
> On 22/08/2013, at 4:37 AM, Phillip Hellewell wrote:
>
>> My idea to solve this was to add support for a
>> true in the declaration. Thoughts?
>
> I didn't think we could change the POM schema? Not without some epic major
> reasoning ( an
On Wed, Aug 21, 2013 at 11:34 AM, Hervé BOUTEMY wrote:
> IIUC Baptiste point, the question is not about exceptionally forcing to the
> old release when 2 versions are "in conflict", but to choose the newer one of
> the two proposed versions vs using the newest in the repository (= the latest)
> be
On Wed, Aug 21, 2013 at 11:28 AM, Robert Scholte wrote:
> The problem with newest is that it can *never* be overridden by the active
> project, for whatever reason.
> Instead of newest I'd prefer to use the RequireUpperBoundDependencies
> Enforcer Rule[1] which give you the same result (otherwise
On 22/08/2013, at 4:37 AM, Phillip Hellewell wrote:
> My idea to solve this was to add support for a
> true in the declaration. Thoughts?
I didn't think we could change the POM schema? Not without some epic major
reasoning ( and if we were to change it, there's plenty of things change… )
Mar
Le mercredi 21 août 2013 19:28:03 Robert Scholte a écrit :
> The problem with newest is that it can *never* be overridden by the active
> project, for whatever reason.
> Instead of newest I'd prefer to use the RequireUpperBoundDependencies
> Enforcer Rule[1] which give you the same result (otherwis
Le mercredi 21 août 2013 10:37:40 Phillip Hellewell a écrit :
> On Wed, Aug 21, 2013 at 3:19 AM, Baptiste Mathus wrote:
> > Wondering: is this strategy still gonna choose the newest version
> > specified
> > even if I specify a version inside my pom? Or is it only gonna be used
> > between depende
The problem with newest is that it can *never* be overridden by the active
project, for whatever reason.
Instead of newest I'd prefer to use the RequireUpperBoundDependencies
Enforcer Rule[1] which give you the same result (otherwise the build will
fail).
Robert
[1]
http://maven.apache.o
On Wed, Aug 21, 2013 at 3:19 AM, Baptiste Mathus wrote:
> Wondering: is this strategy still gonna choose the newest version specified
> even if I specify a version inside my pom? Or is it only gonna be used
> between dependencies?
The behavior we actually need and want most of the time is for it
Wondering: is this strategy still gonna choose the newest version specified
even if I specify a version inside my pom? Or is it only gonna be used
between dependencies?
If the latter, I may agree it can be of interest.
But with the first I guess it would get crazy not being able to force the
versi
On Tue, Aug 20, 2013 at 3:15 PM, Jörg Schaible wrote:
>
> Can you also tell, why you really want to do this? If you really want
> "predictability", then use a shared parent, declare all involved
> dependencies there in a dependencyManagement section and declare your direct
> dependencies without a
Hi Phillip,
Phillip Hellewell wrote:
> Hi all,
>
> I'd like to take a stab at adding support for Maven to be able to mediate
> dependency conflicts using "highest version" strategy rather than "nearest
> definition".
>
> I'll be happy if anyone can point me in the right direction on which
> sou
On Tue, Aug 20, 2013 at 9:36 AM, Phillip Hellewell wrote:
> I believe the behavior needs to be defined in the parent
> pom, e.g., in a new tag called or something
> (help me think of a good name).
Besides "nearest" and "newest", we'll want a "fail" strategy, which
means fail the build on version
Thanks everyone for you help so far.
So would the crux of this be to create a VersionSelector class called
NewestVersionSelector, and then find the code where it is currently
hard-coded to use NearestVersionSelector and make it possible to use this
one instead?
Yeah, I'm also very concerned about
Aether is incredibly flexible and can pretty much do anything. The class that
Olivier pointed you at is the where the Maven rules are encapsulated. The issue
is interoperability in the behaviour of a new Maven that may do something
different and versions of Maven that don't. Selecting the neares
ver.java
>
>
>
> -Ursprüngliche Nachricht-
> Von: Phillip Hellewell [mailto:ssh...@gmail.com]
> Gesendet: Montag, 19. August 2013 20:12
> An: dev@maven.apache.org
> Betreff: Adding support for new dependency mediation strategy
>
> Hi all,
>
> I'd like to
-
Von: Phillip Hellewell [mailto:ssh...@gmail.com]
Gesendet: Montag, 19. August 2013 20:12
An: dev@maven.apache.org
Betreff: Adding support for new dependency mediation strategy
Hi all,
I'd like to take a stab at adding support for Maven to be able to mediate
dependency conflicts using &qu
Hi all,
I'd like to take a stab at adding support for Maven to be able to mediate
dependency conflicts using "highest version" strategy rather than "nearest
definition".
I'll be happy if anyone can point me in the right direction on which source
files I'll need to modify, and any other guidance.
45 matches
Mail list logo
