from:"Fred Cooke"

Re: [VOTE] All new (non-patch) releases of Maven Core after 30th Sep 2013 to require Java 6+

2013-07-23 Thread Fred Cooke

+1, unsure if you could have muddied the essentially simple question
much more, but OK. :-p

On Tue, Jul 23, 2013 at 4:00 PM, Stephen Connolly
 wrote:
> +1 (binding)
>
>
> On 23 July 2013 14:59, Stephen Connolly 
> wrote:
>
>> This vote is to cover the minimum required version of Java for Maven Core.
>>
>> Maven Plugins produced by the Apache Maven Project that are flagged as
>> compatible with older versions of Maven Core as their baseline will still
>> require to stick to the minimum Java requirements of that Maven Core
>> version. In other words, if for example maven-compiler-plugin advertises
>> compatibility with Maven Core 2.0.11+ then that will still need to be
>> compiled targeting Java 1.4 and only using dependencies that are aligned
>> with that runtime requirement.
>>
>> Additionally patch releases to existing releases of Maven Core will not be
>> subject to this requirement.
>>
>> For example [example]*if* this vote passes and *if* on Sep 29th we release
>> Maven 3.2.0 and *if* on Oct 2nd we release Maven 2.0.12, Maven 2.2.2, Maven
>> 3.0.6, Maven 3.1.1, Maven 3.2.1 and Maven 3.3.0 (due to say some security
>> issue that affected all versions of Maven) then only Maven 3.3.0 would be
>> require Java 6 as a minimum runtime requirement, the 2.0.12 release would
>> still require Java 1.4 and the 2.2.2, 3.0.6, 3.1.1 and 3.2.1 versions would
>> all still require Java 1.5.[/example]
>>
>> This is not a requirement that 3rd party plugins need use Java 6 as a
>> minimum. Third party plugins are free to require any Java version >= the
>> corresponding Maven minimum requirement, though obviously from a users
>> perspective it is best if plugins try to adhere to our contracts for
>> corresponding versions of Maven Core.
>>
>> Justification for the cut-off date:
>>
>> * Oracle has gone end of life on Java 6 Feb 2013 (note that there is still
>> extended and sustaining support for existing Oracle customers using Java 5)
>> * IBM will go end of life for z/OS on 30th Sep 2013 (other platforms are
>> still with support, but there are other Java vendors for other platforms)
>> * Apple no longer supports any hardware that does not have at least an
>> Apple Java 6 version available.
>> * Red Hat is providing support for OpenJDK 6
>> * HP-UX, OpenVMS, and Tru64 all have a Java 6 implementation available.
>>
>> As I see it, that essentially ensures that for the vast majority of
>> platforms there is a very strong likelihood of a Java 6 compatible version
>> of Java available for that platform. Toolchains support or forking of the
>> compiler and surefire can provide support for users who still need to build
>> with older versions of Java (e.g., as was the case for Java 1.4.2 with
>> Maven 2.2.1). Additionally users who are forced to use a java version older
>> than Java 6 also are likely unable to upgrade their version of Maven, so
>> this change will not affect them
>>
>> This vote is open for 72 hours. A minimum of three +1 binding votes (i.e.
>> from the PMC) and the majority of votes cast from committers will be
>> required to pass this vote.
>>
>> +1000: Yes, and when can we have the vote to go for Java 7 as a minimum?
>> (This option is equivalent to +1 but provides people the ability to
>> indicate an additional preference while not contributing to the inevitible
>> noise)
>> +1: Yes
>> 0: No opinion
>> -1: No
>>
>> -Stephen
>>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] All new (non-patch) releases of Maven Core after 30th Sep 2013 to require Java 6+

2013-07-23 Thread Fred Cooke

BIG +1 for 6, and small -1 for 7 for my own selfish reasons. The old
versions will always be available, and are forkable for anyone that needs a
fix, hence small -1 and not crying and moaning.

On Tue, Jul 23, 2013 at 4:51 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On 23 July 2013 15:29, Lennart Jörelid  wrote:
>
> > +1000   which is a rather odd number for a vote; blame Stephen
> instead
> > of me.   :)
> >
> > I think we can skip the 1.6 release of the JDK as a Maven basis; JDK 1.6
> is
> > at or near EOL and the step from one
> > minimum JDK version to another (i.e. JDK 1.7) would be just as painful as
> > the step to JDK 1.6 - but with added
> > longevity, feature set and power.
> >
> >
> I am not against holding a vote for Java 1.7 *after* we have got up to Java
> 1.6. OpenJDK6 is an open source implementation of Java 6 that essentially
> means that it is possible to fix issues with Java 6 going forward. It is
> not possible to do that with Java 5 as there is no open source release.
>
> Let's get the baseline moved... the Jenkins project recently moved to Java
> 1.6 as the minimum runtime requirement (while keeping animal-sniffer so
> that only Java 1.5 APIs are permitted in Jenkins core... in case there is a
> backlash)... hopefully if we set a date, other projects will line up on
> that date (I know Kohsuke would be keen to see Jenkins drop the Java 1.5
> API requirements on Jenkins and IBM EOLing JDK 5 for z/OS seems like a fine
> justification to cull JDK 5)
>
> -Stephen
>

Re: Passing information between goals

2013-07-24 Thread Fred Cooke

Just remove the and from the end of it...

On Wed, Jul 24, 2013 at 3:30 PM, Martin Gainty  wrote:

>
> can anyone reach the URL?
>
> Baptiste is it possible to repost comments for build-helper to pastebin?
>
> http://pastebin.com/
>
>
>
>
> > Date: Wed, 24 Jul 2013 15:20:33 +0200
> > Subject: Re: Passing information between goals
> > From: m...@batmat.net
> > To: dev@maven.apache.org
> >
> > Hi,
> >
> > I remember doing that for build-helper. It was for many executions of the
> > same mojo though, not sure how it behaves with different mojos.
> > See
> >
> http://mojo.10943.n7.nabble.com/build-helper-m-p-thread-safety-issue-td39561.htmland
> > the ReserveListenerPortMojo
> >
> > My 2 cents.
> >
> > Cheers
> > Le 24 juil. 2013 14:17, "Stephen Connolly" <
> stephen.alan.conno...@gmail.com>
> > a écrit :
> >
> > > This is generally a tad tricky.
> > >
> > > 1. Because of class unloading it may not be possible to use the
> Hack-type
> > > solution of stashing the data in a Class level static field. Though
> that
> > > solution will work as long as the field uses a collection type that
> allows
> > > for GC when the MavenProject that it is caching a value for has been
> > > collected by GC (think of the users of Maven Embedder who's Maven
> process
> > > may be long lived and reused multiple times)
> > >
> > > 2. Easiest way may just be to serialize the value into a string form
> and
> > > set a project property with a non-maven resolvable name to the string
> > > value. For example I do not think it is possible to have a Maven
> property
> > > start with the null character.
> > >
> > > You code will need to be defensive, and if the property (or cache
> value if
> > > you go route 1) is missing it will have to calculate the value from
> scratch
> > >
> > >
> > > On 24 July 2013 12:57, Francesco Mari 
> wrote:
> > >
> > > > Hi,
> > > >
> > > > I wrote some MOJOs which use common data. This data depends on the
> > > > structure of the project and can't be changed at runtime.
> > > >
> > > > I would like to compute this information at the beginiing of the
> build
> > > > process, and re-use it in each related goal. Ideally, the first goal
> > > should
> > > > compute the data, and the following ones will just use it.
> > > >
> > > > Which is the best option? Are there any plugins already implementing
> > > such a
> > > > strategy, so I can take a look at their source code?
> > > >
> > >
>
>

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

2013-07-25 Thread Fred Cooke

I really appreciate your regularly inserted pieces of Irish humour and
often chuckle at them! Keep that up! :-)

What matters most to me is not the Apache legal stuff, nor good
behaviour/political correctness, rather it's technical excellence and
honesty in achieving it, even if at the expense of hurting someone's
feelings. They should be adults, after all, and not subject to hurt via
technical correction and discussion, even if firey.

My 2c, but you already know how little I care about stepping on toes,
especially when it comes to release semantics :-)

Fred.

On Thu, Jul 25, 2013 at 3:16 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> There are two schools of thought amongst the current members of this
> projects PMC.
>
> Without wanting to deliberately tip my hand and reveal where my opinion is,
> we would like to solicit the opinions if the community that we serve.
>
> Please give us your thoughts.
>
> The topic is essentially:
>
> Do you want the members of the Maven PMC to be social leaders of the Maven
> community, who's actions demonstrate the best community behaviour?
>
> The alternative is that members of the Maven PMC are here purely to
> complete the legal requirements that an Apache TLP has delegated to PMCs
>
> This is not black and white... The answer can be grey... And everyone is
> human so can make mistakes...
>
> So community, what are you expecting?
>
> - Stephen Connolly
>
> On Thursday, 25 July 2013, wrote:
>
> > Author: jdcasey
> > Date: Wed Jul 24 23:21:58 2013
> > New Revision: 1506778
> >
> > URL: http://svn.apache.org/r1506778
> > Log:
> > Adding section on PMC standards of community commitment
> >
> > Modified:
> > maven/site/trunk/content/markdown/project-roles.md
> >
> > Modified: maven/site/trunk/content/markdown/project-roles.md
> > URL:
> >
> http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1506778&r1=1506777&r2=1506778&view=diff
> >
> >
> ==
> > --- maven/site/trunk/content/markdown/project-roles.md (original)
> > +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24
> > 23:21:58 2013
> > @@ -176,6 +176,29 @@ The Project Management Committee has the
> >  * Voting on release artifacts.
> >  * 
> >
> > + Standards for Community Commitment
> > +
> > +In the spirit of supporting the health of our community, Project
> > +Management Committee members refrain from actions that subvert the
> > +functioning of the committee itself.
> > +
> > +First, Project Management Committee members should not maintain
> > long-running
> > +forks of Maven code outside of the project itself. Making significant
> > +changes to Maven code outside of the project displays a lack of
> > +investment in the community. Additionally, attempting to re-integrate
> > +a large number of code changes in bulk overwhelms the ability of
> > +volunteers in the community to review (and potentially veto) the
> > +changes. This effectively thwarts the policing function of the
> > +PMC.
> > +
> > +Second, Project Management Committee members should not divert
> > +work on redesigning, reimplementing, or improving Maven code to
> > +alternative projects outside of this community for the purposes of
> > +reintroducing them as replacement for existing Maven code. While there
> > +is a danger here of falling into a Not Invented Here mentality, new
> > projects
> > +created by Maven PMC members strictly to replace Maven code should not
> be
> > +allowed.
> > +
> >  ### [Project Management Chair](
> > http://www.apache.org/foundation/how-it-works.html#pmc-chair)
> >
> >  For various legal reasons, there are certain things that the Apache
> >
> >
> >
>
> --
> Sent from my phone
>

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

2013-07-25 Thread Fred Cooke

So much in-crowd politics and unspoken but apparently well-known material.

Who is the person, who if they were to come across this, would obviously
know they were being talked about anyway?

Where is the, almost certainly short lived, fork of Maven located? A quick
search failed to reveal this.

Such material is best on the table.

Fred.

On Fri, Jul 26, 2013 at 12:07 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On 25 July 2013 22:34, Nigel Magnay  wrote:
>
> > >
> > >
> > > Should the PMC encourage people experimenting on new improvements to
> > Maven
> > > to do that work at the ASF? And if so, should they then practice what
> > they
> > > preach, and ensure that any experiments with Maven take place on the
> ASF
> > > SCM servers (at least once such experiments become semi-serious or
> > progress
> > > enough not to cause egg-on-face syndrome)?
> > >
> > >
> > That feels to me like swimming entirely against the tide, and a recipe
> for
> > irrelevance.
> >
> > Who, in 2013, *cares* about Apache's SCM? OSS, for just about everyone I
> > speak to these days runs thus:
> >
> > 1) Is it on Github?
> > 2) If no, fork onto GIthub.
> >
> > ASF might indeed value "community over code", but that doesn't seem to
> be a
> > winning strategy any longer, and those changes seem to be trying to
> > double-down on that strategy.
> >
>
> There is nothing preventing the project from being mirrored onto GitHub,
> and in fact the Maven project is mirrored there.
>
> We *legally* need to have the code end up back at ASF if we are to release
> it under the legal protections that the ASF provides.
>
> We *legally* are supposed to review aspects of the provenance of the code
> that gets released. The more code development that takes place on non ASF
> servers, the less we can be sure of.
>
> By having commits and forks at ASF, then each non-ASF set of commits will
> be smaller and more likely from a single author which means less work for
> reviewing.
>
> Code dumps from a long running fork are thus incompatible with releasing
> from the ASF
>
> If you are a YOLO developer, perhaps you don't care about the legal
> stuff... your prerogative... I think it is a mistake though.
>
>
> >
> > Perhaps Maven should extricate itself from the ASF. Maybe that's what
> long
> > standing forks will do.
> >
>
> Perhaps. Perhaps not. This is a different question... and one that also
> begs an answer to a different question: what value do users of Maven place
> on the legal protections that being released from the ASF provide. There is
> also the question of whether the developers value the legal protections.
>
> But at the end of they day there seems to be quite a large cohort of OSS
> developers who take a YOLO attitude towards legal stuff[1]... who knows
> what experiences they will encounter in the next few years and whether they
> will change their opinions in the light of their experiences and whether
> they will then see relevance in the ASF.
>
> [1]: There are lots of projects on GitHub that don't even bother to have a
> license
>

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

2013-07-25 Thread Fred Cooke

It would appear to me to be an evolution from the implicit nature of this
conversation thus far, but whatever, I couldn't care less. I just find
talking about it without talking about it in poor taste.

About the fork, though, I'm interested. I'm interested in why it's
maintained and how it differs. I'm interested because I intend to fork it
myself to fix things which would break others which I know won't change
upstream (site and release stuff). Perhaps someone already fixed what I
consider broken and others, perhaps, do not consider broken. Email me
privately if need be.

If the fork is just a branch (or set thereof), and not promoted as a fork
(in a social sense), then is there really any harm? Is it being viewed as a
loss of potential work done? Open source is open for a reason.

Fred.

On Fri, Jul 26, 2013 at 12:28 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On 25 July 2013 23:15, Fred Cooke  wrote:
>
> > So much in-crowd politics and unspoken but apparently well-known
> material.
> >
> > Who is the person, who if they were to come across this, would obviously
> > know they were being talked about anyway?
> >
>
> I would rather we not focus on specific people. This should be a question
> that is isolated from any specific person. Often times when there is a
> specific person in mind people can have biases both for that person or
> against that person which can colour their views of the question at hand.
>
>
> >
> > Where is the, almost certainly short lived, fork of Maven located? A
> quick
> > search failed to reveal this.
> >
>
> There is at least one Maven Committer who has been maintaining a fork of
> Maven for perhaps the greater part of a year. There is nothing wrong with
> committers maintaining their own private forks. If they intend on bringing
> the work back to the Maven project, then the best way to achieve that is in
> smaller parts and not as one big code drop at the end.
>
> The question is whether the community sees this as against the spirit of
> what it means to be part of the PMC.
>
> We could pick one specific individual as a "test case" but I don't think
> that would be productive. Any such individual is likely to bring a lot of
> other baggage with them and could therefore confuse the results of such a
> "test case"
>
>
> > Such material is best on the table.
> >
>
> I hope we don't have to devolve to specifics about specific individuals.
>
>
> >
> > Fred.
> >
> > On Fri, Jul 26, 2013 at 12:07 AM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > On 25 July 2013 22:34, Nigel Magnay  wrote:
> > >
> > > > >
> > > > >
> > > > > Should the PMC encourage people experimenting on new improvements
> to
> > > > Maven
> > > > > to do that work at the ASF? And if so, should they then practice
> what
> > > > they
> > > > > preach, and ensure that any experiments with Maven take place on
> the
> > > ASF
> > > > > SCM servers (at least once such experiments become semi-serious or
> > > > progress
> > > > > enough not to cause egg-on-face syndrome)?
> > > > >
> > > > >
> > > > That feels to me like swimming entirely against the tide, and a
> recipe
> > > for
> > > > irrelevance.
> > > >
> > > > Who, in 2013, *cares* about Apache's SCM? OSS, for just about
> everyone
> > I
> > > > speak to these days runs thus:
> > > >
> > > > 1) Is it on Github?
> > > > 2) If no, fork onto GIthub.
> > > >
> > > > ASF might indeed value "community over code", but that doesn't seem
> to
> > > be a
> > > > winning strategy any longer, and those changes seem to be trying to
> > > > double-down on that strategy.
> > > >
> > >
> > > There is nothing preventing the project from being mirrored onto
> GitHub,
> > > and in fact the Maven project is mirrored there.
> > >
> > > We *legally* need to have the code end up back at ASF if we are to
> > release
> > > it under the legal protections that the ASF provides.
> > >
> > > We *legally* are supposed to review aspects of the provenance of the
> code
> > > that gets released. The more code development that takes place on non
> ASF
> > > servers, the less we can be sure of.
> > >
> > > By having commits and forks at ASF, then each non-A

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

2013-07-27 Thread Fred Cooke

I have a bunch of IRL stuff to deal with at the moment, and can't even work
on my own FOSS or proprietary code, so don't expect a "fork" soon.

When I say "broken", don't be offended, few codebases aren't broken in some
way :-)

One example of "broken" is my SCM url being munged from this:

scm:git:git:${project.groupId}/${project.artifactId}.git

To this:

scm:git:git:${project.groupId}/${project.artifactId}.git/${project.artifactId}

And all I have to say to that, other than the pain it caused me, is LOL!
:-p OK, I can add one more thing: F*** SVN. OK, now I'm done. :-)

Then there's the issue where my .ssh/config file was totally ignored unless
I used the external provider, and so on and so forth.

Reality check: It's a lot easier and quicker to hack in a fix for me that
breaks everyone else, than it is to agree on and implement a solution that
works for everyone in a backward compatible way. Hence fork. Make what I
need happen now and not sit around waiting for agreement on how to progress
"properly".

Other than a fork of my very own, I'd be VERY hesitant to trust anyone
else's forks. For example, I don't trust Debian Maven nor Fedora Maven out
of unjustified and paranoid fear that their patches to "just use what the
distro has" for deps might be active when they shouldn't be, etc. Forks
rarely gain traction, unless the base project is severely lacking in some
way.

Fred.

On Sat, Jul 27, 2013 at 9:56 AM, Hervé BOUTEMY wrote:

> Le vendredi 26 juillet 2013 01:05:44 Fred Cooke a écrit :
> > About the fork, though, I'm interested. I'm interested in why it's
> > maintained and how it differs. I'm interested because I intend to fork it
> > myself to fix things which would break others which I know won't change
> > upstream (site and release stuff). Perhaps someone already fixed what I
> > consider broken and others, perhaps, do not consider broken. Email me
> > privately if need be.
> >
> > If the fork is just a branch (or set thereof), and not promoted as a fork
> > (in a social sense), then is there really any harm? Is it being viewed
> as a
> > loss of potential work done? Open source is open for a reason.
> +1
>
> in your case for example:
>
> if you make a fork to site plugin to fix it in a personal way, please don't
> hide it but show us where you fork/branch and explain how you change the
> code
> (in a Jira issue?): I'm interested to see your work and understand what
> you're
> doing, since I definitely don't understand how you find the plugin broken
> (and
> to be honest, every time I read this "broken" sentence, I feel aggressed).
>
> IMHO, a personal branch can be an excellent way of working with the
> community:
> I'm really interested to see you fix what I can't do because I really don't
> understand what is "broken".
>
> Of course, if the difference between your branch and trunk gets big, it'll
> be
> harder to find how to converge later: but we'll see. Explaned with the
> community from start, and used to interact with the community to show how
> it
> can evolve, we can understand and define with consensus that this can be a
> real
> friendly fork = a different choice on some fundamental point. Or perhaps it
> will be the start og m-site-p 4: who knows?
>
> Regards,
>
> Hervé
>
> >
> > Fred.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [2/2] git commit: o change the scope of org.eclipse.sisu to test in the maven-aether-provider to prevent it from leaking out to clients.

2013-07-27 Thread Fred Cooke

Yes, easily, if it's the HEAD just do a --amend on it and update it
yourself, Jason's name will be retained. If it's not HEAD then do rebase -i
 then mark the one of interest for
comment edit and proceed.

On Sat, Jul 27, 2013 at 1:28 PM, Hervé BOUTEMY wrote:

> IIUC, this is a fix to https://jira.codehaus.org/browse/MNG-5499
>
> I'm not a git blackbelt: can the comment be updated to add the classical
> [MNG-5499]?
> (and next time not be forgotten from initial comment :) )
>
> I'm adding a reference to the commit in the Jira issue
>
> Regards,
>
> Hervé
>
> Le samedi 27 juillet 2013 01:45:44 jvan...@apache.org a écrit :
> > o change the scope of org.eclipse.sisu to test in the
> maven-aether-provider
> > to prevent it from leaking out to clients.
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/e084ff3b
> > Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/e084ff3b
> > Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/e084ff3b
> >
> > Branch: refs/heads/master
> > Commit: e084ff3b8c04bdfdac62a28a1bef8ec87762d4dc
> > Parents: 0609504
> > Author: Jason van Zyl 
> > Authored: Fri Jul 26 21:09:50 2013 -0400
> > Committer: Jason van Zyl 
> > Committed: Fri Jul 26 21:09:50 2013 -0400
> >
> > --
> >  maven-aether-provider/pom.xml | 30 --
> >  1 file changed, 16 insertions(+), 14 deletions(-)
> > --
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/maven/blob/e084ff3b/maven-aether-prov
> > ider/pom.xml
> > --
> diff
> > --git a/maven-aether-provider/pom.xml b/maven-aether-provider/pom.xml
> index
> > 910fab6..9235f1c 100644
> > --- a/maven-aether-provider/pom.xml
> > +++ b/maven-aether-provider/pom.xml
> > @@ -63,20 +63,6 @@ under the License.
> >aether-impl
> >  
> >  
> > -  org.eclipse.aether
> > -  aether-connector-wagon
> > -  test
> > -
> > -
> > -  org.apache.maven.wagon
> > -  wagon-file
> > -  test
> > -
> > -
> > -  org.eclipse.sisu
> > -  org.eclipse.sisu.plexus
> > -
> > -
> >org.codehaus.plexus
> >plexus-component-annotations
> >  
> > @@ -96,6 +82,22 @@ under the License.
> >  
> >
> >  
> > +
> > +
> > +  org.eclipse.aether
> > +  aether-connector-wagon
> > +  test
> > +
> > +
> > +  org.apache.maven.wagon
> > +  wagon-file
> > +  test
> > +
> > +
> > +  org.eclipse.sisu
> > +  org.eclipse.sisu.plexus
> > +  test
> > +
> >
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [2/2] git commit: o change the scope of org.eclipse.sisu to test in the maven-aether-provider to prevent it from leaking out to clients.

2013-07-27 Thread Fred Cooke

Of course, if anyone is working down stream of this, they will hate you,
and it should be left as is.

On Sat, Jul 27, 2013 at 1:36 PM, Fred Cooke  wrote:

> Yes, easily, if it's the HEAD just do a --amend on it and update it
> yourself, Jason's name will be retained. If it's not HEAD then do rebase -i
>  then mark the one of interest for
> comment edit and proceed.
>
>
> On Sat, Jul 27, 2013 at 1:28 PM, Hervé BOUTEMY wrote:
>
>> IIUC, this is a fix to https://jira.codehaus.org/browse/MNG-5499
>>
>> I'm not a git blackbelt: can the comment be updated to add the classical
>> [MNG-5499]?
>> (and next time not be forgotten from initial comment :) )
>>
>> I'm adding a reference to the commit in the Jira issue
>>
>> Regards,
>>
>> Hervé
>>
>> Le samedi 27 juillet 2013 01:45:44 jvan...@apache.org a écrit :
>> > o change the scope of org.eclipse.sisu to test in the
>> maven-aether-provider
>> > to prevent it from leaking out to clients.
>> >
>> >
>> > Project: http://git-wip-us.apache.org/repos/asf/maven/repo
>> > Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/e084ff3b
>> > Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/e084ff3b
>> > Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/e084ff3b
>> >
>> > Branch: refs/heads/master
>> > Commit: e084ff3b8c04bdfdac62a28a1bef8ec87762d4dc
>> > Parents: 0609504
>> > Author: Jason van Zyl 
>> > Authored: Fri Jul 26 21:09:50 2013 -0400
>> > Committer: Jason van Zyl 
>> > Committed: Fri Jul 26 21:09:50 2013 -0400
>> >
>> > --
>> >  maven-aether-provider/pom.xml | 30 --
>> >  1 file changed, 16 insertions(+), 14 deletions(-)
>> > --
>> >
>> >
>> >
>> http://git-wip-us.apache.org/repos/asf/maven/blob/e084ff3b/maven-aether-prov
>> > ider/pom.xml
>> > --
>> diff
>> > --git a/maven-aether-provider/pom.xml b/maven-aether-provider/pom.xml
>> index
>> > 910fab6..9235f1c 100644
>> > --- a/maven-aether-provider/pom.xml
>> > +++ b/maven-aether-provider/pom.xml
>> > @@ -63,20 +63,6 @@ under the License.
>> >aether-impl
>> >  
>> >  
>> > -  org.eclipse.aether
>> > -  aether-connector-wagon
>> > -  test
>> > -
>> > -
>> > -  org.apache.maven.wagon
>> > -  wagon-file
>> > -  test
>> > -
>> > -
>> > -  org.eclipse.sisu
>> > -  org.eclipse.sisu.plexus
>> > -
>> > -
>> >org.codehaus.plexus
>> >plexus-component-annotations
>> >  
>> > @@ -96,6 +82,22 @@ under the License.
>> >  
>> >
>> >  
>> > +
>> > +
>> > +  org.eclipse.aether
>> > +  aether-connector-wagon
>> > +  test
>> > +
>> > +
>> > +  org.apache.maven.wagon
>> > +  wagon-file
>> > +  test
>> > +
>> > +
>> > +  org.eclipse.sisu
>> > +  org.eclipse.sisu.plexus
>> > +  test
>> > +
>> >
>> >
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>

Re: [2/2] git commit: o change the scope of org.eclipse.sisu to test in the maven-aether-provider to prevent it from leaking out to clients.

2013-07-27 Thread Fred Cooke

No, you do NOT want to do a git pull, almost ever. You want to do a git
fetch, ensure you're not going to destroy other's good work, then if you're
just replacing same with same, force push. This is a risky operation for an
upstream to do as I mentioned above in my amendment. I would recommend
ignoring this slip up and leaving it alone unless it's on a non-master
branch that no one has publicly forked from.

Pull is a shortcut for fetch and merge and merging amended commits in is a
brain-dead thing to do which results in two copies of the same commit being
present in history, one fixed, one original. IE, just an ugly mess, not an
improvement. Either force over the old stuff (after you're sure it's safe
to do so) or leave it alone.

I've heard people on this list write that people should all be sharing the
same repo. This is generally not a good idea due to the above mistakes that
can easily occur by novice Gitters. Much better to have a set of
gate-keepers and individual repos and issue pull requests, emails here, IRC
messages, etc to get your stuff included. The gate-keepers should have an
absolutely solid grasp of Git.

Fred.

On Sat, Jul 27, 2013 at 3:17 PM, Jeff Jensen <
jeffjen...@upstairstechnology.com> wrote:

> That message indicates you need to git pull first.  Even though you
> may already have done so and no one else has pushed since, this usually
> happens when modifying a commit that has been pushed/shared.
>
> On Sat, Jul 27, 2013 at 8:08 AM, Hervé BOUTEMY 
> wrote:
> > the last 2 commits are to be amended: lst one for MNG-5499, previous one
> for
> > MNG-5495
> >
> > I tried git commit --amend -m "[MNG-5499]..." for the last one, but when
> I git
> > push, I get
> >
> > To https://git-wip-us.apache.org/repos/asf/maven.git
> >  ! [rejected]master -> master (non-fast-forward)
> > error: failed to push some refs to '
> https://git-wip-us.apache.org/repos/asf/maven.git'
> > hint: Updates were rejected because the tip of your current branch is
> behind
> > hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
> > hint: before pushing again.
> > hint: See the 'Note about fast-forwards' in 'git push --help' for
> details.
> >
> >
> > Did I do something wrong? Or git repo at ASF is configured to avoid such
> > things?
> >
> > Regards,
> >
> > Hervé
> >
> > Le samedi 27 juillet 2013 13:37:12 Fred Cooke a écrit :
> >> Of course, if anyone is working down stream of this, they will hate you,
> >> and it should be left as is.
> >>
> >> On Sat, Jul 27, 2013 at 1:36 PM, Fred Cooke 
> wrote:
> >> > Yes, easily, if it's the HEAD just do a --amend on it and update it
> >> > yourself, Jason's name will be retained. If it's not HEAD then do
> rebase
> >> > -i
> >> >  then mark the one of interest
> for
> >> > comment edit and proceed.
> >> >
> >> > On Sat, Jul 27, 2013 at 1:28 PM, Hervé BOUTEMY
> > wrote:
> >> >> IIUC, this is a fix to https://jira.codehaus.org/browse/MNG-5499
> >> >>
> >> >> I'm not a git blackbelt: can the comment be updated to add the
> classical
> >> >> [MNG-5499]?
> >> >> (and next time not be forgotten from initial comment :) )
> >> >>
> >> >> I'm adding a reference to the commit in the Jira issue
> >> >>
> >> >> Regards,
> >> >>
> >> >> Hervé
> >> >>
> >> >> Le samedi 27 juillet 2013 01:45:44 jvan...@apache.org a écrit :
> >> >> > o change the scope of org.eclipse.sisu to test in the
> >> >>
> >> >> maven-aether-provider
> >> >>
> >> >> > to prevent it from leaking out to clients.
> >> >> >
> >> >> >
> >> >> > Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> >> >> > Commit:
> http://git-wip-us.apache.org/repos/asf/maven/commit/e084ff3b
> >> >> > Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/e084ff3b
> >> >> > Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/e084ff3b
> >> >> >
> >> >> > Branch: refs/heads/master
> >> >> > Commit: e084ff3b8c04bdfdac62a28a1bef8ec87762d4dc
> >> >> > Parents: 0609504
> >> >> > Author: Jason van Zyl 
> >> >> > Authored: Fri Jul 26 21:09:50 2013 -0400
> >> >> &

Re: [2/2] git commit: o change the scope of org.eclipse.sisu to test in the maven-aether-provider to prevent it from leaking out to clients.

2013-07-27 Thread Fred Cooke

On Sat, Jul 27, 2013 at 3:36 PM, Arnaud Héritier wrote:

> At Apache it is forbidden to rewrite the history of the master branch.
> Which isn't so bad.
>

Ahh, this is a very sound policy! Someone is switched on! :-)


>
> -
> Arnaud
>
> Le 27 juil. 2013 à 15:19, Jeff Jensen
>  a écrit :
>
> > That message indicates you need to git pull first.  Even though you
> > may already have done so and no one else has pushed since, this usually
> > happens when modifying a commit that has been pushed/shared.
> >
> > On Sat, Jul 27, 2013 at 8:08 AM, Hervé BOUTEMY 
> wrote:
> >> the last 2 commits are to be amended: lst one for MNG-5499, previous
> one for
> >> MNG-5495
> >>
> >> I tried git commit --amend -m "[MNG-5499]..." for the last one, but
> when I git
> >> push, I get
> >>
> >> To https://git-wip-us.apache.org/repos/asf/maven.git
> >> ! [rejected]master -> master (non-fast-forward)
> >> error: failed to push some refs to '
> https://git-wip-us.apache.org/repos/asf/maven.git'
> >> hint: Updates were rejected because the tip of your current branch is
> behind
> >> hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
> >> hint: before pushing again.
> >> hint: See the 'Note about fast-forwards' in 'git push --help' for
> details.
> >>
> >>
> >> Did I do something wrong? Or git repo at ASF is configured to avoid such
> >> things?
> >>
> >> Regards,
> >>
> >> Hervé
> >>
> >> Le samedi 27 juillet 2013 13:37:12 Fred Cooke a écrit :
> >>> Of course, if anyone is working down stream of this, they will hate
> you,
> >>> and it should be left as is.
> >>>
> >>> On Sat, Jul 27, 2013 at 1:36 PM, Fred Cooke 
> wrote:
> >>>> Yes, easily, if it's the HEAD just do a --amend on it and update it
> >>>> yourself, Jason's name will be retained. If it's not HEAD then do
> rebase
> >>>> -i
> >>>>  then mark the one of interest
> for
> >>>> comment edit and proceed.
> >>>>
> >>>> On Sat, Jul 27, 2013 at 1:28 PM, Hervé BOUTEMY
> >> wrote:
> >>>>> IIUC, this is a fix to https://jira.codehaus.org/browse/MNG-5499
> >>>>>
> >>>>> I'm not a git blackbelt: can the comment be updated to add the
> classical
> >>>>> [MNG-5499]?
> >>>>> (and next time not be forgotten from initial comment :) )
> >>>>>
> >>>>> I'm adding a reference to the commit in the Jira issue
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Hervé
> >>>>>
> >>>>> Le samedi 27 juillet 2013 01:45:44 jvan...@apache.org a écrit :
> >>>>>> o change the scope of org.eclipse.sisu to test in the
> >>>>>
> >>>>> maven-aether-provider
> >>>>>
> >>>>>> to prevent it from leaking out to clients.
> >>>>>>
> >>>>>>
> >>>>>> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> >>>>>> Commit:
> http://git-wip-us.apache.org/repos/asf/maven/commit/e084ff3b
> >>>>>> Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/e084ff3b
> >>>>>> Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/e084ff3b
> >>>>>>
> >>>>>> Branch: refs/heads/master
> >>>>>> Commit: e084ff3b8c04bdfdac62a28a1bef8ec87762d4dc
> >>>>>> Parents: 0609504
> >>>>>> Author: Jason van Zyl 
> >>>>>> Authored: Fri Jul 26 21:09:50 2013 -0400
> >>>>>> Committer: Jason van Zyl 
> >>>>>> Committed: Fri Jul 26 21:09:50 2013 -0400
> >>>>>>
> >>>>>>
> --
> >>>>>>
> >>>>>> maven-aether-provider/pom.xml | 30 --
> >>>>>> 1 file changed, 16 insertions(+), 14 deletions(-)
> >>>>>>
> >>>>>>
> --
> >>>>>
> >>>>>
> http://git-wip-us.apache.org/repos/asf/maven/blob/e084ff3

Re: [2/2] git commit: o change the scope of org.eclipse.sisu to test in the maven-aether-provider to prevent it from leaking out to clients.

2013-07-27 Thread Fred Cooke

My most humble apologies to Herve for leading you astray! I was unaware of
the policy on this. I hope that I didn't inadvertently cause any harm.

On Sat, Jul 27, 2013 at 3:38 PM, Fred Cooke  wrote:

