I definitely like that. At times (and many times) I want to blow away all
my local snapshots. Having a separate local repo for that would be a nice
separation.
Cheers,
Paul
On Sat, Jun 14, 2014 at 10:12 PM, Mark Derricutt wrote:
> Hey all,
>
> A recent discussion on one of the github PR's led
Hey all,
A recent discussion on one of the github PR's led to a discussion on
SNAPSHOT resolution, which is a long standing issue in maven range
support with several long standing open tickets lingering.
A thought I just had, which relates to some things I've been playing
with in my C.I. bui
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
Le samedi 14 juin 2014 13:51:21 Jason van Zyl a écrit :
> So my current plan is to roll in Christian's change, and then I'm going to
> roll the 3.2.2.
+1
>
> If anyone wants to work on anything else speak up. I'm in no rush but I have
> time this weekend so I'll roll the 3.2.2 if no one else is g
So my current plan is to roll in Christian's change, and then I'm going to roll
the 3.2.2.
If anyone wants to work on anything else speak up. I'm in no rush but I have
time this weekend so I'll roll the 3.2.2 if no one else is going to work on
anything.
My next project is to write a validator
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
this is arleady planned for maven-plugins 26 and done: just waiting for a
release now
:)
see https://issues.apache.org/jira/browse/MPOM-49
Regards,
Hervé
Le samedi 14 juin 2014 08:05:16 Benson Margulies a écrit :
> NVM: I solved this via cargo-cultism. However, why doesn't our parent
> pom con
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
NVM: I solved this via cargo-cultism. However, why doesn't our parent
pom configure the plugin-plugin 'correctly', instead of each plugin
messing with it?
On Sat, Jun 14, 2014 at 8:00 AM, Benson Margulies wrote:
> I'm helping out at the nar-maven-plugin. I'm trying to upgrade to
> annotations fo
I'm helping out at the nar-maven-plugin. I'm trying to upgrade to
annotations for configuration.
The plugin uses a familiar parent:
maven-plugins
org.apache.maven.plugins
25
and defers all configuration to the parent. The plugin-plugin finds no
mojos via annotation, even t
OK, I'll assume that the original author of the plugin I'm upgrading
was confused.
On Sat, Jun 14, 2014 at 2:33 AM, Hervé BOUTEMY wrote:
> @requiresSession?
> I can't find this annotation in plugin-tools's javadoc annotations
> documentation [1]
> And what part of plugin descriptor should it conf
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
18 matches
Mail list logo
