+1
tested with Maven core and ITs
Regards,
Hervé
Le jeudi 12 septembre 2013 13:29:32 Tamás Cservenák a écrit :
> Hi,
>
> We solved 6 issues:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10335&version=19
> 092
>
> There are still a couple of issues left in JIRA:
> https://jira
> Date: Sun, 15 Sep 2013 00:50:17 +0200
> Subject: Lost in space with Subversion...
> From: denn...@apache.org
> To: dev@maven.apache.org
>
> Hi,
>
> When working on improving our license header compliance I ran into a
> problem I've not encountered before: spaces in the path of a directory
Github user cstamas closed the pull request at:
https://github.com/apache/maven/pull/9
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Tamas,
Can you try master now. Do you have a plugin that you are testing that I can
try? I assume that you are using Aether directly and saw an issue? The old and
the new artifacts need to be filtered to prevent NoClassDefFound errors. I will
make a sample plugin using Aether directly, can you
Thanks, running the ITs and there are failures so I'm taking a look now.
On Sep 11, 2013, at 7:41 AM, Tamás Cservenák wrote:
> Hi,
>
> it seems in 3.1.x, since Aether was swapped from Sonatype one to Eclipse
> one, the filtering was not updated, and Eclipse Aether is getting into
> plugin Class
Last time someone asked this I went straight to central and found two
examples. There are plenty out there. I'm not doing it again, you're more
than capable. Also note, it's not much different to go from 3.1.2 to 3.1.4
than it is from 3.1.5 to 3.2.0; you still miss out versions, an infinite
number
The users may well be developers, but I don't think that warrants changing a
normal pattern. Maybe only I consider this a normal pattern, but I don't know
of any examples, personally, where externally represented versions have gaps in
them. I'd ask you the same question I asked Stephen as to whe
Jason, PLEASE understand that you do NOT have a single user. Not even one.
Nada. Zilch. You have developers. Developers, by definition, are not
*completely* stupid (though some try to fool us!). They can handle missing
versions. If you released firefox 12 after firefox 10 it would be confusing
for
On Sep 14, 2013, at 7:34 PM, Stephen Connolly
wrote:
> The difference is that you say those versions did not pass QA.
>
I don't think that will alleviate the confusion, and trying to explain that
will unlikely reach our audience and they will just be confused.
> As a user I'd rather know tha
The difference is that you say those versions did not pass QA.
As a user I'd rather know that what I have *unabiguously* passed QA
(whatever that QA process is, and however lax it is) than know the
increasing version numbers. On top of that, if we go increasing, with no
skips, we are actually givi
As I suspected the ITs don't like it. So 3.1-SNAPSHOT it is.
On Sep 14, 2013, at 5:08 PM, Hervé BOUTEMY wrote:
> I prefer this 3.1.x-SNAPSHOT value: the intent is more clear
>
> Regards,
>
> Hervé
>
> Le samedi 14 septembre 2013 19:42:23 Arnaud Héritier a écrit :
>> No problem for me. At work
I don't agree. I think this would be massively confusing to people if a version
was missing, or several failed and you went from 3.1.0 to 3.1.3. I don't think
that would make much sense to most users.
On Sep 14, 2013, at 5:49 PM, Stephen Connolly
wrote:
> On Saturday, 14 September 2013, Denni
Hi,
When working on improving our license header compliance I ran into a
problem I've not encountered before: spaces in the path of a directory
that is checked into Subversion.
I am unable to update files that reside inside a directory that has
spaces in it. I've tried from Windows and Ubuntu usi
Let me try the ITs quickly and make sure it actually works. If so, I agree with
you.
On Sep 14, 2013, at 5:08 PM, Hervé BOUTEMY wrote:
> I prefer this 3.1.x-SNAPSHOT value: the intent is more clear
>
> Regards,
>
> Hervé
>
> Le samedi 14 septembre 2013 19:42:23 Arnaud Héritier a écrit :
>> N
On Sep 14, 2013, at 4:00 PM, Daniel Kulp wrote:
>
>
> On Sep 14, 2013, at 1:24 PM, Jason van Zyl wrote:
>
>> When a release fails like this it is annoying to have to rev back the
>> version of the POM. I'm not sure who flipped the versions in the POM and
>> while it's a little more visible
On Saturday, 14 September 2013, Dennis Lundberg wrote:
> JIRA is not a big problem. Say for example that the 3.1.1 release was
> abandoned due to some problem, you would simply rename the version in
> JIRA from 3.1.1 to 3.1.2.
Exactly.
Not a problem if you ask me... The only one I can think of
FFS, Mark. You know better than to argue with me about Git, don't you? :-p
Label in a file system = hard link. Garbage collection (space available) =
no hard links to inodes. Cut the shit man :-p
Nit picking is a BIG understatement :-p
Fred.
On Sat, Sep 14, 2013 at 11:12 PM, Dennis Lundberg wr
JIRA is not a big problem. Say for example that the 3.1.1 release was
abandoned due to some problem, you would simply rename the version in
JIRA from 3.1.1 to 3.1.2.
On Sat, Sep 14, 2013 at 10:34 PM, Mark Struberg wrote:
> I think it's mainly because the maintenance and housekeeping costs on the
I prefer this 3.1.x-SNAPSHOT value: the intent is more clear
Regards,
Hervé
Le samedi 14 septembre 2013 19:42:23 Arnaud Héritier a écrit :
> No problem for me. At work I'm also applying this rule but we use
> 3.1.x-SNAPSHOT. I didn't notice issues with this
>
> Cheers.
>
> -
> Arnaud
>
I think it's mainly because the maintenance and housekeeping costs on the JIRA
front and others which use the version nr as reference.
Imagine that you would need to move all the JIRA tickets which got marked as
fixed in a certain release as well. Otherwise the release notes would be broken
-
No, a tag and a branch is not only just a label.
GIT internally has a kind of garbage collection. And once some commits are not
referenced by another tree they are subject to be dropped from the repo on a
re-pack which might happen on git-prune or git-gc. But that's nit picking.
The real pr
On Sep 14, 2013, at 1:24 PM, Jason van Zyl wrote:
> When a release fails like this it is annoying to have to rev back the version
> of the POM. I'm not sure who flipped the versions in the POM and while it's a
> little more visible to see what you're moving toward I prefer the pattern of:
>
I agree on skipping failed versions! I was avoiding the topic because it
seemed popular opinion was to re-spin endlessly like a child's spinning top.
On Sat, Sep 14, 2013 at 9:47 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Why as long as you don't push the tag, there's no bi
Why as long as you don't push the tag, there's no big deal. Pushing the tag
is when problems appear... In any case I'd prefer to just skip failed
version numbers... Though I was voted down last time that came up, and
given I'm not running too many releases at the moment, I don't see my
opinion as b
I believe the strict policy only applies to master branch. The entire
concept is different anyway, it's just a label. Leave it there, it costs
nothing except name space. The persistent try-1 try-2 etc tags will also
get mirrored into perpetuity anyway. Master should likely be left alone
during a re
The question is not whether you do this on a branch or not, but only where to
push this branch to and where people do the validation for the VOTE.
GIT repos at the ASF have a strict history-rewrite policy and don't allow to
ditch stuff. I'm not 100% sure myself if this is also for deleting upst
In DeltaSpike I always push the release branch + tag to my personal github
repo. After the VOTE did succeed I push the exact sha1 upstream to the ASF repo.
This is not perfect but it's good enough imo as the parent commit is verifiable
coming from the ASF upstream repo.
Plus people can check tha
Branches.
On Sat, Sep 14, 2013 at 8:47 PM, Jason van Zyl wrote:
> We need a slight modification of this strategy because the changes need to
> be pushed somewhere so that people can examine the tag if they want during
> the release. I can't keep it on my machine until the vote passes.
>
> On Se
We need a slight modification of this strategy because the changes need to be
pushed somewhere so that people can examine the tag if they want during the
release. I can't keep it on my machine until the vote passes.
On Sep 14, 2013, at 2:20 PM, Mark Struberg wrote:
> +1, that's what we also us
Interesting usecase for http://jira.codehaus.org/browse/MRELEASE-431
So even though 3.1-SNAPSHOT is before 3.1.1 I can imagine why this
practice would work.
btw, for the m-release-p there's no need to change the version back to
3.1.1-SNAPSHOT before a re-release of 3.1.1
Robert
Op Sat, 14
+1, that's what we also use in DeltaSpike and dozen other projects.
pushChanges=false + localCheckout=true for the win!
LieGrue,
strub
- Original Message -
> From: Arnaud Héritier
> To: Maven Developers List
> Cc:
> Sent: Saturday, 14 September 2013, 19:45
> Subject: Re: Leaving Ma
We can certainly move in that direction, nothing is currently setup for this.
On Sep 14, 2013, at 1:29 PM, Fred Cooke wrote:
> You're in Git now. You don't *have* to push your tag and release commits up
> to the public world until AFTER you've checked they're OK. Or by failed
> release do you me
Good practice too. I'm using it also at work and we are doing our
releases on dedicated branches.
-
Arnaud
Le 14 sept. 2013 à 19:30, Fred Cooke a écrit :
> You're in Git now. You don't *have* to push your tag and release commits up
> to the public world until AFTER you've checked they'r
No problem for me. At work I'm also applying this rule but we use
3.1.x-SNAPSHOT. I didn't notice issues with this
Cheers.
-
Arnaud
Le 14 sept. 2013 à 19:25, Jason van Zyl a écrit :
> When a release fails like this it is annoying to have to rev back the version
> of the POM. I'm not s
You're in Git now. You don't *have* to push your tag and release commits up
to the public world until AFTER you've checked they're OK. Or by failed
release do you mean voted down? They could live on branches until set in
stone, then merge --ff-only into master at that point, if so.
On Sat, Sep 14
When a release fails like this it is annoying to have to rev back the version
of the POM. I'm not sure who flipped the versions in the POM and while it's a
little more visible to see what you're moving toward I prefer the pattern of:
3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAP
On 14 September 2013 11:19, Baptiste Mathus wrote:
> Le 13 sept. 2013 19:00, "sebb" a écrit :
>>
>> On 12 September 2013 21:52, Baptiste Mathus wrote:
>> > 2013/9/12 sebb
>> >
>> >> On 12 September 2013 14:52, Arnaud Héritier
> wrote:
>> >> > On Thu, Sep 12, 2013 at 3:44 PM, sebb wrote:
>> >>
+1 (binding)
Robert
Op Thu, 12 Sep 2013 13:29:32 +0200 schreef Tamás Cservenák
:
Hi,
We solved 6 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10335&version=19092
There are still a couple of issues left in JIRA:
https://jira.codehaus.org/issues/?jql=project%20%3D%20
Le 13 sept. 2013 19:00, "sebb" a écrit :
>
> On 12 September 2013 21:52, Baptiste Mathus wrote:
> > 2013/9/12 sebb
> >
> >> On 12 September 2013 14:52, Arnaud Héritier
wrote:
> >> > On Thu, Sep 12, 2013 at 3:44 PM, sebb wrote:
> >> >
> >> >> On 10 September 2013 16:33, Daniel Kulp wrote:
> >>
39 matches
Mail list logo