> On Sat, Jul 27, 2013 at 3:36 PM, Arnaud Héritier wrote:
>
>> At Apache it is forbidden to rewrite the history of the master branch.
>> Which isn't so bad.
>>
>
> Ahh, this is a very sound policy! Someone is switched on! :-)
>
>
>>
>> -
>> Arnaud
>>
>> Le 27 juil. 2013 à 15:19, Jeff Jensen
>>  a écrit :
>>
>> > That message indicates you need to git pull first.  Even though you
>> > may already have done so and no one else has pushed since, this usually
>> > happens when modifying a commit that has been pushed/shared.
>> >
>> > On Sat, Jul 27, 2013 at 8:08 AM, Hervé BOUTEMY 
>> wrote:
>> >> the last 2 commits are to be amended: lst one for MNG-5499, previous
>> one for
>> >> MNG-5495
>> >>
>> >> I tried git commit --amend -m "[MNG-5499]..." for the last one, but
>> when I git
>> >> push, I get
>> >>
>> >> To https://git-wip-us.apache.org/repos/asf/maven.git
>> >> ! [rejected]master -> master (non-fast-forward)
>> >> error: failed to push some refs to '
>> https://git-wip-us.apache.org/repos/asf/maven.git'
>> >> hint: Updates were rejected because the tip of your current branch is
>> behind
>> >> hint: its remote counterpart. Merge the remote changes (e.g. 'git
>> pull')
>> >> hint: before pushing again.
>> >> hint: See the 'Note about fast-forwards' in 'git push --help' for
>> details.
>> >>
>> >>
>> >> Did I do something wrong? Or git repo at ASF is configured to avoid
>> such
>> >> things?
>> >>
>> >> Regards,
>> >>
>> >> Hervé
>> >>
>> >> Le samedi 27 juillet 2013 13:37:12 Fred Cooke a écrit :
>> >>> Of course, if anyone is working down stream of this, they will hate
>> you,
>> >>> and it should be left as is.
>> >>>
>> >>> On Sat, Jul 27, 2013 at 1:36 PM, Fred Cooke 
>> wrote:
>> >>>> Yes, easily, if it's the HEAD just do a --amend on it and update it
>> >>>> yourself, Jason's name will be retained. If it's not HEAD then do
>> rebase
>> >>>> -i
>> >>>>  then mark the one of interest
>> for
>> >>>> comment edit and proceed.
>> >>>>
>> >>>> On Sat, Jul 27, 2013 at 1:28 PM, Hervé BOUTEMY
>> >> wrote:
>> >>>>> IIUC, this is a fix to https://jira.codehaus.org/browse/MNG-5499
>> >>>>>
>> >>>>> I'm not a git blackbelt: can the comment be updated to add the
>> classical
>> >>>>> [MNG-5499]?
>> >>>>> (and next time not be forgotten from initial comment :) )
>> >>>>>
>> >>>>> I'm adding a reference to the commit in the Jira issue
>> >>>>>
>> >>>>> Regards,
>> >>>>>
>> >>>>> Hervé
>> >>>>>
>> >>>>> Le samedi 27 juillet 2013 01:45:44 jvan...@apache.org a écrit :
>> >>>>>> o change the scope of org.eclipse.sisu to test in the
>> >>>>>
>> >>>>> maven-aether-provider
>> >>>>>
>> >>>>>> to prevent it from leaking out to clients.
>> >>>>>>
>> >>>>>>
>> >>>>>> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
>> >>>>>> Commit:
>> http://git-wip-us.apache.org/repos/asf/maven/commit/e084ff3b
>> >>>>>> Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/e084ff3b
>> >>>>>> Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/e084ff3b
>> >>>>>>
>> >>>>>> Branch: refs/heads/master
>> >>>>>> Commit: e084ff3b8c04bdfdac62a28a1bef8ec87762d4dc
>> >>>>>> Parents: 0609504
>> >>>>>> Author: Jason van Zyl 
>> >>>>>> Authored: Fri Jul 26 21:09:50 2013 -0400
>> >>>>>> Committer: Jason van Zyl 
>> >>>>>> Committed: Fri Jul 26 21:09:50 2013 -

Re: [2/2] git commit: o change the scope of org.eclipse.sisu to test in the maven-aether-provider to prevent it from leaking out to clients.

2013-07-27 Thread Fred Cooke

Good practice is to work on a branch anyway, then you're free to do
whatever you wish. I have ~30 branches in my private copy of my project
right now. When one matures I rebase it onto the latest public, then
publish it. Then I rebase the others periodically up onto the latest public
too. Wash rinse repeat.

With SVN changing a bad comment wasn't even possible, so stating "no
amending master" isn't really a restriction at all. It's just good practice.

Fred.

On Sat, Jul 27, 2013 at 4:00 PM, Robert Scholte wrote:

> I'm actually kind of surprised. I'm learning my co-workers that comments
> are very important. With a buildserver it has become very easy to have an
> overview of the latest commits and understand what broke the build.
> Writing good comments should help everybody to understand why a commit is
> done (yes: why. Not 'what', that's already easy to figure out). So I'm
> really in favor to being able change comments, because bad comments are
> sometimes even worse than no comments.
>
> Just like Hervé, I'd really prefer to see if a commit is done for a
> specific issue or not. In this case I would have liked to see a fix on the
> comment if possible, because the current comment is incomplete.
>
> Anyhow, now I know about this.
>
> Robert
>
>
> Op Sat, 27 Jul 2013 15:40:05 +0200 schreef Jeff Jensen  upstairstechnology.com >:
>
>
>  On Sat, Jul 27, 2013 at 8:38 AM, Fred Cooke  wrote:
>>
>>> On Sat, Jul 27, 2013 at 3:36 PM, Arnaud Héritier >> >wrote:
>>>
>>>  At Apache it is forbidden to rewrite the history of the master branch.
>>>> Which isn't so bad.
>>>>
>>>>
>>> Ahh, this is a very sound policy! Someone is switched on! :-)
>>>
>>
>> Yes, very good!
>>
>>
>>  -
>>>> Arnaud
>>>>
>>>> Le 27 juil. 2013 à 15:19, Jeff Jensen
>>>> >
>>>> a écrit :
>>>>
>>>> > That message indicates you need to git pull first.  Even though you
>>>> > may already have done so and no one else has pushed since, this
>>>> usually
>>>> > happens when modifying a commit that has been pushed/shared.
>>>> >
>>>> > On Sat, Jul 27, 2013 at 8:08 AM, Hervé BOUTEMY >>> >
>>>> wrote:
>>>> >> the last 2 commits are to be amended: lst one for MNG-5499, previous
>>>> one for
>>>> >> MNG-5495
>>>> >>
>>>> >> I tried git commit --amend -m "[MNG-5499]..." for the last one, but
>>>> when I git
>>>> >> push, I get
>>>> >>
>>>> >> To 
>>>> >> https://git-wip-us.apache.org/**repos/asf/maven.git<https://git-wip-us.apache.org/repos/asf/maven.git>
>>>> >> ! [rejected]master -> master (non-fast-forward)
>>>> >> error: failed to push some refs to '
>>>> https://git-wip-us.apache.org/**repos/asf/maven.git<https://git-wip-us.apache.org/repos/asf/maven.git>
>>>> '
>>>> >> hint: Updates were rejected because the tip of your current branch is
>>>> behind
>>>> >> hint: its remote counterpart. Merge the remote changes (e.g. 'git
>>>> pull')
>>>> >> hint: before pushing again.
>>>> >> hint: See the 'Note about fast-forwards' in 'git push --help' for
>>>> details.
>>>> >>
>>>> >>
>>>> >> Did I do something wrong? Or git repo at ASF is configured to avoid
>>>> such
>>>> >> things?
>>>> >>
>>>> >> Regards,
>>>> >>
>>>> >> Hervé
>>>> >>
>>>> >> Le samedi 27 juillet 2013 13:37:12 Fred Cooke a écrit :
>>>> >>> Of course, if anyone is working down stream of this, they will hate
>>>> you,
>>>> >>> and it should be left as is.
>>>> >>>
>>>> >>> On Sat, Jul 27, 2013 at 1:36 PM, Fred Cooke 
>>>> wrote:
>>>> >>>> Yes, easily, if it's the HEAD just do a --amend on it and update it
>>>> >>>> yourself, Jason's name will be retained. If it's not HEAD then do
>>>> rebase
>>>> >>>> -i
>>>> >>>>  then mark the one of
>>>> interest
>>>> for
>>>> >>>> comment ed

Re: [2/2] git commit: o change the scope of org.eclipse.sisu to test in the maven-aether-provider to prevent it from leaking out to clients.

2013-07-27 Thread Fred Cooke

How did I know you'd say that? You think I didn't know you could do that?
LOL :-p

Can't do it without bad config and/or administrator privileges. There,
fixed.

Fred.

On Sat, Jul 27, 2013 at 4:22 PM, Robert Scholte wrote:

> "With SVN changing a bad comment wasn't even possible"
>
> Yes it is, I've done it very often:
> http://subversion.apache.org/**faq.html#change-log-msg<http://subversion.apache.org/faq.html#change-log-msg>
> (although I use the GUI for it)
>
> Robert
>
> Op Sat, 27 Jul 2013 16:07:09 +0200 schreef Fred Cooke <
> fred.co...@gmail.com>:
>
>  Good practice is to work on a branch anyway, then you're free to do
>> whatever you wish. I have ~30 branches in my private copy of my project
>> right now. When one matures I rebase it onto the latest public, then
>> publish it. Then I rebase the others periodically up onto the latest
>> public
>> too. Wash rinse repeat.
>>
>> With SVN changing a bad comment wasn't even possible, so stating "no
>> amending master" isn't really a restriction at all. It's just good
>> practice.
>>
>> Fred.
>>
>> On Sat, Jul 27, 2013 at 4:00 PM, Robert Scholte > >wrote:
>>
>>  I'm actually kind of surprised. I'm learning my co-workers that comments
>>> are very important. With a buildserver it has become very easy to have an
>>> overview of the latest commits and understand what broke the build.
>>> Writing good comments should help everybody to understand why a commit is
>>> done (yes: why. Not 'what', that's already easy to figure out). So I'm
>>> really in favor to being able change comments, because bad comments are
>>> sometimes even worse than no comments.
>>>
>>> Just like Hervé, I'd really prefer to see if a commit is done for a
>>> specific issue or not. In this case I would have liked to see a fix on
>>> the
>>> comment if possible, because the current comment is incomplete.
>>>
>>> Anyhow, now I know about this.
>>>
>>> Robert
>>>
>>>
>>> Op Sat, 27 Jul 2013 15:40:05 +0200 schreef Jeff Jensen >> upstairstechnology.com 
>>> 
>>> >>:
>>>
>>>
>>>
>>>  On Sat, Jul 27, 2013 at 8:38 AM, Fred Cooke 
>>> wrote:
>>>
>>>>
>>>>  On Sat, Jul 27, 2013 at 3:36 PM, Arnaud Héritier >>>> >wrote:
>>>>>
>>>>>  At Apache it is forbidden to rewrite the history of the master branch.
>>>>>
>>>>>> Which isn't so bad.
>>>>>>
>>>>>>
>>>>>>  Ahh, this is a very sound policy! Someone is switched on! :-)
>>>>>
>>>>>
>>>> Yes, very good!
>>>>
>>>>
>>>>  -
>>>>
>>>>> Arnaud
>>>>>>
>>>>>> Le 27 juil. 2013 à 15:19, Jeff Jensen
>>>>>> http://upstairstechnology.com>
>>>>>> 
>>>>>> >>
>>>>>>
>>>>>> a écrit :
>>>>>>
>>>>>> > That message indicates you need to git pull first.  Even though you
>>>>>> > may already have done so and no one else has pushed since, this
>>>>>> usually
>>>>>> > happens when modifying a commit that has been pushed/shared.
>>>>>> >
>>>>>> > On Sat, Jul 27, 2013 at 8:08 AM, Hervé BOUTEMY <
>>>>>> herve.bout...@free.fr
>>>>>> >
>>>>>> wrote:
>>>>>> >> the last 2 commits are to be amended: lst one for MNG-5499,
>>>>>> previous
>>>>>> one for
>>>>>> >> MNG-5495
>>>>>> >>
>>>>>> >> I tried git commit --amend -m "[MNG-5499]..." for the last one, but
>>>>>> when I git
>>>>>> >> push, I get
>>>>>> >>
>>>>>> >> To 
>>>>>> >> https://git-wip-us.apache.org/****repos/asf/maven.git<https://git-wip-us.apache.org/**repos/asf/maven.git>
>>>>>> <https://**git-wip-us.apache.org/repos/**asf/maven.git<https://git-wip-us.apache.org/repos/asf/maven.git>
>>>>>> >
>>>>>>
>>>>>> >> ! [rejected]master -> master (non-fast-forward)
>>>>>&

Re: [2/2] git commit: o change the scope of org.eclipse.sisu to test in the maven-aether-provider to prevent it from leaking out to clients.

2013-07-27 Thread Fred Cooke

:-) Tui, yeah right. [1][2]

Or work on branches, pushed publicly with meaningful names like
attempt-fix-of-site-behaviour or whatever and seek peer review before
rebasing and applying to master. IMO this should apply to Maven "gods" as
much to any other committer. No one is incapable of making mistakes.

Those private branches of mine, I self review the entire diff and comment
of every commit multiple times before I publish if publishing directly to
my main branches. I amend and adjust and tweak them until they're as close
to perfectly formed as possible. If I'm pushing to temp branches, I let
others help with the review first ;-)

Fred.

[1] http://www.tui.co.nz/Competitions/Yeah-Right
[2]
http://2.bp.blogspot.com/-lA11480KeR0/Tnsy7llzTXI/A5Y/hHfTeCes9eg/s1600/Tui-Yeah-Right-Calendar-Girls-Billboard.jpg

On Sat, Jul 27, 2013 at 4:45 PM, Hervé BOUTEMY wrote:

> so, this time:
> svn +1
> git -1
>
> :)
>
> more seriously: if we cannot fix comments later, we'll need to be more
> careful
> when committing
>
> Regards,
>
> Hervé
>
> Le samedi 27 juillet 2013 16:27:50 Fred Cooke a écrit :
> > How did I know you'd say that? You think I didn't know you could do that?
> > LOL :-p
> >
> > Can't do it without bad config and/or administrator privileges. There,
> > fixed.
> >
> > Fred.
> >
> > On Sat, Jul 27, 2013 at 4:22 PM, Robert Scholte  >wrote:
> > > "With SVN changing a bad comment wasn't even possible"
> > >
> > > Yes it is, I've done it very often:
> > > http://subversion.apache.org/**faq.html#change-log-msg<
> http://subversion.a
> > > pache.org/faq.html#change-log-msg> (although I use the GUI for it)
> > >
> > > Robert
> > >
> > > Op Sat, 27 Jul 2013 16:07:09 +0200 schreef Fred Cooke <
> > >
> > > fred.co...@gmail.com>:
> > >  Good practice is to work on a branch anyway, then you're free to do
> > >
> > >> whatever you wish. I have ~30 branches in my private copy of my
> project
> > >> right now. When one matures I rebase it onto the latest public, then
> > >> publish it. Then I rebase the others periodically up onto the latest
> > >> public
> > >> too. Wash rinse repeat.
> > >>
> > >> With SVN changing a bad comment wasn't even possible, so stating "no
> > >> amending master" isn't really a restriction at all. It's just good
> > >> practice.
> > >>
> > >> Fred.
> > >>
> > >> On Sat, Jul 27, 2013 at 4:00 PM, Robert Scholte  > >>
> > >> >wrote:
> > >>  I'm actually kind of surprised. I'm learning my co-workers that
> comments
> > >>
> > >>> are very important. With a buildserver it has become very easy to
> have
> > >>> an
> > >>> overview of the latest commits and understand what broke the build.
> > >>> Writing good comments should help everybody to understand why a
> commit
> > >>> is
> > >>> done (yes: why. Not 'what', that's already easy to figure out). So
> I'm
> > >>> really in favor to being able change comments, because bad comments
> are
> > >>> sometimes even worse than no comments.
> > >>>
> > >>> Just like Hervé, I'd really prefer to see if a commit is done for a
> > >>> specific issue or not. In this case I would have liked to see a fix
> on
> > >>> the
> > >>> comment if possible, because the current comment is incomplete.
> > >>>
> > >>> Anyhow, now I know about this.
> > >>>
> > >>> Robert
> > >>>
> > >>>
> > >>> Op Sat, 27 Jul 2013 15:40:05 +0200 schreef Jeff Jensen  **
> > >>> upstairstechnology.com
> > >>>  jeffjen...@upstairstechnology.com>>>>
> > >>>  On Sat, Jul 27, 2013 at 8:38 AM, Fred Cooke 
> > >>>
> > >>> wrote:
> > >>>>  On Sat, Jul 27, 2013 at 3:36 PM, Arnaud Héritier <
> aherit...@gmail.com
> > >>>>
> > >>>>> >wrote:
> > >>>>>  At Apache it is forbidden to rewrite the history of the master
> > >>>>>  branch.
> > >>>>>
> > >>>>>> Which isn't so bad.
> > >>>>>>
> > >>>>>>  Ahh, this is a very sound policy! Someone

Re: Git resources was Re: [2/2] git commit: o change the scope of org.eclipse.sisu to test in the maven-aether-provider to prevent it from leaking out to clients.

2013-07-27 Thread Fred Cooke

This ought to keep you out of trouble if you're a downstream user:

NEVER git pull
NEVER git merge
ALWAYS git fetch 
ALWAYS git merge --ff-only /
ALWAYS git rebase /

[image: http://stuff.fredcooke.com/IDontAlwaysMergeButWhenIDoI.jpg]

rebase -i is your friend if used appropriately.

As mentioned, anything you need to know about you can find on the net or in
the man page or with --help. But, key: If you want to learn, do. With git,
make a new clone and go to town on it, see what magic you can work, you'll
learn a lot. And unless you execute a push --force you can't harm your
"real" copy.

As for the "successful" branching model, yuck... How to make an
incomprehensible mess for no reason.

A variation on the diagram from the git book, which I don't agree with, and
think is misleading and unclear.

[image: Image]

Explanation:

   - On the left are files that are not known to git. New files. Files that
   have not been committed in the past, or have since been removed.
   - Next to that is the normal default state of a committed and tracked
   git file.
   - To the right of that is the same file, modified, and showing a dirty
   status.
   - Finally, on the right is a staging area, where you MUST add new files,
   and where you CAN add existing modified files.

The original 
fileis
misleading in that:

   1. It shows adding a new file as making it tracked, when really, it's
   just staged, and not committed. Sure, git knows about it, but not in a
   permanent/semi-permanent way.
   2. It doesn't show adding a new file as being staged and ready to
   commit, implying that it's committed by adding it.
   3. It doesn't show that you can commit from the modified state without
   staging anything.

Additionally, mine doesn't show that you can remove something from being
staged instead of committing it. Insert a big grey line from right to left
at the bottom in your mind.

Try to avoid messes like this:

[image: Image]

It's easy to make an incomprehensible mess if you don't understand what
you're doing. So try to understand what your goal is before you try to do
something. Much like writing code SHOULD be, but often isn't. [1]

Fred.

[1] http://pragprog.com/the-pragmatic-programmer/extracts/coincidence

On Sat, Jul 27, 2013 at 11:44 PM, Arnaud Héritier wrote:

> I don't think we have many things on Maven project side and really few
> things on apache side
> About the workflow to use with git you have the well known successful
> branching model
> http://nvie.com/posts/a-successful-git-branching-model/
> At work I adapted / completed it for our internal usage (maybe we could do
> the same here)
> http://developer.exoplatform.org/docs/scm/git-workflow.html
>
> There are many cheat sheets and resources on internet, everyone writing its
> own when he starts with git :-)
> http://developer.exoplatform.org/docs/scm/git-cheatsheet.html
>
> Myself I really like these ones :
> http://www.ndpsoftware.com/git-cheatsheet.html
> http://pcottle.github.io/learnGitBranching/
>
> Cheers
>
>
> On Sat, Jul 27, 2013 at 10:30 PM, Barrie Treloar 
> wrote:
>
> > On 28 July 2013 00:24, Kristian Rosenvold 
> > wrote:
> > > It's ok if not pushed, but I think it should be made a lot clearer in
> > the guide.
> >
> > Do we have a "how to" guide for using Git?
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
>
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>

Re: Git resources was Re: [2/2] git commit: o change the scope of org.eclipse.sisu to test in the maven-aether-provider to prevent it from leaking out to clients.

2013-07-27 Thread Fred Cooke

Yes, I've been guilty of it from time to time, as most have been,
especially years ago ;-)

Did you find any of the above useful? I hope so :-)

Coincidental-Fred.

On Sun, Jul 28, 2013 at 12:26 AM, Barrie Treloar  wrote:

> On 28 July 2013 07:45, Fred Cooke  wrote:
> > [1] http://pragprog.com/the-pragmatic-programmer/extracts/coincidence
>
> Ahh I see they are using you as an example :)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Release Maven 3.1.1

2013-07-28 Thread Fred Cooke

+1 on pushing out regression-free fixes and moving forward.
+1 on frequent and small releases and moving forward.

On Sun, Jul 28, 2013 at 6:36 PM, Jason van Zyl  wrote:

> On Jul 28, 2013, at 12:25 PM, Hervé BOUTEMY  wrote:
>
> > I'd like to work on cd tonight
> >
> > so if you wait for tomorrow...
> >
>
> I don't really want to wait, why can't that just go in next week? You
> don't know how long it will take and I think we should just start releasing
> what we have.
>
> > notice there are 2 ITs failing on ASF's Jenkins because of a failure to
> find
> > artifacts that are available AFAIK in the local repo: I suppose I'm
> missing
> > something trivial in the configuration
> > Can you help me on this, please?
>
> The ITs need to work, I till take a look at report back.
>
> >
> > Regards,
> >
> > Hervé
> >
> > Le dimanche 28 juillet 2013 12:08:35 Jason van Zyl a écrit :
> >> I'd like to release Maven 3.1.1 and try to get the cadence revived for
> minor
> >> version releases by trying to release minor versions as frequently as
> there
> >> are fixes to make available.
> >>
> >> Just a couple simple fixes:
> >>
> >> [MNG-5499] maven-aether-provider leaks Sisu Plexus and ObjectWeb classes
> >> onto the classpath when they are not required [MNG-5495] API
> >> incompatibility causes Swagger Maven Plugin (and others) to fail under
> >> Maven 3.1.0
> >>
> >> But helps consumers of the Maven Aether Provider and plugin issues
> caused by
> >> incompatibilities with the converters. There are lots of other things to
> >> fix, but as they become available they can be released. If possible I'd
> >> just like to start releasing any fixes we have on a weekly basis.
> >>
> >> Any objections?
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> --
> >> Jason van Zyl
> >> Founder,  Apache Maven
> >> http://twitter.com/jvanzyl
> >> -
> >>
> >> A man enjoys his work when he understands the whole and when he
> >> is responsible for the quality of the whole
> >>
> >> -- Christopher Alexander, A Pattern Language
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
>
> People develop abstractions by generalizing from concrete examples.
> Every attempt to determine the correct abstraction on paper without
> actually developing a running system is doomed to failure. No one
> is that smart. A framework is a resuable design, so you develop it by
> looking at the things it is supposed to be a design of. The more examples
> you look at, the more general your framework will be.
>
>   -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
>
>
>
>
>
>
>

Re: Release Maven 3.1.1

2013-07-29 Thread Fred Cooke

Tag deleted? :-/

On Mon, Jul 29, 2013 at 3:37 PM, Jason van Zyl  wrote:

> Tag deleted, repository dropped, and now re-released and restaged.
>
> https://repository.apache.org/content/repositories/maven-034/
>
> On Jul 29, 2013, at 9:22 AM, Dennis Lundberg  wrote:
>
> > Yes, the loss of Maven 2.2.1 compatibility is critical IMO.
> >
> > On Mon, Jul 29, 2013 at 3:10 PM, Jason van Zyl  wrote:
> >> Is this critical for this release? I staged the release already?
> >>
> >> On Jul 29, 2013, at 5:39 AM, Dennis Lundberg 
> wrote:
> >>
> >>> Hi Jason
> >>>
> >>> I had a fix for MRRESOURCES-61 that I have committed to trunk now.
> >>>
> >>> When testing out the sample project that is in that issue I first had
> >>> problems running it with maven-remote-resources-plugin 1.5-SNAPSHOT on
> >>> Maven 2.2.1. After adding a missing dependency I got it working again.
> >>> It works fine with 1.4 though, so for that reason I think we need to
> >>> respin the release for maven-remote-resources-plugin. If you want to I
> >>> can take care of it.
> >>>
> >>>
> >>> The error I got was this:
> >>>
> >>> this realm =
> app0.child-container[org.apache.maven.plugins:maven-remote-resources-plugin:1.5-SNAPSHOT]
> >>> urls[0] =
> file:/C:/Users/dlg01/.m2/repository/org/apache/maven/plugins/maven-remote-resources-plugin/1.5-SNAPSHOT/maven-remote-resources-plugin-1.5-SNAPSHOT.jar
> >>> urls[1] =
> file:/C:/Users/dlg01/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> >>> ...
> >>>
> >>> [INFO] Internal error in the plugin manager executing goal
> >>>
> 'org.apache.maven.plugins:maven-remote-resources-plugin:1.5-SNAPSHOT:process':
> >>> Unable to load the mojo
> >>>
> 'org.apache.maven.plugins:maven-remote-resources-plugin:1.5-SNAPSHOT:process'
> >>> in the plugin 'org.apache.maven.plugins:maven-remote-resources-plugin'.
> >>> A required class is missing: org/codehaus/plexus/util/Scanner
> >>>
> >>> The Scanner class wasn't added to plexus-utils until version 1.5.8, so
> >>> using the default version 1.1 won't work.
> >>>
> >>>
> >>> On Mon, Jul 29, 2013 at 1:04 AM, Jason van Zyl  wrote:
>  I staged a release of the remote resources plugin for anyone who
> wants to try:
> 
>  https://repository.apache.org/content/repositories/maven-030/
> 
>  How about we do a simultaneous release vote for the core and the
> remote resources plugin?
> 
>  On Jul 28, 2013, at 3:56 PM, Dennis Lundberg 
> wrote:
> 
> > Hi,
> >
> > There is currently a SNAPSHOT dependency on
> maven-remote-resources-plugin.
> > This was done in this commit by Daniel to improve the LICENCE file:
> >
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=b4dc8931f2cc7b56302df78c03a7db57211cd3a7
> >
> > The question is whether we need to push out a release of that plugin
> > prior to releasing Maven 3.1.1?
> >
> >
> > I just made a small commit, adding a missing license header in a test
> > xml file. Since I don't speak git very well yet, could someone make
> > sure I did it correctly?
> >
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=a58b91819c42c0a5a8616dc5562ba42287fa0f24
> >
> > On Sun, Jul 28, 2013 at 6:08 PM, Jason van Zyl 
> wrote:
> >> I'd like to release Maven 3.1.1 and try to get the cadence revived
> for minor version releases by trying to release minor versions as
> frequently as there are fixes to make available.
> >>
> >> Just a couple simple fixes:
> >>
> >> [MNG-5499] maven-aether-provider leaks Sisu Plexus and ObjectWeb
> classes onto the classpath when they are not required
> >> [MNG-5495] API incompatibility causes Swagger Maven Plugin (and
> others) to fail under Maven 3.1.0
> >>
> >> But helps consumers of the Maven Aether Provider and plugin issues
> caused by incompatibilities with the converters. There are lots of other
> things to fix, but as they become available they can be released. If
> possible I'd just like to start releasing any fixes we have on a weekly
> basis.
> >>
> >> Any objections?
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> --
> >> Jason van Zyl
> >> Founder,  Apache Maven
> >> http://twitter.com/jvanzyl
> >> -
> >>
> >> A man enjoys his work when he understands the whole and when he
> >> is responsible for the quality of the whole
> >>
> >> -- Christopher Alexander, A Pattern Language
> >>
> >>
> >>
> >>
> >>
> >>
> >
> > --
> > Dennis Lundberg
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> 
>  Thanks,
> 
>  Jason
> 
>

Re: Release Maven 3.1.1

2013-07-29 Thread Fred Cooke

Nope, I sent it directly to you to avoid noise on the list, but if you
insist on being a  and spamming everyone, so be it.

On Mon, Jul 29, 2013 at 4:06 PM, Baptiste MATHUS  wrote:

> 2013/7/29 Fred Cooke 
>
> > On Mon, Jul 29, 2013 at 3:57 PM, Baptiste MATHUS  wrote:
> >
> >> 2013/7/29 Fred Cooke 
> >>
> >> > Tag deleted? :-/
> >> >
> >>
> >> Wasn't it already discussed? Are you going to endlessly send that same
> >> email here?
> >>
> >
> > No, I'm going to spice it up a little each time, just for you.
> >
>
> Wrong reply I guess.
>

Re: Release Maven 3.1.1

2013-07-29 Thread Fred Cooke

Jason, there seems to be no trace of either the new or old tag for 3.1.1 on
either ASF server or github. Did you push it? Did you not push it on
purpose?

What are your plans for tags until the release plugin is updated to allow
creation of suffixed tags during the release to be supplemented by a final
tag at publish time as discussed previously?

I was hoping to document the hash of the new tag such that if it fails
again, I can diff between old and new next time to avoid reviewing more
than necessary or potentially missing something. Removing old tags (without
having published the hash of them) breaks anyone's ability to do that in a
secure and reliable way.

I see no sign of the latest release of 3.1.1 in either the github mirror or
the upstream @ ASF. Not on master, nor in a branch. Have you published the
commits from the 3.1.1 release process at all?

And to top it off, the github repo still has the 3.1 and 3.1.0 tags in it.
I now have both here locally, which is a lot better than I can say for
3.1.1, but a bit of a clue about the whole tag deleting thing... once
published, they're out there, don't mess with them.

Please advise on what you've been doing and what you plan to do. I don't
grok it and can't find the source at all.

Regards,

Rot13:vroo AKA rot13:froo AKA Fred. [1][2]

[1] http://www.urbandictionary.com/define.php?term=Froo&defid=4078003
[2] You're hilarious, Stephen! :-p :-)

On Mon, Jul 29, 2013 at 3:37 PM, Jason van Zyl  wrote:

> Tag deleted, repository dropped, and now re-released and restaged.
>
> https://repository.apache.org/content/repositories/maven-034/
>
> On Jul 29, 2013, at 9:22 AM, Dennis Lundberg  wrote:
>
> > Yes, the loss of Maven 2.2.1 compatibility is critical IMO.
> >
> > On Mon, Jul 29, 2013 at 3:10 PM, Jason van Zyl  wrote:
> >> Is this critical for this release? I staged the release already?
> >>
> >> On Jul 29, 2013, at 5:39 AM, Dennis Lundberg 
> wrote:
> >>
> >>> Hi Jason
> >>>
> >>> I had a fix for MRRESOURCES-61 that I have committed to trunk now.
> >>>
> >>> When testing out the sample project that is in that issue I first had
> >>> problems running it with maven-remote-resources-plugin 1.5-SNAPSHOT on
> >>> Maven 2.2.1. After adding a missing dependency I got it working again.
> >>> It works fine with 1.4 though, so for that reason I think we need to
> >>> respin the release for maven-remote-resources-plugin. If you want to I
> >>> can take care of it.
> >>>
> >>>
> >>> The error I got was this:
> >>>
> >>> this realm =
> app0.child-container[org.apache.maven.plugins:maven-remote-resources-plugin:1.5-SNAPSHOT]
> >>> urls[0] =
> file:/C:/Users/dlg01/.m2/repository/org/apache/maven/plugins/maven-remote-resources-plugin/1.5-SNAPSHOT/maven-remote-resources-plugin-1.5-SNAPSHOT.jar
> >>> urls[1] =
> file:/C:/Users/dlg01/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> >>> ...
> >>>
> >>> [INFO] Internal error in the plugin manager executing goal
> >>>
> 'org.apache.maven.plugins:maven-remote-resources-plugin:1.5-SNAPSHOT:process':
> >>> Unable to load the mojo
> >>>
> 'org.apache.maven.plugins:maven-remote-resources-plugin:1.5-SNAPSHOT:process'
> >>> in the plugin 'org.apache.maven.plugins:maven-remote-resources-plugin'.
> >>> A required class is missing: org/codehaus/plexus/util/Scanner
> >>>
> >>> The Scanner class wasn't added to plexus-utils until version 1.5.8, so
> >>> using the default version 1.1 won't work.
> >>>
> >>>
> >>> On Mon, Jul 29, 2013 at 1:04 AM, Jason van Zyl  wrote:
>  I staged a release of the remote resources plugin for anyone who
> wants to try:
> 
>  https://repository.apache.org/content/repositories/maven-030/
> 
>  How about we do a simultaneous release vote for the core and the
> remote resources plugin?
> 
>  On Jul 28, 2013, at 3:56 PM, Dennis Lundberg 
> wrote:
> 
> > Hi,
> >
> > There is currently a SNAPSHOT dependency on
> maven-remote-resources-plugin.
> > This was done in this commit by Daniel to improve the LICENCE file:
> >
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=b4dc8931f2cc7b56302df78c03a7db57211cd3a7
> >
> > The question is whether we need to push out a release of that plugin
> > prior to releasing Maven 3.1.1?
> >
> >
> > I just made a small commit, adding a missing license header in a test
> > xml file. Since I don't speak git very well yet, could someone make
> > sure I did it correctly?
> >
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=a58b91819c42c0a5a8616dc5562ba42287fa0f24
> >
> > On Sun, Jul 28, 2013 at 6:08 PM, Jason van Zyl 
> wrote:
> >> I'd like to release Maven 3.1.1 and try to get the cadence revived
> for minor version releases by trying to release minor versions as
> frequently as there are fixes to make available.
> >>
> >> Just a couple simple fixes:
> >>
> >> [MNG-5499] maven-aether-provider leaks Sisu Plexus and ObjectWeb

Re: Release Maven 3.1.1

2013-07-29 Thread Fred Cooke

<3 isn't sufficient, but this is:
http://stuff.fredcooke.com/throbbing.heart.gif

Quality from the top, I like it.

Fred/vroo.

On Mon, Jul 29, 2013 at 6:18 PM, Jason van Zyl  wrote:

