On Jun 15, 2014, at 11:01 AM, Hervé BOUTEMY wrote:
> Le dimanche 15 juin 2014 09:19:26 Jason van Zyl a écrit :
>> On Jun 14, 2014, at 3:09 PM, Hervé BOUTEMY wrote:
>>> Le samedi 14 juin 2014 13:33:37 Jason van Zyl a écrit :
> yes, but how is the constraint expressed and coded?
Tr
Le dimanche 15 juin 2014 09:19:26 Jason van Zyl a écrit :
> On Jun 14, 2014, at 3:09 PM, Hervé BOUTEMY wrote:
> > Le samedi 14 juin 2014 13:33:37 Jason van Zyl a écrit :
> >>> yes, but how is the constraint expressed and coded?
> >>
> >> Trying to encode these in such a way where you effectively
On Jun 14, 2014, at 3:09 PM, Hervé BOUTEMY wrote:
> Le samedi 14 juin 2014 13:33:37 Jason van Zyl a écrit :
>>> yes, but how is the constraint expressed and coded?
>>
>> Trying to encode these in such a way where you effectively have a property
>> graph is hard. Aether has some preliminary supp
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/21#issuecomment-46114965
No, we do not use install on this particular project where we are
developing the concept of a generation. We either have a project in source form
locally, or we get it remo
Github user talios commented on the pull request:
https://github.com/apache/maven/pull/21#issuecomment-46105389
wow - what the hell happened to the formatting here?
@jvanzyl said in one part "In the case of my current setup we simply
disallow SNAPSHOTs entirely." - I'd love to
Github user asfgit closed the pull request at:
https://github.com/apache/maven/pull/21
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enable
Le samedi 14 juin 2014 13:33:37 Jason van Zyl a écrit :
> > yes, but how is the constraint expressed and coded?
>
> Trying to encode these in such a way where you effectively have a property
> graph is hard. Aether has some preliminary support for this but not really.
> In practice to date it's re
On Jun 14, 2014, at 12:13 PM, Hervé BOUTEMY wrote:
> if my frenglish doesn't cause any unexpected result
All the explanations are appreciated. I don't have any problems understanding
you, but if you do want to be amused I can try and respond in French :-) I'm
sure your English is 100x better
All that said I think Christian's patch is in good addition, all the ITs are
passing and I'm going to integrate it. And then encourage him to give me more
non-trivial patches. I am looking into the automatically delivery of beer with
the closing of good pull requests. We are not above bribery he
On Jun 14, 2014, at 12:13 PM, Hervé BOUTEMY wrote:
> Le samedi 14 juin 2014 10:15:40 Jason van Zyl a écrit :
>> On Jun 14, 2014, at 2:39 AM, Hervé BOUTEMY wrote:
>>> this is one of the problems when using version ranges, tied to
>>> reproducibility and definition of the algorithm for Maven to c
Le samedi 14 juin 2014 10:15:40 Jason van Zyl a écrit :
> On Jun 14, 2014, at 2:39 AM, Hervé BOUTEMY wrote:
> > this is one of the problems when using version ranges, tied to
> > reproducibility and definition of the algorithm for Maven to choose one
> > version in the range adapted to the actual
On Jun 14, 2014, at 4:18 AM, Christian Schulte wrote:
> Am 06/14/14 08:39, schrieb Hervé BOUTEMY:
>> this is one of the problems when using version ranges, tied to
>> reproducibility
>> and definition of the algorithm for Maven to choose one version in the range
>> adapted to the actual conte
On Jun 14, 2014, at 2:39 AM, Hervé BOUTEMY wrote:
> this is one of the problems when using version ranges, tied to
> reproducibility
> and definition of the algorithm for Maven to choose one version in the range
> adapted to the actual context.
>
> This is sometimes incorrectly (IMHO) told a
Am 06/14/14 08:39, schrieb Hervé BOUTEMY:
> this is one of the problems when using version ranges, tied to
> reproducibility
> and definition of the algorithm for Maven to choose one version in the range
> adapted to the actual context.
It's not only about version ranges. It seems inconsistent
this is one of the problems when using version ranges, tied to reproducibility
and definition of the algorithm for Maven to choose one version in the range
adapted to the actual context.
This is sometimes incorrectly (IMHO) told as "maven ranges with non-SNAPSHOT
bounds should not contain SNAPS
Am 06/14/14 04:50, schrieb talios:
> Github user talios commented on the pull request:
>
> https://github.com/apache/maven/pull/21#issuecomment-46076519
>
> Interesting about the version range changes in aether there - whilst the
> [2.2.*] range is nice, that doesn't offer SNAPSHOT exc
Github user talios commented on the pull request:
https://github.com/apache/maven/pull/21#issuecomment-46076519
Interesting about the version range changes in aether there - whilst the
[2.2.*] range is nice, that doesn't offer SNAPSHOT exclusion - unless the
`VersionFilter` is being e
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/21#issuecomment-45980866
http://wiki.eclipse.org/Aether/New_and_Noteworthy#Version_Ranges
---
If your project is set up for it, you can reply to this email and have your
reply appear on Gi
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/21#issuecomment-45980581
From what I can tell, release:prepare-with-pom should work the same way as
before. What this patch basically does is to resolve any parent version range
and then c
Github user talios commented on the pull request:
https://github.com/apache/maven/pull/21#issuecomment-45975916
With regards to `release:prepare` I agree, but here I'm talking about
release:prepare-with-pom which generates a "resolved pom" in relation to
version ranges, in that instan
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/21#issuecomment-45974252
I have done several releases using 'release:prepare release:perform' with a
parent version range in use. The release plugin won't write the resolved parent
version
Github user talios commented on the pull request:
https://github.com/apache/maven/pull/21#issuecomment-45968040
How will this affect the maven-release-plugin's release:prepare-with-pom
goal? Will the parent version reference be automatically resolved and written
correctly, or will we
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/21#issuecomment-45966467
Most excellent, thank you. Do you think you might also try your hand at
creating an integration test and trying to assert the change doesn't break
anything else in Maven? Y
GitHub user ChristianSchulte opened a pull request:
https://github.com/apache/maven/pull/21
[MNG-2199] Version ranges not supported for parent artifacts
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ChristianSchulte/maven maste
24 matches
Mail list logo