> I was referring to the remote resources plugin which is associated with
> the 3.1.1 release.
>
> I have not attempted to release 3.1.1 and I have not sent out any release
> vote. I do intend to add what Sebb suggested by adding the revision.
>
> On Jul 29, 2013, at 12:02 PM, Fred Cooke  wrote:
>
> > Jason, there seems to be no trace of either the new or old tag for 3.1.1
> on
> > either ASF server or github. Did you push it? Did you not push it on
> > purpose?
> >
> > What are your plans for tags until the release plugin is updated to allow
> > creation of suffixed tags during the release to be supplemented by a
> final
> > tag at publish time as discussed previously?
> >
> > I was hoping to document the hash of the new tag such that if it fails
> > again, I can diff between old and new next time to avoid reviewing more
> > than necessary or potentially missing something. Removing old tags
> (without
> > having published the hash of them) breaks anyone's ability to do that in
> a
> > secure and reliable way.
> >
> > I see no sign of the latest release of 3.1.1 in either the github mirror
> or
> > the upstream @ ASF. Not on master, nor in a branch. Have you published
> the
> > commits from the 3.1.1 release process at all?
> >
> > And to top it off, the github repo still has the 3.1 and 3.1.0 tags in
> it.
> > I now have both here locally, which is a lot better than I can say for
> > 3.1.1, but a bit of a clue about the whole tag deleting thing... once
> > published, they're out there, don't mess with them.
> >
> > Please advise on what you've been doing and what you plan to do. I don't
> > grok it and can't find the source at all.
> >
> > Regards,
> >
> > Rot13:vroo AKA rot13:froo AKA Fred. [1][2]
> >
> > [1] http://www.urbandictionary.com/define.php?term=Froo&defid=4078003
> > [2] You're hilarious, Stephen! :-p :-)
> >
> > On Mon, Jul 29, 2013 at 3:37 PM, Jason van Zyl  wrote:
> >
> >> Tag deleted, repository dropped, and now re-released and restaged.
> >>
> >> https://repository.apache.org/content/repositories/maven-034/
> >>
> >> On Jul 29, 2013, at 9:22 AM, Dennis Lundberg 
> wrote:
> >>
> >>> Yes, the loss of Maven 2.2.1 compatibility is critical IMO.
> >>>
> >>> On Mon, Jul 29, 2013 at 3:10 PM, Jason van Zyl  wrote:
> >>>> Is this critical for this release? I staged the release already?
> >>>>
> >>>> On Jul 29, 2013, at 5:39 AM, Dennis Lundberg 
> >> wrote:
> >>>>
> >>>>> Hi Jason
> >>>>>
> >>>>> I had a fix for MRRESOURCES-61 that I have committed to trunk now.
> >>>>>
> >>>>> When testing out the sample project that is in that issue I first had
> >>>>> problems running it with maven-remote-resources-plugin 1.5-SNAPSHOT
> on
> >>>>> Maven 2.2.1. After adding a missing dependency I got it working
> again.
> >>>>> It works fine with 1.4 though, so for that reason I think we need to
> >>>>> respin the release for maven-remote-resources-plugin. If you want to
> I
> >>>>> can take care of it.
> >>>>>
> >>>>>
> >>>>> The error I got was this:
> >>>>>
> >>>>> this realm =
> >>
> app0.child-container[org.apache.maven.plugins:maven-remote-resources-plugin:1.5-SNAPSHOT]
> >>>>> urls[0] =
> >>
> file:/C:/Users/dlg01/.m2/repository/org/apache/maven/plugins/maven-remote-resources-plugin/1.5-SNAPSHOT/maven-remote-resources-plugin-1.5-SNAPSHOT.jar
> >>>>> urls[1] =
> >>
> file:/C:/Users/dlg01/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> >>>>> ...
> >>>>>
> >>>>> [INFO] Internal error in the plugin manager executing goal
> >>>>>
> >>
> 'org.apache.maven.plugins:maven-remote-resources-plugin:1.5-SNAPSHOT:process':
> >>>>> Unable to load the mojo
> >>>>>
> >>
> 'org.apache.maven.plugins:maven-remote-resources-plugin:1.5-SNAPSHOT:process'
> >>>>> in the plugin
> 'org.apache.maven.plugins:maven-remote-resources-plugin'.

Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)

2013-08-02 Thread Fred Cooke

Are definitions of cat A and  B and others listed anywhere? I searched but
failed.

I assume Cat A = permissive and Cat B = copyleft? or?

On Fri, Aug 2, 2013 at 6:54 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Correct. And it would be subject to the same CTR and potential veto if Cat
> A. If Cat B and being added to core then you'd have a mandatory vote by the
> PMC where the majority *of the whole PMC* are required to approve.
>
> The rational being, a Cat A licensed dependency can always be forked into
> Maven if we need to.
>
> On Friday, 2 August 2013, Igor Fedorenko wrote:
>
> > Is this really specific to PMC? Can't a regular developer like myself do
> > the same, i.e. setup a project elsewhere, then commit  to
> > maven core?
> >
> > --
> > Regards,
> > Igor
> >
> > On 2013-08-02 8:29 PM, Paul Benedict wrote:
> >
> > I've stated from the beginning of this thread that it's impossible to
> > prevent someone from developing outside of Apache. I stand by that still.
> > That can't be prevented and any attempt will fail since it's not
> practical.
> >
> > If my words today aren't clear, I'll try again. My stance isn't about
> > halting developing elsewhere, but to halt what I (and maybe some others)
> > perceive as a way of getting around the Apache community.
> >
> > I won't use your "ultra whizzbang high performance logging" :-) example
> > because it doesn't fit what my concern; but imagine an existing component
> > (I won't name any) that is critical and Maven's existence and Maven can't
> > function without it. It's very easy for any PMC member to go to another
> OSS
> > community, develop it, and then kind of leave the other PMCs with no real
> > "choice" but to use it because the code realizes the future of Maven.
> Those
> > other PMCs are really backed into a corner; they have no real recourse to
> > preventing this, lest Maven development is simply halted altogether. The
> > other OSS community has other committers, other mailing lists, other
> > deliberations, etc. Community work and input becomes marginalized here.
> >
> > Does this make sense to you? That kind of community-splitting effort
> needs
> > to stop and that's what I am trying to address.
> >
> > Cheers,
> > Paul
> >
> >
> >
> > On Fri, Aug 2, 2013 at 11:10 AM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> >  We cannot stop somebody from developing something outside of Apache.
> >
> > So I could go off and write a High Performance Logging API... now I could
> > be doing that because I want to foist that Logging API on Maven... or I
> > could be doing it as an experiment that, if successful, I may offer for
> > Maven to consume... or I could be doing it because I need it for my Day
> > Job...
> >
> > We cannot know the reasons why somebody is doing something outside of
> > Maven... we can ask, but we cannot *know* if the answer we are given is
> > truthful.
> >
> > So anyway, I now have this ultra whizzbang high performance logging API
> and
> > I am aware of some deficit in the logging performance of Maven, so I spin
> > up a private fork (it could be a hidden private fork, or it could be a
> > public one... doesn't matter) and integrate the logging API and low and
> > behold I see a whopping X% improvement... so I want to bring that back to
> > Maven...
> >
> > Is there anything wrong with the above?
> >
> > If the library I created is under a Category A license and open source
> and
> > I go with CTR and nobody vetos my commit... we have consensus... why do
> we
> > need to go all Iron Fist and require a vote?
> >
> > We already have established tools: review of commits, vetos on commits,
> > mandatory votes for Category B dependencies...
> >
> > Do we really need *more* processes and procedures to follow?
> >
> > On 2 August 2013 16:51, Paul Benedict  wrote:
> >
> >  I don't understand the iron hand analogy. I was expressing the use of a
> > vote to allow or disallow critical development outside of Apache. The
> >
> > vote
> >
> > would lead to a consensus, no?
> >
> >
> > On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> >  On 2 August 2013 16:32, Paul Benedict  wrote:
> >
> >  Furthermore, I'd like to see explicit procedural rules on Maven Core
> >
> > and
> >
> > forking. For example, if there's a critical component needing
> >
> > development
> >
> > for Core, and a PMC expresses that such development will be done
> >
> > outside
> >
> > of
> >
> > --**--**-
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> Sent from my phone
>

Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)

2013-08-02 Thread Fred Cooke

Thanks for the terms. I had used "apache license categories" and some other
variations.

I assume you mean this:
http://www.apache.org/legal/3party.html#criteriaandcategories

If so, is there an accepted version, other than this merely proposed
version?

Fred.

On Fri, Aug 2, 2013 at 7:39 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Google: Apache third party licenses
>
> Should work on lucky... Or look at the head revision where I added the
> link.
>
> There is a 3rd category: Category X... Eg GPL, which we are not allowed to
> use
>
> On Friday, 2 August 2013, Fred Cooke wrote:
>
> > Are definitions of cat A and  B and others listed anywhere? I searched
> but
> > failed.
> >
> > I assume Cat A = permissive and Cat B = copyleft? or?
> >
> > On Fri, Aug 2, 2013 at 6:54 PM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > Correct. And it would be subject to the same CTR and potential veto if
> > Cat
> > > A. If Cat B and being added to core then you'd have a mandatory vote by
> > the
> > > PMC where the majority *of the whole PMC* are required to approve.
> > >
> > > The rational being, a Cat A licensed dependency can always be forked
> into
> > > Maven if we need to.
> > >
> > > On Friday, 2 August 2013, Igor Fedorenko wrote:
> > >
> > > > Is this really specific to PMC? Can't a regular developer like myself
> > do
> > > > the same, i.e. setup a project elsewhere, then commit  to
> > > > maven core?
> > > >
> > > > --
> > > > Regards,
> > > > Igor
> > > >
> > > > On 2013-08-02 8:29 PM, Paul Benedict wrote:
> > > >
> > > > I've stated from the beginning of this thread that it's impossible to
> > > > prevent someone from developing outside of Apache. I stand by that
> > still.
> > > > That can't be prevented and any attempt will fail since it's not
> > > practical.
> > > >
> > > > If my words today aren't clear, I'll try again. My stance isn't about
> > > > halting developing elsewhere, but to halt what I (and maybe some
> > others)
> > > > perceive as a way of getting around the Apache community.
> > > >
> > > > I won't use your "ultra whizzbang high performance logging" :-)
> example
> > > > because it doesn't fit what my concern; but imagine an existing
> > component
> > > > (I won't name any) that is critical and Maven's existence and Maven
> > can't
> > > > function without it. It's very easy for any PMC member to go to
> another
> > > OSS
> > > > community, develop it, and then kind of leave the other PMCs with no
> > real
> > > > "choice" but to use it because the code realizes the future of Maven.
> > > Those
> > > > other PMCs are really backed into a corner; they have no real
> recourse
> > to
> > > > preventing this, lest Maven development is simply halted altogether.
> > The
> > > > other OSS community has other committers, other mailing lists, other
> > > > deliberations, etc. Community work and input becomes marginalized
> here.
> > > >
> > > > Does this make sense to you? That kind of community-splitting effort
> > > needs
> > > > to stop and that's what I am trying to address.
> > > >
> > > > Cheers,
> > > > Paul
> > > >
> > > >
> > > >
> > > > On Fri, Aug 2, 2013 at 11:10 AM, Stephen Connolly <
> > > > stephen.alan.conno...@gmail.com> wrote:
> > > >
> > > >  We cannot stop somebody from developing something outside of Apache.
> > > >
> > > > So I could go off and write a High Performance Logging API... now I
> > could
> > > > be doing that because I want to foist that Logging API on Maven...
> or I
> > > > could be doing it as an experiment that, if successful, I may offer
> for
> > > > Maven to consume... or I could be doing it because I need it for my
> Day
> > > > Job...
> > > >
> > > > We cannot know the reasons why somebody is doing something outside of
> > > > Maven... we can ask, but we cannot *know* if the answer we are given
> is
> > > > truthful.
> > > >
> > > &

Re: What is the correct Git SCM URL for a branch?

2013-08-10 Thread Fred Cooke

Please keep such information leakage optional. The editing of, and indeed
adding of, the "tag" element by the release plugin should already be
optional IMO. Especially if it breaks formatting of the POM, which it does
in some cases, at least. And yeah, I know why, and I know it's not a
trivial fix. (Thanks to Robert for educating me many months ago).

On Sat, Aug 10, 2013 at 2:54 PM, Olivier Lamy  wrote:

> On 10 August 2013 21:12, Dennis Lundberg  wrote:
> > Hi,
> >
> > I'm looking at the sources for Maven core in Git, which I'm learning
> > as I go along.
> >
> > "master" is at version 3.1.1-SNAPSHOT and has this in its pom.xml
> >   
> > scm:git:
> https://git-wip-us.apache.org/repos/asf/maven.git
> > scm:git:
> https://git-wip-us.apache.org/repos/asf/maven.git
> > https://git-wip-us.apache.org/repos/asf?p=maven.git
> > HEAD
> >   
> >
> > The head "maven-3.0.x" is at version 3.0.6-SNAPSHOT and has this in its
> pom.xml
> >   
> > scm:git:
> https://git-wip-us.apache.org/repos/asf/maven.git
> > scm:git:
> https://git-wip-us.apache.org/repos/asf/maven.git
> > https://git-wip-us.apache.org/repos/asf?p=maven.git
> > HEAD
> >   
> >
> > Since this is identical to what is in "master" I don't think this
> > would work if you tried to do a release using the Release Plugin.
> > Wouldn't that release what is specified in  i.e. "HEAD". Now, I
> > have looked through our documentation and used Google to find a
> > solution, but to no avail. From what I have gathered we should change
> > the value of , but to what? Would it involve
> > "ref/heads/maven-3.0.x"?
> >
> > The head "maven-2.2.x" is at version 2.2.2-RC1-SNAPSHOT and has this
> > in its pom.xml
> >   
> > scm:svn:
> http://svn.apache.org/repos/asf/maven/maven-2/branches/maven-2.2.x
> 
> > scm:svn:
> https://svn.apache.org/repos/asf/maven/maven-2/branches/maven-2.2.x
> 
> > http://svn.apache.org/viewvc/maven/maven-2/branches/maven-2.2.x
> 
> >   
> >
> > Obviously this has not been updated since the move to Git, which is
> > one of the things I'm trying to fix.
>
> scm url will be the same for all branches.
> It simply depend of the branch you are working on locally.
> btw the HEAD in maven-3.0.x branch is wrong.
> IHMO It's something to improve in the release plugin to put here the
> current branch in use.
>
> >
> > Hopefully someone who has made a release using Maven Release Plugin
> > from a Git branch can shed some light on this.
> >
> > --
> > Dennis Lundberg
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
>
> --
> Olivier Lamy
> Ecetera: http://ecetera.com.au
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: What is the correct Git SCM URL for a branch?

2013-08-10 Thread Fred Cooke

Convention over configuration is fine. Dictatorships end badly. Make it the
convention, and allow it to be configured off. This is where Maven has
always failed from time to time, especially in the old days. The less it's
true, the better.

On Sat, Aug 10, 2013 at 3:13 PM, Olivier Lamy  wrote:

> On 10 August 2013 23:06, Fred Cooke  wrote:
> > Please keep such information leakage optional. The editing of, and indeed
> > adding of, the "tag" element by the release plugin should already be
> > optional IMO.
>
> Why?
> With such information I know which tag has been used to build
> artifacts. (
> http://repo.maven.apache.org/maven2/org/apache/maven/maven/3.0.5/maven-3.0.5.pom
> )
> Without this it's not possible with only the git url.
> For people/tools using scm informations for rebuilding packages etc..
> it can be very interesting.
>
>
> >Especially if it breaks formatting of the POM, which it does
> > in some cases, at least. And yeah, I know why, and I know it's not a
> > trivial fix. (Thanks to Robert for educating me many months ago).
> >
> > On Sat, Aug 10, 2013 at 2:54 PM, Olivier Lamy  wrote:
> >
> >> On 10 August 2013 21:12, Dennis Lundberg  wrote:
> >> > Hi,
> >> >
> >> > I'm looking at the sources for Maven core in Git, which I'm learning
> >> > as I go along.
> >> >
> >> > "master" is at version 3.1.1-SNAPSHOT and has this in its pom.xml
> >> >   
> >> > scm:git:
> >> https://git-wip-us.apache.org/repos/asf/maven.git
> >> > scm:git:
> >> https://git-wip-us.apache.org/repos/asf/maven.git
> >> > https://git-wip-us.apache.org/repos/asf?p=maven.git
> >> > HEAD
> >> >   
> >> >
> >> > The head "maven-3.0.x" is at version 3.0.6-SNAPSHOT and has this in
> its
> >> pom.xml
> >> >   
> >> > scm:git:
> >> https://git-wip-us.apache.org/repos/asf/maven.git
> >> > scm:git:
> >> https://git-wip-us.apache.org/repos/asf/maven.git
> >> > https://git-wip-us.apache.org/repos/asf?p=maven.git
> >> > HEAD
> >> >   
> >> >
> >> > Since this is identical to what is in "master" I don't think this
> >> > would work if you tried to do a release using the Release Plugin.
> >> > Wouldn't that release what is specified in  i.e. "HEAD". Now, I
> >> > have looked through our documentation and used Google to find a
> >> > solution, but to no avail. From what I have gathered we should change
> >> > the value of , but to what? Would it involve
> >> > "ref/heads/maven-3.0.x"?
> >> >
> >> > The head "maven-2.2.x" is at version 2.2.2-RC1-SNAPSHOT and has this
> >> > in its pom.xml
> >> >   
> >> > scm:svn:
> >> http://svn.apache.org/repos/asf/maven/maven-2/branches/maven-2.2.x
> >> 
> >> > scm:svn:
> >> https://svn.apache.org/repos/asf/maven/maven-2/branches/maven-2.2.x
> >> 
> >> > 
> http://svn.apache.org/viewvc/maven/maven-2/branches/maven-2.2.x
> >> 
> >> >   
> >> >
> >> > Obviously this has not been updated since the move to Git, which is
> >> > one of the things I'm trying to fix.
> >>
> >> scm url will be the same for all branches.
> >> It simply depend of the branch you are working on locally.
> >> btw the HEAD in maven-3.0.x branch is wrong.
> >> IHMO It's something to improve in the release plugin to put here the
> >> current branch in use.
> >>
> >> >
> >> > Hopefully someone who has made a release using Maven Release Plugin
> >> > from a Git branch can shed some light on this.
> >> >
> >> > --
> >> > Dennis Lundberg
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> > For additional commands, e-mail: dev-h...@maven.apache.org
> >> >
> >>
> >>
> >>
> >> --
> >> Olivier Lamy
> >> Ecetera: http://ecetera.com.au
> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
>
>
>
> --
> Olivier Lamy
> Ecetera: http://ecetera.com.au
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: What is the correct Git SCM URL for a branch?

2013-08-10 Thread Fred Cooke

Are you sure it's not using the src package uploaded in parallel with the
binary jar? This was my understanding. Doing it from SCM would be a mine
field at best. I know it gets javadocs this way, assumed source was the
same.

On Sat, Aug 10, 2013 at 9:20 PM, Arnaud Héritier wrote:

> AFAIR in eclipse m2e ( I don't use it anymore ) you can checkout the
> code of any maven dependency/project (materialize feature). I'm almost
> sure that it is using informations from SCM part in the POM to do it.
> I think it isn't the only usage of it. I'm not 100% satisfied of this
> usage because such information can change in the future (imagine a SVN
> -> git migration or any change in the scm hosting of a project - URL
> ...)
>
> -
> Arnaud
>
> Le 10 août 2013 à 20:02, Mark Struberg  a écrit :
>
> > I found that most people use
> > false and
> > true
> >
> > Which renders most of the  stuff useless in GIT.
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> > - Original Message -
> >> From: Fred Cooke 
> >> To: Maven Developers List 
> >> Cc:
> >> Sent: Saturday, 10 August 2013, 15:19
> >> Subject: Re: What is the correct Git SCM URL for a branch?
> >>
> >> Convention over configuration is fine. Dictatorships end badly. Make it
> the
> >> convention, and allow it to be configured off. This is where Maven has
> >> always failed from time to time, especially in the old days. The less
> it's
> >> true, the better.
> >>
> >> On Sat, Aug 10, 2013 at 3:13 PM, Olivier Lamy  wrote:
> >>
> >>> On 10 August 2013 23:06, Fred Cooke  wrote:
> >>>> Please keep such information leakage optional. The editing of, and
> >> indeed
> >>>> adding of, the "tag" element by the release plugin should
> >> already be
> >>>> optional IMO.
> >>>
> >>> Why?
> >>> With such information I know which tag has been used to build
> >>> artifacts. (
> >>
> http://repo.maven.apache.org/maven2/org/apache/maven/maven/3.0.5/maven-3.0.5.pom
> >>> )
> >>> Without this it's not possible with only the git url.
> >>> For people/tools using scm informations for rebuilding packages etc..
> >>> it can be very interesting.
> >>>
> >>>
> >>>> Especially if it breaks formatting of the POM, which it does
> >>>> in some cases, at least. And yeah, I know why, and I know it's not
> >> a
> >>>> trivial fix. (Thanks to Robert for educating me many months ago).
> >>>>
> >>>> On Sat, Aug 10, 2013 at 2:54 PM, Olivier Lamy 
> >> wrote:
> >>>>
> >>>>> On 10 August 2013 21:12, Dennis Lundberg
> >>  wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> I'm looking at the sources for Maven core in Git, which
> >> I'm learning
> >>>>>> as I go along.
> >>>>>>
> >>>>>> "master" is at version 3.1.1-SNAPSHOT and has this
> >> in its pom.xml
> >>>>>>
> >>>>>>  scm:git:
> >> https://git-wip-us.apache.org/repos/asf/maven.git
> >>>>>>  scm:git:
> >> https://git-wip-us.apache.org/repos/asf/maven.git
> >> https://git-wip-us.apache.org/repos/asf?p=maven.git
> >>>>>>  HEAD
> >>>>>>
> >>>>>>
> >>>>>> The head "maven-3.0.x" is at version 3.0.6-SNAPSHOT
> >> and has this in
> >>> its
> >>>>> pom.xml
> >>>>>>
> >>>>>>  scm:git:
> >> https://git-wip-us.apache.org/repos/asf/maven.git
> >>>>>>  scm:git:
> >> https://git-wip-us.apache.org/repos/asf/maven.git
> >> https://git-wip-us.apache.org/repos/asf?p=maven.git
> >>>>>>  HEAD
> >>>>>>
> >>>>>>
> >>>>>> Since this is identical to what is in "master" I
> >> don't think this
> >>>>>> would work if you tried to do a release using the Release
> >> Plugin.
> >>>>>> Wouldn't that release what is specified in 
> >> i.e. "HEAD". Now, I
> >>>>>> have lo

Re: [VOTE] Release Apache Maven Model Converter version 2.3

2013-08-13 Thread Fred Cooke

Where, and also when; don't forget that. This is old news, but a pat on
sebb's back for beating the stick regardless of how much it seems to
irritate everyone to hear that noise.

On Tue, Aug 13, 2013 at 7:58 PM, Dennis Lundberg  wrote:

> On Tue, Aug 13, 2013 at 12:30 AM, sebb  wrote:
> > On 12 August 2013 20:10, Jason van Zyl  wrote:
> >>
> 
>  I have now read the threads that are referring to, and have not found
>  a single link to any ASF rule stating that we need to include these
>  things in a VOTE thread.
> >>>
> >>> So how do you propose that reviewers check the provenance of the files
> >>> in the source release?
> >>
> >> Are you looking for files that are in a distribution that didn't come
> from source control? Everything else as far as provenance goes is covered.
> Errant content is a potential problem, but everything in a distribution
> should come from source control which no one has access to until they have
> a signed CLA on file.
> >
> > Yes. That is where the whole saga started.
> >
> > Proving provenance is why the SCM coordinates are needed for the vote.
> >
> > The SCM details may also be useful to discover files accidentally
> > omitted from the source archive.
>
> You want to compare the contents of the *-source-release.zip with
> something from SCM, to make nothing bad has crept into the source
> bundle. So you need to know where in SCM you can find it. Have I
> understood you correctly?
>
> >> Thanks,
> >>
> >> Jason
> >>
> >> --
> >> Jason van Zyl
> >> Founder,  Apache Maven
> >> http://twitter.com/jvanzyl
> >> -
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
>
> --
> Dennis Lundberg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Surefire Plugin version 2.16

2013-08-14 Thread Fred Cooke

Just saw your tag, BIG +1 for me, on no basis other than you seem to care
about the quality of your work.

On Wed, Aug 14, 2013 at 6:03 PM, Andreas Gudian wrote:

> Anyone?
>
> If I can't collect the results today, I won't be able to do it for another
> week or so.
>
> Am Sonntag, 11. August 2013 schrieb Andreas Gudian :
>
> > Hi,
> >
> > We solved 13 issues:
> >
> >
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&version=19331
> >
> > This release addresses some serious problems with character encodings in
> > the test report XML files and adds a new Parallel Computer implementation
> > to the JUnit 4.7+ provider, offering a bunch of new options and features
> > around in-process parallel execution (submitted by Tibor17, thanks
> again!).
> >
> > There are still lots of issues left in JIRA:
> >
> >
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-085
> >
> >
> https://repository.apache.org/content/repositories/maven-085/org/apache/maven/plugins/maven-surefire-plugin/2.16/maven-surefire-plugin-2.16-sources.jar
> >
> >
> https://repository.apache.org/content/repositories/maven-085/org/apache/maven/plugins/maven-failsafe-plugin/2.16/maven-failsafe-plugin-2.16-sources.jar
> > Source: https://git-wip-us.apache.org/repos/asf/maven-surefire.git tag
> > surefire-2.16_vote-1
> >
> > Staging site:
> >
> >
> http://maven.apache.org/surefire-archives/maven-surefire-2.16/maven-surefire-plugin/index.html
> >
> >
> http://maven.apache.org/surefire-archives/maven-surefire-2.16/maven-failsafe-plugin/index.html
> >
> >
> http://maven.apache.org/surefire-archives/maven-surefire-2.16/maven-surefire-report-plugin/index.html
> >
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
>

Re: [VOTE] Release Apache Maven Model Converter version 2.3

2013-08-14 Thread Fred Cooke

It's NOT trolling... If you feel trolled, grow some skin.

On Thu, Aug 15, 2013 at 1:24 AM, Olivier Lamy  wrote:

> On 15 August 2013 08:53, sebb  wrote:
> > On 14 August 2013 21:21, Dennis Lundberg  wrote:
> >> On Wed, Aug 14, 2013 at 10:47 AM, sebb  wrote:
> >>
> >>> On 13 August 2013 18:58, Dennis Lundberg  wrote:
> >>> > On Tue, Aug 13, 2013 at 12:30 AM, sebb  wrote:
> >>> >> On 12 August 2013 20:10, Jason van Zyl  wrote:
> >>> >>>
> >>> >
> >>> > I have now read the threads that are referring to, and have not
> found
> >>> > a single link to any ASF rule stating that we need to include
> these
> >>> > things in a VOTE thread.
> >>> 
> >>>  So how do you propose that reviewers check the provenance of the
> files
> >>>  in the source release?
> >>> >>>
> >>> >>> Are you looking for files that are in a distribution that didn't
> come
> >>> from source control? Everything else as far as provenance goes is
> covered.
> >>> Errant content is a potential problem, but everything in a distribution
> >>> should come from source control which no one has access to until they
> have
> >>> a signed CLA on file.
> >>> >>
> >>> >> Yes. That is where the whole saga started.
> >>> >>
> >>> >> Proving provenance is why the SCM coordinates are needed for the
> vote.
> >>> >>
> >>> >> The SCM details may also be useful to discover files accidentally
> >>> >> omitted from the source archive.
> >>> >
> >>> > You want to compare the contents of the *-source-release.zip with
> >>> > something from SCM, to make nothing bad has crept into the source
> >>> > bundle. So you need to know where in SCM you can find it. Have I
> >>> > understood you correctly?
> >>>
> >>> It's vital to be able to link the files in the source release
> >>> archive(s) to their origin in SCM.
> >>>
> >>> The provenance of any source files the ASF releases must be clearly
> >>> traceable.
> >>>
> >>
> >> This information is clearly traceable and available to anyone who wants
> to
> >> review a release made by the Maven project. Our process uses the Release
> >> Plugin, which will put the POM from the SCM tag in the staging directory
> >> along with the source-release.zip. In that POM wou will find the URL to
> the
> >> original sources in SCM.
> >>
> >
> > As has already been pointed out, SVN tags are not immutable, so the
> > tag name alone is not sufficient.
>
> I think Stephen perfectly sum up the situation.
> If you're not happy follow that.
>
> But please STOP the troll!
>
> Thanks!
>
>
> >
> >>
> >>>
> >>> >>> Thanks,
> >>> >>>
> >>> >>> Jason
> >>> >>>
> >>> >>> --
> >>> >>> Jason van Zyl
> >>> >>> Founder,  Apache Maven
> >>> >>> http://twitter.com/jvanzyl
> >>> >>> -
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>
> >>> >>
> -
> >>> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Dennis Lundberg
> >>> >
> >>> > -
> >>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>> > For additional commands, e-mail: dev-h...@maven.apache.org
> >>> >
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>>
> >>> --
> >>> Dennis Lundberg 
> >>>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
>
> --
> Olivier Lamy
> Ecetera: http://ecetera.com.au
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Model Converter version 2.3

2013-08-15 Thread Fred Cooke

Dennis, effectively what is required is a statement like this: "I believe
that I've released XYZ binaries from ABC sources (tarball + N patches, SCM,
whatever)" with enough info to exactly identify what XYZ and ABC are
(checksums, URLs, revisions, etc) without guessing and duplicated
research/looking up of by everyone who wants to check.

If you just say "here's the binaries" then you have to put a LOT more work
in to figure out the source to compare with, and thus trace history, and
thus know that they're legit, or not. That's the problem.

No statement is being made about what the release manager thinks they've
released. Thus that release could be from a wrong Git branch by accident,
for example or any number of other things. EG POM edited to not be
snapshots and manual build done with changes made, etc.

PS, it's ing GREAT that Jason stepped up and said what he said. Amen to
that! More fine leadership.

Regards,

Fred.

On Thu, Aug 15, 2013 at 9:37 PM, Dennis Lundberg  wrote:

> On Thu, Aug 15, 2013 at 10:50 AM, Jörg Schaible <
> joerg.schai...@scalaris.com
> > wrote:
>
> > Hi Oliver,
> >
> > Olivier Lamy wrote:
> >
> > > On 15 August 2013 08:53, sebb  wrote:
> > >> On 14 August 2013 21:21, Dennis Lundberg  wrote:
> > >>> On Wed, Aug 14, 2013 at 10:47 AM, sebb  wrote:
> > >>>
> >  On 13 August 2013 18:58, Dennis Lundberg 
> wrote:
> >  > On Tue, Aug 13, 2013 at 12:30 AM, sebb  wrote:
> >  >> On 12 August 2013 20:10, Jason van Zyl  wrote:
> >  >>>
> >  >
> >  > I have now read the threads that are referring to, and have
> not
> >  > found a single link to any ASF rule stating that we need to
> >  > include these things in a VOTE thread.
> >  
> >   So how do you propose that reviewers check the provenance of
> the
> >   files in the source release?
> >  >>>
> >  >>> Are you looking for files that are in a distribution that didn't
> >  >>> come
> >  from source control? Everything else as far as provenance goes is
> >  covered. Errant content is a potential problem, but everything in a
> >  distribution should come from source control which no one has access
> > to
> >  until they have a signed CLA on file.
> >  >>
> >  >> Yes. That is where the whole saga started.
> >  >>
> >  >> Proving provenance is why the SCM coordinates are needed for the
> >  >> vote.
> >  >>
> >  >> The SCM details may also be useful to discover files accidentally
> >  >> omitted from the source archive.
> >  >
> >  > You want to compare the contents of the *-source-release.zip with
> >  > something from SCM, to make nothing bad has crept into the source
> >  > bundle. So you need to know where in SCM you can find it. Have I
> >  > understood you correctly?
> > 
> >  It's vital to be able to link the files in the source release
> >  archive(s) to their origin in SCM.
> > 
> >  The provenance of any source files the ASF releases must be clearly
> >  traceable.
> > 
> > >>>
> > >>> This information is clearly traceable and available to anyone who
> wants
> > >>> to review a release made by the Maven project. Our process uses the
> > >>> Release Plugin, which will put the POM from the SCM tag in the
> staging
> > >>> directory along with the source-release.zip. In that POM wou will
> find
> > >>> the URL to the original sources in SCM.
> > >>>
> > >>
> > >> As has already been pointed out, SVN tags are not immutable, so the
> > >> tag name alone is not sufficient.
> > >
> > > I think Stephen perfectly sum up the situation.
> > > If you're not happy follow that.
> > >
> > > But please STOP the troll!
> >
> > The Maven PMC has made clear, that it knows about the problems and want
> to
> > ignore it. However, please understand that Sebb is playing devil's
> advocate
> > here, because the same release process is used for other Apache projects
> > where the PMCs will *not* ignore this flaws. Sebb is more or less
> pestering
> > you, because he is tired of having the same discussions in projects where
> > he
> > *is* PMC and is therefore responsible for the release. So, it is a bit
> > short
> > sighted to declare him as troll, simply because you (the Maven PMC)
> decided
> > to ignore the problem.
> >
>
> Hi Jörg,
>
> Personally I'm not ignoring the problem, and I don't think anyone else is
> either.
>
> I am trying to understand what the problem is, because I cannot see it.
> Therefor I ask questions to try to find out what the problem is and then,
> and only then, decide if/how to solve it.
>
>
> >
> > - Jörg
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> Dennis Lundberg
>

Re: [VOTE] Release Apache Maven Model Converter version 2.3

2013-08-15 Thread Fred Cooke

>
> Right so far?
>

No, you're not. Step three, in SVN, requires reviewing history to confirm
no changes were made to that URL *ever*. In Git, step 3 involves knowing
the hash, as spurious tags have already been known to circulate.

Even if all of the details were in the POM, the question still remains, is
this the revision you *intended* to release? Or not? ONLY you can answer
this.

Fred.

On Thu, Aug 15, 2013 at 9:57 PM, Dennis Lundberg  wrote:

> On Thu, Aug 15, 2013 at 9:27 PM, sebb  wrote:
>
> > On 15 August 2013 14:16, Jason van Zyl  wrote:
> > > What Sebb is doing is perfectly reasonable.
> >
>
> I agree. Checking that the source bundle is correct is good release review
> practice.
>
> Thank you!
> >
> > > He's trying to assert that everything in the source ball actually comes
> > from source control and that no errant files have made their way into the
> > distribution. Right now we cannot assert that the assembly plugin has not
> > wandered outside the checkout and pulled something else in, or that
> someone
> > didn't accidentally put something else in the distribution. I think this
> > unlikely but we can't assert otherwise right now which I believe is
> Sebb's
> > point.
> >
> > It *has* already happened several times that I am aware of.
> >
> > The last few releases of the War plugin (various RMs & voters)
> > included at least one spurious file.
> > So it was not just a one-off packaging - and review - failure.
> > [See separate thread(s) for all the details; they are not germane here.]
> >
> > The message is that mistakes happen even in automated processes.
> > Which is why independent comparison of input and output is valuable.
> >
> > > If we can embed the revision from which the assembly was made in the
> > assembly itself (and maybe the build number plugin is doing this
> already),
> > then a tool can be made to unpack the assembly, checkout the revision and
> > assert that everything in the source distribution comes from source
> control.
> > >
> > > If we can also assert that as part of each build all the license files
> > are intact and headers are in place then I believe we're done with
> > provenance.
> > > Licenses are present, all files have valid license headers, all files
> > present in the source distribution come from source control, all
> > contributions to source control are from bonafide CLA carrying Apache
> > committers because you don't get access to commit until the CLA is on
> file.
> > >
> > > Sebb, reasonably accurate?
> >
> > Yes.
> >
> > One other point I made already is that I think the vote e-mail needs
> > to be transparent to all, not just those on the PMC.
> > Links to the output from the release process are obviously already in
> > the mail; what is missing is the input to the process, e.g.. SCM
> > coords.
> > Yes, it may be possible to dig out the details from the archive, but
> > that's not trivial.
> >
>
> I disagree.
>
> If we focus first on a "normal" release, one that succeeds on the first
> attempt, without a respin or deleting of tags.
> To check provenance you would do this:
>
> 1. download the source bundle
> 2. unpack the source bundle
> 3. checkout the corresponding source code from the SCM
> 4. compare the two trees
>
> Right so far?
>
> What you want, if I understand you correctly, is to have the SCM URL in the
> vote email. So that you can give that to your SCM client in step 3.
>
> With the process we use here at the Maven project, the SCM URL is in the
> pom.xml file that sits in the root directory of the unpacked source bundle.
> All you need to do is open the file and copy the URL from there. I still
> fail to see how that is so much harder than to copy the URL from an email.
>
> That is if you don't know the conventions that we use, by way of the
> Release Plugin. The tag will always be in the format
> ${project.artifactId}-${project.version}
>
> Now, for a respun release thing are trickier. Here it might be a good idea
> to include the revision number or hash, or whatever is unique in the SCM
> being used. Even though the code under review will always be under the
> latest tag in the above format (at least for Subversion).
>
>
> > Publishing the SCM coordinates in the mail is trivial to do, and shows
> > that the input is an important part of the review process.
> > Having the information in the mail thread is also useful for the
> archives.
> >
>
> As others have said before, we aim to automate the release process as much
> as possible. Therefor even a seemingly minor addition will be questioned,
> as you have noticed, before it is included in our process.
>
> Can you explain why the information is useful for the archives? I've seen
> you mentioned that before. Isn't that moot once the release is approved?
> The tag will be in Subversion for the forseable future and noone will touch
> it. What am I missing?
>
>
> >
> > > On Aug 15, 2013, at 9:01 AM, Chris Graham 
> wrote:
> > >
> > >>
> > >>
> > >> Sent from my iPhone
> > >>
> > >> On

Re: [VOTE] Release Apache Maven Model Converter version 2.3

2013-08-15 Thread Fred Cooke

Actually, I missed exactly nothing!!!

Your process could be flawed. Human errors do happen.

The entire point of any review is to not trust process or people, and to
check everything. You're effectively advocating not doing that, and this
*IS* unhealthy.

I know that with your process on a primary vote the tag should exist once,
and only once. Someone could screw up. It happens. Your promise of "we
never make mistakes" holds no water with me.

The most disturbing part of all is Sebb being persecuted and attacked and
labeled a *troll* of all things for advocating due diligence. :-/

Fred.

On Thu, Aug 15, 2013 at 10:33 PM, Dennis Lundberg wrote:

> On Thu, Aug 15, 2013 at 10:24 PM, Fred Cooke  wrote:
>
> > >
> > > Right so far?
> > >
> >
> > No, you're not. Step three, in SVN, requires reviewing history to confirm
> > no changes were made to that URL *ever*. In Git, step 3 involves knowing
> > the hash, as spurious tags have already been known to circulate.
> >
>
> I don't know Git that well yet, so I won't go into a discussion about that.
>
> As for Subversion, you missed a few bits of what I wrote. I was talking
> about a release that is *not* respun. With our process that means that
> there has never been such a tag before and, if the vote passes, there will
> never be another one again *ever*. If someone doesn't follow our process
> that will become apparent during the review.
>
>
> > Even if all of the details were in the POM, the question still remains,
> is
> > this the revision you *intended* to release? Or not? ONLY you can answer
> > this.
> >
>
> With our process - yes it is. *always*
>
>
> >
> > Fred.
> >
> > On Thu, Aug 15, 2013 at 9:57 PM, Dennis Lundberg 
> > wrote:
> >
> > > On Thu, Aug 15, 2013 at 9:27 PM, sebb  wrote:
> > >
> > > > On 15 August 2013 14:16, Jason van Zyl  wrote:
> > > > > What Sebb is doing is perfectly reasonable.
> > > >
> > >
> > > I agree. Checking that the source bundle is correct is good release
> > review
> > > practice.
> > >
> > > Thank you!
> > > >
> > > > > He's trying to assert that everything in the source ball actually
> > comes
> > > > from source control and that no errant files have made their way into
> > the
> > > > distribution. Right now we cannot assert that the assembly plugin has
> > not
> > > > wandered outside the checkout and pulled something else in, or that
> > > someone
> > > > didn't accidentally put something else in the distribution. I think
> > this
> > > > unlikely but we can't assert otherwise right now which I believe is
> > > Sebb's
> > > > point.
> > > >
> > > > It *has* already happened several times that I am aware of.
> > > >
> > > > The last few releases of the War plugin (various RMs & voters)
> > > > included at least one spurious file.
> > > > So it was not just a one-off packaging - and review - failure.
> > > > [See separate thread(s) for all the details; they are not germane
> > here.]
> > > >
> > > > The message is that mistakes happen even in automated processes.
> > > > Which is why independent comparison of input and output is valuable.
> > > >
> > > > > If we can embed the revision from which the assembly was made in
> the
> > > > assembly itself (and maybe the build number plugin is doing this
> > > already),
> > > > then a tool can be made to unpack the assembly, checkout the revision
> > and
> > > > assert that everything in the source distribution comes from source
> > > control.
> > > > >
> > > > > If we can also assert that as part of each build all the license
> > files
> > > > are intact and headers are in place then I believe we're done with
> > > > provenance.
> > > > > Licenses are present, all files have valid license headers, all
> files
> > > > present in the source distribution come from source control, all
> > > > contributions to source control are from bonafide CLA carrying Apache
> > > > committers because you don't get access to commit until the CLA is on
> > > file.
> > > > >
> > > > > Sebb, reasonably accurate?
> > > >
> > > > Yes.
> > > >
> > > > One other point I made already is that I think the vote e-mail n

Re: [VOTE] Release Apache Maven Model Converter version 2.3

2013-08-15 Thread Fred Cooke

Firstly, I'm not heated up, so I can not cool down, without going into
hypothermia.

Secondly, I never said that *you* were doing that, just that it was being
done.

Thirdly, I'm super glad that you agree SCM and bundles should be compared.

Fourthly, let's get on with the discussion about what it takes to do that.
No, wait. Sebb and Jason already have that nailed the  down.

Good men, those two.

Fred.

On Thu, Aug 15, 2013 at 11:21 PM, Dennis Lundberg wrote:

> Hi Fred,
>
> On Thu, Aug 15, 2013 at 10:48 PM, Fred Cooke  wrote:
>
> > Actually, I missed exactly nothing!!!
> >
> > Your process could be flawed. Human errors do happen.
> >
>
> The process is not flawed, but people make mistakes.
>
>
> > The entire point of any review is to not trust process or people, and to
> > check everything. You're effectively advocating not doing that, and this
> > *IS* unhealthy.
> >
>
> Why on earth would you think that I advocate not checking everything? I
> have just agreed that Sebb has a point in that we *should* check the source
> bundle against the SCM. Nobody is disputing that. That is not what this
> disussion is about.
>
>
> > I know that with your process on a primary vote the tag should exist
> once,
> > and only once. Someone could screw up. It happens. Your promise of "we
> > never make mistakes" holds no water with me.
> >
>
> I have never promised such a thing. People make mistakes. That is why we
> have review. To catch those errors.
>
>
> >
> > The most disturbing part of all is Sebb being persecuted and attacked and
> > labeled a *troll* of all things for advocating due diligence. :-/
> >
>
> I am not attacking anyone and have not called anyone a troll. Just trying
> to understand the problem at hand.
>
> May I suggest that you cool down a bit.
>
>
> >
> > Fred.
> >
> > On Thu, Aug 15, 2013 at 10:33 PM, Dennis Lundberg  > >wrote:
> >
> > > On Thu, Aug 15, 2013 at 10:24 PM, Fred Cooke 
> > wrote:
> > >
> > > > >
> > > > > Right so far?
> > > > >
> > > >
> > > > No, you're not. Step three, in SVN, requires reviewing history to
> > confirm
> > > > no changes were made to that URL *ever*. In Git, step 3 involves
> > knowing
> > > > the hash, as spurious tags have already been known to circulate.
> > > >
> > >
> > > I don't know Git that well yet, so I won't go into a discussion about
> > that.
> > >
> > > As for Subversion, you missed a few bits of what I wrote. I was talking
> > > about a release that is *not* respun. With our process that means that
> > > there has never been such a tag before and, if the vote passes, there
> > will
> > > never be another one again *ever*. If someone doesn't follow our
> process
> > > that will become apparent during the review.
> > >
> > >
> > > > Even if all of the details were in the POM, the question still
> remains,
> > > is
> > > > this the revision you *intended* to release? Or not? ONLY you can
> > answer
> > > > this.
> > > >
> > >
> > > With our process - yes it is. *always*
> > >
> > >
> > > >
> > > > Fred.
> > > >
> > > > On Thu, Aug 15, 2013 at 9:57 PM, Dennis Lundberg  >
> > > > wrote:
> > > >
> > > > > On Thu, Aug 15, 2013 at 9:27 PM, sebb  wrote:
> > > > >
> > > > > > On 15 August 2013 14:16, Jason van Zyl  wrote:
> > > > > > > What Sebb is doing is perfectly reasonable.
> > > > > >
> > > > >
> > > > > I agree. Checking that the source bundle is correct is good release
> > > > review
> > > > > practice.
> > > > >
> > > > > Thank you!
> > > > > >
> > > > > > > He's trying to assert that everything in the source ball
> actually
> > > > comes
> > > > > > from source control and that no errant files have made their way
> > into
> > > > the
> > > > > > distribution. Right now we cannot assert that the assembly plugin
> > has
> > > > not
> > > > > > wandered outside the checkout and pulled something else in, or
> that
> > > > > someone
> > > > > > didn't accidentally put something else in the distribution. I
> think
&g

Re: [VOTE] Release Apache Maven Model Converter version 2.3

2013-08-15 Thread Fred Cooke

It's funny that you cite "no time" and use the equivalent of 299.5 6 digit
revision numbers to send us an email on your lack of time. You could have
done 299 releases to Sebb's quite reasonable standards with that much
keyboard activity. Point made? :-p

On Fri, Aug 16, 2013 at 1:14 AM, Olivier Lamy  wrote:

> On 15 August 2013 18:50, Jörg Schaible 
> wrote:
> > Hi Oliver,
> >
> > Olivier Lamy wrote:
> >
> >> On 15 August 2013 08:53, sebb  wrote:
> >>> On 14 August 2013 21:21, Dennis Lundberg  wrote:
>  On Wed, Aug 14, 2013 at 10:47 AM, sebb  wrote:
> 
> > On 13 August 2013 18:58, Dennis Lundberg  wrote:
> > > On Tue, Aug 13, 2013 at 12:30 AM, sebb  wrote:
> > >> On 12 August 2013 20:10, Jason van Zyl  wrote:
> > >>>
> > >
> > > I have now read the threads that are referring to, and have not
> > > found a single link to any ASF rule stating that we need to
> > > include these things in a VOTE thread.
> > 
> >  So how do you propose that reviewers check the provenance of the
> >  files in the source release?
> > >>>
> > >>> Are you looking for files that are in a distribution that didn't
> > >>> come
> > from source control? Everything else as far as provenance goes is
> > covered. Errant content is a potential problem, but everything in a
> > distribution should come from source control which no one has access
> to
> > until they have a signed CLA on file.
> > >>
> > >> Yes. That is where the whole saga started.
> > >>
> > >> Proving provenance is why the SCM coordinates are needed for the
> > >> vote.
> > >>
> > >> The SCM details may also be useful to discover files accidentally
> > >> omitted from the source archive.
> > >
> > > You want to compare the contents of the *-source-release.zip with
> > > something from SCM, to make nothing bad has crept into the source
> > > bundle. So you need to know where in SCM you can find it. Have I
> > > understood you correctly?
> >
> > It's vital to be able to link the files in the source release
> > archive(s) to their origin in SCM.
> >
> > The provenance of any source files the ASF releases must be clearly
> > traceable.
> >
> 
>  This information is clearly traceable and available to anyone who
> wants
>  to review a release made by the Maven project. Our process uses the
>  Release Plugin, which will put the POM from the SCM tag in the staging
>  directory along with the source-release.zip. In that POM wou will find
>  the URL to the original sources in SCM.
> 
> >>>
> >>> As has already been pointed out, SVN tags are not immutable, so the
> >>> tag name alone is not sufficient.
> >>
> >> I think Stephen perfectly sum up the situation.
> >> If you're not happy follow that.
> >>
> >> But please STOP the troll!
> >
> > The Maven PMC has made clear, that it knows about the problems and want
> to
> > ignore it. However, please understand that Sebb is playing devil's
> advocate
> > here, because the same release process is used for other Apache projects
> > where the PMCs will *not* ignore this flaws. Sebb is more or less
> pestering
> > you, because he is tired of having the same discussions in projects
> where he
> > *is* PMC and is therefore responsible for the release. So, it is a bit
> short
> > sighted to declare him as troll, simply because you (the Maven PMC)
> decided
> > to ignore the problem.
>
> I declared the thread as a troll not someone and BTW I'm not english
> native speaker so the troll word is not so rude for me :-)
> If it was read as something rude and a sort of personal attack so I
> apologize.
>
> I'm just tired by all of those threads.
> As described by Stephen we provide what ASF rules need.
> Perso I'm a volunteer here and I spend my spare time on writing code
> here to help our users.
> So my time here is limited and I prefer coding rather than waste my
> time on non needed procedure steps.
> So if someone want to add extra/over prodecure steps why not but in
> these case tools must be provided to ease our life.
> I'm a developer and yes maybe I tend to be lazy so I prefer
> using/writing tools to avoid manual tasks :-).
>
> That won't be too complicated as the src tarball contains the pom with
> scm information.
> But perso no time for that so I prefer to not feed troll when I don't
> have time to REALLY do the job.
>
> But tired of that and why?
> Because I heard/read so many people complaining about ASF too much
> bureaucratic and not a place for innovations..
> Those threads are the perfect examples of that!!
> I just don't want to go in a too many procedures model as I can see in
> some projects (again especially when it's not needed)
> At the end the only result is: folks are just scared about releasing
> because it's too complicated and on vote thread they only receive
> comments on missing comma in a text file and/o

Re: [VOTE] Release Apache Maven Model Converter version 2.3

2013-08-15 Thread Fred Cooke

Chances of understanding me:

   - Close friend: 50%
   - Other friend: 25%
   - Kiwi: 15%
   - Ozzy: 10% (that's you)
   - POHM: 8%
   - Yank: 5%
   - Spaniard: 1%

So don't feel too bad, you had a 90% chance of failure stacked against you
;-)

I'd dearly love to contribute, but I will not and can not until it's nailed
down that things are being done properly, and I mean the MOJO list, not
this list. Both are questionable, though.

My point about the volume of text from Olivier was valid and remains valid,
with or without the non-smile pokey tongue. Those 1797 characters could
have quietly done a lot of good. I hope it in no way offended Olivier, and
if it did, I apologise.

Enhancing the template is a fruitless exercise without agreement that it
should be done.

Besides, I was just throwing some backup Sebb's way when he was under
attack...

Yours incomprehensibly,

Fred

On Fri, Aug 16, 2013 at 12:11 PM, Barrie Treloar  wrote:

> On 16 August 2013 08:54, Fred Cooke  wrote:
> > It's funny that you cite "no time" and use the equivalent of 299.5 6
> digit
> > revision numbers to send us an email on your lack of time. You could have
> > done 299 releases to Sebb's quite reasonable standards with that much
> > keyboard activity. Point made? :-p
>
> I don't understand your behaviour Fred.
>
> You want people to change but then you attack them personally (even if
> you add a smiley face)
>
> As Olivier points out, this is open source volunteer work.
> Perhaps you could actually help out and cut some code/releases?
> You could even enhance the templates or release tooling to support
> what you are asking for.
>
> I think you would get better responses if you didn't throw stones.
> A worst case scenario is that those who are doing the work, don't
> bother.  How is that helping anyone?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Model Converter version 2.3

2013-08-16 Thread Fred Cooke

Dennis, I've been using (and mostly loving) the release plugin/process for
the better part of a decade and certainly claim to understand it well. I
don't see how my knowledge of that (or Sebb's perceived lack of knowledge
of that) is in any way relevant. The release plugin means it's harder to do
something wrong, and this is good, and why I love it. However, you can,
could, and someone may, produce non-snapshot binaries on a staging server
without having used it, from arbitrary sources and/or a bug in the release
plugin could do something wrong, and given our collective faith in that
plugin, you'd likely not check unless suspicious (eg  when the assembly
plugin suddenly stopped compressing some archives).

On Fri, Aug 16, 2013 at 8:32 PM, Dennis Lundberg  wrote:

> On Fri, Aug 16, 2013 at 9:52 AM, sebb  wrote:
>
> > On 16 August 2013 08:10, Dennis Lundberg  wrote:
> > > On Fri, Aug 16, 2013 at 1:20 AM, sebb  wrote:
> > >
> > >> On 15 August 2013 20:57, Dennis Lundberg  wrote:
> > >> > On Thu, Aug 15, 2013 at 9:27 PM, sebb  wrote:
> > >> >
> > >> >> On 15 August 2013 14:16, Jason van Zyl  wrote:
> > >> >> > What Sebb is doing is perfectly reasonable.
> > >> >>
> > >> >
> > >> > I agree. Checking that the source bundle is correct is good release
> > >> review
> > >> > practice.
> > >> >
> > >> > Thank you!
> > >> >>
> > >> >> > He's trying to assert that everything in the source ball actually
> > >> comes
> > >> >> from source control and that no errant files have made their way
> into
> > >> the
> > >> >> distribution. Right now we cannot assert that the assembly plugin
> has
> > >> not
> > >> >> wandered outside the checkout and pulled something else in, or that
> > >> someone
> > >> >> didn't accidentally put something else in the distribution. I think
> > this
> > >> >> unlikely but we can't assert otherwise right now which I believe is
> > >> Sebb's
> > >> >> point.
> > >> >>
> > >> >> It *has* already happened several times that I am aware of.
> > >> >>
> > >> >> The last few releases of the War plugin (various RMs & voters)
> > >> >> included at least one spurious file.
> > >> >> So it was not just a one-off packaging - and review - failure.
> > >> >> [See separate thread(s) for all the details; they are not germane
> > here.]
> > >> >>
> > >> >> The message is that mistakes happen even in automated processes.
> > >> >> Which is why independent comparison of input and output is
> valuable.
> > >> >>
> > >> >> > If we can embed the revision from which the assembly was made in
> > the
> > >> >> assembly itself (and maybe the build number plugin is doing this
> > >> already),
> > >> >> then a tool can be made to unpack the assembly, checkout the
> revision
> > >> and
> > >> >> assert that everything in the source distribution comes from source
> > >> control.
> > >> >> >
> > >> >> > If we can also assert that as part of each build all the license
> > files
> > >> >> are intact and headers are in place then I believe we're done with
> > >> >> provenance.
> > >> >> > Licenses are present, all files have valid license headers, all
> > files
> > >> >> present in the source distribution come from source control, all
> > >> >> contributions to source control are from bonafide CLA carrying
> Apache
> > >> >> committers because you don't get access to commit until the CLA is
> on
> > >> file.
> > >> >> >
> > >> >> > Sebb, reasonably accurate?
> > >> >>
> > >> >> Yes.
> > >> >>
> > >> >> One other point I made already is that I think the vote e-mail
> needs
> > >> >> to be transparent to all, not just those on the PMC.
> > >> >> Links to the output from the release process are obviously already
> in
> > >> >> the mail; what is missing is the input to the process, e.g.. SCM
> > >> >> coords.
> > >> >> Yes, it may be possible to dig out the details from the archive,
> but
> > >> >> that's not trivial.
> > >> >>
> > >> >
> > >> > I disagree.
> > >> >
> > >> > If we focus first on a "normal" release, one that succeeds on the
> > first
> > >> > attempt, without a respin or deleting of tags.
> > >> > To check provenance you would do this:
> > >> >
> > >> > 1. download the source bundle
> > >> > 2. unpack the source bundle
> > >> > 3. checkout the corresponding source code from the SCM
> > >> > 4. compare the two trees
> > >> >
> > >> > Right so far?
> > >> >
> > >> > What you want, if I understand you correctly, is to have the SCM URL
> > in
> > >> the
> > >> > vote email. So that you can give that to your SCM client in step 3.
> > >>
> > >> Yes.
> > >>
> > >> > With the process we use here at the Maven project, the SCM URL is in
> > the
> > >> > pom.xml file that sits in the root directory of the unpacked source
> > >> bundle.
> > >> > All you need to do is open the file and copy the URL from there. I
> > still
> > >> > fail to see how that is so much harder than to copy the URL from an
> > >> email.
> > >> >
> > >> > That is if you don't know the conventions that we use, by way of the
> > >> > Release Plugin. The tag

Re: [VOTE] Release Apache Maven Model Converter version 2.3

2013-08-16 Thread Fred Cooke

Dennis, of course source bundles will contain URLs and hashes and revisions
and so forth, and the chance of those being mismatched is approximately
zero. That's not the point.

The point (for me, at least) is what did you INTEND to release, and does
THAT match what is actually found in the bundle (including URLs and hashes
etc matching).

Releasing is a fundamentally human process that consists of "is this
ready?" and "pull trigger". Some binaries and bundles end up on server of
some type somewhere. I want to know the checksum of one of the set of items
(so I KNOW (not guess) that I'm looking at what you want me to), and I want
to know what SCM or tarball+patchset you think you released it from. This
is human information that can't be automated. The bundle someone goes and
finds could have anything in it, and they won't know if it's what you
wanted it to have in it, or not.

Fred.

On Fri, Aug 16, 2013 at 11:25 PM, Dennis Lundberg wrote:

> On Fri, Aug 16, 2013 at 11:24 AM, sebb  wrote:
>
> > On 16 August 2013 09:32, Dennis Lundberg  wrote:
> > > On Fri, Aug 16, 2013 at 9:52 AM, sebb  wrote:
> > >
> > >> On 16 August 2013 08:10, Dennis Lundberg  wrote:
> > >> > On Fri, Aug 16, 2013 at 1:20 AM, sebb  wrote:
> > >> >
> > >> >> On 15 August 2013 20:57, Dennis Lundberg 
> wrote:
> > >> >> > On Thu, Aug 15, 2013 at 9:27 PM, sebb  wrote:
> > >> >> >
> > >> >> >> On 15 August 2013 14:16, Jason van Zyl  wrote:
> > >> >> >> > What Sebb is doing is perfectly reasonable.
> > >> >> >>
> > >> >> >
> > >> >> > I agree. Checking that the source bundle is correct is good
> release
> > >> >> review
> > >> >> > practice.
> > >> >> >
> > >> >> > Thank you!
> > >> >> >>
> > >> >> >> > He's trying to assert that everything in the source ball
> > actually
> > >> >> comes
> > >> >> >> from source control and that no errant files have made their way
> > into
> > >> >> the
> > >> >> >> distribution. Right now we cannot assert that the assembly
> plugin
> > has
> > >> >> not
> > >> >> >> wandered outside the checkout and pulled something else in, or
> > that
> > >> >> someone
> > >> >> >> didn't accidentally put something else in the distribution. I
> > think
> > >> this
> > >> >> >> unlikely but we can't assert otherwise right now which I believe
> > is
> > >> >> Sebb's
> > >> >> >> point.
> > >> >> >>
> > >> >> >> It *has* already happened several times that I am aware of.
> > >> >> >>
> > >> >> >> The last few releases of the War plugin (various RMs & voters)
> > >> >> >> included at least one spurious file.
> > >> >> >> So it was not just a one-off packaging - and review - failure.
> > >> >> >> [See separate thread(s) for all the details; they are not
> germane
> > >> here.]
> > >> >> >>
> > >> >> >> The message is that mistakes happen even in automated processes.
> > >> >> >> Which is why independent comparison of input and output is
> > valuable.
> > >> >> >>
> > >> >> >> > If we can embed the revision from which the assembly was made
> in
> > >> the
> > >> >> >> assembly itself (and maybe the build number plugin is doing this
> > >> >> already),
> > >> >> >> then a tool can be made to unpack the assembly, checkout the
> > revision
> > >> >> and
> > >> >> >> assert that everything in the source distribution comes from
> > source
> > >> >> control.
> > >> >> >> >
> > >> >> >> > If we can also assert that as part of each build all the
> license
> > >> files
> > >> >> >> are intact and headers are in place then I believe we're done
> with
> > >> >> >> provenance.
> > >> >> >> > Licenses are present, all files have valid license headers,
> all
> > >> files
> > >> >> >> present in the source distribution come from source control, all
> > >> >> >> contributions to source control are from bonafide CLA carrying
> > Apache
> > >> >> >> committers because you don't get access to commit until the CLA
> > is on
> > >> >> file.
> > >> >> >> >
> > >> >> >> > Sebb, reasonably accurate?
> > >> >> >>
> > >> >> >> Yes.
> > >> >> >>
> > >> >> >> One other point I made already is that I think the vote e-mail
> > needs
> > >> >> >> to be transparent to all, not just those on the PMC.
> > >> >> >> Links to the output from the release process are obviously
> > already in
> > >> >> >> the mail; what is missing is the input to the process, e.g.. SCM
> > >> >> >> coords.
> > >> >> >> Yes, it may be possible to dig out the details from the archive,
> > but
> > >> >> >> that's not trivial.
> > >> >> >>
> > >> >> >
> > >> >> > I disagree.
> > >> >> >
> > >> >> > If we focus first on a "normal" release, one that succeeds on the
> > >> first
> > >> >> > attempt, without a respin or deleting of tags.
> > >> >> > To check provenance you would do this:
> > >> >> >
> > >> >> > 1. download the source bundle
> > >> >> > 2. unpack the source bundle
> > >> >> > 3. checkout the corresponding source code from the SCM
> > >> >> > 4. compare the two trees
> > >> >> >
> > >> >> > Right so far?
> > >> >> >
> > >> >> > What you want, if I understand you correctly, is to

Re: [VOTE] Release Apache Maven Model Converter version 2.3

2013-08-16 Thread Fred Cooke

They're deployed as a set, so what I want is the SHA1 or even MD5 of any
one of the set of uploaded files, such that I can confirm that the set is
the set that I am supposed to be looking at. I don't see importance in
which, but I've not thought about it much. I think *all* would be huge
overkill.

On Sat, Aug 17, 2013 at 12:00 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> That sounds like you are looking for the SHA1 sum of the source bundle to
> be included in the vote email. Which would seem perfectly reasonable to me.
>
>
>
>
> On 16 August 2013 12:31, Fred Cooke  wrote:
>
> > Dennis, of course source bundles will contain URLs and hashes and
> revisions
> > and so forth, and the chance of those being mismatched is approximately
> > zero. That's not the point.
> >
> > The point (for me, at least) is what did you INTEND to release, and does
> > THAT match what is actually found in the bundle (including URLs and
> hashes
> > etc matching).
> >
> > Releasing is a fundamentally human process that consists of "is this
> > ready?" and "pull trigger". Some binaries and bundles end up on server of
> > some type somewhere. I want to know the checksum of one of the set of
> items
> > (so I KNOW (not guess) that I'm looking at what you want me to), and I
> want
> > to know what SCM or tarball+patchset you think you released it from. This
> > is human information that can't be automated. The bundle someone goes and
> > finds could have anything in it, and they won't know if it's what you
> > wanted it to have in it, or not.
> >
> > Fred.
> >
> > On Fri, Aug 16, 2013 at 11:25 PM, Dennis Lundberg  > >wrote:
> >
> > > On Fri, Aug 16, 2013 at 11:24 AM, sebb  wrote:
> > >
> > > > On 16 August 2013 09:32, Dennis Lundberg  wrote:
> > > > > On Fri, Aug 16, 2013 at 9:52 AM, sebb  wrote:
> > > > >
> > > > >> On 16 August 2013 08:10, Dennis Lundberg 
> > wrote:
> > > > >> > On Fri, Aug 16, 2013 at 1:20 AM, sebb  wrote:
> > > > >> >
> > > > >> >> On 15 August 2013 20:57, Dennis Lundberg 
> > > wrote:
> > > > >> >> > On Thu, Aug 15, 2013 at 9:27 PM, sebb 
> > wrote:
> > > > >> >> >
> > > > >> >> >> On 15 August 2013 14:16, Jason van Zyl 
> > wrote:
> > > > >> >> >> > What Sebb is doing is perfectly reasonable.
> > > > >> >> >>
> > > > >> >> >
> > > > >> >> > I agree. Checking that the source bundle is correct is good
> > > release
> > > > >> >> review
> > > > >> >> > practice.
> > > > >> >> >
> > > > >> >> > Thank you!
> > > > >> >> >>
> > > > >> >> >> > He's trying to assert that everything in the source ball
> > > > actually
> > > > >> >> comes
> > > > >> >> >> from source control and that no errant files have made their
> > way
> > > > into
> > > > >> >> the
> > > > >> >> >> distribution. Right now we cannot assert that the assembly
> > > plugin
> > > > has
> > > > >> >> not
> > > > >> >> >> wandered outside the checkout and pulled something else in,
> or
> > > > that
> > > > >> >> someone
> > > > >> >> >> didn't accidentally put something else in the distribution.
> I
> > > > think
> > > > >> this
> > > > >> >> >> unlikely but we can't assert otherwise right now which I
> > believe
> > > > is
> > > > >> >> Sebb's
> > > > >> >> >> point.
> > > > >> >> >>
> > > > >> >> >> It *has* already happened several times that I am aware of.
> > > > >> >> >>
> > > > >> >> >> The last few releases of the War plugin (various RMs &
> voters)
> > > > >> >> >> included at least one spurious file.
> > > > >> >> >> So it was not just a one-off packaging - and review -
> failure.
> > > > >> >> >> [See separa

Re: What is the correct Git SCM URL for a branch?

2013-08-24 Thread Fred Cooke

I understood that the purpose of the SCM *URL* was to be able to *use*
it with a tool (where browser != tool), as such, there is only one
correct URL, the rest are paths for browsing on a file system or
web-front end. I did this knowing it would fail to illustrate the
point:

fred@cheetah:~/workspaces$ git clone
https://git-wip-us.apache.org/repos/asf/maven.git/tree/heads/maven-2.2.x
Cloning into 'maven-2.2.x'...
fatal: 
https://git-wip-us.apache.org/repos/asf/maven.git/tree/heads/maven-2.2.x/info/refs
not found: did you run git update-server-info on the server?

On Sat, Aug 24, 2013 at 4:49 PM, Hervé BOUTEMY  wrote:
> I made some research and tests and here are my findings
>
> for the scm url, ie. web access like we have ViewVC url for svn, git provides
> GitWeb equivalent to ViewVC (even if a lot of other solutions exist [1]),
> which is what is configured on Apache git http
> Then the GitWeb url format is in the git documentation [2]
>
> With this format, you can refer to branches, tags and revisions, like
> following examples:
>
> branches:
>   HEAD:
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/HEAD
>   maven-3.0.x:
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/heads/maven-3.0.x
>   maven-2.2.x:
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/heads/maven-2.2.x
>
> tags:
>   https://git-wip-us.apache.org/repos/asf/maven.git/tree/tags/maven-3.1.0
>   https://git-wip-us.apache.org/repos/asf/maven.git/tree/tags/maven-3.0.5
>   https://git-wip-us.apache.org/repos/asf/maven.git/tree/tags/maven-2.2.1
>
> revisions: (same examples as previous tags)
>   
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/5a0e6574404b4964522d90c3438e25574a95466c
>   
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/fbdd91ba01387485598935fe7d340261239e6a31
>   
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/238f83f8230b1e0ad3239ca7e4f849591331c801
>
>
> From the GitWeb url format documentation [2], we should be able to navigate
> into the reporitory directories by ading ":/", but it fails on Apache
> GitWeb installation:
>   https://git-wip-us.apache.org/repos/asf/maven.git/tree/HEAD:/maven-core
> it works on Git's GitWeb installation
>   http://repo.or.cz/w/git.git/tree/tags/v1.8.2:/gitweb
>
> I don't know why Apache GitWeb is failing: previous version? some
> configuration?
> I know that even if the feature worked, this wouldn't permit us to let Maven
> calculate automatically child scm url from parent, since the format requires
> ':/' to be added for the first directory:
>   http://repo.or.cz/w/git.git/tree/tags/v1.8.2
>   http://repo.or.cz/w/git.git/tree/tags/v1.8.2:/gitweb
> For actuel Maven to correctly calculate the second from the first, we would
> need to write
>   http://repo.or.cz/w/git.git/tree/tags/v1.8.2:
> or  http://repo.or.cz/w/git.git/tree/tags/v1.8.2:/
> which are both unsupported by GitWeb actually
>
> Notice GitHub's url format works like a charm:
> https://github.com/apache/maven/tree/maven-3.1.0
> https://github.com/apache/maven/tree/maven-3.1.0/maven-core
> https://github.com/apache/maven/tree/maven-3.0.x
> https://github.com/apache/maven/tree/maven-3.0.x/maven-core
>
>
> Should we configure scm url to point to GitHub mirror instead of Apache
> canonical repo?
>
> I still didn't had a look at the way release plugin can transform branch url
> to release url during pom.xml modification: I wanted to share these findings
> first
>
> I had some thought about scm connection and developerConnection, but it's
> another story and this mail is already quite long: we'll see it after we
> improve web access support.
>
> Regards,
>
> Hervé
>
>
> [1]
> https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools#Web_Interfaces
>
> [2] http://git-scm.com/docs/gitweb.html#_actions,_and_urls
>
> Le samedi 10 août 2013 13:12:00 Dennis Lundberg a écrit :
>> Hi,
>>
>> I'm looking at the sources for Maven core in Git, which I'm learning
>> as I go along.
>>
>> "master" is at version 3.1.1-SNAPSHOT and has this in its pom.xml
>>   
>>
>> scm:git:https://git-wip-us.apache.org/repos/asf/maven.git> ection>
>> scm:git:https://git-wip-us.apache.org/repos/asf/maven.
>> git
>> https://git-wip-us.apache.org/repos/asf?p=maven.git
>> HEAD
>>   
>>
>> The head "maven-3.0.x" is at version 3.0.6-SNAPSHOT and has this in its
>> pom.xml 
>>
>> scm:git:https://git-wip-us.apache.org/repos/asf/maven.git> ection>
>> scm:git:https://git-wip-us.apache.org/repos/asf/maven.
>> git
>> https://git-wip-us.apache.org/repos/asf?p=maven.git
>> HEAD
>>   
>>
>> Since this is identical to what is in "master" I don't think this
>> would work if you tried to do a release using the Release Plugin.
>> Wouldn't that release what is specified in  i.e. "HEAD". Now, I
>> have looked through our documentation and used Google to find a
>> solution, but to no avail. From what I have gathered we should change
>> the value of , but to what? Would it involve
>> "ref/heads/maven-3.0.x"?
>>
>> The head

Re: What is the correct Git SCM URL for a branch?

2013-08-24 Thread Fred Cooke

Apologies, however as Herve noted, the web URL is variable across different
web implementations so it too should likely be left as is, being a human
chosen URL for human use. The previous SVN butchering of such fields
doesn't necessarily apply to other systems like HG or Git. My 2c.


On Sat, Aug 24, 2013 at 5:08 PM, Baptiste Mathus  wrote:

> See http://maven.apache.org/pom.html#SCM Hervé is talking about
> xpath:/SCM/url which is indeed a scm web ui and said (developer)Connection
> would be discussed in another thread.
>
> Cheers
> Le 24 août 2013 16:57, "Fred Cooke"  a écrit :
>
> > I understood that the purpose of the SCM *URL* was to be able to *use*
> > it with a tool (where browser != tool), as such, there is only one
> > correct URL, the rest are paths for browsing on a file system or
> > web-front end. I did this knowing it would fail to illustrate the
> > point:
> >
> > fred@cheetah:~/workspaces$ git clone
> > https://git-wip-us.apache.org/repos/asf/maven.git/tree/heads/maven-2.2.x
> > Cloning into 'maven-2.2.x'...
> > fatal:
> >
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/heads/maven-2.2.x/info/refs
> > not found: did you run git update-server-info on the server?
> >
> > On Sat, Aug 24, 2013 at 4:49 PM, Hervé BOUTEMY 
> > wrote:
> > > I made some research and tests and here are my findings
> > >
> > > for the scm url, ie. web access like we have ViewVC url for svn, git
> > provides
> > > GitWeb equivalent to ViewVC (even if a lot of other solutions exist
> [1]),
> > > which is what is configured on Apache git http
> > > Then the GitWeb url format is in the git documentation [2]
> > >
> > > With this format, you can refer to branches, tags and revisions, like
> > > following examples:
> > >
> > > branches:
> > >   HEAD:
> > > https://git-wip-us.apache.org/repos/asf/maven.git/tree/HEAD
> > >   maven-3.0.x:
> > >
> > https://git-wip-us.apache.org/repos/asf/maven.git/tree/heads/maven-3.0.x
> > >   maven-2.2.x:
> > >
> > https://git-wip-us.apache.org/repos/asf/maven.git/tree/heads/maven-2.2.x
> > >
> > > tags:
> > >
> > https://git-wip-us.apache.org/repos/asf/maven.git/tree/tags/maven-3.1.0
> > >
> > https://git-wip-us.apache.org/repos/asf/maven.git/tree/tags/maven-3.0.5
> > >
> > https://git-wip-us.apache.org/repos/asf/maven.git/tree/tags/maven-2.2.1
> > >
> > > revisions: (same examples as previous tags)
> > >
> >
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/5a0e6574404b4964522d90c3438e25574a95466c
> > >
> >
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/fbdd91ba01387485598935fe7d340261239e6a31
> > >
> >
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/238f83f8230b1e0ad3239ca7e4f849591331c801
> > >
> > >
> > > From the GitWeb url format documentation [2], we should be able to
> > navigate
> > > into the reporitory directories by ading ":/", but it fails on
> > Apache
> > > GitWeb installation:
> > >
> > https://git-wip-us.apache.org/repos/asf/maven.git/tree/HEAD:/maven-core
> > > it works on Git's GitWeb installation
> > >   http://repo.or.cz/w/git.git/tree/tags/v1.8.2:/gitweb
> > >
> > > I don't know why Apache GitWeb is failing: previous version? some
> > > configuration?
> > > I know that even if the feature worked, this wouldn't permit us to let
> > Maven
> > > calculate automatically child scm url from parent, since the format
> > requires
> > > ':/' to be added for the first directory:
> > >   http://repo.or.cz/w/git.git/tree/tags/v1.8.2
> > >   http://repo.or.cz/w/git.git/tree/tags/v1.8.2:/gitweb
> > > For actuel Maven to correctly calculate the second from the first, we
> > would
> > > need to write
> > >   http://repo.or.cz/w/git.git/tree/tags/v1.8.2:
> > > or  http://repo.or.cz/w/git.git/tree/tags/v1.8.2:/
> > > which are both unsupported by GitWeb actually
> > >
> > > Notice GitHub's url format works like a charm:
> > > https://github.com/apache/maven/tree/maven-3.1.0
> > > https://github.com/apache/maven/tree/maven-3.1.0/maven-core
> > > https://github.com/apache/maven/tree/maven-3.0.x
> > > https://github.com/apache/maven/tree/maven-3.0.x/maven-core
> > >
> > >
> > > Should we configure scm url to point to GitHub mirror instead of Apache
> > >

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

2013-09-14 Thread Fred Cooke

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, 2013 at 7: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:
>
> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
>
> I know this may not be obvious to the casual observer as they may think
> 3.1 is next, but I'm personally fine with that.
>
> Especially after a failed release because then I don't have to go change
> all the POMs (whether rolling back manually, using the release rollback,
> the version:set command, or whatever else). It's much easier to just fix
> what's necessary and carry on.
>
> Unless anyone objects I would like to go back this pattern, what I
> previously had, because it's far easier to manage. Ideally it might be nice
> if all the tools understood 3.1.z-SNAPSHOT but they don't an in lieu of
> that I would prefer not to diddle POMs after a failed release.
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
>
>
>
>
>
>
>
>

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

2013-09-14 Thread Fred Cooke

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 Sep 14, 2013, at 2:20 PM, Mark Struberg  wrote:
>
> > +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 Maven Core POMs at major.minor-SNAPSHOT
> >>
> >> G ood 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'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, 2013 at 7: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:
> >>>>
> >>>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 -->
> >> 3.1-SNAPSHOT
> >>>>
> >>>> I know this may not be obvious to the casual observer as they may
> think
> >>>> 3.1 is next, but I'm personally fine with that.
> >>>>
> >>>> Especially after a failed release because then I don't have to go
> >> change
> >>>> all the POMs (whether rolling back manually, using the release
> >> rollback,
> >>>> the version:set command, or whatever else). It's much easier to
> >> just fix
> >>>> what's necessary and carry on.
> >>>>
> >>>> Unless anyone objects I would like to go back this pattern, what I
> >>>> previously had, because it's far easier to manage. Ideally it might
> >> be nice
> >>>> if all the tools understood 3.1.z-SNAPSHOT but they don't an in
> >> lieu of
> >>>> that I would prefer not to diddle POMs after a failed release.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Jason
> >>>>
> >>>> --
> >>>> Jason van Zyl
> >>>> Founder,  Apache Maven
> >>>> http://twitter.com/jvanzyl
> >>>> -
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
>
>
>
>
>
>
>
>

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

2013-09-14 Thread Fred Cooke

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 release such that a ff is possible. If changes are required from
failed vote, they are made on master, then a new branch is forked off, and
try again. If not waiting for that, a full merge would be OK too, there
would be no conflict even if the POM had changed in other places. I
personally prefer to avoid them where possible, though.


On Sat, Sep 14, 2013 at 9:15 PM, Mark Struberg  wrote:

> 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
> upstream branches on the central repo.
>
> What might be a solution would be to have a 2nd 'sandbox' GIT repo for
> each of our 'main' GIT repos for a project. The master of this sandbox GIT
> repo would automatically get replicated from the main repo and would deny
> any push to master otherwise. This repo could be used to create temporary
> playground like feature branches etc. History rewrite and deleting branches
> and tags would be allowed on this repo. Might be a way to tackle this on
> ASF hardware without forcing people to use another repo hosting.
>
> LieGrue,
> strub
>
>
>
>
> - Original Message -
> > From: Fred Cooke 
> > To: Maven Developers List 
> > Cc:
> > Sent: Saturday, 14 September 2013, 20:48
> > Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
> >
> > 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 Sep 14, 2013, at 2:20 PM, Mark Struberg  wrote:
> >>
> >>  > +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 Maven Core POMs at major.minor-SNAPSHOT
> >>  >>
> >>  >> G ood 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'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, 2013 at 7: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:
> >>  >>>>
> >>  >>>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2
> > -->
> >>  >> 3.1-SNAPSHOT
> >>  >>>>
> >>  >>

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

2013-09-14 Thread Fred Cooke

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 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 being heavyweight on that subject... Version numbers are cheap
> and we've had borked releases before (eg critical IMHO bugs in 2.1.0, 2.2.0
> and 3.1.0...) so I don't buy the "what if a user checks out a tag that was
> not released" argument.
>
> In my opinion we need a release status page anyway, eg stating whether
> specific versions are considered stabilising, stable, retired or advised
> not to be used... Such a page would remove the need for recycling version
> numbers *and* provide benefit to users at the same time.
>
> But I will leave it for others to fight the relative costs of version
> numbers (given the infinite supply) against making sure JIRA release notes
> and javadoc @since tags (which is stupid, @since 3.2.3 means it should be
> there in the 3.3.0 release that 3.2.3 became, so no fix strictly
> required) are correct and saving the risk that a user checks out an
> unreleased tag and tries to build that from source and then starts trying
> to raise bugs against a non-exist any version!
>
> On Saturday, 14 September 2013, 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 Sep 14, 2013, at 2:20 PM, Mark Struberg  wrote:
> >
> > > +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 Maven Core POMs at major.minor-SNAPSHOT
> > >>
> > >> G ood 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'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, 2013 at 7: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:
> > >>>>
> > >>>> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 -->
> > >> 3.1-SNAPSHOT
> > >>>>
> > >>>> I know this may not be obvious to the casual observer as they may
> > think
> > >>>> 3.1 is next, but I'm personally fine with that.
> > >>>>
> > >>>> Especially after a failed release because then I don't have to go
> > >> change
> > >>>> all the POMs (whether rolling back manually, using the release
> > >> rollback,
> > >>>> the version:set command, or whatever else). It's much easier to
> > >> just fix
> > >>>> what's necessary and carry on.
> > >>>>
> > >>>> Unless anyone objects I would like to go back this pattern, what I
> > >>&

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

2013-09-14 Thread Fred Cooke

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 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.
>
> 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 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 - or would need to get maintained manually.
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > - Original Message -
> >> From: Fred Cooke 
> >> To: Maven Developers List 
> >> Cc:
> >> Sent: Saturday, 14 September 2013, 21:51
> >> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
> >>
> >> 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 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 being heavyweight on that subject... Version numbers are
> cheap
> >>>  and we've had borked releases before (eg critical IMHO bugs in 2.1.0,
> >> 2.2.0
> >>>  and 3.1.0...) so I don't buy the "what if a user checks out a tag
> >> that was
> >>>  not released" argument.
> >>>
> >>>  In my opinion we need a release status page anyway, eg stating whether
> >>>  specific versions are considered stabilising, stable, retired or
> advised
> >>>  not to be used... Such a page would remove the need for recycling
> version
> >>>  numbers *and* provide benefit to users at the same time.
> >>>
> >>>  But I will leave it for others to fight the relative costs of version
> >>>  numbers (given the infinite supply) against making sure JIRA release
> notes
> >>>  and javadoc @since tags (which is stupid, @since 3.2.3 means it
> should be
> >>>  there in the 3.3.0 release that 3.2.3 became, so no fix strictly
> >>>  required) are correct and saving the risk that a user checks out an
> >>>  unreleased tag and tries to build that from source and then starts
> trying
> >>>  to raise bugs against a non-exist any version!
> >>>
> >>>  On Saturday, 14 September 2013, 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 Sep 14, 2013, at 2:20 PM, Mark Struberg 
> >> wrote:
> >>>  >
> >>>  > > +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 Maven Core POMs at major.minor-SNAPSHOT
> >>>  > >>
> >>>  > >> G ood practice too. I'm using it also at work and we are

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

2013-09-14 Thread Fred Cooke

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 millions, maven 3.1.5 after maven 3.1.1, ONLY a complete and utter
moron would be confused by this. Few developers are that stupid, and those
who are have limited months of career as a dev ahead of them. "it's
confusing" holds no water in the context of a hard-core dev tool IMO.


On Sun, Sep 15, 2013 at 1:34 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> 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 giving people a false sense of extra QA... By
> telling people "go to this page where we list the status of each version"
> then they will not be confused at all... Instead they get greater
> confidence...
>
> They will see
>
> * some versions we never released a binary for... Those were really bad
>
> * some versions we released a binary for... And then found critical bugs is
>
> * some versions we released a binary for, but its only recent so there
> could be regressions our test suite missed
>
> * some versions we reased a binary for, have had no serious issues raised
> for the past 6 weeks and are considered stable
>
> * some versions we no longer recommend
>
> As a user such a page gives me much more confidence in the project rather
> than our current "every release is a release" lase fair attitude that saw
> 2.1.0 pushed as the latest for longer than was healthy given the artifact
> signing issues. As a user it also gives me more confidence that once I see
> a new release transition to stable (say 6 weeks) or recommended (say 3
> months) that I am following the project guidelines
>
> I am not saying the version would be missing (the tag would always be
> there) but that a binary or source dist would not...
>
> Everyone is entitled to their opinion... previously it was Maven developers
> who said no missing version... Iirc you are the first to suggest users
> would be confused Have we actually asked users which is more confusing?
>
> On Saturday, 14 September 2013, Jason van Zyl wrote:
>
> > 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 <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > 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 if the
> javadoc
> > > @since tags and even without skipping versions they can end up at a
> > > unreleased version label, plus they are just a >= which will be valid
> > anyway
> > >
> > >
> > >>
> > >> 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 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 - or would need to get maintained manually.
> > >>>
> > >>>
> > >>> LieGrue,
> > >>> strub
> > >>>
> > >>>
> > >>>
> > >>> - Original Message -
> > >>>> From: Fred Cooke 
> > >>>> To: Maven Developers List 
> > >>>> Cc:
> > >>>> Sent: Saturday, 14 September 2013, 21:51
> > >>>> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
> > >>>>
> > >>>> I agree on skipping failed versions! I was avoiding the topic
> because
>

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

2013-09-14 Thread Fred Cooke

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 of them, in fact.

Preferring not to have gaps is a choice and one I was aware you lot would
make. That's why I didn't bring it up in the first place despite preferring
to just straight miss them. Or just straight publish all releases (as is
normal mvn practice since forever) and direct users to the ones that
work... I *think* this is what Stephen is trying to say, but if I'm honest
I missed out a lot of what he wrote. Forgive me, it's 2am here.


On Sun, Sep 15, 2013 at 2:00 AM, Jason van Zyl  wrote:

> 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
> whether you know of any projects, or products, that do this? Just because
> we can skip versions isn't a good reason to do so. If lots of projects do
> it then it's worth considering. Have any examples on hand?
>
> For now while I'm doing the core releases, I would prefer not to have
> gaps. Call me provincial, but I'd like to do what we've always done since
> the inception of the project unless there is a compelling reason to do
> otherwise.
>
> On Sep 14, 2013, at 7:48 PM, Fred Cooke  wrote:
>
> > 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 millions, maven 3.1.5 after maven 3.1.1, ONLY a complete and utter
> > moron would be confused by this. Few developers are that stupid, and
> those
> > who are have limited months of career as a dev ahead of them. "it's
> > confusing" holds no water in the context of a hard-core dev tool IMO.
> >
> >
> > On Sun, Sep 15, 2013 at 1:34 AM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> >> 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 giving people a false sense of extra QA... By
> >> telling people "go to this page where we list the status of each
> version"
> >> then they will not be confused at all... Instead they get greater
> >> confidence...
> >>
> >> They will see
> >>
> >> * some versions we never released a binary for... Those were really bad
> >>
> >> * some versions we released a binary for... And then found critical
> bugs is
> >>
> >> * some versions we released a binary for, but its only recent so there
> >> could be regressions our test suite missed
> >>
> >> * some versions we reased a binary for, have had no serious issues
> raised
> >> for the past 6 weeks and are considered stable
> >>
> >> * some versions we no longer recommend
> >>
> >> As a user such a page gives me much more confidence in the project
> rather
> >> than our current "every release is a release" lase fair attitude that
> saw
> >> 2.1.0 pushed as the latest for longer than was healthy given the
> artifact
> >> signing issues. As a user it also gives me more confidence that once I
> see
> >> a new release transition to stable (say 6 weeks) or recommended (say 3
> >> months) that I am following the project guidelines
> >>
> >> I am not saying the version would be missing (the tag would always be
> >> there) but that a binary or source dist would not...
> >>
> >> Everyone is entitled to their opinion... previously it was Maven
> developers
> >> who said no missing version... Iirc you are the first to suggest users
> >> would be confused Have we actually asked users which is more
> confusing?
> >>
> >> On Saturday, 14 September 2013, Jason van Zyl wrote:
> >>
> >>> I don't agree. I think t

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

2013-09-15 Thread Fred Cooke

Your poll is a special case, which was separated in the discussions. For
all cases, but especially your special case, a good solution is to do what
some other ASF project does, and vote on SCM, then release once. They build
snapshots (gasp, maven concept in use, and IIRC they don't even use maven),
deploy them somewhere temporary, review, discuss, vote, then either fix and
respin temp stuff, or release proper. This makes a HUGE amount of sense and
is what the gods of Maven have taught me since I was a little boy.
Generally good practice too. Plus, yeah, I'd argue that they are indeed
morons :-p "Maven 4 has been released get it here " (4.1.3 is
totally absurd...) should confuse no one except morons.

What has LTS got to do with this? Irrelevant as far as I can tell.

Deleting tags is always bad, but in Git it's downright stupid.

Fred.




On Sun, Sep 15, 2013 at 1:18 PM, Robert Scholte wrote:

> That someone might have been me.
> I did an internal poll to ask if people would understand if Maven would
> jump from 3.0.5 to 4.1.3.
> None of them did, they all wondered what happened to the missing versions.
> Sure they understand that 4.1.3 is newer than 3.0.5, these aren't morons.
>
> One major difference is that Maven can't update itself to the latest
> version. If that would be the case, then versions are only interesting to
> reproduce issues and people often wouldn't see/matter the version.
>
> *If* we would allow gaps, we should also introduce LTS releases.
>
> For now, I'd prefer reusing versions and no gaps. I don't mind deleting
> tags, otherwise I'd prefer the usage of RCx during votes.
>
> Robert
>
> Op Sun, 15 Sep 2013 02:05:55 +0200 schreef Fred Cooke <
> fred.co...@gmail.com>:
>
>
>  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 of them, in fact.
>>
>> Preferring not to have gaps is a choice and one I was aware you lot would
>> make. That's why I didn't bring it up in the first place despite
>> preferring
>> to just straight miss them. Or just straight publish all releases (as is
>> normal mvn practice since forever) and direct users to the ones that
>> work... I *think* this is what Stephen is trying to say, but if I'm honest
>> I missed out a lot of what he wrote. Forgive me, it's 2am here.
>>
>>
>> On Sun, Sep 15, 2013 at 2:00 AM, Jason van Zyl  wrote:
>>
>>  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
>>> whether you know of any projects, or products, that do this? Just because
>>> we can skip versions isn't a good reason to do so. If lots of projects do
>>> it then it's worth considering. Have any examples on hand?
>>>
>>> For now while I'm doing the core releases, I would prefer not to have
>>> gaps. Call me provincial, but I'd like to do what we've always done since
>>> the inception of the project unless there is a compelling reason to do
>>> otherwise.
>>>
>>> On Sep 14, 2013, at 7:48 PM, Fred Cooke  wrote:
>>>
>>> > 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 millions, maven 3.1.5 after maven 3.1.1, ONLY a complete and utter
>>> > moron would be confused by this. Few developers are that stupid, and
>>> those
>>> > who are have limited months of career as a dev ahead of them. "it's
>>> > confusing" holds no water in the context of a hard-core dev tool IMO.
>>> >
>>> >
>>> > On Sun, Sep 15, 2013 at 1:34 AM, Stephen Connolly <
>>> > stephen.alan.connolly@gmail.**com >
>>> wrote:
>>> >
>>> >> The difference is that you say those versions did not pass QA.
>>> >>
>>> >> As a user

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

2013-09-15 Thread Fred Cooke

Exactly! :-)


On Sun, Sep 15, 2013 at 1:29 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> But you asked the wrong jump then.
>
> It would be 3.0.5 to 4.0.4... There's no way we'd skip 4.0.x to go to 4.1.x
> if we have not had a 4.0.x released at all.
>
> My point is patch version people are perfectly fine with skips Minor
> version skips would be bad, but there is zero need for them.
>
> On Sunday, 15 September 2013, Robert Scholte wrote:
>
> > That someone might have been me.
> > I did an internal poll to ask if people would understand if Maven would
> > jump from 3.0.5 to 4.1.3.
> > None of them did, they all wondered what happened to the missing
> versions.
> > Sure they understand that 4.1.3 is newer than 3.0.5, these aren't morons.
> >
> > One major difference is that Maven can't update itself to the latest
> > version. If that would be the case, then versions are only interesting to
> > reproduce issues and people often wouldn't see/matter the version.
> >
> > *If* we would allow gaps, we should also introduce LTS releases.
> >
> > For now, I'd prefer reusing versions and no gaps. I don't mind deleting
> > tags, otherwise I'd prefer the usage of RCx during votes.
> >
> > Robert
> >
> > Op Sun, 15 Sep 2013 02:05:55 +0200 schreef Fred Cooke <
> > fred.co...@gmail.com>:
> >
> >  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 of them, in fact.
> >
> > Preferring not to have gaps is a choice and one I was aware you lot would
> > make. That's why I didn't bring it up in the first place despite
> preferring
> > to just straight miss them. Or just straight publish all releases (as is
> > normal mvn practice since forever) and direct users to the ones that
> > work... I *think* this is what Stephen is trying to say, but if I'm
> honest
> > I missed out a lot of what he wrote. Forgive me, it's 2am here.
> >
> >
> > On Sun, Sep 15, 2013 at 2:00 AM, Jason van Zyl  wrote:
> >
> >  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
> > whether you know of any projects, or products, that do this? Just because
> > we can skip versions isn't a good reason to do so. If lots of projects do
> > it then it's worth considering. Have any examples on hand?
> >
> > For now while I'm doing the core releases, I would prefer not to have
> > gaps. Call me provincial, but I'd like to do what we've always done since
> > the inception of the project unless there is a compelling reason to do
> > otherwise.
> >
> > On Sep 14, 2013, at 7:48 PM, Fred Cooke  wrote:
> >
> > > 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 millions, maven 3.1.5 after maven 3.1.1, ONLY a complete and utter
> > > moron would be confused by this. Few developers are that stupid, and
> > those
> > > who are have limited months of career as a dev ahead of them. "it's
> > > confusing" holds no water in the context of a hard-core dev tool IMO.
> > >
> > >
> > > On Sun, Sep 15, 2013 at 1:34 AM, Stephen Connolly <
> > > stephen.alan.conno...@gmail.com> wrote:
> > >
> > >> 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 giving people a false sense of extra QA... By
> > >> telling people "go to this page where we list the status of each
&g

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

2013-09-15 Thread Fred Cooke

That's why I said to use branches. Braches XOR skip versions. I prefer the
latter, though they can be mixed too.


On Mon, Sep 16, 2013 at 1:22 AM, sebb  wrote:

> Some other ASF PMCs have no qualms about skipping version numbers.
>
> For example AIUI Tomcat creates a release candidate, and if the vote
> fails, they bump the patch version.
> For example they released 7.0.30 and 7.0.32; there is no 7.0.31.
>
> The other point I would make is that bumping the way the release
> plugin currently works has some problems.
> It should not update trunk until the release succeeds.
> There would then be no need to fix up trunk if a release vote fails.
> See MRELEASE-721
>
>
> On 15 September 2013 13:49, Stephen Connolly
>  wrote:
> > Another data point is exactly how many times have we got patch release
> .0 right?
> >
> > 2.1.0 - seriously borked use 2.2.1
> > 2.2.0 - seriously borked use 2.2.1
> > 3.0.0-3.0.2 - not recommended for use
> > 3.0.3 - ok but has issues with release plugin
> > 3.0.4 - first 3.x that could be considered stable
> > 3.1.0 - borked enough to recommend not for production IMHO
> >
> > From experience I, as a PMC member, do not recommend my day job picking
> up a x.y.0 from Maven... So why should we hold patch numbers as special
> enough that they must increase by 1 between "blessed" releases *when we
> cannot even guarantee that a "blessed" release is ready for production?*
> >
> > Maybe we should split this into another DISCUSS thread, though I am
> conscious that this subject is distracting from actually getting releases
> out the door... OTOH allowing skips in patch release numbers would allow
> work on core to continue without having to coordinate a "nobody commit to
> master while vote in play" policy which seems completely against how one
> should use GIT
> >
> > Sent from my iPhone
> >
> > On 15 Sep 2013, at 12:30, Fred Cooke  wrote:
> >
> >> Exactly! :-)
> >>
> >>
> >> On Sun, Sep 15, 2013 at 1:29 PM, Stephen Connolly <
> >> stephen.alan.conno...@gmail.com> wrote:
> >>
> >>> But you asked the wrong jump then.
> >>>
> >>> It would be 3.0.5 to 4.0.4... There's no way we'd skip 4.0.x to go to
> 4.1.x
> >>> if we have not had a 4.0.x released at all.
> >>>
> >>> My point is patch version people are perfectly fine with skips
> Minor
> >>> version skips would be bad, but there is zero need for them.
> >>>
> >>> On Sunday, 15 September 2013, Robert Scholte wrote:
> >>>
> >>>> That someone might have been me.
> >>>> I did an internal poll to ask if people would understand if Maven
> would
> >>>> jump from 3.0.5 to 4.1.3.
> >>>> None of them did, they all wondered what happened to the missing
> >>> versions.
> >>>> Sure they understand that 4.1.3 is newer than 3.0.5, these aren't
> morons.
> >>>>
> >>>> One major difference is that Maven can't update itself to the latest
> >>>> version. If that would be the case, then versions are only
> interesting to
> >>>> reproduce issues and people often wouldn't see/matter the version.
> >>>>
> >>>> *If* we would allow gaps, we should also introduce LTS releases.
> >>>>
> >>>> For now, I'd prefer reusing versions and no gaps. I don't mind
> deleting
> >>>> tags, otherwise I'd prefer the usage of RCx during votes.
> >>>>
> >>>> Robert
> >>>>
> >>>> Op Sun, 15 Sep 2013 02:05:55 +0200 schreef Fred Cooke <
> >>>> fred.co...@gmail.com>:
> >>>>
> >>>> 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 of them, in fact.
> >>>>
> >>>> Preferring not to have gaps is a choice and one I was aware you lot
> would
> >>>> make. That's why I didn't bring it up in the first place despite
> >>> preferring
> >>>> to just straight miss them. Or just straight publish all releases (as
> is
> >>>> normal mvn practice since forever) a

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

2013-09-16 Thread Fred Cooke

Version ranges are extremely useful for this case: lib 0.2.4 >> 0.3.0 non
inclusive where lib has a guaranteed stable API with only non-breaking bug
fixes and additions. There are other uses, too. I sincerely hope it's never
dropped or broken.


On Mon, Sep 16, 2013 at 10:09 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On 16 September 2013 08:20, Jörg Schaible  >wrote:
>
> > Hi Jason,
> >
> > 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:
> > >
> > > 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
> > >
> > > I know this may not be obvious to the casual observer as they may think
> > > 3.1 is next, but I'm personally fine with that.
> >
> > That's quite funny, because we did this years ago when we started using
> M2
> > and then we were told here in the list it is an anti-pattern, because
> 3.1-
> > SNAPSHOT is always minor for the dependency resolution than any 3.1.x
> > release.
> >
> >
> That was before it was decided that version ranges were a bad plan. If we
> were using version ranges then this would indeed be crapulent
>
>
> > - Jörg
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

2013-09-16 Thread Fred Cooke

Fair call.


On Mon, Sep 16, 2013 at 1:39 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On 16 September 2013 12:26, Fred Cooke  wrote:
>
> > Version ranges are extremely useful for this case: lib 0.2.4 >> 0.3.0 non
> > inclusive where lib has a guaranteed stable API with only non-breaking
> bug
> > fixes and additions. There are other uses, too. I sincerely hope it's
> never
> > dropped or broken.
> >
> >
> What I want to see, and it would be a change that requires a POM
> specification change, is that version ranges are never provided without a
> "recommended" version.
>
> So I would see something like 1.0.3:[1.0.0,1.1.0),[1.1.1,2.0.0) as meaning
> use 1.0.3 but it should work with anything >= 1.0.0 and < 1.1.0 or >=1.1.1
> but < 2.0.0 (presumably 1.1.0 is known broken)
>
> You could even allow meta-labels when the pom itself is a -SNAPSHOT
> version, e.g.
>
> SNAPSHOT:[1.0.0,1.1.0),[1.1.1,2.0.0)
> LATEST:[1.0.0,1.1.0),[1.1.1,2.0.0)
> STABLE:[1.0.0,1.1.0),[1.1.1,2.0.0)
>
> The first says pick the highest version that is in the range and -SNAPSHOT
> is allowed
> The second says pick the highest release version that is in the range,
> -SNAPSHOT is not allowed
> The third says pick the lowest release version that is in the range,
> -SNAPSHOT is not allowed
>
> When the release plugin runs, it would replace the SNAPSHOT, LATEST or
> STABLE with the most appropriate corresponding release version *at the time
> of release*.
>
> Thus release builds are reproducible always and developers would not need
> to worry about updating poms. Some tooling or CLI options on Maven could
> allow for switching a build from the meta-label in the POM to a specific
> meta-label so that CI builds could probe the extremes easily... and I am
> sure we could provide additional tooling to probe data points within the
> various ranges.
>
> But I would like to see naked ranges dropped from release builds as they
> lead to irreproducible release builds, which is a very bad thing
>
>
> > On Mon, Sep 16, 2013 at 10:09 AM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > On 16 September 2013 08:20, Jörg Schaible  > > >wrote:
> > >
> > > > Hi Jason,
> > > >
> > > > 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:
> > > > >
> > > > > 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT
> > > > >
> > > > > I know this may not be obvious to the casual observer as they may
> > think
> > > > > 3.1 is next, but I'm personally fine with that.
> > > >
> > > > That's quite funny, because we did this years ago when we started
> using
> > > M2
> > > > and then we were told here in the list it is an anti-pattern, because
> > > 3.1-
> > > > SNAPSHOT is always minor for the dependency resolution than any 3.1.x
> > > > release.
> > > >
> > > >
> > > That was before it was decided that version ranges were a bad plan. If
> we
> > > were using version ranges then this would indeed be crapulent
> > >
> > >
> > > > - Jörg
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > >
> > >
> >
>

Re: [VOTE] Release Maven 3.1.1

2013-10-03 Thread Fred Cooke

+1 even if I'm late to the epic party. Love the sebbaliser, great work, and
sense of humour, Jason! Dislike his lack of enthusiasm for the name. I'd
have bragged about it for years if you'd called it the fredaliser :-)
Unfortunately I am too busy to continue nagging. Good on sebb for picking
up the slack and keeping the pressure on.


On Mon, Sep 30, 2013 at 10:39 PM, Robert Scholte wrote:

> +1
>
> Op Wed, 25 Sep 2013 17:22:45 +0200 schreef Jason van Zyl :
>
>
>  Anyone else going to give the release a whirl?
>>
>> On Sep 17, 2013, at 8:39 AM, Jason van Zyl  wrote:
>>
>>  Hi,
>>>
>>> Maven Core ITs are good, and the license/notice issue has been resolved
>>> so I'm rolling 3.1.1 again.
>>>
>>> Here is a link to Jira with 6 issues resolved:
>>> https://jira.codehaus.org/**secure/ReleaseNote.jspa?**
>>> projectId=10500&version=18968
>>>
>>> Staging repo:
>>> https://repository.apache.org/**content/repositories/maven-**065/
>>>
>>> The distributable binaries and sources for testing can be found here:
>>> https://repository.apache.org/**content/repositories/maven-**
>>> 065/org/apache/maven/apache-**maven/3.1.1/
>>>
>>> Specifically the zip, tarball, and source archives can be found here:
>>> https://repository.apache.org/**content/repositories/maven-**
>>> 065/org/apache/maven/apache-**maven/3.1.1/apache-maven-3.1.**1-bin.zip
>>> https://repository.apache.org/**content/repositories/maven-**
>>> 065/org/apache/maven/apache-**maven/3.1.1/apache-maven-3.1.**
>>> 1-bin.tar.gz
>>> https://repository.apache.org/**content/repositories/maven-**
>>> 065/org/apache/maven/apache-**maven/3.1.1/apache-maven-3.1.**1-src.zip
>>> https://repository.apache.org/**content/repositories/maven-**
>>> 065/org/apache/maven/apache-**maven/3.1.1/apache-maven-3.1.**
>>> 1-src.tar.gz
>>>
>>> Source release checksum(s):
>>> apache-maven-3.1.1-src.zip sha1: 2251357aa47129674df578e787504b**
>>> 72cd57ed4d
>>>
>>> Staging site:
>>> http://people.apache.org/~**jvanzyl/maven-3.1.1/
>>>
>>> Vote open for 72 hours.
>>>
>>> [ ] +1
>>> [ ] +0
>>> [ ] -1
>>>
>>> Thanks,
>>>
>>> The Maven Team
>>> Thanks,
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> Thanks,
>>
>> Jason
>>
>> --**
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> --**---
>>
>>
>>
>>
>>
>>
>>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@maven.apache.**org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [ANN] Maven 3.1.1 Release

2013-10-04 Thread Fred Cooke

Congratulations, Jason! :-)


On Fri, Oct 4, 2013 at 10:56 PM, Jason van Zyl  wrote:

> Hi!
>
> The Apache Maven Team is pleased to announce the release of 3.1.1
>
> The release notes can be found here:
> http://maven.apache.org/docs/3.1.1/release-notes.html
>
> The release can be downloaded from:
> http://maven.apache.org/download.cgi
>
> The changes in this release are as follows:
>
> Bug:
> [MNG-5459] - failure to resolve pom artifact from snapshotVersion in
> maven-metadata.xml
> [MNG-5495] - API incompatibility causes Swagger Maven Plugin (and others)
> to fail under Maven 3.1.0
> [MNG-5499] - maven-aether-provider leaks Sisu Plexus and ObjectWeb classes
> onto the classpath when they are not required
> [MNG-5500] - help for --legacy-local-repository option explains
> _maven.repositories instead of _remote.repositories
> [MNG-5503] - Maven 3.1.0 fails to resolve artifacts produced by reactor
> build
> [MNG-5509] - org.apache.maven.repository.legacy.DefaultWagonManager should
> set User-Agent
>
> Thanks,
>
> The Maven Team
>
>
>
>
>
>
>

Re: Maven Core moving to 1.6

2013-10-07 Thread Fred Cooke

+1 too, 1.5 is dead for me.


On Mon, Oct 7, 2013 at 8:12 PM, Dennis Lundberg wrote:

> +1 to 1.6 for 3.2
>
> On Sat, Oct 5, 2013 at 5:03 AM, Jason van Zyl  wrote:
> > Given the vote we had about releases after September does anyone mind if
> I update the source/target levels to 1.6 for the core?
> >
> > Thanks,
> >
> > Jason
> >
> > --
> > Jason van Zyl
> > Founder,  Apache Maven
> > http://twitter.com/jvanzyl
> > -
> >
> >
> >
> >
> >
> >
> >
>
>
>
> --
> Dennis Lundberg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Apache Maven SCM 1.9

2013-10-24 Thread Fred Cooke

+1 list looks good.

Beware of jgit and symlinks, though, you can end up with a lot of disk and
cpu churn because of it if not careful.


On Thu, Oct 24, 2013 at 5:35 AM, Olivier Lamy  wrote:

> Hi,
> We fixed 9 issues. The new feature is the jgit provider (based on jgit).
> Details:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10527&version=18783
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-027/
> Staged site: http://maven.apache.org/scm-archives/scm-LATEST/
>
> Sources release:
>
> https://repository.apache.org/content/repositories/maven-027/org/apache/maven/scm/maven-scm/1.9/maven-scm-1.9-source-release.zip
>
> Vote open for 72H
>
> [+1]
> [0]
> [-1]
>
>
> Thanks
> --
> Olivier Lamy
> Ecetera: http://ecetera.com.au
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Convert everything to Git

2014-02-12 Thread Fred Cooke

I like you more and more! :-)


On Thu, Feb 13, 2014 at 4:37 PM, Jason van Zyl  wrote:

> Can we start the process of converting everything to Git. I don't really
> see any benefit in using Subversion any longer.
>
> If so then we should just get together for a day and convert them and then
> get infra to use what we converted to do the flip.
>
> Jason (who would be happy to never execute svn again)
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Convert everything to Git

2014-02-12 Thread Fred Cooke

The SVN repo should probably be retained anyway, just in RO format, and
with a new URL that indicates it shouldn't be used. You can try to retain
all history, but it's never quite in the same form, really. Perhaps no one
cares, though?

+1 for decompose into individual repos.

Fred.

PS, perhaps one day we'll meet, who knows. :-p



On Thu, Feb 13, 2014 at 5:50 PM, Jason van Zyl  wrote:

> Probably a little more decompose like a repository for each plugin and
> shared component. No reason all history can't be retained.
>
> On Feb 12, 2014, at 11:03 PM, Mark Derricutt  wrote:
>
> > Do you envisage one master git repo, or multiple repositories for each
> moveable piece?
> >
> > Full history retainment?
> >
> > On 13 Feb 2014, at 16:37, Jason van Zyl wrote:
> >
> >> Can we start the process of converting everything to Git. I don't
> really see any benefit in using Subversion any longer.
> >>
> >> If so then we should just get together for a day and convert them and
> then get infra to use what we converted to do the flip.
> >>
> >> Jason (who would be happy to never execute svn again)
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> To do two things at once is to do neither.
>
>  -- Publilius Syrus, Roman slave, first century B.C.
>
>
>
>
>
>
>
>
>
>

Re: Convert everything to Git

2014-02-13 Thread Fred Cooke

Great posts, Jason! There are so many reasons to dump SVN, but controlled
branch sharing and personal work flow are big ones for me, too. I have a
dozen or more local branches of my project, too, and like you, I rebase
against what I publish until they're ready, then publish them, and rebase
the others, etc. It gives you immense power to work freely and experiment
and ultimately contribute higher quality material once you finally publish.
But I'm clearly preaching to the choir ;-)


On Fri, Feb 14, 2014 at 8:29 AM, Jason van Zyl  wrote:

> On Feb 13, 2014, at 12:28 PM, Hervé BOUTEMY  wrote:
>
> > Le jeudi 13 février 2014 08:27:14 Jason van Zyl a écrit :
> >> On Feb 13, 2014, at 1:36 AM, Hervé BOUTEMY 
> wrote:
> >>> the only show stopper I know is for svn trunk which contains a lot of
> >>> components
> >>>
> >>> so -1 for plugins, shared, skins, resources
> >>
> >> Why wouldn't you put something with its own release cycle in its own
> >> repository?
> > because plugins = 44 entries, shared = 20 entries, skins = 6 entries,
> > resources = 5 entries
> > sum = 75 entries
> >
> > each entry would mean 1 git repo + 1Jenkins job (or even more, since
> plugins
> > have multiple Jenkins jobs: 1 for Maven 2.2.x, 1 for Maven 3.0.x, 1 for
> Maven
> > 3.1.x)
> > IMHO, we're not ready for such granularity, neither at git nor Jenkins
> level
>
> I'm used to more granularity in Git, if something has a separate lifecycle
> it doesn't bother me to have a different repo for it. In the case where
> there are a bunch of things that have different artifactIds but really only
> get released together then group those together. I can't speak to what
> Jenkins can handle.
>
> >
> >
> >>> but no problem for me for other release roots containing only one
> >>> component
> >>> [1]
> >>>
> >>> notice I don't see much gain: did we get much patches for components
> >>> already in git? did nobody send a patch through github for a svn
> >>> component replicated to github? Is everybody fluent with git (I still
> ses
> >>> much "merge" commits in git)
> >>> So what's the rationale, really? (apart from bashing one scm over the
> >>> other, in one or another direction)
> >>
> >> The biggest win for me is working on branches. Working with branches in
> SVN
> >> is horrible, only worse in p4 which is saying a lot.
> > what is "p4"?
>
> Perforce.
>
> > which component from the 75 previous entries have branches? should
> require
> > branches?
> >
>
> For Maven core I have 10 branches locally, I share some of them with
> others and this is very easy with Git. This is the issue with SVN, it's so
> cumbersome to make branches and use them no one does.
>
> >> The ability to easily
> >> create branches, squash commits, incrementally improve them without
> fear. I
> >> constantly rebase against master and it's really easy with all the great
> >> tools like GitX, GitTower, or SourceTree to easily see changes. The
> Eclipse
> >> support for Git is a million times better, and doing anything Git
> related
> >> with JGit in Java is always a pleasure (because the #2 CGit guy, wrote
> >> JGit)
> > do you mean you intend to contribute to other components than core?
> >
>
> I think it would make it easier for anyone to contribute if they wanted to.
>
> >>
> >> As far as potential contribution if you look at Apache projects at
> Github
> >> there are varying numbers of forks and pull requests but for some of
> them
> >> it's pretty significant.
> >>
> >> But for me it's a primarily a personal workflow issue.
> >>
> >>> So I'm -0 on such a change for parts where I feel it would be feasible
> >>>
> >>> Regards,
> >>>
> >>> Hervé
> >>>
> >>> [1]
> >>>
> https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/d
> >>> ist-tool-check-source-release.html>
> >>> Le mercredi 12 février 2014 22:37:36 Jason van Zyl a écrit :
>  Can we start the process of converting everything to Git. I don't
> really
>  see any benefit in using Subversion any longer.
> 
>  If so then we should just get together for a day and convert them and
>  then
>  get infra to use what we converted to do the flip.
> 
>  Jason (who would be happy to never execute svn again)
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>  For additional commands, e-mail: dev-h...@maven.apache.org
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> --
> >> Jason van Zyl
> >> Founder,  Apache Maven
> >> http://twitter.com/jvanzyl
> >> http://twitter.com/takari_io
> >> -
> >>
> >> Our achievements speak for themselves. What we have to keep track
> >> of are our failur

Re: Convert everything to Git

2014-02-13 Thread Fred Cooke

I have my private git repo setup in a nested way. No reason you couldn't do
that the same for this.

baseurl/org/apache/mvn/core/componentA.git

etc.

Unsure if this addresses your concerns or not, but it's certainly neat and
tidy at the server end, and the user can duplicate the path structure the
same at home.

Fred.


On Fri, Feb 14, 2014 at 7:33 PM, Hervé BOUTEMY wrote:

> I'm not a git expert: if there are solutions, yes, they have to be found,
> explained, tested, before we launch "convert everything to git"
>
> thank you for any good idea and then any tests from people wanting the
> great
> migration to happen (without wreaking havoc)
>
> Regards,
>
> Hervé
>
> Le vendredi 14 février 2014 17:10:07 Mark Derricutt a écrit :
> > Jenkins could build from a super-repo that uses git submodule.
> >
> > Since a quite a few versions ago, git-submodules can now follow a branch
> > rather than a fixed SHA1.
> >
> > So you could build/test monolithically, branch/commit individually.
> >
> > Compromise maybe?
> >
> > On 14 Feb 2014, at 6:28, Hervé BOUTEMY wrote:
> > > each entry would mean 1 git repo + 1Jenkins job (or even more, since
> > > plugins
> > > have multiple Jenkins jobs: 1 for Maven 2.2.x, 1 for Maven 3.0.x, 1
> > > for Maven
> > > 3.1.x)
> > > IMHO, we're not ready for such granularity, neither at git nor Jenkins
> > > level
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Convert everything to Git

2014-02-14 Thread Fred Cooke

Some of the converters/one of the converters correctly creates git tags
from svn branches, however I'm unsure what happens if the "tag" has been
committed to as sometimes happens with n00b devs in SVN land.


On Fri, Feb 14, 2014 at 9:31 PM, Lennart Jörelid
wrote:

> While I agree that the migration from Subversion to Git can be somewhat
> labour-intensive,
> it can be an ongoing activity, simply migrating piece by piece.
>
> Since there is a particular issue with the Maven release plugin creating
> what is normally
> interpreted as Git branches (as opposed to Git tags) one does normally need
> to run some
> correct-the-history type scripts following the standard migration. Of
> course, the more nonstandard
> of a Subversion stucture one originates from, the more complex these
> scripts become.
>
> The migration itself is - in my experience - something fairly
> straightforward.
> It's the script-to-correct-history phase which follows the VCS migration
> that is somewhat cumbersome.
>
> ... and it therefore becomes important to migrate big repos piece by piece.
>
>
> 2014-02-14 9:23 GMT+01:00 Kristian Rosenvold  >:
>
> > I think the main problem with especially maven-plugins is the sheer
> amount
> > of work required to convert these to individual repositories, especially
> > due to the somewhat not-good structure of the current clone.
> >
> > The others should be fairly straight forward, splitting maven-shared
> > included.
> >
> > Kristian
> >
> >
> >
> >
> >
> > 2014-02-14 9:19 GMT+01:00 Hervé BOUTEMY :
> >
> > > No doubt it can be done in general, but the question is on ASF
> > (canonical)
> > > git
> > > repo [1]
> > > at the moment, everything seems flat
> > > IMHO, some git expert should work with infra to make it more structured
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > [1] https://git-wip-us.apache.org/repos/asf
> > >
> > > Le vendredi 14 février 2014 20:23:34 Fred Cooke a écrit :
> > > > I have my private git repo setup in a nested way. No reason you
> > couldn't
> > > do
> > > > that the same for this.
> > > >
> > > > baseurl/org/apache/mvn/core/componentA.git
> > > >
> > > > etc.
> > > >
> > > > Unsure if this addresses your concerns or not, but it's certainly
> neat
> > > and
> > > > tidy at the server end, and the user can duplicate the path structure
> > the
> > > > same at home.
> > > >
> > > > Fred.
> > > >
> > > > On Fri, Feb 14, 2014 at 7:33 PM, Hervé BOUTEMY <
> herve.bout...@free.fr
> > > >wrote:
> > > > > I'm not a git expert: if there are solutions, yes, they have to be
> > > found,
> > > > > explained, tested, before we launch "convert everything to git"
> > > > >
> > > > > thank you for any good idea and then any tests from people wanting
> > the
> > > > > great
> > > > > migration to happen (without wreaking havoc)
> > > > >
> > > > > Regards,
> > > > >
> > > > > Hervé
> > > > >
> > > > > Le vendredi 14 février 2014 17:10:07 Mark Derricutt a écrit :
> > > > > > Jenkins could build from a super-repo that uses git submodule.
> > > > > >
> > > > > > Since a quite a few versions ago, git-submodules can now follow a
> > > branch
> > > > > > rather than a fixed SHA1.
> > > > > >
> > > > > > So you could build/test monolithically, branch/commit
> individually.
> > > > > >
> > > > > > Compromise maybe?
> > > > > >
> > > > > > On 14 Feb 2014, at 6:28, Hervé BOUTEMY wrote:
> > > > > > > each entry would mean 1 git repo + 1Jenkins job (or even more,
> > > since
> > > > > > > plugins
> > > > > > > have multiple Jenkins jobs: 1 for Maven 2.2.x, 1 for Maven
> > 3.0.x, 1
> > > > > > > for Maven
> > > > > > > 3.1.x)
> > > > > > > IMHO, we're not ready for such granularity, neither at git nor
> > > Jenkins
> > > > > > > level
> > > > > >
> > > > > >
> > -
> > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>
>
>
> --
>
> --
> +==+
> | Bästa hälsningar,
> | [sw. "Best regards"]
> |
> | Lennart Jörelid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | Mölnlycke - Kista
> |
> | Email: l...@jguru.se
> | URL:   www.jguru.se
> | Phone
> | (skype):jgurueurope
> | (intl): +46 708 507 603
> | (domestic): 0708 - 507 603
> +==+
>

Re: Towards faster releases

2014-02-18 Thread Fred Cooke

Perhaps a stupid question, however if no change goes in, and it kicks off
and gives the same gold star as the previous week, then there's no point to
releasing it, because it's the same thing, what takes care of this? Just
the human going "well, actually there were no commits, so this email is
spurious"?

I see no problem with a thorough test rig like this, though. It seems
purely positive. And if phrased more like "This gold star means it's OK to
make a release" as opposed to "This gold star means a human should think
about making a release" then it'd provoke no  technical offense, probably.

Releases are inherently human. It could be that it gold star with 3 out of
a 5 commit patch that makes no sense to release, even if it passes all
tests (tests missing?). You get a release out by making a clear decision
about what will be in it, working towards that solidly, and not creeping to
other related/new things. If at some point you realise you bit off more
than could be chewed, you trim the excess and re-decide what'll be in the
release, which brings it closer, or even to the point of occurring.

My 2c about which I welcome feedback and abuse. :-)

Fred.


On Wed, Feb 19, 2014 at 11:19 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Tuesday, 18 February 2014, Jason van Zyl  wrote:
>
> >
> > On Feb 18, 2014, at 11:47 AM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com > wrote:
> >
> > > Well all this will be for the moment is a reminder that the best tests
> we
> > > have say it is releasable and that a *human* can think about cutting a
> > > release.
> > >
> > > Right now it will fail to notify because there are failing integration
> > > tests (need a 3.2.1 in central to fix the three failing tests)
> > >
> > > If we switch master to a 4.x line I will switch the job to follow the
> > 3.2.x
> > > branch.
> > >
> >
> > I think that will be a few weeks as I'm in the middle of trying to punch
> > out flipping the core to jsr330, refactor some of the resolution and get
> us
> > to a place where we can make a punch list of what we're going to eject
> from
> > the core. I think once everything is marked as deprecated we'll have to
> > make some decisions about what we're going to nuke for the 4.x. I think
> we
> > need to make at least one release once everything is deprecated, maybe it
> > doesn't matter.
> >
> > > What I want this to do is ensure that any fixes for 3.2.x get released
> > > quickly.
> > >
> >
> > Sure, I don't disagree but again I think it's curating the issues and
> > having something to release. The core issue is having something to
> release.
>
>
> Which is what the build chain establishes. If the hash gets a gold star, we
> have something to consider releasing and a mail suggesting that we should
> cut a release
>
>
> >  I plan to work on the 3.2.2 list and maybe we agree to leave it that
> size
> > and when it's done release it. I would rather agree that a set of issues
> > are in a release and release it when it's done, and if it's taking too
> long
> > shear off some issues and release.
> >
> > > The major changes will be towards 4.x, where a slower release cycle is
> > fine.
> > >
> > > Given that 3.2.x should only have bug fixes how do you see this as
> risky?
> >
> > That it's releasing for releasing sake, and not trying to address the
> real
> > issue of lack of movement in the core. I think if you fix some bugs it's
> > fine for them to collect over 6 weeks. The vast majority of users are in
> > organizations where there is no way they are going to absorb these
> changes.
> > For people who are heavily involved can take CI builds and try them,
> > otherwise a 6 weeks cadence I believe is quite good.
> >
> > > If anything it means that if you fix a bug in 3.2.x it will be released
> > > quickly... 3.2.x has taken far far too long.
> >
> > By what measure?
>
>
> It was supposed to be a quick release the first week if Oct 2013... We
> still have not released it
>
>
> >
> > > High cadence when there are
> > > changes to release is a better way.
> >
> > Again high cadence compared to what?
>
>
> Compared to our average cadence over the past N years.
>
> This is a three month experiment. If it doesn't work we will try something
> else. If the rest if the PMC gets pissed off then the releases will not get
> enough binding voted and it will come to a natural halt
>
> Previously you have suggested a 4-6 week cadence... That cadence failed to
> deliver... Weekly is probably the fastest cadence you can have at ASF (and
> it may prove to be too fast for ASF) but we won't know unless we try.
>
> So I am suggesting that we try shipping code as fast as we can and step
> back if that speed isn't working
>
> >
> > > I will act as RM if nobody else steps
> > > up during this 3 month experiment (but I would encourage other
> committers
> > > to pick up the role for practice)
> >
> > So you're deciding I'm not the RM now after having done the last two
> > releases? How does that

Re: Towards faster releases

2014-02-19 Thread Fred Cooke

You missed the point. No-change commits include:

   - Clean up white space
   - Fix some comments in the code base
   - POM tweaks that don't affect binary output
   - Light genuine bonafide refactoring that causes no actual change in
   behaviour at all

There is zero point to releasing these things.

Fred.


On Wed, Feb 19, 2014 at 10:46 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On 18 February 2014 22:49, Fred Cooke  wrote:
>
> > Perhaps a stupid question, however if no change goes in, and it kicks off
> > and gives the same gold star as the previous week, then there's no point
> to
> > releasing it, because it's the same thing, what takes care of this?
>
>
> It will not work that way.
>
> In order to establish the downstream jobs and builds in Jenkins you need to
> use fingerprinting.
>
> How the jobs work is like this:
>
> 1. The top job passes if the last commit is not '[maven-release-plugin]
> prepare for next development..."
>
> It also runs `git rev-parse HEAD > git-commit.txt` and we archive and
> fingerprint the git-commit.txt file
>
> 2. The second job is to verify that everything builds.
>
> It picks up the git revision to build as a build parameter injected by
> the promotion of the top job.
>
> It generates a throw-away GPG key and runs the build with the full
> apache-release profile enabled.
> i.e. release:prepare will work if this build passes.
>
> At the end of its build it runs `git rev-parse HEAD > git-commit.txt`
> and we archive and fingerprint the git-commit.txt file
>
> It also triggers the third job with a parameter indicating which build
> of the second job triggered the third job.
>
> It also adds a "builds" promotion to the first job (green star) - note
> that the star will be added to the first build that introduced the matching
> `git-commit.txt`
>
> 3. The third job is to verify the integration tests
>
> It copies the maven distribution and `git-commit.txt` files from the
> build of the second job provided by the parameter and then runs the
> integration tests
>
> At the end of the build we archive the git-commit.txt and add a
> "integration tests pass" promotion to the first job (gold star) - note that
> the star will be added to the first build that introduced the matching
> `git-commit.txt`
>
> So week 1 there are no changes since the last release. Job 1 Build 1 fails,
> nothing else happens
>
> Week 2, there are changes since the last release. Job 1 Build 2 passes, Job
> 2 Build 1 fails, nothing else happens
>
> Week 3, there are no changes since week 2. Job 1 Build 3 passes, Job 2
> Build 2 fails, nothing else happens
>
> Week 4, there are changes since week 3. Job 1 Build 4 passes, Job 2 Build 3
> passes, Job 3 Build 1 fails. Job 1 Build 4 gets a green star. (The
> integration tests broke because of a broken integration test)
>
> Week 5, there are no changes since week 4 (but the integration test is now
> fixed). Job 1 Build 5 passes, Job 2 Build 4 passes, Job 3 Build 2 passes.
> Job 1 Build 4 now gets a gold star. Job 1 Build 5 has no stars as it did
> not introduce a new git-commit.txt. Email gets sent to the dev list. Nobody
> bothers their arse to cut a release
>
> Week 6, there are no changes since week 4. Job 1 Build 6 passes, Job 2
> Build 5 passes, Job 3 Build 3 passes. Nothing else happens as Job 1 Build 4
> already has green and gold stars and that was the first job to introduce
> the specific git-commit.txt
>
> Week 7, there are changes since week 6. Job 1 Build 7 passes, Job 2 Build 6
> passes, Job 3 Build 4 passes. Job 1 Build 7 now gets both green and gold
> stars. Email gets sent to the dev list.
>
> The behaviour is perhaps a bit smarter than you might have thought ;-)
>
>
> > Just
> > the human going "well, actually there were no commits, so this email is
> > spurious"?
> >
> > I see no problem with a thorough test rig like this, though. It seems
> > purely positive. And if phrased more like "This gold star means it's OK
> to
> > make a release" as opposed to "This gold star means a human should think
> > about making a release" then it'd provoke no  technical offense,
> probably.
> >
> > Releases are inherently human. It could be that it gold star with 3 out
> of
> > a 5 commit patch that makes no sense to release, even if it passes all
> > tests (tests missing?). You get a release out by making a clear decision
> > about what will be in it, working towards that solidly, and not creeping
> to
> > other related/new things. If at some point you realise y

Re: Towards faster releases

2014-02-19 Thread Fred Cooke

Sorry, still working on your first email in this thread which never
explicitly stated that, only implicitly, if your read the URL linked to,
AND happened to know what state 3.2.X was in. You did indeed point this out
at a later date. My mistake. But the first email set the tone, which is
hard to shake :-)


On Thu, Feb 20, 2014 at 12:00 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On 19 February 2014 10:13, Fred Cooke  wrote:
>
> > You missed the point. No-change commits include:
> >
> >- Clean up white space
> >- Fix some comments in the code base
> >- POM tweaks that don't affect binary output
> >- Light genuine bonafide refactoring that causes no actual change in
> >behaviour at all
> >
>
> Why are those things going into a maintenance release branch?
>
> Whitespace cleanup - not for a maintenance branch.
>
> General comments in the code base - not for a maintenance branch.
>
> Now fixing javadoc comments because they are incorrect... that's a bug...
> and the updated API should be published so that is releasable.
>
> Genuine refactoring that causes no actual change in behaviour at all should
> never go into a maintenance branch... unless it is necessary to cherry pick
> the fix of a bug... in which case it is part of the cherry pick and
> associated with fixing a bug
>
> The maintenance release branch should only get bug fixes that are backwards
> compatible. Those things go into the mainline for the next minor/major
> release.
>
>
> >
> > There is zero point to releasing these things.
> >
> > Fred.
> >
> >
> > On Wed, Feb 19, 2014 at 10:46 PM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > On 18 February 2014 22:49, Fred Cooke  wrote:
> > >
> > > > Perhaps a stupid question, however if no change goes in, and it kicks
> > off
> > > > and gives the same gold star as the previous week, then there's no
> > point
> > > to
> > > > releasing it, because it's the same thing, what takes care of this?
> > >
> > >
> > > It will not work that way.
> > >
> > > In order to establish the downstream jobs and builds in Jenkins you
> need
> > to
> > > use fingerprinting.
> > >
> > > How the jobs work is like this:
> > >
> > > 1. The top job passes if the last commit is not '[maven-release-plugin]
> > > prepare for next development..."
> > >
> > > It also runs `git rev-parse HEAD > git-commit.txt` and we archive
> and
> > > fingerprint the git-commit.txt file
> > >
> > > 2. The second job is to verify that everything builds.
> > >
> > > It picks up the git revision to build as a build parameter injected
> > by
> > > the promotion of the top job.
> > >
> > > It generates a throw-away GPG key and runs the build with the full
> > > apache-release profile enabled.
> > > i.e. release:prepare will work if this build passes.
> > >
> > > At the end of its build it runs `git rev-parse HEAD >
> git-commit.txt`
> > > and we archive and fingerprint the git-commit.txt file
> > >
> > > It also triggers the third job with a parameter indicating which
> > build
> > > of the second job triggered the third job.
> > >
> > > It also adds a "builds" promotion to the first job (green star) -
> > note
> > > that the star will be added to the first build that introduced the
> > matching
> > > `git-commit.txt`
> > >
> > > 3. The third job is to verify the integration tests
> > >
> > > It copies the maven distribution and `git-commit.txt` files from
> the
> > > build of the second job provided by the parameter and then runs the
> > > integration tests
> > >
> > > At the end of the build we archive the git-commit.txt and add a
> > > "integration tests pass" promotion to the first job (gold star) - note
> > that
> > > the star will be added to the first build that introduced the matching
> > > `git-commit.txt`
> > >
> > > So week 1 there are no changes since the last release. Job 1 Build 1
> > fails,
> > > nothing else happens
> > >
> > > Week 2, there are changes since the last release. Job 1 Build 2 passes,
> > Job
> > > 2 Build 1 fails, nothing else happens
> > >
> > > Week 3, there are no changes since week 2. Jo

Re: Convert everything to Git

2014-02-20 Thread Fred Cooke

The entire SCM interface is very SVN-centric IMO. I raised a number of git
related m-rel-p issues some time ago, but have been busy moving countries
and more in the mean time. I doubt there has been progress on them, though.
One pretty much required a core change to Maven (perhaps something for
4.0.0?) which IIRC people were adamantly against.

One example off the top of my head is allowing meaningful tags to be
created. Another was the git provider not respecting git configuration, I
worked around that by using native git IIRC. There were other things,
nothing HUGE, and mostly work-around-able but still not ideal for general
use IMO.

Fred.


On Fri, Feb 21, 2014 at 10:27 AM, Jason van Zyl  wrote:

>
> On Feb 20, 2014, at 1:07 PM, Dennis Lundberg 
> wrote:
>
> > Hi Jason
> >
> > While I'm finally starting to see the potential with a DVCS like git,
> > there are a couple of things that stands in the way of migrating, for
> > example plugins, to git:
> >
> > 1. Judging by our resident git gurus, it will require quite some
> > effort to prepare for and execute the actual migration. Do we have
> > someone with enough knowledge and time to do it?
> >
>
> I'm willing and I think Kristian would help as well.
>
> > 2. Our own tooling, in particular maven-release-plugin, still isn't
> > good enough for git use. IMO we need to get that fixed and verified on
> > our own releases before we migrate any more components to git.
> >
>
> I only release core and that works fine which begs the question: do we
> want to normalize our repository structure to simplify the tooling
> requirements. What exactly doesn't work? Trying to release a single thing
> out of a repository containing many things?
>
> > On Thu, Feb 13, 2014 at 4:37 AM, Jason van Zyl  wrote:
> >> Can we start the process of converting everything to Git. I don't
> really see any benefit in using Subversion any longer.
> >>
> >> If so then we should just get together for a day and convert them and
> then get infra to use what we converted to do the flip.
> >>
> >> Jason (who would be happy to never execute svn again)
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >
> >
> >
> > --
> > Dennis Lundberg
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> I never make the mistake of arguing with people for whose opinions I have
> no respect.
>
> -- Edward Gibbon
>
>
>
>
>
>
>
>
>
>

Re: Convert everything to Git

2014-02-20 Thread Fred Cooke

+
+org.apache.maven.wagon
+wagon-ssh-external
+${extension.version.wagon}
+

It was SSH settings that were not being respected. Things like ports and
ssh hosts vs DNS lookups, etc.

There were other issues with multi-module-parents vs ONLY-parents vs
aggregator poms. MRELEASE-814

https://jira.codehaus.org/browse/MRELEASE-812
https://jira.codehaus.org/browse/MRELEASE-815

Other issues were m-site-p in terms of variables and inheritance and
uploads, which work OK for general generation.

IIRC the results of these bugs was that I had a lot of unwanted duplication
of config that I couldn't inherit because it got mal-processed. Nothing
worse, but duplication is evil and makes baby Jesus and other equally
ordinary small children cry.

Then there are things that are just generally broken and don't affect git
worse than other SCMs

But I'm OT now.

Fred.

On Fri, Feb 21, 2014 at 10:58 AM, Mark Derricutt  wrote:

> On 21 Feb 2014, at 10:27, Jason van Zyl wrote:
>
>  I only release core and that works fine which begs the question: do we
>> want to normalize our repository structure to simplify the tooling
>> requirements. What exactly doesn't work? Trying to release a single thing
>> out of a repository containing many things?
>>
>
> A stock m-r-p config will break using the latest releases of git ( due to
> depending on an old version of the -scm- artefacts ) which I've mentioned
> before, and I believe there are commits awaiting release to resolve this.
>
> m-r-p also _really_ likes to release from the root directory of a
> repository, so doing independent releases from sub directories/modules is
> difficult ( there is a setting which lets this work, but that's just
> unpleasant ) - but due to git's tagging/branching being repository wide
> just releasing an individual module really is unpleasant.
>
> Basically, if modules have a constant release cadence/version numbering
> scheme, they can release together in a single repo, otherwise they should
> be separate. This however I don't see as a "problem with git tooling in
> maven" - just good practise.
>
> Mark
>

Re: Operating system requirement

2014-03-30 Thread Fred Cooke

A minimum is just that, a minimum! My repo is 600 meg, but I have a stack
of *dependencies* in there... A minimum should not include *user*
dependency guesswork, it should only include what a default hello-world
project with NO deps outside the default near-empty pom produces when run
through most or all of the phases and goals. Someone start with nothing and
build such a project in N ways until there are none left, then du -hs ~/.m2
and see what you get. Calling it the "500" because that's what an average
dev might have (with or without snapshots?) is silly, however warning in
appropriate words that in real-world use it will probably reach half a gig,
and often reach as much as 2 gig, is useful. Maven by nature and by design
is incomplete, calling the minimum 5 is an equal sin. Only once maven has
downloaded itself is it reasonable to state a minimum. Additionally, all of
the above is misleading, it's actually more like this: min usable/used
size  = maven + (numUsers * pluginsAndTheirDeps)... which for a single user
simplifies out to maven + pluginsAndTheirDeps ~= 100? Too much said, but
the inaccuracy in this thread was too much, also.

On Sun, Mar 30, 2014 at 10:31 PM, Anders Hammar  wrote:

> Handled in ticket MNG-5610.
>
> /Anders
>
>
> On Fri, Mar 28, 2014 at 4:47 PM, sebb  wrote:
>
> > On 28 March 2014 12:09, Anders Hammar  wrote:
> > >> The requirements also says:
> > >>
> > >> "Disk No minimum requirement. Approximately 100MB will be used for
> > >> your local repository, however this will vary depending on usage ..."
> > >>
> > >> AFAICT there _is_ a minimum requirement which is needed to store a
> > >> basic set of plugins.
> > >> And of course there is the Maven application itself, though that is
> > >> tiny (under 6Mb for 3.0.5)
> > >>
> > >> 100MB is quite a small repository; they can easily grow to 1GB or
> more.
> > >>
> > >
> > > So you think we should change to for example:
> > > "Approximately 10MB is required for the Maven installation itself. In
> > > addition to that, additional disk space will be used for your local
> Maven
> > > repository. The size of your local repository will vary depending on
> > usage
> > > but calculate for at least 500MB."
> > >
> > > Maven 3.2.1 is around 8MB, but Maven 3.0 is around 3.5MB and 2.x is
> even
> > > smaller. Stating approx 10MB will give us some space.
> > >
> > > My local repo is 1.5GB so I'm guessing an average dev would need at
> least
> > > 500MB.
> > >
> > > ok?
> >
> > +1
> >
> > > /Anders
> > >
> > >
> > >>
> > >> > /Anders
> > >> >
> > >> > [1] http://maven.apache.org/download.cgi#Requirements
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >> For additional commands, e-mail: dev-h...@maven.apache.org
> > >>
> > >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Maven 1.x cleanup

2014-07-28 Thread Fred Cooke

Leave SVN alone, it's only a matter of time before it's permanently retired
in it's entirety, right?


On Tue, Jul 29, 2014 at 12:58 PM, Brett Porter  wrote:

> Hi,
>
> About a year ago, the EOL banner was added for Maven 1.x. Today I saw
> there was a still a maven-1.x link in the navigation from the parent POM,
> which I removed, and added a single section to the bottom of the front page
> for archived documentation.
>
> Looking at http://maven.apache.org/maven-1.x-eol.html, it says that the
> docs will move to "archives", but that hadn't happened yet - so I did that
> also and put in a redirect. Let me know if you spot any issues.
>
> The doc also says that the SVN tree will move to the retired section -
> does anyone still want to pursue that for maven-1 and maven-2? The main
> downside is that it breaks old tag locations.
>
> - Brett

Re: Git Push Summary

2014-09-15 Thread Fred Cooke

There will still be a copy around, get hold of the original and push it
back up. Hooks should be setup to prevent tag deletion...

On Tue, Sep 16, 2014 at 8:40 AM, Robert Scholte 
wrote:

> Ouch?!
>
> Op Mon, 15 Sep 2014 03:44:29 +0200 schreef :
>
>  Repository: maven-wagon
>> Updated Tags:  refs/tags/wagon-2.7 [deleted] b00132663
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Releases, Continuous Delivery and the Future

2014-12-14 Thread Fred Cooke

Thank /***, finally some movement in the right direction! :-D

Please also try to remember that EVERY single one of your "users" is a
*developer* and should comprehend that a version is an arbitrary label on a
piece of software to be used to uniquely identify it. If not, they should
be educated.

Thanks for putting some time into this. Qualifiers suit me fine. As long as
they're immutable, I'm happy.

Another approach is: SNAPSHOTs until you're actually confident, then
release a real one, and if it sucks, release another post more snapshots.
This is the entire point of snapshot builds in the first place, right? Just
my 2c.

/me goes back to lurking.

Regards,

Fred.

On Mon, Dec 15, 2014 at 2:29 PM, Jason van Zyl  wrote:

> Hi,
>
> The discussion keeps resurfacing about how we deal with failed releases so
> I'll summarize how I think it should ultimately be done as a starting point.
>
> I'll go over the cases we've encountered thus far:
>
> 1) The user case prefers non-disjunct sets of releases, or from our PoV
> re-used versions. I believe people are confused by missing versions and
> will always result in questions like "What happened to version X?", where X
> is a non-viable build. Not many people read release notes, will not
> self-serve and it will just be a lot of questions and confusion. The
> typical user doesn't care about the question of whether a particular build
> is viable or not. I think they naturally expect contiguous, increasing
> versions when they update to new versions of a product.
>
> 2) The tester case prefers new versions but has tolerated re-used
> versions. Testers for core only really have to deal with the binary
> distribution and if it gets thrown away there's not much chance of local
> repository inconsistency because the typical tester, who is not an
> integrator, isn't going to depend on the new core release for anything.
> Running 3.2.4 doesn't put anything related to 3.2.4 in your local
> repository.
>
> 3) The integrator case prefers new versions. Different content with the
> same version is a violation of our immutability philosophy and can cause
> issues. Even though this is very much contained at the moment let's be
> optimistic and believe we will have many integrators that will test
> pre-released versions. Igor is right in that it's not fun to keep track of
> this and why should the burden be placed on the integrator. The answer is
> it shouldn't.
>
> 4) The release manager case prefers new versions. I have typically reused
> versions because I believe 1) is true. It's a PITA to erase tags,  shuffle
> issues around in JIRA, and reset the POMs. I would prefer to just move
> forward, but I have done it because the user confusion is not worth the
> small effort it takes me to clean up a few resources. One hour for me
> versus thousands of hours of confusion for all users. It's an easy
> calculation.
>
> Taking all these cases into consideration so that all participants are
> satisfied I think we ultimately want increasing and contiguous versions for
> users, testers and integrators while the release manager does not have to
> shuffle a bunch of resources around in the event of a non-viable build.
> What we want is a form of continuous delivery where a version like 3.2.4 is
> the version that we call it to the outside world (some refer to it as the
> marketing version) and the qualifier changes from build to build so we have:
>
> 3.2.4-qualifier
>
> And for simplicity's sake let's just say the qualifier is a build number
> so we end up with:
>
> 3.2.4-01
> 3.2.4-02
> ...
> 3.2.4-NN
>
> Every build is a complete build that can be released, and in the stream of
> builds that are produced we decide that one is good enough for public
> consumption. Nothing in the issue tracking or documentation needs to change
> as it's still referred to as 3.2.4. People who download the distribution
> aren't going to care what the exact versions say on the JARs but some
> education might be required to tell people that something like 3.2.4 is
> actually 3.2.4-05 if they want to refer to an artifact from 3.2.4. I don't
> think making aliases to the marketing versions are a good idea and wouldn't
> want to duplicate artifacts so that they can be referred to by the
> marketing version. People will just become accustom to knowing a qualifier
> is necessary to find the actual version.
>
> This is more how things work at Eclipse where if you look at something
> from Jetty:
>
>
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.eclipse.jetty%22%20AND%20a%3A%22jetty-servlet%22
>
> You'll see that something like jetty-servlet 9.2.3 is actually referred to
> as 9.2.3.v20140905. Jetty seems somewhat inconsistent with respect to
> milestones but you get the idea. I think this works for all parties but
> especially users where say we all happen to write blog entries about 3.2.4
> and it fails twice and we actually release 3.2.6. This is just so confusing
> as anything that referred to 3.2.4 n

Re: Releases, Continuous Delivery and the Future

2014-12-14 Thread Fred Cooke

OK, well, classifiers works for me, then. It certainly seems like SNAPSHOTs
are  not the go-forward plan, at least, without your fix.

Is it true that you can't use 4 part versions with Maven without confusing
some logic that is hard coded to look for 1.2.3 rather than
N.N+1.N+2N+M ? If not true, you could just step up to 4 and use up
minor minor steps.

Fred.

On Mon, Dec 15, 2014 at 3:11 PM, Jason van Zyl  wrote:

> A further definition of a qualifier is that it applies to all artifacts in
> a multi-module project (MMP). Unfortunately, at present, SNAPSHOTs are
> fundamentally flawed in that all artifacts produced in an MMP do not get
> the same timestamp. Each artifact gets its own which makes it impossible to
> refer to the MMP with a single version. This is highly problematic and was
> certainly a design oversight 10 years ago.I have code that remedies this
> but it's only one aspect of moving toward continuous delivery in that all
> builds produced at all times need to be releasable. So in the builds that I
> work on everything required for a release is enabled including source JAR
> generation and any checks. I have had customers in the past that went
> through all sorts of contortions to collect all the various snapshot
> versions for a release to mimc something like CD but it's certainly not
> ideal.
>
> On Dec 14, 2014, at 8:44 PM, Fred Cooke  wrote:
>
> > Thank /***, finally some movement in the right direction! :-D
> >
> > Please also try to remember that EVERY single one of your "users" is a
> > *developer* and should comprehend that a version is an arbitrary label
> on a
> > piece of software to be used to uniquely identify it. If not, they should
> > be educated.
> >
> > Thanks for putting some time into this. Qualifiers suit me fine. As long
> as
> > they're immutable, I'm happy.
> >
> > Another approach is: SNAPSHOTs until you're actually confident, then
> > release a real one, and if it sucks, release another post more snapshots.
> > This is the entire point of snapshot builds in the first place, right?
> Just
> > my 2c.
> >
> > /me goes back to lurking.
> >
> > Regards,
> >
> > Fred.
> >
> > On Mon, Dec 15, 2014 at 2:29 PM, Jason van Zyl  wrote:
> >
> >> Hi,
> >>
> >> The discussion keeps resurfacing about how we deal with failed releases
> so
> >> I'll summarize how I think it should ultimately be done as a starting
> point.
> >>
> >> I'll go over the cases we've encountered thus far:
> >>
> >> 1) The user case prefers non-disjunct sets of releases, or from our PoV
> >> re-used versions. I believe people are confused by missing versions and
> >> will always result in questions like "What happened to version X?",
> where X
> >> is a non-viable build. Not many people read release notes, will not
> >> self-serve and it will just be a lot of questions and confusion. The
> >> typical user doesn't care about the question of whether a particular
> build
> >> is viable or not. I think they naturally expect contiguous, increasing
> >> versions when they update to new versions of a product.
> >>
> >> 2) The tester case prefers new versions but has tolerated re-used
> >> versions. Testers for core only really have to deal with the binary
> >> distribution and if it gets thrown away there's not much chance of local
> >> repository inconsistency because the typical tester, who is not an
> >> integrator, isn't going to depend on the new core release for anything.
> >> Running 3.2.4 doesn't put anything related to 3.2.4 in your local
> >> repository.
> >>
> >> 3) The integrator case prefers new versions. Different content with the
> >> same version is a violation of our immutability philosophy and can cause
> >> issues. Even though this is very much contained at the moment let's be
> >> optimistic and believe we will have many integrators that will test
> >> pre-released versions. Igor is right in that it's not fun to keep track
> of
> >> this and why should the burden be placed on the integrator. The answer
> is
> >> it shouldn't.
> >>
> >> 4) The release manager case prefers new versions. I have typically
> reused
> >> versions because I believe 1) is true. It's a PITA to erase tags,
> shuffle
> >> issues around in JIRA, and reset the POMs. I would prefer to just move
> >> forward, but I have done it because the user confusion is not worth the
&g

Re: [DISCUSS] To SemVer or not to SemVer, that is the question

2015-02-22 Thread Fred Cooke

It's worth pointing out that if you just run the two part version in the
first place you are doing the same thing. IE, internally maven's versions
are always x.y.z even if you only specify x.y thus if you have 2.6 and
you're doing SemVer (2+, 1 sucked), then it'll behave correctly. Add the
patches if/when you need them like usual.

I'd also love to hear that no one is trying to release 200 artifacts in a
single reactor. That makes no sense at all, to me. The chances are on a big
corporate project you've only changed <25% of them per top level release
anyway. So to run a top level MVN release against the entire tree would
produce 75% duplicate (by code, not number) artifacts. Or did I
misunderstand?


On Mon, Feb 23, 2015 at 9:55 AM, Dennis Lundberg  wrote:

> Thanks Robert,
>
> I'll have a look at it.
>
> On Sun, Feb 22, 2015 at 1:00 PM, Robert Scholte 
> wrote:
> > Hi Dennis,
> >
> > I've already started to extract some parts of the maven-release-manager
> to
> > an API.
> > The project has now 4 modules[1], whereas the maven-release-apis[2]
> should
> > be interesting.
> > I've started with a VersionPolicy interface, Simone already started on
> his
> > own implementation of OddEven Policy[3]
> > The current version already works with this API and the default
> > implementation, so there's only one more step to take: make it settable
> by
> > plugin configuration.
> > So you could work on the SemVer policy based on this API. If this
> confirms
> > that the API for version policy is complete, we can expose it.
> >
> > thanks,
> > Robert
> >
> > [1] http://maven.apache.org/maven-release/
> > [2]
> >
> http://maven.apache.org/maven-release/maven-release-api/apidocs/index.html
> > [3]
> >
> http://maven.apache.org/maven-release/maven-release-policies/maven-release-oddeven-policy/index.html
> >
> >
> > Op Sat, 21 Feb 2015 23:05:37 +0100 schreef Dennis Lundberg
> > :
> >
> >
> >> Hi,
> >>
> >> Although I strongly feel that SemVer [1] is the way to go when it
> >> comes to versioning, I still haven't started using it though. That got
> >> me thinking about why that is the case. I've come to the conclusion
> >> that I'm lazy :)
> >>
> >> It all comes down to tooling. Being accustomed to, and spoiled by,
> >> using the Release Plugin, I don't want to do anything manually any
> >> more. That includes as simple a thing as changing the "next version"
> >> (or developmentVersion) manually during the interactive command line
> >> session when using the Release Plugin. I want it to be the guessed
> >> correctly for me. Let me outline an example to show you what I mean.
> >> The vast majority of releases I make, both here and at my day job, are
> >> minor releases. So I want the Release Plugin to work for me, and not
> >> against me.
> >>
> >>
> >> Not using SemVer
> >>
> >> 1.0-SNAPSHOT --> 1.0 --> 1.1-SNAPSHOT
> >>
> >> No problems here, the Release Plugin will correctly guess that
> >> 1.1-SNAPSHOT is the next version that I want to use. Just hit 
> >> a couple of times during the release process.
> >>
> >>
> >> Using SemVer
> >>
> >> 1.0.0-SNAPSHOT --> 1.0.0 --> 1.0.1-SNAPSHOT
> >>
> >> This is not what I want. The Release Plugin will guess that the next
> >> version should be 1.0.1-SNAPSHOT. To change it I have to type in the
> >> value that I want on the command line. I'm too lazy for that. Instead
> >> I want the Release Plugin to do this:
> >>
> >> 1.0.0-SNAPSHOT --> 1.0.0 --> 1.1.0-SNAPSHOT
> >>
> >>
> >> How can we solve this? The solution that I have come up with is a new
> >> parameter for release:prepare tentatively called "versionIncrement"
> >> that can take the values "major", "minor" and "patch", with "patch"
> >> being the default value for backwards compatibility.
> >>
> >> In my use case above I would simply set versionIncrement=minor and the
> >> Release Plugin would then do things my way.
> >>
> >> What are your thoughts on this?
> >>
> >> I would like for us to start using SemVer for all releases in the
> >> Maven project, not just in core. What do you think?
> >>
> >>
> >> [1] http://semver.org/
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
>
> --
> Dennis Lundberg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] To SemVer or not to SemVer, that is the question

2015-02-23 Thread Fred Cooke

That makes some sense, but a more generic big project where the life cycle
of each component is distinct and meaingfully distinct, it does not. I can
think of another good case, albeit with a much lower number of moving
parts: Parent sets. It's nice to have only one current version number to
remember when you're poking around your POM and spot the parent tags. In
this case I'd rather have duplicate releases because as a set, they work
together well, or so it should be.

Strict adherence to SemVer is a bit of a fail anyway, provided your
versions have semantic meaning that is well defined within their context,
you're doing well. For example, your long lived release branches.

On Mon, Feb 23, 2015 at 5:09 PM, Chris Graham  wrote:

> On Mon, Feb 23, 2015 at 8:42 AM, Fred Cooke  wrote:
>
> >
> > I'd also love to hear that no one is trying to release 200 artifacts in a
> > single reactor. That makes no sense at all, to me. The chances are on a
> big
> > corporate project you've only changed <25% of them per top level release
> > anyway. So to run a top level MVN release against the entire tree would
> > produce 75% duplicate (by code, not number) artifacts. Or did I
> > misunderstand?
> >
>
> From a pragmatic, not a SemVer point of view, it makes a lot of sense. I
> can think of some Message Broker projects that I did, with a few hundred
> message sets. You're right, in that the % change is minimal. The issue is
> that it's rarely the same modules that change. And in that sense, setting
> up the SCM tagging would be a nightmare.
>
> So, what I've done is to set up a monolithic build, where I rebuild
> everything everytime, and release everything time. So it's not SemVer, but
> it works. I can verify the SCM provenance of the code with a single tag.
> The only thing that defines a vesion, is that it's different, in some way,
> to another another version.
>
> In message brokers case, it drastically simplifies the deployment options,
> it's simple as everything gets deployed each and every time. Automating the
> deployment of a single message set across any given number of bar files
> into whatever execution groups require it would be next to impossible (and
> not worth the effort in doing so).
>
> I used long life release branches (a release of X.Y lives in it's own
> branch, in some cases up to 18 months), with many releases of
> X.Y.Z-SNAPSHOT on the branch. The last project used Oracle CC&B, and we
> have 5 concurrent release branches. SemVer in that instance is not doable.
>
> So yes, the same code will be tagged multiple times, with different
> versions with no real changes to the module. And that is fine. You've also
> got to remember that I set the maven builds up underneath the devs, so that
> they were not aware of it, other than this strange looking pom.xml that
> suddenly appeared in their projects :)
>

Re: Jekyll experiment

2015-03-18 Thread Fred Cooke

Well, if you created it, then a personal thank you from me for that. I
would never use it for normal web stuff, but for the autogenerated stuff
like PMD, checkstyle, findbugs, cross ref code, javadocs, etc etc it's
GREAT at release time to give you a reference of what was. Or during dev,
when one feels like it, to create a comprehensive detailed view of the
state of the code that can be casually navigated through using a browser.
It has some SVNness in it, which I hate, so I invite you to continue the
hate for your own reasons :-D

On Thu, Mar 19, 2015 at 4:32 PM, Jason van Zyl  wrote:

> Anyone interested in trying a Jekyll experiment for our website? Extract
> the useful documentation we believe there is and try to make working on the
> site a pleasurable experience that is easy for users to contribute to?
>
> I'd like to try this because after this last release I'm frankly tired of
> looking at our pretty awful website. It's ugly, noisy, unmaintained, hard
> to navigate and personally just makes me not want to write anything. I
> would like to like writing documentation again and I think a more standard
> tool like Jekyll will help. I honestly dislike doing core releases because
> I have to use the site plugin. I created it, I can hate it and I do hate it.
>
> Even if no one answers I'll try this experiment because I think there's
> only 10-15 useful documents in the whole site so it likely won't take long.
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> There's no sense in being precise when you don't even know what you're
> talking about.
>
>  -- John von Neumann
>
>
>
>
>
>
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: IRC rooms @codehaus

2015-05-10 Thread Fred Cooke

Yes, been lurking there for years anyway, and it's usually bigger, but the
topic needs to be updated to not say "go to codehaus irc", last time I
looked, anyway.

On Mon, May 11, 2015 at 8:41 AM, Robert Scholte 
wrote:

> Hi,
>
> Up until now the official IRC rooms were #maven and #maven-dev @
> irc.codehaus.org
> Now that the end of Codehaus is getting closer, should we move to
> irc.freenode.org? It seems like most other ASF  projects can be found
> there as well.
>
> thanks,
> Robert
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Releasing entire maven-shared as a single release ?

2015-05-30 Thread Fred Cooke

+1 from me, too! Well said.

On Sun, May 31, 2015 at 6:09 AM, Michael Osipov  wrote:

> Am 2015-05-30 um 17:17 schrieb Jason van Zyl:
>
>> If they have truly separate development cycles, then I think it best to
>> try and move toward meaningful (semantic) versioning for each component.
>> Which means they have their own version and are released individually.
>>
>> As part of the Git migration I think putting components that have their
>> own unique lifecycle into their its own repository is more the direction we
>> need to go in. Grouping everything together and releasing them together I
>> believe runs counter to having a good separation of concerns in general.
>>
>>
> +1
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Full migration to Git

2015-06-01 Thread Fred Cooke

+1, SVN fans should not be involved in these decisions at all, they'll just
get it totally wrong.

On Mon, Jun 1, 2015 at 8:08 PM, Arnaud Héritier  wrote:

> For me it should be one per plugin, shared component.
> Everything which has its own release lifecycle must have its own repo
>
> On Mon, Jun 1, 2015 at 10:04 AM, Chris Graham 
> wrote:
>
> > So how are we planning to calve up the migration?
> >
> > A repo per trunk?
> > An all in one blob?
> > A mixture, if so, split along what lines?
> >
> > -Chris
> >
> > On Sun, May 31, 2015 at 6:57 PM, Jason van Zyl  wrote:
> >
> > > Great, thanks Baptiste.
> > >
> > > > On May 31, 2015, at 4:36 AM, Baptiste Mathus 
> > wrote:
> > > >
> > > > See https://github.com/mojohaus/convert-to-git for MojoHaus
> > (previously
> > > > Mojo@Codehaus).
> > > > Though a bit rough a the main script being a bit oriented towards the
> > > Mojo
> > > > SVN, it has no real specificities wrt SVN->Git migration, so it
> should
> > be
> > > > at least a good starting point.
> > > >
> > > > I can privide help, or help anyone wanting to try and use it, and
> > > document
> > > > what needs be. Just tell me.
> > > >
> > > > Cheers
> > > >
> > > > 2015-05-31 6:26 GMT+02:00 Barrie Treloar :
> > > >
> > > >> On 31 May 2015 at 08:18, Jason van Zyl  wrote:
> > > >>
> > > >>> I’m sure those responsible for the migration of the Mojo project
> > > monorepo
> > > >>> into the separated repos will help us.
> > > >>
> > > >>
> > > >> I ask because I'm going to be facing the same thing at work
> soon-ish,
> > so
> > > >> there is a good chance of finding some capacity during work hours to
> > > help
> > > >> out with this migration to gain some skillz.
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Baptiste  MATHUS - http://batmat.net
> > > > Sauvez un arbre,
> > > > Mangez un castor !
> > >
> > > Thanks,
> > >
> > > Jason
> > >
> > > --
> > > Jason van Zyl
> > > Founder, Takari and Apache Maven
> > > http://twitter.com/jvanzyl
> > > http://twitter.com/takari_io
> > > -
> > >
> > > Simplex sigillum veri. (Simplicity is the seal of truth.)
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>
>
>
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>

Re: Full migration to Git

2015-06-01 Thread Fred Cooke

Git can generate normal patches that you can simply apply and commit after
testing. Or you could have a Git-SVN repo of your own setup, fetch the git
commits, cherry pick hem into your SVN based tree, and dcommit them back
up. I use Git-SVN every day at work. It's either that or kill myself as SVN
is wretched in every way.

On Mon, Jun 1, 2015 at 9:52 PM, Dennis Lundberg  wrote:

> I just want to clarify the reason for my struggles, for those who
> might not have read that thread:
>
> Someone set up a GitHub mirror for maven-plugins, but the canonical
> repo for maven-plugins is in Subversion. That makes it very difficult
> to use the native git tools to handle the contributions, beacuse data
> only ever travels from svn to git in this case IIUC. It also makes our
> contributors think that merging their pull requests is an easy task,
> because it would be if it was all git. When we don't respond to those
> pull requests they might loose interest and stop creating pull
> requests. So it really has nothing to do with technology and has
> everything to do with bad timing.
>
>
> On Fri, May 29, 2015 at 1:23 PM, Jason van Zyl  wrote:
> > I think it's time for a full migration of all our repositories to Git. I
> just see the email with Dennis struggling to merge a simple pull request
> and I think it's just time to switch completely. I think someone already
> started a list and we should just move through it. Personally I find SVN is
> just a huge hindrance at this point, especially for contributors.
> >
> > Thanks,
> >
> > Jason
> >
> > --
> > Jason van Zyl
> > Founder, Takari and Apache Maven
> > http://twitter.com/jvanzyl
> > http://twitter.com/takari_io
> > -
> >
> > The most dangerous risk: spending your life not doing what you want on
> the bet you can buy yourself freedom to do it later.
> >
> >  -- Randy Komisar
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
>
> --
> Dennis Lundberg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Full migration to Git

2015-06-01 Thread Fred Cooke

Yep, that's getting pretty deep! If the clone(s where's the s?) has
been done poorly (monolithically or otherwise brokenly) then the only
sensible option is to do it again. The right approach is the slow one, per
slice, otherwise the tags don't make sense. Trying to do this after the
fact from a monolithic clone sounds hideously painful.

On Tue, Jun 2, 2015 at 5:13 AM, Kristian Rosenvold <
kristian.rosenv...@gmail.com> wrote:

> Re-running the clone from a backup of asf svn is time consuming but might
> be the way to go, because we could probably get the correct layout in one
> go. (But it's dooog slow and will be even worse multiplied by X)
>
> Alternately one could probably get around the strange layout of the current
> git-svn clone by doing some hardcore conditional filter-branching to
> rewrite the root directory of only those commits that are not already at
> the root. This is not your average git-svn rewrite and we're *way* beyond
> powerpoint presentations here.
>
> But bottom line, it's just a dirty job that someone has to do :)
>
>  Kristian
>
> 2015-06-01 17:12 GMT+02:00 Jason van Zyl :
>
> > I wasn’t but that’s good. If you wanted to run the clone again is that an
> > issue? We just figure out the best way and then do it to all of them.
> >
> > > On Jun 1, 2015, at 10:48 AM, Kristian Rosenvold <
> > kristian.rosenv...@gmail.com> wrote:
> > >
> > > You're probably aware the I have done a substantial number of git
> > > migrations. Hopefully someone out there has a simple way to fix this
> > > problem;
> > >
> > > If I was to do this I'd probably re-run the initial git svn clone from
> > the
> > > SVN repository...
> > >
> > > Kristian
> > >
> > >
> > > 2015-06-01 16:40 GMT+02:00 Jason van Zyl :
> > >
> > >> Ok, let’s look around I’m sure folks have gone from monorepo setups to
> > >> individual project setups. I doubt we’re the first to attempt this.
> > >>
> > >>> On Jun 1, 2015, at 10:28 AM, Kristian Rosenvold <
> > >> kristian.rosenv...@gmail.com> wrote:
> > >>>
> > >>> git clone https://github.com/apache/maven-plugins.git
> > >>> cd maven-plugins
> > >>> ls -al
> > >>> git checkout maven-shade-plugin-2.2
> > >>> ls -al
> > >>>
> > >>> The root gets rewritten on the tags. Not nice. Mojo did not have this
> > >> issue.
> > >>>
> > >>> Kristian
> > >>>
> > >>>
> > >>> 2015-06-01 16:27 GMT+02:00 Kristian Rosenvold <
> > >> kristian.rosenv...@gmail.com>
> > >>> :
> > >>>
> >  No, the maven-plugins repo is a slightly different beast when
> compared
> > >> to
> >  mojo. And since we're splitting anyway, we're talking about 30-40
> > >> different
> >  repos, so there is really no point in your suggested route (the git
> > >> clones
> >  already exist although I am unsure if they can be used).
> > 
> >  So I think it's a good idea for everything but maven-shared and
> >  maven-plugins. The plan you have outlined does not make sense for
> > >> these. We
> >  need that script that creates plausible split repos first.
> > 
> >  To be verify specific, there's something weird about the *tags* in
> the
> >  plugins repo and how this has been translated to git in the current
> > git
> > >> svn
> >  close. Mojo did not have this problem.
> > 
> >  Try this:
> > 
> >  git clone https://github.com/apache/maven-plugins.git
> > 
> >  Kristian
> > 
> > 
> > 
> > 
> > 
> >  2015-06-01 16:16 GMT+02:00 Jason van Zyl :
> > 
> > > I think we have that PoC with Mojo moving to Github no? Baptiste,
> was
> > > this an issue?
> > >
> > > I think it will just be easier to do it all from Git. I don’t think
> > >> we’re
> > > going to lose anything in the translation directly from SVN to Git
> > >> with the
> > > maturity of the tools.
> > >
> > > But do you agree with the general plan. Get it all to Git and then
> > >> we’ll
> > > collectively figure it out. I really don’t see it being an issue
> > given
> > >> how
> > > much Git knowledge we have between us all and the Mojo migration to
> > >> Github.
> > >
> > >> On Jun 1, 2015, at 8:13 AM, Kristian Rosenvold <
> > > kristian.rosenv...@gmail.com> wrote:
> > >>
> > >> The real problem here is maven-shared and maven-plugins, which
> need
> > to
> > > be
> > >> rewritten quite heavily.
> > >>
> > >> The existing git mirrors may be used as a starting point for
> > filtering
> > >> operations, but I suspect retaining history is going to be quite a
> > lot
> > > of
> > >> work when splitting the repos.
> > >>
> > >> We should not defer this operation like you suggest, we really
> need
> > a
> > > proof
> > >> of concept filtering first.
> > >>
> > >> Kristian
> > >>
> > >>
> > >> 2015-06-01 14:06 GMT+02:00 Jason van Zyl :
> > >>
> > >>> Maybe it best then to have everything mirrored to Git, if there
> are
> > >> any
> > >>> repos that are no

Re: [MNG-5840] IMHO critical regression in Maven 3.3.1 & 3.3.3

2015-06-05 Thread Fred Cooke

Your tar file is polluted with ._ stuff that ends up laying around the
place. Aside from that:

3.1.1 succeeds.
3.3.3 fails

The description of what is wrong/your expectation could be better.

I guess I would expect it to fail, but fail because relative path POM
version doesn't match that specified.

On Fri, Jun 5, 2015 at 9:42 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> https://issues.apache.org/jira/browse/MNG-5840
>
> Can some other people see if this test case I attached to this issue is
> replicated in their environments?
>
> I've been badly bitten by this a couple of times (and worse for me, I have
> a project that needs 3.3.1+ to build due to bugs that were only fixed in
> the 3.3 series)
>
> I only now had the time to try and create a minimal test case
>
> -Stephen
>

Re: [MNG-5840] IMHO critical regression in Maven 3.3.1 & 3.3.3

2015-06-05 Thread Fred Cooke

It still seems correct as per the quote provided above, even if it didn't
used to work this way. Is there anywhere else where it specifies the
behaviour that you've come to expect?

I see a few cases:

gid + aid = error or at least warning for no version, unless ../pom.xml
exists
gid + aid + ver = success if ver available, though according to docs
../pom.xml should make it succeed.
gid + aid + relpath = success if relpath available
gid + aid + ver + relpath = ?

during build, vs during release
specified version is snapshot or not
relpath version is snapshot or not
versions match or don't
path specified exists, or not

I agree that if it's using some snapshot (even if resolved through the
relative path) during a release, that's wrong/bad/evil. But the rest of the
time?

The language seems pretty clear "Maven looks for the parent POM first in
this location on the filesystem, then the local repository, and lastly in
the remote repo."

On Fri, Jun 5, 2015 at 10:56 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Fred: does
>
> https://issues.apache.org/jira/browse/MNG-5840?focusedCommentId=14574303&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14574303
> explain the issue better?
>
> On 5 June 2015 at 11:05, Fred Cooke  wrote:
>
> > Your tar file is polluted with ._ stuff that ends up laying around the
> > place. Aside from that:
> >
> > 3.1.1 succeeds.
> > 3.3.3 fails
> >
> > The description of what is wrong/your expectation could be better.
> >
> > I guess I would expect it to fail, but fail because relative path POM
> > version doesn't match that specified.
> >
> >
> > On Fri, Jun 5, 2015 at 9:42 PM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > https://issues.apache.org/jira/browse/MNG-5840
> > >
> > > Can some other people see if this test case I attached to this issue is
> > > replicated in their environments?
> > >
> > > I've been badly bitten by this a couple of times (and worse for me, I
> > have
> > > a project that needs 3.3.1+ to build due to bugs that were only fixed
> in
> > > the 3.3 series)
> > >
> > > I only now had the time to try and create a minimal test case
> > >
> > > -Stephen
> > >
> >
>

Re: IRC rooms @codehaus

2015-06-13 Thread Fred Cooke

Not that I know of, you seem to be in the right one. :-)

On Sat, Jun 13, 2015 at 10:23 PM, Robert Scholte 
wrote:

> It seems less crowded on the IRC @ FreeNode (Europe) compared to IRC @
> codehaus.
> Did I miss some rooms?
>
> Robert
>
>
> Op Mon, 11 May 2015 18:16:52 +0200 schreef Jason van Zyl  >:
>
>
>  The rooms have been there for a while already. Someone I don't know is
>> the channel operator for #maven, Mark appears to be so for #maven-dev.
>>
>> On May 10, 2015, at 4:41 PM, Robert Scholte 
>> wrote:
>>
>>  Hi,
>>>
>>> Up until now the official IRC rooms were #maven and #maven-dev @
>>> irc.codehaus.org
>>> Now that the end of Codehaus is getting closer, should we move to
>>> irc.freenode.org? It seems like most other ASF  projects can be found
>>> there as well.
>>>
>>> thanks,
>>> Robert
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>
>> Thanks,
>>
>> Jason
>>
>> --
>> Jason van Zyl
>> Founder, Takari and Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> -
>>
>> the course of true love never did run smooth ...
>>
>>  -- Shakespeare
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: number of bugs in maven-release-plugin

2015-06-27 Thread Fred Cooke

Some of the issues are mine. I'm pretty sure that at some point I realised
that to get it working properly for my use case would require forking it to
a privately released version. I guess now that it's mostly or all in git,
that's feasible. The conflicting requirements across SCMs, the highly
varied usage, and the historical bias towards SVN that runs deep through
far more than just m-rel-p make it pretty difficult, though. At least,
without breaking stuff for existing users.

I'm curious as to what an "irrelevant bug" is? If it's not a bug, then
close on review immediately after creation.

Fred.

On Sat, Jun 27, 2015 at 9:57 PM, Robert Scholte 
wrote:

> It was even worse.
> When I joined this team I started working on this plugin and managed to
> close half of them ( let's say from 300 back to 150 issues).
> Right now there's a situation where new issues are often easy to reproduce.
> The older ones are often harder to reproduce or are already fixed.
> I've already asked for feedback for a lot of issues. If I go through that
> list again,I'm pretty sure I can close a lot again.
> Then there are some issues which require some redesign, but without good
> code coverage it is hard to discover regression.
> For instance, I'd like to replace jdom with woodstox, because there are a
> lot of hacks in the code to please jdom.
> When I'm done with the M3 plugin migration I'd love to pick it up again.
>
> Then there's this tricky thing that it should work for all SCM's. It's
> great that maven-scm is a separate project, but that might need even more
> attention. But then we hit the problem that there's not enough knowledge
> for all these systems. And without the ability to verify both the bug and
> the fix *I* won't apply those patches (unless the code clearly exposes the
> issue).
>
> thanks,
> Robert
>
>
> Op Fri, 26 Jun 2015 22:55:02 +0200 schreef Tibor Digana <
> tibordig...@apache.org>:
>
>
>  Do you know what's wrong with Jira on maven-release-plugin MRELEASE?
>> It's growing nearly to 200 open bugs. It looks like the community use to
>> fix 5 in each release. Maybe the community should start closing irrelevant
>> bugs which better helps concentrating on more relevant bugs.
>>
>> We started this strategy in surefire plugin and closed irrelevant bugs.
>> This iteration has happened several times already. Then we released cca 30
>> fixed issues in every major release. This way we are now under 100 open
>> issues and still cutting the bugs down.
>> I have a strategy to handle new bug as it comes in Jira and ask the
>> originator to fix it and offering some hints to him/her. This way we have
>> got few more contributors in surefire project. Even if the contributor
>> does
>> not implement properly, it always saves my time and I can still modify his
>> implementation or ask him to reimplement it.
>>
>> Maybe it's the only question if we really want to have better statistics
>> and fix more bugs.
>> Maybe it's a question of resources like number of committers. We have some
>> contributors on GitHub, so maybe it is as simple as to ask them get this
>> position.
>>
>> Cheers
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: number of bugs in maven-release-plugin

2015-06-27 Thread Fred Cooke

Benson, I'm curious as to what you did, and also how it broke both for Git
users and other users. Any links/refs/bugs/emails/etc to read?

Was it just a case of leveraging features only available in very new
versions? A data point if so:

This sid laptop 2.1.3
My wheezy server 1.7.10.4
Work ucuntu 14.10 box 2.1.0
Current win git default 1.9.5

However I believe I've been using it since 1.5 or 1.6 or maybe earlier and
the core functionality is virtually unchanged since then, no? I remember
the porcelain stuff changing, so perhaps it was this?

egit/jgit has some serious flaws that render certain projects unusable with
it (Java limitation on symlinks)

It also seems/seemed to completely ignore ~/.ssh/config and other similar
things. I forget the details as I'm pretty sure I use real git in my parent
pom setup.

Regards,

Fred.

On Sun, Jun 28, 2015 at 5:01 AM, Benson Margulies 
wrote:

> Tibor,
>
> Well, we'll see. Let's parse this situation into some smaller ones. We
> don't need any votes. We need initiative coupled with enough time,
> knowledge, and energy to make progress.
>
> There's the maven core and the pom. Quite a while ago, I tried to push
> this; but I don't have the necessary intellectual investment in the maven
> core to lead here. The community needn't / shouldn't wait for Jason, but
> the problem of 'we can't change the pom, all those other tools will bust'
> is a hard problem.
>
> Then we have plugins. In my entirely personal opinion, there are too many
> plugins inside the Apache Maven project. We would be more successful, I
> submit, if the formal project owned a very minimal set of completely
> essential plugins, and the others were maintained by communities of the
> interested. Does the release plugin belong inside or outside?
>
> From a functional standpoint, I prefer the gitflow maven plugin to the
> maven-release-plugin. Sadly, the gitflow plugin is much too buggy for
> production use. It does actual merges, and sometimes they fail and leave a
> less. So I try to fix problems in the release plugin when they bite me.
>
> Right now, the release plugin rides on top of the SCM plugin. The SCM
> plugin tries to be completely general. The release plugin has very specific
> needs: update versions in poms, check them in, create tags, check out at
> tags. Maybe we'd have a happier release plugin if it had a tailored
> abstraction. Maybe not.
>
> --benson
>
>
>
>
>
>
> On Sat, Jun 27, 2015 at 10:14 AM, Tibor Digana 
> wrote:
>
> > @Benson
> >
> > Excellent!
> >
> > Since you have good inside of this problem you should post a Vote with
> this
> > list of activities and I hope that others will extend it.
> >
> > As you and Robert Scholte described, the situation around
> > maven-release-plugin and SCM artifacts is pathetic. I hope Jason will
> bring
> > some inspiration to make us all more optimistic.
> >
> >
> >
> > --
> > View this message in context:
> >
> http://maven.40175.n5.nabble.com/number-of-bugs-in-maven-release-plugin-tp5838696p5838800.html
> > Sent from the Maven Developers mailing list archive at Nabble.com.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Reproducibility versus ranges

2015-10-26 Thread Fred Cooke

There is a plugin by a friend of a friend (don't ask me what it's called)
that writes out a de-ranged pom.xml as part of the build, in the event that
you need to reproduce a build, eg, branching from a tag for a production
fix, you swap in the tag, drop in the pom, make the change down stream as
required, depend on it with [], and continue. We use ranges here for the
entire tree. External deps are isolated through compositions with fixed []
deps and they themselves are ranged (because we control them). It does
require "semver discipline", however it makes for predictable and fluid
development forward. Do note that you need to de-range transitively for
this to work, ie, transitively resolved artefacts must be in the new fixed
pom.

On Tue, Oct 27, 2015 at 6:03 AM, Benson Margulies 
wrote:

> On Mon, Oct 26, 2015 at 11:42 AM, Anders Hammar
>  wrote:
> > You're right, this is the problem. What would need to be done is the
> > version to be fixed for the release version (tag).
>
> Do we have any tooling for this? In my imagination, the top pom for a
> product to be released could be auto-decorated with
> dependencyManagement locks.
>
> >
> > /Anders (mobile)
> > Den 26 okt 2015 15:55 skrev "Benson Margulies" :
> >
> >> Folks,
> >>
> >> I would appreciate some assistance in thinking through the
> >> implications of the use of version ranges.
> >>
> >> As a thought experiment, consider a loosely-coupled collection of
> >> maven project, maintained with a semver discipline.
> >>
> >> Each component has dependencies, and those are written with ordinary
> >> dependency elements. No dependency management, no ranges.
> >>
> >> Maven will resolve version numbers, and the builds will be 100%
> >> reproducible. However, the resolution algorithm is not semver, it's
> >> doing the tree distance thing.
> >>
> >> So, to get semver semantics, I might consider adding ranges. However,
> >> and here I hope I'm confused, I just lost reproducibility. If someone
> >> adds a new version to the repository, a re-run of the build will
> >> select it if it satisfies the ranges. Rebuilding from the tag is not
> >> the same build.
> >>
> >> Am I missing something? Could it be that the release process somehow
> >> resolves the ranges and writes them into the poms?
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Reproducibility versus ranges

2015-10-26 Thread Fred Cooke

In our case, we don't want the original range back exactly, we want the
current version of that, ie, higher lower bound to currently released
things.

Do not forget the transient ranges that need to be locked in our modified
pom, either. Without this any tooling would be severely limited in use.

Fred.

On Tue, Oct 27, 2015 at 11:02 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> The idea I had in versions-m-p was to put XML PI with the original range
> beside the resolved value so that the range can be set back post prepare
> (see completionGoals)
>
> Oh where is my elusive time
>
> On Monday 26 October 2015, Bernd Eckenfels  wrote:
>
> > Am Mon, 26 Oct 2015 13:03:03 -0400
> > schrieb Benson Margulies >:
> > > Do we have any tooling for this? In my imagination, the top pom for a
> > > product to be released could be auto-decorated with
> > > dependencyManagement locks.
> >
> > I think besides the release-with-pom from the release plugin but also
> > versions:resolve-ranges:
> >
> > http://www.mojohaus.org/versions-maven-plugin/resolve-ranges-mojo.html
> >
> > Gruss
> > Bernd
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> > For additional commands, e-mail: dev-h...@maven.apache.org
> 
> >
> >
>
> --
> Sent from my phone
>

Re: Reproducibility versus ranges

2015-10-26 Thread Fred Cooke

Conflicting ranges should break the build, and would break it in the first
place. If it released OK in the first place with bounded ranges and your
repo still has the artifacts, it can be released again. If the old ranges
now won't release, you have a conflict to resolve in your tree.

On Tue, Oct 27, 2015 at 11:39 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Shoot me for not giving the full response.
>
> Release.properties is too hacky to contain all the info to be
> restored/restored with modifications.
>
> Never mind that if you lost the release.properties file and had to resume
> elsewhere you might get stuck.
>
> So in my view you need to stash the original range in the pom... XMLPI is
> the logical holder as it is a processing instruction for the release plugin
> (or versions plugin)
>
> You need to bump the lower limit to whatever the range got resolved to when
> switching back to development.
>
> The only remaining issue is how would people resolve conflicts of multiple
> dependencies all have conflicting hard ranges? (Ok you add excludes... But
> still could get hairy... Ok likely alerting of potential issue too there)
>
> On Monday 26 October 2015, Fred Cooke  wrote:
>
> > In our case, we don't want the original range back exactly, we want the
> > current version of that, ie, higher lower bound to currently released
> > things.
> >
> > Do not forget the transient ranges that need to be locked in our modified
> > pom, either. Without this any tooling would be severely limited in use.
> >
> > Fred.
> >
> > On Tue, Oct 27, 2015 at 11:02 AM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com > wrote:
> >
> > > The idea I had in versions-m-p was to put XML PI with the original
> range
> > > beside the resolved value so that the range can be set back post
> prepare
> > > (see completionGoals)
> > >
> > > Oh where is my elusive time
> > >
> > > On Monday 26 October 2015, Bernd Eckenfels  > > wrote:
> > >
> > > > Am Mon, 26 Oct 2015 13:03:03 -0400
> > > > schrieb Benson Margulies 
> > >:
> > > > > Do we have any tooling for this? In my imagination, the top pom
> for a
> > > > > product to be released could be auto-decorated with
> > > > > dependencyManagement locks.
> > > >
> > > > I think besides the release-with-pom from the release plugin but also
> > > > versions:resolve-ranges:
> > > >
> > > >
> http://www.mojohaus.org/versions-maven-plugin/resolve-ranges-mojo.html
> > > >
> > > > Gruss
> > > > Bernd
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >  
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > 
> > > 
> > > >
> > > >
> > >
> > > --
> > > Sent from my phone
> > >
> >
>
>
> --
> Sent from my phone
>

Re: Reproducibility versus ranges

2015-10-26 Thread Fred Cooke

False, you've locked to a specific version of a thing which depends on
ranges. This does not lock down those ranges, as it doesn't have enough
information to do that.

On Tue, Oct 27, 2015 at 1:42 PM, Bernd Eckenfels 
wrote:

> Hello,
>
> if you lock down ranges on release your dependencies will also have no
> ranges and you do not need to lock them down transitively.
>
> BTW: I really think tis is a topic for the maven-user list.
>
> Gruss
> Bernd
>
>  Am Tue, 27
> Oct 2015 11:21:09 +1300 schrieb Fred Cooke :
>
> > In our case, we don't want the original range back exactly, we want
> > the current version of that, ie, higher lower bound to currently
> > released things.
> >
> > Do not forget the transient ranges that need to be locked in our
> > modified pom, either. Without this any tooling would be severely
> > limited in use.
> >
> > Fred.
> >
> > On Tue, Oct 27, 2015 at 11:02 AM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > The idea I had in versions-m-p was to put XML PI with the original
> > > range beside the resolved value so that the range can be set back
> > > post prepare (see completionGoals)
> > >
> > > Oh where is my elusive time
> > >
> > > On Monday 26 October 2015, Bernd Eckenfels 
> > > wrote:
> > >
> > > > Am Mon, 26 Oct 2015 13:03:03 -0400
> > > > schrieb Benson Margulies >:
> > > > > Do we have any tooling for this? In my imagination, the top pom
> > > > > for a product to be released could be auto-decorated with
> > > > > dependencyManagement locks.
> > > >
> > > > I think besides the release-with-pom from the release plugin but
> > > > also versions:resolve-ranges:
> > > >
> > > >
> http://www.mojohaus.org/versions-maven-plugin/resolve-ranges-mojo.html
> > > >
> > > > Gruss
> > > > Bernd
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > >  For additional commands, e-mail:
> > > > dev-h...@maven.apache.org
> > > 
> > > >
> > > >
> > >
> > > --
> > > Sent from my phone
> > >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Reproducibility versus ranges

2015-10-26 Thread Fred Cooke

Ahh, but we do, everything is ranged! As explained, externals are ranged
via composites in between to isolate us from their whims, eg spring, etc.

On Tue, Oct 27, 2015 at 2:13 PM, Bernd Eckenfels 
wrote:

> If you do not release POMs with ranges there are no poms with ranges to
> depend on.
>
> Am Tue, 27 Oct 2015 14:03:01 +1300
> schrieb Fred Cooke :
>
> > False, you've locked to a specific version of a thing which depends on
> > ranges. This does not lock down those ranges, as it doesn't have
> > enough information to do that.
> >
> > On Tue, Oct 27, 2015 at 1:42 PM, Bernd Eckenfels
> >  wrote:
> >
> > > Hello,
> > >
> > > if you lock down ranges on release your dependencies will also have
> > > no ranges and you do not need to lock them down transitively.
> > >
> > > BTW: I really think tis is a topic for the maven-user list.
> > >
> > > Gruss
> > > Bernd
> > >
> > >  Am Tue, 27
> > > Oct 2015 11:21:09 +1300 schrieb Fred Cooke :
> > >
> > > > In our case, we don't want the original range back exactly, we
> > > > want the current version of that, ie, higher lower bound to
> > > > currently released things.
> > > >
> > > > Do not forget the transient ranges that need to be locked in our
> > > > modified pom, either. Without this any tooling would be severely
> > > > limited in use.
> > > >
> > > > Fred.
> > > >
> > > > On Tue, Oct 27, 2015 at 11:02 AM, Stephen Connolly <
> > > > stephen.alan.conno...@gmail.com> wrote:
> > > >
> > > > > The idea I had in versions-m-p was to put XML PI with the
> > > > > original range beside the resolved value so that the range can
> > > > > be set back post prepare (see completionGoals)
> > > > >
> > > > > Oh where is my elusive time
> > > > >
> > > > > On Monday 26 October 2015, Bernd Eckenfels
> > > > >  wrote:
> > > > >
> > > > > > Am Mon, 26 Oct 2015 13:03:03 -0400
> > > > > > schrieb Benson Margulies  > > > > > >:
> > > > > > > Do we have any tooling for this? In my imagination, the top
> > > > > > > pom for a product to be released could be auto-decorated
> > > > > > > with dependencyManagement locks.
> > > > > >
> > > > > > I think besides the release-with-pom from the release plugin
> > > > > > but also versions:resolve-ranges:
> > > > > >
> > > > > >
> > > http://www.mojohaus.org/versions-maven-plugin/resolve-ranges-mojo.html
> > > > > >
> > > > > > Gruss
> > > > > > Bernd
> > > > > >
> > > > > >
> -
> > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > >  For additional commands, e-mail:
> > > > > > dev-h...@maven.apache.org
> > > > > 
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Sent from my phone
> > > > >
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Unreadable dependency resolution/collection failure messages

2015-11-19 Thread Fred Cooke

Compare this original version:

[ERROR] Failed to execute goal on project emerge-monolithic-services: Could
not resolve dependencies for project
nz.co.company.emerge:emerge-monolithic-services:jar:40.166-SNAPSHOT: Failed
to collect dependencies for
nz.co.company.emerge:emerge-monolithic-services:jar:40.166-SNAPSHOT: Could
not resolve version conflict among
[nz.co.company.emerge:emerge-services:jar:[8.563,9) ->
nz.co.company.ristretto:ristretto-aaa-api:jar:[5.16,6),
nz.co.company.emerge:emerge-services:jar:[8.563,9) ->
nz.co.company.milo:emerge-task-services-v1:jar:[1.63,2) ->
nz.co.company.ristretto:ristretto-aaa-api:jar:[5.16,6),
nz.co.company.ristretto.aaa:ristretto-aaa-client:jar:[4.6,5) ->
nz.co.company.ristretto:ristretto-aaa-api:jar:[5.16,6),
nz.co.company.emerge.integration:emerge-digital-assets-axle-v1:jar:[1.17,2)
-> nz.co.company.ristretto:ristretto-aaa-api:jar:[3.8,4)] -> [Help 1]

With this manually formatted version:

[ERROR] Failed to execute goal on project emerge-monolithic-services: Could
not resolve dependencies for project
nz.co.company.emerge:emerge-monolithic-services:jar:40.166-SNAPSHOT: Failed
to collect dependencies for
nz.co.company.emerge:emerge-monolithic-services:jar:40.166-SNAPSHOT: Could
not resolve version conflict among [
nz.co.company.emerge:emerge-services:jar:[8.563,9) ->
nz.co.company.ristretto:ristretto-aaa-api:jar:[5.16,6)
nz.co.company.emerge:emerge-services:jar:[8.563,9) ->
nz.co.company.milo:emerge-task-services-v1:jar:[1.63,2) ->
nz.co.company.ristretto:ristretto-aaa-api:jar:[5.16,6)
nz.co.company.ristretto.aaa:ristretto-aaa-client:jar:[4.6,5) ->
nz.co.company.ristretto:ristretto-aaa-api:jar:[5.16,6)
nz.co.company.emerge.integration:emerge-digital-assets-axle-v1:jar:[1.17,2)
-> nz.co.company.ristretto:ristretto-aaa-api:jar:[3.8,4)
] -> [Help 1]

It's very hard to scan through the wrapped one line version looking for the
actual offending things, and tracing back their resolution paths in the
real version. In my hacked version you can easily scan each line and settle
on the end seeing exactly what's wrong in a fraction of a second.

If there's some agreement on this, I'd be happy to submit a patch. I've not
looked at where the code lives, but it's quite horrible to use right now.

Regards,

Fred.

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

2015-12-01 Thread Fred Cooke

My 2c:

Our shop has all of the infrastructure on Ubuntu (for better or worse) and
no LTS Ubuntu version exists with Java 8.

So for now we (and anyone else using Ubuntu) are stuck with a few options:

1) stay with 12.04/14.04 and J7
2) backport J8 to 14.04 and/or use a PPA
3) use a non-LTS stable version to get J8

Both 2 and 3 have issues and are a bit of work, so 1 is enduring. You won't
see responsible devs in our office rocking a J8-requiring Maven for a while
at least. That said, I'm OK with the one we're currently using, which is a
3.2 series Maven IIRC, and we're unlikely to require significant new
tooling for anything anyway.

Just a data point.

Regards,

Fred.



On Tue, Dec 1, 2015 at 10:07 PM, Stephane Nicoll 
wrote:

> I disagree. Changing system requirements in a minor release is kind of
> weird so I'd rather say that the current practice is problematic. I
> actually don't know the rationale to require Java8 in the codebase but if
> we do it please let's label that as a major release.
>
> S.
>
> On Tue, Dec 1, 2015 at 8:10 AM, Kristian Rosenvold <
> kristian.rosenv...@gmail.com> wrote:
>
> > Technically, JDK8 is entirely undramatic for maven; I'm having a hard
> > time understanding why it should trigger any api changes or any other
> > "4.0" reasons.
> >
> > I cannot make heads or tails of the supposed versioning policy, the
> > language is too convoluted for me or I'm just not smart enough.
> >
> > If we are to stay aligned with current practice, jdk8 should be a
> > minor release. As for the actual topic of "should" we switch, i'm
> > always in favour of moving forwards. But not in any religious sense.
> >
> >
> > Kristian
> >
> > 2015-12-01 6:59 GMT+01:00 Mirko Friedenhagen :
> > > +1 for Java 8 and the version bump to 4.x,.communicates the change more
> > > clearly.
> > >
> > > Regards
> > > Mirko
> > > --
> > > Sent from my mobile
> > > On Nov 30, 2015 23:44, "Stephen Connolly" <
> > stephen.alan.conno...@gmail.com>
> > > wrote:
> > >
> > >> I have no issues if we want to call the next version 4.0.x rather than
> > >> 3.4.x
> > >>
> > >> In my view there are some advantages to using the 4.0.x version number
> > as a
> > >> Java 8 bump... namely that leaves the modelVersion 5.0 changes to
> Maven
> > 5.0
> > >>
> > >> And let's face it, it will just be less confusing to users to say "To
> > build
> > >> a modelVersion 5.0 pom you need Maven 5"
> > >>
> > >> So if there is strong interest in jumping to Java 8 perhaps we just
> bite
> > >> the bullet and jump to Maven 4.0 with Java 8 now and then we can start
> > the
> > >> model version 5.0 debate in earnest as we plan the features for Maven
> > 5.0
> > >> ;-)
> > >>
> > >> -Stephen
> > >>
> > >> On 30 November 2015 at 22:25, Jason van Zyl  wrote:
> > >>
> > >> > I agree that jumping to Java 8 would be unwise. I think we can wait
> > until
> > >> > 4.x. Don’t get me wrong, I’d prefer to use Java 8 and I do for
> almost
> > >> > everything else but I don’t think there’s any dire rush.
> > >> >
> > >> > > On Nov 30, 2015, at 2:00 PM, Michael Osipov 
> > >> wrote:
> > >> > >
> > >> > > Am 2015-11-30 um 22:18 schrieb Stephen Connolly:
> > >> > >> Picking up from
> > >> > >>
> > >> >
> > >>
> >
> http://mail-archives.apache.org/mod_mbox/maven-dev/201511.mbox/%3CCA%2BnPnMyjogmqRweYbxLuULLB9ve2P6MPcQuH%2BPkxcNn-oN4GPg%40mail.gmail.com%3E
> > >> > >> (and my follow up to that but archive.apache.org is being a tad
> > slow)
> > >> > >>
> > >> > >> Here is our policy:
> > >> > >>
> > >> > >> The development line of Maven core should require a minimum JRE
> > >> version
> > >> > >>> that is no older than 18 months after the end of Oracle's public
> > >> > updates
> > >> > >>> for that JRE version at the time that the first version of the
> > >> > development
> > >> > >>> line was released, but may require a higher minimum JRE version
> if
> > >> > other
> > >> > >>> requirements dictate a higher JRE version
> > >> > >>
> > >> > >>
> > >> > >> (Source:
> > >> > >>
> > >>
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> > >> > )
> > >> > >>
> > >> > >> OK, so it's a draft policy... but we've all been silent on the
> > draft,
> > >> so
> > >> > >> lazy consensus!
> > >> > >>
> > >> > >> Now in
> > http://www.oracle.com/technetwork/java/javase/eol-135779.html
> > >> > they
> > >> > >> state:
> > >> > >>
> > >> > >> after April 2015, Oracle will not post further updates of Java SE
> > 7 to
> > >> > its
> > >> > >>> public download sites
> > >> > >>
> > >> > >>
> > >> > >> So per our (draft) version number policy, we can keep Java 7 as
> the
> > >> > >> baseline :-( or we can choose to upgrade code to Java 8 (because
> we
> > >> > want to
> > >> > >> use lambdas... there's a requirement)
> > >> > >>
> > >> > >>
> > >> > >> So assuming we bump the master branch of Maven core to 3.4.0,
> what
> > >> Java
> > >> > >> version do we want to use as the baseline?
> > >> > >>
> > >> > >> There are thankfully only two options:
> > >> >

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

2015-12-02 Thread Fred Cooke

"You can run maven with Java 8 right now, so it is not a change in any way
for those users."

This equates to ruling out developers who are forced to use older JDKs/JREs
if you look at it the other way.

"I agree that jumping to Java 8 would be unwise. I think we can wait until
4.x. Don’t get me wrong, I’d prefer to use Java 8 and I do for almost
everything else but I don’t think there’s any dire rush."

As per usual, Jason has it right, IMO.

Don't forget Maven is a tool, and as with libs, the decision to push
everything above you upward is a dangerous one. As far as tools go in J
land, they don't come much more foundational than Maven.

Regards,

Fred.

On Wed, Dec 2, 2015 at 9:38 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> If we look at our JVM company history, IIRC
>
> 2.0 = Java 1.4
> 2.1 = Java 1.4
> 2.2 = Java 1.5
> 3.0 = Java 1.5
> 3.1 = Java 1.6
> 3.2 = Java 1.6
> 3.3 = Java 1.7
>
> (I may have the jump versions out as this is from memory on my phone)
>
> So historically we have viewed bumping the minimum Java version as a minor
> change. The only strong argument I can see for running with 4.0 is to align
> the modelVersion... On the other hand actually having a maven version
> number that matches the modelVersion might cause confusion in users... The
> "oh this is moselVersion 4.0.0 so you need to use at least Maven 4"... On
> the one hand, great for adoption and we will want that for modelVersion
> 5.0.0... On the other hand it gives a false impression...
>
> So the question really becomes how intrinsic a part of the maven API is the
> baseline Java version.
>
> You can run maven with Java 8 right now, so it is not a change in any way
> for those users.
>
> We do have to start to recognise the risk of dependencies compiled with JDK
> 8... IOW when releasing bits of Maven we strictly require the release
> manager to use the base Java version. That puts restrictions on what the
> developers can use.
>
> The base version for plugins will always lag behind the base version for
> core. So, for example, plugins are only now getting up to Java 1.6 as a
> baseline... But it is getting harder for me to get a Java 6 to compile
> with... I know for building the animal sniffer signatures I couldn't get
> JDKs that could be installed on my primary OS at the time (Linux) down
> below 1.4... With some VMs I was able to get down to 1.3 for some JVMs and
> one set of 1.2 signatures. I can't get a Java 1.5 for my Mac... The 1.6 is
> getting hard we to install... So 1.7 is an effective baseline unless I
> develop in a VM... What will the story be in 2-3 years? The choice we make
> now affects that future.
>
> JDK 9 or 10 will drop support for at least -target 1.6 and perhaps -target
> 1.7 so as I see it we have to start being more aggressive whether that
> starts now or in 6 months when JDK 9 comes out is a timing question only
> IMHO
>
> On Wednesday 2 December 2015, Hervé BOUTEMY  wrote:
>
> > from source code point of view, you don't need to change anything to
> > compile
> > with JDK 8, true
> >
> > But what we showed with Arnaud in our ApacheCON demo (sorry to tell a lot
> > about it, but that was the topic...), JDK 8 compiler may introduce Java 8
> > API
> > references into bytecode from source that don't have any JDK 8 reference
> > See bonus demo [1] for a demo :)
> >
> > This is the first time in JDK history that such a behaviour happens:
> using
> > JDK
> > 8 instead of JDK 7 for launching Maven/javac does not give same result
> > (unless
> > using toolchains, of course).
> >
> > That's why I currently fear with JDK 8 that people will get some
> unexpected
> > failures. And during the conf, for a few attendees, this demo gave a
> "now I
> > understand what happened to me on one of my builds..." reaction
> >
> > Regards,
> >
> > Hervé
> >
> > [1]
> >
> https://github.com/MavenDemo/java-evolving-en/blob/master/toolchains/bonus.sh
> >
> > Le mardi 1 décembre 2015 08:10:51 Kristian Rosenvold a écrit :
> > > Technically, JDK8 is entirely undramatic for maven; I'm having a hard
> > > time understanding why it should trigger any api changes or any other
> > > "4.0" reasons.
> > >
> > > I cannot make heads or tails of the supposed versioning policy, the
> > > language is too convoluted for me or I'm just not smart enough.
> > >
> > > If we are to stay aligned with current practice, jdk8 should be a
> > > minor release. As for the actual topic of "should" we switch, i'm
> > > always in favour of moving forwards. But not in any religious sense.
> > >
> > >
> > > Kristian
> > >
> > > 2015-12-01 6:59 GMT+01:00 Mirko Friedenhagen  > >:
> > > > +1 for Java 8 and the version bump to 4.x,.communicates the change
> more
> > > > clearly.
> > > >
> > > > Regards
> > > > Mirko
> > > > --
> > > > Sent from my mobile
> > > > On Nov 30, 2015 23:44, "Stephen Connolly"
> > > > >
> > > >
> > > > wrote:
> > > >> I have no issues if we want to call the next version 4.0.x rather
> than
> > > >> 3.4.x
> > > >>
>

Re: Strange GIT

2016-05-29 Thread Fred Cooke

I cloned it, assuming you're talking about the linked hash, which is the
tip/head of master, then the diff shown is correct, you moved the package
declaration around under the auspices of "investigating". Your change must
be in an earlier commit. I looked at a few, but gave up.

On Mon, May 30, 2016 at 4:05 PM, Tibor Digana 
wrote:

> Hi all,
>
> The Git/GitHub diff does not show me real changes [1] I made.
> Our Jenkins CI does not update the Maven project with these changes.
>
> What's going on wrong?
> I am using git 1.9.5.0.msysgit.0.
>
> The content [2] on GitHub contains my changes but the diff does not.
>
> [1]
>
> https://github.com/apache/maven-surefire/commit/ce3bdd50678c1e83efe55a1f243631dedac01921#diff-dadf82ac2a525e3b95545bb671364989
>
> [2]
>
> https://github.com/apache/maven-surefire/blob/ce3bdd50678c1e83efe55a1f243631dedac01921/surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/jiras/Surefire1211JUnitTestNgIT.java
>
> I have added several lines of the change:
>
> @Before
> public void before() {
> System.out.println( "java.specification.version: " + getProperty(
> "java.specification.version" ) );
> System.err.println( "java.specification.version: " + getProperty(
> "java.specification.version" ) );
> }
>
>
>
> --
> Cheers
> Tibor
>

Re: Strange GIT

2016-05-29 Thread Fred Cooke

I take that back. In a single blow, you changed the entire file! Why?
Because since that file was created on Christmas eve 2015, it has had
broken line endings. Fix up the line endings and move on.

On Mon, May 30, 2016 at 4:20 PM, Fred Cooke  wrote:

> I cloned it, assuming you're talking about the linked hash, which is the
> tip/head of master, then the diff shown is correct, you moved the package
> declaration around under the auspices of "investigating". Your change must
> be in an earlier commit. I looked at a few, but gave up.
>
> On Mon, May 30, 2016 at 4:05 PM, Tibor Digana  > wrote:
>
>> Hi all,
>>
>> The Git/GitHub diff does not show me real changes [1] I made.
>> Our Jenkins CI does not update the Maven project with these changes.
>>
>> What's going on wrong?
>> I am using git 1.9.5.0.msysgit.0.
>>
>> The content [2] on GitHub contains my changes but the diff does not.
>>
>> [1]
>>
>> https://github.com/apache/maven-surefire/commit/ce3bdd50678c1e83efe55a1f243631dedac01921#diff-dadf82ac2a525e3b95545bb671364989
>>
>> [2]
>>
>> https://github.com/apache/maven-surefire/blob/ce3bdd50678c1e83efe55a1f243631dedac01921/surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/jiras/Surefire1211JUnitTestNgIT.java
>>
>> I have added several lines of the change:
>>
>> @Before
>> public void before() {
>> System.out.println( "java.specification.version: " + getProperty(
>> "java.specification.version" ) );
>> System.err.println( "java.specification.version: " + getProperty(
>> "java.specification.version" ) );
>> }
>>
>>
>>
>> --
>> Cheers
>> Tibor
>>
>
>

Re: Allowed characters in GAV and how/where to sanitize?

2018-01-10 Thread Fred Cooke

Re versions, I know the background on it, but it annoys me that maven can't
handle 4 part versions, 1.2.3.4 as sometimes it's handy to do a patch level
that deep. Lots of messed up software in the world :-)

Format should be N[.N as many times as needed][optional hyphen and
qualifier of some sort] or something like that. Not hard limited to 1 2 or
3 parts.

On 10 January 2018 at 22:21, Andreas Sewe <
s...@st.informatik.tu-darmstadt.de> wrote:

> Hervé BOUTEMY wrote:
> > notice that Central contains artifacts produced by Maven but also by
> other
> > tools: I did some analysis myself and found strange things also that are
> > clearly not produced by Maven. Scala for example produces some artifacts
> that
> > I doubt could be referenced by Maven.
>
> Yes, Maven is not the only tool that can deploy artifacts to Central --
> and that's a good thing.
>
> > Then: what do we call "broken"?
> > Something that seems "clearly" related to a typo?
> > Something that can't be consumed by Maven?
> > Something that people who produced the release (with any tooling) won't
> > consume for syntactic reasons on the result? Something that they won't
> consume
> > for other reasons? (like for example because it's continuous deployment
> and
> > it's the 4th version of the day)
>
> I wouldn't go so far to treat version=1.6.2.1 as an illegal version
> (after all, I can image someone using legitimately using a qualifier
> scheme like 1.2.3-os=linux), but there are IMHO two cases which I always
> consider broken:
>
> - Spaces in any of the components of a GAV
> - A colon in any of the components of a GAV
>
> Spaces are just likely to cause trouble for some tool further down the
> line.
>
> And for colons we know that they will cause trouble, being the default
> separator for GAVs when written as a single string.
>
> Aside from those characters, I would probably just ban a few characters
> (non-printable control characters). A bit similar to what XML did with a
> its NCName (non-colon name) production [1].
>
> However, for groudId and artifactId we already have much stricter rules
> (A-Z, a-z, 0-9, ., -, _), so the argument can be made that
> versions/classifiers/extensions should also be made up of a more limited
> character set as well.
>
> In particular, care should to be taken that the path component can still
> be parsed unambiguously, so allowing '.' in a classifier is probably
> asking for trouble.
>
> > And what can we do?
> > On the past artifacts, removing anything is not really an option: IMHO,
> the
> > issue does not deserve the effort and to break our base rule about
> > inalterability.
> > On the future, perhaps we can do something:
> > - at Maven level, sure we can and we should improve controls as much as
> > possible
>
> Yes, if only that at this level we can provide the best error messages,
> as the error is recognized closest to the user.
>
> > - on other build tools: perhaps we should try not only to implement
> checks in
> > Maven but also document rules for other tools to implement same rules
>
> The Maven Resolver is a great place to enforce some rules in
> DefaultArtifact (or whatever replaces it). Granted, not everyone deploys
> using the Maven Resolver, but its *the* place that knows about all the
> intricacies of the repository layout already.
>
> > - on repo managers used by the publishers: same rules documentation
> > prerequisite, but other tools target
>
> Well, Nexus already has some checks in place, to avoid versions like
> "1/../../other-artifact/2". However, groupIds like "org...example" are
> still accepted (deployed under org/example).
>
> > - on sync to central: this is the only location where some rules can be
> > checked for absolutely any new artifact then really interesting at a
> first
> > glance. But making rules evolve at this level is really hard since there
> is no
> > real feedback process I know of when base Central publication rules are
> not
> > met. Base Central publication rules were defined from the beginning
> (signature,
> > ...), then are implemented by publishers' repo managers. I suppose failed
> > controls done by sync to central (then sync blocked) are rare: I'm not
> sure
> > there is a strong process/tooling. And adding it would cost some
> management:
> > not easy. IMHO, we should start by first detecting if there are really
> issues
> > on new artifacts these days before trying to take actions at this level.
>
> That being said, I think the first step is to document the syntax for
> GAVs somewhere (e.g., at [2] or [3]).
>
> Best wishes,
>
> Andreas
>
> [1] 
> [2] 
> [3] 
>
>
>

Re: Allowed characters in GAV and how/where to sanitize?

2018-01-10 Thread Fred Cooke

Looks like I'm just plain wrong (and happy about it). I'm not sure where
that memory came from. Perhaps maven 2 some time ago, though it felt fresh
in my mind. Apologies for the noise! :-(

On 11 January 2018 at 11:22, Hervé BOUTEMY  wrote:

> Le mercredi 10 janvier 2018, 10:21:35 CET Andreas Sewe a écrit :
> > Hervé BOUTEMY wrote:
> > > notice that Central contains artifacts produced by Maven but also by
> other
> > > tools: I did some analysis myself and found strange things also that
> are
> > > clearly not produced by Maven. Scala for example produces some
> artifacts
> > > that I doubt could be referenced by Maven.
> >
> > Yes, Maven is not the only tool that can deploy artifacts to Central --
> > and that's a good thing.
> +1
>
> >
> > > Then: what do we call "broken"?
> > > Something that seems "clearly" related to a typo?
> > > Something that can't be consumed by Maven?
> > > Something that people who produced the release (with any tooling) won't
> > > consume for syntactic reasons on the result? Something that they won't
> > > consume for other reasons? (like for example because it's continuous
> > > deployment and it's the 4th version of the day)
> >
> > I wouldn't go so far to treat version=1.6.2.1 as an illegal version
> I was not talking about a version with 4 parts: Maven 3 supports an
> arbitrary
> count of parts.
> I was talking about an artifact that is released 4 times per day, because
> it's
> continuous delivery (I suppose): a vast majority of releases are IMHO never
> used
>
> > (after all, I can image someone using legitimately using a qualifier
> > scheme like 1.2.3-os=linux), but there are IMHO two cases which I always
> > consider broken:
> >
> > - Spaces in any of the components of a GAV
> > - A colon in any of the components of a GAV
> +1
>
> >
> > Spaces are just likely to cause trouble for some tool further down the
> line.
> >
> > And for colons we know that they will cause trouble, being the default
> > separator for GAVs when written as a single string.
> >
> > Aside from those characters, I would probably just ban a few characters
> > (non-printable control characters). A bit similar to what XML did with a
> > its NCName (non-colon name) production [1].
> +1
>
> >
> > However, for groudId and artifactId we already have much stricter rules
> > (A-Z, a-z, 0-9, ., -, _), so the argument can be made that
> > versions/classifiers/extensions should also be made up of a more limited
> > character set as well.
> +1
>
> >
> > In particular, care should to be taken that the path component can still
> > be parsed unambiguously, so allowing '.' in a classifier is probably
> > asking for trouble.
> +1 again
>
> >
> > > And what can we do?
> > > On the past artifacts, removing anything is not really an option: IMHO,
> > > the
> > > issue does not deserve the effort and to break our base rule about
> > > inalterability.
> > > On the future, perhaps we can do something:
> > > - at Maven level, sure we can and we should improve controls as much as
> > > possible
> >
> > Yes, if only that at this level we can provide the best error messages,
> > as the error is recognized closest to the user.
> >
> > > - on other build tools: perhaps we should try not only to implement
> checks
> > > in Maven but also document rules for other tools to implement same
> rules
> > The Maven Resolver is a great place to enforce some rules in
> > DefaultArtifact (or whatever replaces it). Granted, not everyone deploys
> > using the Maven Resolver, but its *the* place that knows about all the
> > intricacies of the repository layout already.
> >
> > > - on repo managers used by the publishers: same rules documentation
> > > prerequisite, but other tools target
> >
> > Well, Nexus already has some checks in place, to avoid versions like
> > "1/../../other-artifact/2". However, groupIds like "org...example" are
> > still accepted (deployed under org/example).
> probably ".." should be forbidden also
>
> >
> > > - on sync to central: this is the only location where some rules can be
> > > checked for absolutely any new artifact then really interesting at a
> first
> > > glance. But making rules evolve at this level is really hard since
> there
> > > is no real feedback process I know of when base Central publication
> rules
> > > are not met. Base Central publication rules were defined from the
> > > beginning (signature, ...), then are implemented by publishers' repo
> > > managers. I suppose failed controls done by sync to central (then sync
> > > blocked) are rare: I'm not sure there is a strong process/tooling. And
> > > adding it would cost some management: not easy. IMHO, we should start
> by
> > > first detecting if there are really issues on new artifacts these days
> > > before trying to take actions at this level.
> > That being said, I think the first step is to document the syntax for
> > GAVs somewhere (e.g., at [2] or [3]).
> +1
> there is an edit button near the title to find the source and propose a P

Re: [ANN] Apache Maven 3.5.3 Released

2018-03-08 Thread Fred Cooke

3.5.3 as per subject and list or 3.5.2 as per opening sentence? Guessing
the former.

On 9 March 2018 at 01:31, Stephen Connolly  wrote:

> The Apache Maven team is pleased to announce the release of the Apache
> Maven 3.5.2
>
> You can download the appropriate sources etc. from the download page
>
> Contributors
> 
> The Apache Maven team would like to thank the following contributors,
> without whom this release would not have been possible:
>
> Code contributors:
>
> - Sylwester Lachiewicz
> - Bengt Söderberg
> - Robin Müller
> - Romain Manni-Bucau
>
> Issue reporters:
>
> - Ryan Heaton
> - Ryan J McDonough
> - Andreas Kurth
> - Ben Caradoc-Davies
> - Romain Manni-Bucau
> - Robin Müller
> - Dejan Stojadinović
> - Andrew Kennedy
> - Sylwester Lachiewicz
> - Andy Wilkinson
> - Eugene Pliskin
> - Tony Guan
>
> Community testers participating in voting for this release:
>
> - Sylwester Lachiewicz
> - Grzegorz Grzybek
>
> Thank you for your time and feedback.
>
>
> Release Notes - Maven - Version 3.5.3
>
> ***Known issues***:
>* [MNG-6372] - On Windows with -T option, Maven can output spurious ANSI
> escapes such as [0m [0m
>
> Bug:
> * [MNG-6188] - Console color not properly reset when interrupting build
> process
> * [MNG-6255] - Maven script cannot parse jvm.config with CRLF
> * [MNG-6282] - Console output has no colors in shell (both Git Bash and
> Cygwin) [regression in Jansi 1.16 / Maven 3.5.1]
> * [MNG-6296] - New option -Dstyle.color is not working
> * [MNG-6298] - 3.5.2: ClassNotFoundException:
> javax.annotation.security.
> RolesAllowed
> * [MNG-6300] - Multi module release creates empty directories in war
> file instead of jars
> * [MNG-6305] - Validation of CI friendly version incorrect
> * [MNG-6320] - Apparently wrong encoding of non-ascii java class
> filename in error messages in the maven log
> * [MNG-6323] - Deadlock in multithreaded dependency resolution
> * [MNG-6330] - [regression] Parents relativePath not verified anymore
>
> New Feature:
> * [MNG-6302] - Provide some "progress" hints
>
> Improvement:
> * [MNG-5992] - Git passwords are exposed as the Super POM still uses
> Maven Release Plugin 2.3.2
> * [MNG-6306] - Replace use of Guava in maven-resolver-provider with a
> lighter weight alternative
> * [MNG-6308] - display packaging & groupId:artifactId when building a
> module
> * [MNG-6332] - Cleaned up mvn.cmd Script
> * [MNG-6340] - [Performance]To make System.gc() call configurable in
> target summary code
> * [MNG-6342] - Emit a WARNING about LATEST/RELEASE in parent
> * [MNG-6352] - Printout version information at the end of the build
>
> Task:
> * [MNG-6331] - Remove maven-bundle-pugin from build pluginManagement
>
> Dependency upgrade:
> * [MNG-6312] - Update Maven Wagon dependency
> * [MNG-6335] - Update test framework Mockito from 1.10 to 2.12
> * [MNG-6353] - Upgrade maven-shared-utils to 3.2.1
>
> Enjoy,
>
> -The Apache Maven team
>

Re: IRC Chat

2018-08-17 Thread Fred Cooke

Yes, create an account, spam attack = +r set on most channels and
registration required to enter. Hope that helps.

On 18 August 2018 at 00:37, Christian Stein  wrote:

> Hi Maven-Devs,
>
> tried to join #maven-dev via http://webchat.freenode.net but it
> does not work like it used to do. I guess, one has to
>
>   Auth to services: [ ]
>
> now, but which user/pass is required? Do I have to create an
> account at freenode.net?
>
> Cheers,
> Christian
>

Re: IRC Chat

2018-08-17 Thread Fred Cooke

The process is done through IRC, there will be a help page on freenode
somewhere, search register or similar.

You connect with desired nickname, and then send commands to nickserv to
sort it out.

On 18 August 2018 at 04:47, Christian Stein  wrote:

> On Fri, Aug 17, 2018 at 2:41 PM Fred Cooke  wrote:
>
> > Yes, create an account, spam attack = +r set on most channels and
> > registration required to enter. Hope that helps.
> >
> >
> Okay, understood. But, can't find a registration page at
> https://freenode.net
> Can you please point me to it ... or are the apache credentials accepted
> there?
>

1 2 >

1 - 100 of 177 matches

Mail list logo