Re: Issue with 3.8.2 and support status of 3.6.3, 3.5.X, 3.3.X and .3.2.X

[Fred Cooke]

Gidday Tamas,

Yeah, I'm not surprised. I don't install maven on my personal machines with
Brew, I grab and expand the tarball and have a system of symlinks to switch
around easily from old to new etc (I have some crappy old projects I still
need to build with old JDK and old Maven).

But at work, Mac. With corporate spyware, no less. And Brew is how we get
OpenSSL, Git, Maven, OpenJDK, and Branchout (a great tool a friend of mine
wrote that I've been contributing to as much as I can, not perfect yet, but
pretty good depending on your style/needs).

My hope was that I could set a Maven@3.8.1 dependency in Branchout's brew
project to avoid 3.8.2, however I saw it wasn't there, but ancient stuff
WAS there, and thought "sweet, I'll just contribute it", but nope, not so
fast :-D What's amazing to me is that they wouldn't accept a legit 3.6 but
have 3.5, 3.3, and 3.2 - all great versions back in their day, but all
obsolete outside of say super old fashioned slow adopting banks or
whatever. That's mind blowing. I'd do a PR to remove the older ones, but
someone might be using them, and I couldn't live with myself, however the
inconsistency totally bothers me :-D

Always game to "try latest" but when it's work, continuity and stability
are needed, and Brew certainly doesn't provide that. If 3.8.3 is a fizzer
[1] I'll add a "tap" of 3.8.1 to Branchout side by side with the branchout
formula files and depend directly on that. Then it'll be stable. But that
seems like a lot of work for something that could be supported out of the
box especially considering formulae are text files and no hosting is
required...

Wasn't aware of sdkman, but I don't decide what dozens of mac users use.
Used to be fink, then it was ports, now it's brew, it's probably not the
last project to try to fill the voids apple leaves. :-)

To be fair, it's worked well up until now, just 3.8.2 didn't cut the
mustard for us, but I'm sure along the way there were flaws in the 3.6
series that were deal breakers for others while they were fine for us. Such
is life :-)

Cheers,

Fred.

[1] Firework where only the fuse burns (fizzes) leaving you wondering if
it's about to blow, ruining the excitement, and causing a gap in the fun
while you wait until it's probably safe to pick up :-D

On Fri, 1 Oct 2021 at 19:04, Tamás Cservenák  wrote:

> Howdy,
>
> I was chased away from Brew many times with the words "it's not a version
> manager" :)
>
> Yes, Brew is a tool that helps you install stuff, but it really focus on
> "latest", and does not have a notion of package "version", they solve it
> (correct me if I'm wrong), by doing some trickeries around formulas (so
> X.0.1 and X.0.2 are actually TWO formulas).
>
> In short, I don\t want to be smartxss, but:
> - are you sure Brew is the tool you want to provision Maven?
> - Are you aware of SDKMAN (https://sdkman.io/) for example, that is able
> to
> do exactly what you need, out of the box?
>
> But in general, I am completely aligned with Karl, try latest (as you
> noticed, soon 3.8.3)
>
> HTH
> Tamas
>
>
>
> On Fri, Oct 1, 2021 at 12:41 AM Fred Cooke  wrote:
>
> > Hey Karl,
> >
> > Thank you very much for your response and for all your work over the
> years!
> > :-)
> >
> > Now that I'm awake and not desperate to go to bed, I found the issue
> > reported by someone else, but NOT on maven:
> > https://issues.apache.org/jira/browse/MINVOKER-283
> >
> > However the comment from Michael Osipov suggests that it probably has
> been
> > identified in Maven and is likely included with 3.8.3 which (awesome to
> > hear) is coming out very soon.
> >
> > Thanks to everyone who jumped on the ticket. I'll add my 2c there in a
> > minute - it's already closed (harsh) but a bit of follow up is necessary.
> >
> > To be clear, I wasn't complaining about Maven, I've been using it since
> > 2.0.4 or maybe earlier and have always been a huge fan. It's a hairy
> beast
> > and progress necessitates making calls to break things sometimes. I don't
> > know if that's what this is, or if it's just a regression because hairy,
> > but either way, it's normal for software to have various issues over
> > various versions through its lifetime. The issue is that Brew has a very
> > narrow view of "use only the latest" which is never practical. Such
> > impractical views are regularly the work of Apple and deciphels thereof
> but
> > you won't find that in Debian where you can get stuff from WAY back IF
> you
> > need it. Same for ubu and I imagine same for most distros. I mean, look
> at
> > maven central, you need something from 2005? No problem. Brew: You need
> > something from LAST WEEK - absolutely not! :-D

Re: Issue with 3.8.2 and support status of 3.6.3, 3.5.X, 3.3.X and .3.2.X

[Fred Cooke]

Hey Karl,

Thank you very much for your response and for all your work over the years!
:-)

Now that I'm awake and not desperate to go to bed, I found the issue
reported by someone else, but NOT on maven:
https://issues.apache.org/jira/browse/MINVOKER-283

However the comment from Michael Osipov suggests that it probably has been
identified in Maven and is likely included with 3.8.3 which (awesome to
hear) is coming out very soon.

Thanks to everyone who jumped on the ticket. I'll add my 2c there in a
minute - it's already closed (harsh) but a bit of follow up is necessary.

To be clear, I wasn't complaining about Maven, I've been using it since
2.0.4 or maybe earlier and have always been a huge fan. It's a hairy beast
and progress necessitates making calls to break things sometimes. I don't
know if that's what this is, or if it's just a regression because hairy,
but either way, it's normal for software to have various issues over
various versions through its lifetime. The issue is that Brew has a very
narrow view of "use only the latest" which is never practical. Such
impractical views are regularly the work of Apple and deciphels thereof but
you won't find that in Debian where you can get stuff from WAY back IF you
need it. Same for ubu and I imagine same for most distros. I mean, look at
maven central, you need something from 2005? No problem. Brew: You need
something from LAST WEEK - absolutely not! :-D Hilarious.

Cheers,

Fred.

On Fri, 1 Oct 2021 at 09:11, Karl Heinz Marbaise  wrote:

> Hi,
>
> On 30.09.21 15:49, Fred Cooke wrote:
> > Hi all,
> >
> > We've hit an issue with maven 3.8.2 which a lot of our clients use on
> macs
> > through Brew and although brew supports the latest 3.8, 3.5, 3.3, 3.2
> > versions it does not support 3.8.1 which doesn't have the regression and
> > does not have 3.6 which was also fine for our purposes.
> >
> > I'm not sure if the issue we've got has been reported (not by me at
> least)
> > and I can certainly get that information, but it'd be helpful if someone
> > like Robert of Stephen could chime in on this PR:
> >
> > https://github.com/Homebrew/homebrew-core/pull/86192 < Put 3.6.3 back in
> > Brew on mac as an option.
>
> First It would be very helpful to know about what you are talking? Have
> you created an JIRA issue for it? Have you checked the JIRA for it if
> one already exist?
>
> Furthermore If someone has an issue with a particular Maven version than
> use the most recent one of that's not possible go down one
> version...that's it...
>
> Most important here is to report such things. If we don't know anything
> how could we know and even more important how could we fix it..
>
> Another thing is why should one of our devs get into a homebrew parts?
> Also as Michael already wrote...
>
>  > The general approach is that every new version supersedes old
> version. There is no old minor version support.
>
>  > Forget anything before 3.5.4 or even 3.6.3. If 3.8.3 proves to be
> regression-free, forget 3.6.3 as
>
> Always use the most recent one...
>
> Kind regards
> Karl Heinz Marbaise
>
> >
> > I don't mind if in support or against my comments and intent, just keen
> to
> > see a resolution for ~50 developers :-D
> >
> > Regards,
> >
> > Fred (3am, off to bed!)
> >
>

Issue with 3.8.2 and support status of 3.6.3, 3.5.X, 3.3.X and .3.2.X

[Fred Cooke]

Hi all,

We've hit an issue with maven 3.8.2 which a lot of our clients use on macs
through Brew and although brew supports the latest 3.8, 3.5, 3.3, 3.2
versions it does not support 3.8.1 which doesn't have the regression and
does not have 3.6 which was also fine for our purposes.

I'm not sure if the issue we've got has been reported (not by me at least)
and I can certainly get that information, but it'd be helpful if someone
like Robert of Stephen could chime in on this PR:

https://github.com/Homebrew/homebrew-core/pull/86192 < Put 3.6.3 back in
Brew on mac as an option.

I don't mind if in support or against my comments and intent, just keen to
see a resolution for ~50 developers :-D

Regards,

Fred (3am, off to bed!)

Re: Issues to be done for Maven Core 4.0.0-alpha-1?

[Fred Cooke]

Thanks for that, Robert!

Aside from the 5 page issue list of what actually got done, is there
somewhere where the intention and motivation for the change was documented
before the key work (a subset of that list) was done? Or just other threads
in this mailing list (which I don't read as often as I should, but I do
recall some of the two-poms discussions a while back).

I was unable to find the ticket about what "ci-friendly versions" means but
if that's only for mostly-anti-pattern MM projects, no bother, my curiosity
will quickly fade :-D

Duplicate dependencies will be an error is most welcome! :-) I don't think
that's ever happened to me, but the number of times I've fixed it for
sloppy careless others is horrendous.

The wrapper plugin main page could do with an intro and some use cases that
it satisfies, there's almost nothing there but the usage page goes through
it in a bit more detail than belongs on the main page and makes it clear
(except why that would be useful, maybe some CI where you don't control the
container content?).

I don't understand the concept of a local execution of a plugin using an
uploaded pom rather than the local one. To make it clear why, what about -o
builds? What does "uploaded" really mean?

But yes, the two-poms stepping stone makes it clear why the bump, that's a
big departure from the past.

Cheers,

Fred.

On Sun, 23 May 2021 at 22:58, Robert Scholte  wrote:

> TLDR; Most things will still work, but some things will break.
>
> Maven 4 is the preparation for Maven 5, where we will be able to introduce
> a new pom model. To keep the Maven eco system stable, it must be possible
> to upload model 4.0.0 compatible poms to remote repositories, especially to
> Central.
> Every plugin that uses the local pom where it should be using the uploaded
> pom will fail, think about the plugins that sign. These need to be
> rewritten.
> To support this, huge changes had to be made in the architecture of Maven.
> This to proof that we can transform pom files without any impact.
> Maven 4 must proof this transforming mechanism, Maven for will be able to
> expand and clean up the pom.This is reflected by the following new features
> for multimodule projects:
> - automatic parent version based on relativePath
>
> - automatic dependency version for reactor dependencies.
> - proper ci-friendly versioning
>
> Some other things that might break your build:
> - require Java 8
> - upgrade of the default versions of the plugins per packaging type
> - strict checksum validation
>
> - removal of some deprecated Maven2 commandline flags
> - some warnings will now be errors (e.g. duplicate dependencies in your
> pom.xml)
> - removal of release-profile from super-pom
>
> New features:
> - maven-wrapper is now part of Maven core. There's a new lifecycle for it
> ('mvn wrapper') and a new plugin('maven-wrapper-plugin)
> - improved commandline options when working with multimodule projects.
> - jansi based console output improvements
>
> This is just a short summary of the release[1], but it should give you an
> idea why this version should be called Maven 4.
>
> thanks,
> Robert
>
> [1]
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-alpha-1
>
> On 23-5-2021 11:55:59, Fred Cooke  wrote:
> Is there somewhere where I can read about the rationale behind the first
> major version bump since I learned M2 15 years ago and what's changed in a
> positive but breaking fashion that warranted that bump?
>
> Just the 4 sounds exciting without any context. I hope the context lives up
> to it, but 3 has been serving me SO well for such a long time, I'm
> skeptical :-D
>
> Introduction of repaint.io tiles as the default parent mechanism, perhaps?
>
> Cheers,
>
> Fred.
>
> PS: Disclaimer: I've not even tried 3.8.2 yet! And only just upgraded my
> personal stuff from 3.3.9 to 3.6.3 without any breakage at all.
>
> On Sun, 23 May 2021 at 21:43, Martin Kanters
> wrote:
>
> > Hi all,
> >
> > With MNG-6915 [1] being merged yesterday, all Jansi-related PRs are
> merged.
> > AFAIK there is nothing pressing left for the Maven 4.0.0-alpha-1 release,
> > or am I missing something?
> >
> > Martin
> >
> > [1] https://issues.apache.org/jira/browse/MNG-6915
> >
> > Op di 4 mei 2021 om 19:56 schreef Martin Kanters
> > >:
> >
> > > @Guillaume Great, thanks for updating them! I'm processing them as we
> > > speak.
> > >
> > > Martin
> > >
> > > Op di 4 mei 2021 om 15:13 schreef Michael Osipov :
> > >
> > >> Am 2021-05-03 um 20:35 schrieb Guillaume Nodet:
> > >> > Now that maven-shared-utils has been released, I've rebased my PRs:
> > >> > https://github.com/apache/maven/pulls/gnodet
> > >>
> > >> Darn, I would I could review your quality PRs, still busy with
> > Resolver...
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >> For additional commands, e-mail: dev-h...@maven.apache.org
> > >>
> > >>
> >
>

Re: Issues to be done for Maven Core 4.0.0-alpha-1?

[Fred Cooke]

Is there somewhere where I can read about the rationale behind the first
major version bump since I learned M2 15 years ago and what's changed in a
positive but breaking fashion that warranted that bump?

Just the 4 sounds exciting without any context. I hope the context lives up
to it, but 3 has been serving me SO well for such a long time, I'm
skeptical :-D

Introduction of repaint.io tiles as the default parent mechanism, perhaps?

Cheers,

Fred.

PS: Disclaimer: I've not even tried 3.8.2 yet! And only just upgraded my
personal stuff from 3.3.9 to 3.6.3 without any breakage at all.

On Sun, 23 May 2021 at 21:43, Martin Kanters 
wrote:

> Hi all,
>
> With MNG-6915 [1] being merged yesterday, all Jansi-related PRs are merged.
> AFAIK there is nothing pressing left for the Maven 4.0.0-alpha-1 release,
> or am I missing something?
>
> Martin
>
> [1] https://issues.apache.org/jira/browse/MNG-6915
>
> Op di 4 mei 2021 om 19:56 schreef Martin Kanters  >:
>
> > @Guillaume Great, thanks for updating them! I'm processing them as we
> > speak.
> >
> > Martin
> >
> > Op di 4 mei 2021 om 15:13 schreef Michael Osipov :
> >
> >> Am 2021-05-03 um 20:35 schrieb Guillaume Nodet:
> >> > Now that maven-shared-utils has been released, I've rebased my PRs:
> >> >https://github.com/apache/maven/pulls/gnodet
> >>
> >> Darn, I would I could review your quality PRs, still busy with
> Resolver...
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
>

Re: IRC: still being used?

[Fred Cooke]

Yeah, it still gets a bit of traffic.

On Tue, 31 Mar 2020 at 00:43, Elliotte Rusty Harold 
wrote:

> A lot of our docs and READMEs talk about the IRC channel. E.g.
>
> #Maven IRC channel on freenode.org
>
> Is this still in use? Or should  I remove this from the docs where I
> find it and perhaps point folks to the slack instead?
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: IRC Chat

[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?
>

Re: IRC Chat

[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: [ANN] Apache Maven 3.5.3 Released

[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: Allowed characters in GAV and how/where to sanitize?

[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 

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

[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: Building a Java9 project just using JDK9

[Fred Cooke]

I'll throw my 2c in here, too:

Java 9 runtime forces me to rewrite parts of my application because
non-root thread priority control is no longer available. Plenty of people
have relied on lines like this to achieve their desired behaviour:

java -jar -Xms128m -Xmx1024m *-XX:ThreadPriorityPolicy=42*
/usr/share/java/some.jar "$@"

Not only is thread deprioritisation as non-root no longer available
(arbitrary decision on JRE's part, OS can do it!), the JRE won't even start
up with that line, rejecting it entirely as invalid when it's been
*unofficially* valid since who knows when.

I understand that it's roughly equivalent to equivalent importing from
com.sun, however the existing behaviour could simply have been documented
and an official numeric option for "reasonable behaviour" added, then
making it compatible without breaking J8 JRE compatibility would have been
as simple as dropping the 4, or similar.

Aside from that, the extra class included when compiled with J9 is not
bytecode compatible, even if the rest of the jar is. That breaks the
obfuscator. Solvable by not using the latest/greatest, but... somewhat
annoying when the rest of the jar is fine.

Regards,

Fred.


On 14 August 2017 at 03:30, Tibor Digana 
wrote:

> I found an issue. JDK printed this on std/out:
> WARNING: Using incubator modules: jdk.incubator.httpclient
>
> It hapens after my test:
>
> import org.junit.Test;
>
> public class J9Test
> {
> @Test
> public void testMiscellaneousAPI() throws java.sql.SQLException
> {
> System.out.println( "loaded class " +
> java.sql.SQLException.class.getName() );
> System.out.println( "loaded class " +
> javax.xml.ws.Holder.class.getName() );
> System.out.println( "loaded class " +
> javax.xml.bind.JAXBException.class.getName() );
> System.out.println( "loaded class " +
> org.omg.CORBA.BAD_INV_ORDER.class.getName() );
> System.out.println( "loaded class " +
> javax.xml.xpath.XPath.class.getName() );
> System.out.println( "java.specification.version=" +
> System.getProperty( "java.specification.version" ) );
> }
>
> @Test
> public void test_corba_mod() throws org.omg.CORBA.BAD_INV_ORDER
> {
> }
> }
>
>
> On Sun, Aug 13, 2017 at 5:29 PM, Tibor Digana  >
> wrote:
>
> > But why to add it? It's a hack. I do not use module-info.java and so
> there
> > is no reason to break the backwards compatibility.
> >
> > This is no more about Maven. It is about entire Java world.
> > If we in Maven do it then everybody has to.
> > And I am sure that the voices says that Kotlin is better and Scala is
> > better would make sense. Why to help these attempts to happen? No reason!
> >
> > On Sun, Aug 13, 2017 at 5:11 PM, Gary Gregory 
> > wrote:
> >
> >> Is there a Maven way to add ALL-SYSTEM to everything? Using plugin
> >> specific
> >> tags like below is going to be painful.
> >>
> >> Gary
> >>
> >> On Aug 13, 2017 07:30, "Tibor Digana"  wrote:
> >>
> >> > Hi @Enrico,
> >> >
> >> > I am very unhappy with Java 9 status and very afraid.
> >> > I do not like the style how Oracle has changed Java to Java 9 and
> forced
> >> > all the world to use additional effort to adapt to Oracle activities.
> >> >
> >> > I am facing more unhappy Java development teams with Java 9 in the
> >> future.
> >> > For instance as I have tried to implement users wish in Maven Surefire
> >> > project and invested my personal time and effort to adapt to Oracle
> >> > requirements, this still does not convince me to say that Java 9 is
> >> ready
> >> > to go.
> >> >
> >> > This is my comment from Jira:
> >> >
> >> > "This is not nice on Java 9 that they broke backwards compatibility
> and
> >> > force the world to use the switch to use --add-modules ALL-SYSTEM
> >> instead
> >> > of providing all modules installed in JRE. For instance, small JRE
> >> having
> >> > {{java.base}} has advantage on embedded systems and the only should be
> >> > propagated. Big scope JRE should propagate all installed modules.
> >> > But for me it does not make security sense and common sense to force
> >> JRE to
> >> > provide modules. It should be opposite and the admin/Jenkins should
> >> > configure big scope JRE with selected modules propagated to Java
> runtime
> >> > applications.
> >> > If this admin does not do that then all modules should be available by
> >> > default which is backwards compatibility for me and we do not have to
> to
> >> > implement these stupid tricks."
> >> >
> >> > As far as we remember Java Security, the policies can be configured.
> >> > I can imaging same paradigm in Jigsaw/Java 9 and then the admin who
> has
> >> > installed JDK or JRE would "switch off" some modules. But opposite,
> that
> >> > means the script which starts Java app currently enables "all" modules
> >> is
> >> > against security and against the principle of modular system because
> 

Re: No helping on the 3.5.0 release checklist...

[Fred Cooke]

Yes, agreed, 30 is a lot, but if you have N artifacts in a dir running
sha1sum dir/* and pasting the result raw into the email is not difficult.
Less so than formatting the two, probably.

On 8 April 2017 at 09:13, Stephen Connolly <stephen.alan.conno...@gmail.com>
wrote:

> On 7 April 2017 at 22:10, Fred Cooke <fred.co...@gmail.com> wrote:
>
> > Thanks for all of your hard work on this, much appreciated!
> >
> > A little feedback for 3.5.1 (not helping with 3.5.0): checksums for the
> > binaries too, not just the source.
> >
> >
> checksums are in the staging repo and on the dowload site too. legally we
> only vote on the source distribution. we can look into providing the
> checksums as a convenience but 30 steps is too much for a release... I want
> to strip that way way down
>
>
> > That's it. :-)
> >
> > On 8 April 2017 at 09:05, Stephen Connolly <stephen.alan.connolly@gmail.
> > com>
> > wrote:
> >
> > > 24. Publish the website with https://cms.apache.org/maven/publish
> > > 25. Send the announcement email
> > > 26. (PMC only) Record the release on
> > > https://reporter.apache.org/addrelease.html?maven
> > > 27. Tweet the release
> > >
> > > TODO:
> > > 28. Wait for the announcement email to show up on the
> > > https://mail-archives.apache.org/mod_mbox/maven-announce/ archives
> > > 29. Update the site history with the announce email
> > > 30. Publish the site again
> > > 31. Celebrate!!!
> > >
> > > On 7 April 2017 at 09:59, Stephen Connolly
> <stephen.alan.connolly@gmail.
> > > com>
> > > wrote:
> > >
> > > > 23. Mark the version in JIRA as released
> > > >
> > > > On 7 April 2017 at 09:40, Stephen Connolly
> > <stephen.alan.connolly@gmail.
> > > > com> wrote:
> > > >
> > > >> 14. Close the vote
> > > >> 15. Commit the finalized release notes
> > > >> 16. Commit the updated doap
> > > >> 17. Add the release to the dist
> > > >>
> > > >> $ cd ~/tmp
> > > >> $ svn co https://dist.apache.org/repos/dist/dev/maven/maven-3
> > > maven-dist
> > > >> $ cd maven-dist
> > > >> $ mkdir -p 3.5.0/{binaries,source}
> > > >> $ for ext in tar.gz zip ; do ( cd 3.5.0/binaries/ ; for hash in ""
> > .asc
> > > >> .md5 .sha1 ; do curl -O https://repository.apache.org/
> > > >> content/repositories/maven-1326/org/apache/maven/apache-mave
> > > >> n/3.5.0/apache-maven-3.5.0-bin.$ext$hash ; done ) done
> > > >> $ for ext in tar.gz zip ; do ( cd 3.5.0/source/ ; for hash in ""
> .asc
> > > >> .md5 .sha1 ; do curl -O https://repository.apache.org/
> > > >> content/repositories/maven-1326/org/apache/maven/apache-mave
> > > >> n/3.5.0/apache-maven-3.5.0-src.$ext$hash ; done ) done
> > > >> $ svn add 3.5.0
> > > >> $ svn ci -m "Staging the binaries for the release"
> > > >>
> > > >> 18. Release the staging repo in nexus
> > > >> 19. Release the binaries
> > > >>
> > > >> $ svn mv https://dist.apache.org/repos/dist/dev/maven/maven-3/3.5.0
> > > >> https://dist.apache.org/repos/dist/release/maven/maven-3 -m
> "Release
> > > >> 3.5.0"
> > > >>
> > > >> 20. Deploy the current reference
> > > >>
> > > >> $ svn cp https://svn.apache.org/repos/infra/websites/production/
> maven
> > > >> /components/ref/3-LATEST https://svn.apache.org/repos/i
> > > >> nfra/websites/production/maven/components/ref/3.5.0 -m "Deploy the
> > > 3.5.0
> > > >> reference documentation"
> > > >>
> > > >> 21. Draft the Announcement email
> > > >>
> > > >> 22. Wait for the binaries to sync to the mirrors (check
> > > >> https://www.apache.org/mirrors/ look at the mean / median mirror
> age,
> > > >> wait that long)
> > > >>
> > > >> On 4 April 2017 at 07:40, Stephen Connolly
> > > <stephen.alan.connolly@gmail.c
> > > >> om> wrote:
> > > >>
> > > >>> 12. Run the integration tests: (in debian as that matches the ci
> > > server)
> > > >>>
> > > >>> $ ID=$(docker build environments/debian-jdk7) &&
> > > >

Re: No helping on the 3.5.0 release checklist...

[Fred Cooke]

Thanks for all of your hard work on this, much appreciated!

A little feedback for 3.5.1 (not helping with 3.5.0): checksums for the
binaries too, not just the source.

That's it. :-)

On 8 April 2017 at 09:05, Stephen Connolly 
wrote:

> 24. Publish the website with https://cms.apache.org/maven/publish
> 25. Send the announcement email
> 26. (PMC only) Record the release on
> https://reporter.apache.org/addrelease.html?maven
> 27. Tweet the release
>
> TODO:
> 28. Wait for the announcement email to show up on the
> https://mail-archives.apache.org/mod_mbox/maven-announce/ archives
> 29. Update the site history with the announce email
> 30. Publish the site again
> 31. Celebrate!!!
>
> On 7 April 2017 at 09:59, Stephen Connolly  com>
> wrote:
>
> > 23. Mark the version in JIRA as released
> >
> > On 7 April 2017 at 09:40, Stephen Connolly  > com> wrote:
> >
> >> 14. Close the vote
> >> 15. Commit the finalized release notes
> >> 16. Commit the updated doap
> >> 17. Add the release to the dist
> >>
> >> $ cd ~/tmp
> >> $ svn co https://dist.apache.org/repos/dist/dev/maven/maven-3
> maven-dist
> >> $ cd maven-dist
> >> $ mkdir -p 3.5.0/{binaries,source}
> >> $ for ext in tar.gz zip ; do ( cd 3.5.0/binaries/ ; for hash in "" .asc
> >> .md5 .sha1 ; do curl -O https://repository.apache.org/
> >> content/repositories/maven-1326/org/apache/maven/apache-mave
> >> n/3.5.0/apache-maven-3.5.0-bin.$ext$hash ; done ) done
> >> $ for ext in tar.gz zip ; do ( cd 3.5.0/source/ ; for hash in "" .asc
> >> .md5 .sha1 ; do curl -O https://repository.apache.org/
> >> content/repositories/maven-1326/org/apache/maven/apache-mave
> >> n/3.5.0/apache-maven-3.5.0-src.$ext$hash ; done ) done
> >> $ svn add 3.5.0
> >> $ svn ci -m "Staging the binaries for the release"
> >>
> >> 18. Release the staging repo in nexus
> >> 19. Release the binaries
> >>
> >> $ svn mv https://dist.apache.org/repos/dist/dev/maven/maven-3/3.5.0
> >> https://dist.apache.org/repos/dist/release/maven/maven-3 -m "Release
> >> 3.5.0"
> >>
> >> 20. Deploy the current reference
> >>
> >> $ svn cp https://svn.apache.org/repos/infra/websites/production/maven
> >> /components/ref/3-LATEST https://svn.apache.org/repos/i
> >> nfra/websites/production/maven/components/ref/3.5.0 -m "Deploy the
> 3.5.0
> >> reference documentation"
> >>
> >> 21. Draft the Announcement email
> >>
> >> 22. Wait for the binaries to sync to the mirrors (check
> >> https://www.apache.org/mirrors/ look at the mean / median mirror age,
> >> wait that long)
> >>
> >> On 4 April 2017 at 07:40, Stephen Connolly
>  >> om> wrote:
> >>
> >>> 12. Run the integration tests: (in debian as that matches the ci
> server)
> >>>
> >>> $ ID=$(docker build environments/debian-jdk7) &&
> >>> docker run -it --rm -v $(pwd):/root/maven-integration-testing -v
> >>> $(pwd)/../maven:/root/maven $ID bash
> >>> $ cd /root
> >>> $ mvn clean install -Prun-its -Dmaven.repo.local=$HOME/tmp/repo
> >>> -DmavenDistro=../maven/target/checkout/apache-maven/target/a
> >>> pache-maven-3.5.0-bin.zip
> >>>
> >>> 13. Publish the integration tests site: (by bind mounting the test run
> >>> we can publish the results from inside docker outside of docker)
> >>>
> >>> $ mvn -Preporting site site:stage && mvn scm-publish:publish-scm
> >>>
> >>> On 3 April 2017 at 23:36, Stephen Connolly <
> >>> stephen.alan.conno...@gmail.com> wrote:
> >>>
>  11. Run the source release analyzer (https://github.com/stephenc/s
>  ource-release-validator/commit/2e91ac959d0320a509e023b11b6389
> cc05719cdb)
>  and reply to the vote with the results.
> 
>  On 3 April 2017 at 23:18, Stephen Connolly <
>  stephen.alan.conno...@gmail.com> wrote:
> 
> > Note to self, here's all the steps so far
> >
> > 1. $ export JAVA_HOME=jdk7
> > 2. $ export PATH=${JAVA_HOME}/bin:${PATH}
> > 3. $ mvn release:prepare release:perform
> > 4. $ cd target/checkout
> > 5. $ export MAVEN_OPTS=-Xmx1024m -XX:MaxPermSize=512m
> > 6. Close staging repo
> > 7. $ mvn -Preporting site site:stage
> > 8. $ mvn scm-publish:publish-scm
> > 9. Send vote email
> > 10. Start preparing the release notes
> >
> 
> 
> >>>
> >>
> >
>

Re: [VOTE] Release Apache Maven 3.5.0

[Fred Cooke]

+1 non binding, built my main app without drama, and the rest of my
personal projects are simpler

On 5 April 2017 at 09:37, Tibor Digana  wrote:

> +1 (binding)
>
> On Tue, Apr 4, 2017 at 12:14 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Hi,
> >
> > We solved 86 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > projectId=12316922=12336084=Text
> >
> > In there are 324 issues left in JIRA for Maven core:
> > https://issues.apache.org/jira/issues/?jql=project%20%
> > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1326
> >
> > The distributable binaries and sources for testing can be found here:
> > https://repository.apache.org/content/repositories/maven-
> > 1326/org/apache/maven/apache-maven/3.5.0/
> >
> > Specifically the zip, tarball, and source archives can be found here:
> > https://repository.apache.org/content/repositories/maven-
> > 1326/org/apache/maven/apache-maven/3.5.0/apache-maven-3.5.0-bin.zip
> > https://repository.apache.org/content/repositories/maven-
> > 1326/org/apache/maven/apache-maven/3.5.0/apache-maven-3.5.0-bin.tar.gz
> > https://repository.apache.org/content/repositories/maven-
> > 1326/org/apache/maven/apache-maven/3.5.0/apache-maven-3.5.0-src.zip
> > https://repository.apache.org/content/repositories/maven-
> > 1326/org/apache/maven/apache-maven/3.5.0/apache-maven-3.5.0-src.tar.gz
> >
> > Source release checksum(s):
> > apache-maven-3.5.0-src.tar.gz sha1: 1730812af1cdd77493e269b371ef8a
> > c536230c15
> > apache-maven-3.5.0-src.zip sha1: 40b18ca1d4e14a04a5b872c822f37f
> 6578a17cb9
> >
> > Git tag:
> > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> > ff8f5e7444045639af65f6095c62210b5713f426
> >
> > Staging site:
> > https://maven.apache.org/components/ref/3-LATEST/
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> > Thanks,
> > -Stephen
> >
>

Re: [DISCUSS] How to work with branches

[Fred Cooke]

Because unless the unit test suite has 100% line and branch coverage, and
possibly various
other metrics, all of which are unfeasible for any real-world sized code
base, it could miss
something. The first line should/must (if you care) be manual integration
of the two change
sets, conflicting, or not. That's why! :-p

What you're suggesting is a good thing, however what you said was false or
at best misleading.

Part of the issue I see is that people keep rebasing so that they can be
sure their changes will merge without conflict.

I don't see that as an issue, I see that as due diligence and a wise thing
to do in a dynamic code base.



On 20 March 2017 at 20:15, Stephen Connolly <stephen.alan.conno...@gmail.com
> wrote:

> On Mon 20 Mar 2017 at 00:44, Fred Cooke <fred.co...@gmail.com> wrote:
>
> > Sounds like the solution is for people to use a different remote that you
> > don't feel personally responsible for checking every commit in. And to
> fix
> > the email system.
> >
> > Split emails for commits on master to everyone and a new list for other
> > branches.
> >
> > As for Jenkins validating a merge, that's rubbish. A merge, or a rebase,
> is
> > a human operation, even when the tool can do it "cleanly"/automatically.
> To
> > ignore this is to introduce subtle issues and breakages.
> >
>
> How is Jenkins checking that the branch merges cleanly rubbish?
>
> GitHub does that all the time for PRs
>
> Part of the issue I see is that people keep rebasing so that they can be
> sure their changes will merge without conflict.
>
> If Jenkins has tested that the changes will merge without conflict, no need
> to rebase and push the rebase just to get the test status updated...
> because it is updated.
>
> We cannot have Jenkins *push* the merge anywhere it would just be
> verifying that the merge is without conflict and "trivial"... and running
> the tests on the result
>
> >
> > On 20 March 2017 at 10:20, Stephen Connolly <
> > stephen.alan.conno...@gmail.com
> > > wrote:
> >
> > > On Sun 19 Mar 2017 at 20:05, Fred Cooke <fred.co...@gmail.com> wrote:
> > >
> > > > How are branches noisy? Promiscuous automated emails or some such?
> > >
> > >
> > > PMC (and committers too, but the buck stops at the PMC) are supposed to
> > > monitor the commits@m.a.o mailing list.
> > >
> > > Every time a branch is rebased... boom all the commits are emailed
> > *again*
> > >
> > >
> > > >
> > > > Surely you don't need to look at all branches unless you've been
> asked
> > to
> > > > pre-review something prior to fast-forward? Just the ones you're
> > > interested
> > > > in?
> > >
> > >
> > > Need to check for Apache license issues and other ill-defined criteria
> > >
> > >
> > > >
> > > > Naming scheme sounds sensible, however unless everyone is constantly
> > > > rebasing (or making a mess with merge) there's a solid chance they
> > won't
> > > > merge cleanly (which is a human operation).
> > >
> > >
> > > This is why Jenkins will validate the merge cleanly so that the human
> has
> > > an easy merge
> > >
> > >
> > > >
> > > > Also, unless you're talking about maven itself with multiple
> supported
> > > > versions, there should be exactly one target branch for most stuff,
> so
> > > I'd
> > > > say reorder your pattern to reduce base-level "noise", eg
> > > > target/owner/ticket-purpose
> > >
> > >
> > > Perhaps, though then a lot of branches will start with "master/"
> > >
> > > Otoh it does make it easier to find all targeting master...
> > >
> > >
> > > > On 20 March 2017 at 06:34, Stephen Connolly <
> > > > stephen.alan.conno...@gmail.com
> > > > > wrote:
> > > >
> > > > > Unlike the other discuss threads, I think I have some extra context
> > > that
> > > > > means I am going to start from my proposal... or rather my
> > requirements
> > > > and
> > > > > then proposal to solve those requirements.
> > > > >
> > > > > Requirements
> > > > > ===
> > > > >
> > > > > As a Release Manager,
> > > > >
> > > > > I cannot tell which branches on the CI server are targeted for the
> > > > 

Re: [DISCUSS] How to work with branches

[Fred Cooke]

Sounds like the solution is for people to use a different remote that you
don't feel personally responsible for checking every commit in. And to fix
the email system.

Split emails for commits on master to everyone and a new list for other
branches.

As for Jenkins validating a merge, that's rubbish. A merge, or a rebase, is
a human operation, even when the tool can do it "cleanly"/automatically. To
ignore this is to introduce subtle issues and breakages.

On 20 March 2017 at 10:20, Stephen Connolly <stephen.alan.conno...@gmail.com
> wrote:

> On Sun 19 Mar 2017 at 20:05, Fred Cooke <fred.co...@gmail.com> wrote:
>
> > How are branches noisy? Promiscuous automated emails or some such?
>
>
> PMC (and committers too, but the buck stops at the PMC) are supposed to
> monitor the commits@m.a.o mailing list.
>
> Every time a branch is rebased... boom all the commits are emailed *again*
>
>
> >
> > Surely you don't need to look at all branches unless you've been asked to
> > pre-review something prior to fast-forward? Just the ones you're
> interested
> > in?
>
>
> Need to check for Apache license issues and other ill-defined criteria
>
>
> >
> > Naming scheme sounds sensible, however unless everyone is constantly
> > rebasing (or making a mess with merge) there's a solid chance they won't
> > merge cleanly (which is a human operation).
>
>
> This is why Jenkins will validate the merge cleanly so that the human has
> an easy merge
>
>
> >
> > Also, unless you're talking about maven itself with multiple supported
> > versions, there should be exactly one target branch for most stuff, so
> I'd
> > say reorder your pattern to reduce base-level "noise", eg
> > target/owner/ticket-purpose
>
>
> Perhaps, though then a lot of branches will start with "master/"
>
> Otoh it does make it easier to find all targeting master...
>
>
> > On 20 March 2017 at 06:34, Stephen Connolly <
> > stephen.alan.conno...@gmail.com
> > > wrote:
> >
> > > Unlike the other discuss threads, I think I have some extra context
> that
> > > means I am going to start from my proposal... or rather my requirements
> > and
> > > then proposal to solve those requirements.
> > >
> > > Requirements
> > > ===
> > >
> > > As a Release Manager,
> > >
> > > I cannot tell which branches on the CI server are targeted for the
> > release
> > > and which are "future work"
> > >
> > > I cannot tell who is responsible for which branches in order to know
> who
> > to
> > > ask w.r.t. their status
> > >
> > > As a PMC member tasked with reviewing commits
> > >
> > > I cannot keep track of all the many commits and rebases
> > >
> > > Proposal
> > > 
> > >
> > > 1. We should use a naming scheme for all branches. I am suggesting
> > > owner/targetBranch/mng- - this gives me the information about who
> > owns
> > > the branch and where the branch is targeted for.
> > >
> > > 2. We should have the Jenkinsfile build not just the head commit but
> the
> > > head commit merged to the target branch for any branch following the
> > naming
> > > scheme. We get the target branch from the naming scheme and by having
> the
> > > build verify that the branch can be merged without conflict onto the
> > target
> > > branch we remove the need for constant rebases
> > >
> > > 3. We merge branches with an explicit merge commit and stop using
> > > fast-forward merging only. Again this makes it easier to review and
> > allows
> > > the noisy branches to be quiet when looked at from the PoV of master
> > >
> > > This will not solve all the issues, but it would solve the pain points
> I
> > > have currently.
> > >
> > > Now if others have a different PoV or a counter-proposal, please speak
> > up!
> > >
> >
> --
> Sent from my phone
>

Re: [DISCUSS] How to work with branches

[Fred Cooke]

No need to cherry-pick, that should be a rare operation.

Clean up the branch and prepare it for a fast forward with high quality
commits, then just push it when it's ready and passes scrutiny and tests.

+1 on ugly masters. Last time I looked at the docker project the displayed
history showed 15 or so merge commits and NO content commits. Useless.

On 20 March 2017 at 11:46, Hervé BOUTEMY  wrote:

> until now, target version was managed through Jira issue: I'm not convinced
> putting the info in an additional place like branch name will help keep
> info
> in sync
>
> For the merge idea, the "target branch" concept seems too much for me: if
> the
> branch was automatically locally rebased on master, this would be simpler
> and
> sufficient IMHO
>
> And I completely dislike merge commits and remaining branches in master:
> commits should be cherry picked and merge commit totally avoided IMHO.
> Merge commits (and complex history retained from this practice) is a big
> pain
> point to me to have a clear master history
>
> Regards,
>
> Hervé
>
> Le dimanche 19 mars 2017, 17:34:21 CET Stephen Connolly a écrit :
> > Unlike the other discuss threads, I think I have some extra context that
> > means I am going to start from my proposal... or rather my requirements
> and
> > then proposal to solve those requirements.
> >
> > Requirements
> > ===
> >
> > As a Release Manager,
> >
> > I cannot tell which branches on the CI server are targeted for the
> release
> > and which are "future work"
> >
> > I cannot tell who is responsible for which branches in order to know who
> to
> > ask w.r.t. their status
> >
> > As a PMC member tasked with reviewing commits
> >
> > I cannot keep track of all the many commits and rebases
> >
> > Proposal
> > 
> >
> > 1. We should use a naming scheme for all branches. I am suggesting
> > owner/targetBranch/mng- - this gives me the information about who
> owns
> > the branch and where the branch is targeted for.
> >
> > 2. We should have the Jenkinsfile build not just the head commit but the
> > head commit merged to the target branch for any branch following the
> naming
> > scheme. We get the target branch from the naming scheme and by having the
> > build verify that the branch can be merged without conflict onto the
> target
> > branch we remove the need for constant rebases
> >
> > 3. We merge branches with an explicit merge commit and stop using
> > fast-forward merging only. Again this makes it easier to review and
> allows
> > the noisy branches to be quiet when looked at from the PoV of master
> >
> > This will not solve all the issues, but it would solve the pain points I
> > have currently.
> >
> > Now if others have a different PoV or a counter-proposal, please speak
> up!
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] How to work with branches

[Fred Cooke]

How are branches noisy? Promiscuous automated emails or some such?

Surely you don't need to look at all branches unless you've been asked to
pre-review something prior to fast-forward? Just the ones you're interested
in?

Naming scheme sounds sensible, however unless everyone is constantly
rebasing (or making a mess with merge) there's a solid chance they won't
merge cleanly (which is a human operation).

Also, unless you're talking about maven itself with multiple supported
versions, there should be exactly one target branch for most stuff, so I'd
say reorder your pattern to reduce base-level "noise", eg
target/owner/ticket-purpose

On 20 March 2017 at 06:34, Stephen Connolly  wrote:

> Unlike the other discuss threads, I think I have some extra context that
> means I am going to start from my proposal... or rather my requirements and
> then proposal to solve those requirements.
>
> Requirements
> ===
>
> As a Release Manager,
>
> I cannot tell which branches on the CI server are targeted for the release
> and which are "future work"
>
> I cannot tell who is responsible for which branches in order to know who to
> ask w.r.t. their status
>
> As a PMC member tasked with reviewing commits
>
> I cannot keep track of all the many commits and rebases
>
> Proposal
> 
>
> 1. We should use a naming scheme for all branches. I am suggesting
> owner/targetBranch/mng- - this gives me the information about who owns
> the branch and where the branch is targeted for.
>
> 2. We should have the Jenkinsfile build not just the head commit but the
> head commit merged to the target branch for any branch following the naming
> scheme. We get the target branch from the naming scheme and by having the
> build verify that the branch can be merged without conflict onto the target
> branch we remove the need for constant rebases
>
> 3. We merge branches with an explicit merge commit and stop using
> fast-forward merging only. Again this makes it easier to review and allows
> the noisy branches to be quiet when looked at from the PoV of master
>
> This will not solve all the issues, but it would solve the pain points I
> have currently.
>
> Now if others have a different PoV or a counter-proposal, please speak up!
>

Re: [VOTE] Revert Surefire and commit to branches

[Fred Cooke]

Git revert hash produces an inverse commit to hash. If from the 11 only one
is bad, revert is your friend. If you want to get back to the same state,
my options previously are required, not a single revert operation with just
a hash supplied. man git revert && man git reset # :-)

On Wed, Jan 18, 2017 at 6:35 PM, Tibor Digana <tibor.dig...@googlemail.com>
wrote:

> For me it is useful to still see the history because we want to be
> motivated and open branches which fix the reverted commits.
> There are only 11 commits to revert. Few days ago, unlike in Maven.
> So pure git revert  is fine.
>
> On Wed, Jan 18, 2017 at 6:01 AM, Fred Cooke <fred.co...@gmail.com> wrote:
>
> > By revert do you mean reset --hard or keep the full history and rest the
> > contents then re commit and verify with a diff to that hash?
> >
> > Or did you mean revert, each commit, in reverse order, back to that base?
> >
> >
> >
> > On Wed, Jan 18, 2017 at 5:43 PM, Tibor Digana <tibordig...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > We have messed up Surefire codeline and we want to revert to [1] where
> CI
> > > was stable.
> > > This enables us to continue with development.
> > >
> > > [1] 66bc4c0839ba11af7a8915930f76abf3cd58ee53
> > >
> > > Vote open for at least 72 hours.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> >
>
>
>
> --
> Cheers
> Tibor
>

Re: [VOTE] Revert Surefire and commit to branches

[Fred Cooke]

By revert do you mean reset --hard or keep the full history and rest the
contents then re commit and verify with a diff to that hash?

Or did you mean revert, each commit, in reverse order, back to that base?



On Wed, Jan 18, 2017 at 5:43 PM, Tibor Digana 
wrote:

> Hi,
>
> We have messed up Surefire codeline and we want to revert to [1] where CI
> was stable.
> This enables us to continue with development.
>
> [1] 66bc4c0839ba11af7a8915930f76abf3cd58ee53
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: [2/2] maven git commit: Merge branch 'MNG-5629'

[Fred Cooke]

My preference matches yours for the exact same reason. You're trying to
rebase or merge something you don't understand, otherwise. Blind. 10/10 :-)

On Mon, Jan 16, 2017 at 10:21 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> or if you want less commands
>
> git checkout BRANCH
> git pull --rebase origin master
> git push origin BRANCH:master
> git push origin :BRANCH
>
> but personally I prefer to separate the fetch from the rebase as you have
> at least more of a feeling of control (e.g. you can check the git log
> origin/master locally first before doing the rebase
>
> On 16 January 2017 at 09:11, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > I do not thing we want an overly heavy process.
> >
> > For the 3.5.0 release I suggest we try the following. Rebase so that it
> is
> > a fast-forward merge
> >
> > git checkout BRANCH
> > git fetch origin
> > git rebase origin/master
> > git push origin BRANCH:master
> >
> > if that git push fails,
> >
> > fetch
> > rebase
> > push
> >
> > once your push has succeeded
> >
> > git push origin :BRANCH
> >
> >
> > On 16 January 2017 at 08:51, Christian Schulte <c...@schulte.it> wrote:
> >
> >> Am 16.01.2017 um 09:00 schrieb Fred Cooke:
> >> > No, not correct in my books.
> >> >
> >> > git checkout BRANCH # Assuming it's local already
> >> > git fetch upstream # risk free, unlike pull!
> >> > git rebase upstream/master # diff difftool merge mergetool settings
> are
> >> > useful, prompt = false and specify your diff tool in advance
> >> > git push --force upstream BRANCH # After verifying no one has pushed
> to
> >> it
> >> > # create pull request/email someone/communicate your intention to have
> >> it
> >> > merged
> >> >
> >> > ^ correct in my books, others may differ.
> >>
> >> I merged pull requests from others in the past as well. Create pull
> >> requests for master even if I am a committer? Really? That would mean I
> >> would create a pull request I will pull in myself afterwards? Leave the
> >> merge commit so that the merges can be tracked back to the PR?
> >>
> >> Regards,
> >> --
> >> Christian
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
> >
>

Re: [2/2] maven git commit: Merge branch 'MNG-5629'

[Fred Cooke]

Perfect, if reviews aren't part of the deal. <3

On Mon, Jan 16, 2017 at 10:11 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> I do not thing we want an overly heavy process.
>
> For the 3.5.0 release I suggest we try the following. Rebase so that it is
> a fast-forward merge
>
> git checkout BRANCH
> git fetch origin
> git rebase origin/master
> git push origin BRANCH:master
>
> if that git push fails,
>
> fetch
> rebase
> push
>
> once your push has succeeded
>
> git push origin :BRANCH
>
>
> On 16 January 2017 at 08:51, Christian Schulte <c...@schulte.it> wrote:
>
> > Am 16.01.2017 um 09:00 schrieb Fred Cooke:
> > > No, not correct in my books.
> > >
> > > git checkout BRANCH # Assuming it's local already
> > > git fetch upstream # risk free, unlike pull!
> > > git rebase upstream/master # diff difftool merge mergetool settings are
> > > useful, prompt = false and specify your diff tool in advance
> > > git push --force upstream BRANCH # After verifying no one has pushed to
> > it
> > > # create pull request/email someone/communicate your intention to have
> it
> > > merged
> > >
> > > ^ correct in my books, others may differ.
> >
> > I merged pull requests from others in the past as well. Create pull
> > requests for master even if I am a committer? Really? That would mean I
> > would create a pull request I will pull in myself afterwards? Leave the
> > merge commit so that the merges can be tracked back to the PR?
> >
> > Regards,
> > --
> > Christian
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [2/2] maven git commit: Merge branch 'MNG-5629'

[Fred Cooke]

Squashing is for commits that were not done properly in the first place,
either by choice WIP style, or by incompetence. I'd be heart broken if you
squashed my carefully crafted atomic and standalone commits. :-p

With-lease is new to me, but it's what I manually do anyway. If I see the
from hash is not what I thought, then I back it out again. Though that's
yet to happen, so I'll save the key strokes and use my alias "git force".

On Mon, Jan 16, 2017 at 9:51 PM, Christian Schulte <c...@schulte.it> wrote:

> Am 16.01.2017 um 09:00 schrieb Fred Cooke:
> > No, not correct in my books.
> >
> > git checkout BRANCH # Assuming it's local already
> > git fetch upstream # risk free, unlike pull!
> > git rebase upstream/master # diff difftool merge mergetool settings are
> > useful, prompt = false and specify your diff tool in advance
> > git push --force upstream BRANCH # After verifying no one has pushed to
> it
> > # create pull request/email someone/communicate your intention to have it
> > merged
> >
> > ^ correct in my books, others may differ.
>
> I merged pull requests from others in the past as well. Create pull
> requests for master even if I am a committer? Really? That would mean I
> would create a pull request I will pull in myself afterwards? Leave the
> merge commit so that the merges can be tracked back to the PR?
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [2/2] maven git commit: Merge branch 'MNG-5629'

[Fred Cooke]

No, not correct in my books.

git checkout BRANCH # Assuming it's local already
git fetch upstream # risk free, unlike pull!
git rebase upstream/master # diff difftool merge mergetool settings are
useful, prompt = false and specify your diff tool in advance
git push --force upstream BRANCH # After verifying no one has pushed to it
# create pull request/email someone/communicate your intention to have it
merged

^ correct in my books, others may differ.


On Mon, Jan 16, 2017 at 8:52 PM, Christian Schulte <c...@schulte.it> wrote:

> Am 16.01.2017 um 08:27 schrieb Fred Cooke:
> > Rebase is the only clean way forward for small projects in which people
> > step on each others toes.
> >
> > Merge commits are difficult to comprehend for some developers, leading to
> > errors. Avoiding them is beneficial.
> >
> > On Mon, Jan 16, 2017 at 8:23 PM, Hervé BOUTEMY <herve.bout...@free.fr>
> > wrote:
> >
> >> do we want to keep such merge commits?
>
> Just to clarify. I should have done the following:
>
> cmd> git checkout master
> cmd> git merge BRANCH
> cmd> git rebase (possible -i to do some housekeeping)
> cmd> git push
>
> Correct? I did this but then decided to keep that merge commit so that
> it's obvious that there had been a branch carrying the commit(s).
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [2/2] maven git commit: Merge branch 'MNG-5629'

[Fred Cooke]

Rebase is the only clean way forward for small projects in which people
step on each others toes.

Merge commits are difficult to comprehend for some developers, leading to
errors. Avoiding them is beneficial.

On Mon, Jan 16, 2017 at 8:23 PM, Hervé BOUTEMY 
wrote:

> do we want to keep such merge commits?
>
> I would have expected that when merging, we rebase then have no such merge
> commit: that branch work is just a temporary situation that completely
> disappears once merged (and we must not forget to delete merged branch)
>
> what do others think?
>
> Regards,
>
> Hervé
>
> Le lundi 16 janvier 2017, 02:17:26 CET schu...@apache.org a écrit :
> > Merge branch 'MNG-5629'
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/c6c5192d
> > Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/c6c5192d
> > Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/c6c5192d
> >
> > Branch: refs/heads/master
> > Commit: c6c5192d4bcb50c1aab6fade53dfb9c2f3d9b7e7
> > Parents: a83296d ca1179c
> > Author: Christian Schulte 
> > Authored: Mon Jan 16 03:16:49 2017 +0100
> > Committer: Christian Schulte 
> > Committed: Mon Jan 16 03:16:49 2017 +0100
> >
> > --
> >  .../legacy/DefaultUpdateCheckManager.java   | 61
> 
> >  1 file changed, 24 insertions(+), 37 deletions(-)
> > --
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

[Fred Cooke]

Christian, some (potentially unwelcome) advice: Learn to use rebase, learn
to fetch, never pull, and review your changes in their new context before
pushing them.

Whether you take the advice, or not, this is how I ensure that my changes
are clean and focused and coherent, every time.

Pull is a blind operation, which basically says "get whatever is out there,
even though I have no idea what it is, and try to merge my changes with
those changes, regardless, and before reviewing what those changes are".

If you fetch first you can at least look and make a conscious decision. Not
possible if you pull.

This style fits with the Apache "just commit it" mentality, but relies on
individual developer discipline to work well. The task of "gate keeper" is
effectively distributed to each person wanting to push; they gate keep
themselves, or not.

Fred.


On Sun, Jan 8, 2017 at 1:27 PM, Tibor Digana 
wrote:

> You committed right after me and you have reverted two Jira issue.
> I do not want to continue until we make agreement.
> If you want to see thrown IOException, then we can use InputStream.close()
> instead of IOUtils.close().
> Please nobody commit until we know what we clarify.
> Except for PrintWriter there is again all old staff back like missed
> flush(), etc.
> Btw. PrintWriter has a method which could be called and throw exception
> from our code
>
> public boolean checkError() {
> if (out != null) {
> flush();
> }
> if (out instanceof java.io.PrintWriter) {
> PrintWriter pw = (PrintWriter) out;
> return pw.checkError();
> } else if (psOut != null) {
> return psOut.checkError();
> }
> return trouble;
> }
>
>
>
>
> On Sun, Jan 8, 2017 at 12:47 AM, Christian Schulte 
> wrote:
>
> > Am 01/07/17 um 04:00 schrieb Tibor Digana:
> > > I have created a pull request
> > > https://github.com/apache/maven-surefire/pull/139
> > > The build passed successfully.
> > > Christian, Benedikt please have a look and I will amend the HEAD
> revision
> > > in origin/master.
> > > Thx.
> >
> > Damn it. I did not read your emails. Could be I just made that?  I "git
> > pull"ed and that produced conflicts. I solved those conflicts and then
> > pushed. Your changes are preserved, of course.
> >
> > I changed usages of "PrintWriter" to a "real" writer where possible
> > (only used privately) because the PrintWriter does not throw any
> > IOException and all "checkError" calls where missing.
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
>
> --
> Cheers
> Tibor
>

Re: Would Commons Lang on Java 8 be a problem for the Apache Maven project?

[Fred Cooke]

Commons lang could commit to providing patch releases/bug fixes in a
maintenance series of the existing line
for that purpose. Then it'd be totally fine to do whatever they liked in
the new version with major incremented.

On Mon, Sep 26, 2016 at 3:20 AM, Robert Scholte 
wrote:

> On Sun, 25 Sep 2016 16:11:22 +0200, Benedikt Ritter 
> wrote:
>
> Hello Robert,
>>
>> just watched your JavaOne presentation. Very interesting :-)
>>
>
> thanks!
>
>
>> Robert Scholte  schrieb am So., 25. Sep. 2016 um
>> 13:48 Uhr:
>>
>> It depends. If you are changing existing methods to only work with Java8,
>>> that would be a problem (read: we cannot upgrade). If you have both Java8
>>> and pre-Java8 implementations, either by reflection or proper
>>> encapsulated
>>> code it'll work for us.
>>> We do it ourselves too[1]
>>>
>>> for us it would be nice if the target is still 1.7
>>>
>>> if ( isJava8() )
>>> { // do java8 stuff }
>>> else
>>> { do classic stuff } )
>>>
>>> if the java8 stuff uses reflection, you can build it with JDK7, otherwise
>>> you must use JDK8
>>>
>>>
>> We're thinking about adding APIs for dealing with e.g. Functions. So
>> maven.compiler.source and maven.compiler.target would be 1.8. This would
>> require downstream user to also compile with Java 8. If I understand
>> correctly, this would be a problem for Maven, right?
>>
>
> As long as we say that users can run Maven with Java7, then yes it would
> block us from upgrading. Is that a problem? Maybe, as long as we don't hit
> a bug commons-lang.
>
> Robert
>
>
>
>> Regards,
>> Benedikt
>>
>>
>>
>>> Robert
>>>
>>> [1]
>>>
>>> https://maven.apache.org/shared/maven-shared-utils/xref/org/
>>> apache/maven/shared/utils/io/FileUtils.html#L831
>>>
>>> On Sun, 25 Sep 2016 09:48:56 +0200, Benedikt Ritter 
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > at the Apache Commons Project we're currently discussing where we can
>>> > host
>>> > utility classes for working with the features introduced in Java 8. One
>>> > proposal add this to Commons Lang [1]. Since Apache Maven makes use of
>>> > Commons Lang, I would like to know whether it would be a problem for
>>> you
>>> > if
>>> > Commons Lang would require Java 8.
>>> >
>>> > Thank you,
>>> > Benedikt
>>> >
>>> > [1] http://markmail.org/message/ecxc4brpxufamuzu
>>>
>>> -
>>> 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: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Fred Cooke]

Yes, presumably to be consumed in another build, right? :-)

On Tue, Aug 30, 2016 at 10:45 AM, Christian Schulte <c...@schulte.it> wrote:

> Am 08/30/16 um 00:33 schrieb Fred Cooke:
> > I fail to see how any such flattening can do away with interpolation.
> Your
> > typical nonlib project has say 5-100 deps, each of which would have a
> flat
> > tree that needs to be compared with and resolved against the others.
>
> As far as I understood the proposal, this is solely happening during
> build time backed by the build pom. The consumer pom is just a
> constant/final list (tree?) of dependencies the way it got resolved
> during building.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Fred Cooke]

I fail to see how any such flattening can do away with interpolation. Your
typical nonlib project has say 5-100 deps, each of which would have a flat
tree that needs to be compared with and resolved against the others. I can
see it speeding things up due to having all of the information for just the
declared number after that many downloads, but you can't have simple code
that just gets stuff. Not going to work.

Or am I blind?

On Tue, Aug 30, 2016 at 10:27 AM, Christian Schulte  wrote:

> Am 08/30/16 um 00:16 schrieb Paul Benedict:
> > I see a deployed faulty "consumer pom" to be more more harmful than
> > generating it locally on demand. At least with the local one I can
> upgrade
> > my client to fix a dependency calculation. There will be no such relief
> in
> > the case of your proposal.
>
> It's not my proposal but I agree to what is proposed. This whole
> discussion started because users have requested to revert commits due to
> compatibility issues. They want to keep such "faulty" behaviour. If they
> want to fix it, they can deploy a new version using a more recent Maven
> version. The older Maven version will then also see this new behaviour.
> If the consumer pom contains the complete resolved dependency tree, the
> code interpreting that data is not much more than downloading some files
> from some repository. Yes. Repository information needs to be part of
> that consumer pom as well. So the resolved dependency tree including
> repository information from where to get the resolved artifacts. And we
> also need to find a way to handle version ranges.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Fred Cooke]

I still find it a bit off that the original real POM won't always be
directly available anymore.

Other tools create fake POMs because they *have* to - there's no other
option.

I feel like some fidelity would be lost. Diffability would be lost (from a
scenario where there's nothing to diff).

Unrelated, really, but kind of related: top level deployable artefact
deployments, debs, wars, exes, etc. When ranges are in use it'd be nice to
deploy a sort of strict effective pom with fully hard [] versions for all
things. This can be achieved in other ways, though.

I guess that is to say, don't forget about non-central deployments. I
suppose if there's a way to always deploy pom.xml.build through some plugin
or configuration or some such, then that's fine with me.

On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY <herve.bout...@free.fr>
wrote:

> Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit :
> > Fair call re embedded pom, however it's quite convenient to just browse
> to
> > it and read.
> >
> > I've occasionally gone looking for details from poms of artefacts and
> found
> > a mess and missing stuff, and been annoyed. It probably wasn't gradle's
> > fault, though. Just a sloppy author. If I'm honest I wouldn't even know
> if
> > I've ever consumed a non-maven artefact, certainly none of mine! :-)
> >
> > No, I am sure, I have, at least one, and it's an ant one with a hard
> coded
> > POM that doesn't always reflect the contents of the jar. Yuck. Clearly
> not
> > an issue with automated stuff, though.
> >
> > My only argument now is ease of reading things like project descriptions,
> > contributors, SCM details, etc rather than having to unpack the jar. And
> if
> > you do, and end up with two pom.xmls laying around, that's not nice.
> Better
> > to just start always suffixing one with pom.xml.build or some such? I
> think
> > so, but I haven't thought deeply about it aside from reading this thread.
> our consumer pom will be generated from build pom: we can automate copy of
> any
> information we want, and for sure, I expect to put at least description,
> scm
> details, issueManagement, license (of course).
> In your list, there is only constributors that I was not counting on it:
> but
> it's a detailed decision we'll have to make
>
> for sure, Maven consumer poms, since generated from Maven build pom, can
> have
> much more details (and be sure they are accurrate) than build tools that
> don't
> generate it from data that exists in their original build format
>
> Regards,
>
> Hervé
>
> >
> >
> >
> > On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY <herve.bout...@free.fr>
> >
> > wrote:
> > > Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
> > > > That should have separation between builder Pom and consumer Pom. For
> > > > packaging=pom we deploy the builder Pom using classifier=build
> > > > *for all other packaging a we do not deploy the builder Pom*.
> > > >
> > > > I don't like the sound of this. The deployed artefacts should include
> > > > the
> > > > exact POM in use to build the project, as a reference, even if under
> a
> > > > different name. Yes, they should be in SCM, however down stream it's
> > >
> > > useful
> > >
> > > > to see these even when the SCM is offline or gone or private or
> > > > whatever.
> > > > Or did I misunderstand? If so, please clarify?
> > >
> > > when you consume an artifact not build with Maven, do you get the full
> > > build
> > > script?
> > > no
> > > I know that, as Maven users, we got used to have the build pom
> published
> > > in
> > > central: this is now an issue, but we like that
> > >
> > > notice: the build pom can be injected in the artifact, in
> META-INF/maven,
> > > like
> > > it is currently done
> > > but I don't see the point in requiring it to be pbulished separately in
> > > central: no other build tool does that, and they don't have any issue
> with
> > > that (and eventually it's a feature: don't publish internal details you
> > > don't
> > > really want people to see)
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > > On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
> > > >
> > > > stephen.alan.conno...@gmail.com> wrote:
> > > > > On Tuesday 23 August 2016, Paul Benedict <pbened...@apache.org>
> wrote:
> > > > > > On Tue, Aug 23, 2

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Fred Cooke]

Fair call re embedded pom, however it's quite convenient to just browse to
it and read.

I've occasionally gone looking for details from poms of artefacts and found
a mess and missing stuff, and been annoyed. It probably wasn't gradle's
fault, though. Just a sloppy author. If I'm honest I wouldn't even know if
I've ever consumed a non-maven artefact, certainly none of mine! :-)

No, I am sure, I have, at least one, and it's an ant one with a hard coded
POM that doesn't always reflect the contents of the jar. Yuck. Clearly not
an issue with automated stuff, though.

My only argument now is ease of reading things like project descriptions,
contributors, SCM details, etc rather than having to unpack the jar. And if
you do, and end up with two pom.xmls laying around, that's not nice. Better
to just start always suffixing one with pom.xml.build or some such? I think
so, but I haven't thought deeply about it aside from reading this thread.



On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY <herve.bout...@free.fr>
wrote:

> Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
> > That should have separation between builder Pom and consumer Pom. For
> > packaging=pom we deploy the builder Pom using classifier=build
> > *for all other packaging a we do not deploy the builder Pom*.
> >
> > I don't like the sound of this. The deployed artefacts should include the
> > exact POM in use to build the project, as a reference, even if under a
> > different name. Yes, they should be in SCM, however down stream it's
> useful
> > to see these even when the SCM is offline or gone or private or whatever.
> > Or did I misunderstand? If so, please clarify?
> when you consume an artifact not build with Maven, do you get the full
> build
> script?
> no
> I know that, as Maven users, we got used to have the build pom published in
> central: this is now an issue, but we like that
>
> notice: the build pom can be injected in the artifact, in META-INF/maven,
> like
> it is currently done
> but I don't see the point in requiring it to be pbulished separately in
> central: no other build tool does that, and they don't have any issue with
> that (and eventually it's a feature: don't publish internal details you
> don't
> really want people to see)
>
> Regards,
>
> Hervé
>
> >
> > On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
> >
> > stephen.alan.conno...@gmail.com> wrote:
> > > On Tuesday 23 August 2016, Paul Benedict <pbened...@apache.org> wrote:
> > > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <c...@schulte.it
> > > >
> > > > <javascript:;>> wrote:
> > > > > Am 08/24/16 um 00:08 schrieb Paul Benedict:
> > > > > > POM and a future major version POM? I am hinting at a strategy
> for
> > > > >
> > > > > forward
> > > > >
> > > > > > compatibility.
> > > > >
> > > > > Is forward compatibility really needed/required?
> > > >
> > > > I honestly don't know, which is why I am asking. An answer of "no
> > > > compatibility" is possible, too.
> > > >
> > > > I can completely see the argument that says POMs must be
> > > > all-parseable-or-nothing -- for the sake of reproducibility. I
> actually
> > > > prefer this answer. I think it is sensible to fail a build when
> > > > encountering a POM version too advanced. If your client only
> supports up
> > >
> > > to
> > >
> > > > model 4.0.0, then all artifacts must be specified by 4.0.0 models,
> too.
> > > >
> > > > On the other hand, I wanted to give the benefit of the doubt to the
> > > > opposite argument. At least one person spoke up and said it's
> > >
> > > unacceptable
> > >
> > > > to fail a build on configuration you don't understand. Well, that's
> an
> > > > interesting argument, too. That person doesn't want to tank the build
> > > > for
> > > > the 1% of configuration that can't be understood but I fail to
> see
> > > > an
> > > > escape hatch here. If a client can't understand what's being
> specified,
> > > > then what else can be done but fail?
> > >
> > > Strip the dependencies a and let the user fix up manually (ideally by
> > > logging a warning that you are consuming a dependency using a newer
> > > modelVersion)
> > >
> > > Everyone forgets that the 4.0.0 ship has sailed already, so we have to
> > > deploy best-effort 4.0.0 poms
> > >
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Fred Cooke]

That should have separation between builder Pom and consumer Pom. For
packaging=pom we deploy the builder Pom using classifier=build
*for all other packaging a we do not deploy the builder Pom*.

I don't like the sound of this. The deployed artefacts should include the
exact POM in use to build the project, as a reference, even if under a
different name. Yes, they should be in SCM, however down stream it's useful
to see these even when the SCM is offline or gone or private or whatever.
Or did I misunderstand? If so, please clarify?

On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Tuesday 23 August 2016, Paul Benedict  wrote:
>
> > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte  > > wrote:
> >
> > > Am 08/24/16 um 00:08 schrieb Paul Benedict:
> > > > POM and a future major version POM? I am hinting at a strategy for
> > > forward
> > > > compatibility.
> > >
> > > Is forward compatibility really needed/required?
> > >
> >
> > I honestly don't know, which is why I am asking. An answer of "no
> > compatibility" is possible, too.
> >
> > I can completely see the argument that says POMs must be
> > all-parseable-or-nothing -- for the sake of reproducibility. I actually
> > prefer this answer. I think it is sensible to fail a build when
> > encountering a POM version too advanced. If your client only supports up
> to
> > model 4.0.0, then all artifacts must be specified by 4.0.0 models, too.
> >
> > On the other hand, I wanted to give the benefit of the doubt to the
> > opposite argument. At least one person spoke up and said it's
> unacceptable
> > to fail a build on configuration you don't understand. Well, that's an
> > interesting argument, too. That person doesn't want to tank the build for
> > the 1% of configuration that can't be understood but I fail to see an
> > escape hatch here. If a client can't understand what's being specified,
> > then what else can be done but fail?
>
>
> Strip the dependencies a and let the user fix up manually (ideally by
> logging a warning that you are consuming a dependency using a newer
> modelVersion)
>
> Everyone forgets that the 4.0.0 ship has sailed already, so we have to
> deploy best-effort 4.0.0 poms
>
> Now I say that 3.4 should not have a new modelVersion but what it could do
> is be more forgiving of newer modelVersions or try and download and use an
> XSLT to convert newer modelVersions to 4.0.0 (while logging a warning) with
> option flags to allow failing the build if XSLT had to be applied
>
> So let's bump the modelVersion in Maven 5.0.0 (there is no Maven 4.x let's
> align on the modelVersion)
>
> That should have separation between builder Pom and consumer Pom. For
> packaging=pom we deploy the builder Pom using classifier=build for all
> other packaging a we do not deploy the builder Pom.
>
> We deploy a *best effort* conversion of the consumer Pom to modelVersion
> 4.0.0 without a classifier and the consumer Pom gets deployed as classifier
> consumer.
>
> The consumer Pom format allows for XSLT to transform to a parsable syntax,
> if transform is required we log a warning (or fail the build if the builder
> Pom indicates strict modelVersion adherence)
>
> So yeah maven 5.x will be able to parse dependencies with modelVersion 6.x
> while logging warnings that the user may not have the correct dependency
> tree. That is IMHO acceptable forward compatibility
>
> HTH
>
> -Stephen
>
> Ps I'm really hoping someone has a less crappy solution that this... But I
> believe this is actually *a* solution... And prior to this I have not seen
> any solution
>
>
> > Cheers,
> > Paul
> >
>
>
> --
> Sent from my phone
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Fred Cooke]

Someone nailed it when they said it'd be two big decisions, one for JRE one
for MVN.

But here's the reality: People are just going to grab and use "the latest",
whatever it is.

What does that mean? We'll probably start seeing dependencies we can't
consume, but want to, and otherwise could.

A good library author/maintainer will dodge this bullet for their
downstream users, but some won't care, or will be lazy, or will get annoyed
running N versions of Maven.

There's some great discussion further up about splitting things sideways. I
think that's the line this has to take.

In terms of a chunk of code that I want to leverage, I don't care much
about it aside from its dependency tree and the classes within.

Keep this behaviour, somehow.


On Wed, Aug 24, 2016 at 11:11 AM, Christian Schulte  wrote:

> Am 08/24/16 um 00:57 schrieb Paul Benedict:
> > escape hatch here. If a client can't understand what's being specified,
> > then what else can be done but fail?
>
> That's what caught my attention as well. Is there anyone around knowing
> about any kind of software which can handle forward compatiblity in a
> way I could learn from?
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: slf4j runtime dependency for plugin

[Fred Cooke]

Something doesn't have to be in Java to be universal (as SLF4J really is),
and conversely, something being in Java doesn't make the world instantly
catch up (eg YodaTime vs J8+).

Adding the nop logger as a dep seems like the wrong thing to do and will
(IIRC) cause a warning/error at runtime if there's another one present.
Leaving it out (IIRC) falls back to that anyway with a warning given. IE, I
don't think adding that does any good whatsoever.

IIRCs because it's been a long time since I had this misconfigured :-)

On Tue, Aug 16, 2016 at 4:47 AM, Christopher  wrote:

> On Mon, Aug 15, 2016 at 2:37 AM Michael Osipov 
> wrote:
>
> > Am 2016-08-14 um 23:21 schrieb Christopher:
> > > On Sun, Aug 14, 2016 at 4:31 PM Michael Osipov 
> > wrote:
> > >
> > >> Am 2016-08-12 um 23:48 schrieb Christopher:
> > >>> Hi,
> > >>>
> > >>> I use a plugin which has a runtime dependency on an slf4j
> > implementation,
> > >>> but the plugin itself is built without declaring one in its pom. (
> > >>> https://github.com/koraktor/mavanagaiata/issues/43)
> > >>>
> > >>> In some versions of Maven, I get a warning about slf4j not finding an
> > >>> implementation. In other versions, it is silent.
> > >>>
> > >>> Was an slf4j implementation provided in newer versions to the
> execution
> > >> of
> > >>> plugins?
> > >>>
> > >>> Will there be a multiple-binding conflict if the plugin itself
> provides
> > >> one
> > >>> of its own to get rid of the warning on certain versions of maven
> which
> > >>> result in that warning (I didn't see one when I tried)?
> > >>>
> > >>> If there is a risk of a conflict, which implementation would be
> > preferred
> > >>> in order to converge on one provided by Maven?
> > >>>
> > >>> Is there another solution the plugin should seek?
> > >>>
> > >>> In general, what dependencies are plugins expected to provide, and
> what
> > >>> dependencies are expected to be provided by Maven, and how are
> > conflicts
> > >>> resolved in the architecture?
> > >>>
> > >>> Feel free to comment on the GitHub issue directly, or here. I'll be
> > >>> watching both.
> > >>
> > >> I will cite what I have written on Stack Overflow
> > >> (http://stackoverflow.com/a/7107934/696632) five years ago and it
> still
> > >> holds true:
> > >>
> > >> You *never* provide a log implementation. The client application has
> to
> > >> do so. Otherwhise this would be a violation of separation of concerns.
> > >> Don't do any assumptions about an unknown client.
> > >>
> > >>
> > > I agree with that sentiment...generally. But this is a maven plugin, so
> > I'm
> > > trying to figure out what Maven is going to provide it when it
> executes.
> > If
> > > it's not going to provide an implementation, then the plugin has to. If
> > you
> > > have answers to the specific questions I asked above, I think it might
> > help.
> >
> > It should not matter to you what Maven provides. It will always provide
> > some backend. Otherwise Maven won't be able to log itself.  Even if
> > Maven would not provide anything. It is not your task to force some
> > implementation. It is a several failure of the client to do so.
> >
> > Michael
> >
>
> That would make more sense to me if there were a universally agreed upon
> logging API, and all clients were guaranteed to provide *some* backend for
> that standard logging API. Unfortunately, no logging API seems to be
> universal, and the one provided in Java itself is awful. I'm not even sure
> what Maven uses underneath, and it may not use SLF4J at all (which means it
> has no reason to provide an implementation).
>
> This is actually a pretty unfortunate circumstance in the first place...
> Maven plugins should only be logging to the provided Maven logger itself,
> and the plugin shouldn't care what backend Maven is using for that logger.
> This
> particular plugin is doing the right thing... using the Maven logger and
> relying on Maven for the backend. Unfortunately, it seems the
> org.eclipse.jgit dependency does its own logging, and that's outside this
> plugin's control.
>
> Until there is a universal logging framework, these heuristics about what
> the "right" thing to do are not going to be perfect. Ideals like "rely on
> the client to provide the implementation" aren't going to fully match
> reality. Personally, I'd like to see an slf4j-like API make its way into
> Java itself. Then, perhaps these kinds of issues wouldn't come up as often.
>

Re: slf4j runtime dependency for plugin

[Fred Cooke]

Clearly it's going to matter to him if Maven fails to provide and it
doesn't work. Some sort of dependency isolation not right somewhere?
Something seems to be going on. You're right, but he's seeing behaviour
that indicates something is amiss.

On Mon, Aug 15, 2016 at 6:37 PM, Michael Osipov  wrote:

> Am 2016-08-14 um 23:21 schrieb Christopher:
>
>> On Sun, Aug 14, 2016 at 4:31 PM Michael Osipov 
>> wrote:
>>
>> Am 2016-08-12 um 23:48 schrieb Christopher:
>>>
 Hi,

 I use a plugin which has a runtime dependency on an slf4j
 implementation,
 but the plugin itself is built without declaring one in its pom. (
 https://github.com/koraktor/mavanagaiata/issues/43)

 In some versions of Maven, I get a warning about slf4j not finding an
 implementation. In other versions, it is silent.

 Was an slf4j implementation provided in newer versions to the execution

>>> of
>>>
 plugins?

 Will there be a multiple-binding conflict if the plugin itself provides

>>> one
>>>
 of its own to get rid of the warning on certain versions of maven which
 result in that warning (I didn't see one when I tried)?

 If there is a risk of a conflict, which implementation would be
 preferred
 in order to converge on one provided by Maven?

 Is there another solution the plugin should seek?

 In general, what dependencies are plugins expected to provide, and what
 dependencies are expected to be provided by Maven, and how are conflicts
 resolved in the architecture?

 Feel free to comment on the GitHub issue directly, or here. I'll be
 watching both.

>>>
>>> I will cite what I have written on Stack Overflow
>>> (http://stackoverflow.com/a/7107934/696632) five years ago and it still
>>> holds true:
>>>
>>> You *never* provide a log implementation. The client application has to
>>> do so. Otherwhise this would be a violation of separation of concerns.
>>> Don't do any assumptions about an unknown client.
>>>
>>>
>>> I agree with that sentiment...generally. But this is a maven plugin, so
>> I'm
>> trying to figure out what Maven is going to provide it when it executes.
>> If
>> it's not going to provide an implementation, then the plugin has to. If
>> you
>> have answers to the specific questions I asked above, I think it might
>> help.
>>
>
> It should not matter to you what Maven provides. It will always provide
> some backend. Otherwise Maven won't be able to log itself.  Even if Maven
> would not provide anything. It is not your task to force some
> implementation. It is a several failure of the client to do so.
>
> Michael
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Git Commit log with wrong encoding

[Fred Cooke]

The solution is to not push directly, and to seek peer review even if
you're the king of the hill. Once pushed to a public upstream a commit
should pretty much never be touched.

What was the impact of the encoding being wrong? I haven't yet understood
the actual problem.

On Sun, Aug 7, 2016 at 6:38 AM, Michael Osipov  wrote:

> Am 2016-08-06 um 20:35 schrieb Karl Heinz Marbaise:
>
>> On 8/6/16 8:29 PM, Michael Osipov wrote:
>>
>>> Am 2016-08-06 um 20:24 schrieb Karl Heinz Marbaise:
>>>
 Hi Michael,

 On 8/6/16 8:20 PM, Michael Osipov wrote:

> Am 2016-08-06 um 20:01 schrieb Karl Heinz Marbaise:
>
>> Hi Michael,
>>
>> On 8/6/16 7:46 PM, Michael Osipov wrote:
>>
>>> Am 2016-08-06 um 19:38 schrieb Karl Heinz Marbaise:
>>>
 Hi,

 I have accidently committed a change in Git with a log message which
 contains wrongly encoded characters...

 What is the best to handle this?

 git commit --amend ..

 and

 git push -f

>>>
>>> The ASF server will probably block history rewrite.
>>>
>>>
>> It works...So I have fixed the wrong encoding log message..
>>
>
> You were lucky because no one pulled yet from and if someone did and
> pushed again, that would be a pain.
>
 I know about the risks I took...;-(...

 But would be the "better" way to fix such issue ?  Do you know a better
 one?

>>>
>>> From the top of my head, I would create an empty commit with a fixed
>>> message refencing the SHA1 which was fixed.
>>>
>>
>> But doesn't this kept the commit with the wrong encoded message or do i
>> misunderstand a thing ?
>>
>
> Correct but you don't rewrite history and don't mess up other people's
> cloned repo.
>
> See for details: http://stackoverflow.com/q/1491001/696632
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

[Fred Cooke]

Got it! Thanks. The dependency without [] needs to exist, but may not end
up being used due to conflicts. Fair enough. :-)

On Sat, Aug 6, 2016 at 3:24 PM, Christian Schulte  wrote:

> Am 08/06/16 um 05:15 schrieb Christian Schulte:
> > It just takes the highest version the version range resolver returns and
> uses that or fails if nothing like that is available.
>
> If using version range syntax.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

[Fred Cooke]

A parent, I thought, used to be equivalent to [], ie, hard requirement. A
dependency without [] is NOT a hard requirement, simply advisory. So yeah,
they're different, or were. I wonder what semantics the ranged parents
behaviour has for a simple backward compatible (or not) plain version?
Implicitly converted to []? In any case, you solved your issue with
something that makes sense, good.

On Sat, Aug 6, 2016 at 10:02 AM, Thiebaud, Christophe <
christophe.thieb...@sap.com> wrote:

> Sorry, I strongly disagree, dependency is not optional.
>
> If there were not a valid, higher resolution path, the build would fail as
> well.
>
> Regards,
> Christophe
>
> -Original Message-
> From: Christian Schulte [mailto:c...@schulte.it]
> Sent: Freitag, 5. August 2016 16:33
> To: Maven Developers List 
> Subject: Re: project having a dependency with a version range fails
> building when parent pom of dependency is evicted from remote repo
>
> Am 08/05/16 um 16:10 schrieb Thiebaud, Christophe:
> > ... oh ... I was 200% sure that parent did not allow a version range ...
>
> Introduced in Maven 3.2.2. Broken since a few releases. Fixed in
> 3.4.0-SNAPSHOT.
>
> >
> > I tried, -> BUILD SUCCESS.
> >
> > Hourah, and thanks.
> >
> > Let see now if this option is ok with our developers.
> >
> > In any case, don't you think there is some valid reason to fill a jira
> entry ?
>
> Issue is the repository being in an inconsistent state. It would not
> have been possible to deploy lib-1.0-SNAPSHOT without its parent being
> available in the repository.
>
> > I mean, iterating over a set of possible resolutions should not fail if
> one of the set fails, but if no acceptable resolution is found at the end,
> no ?
> >
> > In fact, this is what happen when the (failing) parent relationship is
> replaced with a (failing as well) dependency relationship.
>
> What exactly do you mean with "failing as well"? There is a difference
> between not finding a dependency and not finding a parent. The first is
> comparable to an "optional file not found" whereas the parent is nothing
> optional.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

[Fred Cooke]

I'm surprised the transitive dependency to that parent succeeds, unless
it's ranged.

For the others, in order to determine the dependency tree, and thus any
transitive dependencies, and so on, the entire pom needs to be present. A
parent is part of that. If the parent is of a fixed version (all that's
currently supported IIRC) and not present, then it should fail otherwise
it's going to produce something potentially quite different to what the
developer intended (or accidentally indicated that they intended).

I'm wondering what SNAPSHOTs are doing in a remote, but I know some people
operate that way. I wouldn't/don't.

Another thing I wouldn't do is stick dependencies in a parent, period. Or
use a snapshot parent, ever.

Interested to read what the gurus come back with, though :-)

Regards,

Fred.

On Thu, Aug 4, 2016 at 3:36 AM, Thiebaud, Christophe <
christophe.thieb...@sap.com> wrote:

> Hi All,
>
>
>
> The title says it all.
>
>
>
> Any suggestions how to overcome this issue ?
>
>
>
> Explanation below. Let the projects be:
>
>
>
> ‘parent’ : the parent pom of the ‘lib’ library just below
>
> ‘lib’ : the library
>
> ‘app’ : the application dependent on ‘lib’ through a version range.
>
>
>
> (all three minimalistic sample projects here: https://github.com/iroif)
>
>
>
>
>
> Here is what happens during time, when versions are bumped and projects
> are deployed to remote repo:
>
>
>
> day 0
>
>
>
> ‘parent’ 0.0.1-SNAPSHOT is deployed to remote repo
>
> ‘lib’0.0.1-SNAPSHOT is deployed to remote repo
>
> ‘app’ builds OK
>
>
>
> day 1
>
>
>
> ‘parent’ 0.0.1-SNAPSHOT is still on remote repo
>
> ‘parent’ 0.0.2-SNAPSHOT is deployed to remote repo
>
> ‘lib’0.0.1-SNAPSHOT is still on remote repo
>
> ‘app’ builds OK
>
>
>
> day 2
>
>
>
> ‘parent’ 0.0.1-SNAPSHOT is still on remote repo
>
> ‘parent’ 0.0.2-SNAPSHOT is still on remote repo
>
> ‘lib’0.0.1-SNAPSHOT is still on remote repo
>
> ‘lib’0.0.2-SNAPSHOT is deployed to remote repo
>
> ‘app’ builds OK
>
>
>
> day 3
>
>
>
> ‘parent’ 0.0.1-SNAPSHOT is automatically evicted from remote repo by some
> rule
>
> ‘parent’ 0.0.2-SNAPSHOT is still on remote repo
>
> ‘lib’0.0.1-SNAPSHOT is still on remote repo
>
> ‘lib’0.0.2-SNAPSHOT is still on remote repo
>
> *‘app’ build FAILS*
>
>
>
> this is because maven tries to build the pom for ‘lib’ 0.0.1-SNAPSHOT and
> fails as ‘parent’ 0.0.1-SNAPSHOT is not available anymore.
>
>
>
> However, IMHO, the build of ‘app’ should not fail as there is another
> valid dependency resolution : ‘lib’ 0.0.2-SNAPSHOT with ‘parent’
> 0.0.2-SNAPSHOT.
>
>
>
> In fact, when the relationship between parent and lib is a dependency (and
> not a parent-child relationship), the build of ‘app’ succeeds, even when
> transitive dependency to ‘parent’ 0.0.1-SNAPSHOT cannot be resolved.
>
>
>
> Note that ‘app’ build is successful again, when on day 4, ‘lib’
> 0.0.1-SNAPSHOT is in turn evicted:
>
>
>
> day 4
>
>
>
> ‘parent’ 0.0.2-SNAPSHOT is still on remote repo
>
> ‘lib’0.0.1-SNAPSHOT is automatically evicted from remote repo by some
> rule
>
> ‘lib’0.0.2-SNAPSHOT is still on remote repo
>
> *‘app’ build resumes OK*
>
>
>
> Any suggestions how to overcome this issue ?
>
>
>
> We have builds failing every other day in our build farm for this reason.
>
>
>
> Thanks!
>
> Christophe
>
> PS. The content of this mail is duplicated here :
> https://github.com/iroif/iroif-parent
>
>
>

Re: Strange GIT

[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 <fred.co...@gmail.com> 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 <tibor.dig...@googlemail.com
> > 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

[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: [DISCUSS] Java version requirement for Mavan 3.4.x

[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"
> > > > >
> > > >
> > > > 

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

[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 

Unreadable dependency resolution/collection failure messages

[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: Reproducibility versus ranges

[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 <fred.co...@gmail.com> 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 <javascript:;>> 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 <e...@zusammenkunft.net
> > <javascript:;>> wrote:
> > >
> > > > Am Mon, 26 Oct 2015 13:03:03 -0400
> > > > schrieb Benson Margulies <bimargul...@gmail.com <javascript:;>
> > <javascript:;>>:
> > > > > 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
> > <javascript:;> <javascript:;>
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > <javascript:;>
> > > <javascript:;>
> > > >
> > > >
> > >
> > > --
> > > Sent from my phone
> > >
> >
>
>
> --
> Sent from my phone
>

Re: Reproducibility versus ranges

[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 <e...@zusammenkunft.net>
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 <fred.co...@gmail.com>:
>
> > 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
> > <e...@zusammenkunft.net> 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 <fred.co...@gmail.com>:
> > >
> > > > 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
> > > > > <e...@zusammenkunft.net> wrote:
> > > > >
> > > > > > Am Mon, 26 Oct 2015 13:03:03 -0400
> > > > > > schrieb Benson Margulies <bimargul...@gmail.com
> > > > > > <javascript:;>>:
> > > > > > > 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
> > > > > > <javascript:;> For additional commands, e-mail:
> > > > > > dev-h...@maven.apache.org
> > > > > <javascript:;>
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > 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
>
>

Re: Reproducibility versus ranges

[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

[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 <e...@zusammenkunft.net>
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 <fred.co...@gmail.com>:
>
> > 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 <e...@zusammenkunft.net>
> > > wrote:
> > >
> > > > Am Mon, 26 Oct 2015 13:03:03 -0400
> > > > schrieb Benson Margulies <bimargul...@gmail.com <javascript:;>>:
> > > > > 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
> > > > <javascript:;> For additional commands, e-mail:
> > > > dev-h...@maven.apache.org
> > > <javascript:;>
> > > >
> > > >
> > >
> > > --
> > > 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

[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: number of bugs in maven-release-plugin

[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 rfscho...@apache.org
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

[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 bimargul...@gmail.com
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 tibordig...@apache.org
 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: IRC rooms @codehaus

[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 rfscho...@apache.org
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 ja...@takari.io
 :


  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 codeh...@sourcegrounds.com
 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: [MNG-5840] IMHO critical regression in Maven 3.3.1 3.3.3

[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=14574303page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14574303
 explain the issue better?

 On 5 June 2015 at 11:05, Fred Cooke fred.co...@gmail.com 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: [MNG-5840] IMHO critical regression in Maven 3.3.1 3.3.3

[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: Full migration to Git

[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 aherit...@gmail.com 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 chrisgw...@gmail.com
 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 ja...@takari.io wrote:
 
   Great, thanks Baptiste.
  
On May 31, 2015, at 4:36 AM, Baptiste Mathus bmat...@batmat.net
  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 baerr...@gmail.com:
   
On 31 May 2015 at 08:18, Jason van Zyl ja...@takari.io 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 Batmat 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

[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 denn...@apache.org 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 ja...@takari.io 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

[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 ja...@takari.io:

  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 ja...@takari.io:
  
   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 ja...@takari.io:
  
   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 ja...@takari.io:
  
   Maybe it best then to have everything mirrored to Git, if there
 are
   any
   repos that are not. Turn off SVN and do any partitioning once
   everything is
   on the Git side?
  
   Anyone have any objections to this general plan of action:
  
   1) Mirror anything to Git that isn’t
   2) Make all the Git repos the primary
   3) Do any separation or refactoring once in Git to avoid any
  dealings
   with
   SVN
  
   On Jun 1, 2015, at 7:53 AM, Olivier Lamy ol...@apache.org
  wrote:
  
   On 1 June 2015 at 21:37, Jason van Zyl ja...@takari.io wrote:
  
   Great, you should update the document. I’ll move on to the
  enforcer
   then.
  
   Did you have explicit instructions for 

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

[Fred Cooke]

+1 from me, too! Well said.

On Sun, May 31, 2015 at 6:09 AM, Michael Osipov micha...@apache.org 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: IRC rooms @codehaus

[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 codeh...@sourcegrounds.com
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: Jekyll experiment

[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 ja...@takari.io 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: [DISCUSS] To SemVer or not to SemVer, that is the question

[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 chrisgw...@gmail.com wrote:

 On Mon, Feb 23, 2015 at 8:42 AM, Fred Cooke fred.co...@gmail.com 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 CCB, 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: [DISCUSS] To SemVer or not to SemVer, that is the question

[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 denn...@apache.org wrote:

 Thanks Robert,

 I'll have a look at it.

 On Sun, Feb 22, 2015 at 1:00 PM, Robert Scholte rfscho...@apache.org
 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
  denn...@apache.org:
 
 
  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 enter
  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: Releases, Continuous Delivery and the Future

[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 ja...@takari.io 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 now really means 3.2.6 which is totally
 inconsistent. I think skipping 

Re: Releases, Continuous Delivery and the Future

[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 ja...@takari.io 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 fred.co...@gmail.com 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 ja...@takari.io 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

Re: Git Push Summary

[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 rfscho...@apache.org
wrote:

 Ouch?!

 Op Mon, 15 Sep 2014 03:44:29 +0200 schreef ol...@apache.org:

  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: Maven 1.x cleanup

[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 br...@apache.org 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: Operating system requirement

[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 and...@hammar.net wrote:

 Handled in ticket MNG-5610.

 /Anders


 On Fri, Mar 28, 2014 at 4:47 PM, sebb seb...@gmail.com wrote:

  On 28 March 2014 12:09, Anders Hammar and...@hammar.net 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: Convert everything to Git

[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 ja...@takari.io wrote:


 On Feb 20, 2014, at 1:07 PM, Dennis Lundberg dennisl.apa...@gmail.com
 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 ja...@tesla.io 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

[Fred Cooke]

+extension
+groupIdorg.apache.maven.wagon/groupId
+artifactIdwagon-ssh-external/artifactId
+version${extension.version.wagon}/version
+/extension

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

!-- scmCommentPrefixReleasing ${project.artifactId}
version ${project.version} /scmCommentPrefix -- !-- Space trimmed and
version snapshot, yuck. --

But I'm OT now.

Fred.


On Fri, Feb 21, 2014 at 10:58 AM, Mark Derricutt m...@talios.com 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: Towards faster releases

[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 fred.co...@gmail.com 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 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 ja...@takari.io wrote:
  
   
On Feb 18, 2014, at 11:47 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com javascript:; wrote:
   
 Well all this will be for the moment

Re: Towards faster releases

[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 fred.co...@gmail.com 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 fred.co...@gmail.com 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

Re: Towards faster releases

[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 ja...@takari.io wrote:

 
  On Feb 18, 2014, at 11:47 AM, Stephen Connolly 
  stephen.alan.conno...@gmail.com javascript:; 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 work?


 The RM has always been whoever stands up and says I am cutting a release

 I was just saying that if it is too much effort for you, I am willing to
 step up and 

Re: Convert everything to Git

[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
lennart.jore...@gmail.comwrote:

 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 kristian.rosenv...@gmail.com
 :

  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 herve.bout...@free.fr:
 
   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: Convert everything to Git

[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 ja...@takari.io wrote:

 On Feb 13, 2014, at 12:28 PM, Hervé BOUTEMY herve.bout...@free.fr 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 herve.bout...@free.fr
 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 failures, discouragements and doubts. We tend to forget
  the past difficulties, the many false starts, and the painful
  groping. We see our past achievements as the end result of a
  clean forward thrust, and our present difficulties as
  signs of decline and decay.
 
  -- Eric Hoffer, 

Re: Convert everything to Git

[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 herve.bout...@free.frwrote:

 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

[Fred Cooke]

I like you more and more! :-)


On Thu, Feb 13, 2014 at 4:37 PM, Jason van Zyl ja...@tesla.io 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

[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 ja...@takari.io 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 m...@talios.com 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: [VOTE] Apache Maven SCM 1.9

[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 ol...@apache.org 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=10527version=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: Maven Core moving to 1.6

[Fred Cooke]

+1 too, 1.5 is dead for me.


On Mon, Oct 7, 2013 at 8:12 PM, Dennis Lundberg dennisl.apa...@gmail.comwrote:

 +1 to 1.6 for 3.2

 On Sat, Oct 5, 2013 at 5:03 AM, Jason van Zyl ja...@tesla.io 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: [ANN] Maven 3.1.1 Release

[Fred Cooke]

Congratulations, Jason! :-)


On Fri, Oct 4, 2013 at 10:56 PM, Jason van Zyl ja...@tesla.io 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: [VOTE] Release Maven 3.1.1

[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 rfscho...@apache.orgwrote:

 +1

 Op Wed, 25 Sep 2013 17:22:45 +0200 schreef Jason van Zyl ja...@tesla.io:


  Anyone else going to give the release a whirl?

 On Sep 17, 2013, at 8:39 AM, Jason van Zyl ja...@tesla.io 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=10500version=18968https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18968

 Staging repo:
 https://repository.apache.org/**content/repositories/maven-**065/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/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.ziphttps://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.gzhttps://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.ziphttps://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.gzhttps://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/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.**orgdev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

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

[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 joerg.schai...@scalaris.com
 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

[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 fred.co...@gmail.com 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 joerg.schai...@scalaris.com
   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

[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 url to 4.0.3 (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 rfscho...@apache.orgwrote:

 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 ja...@tesla.io 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 fred.co...@gmail.com 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 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

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

[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 ja...@tesla.io 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 fred.co...@gmail.com 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

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

[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 seb...@gmail.com 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
 stephen.alan.conno...@gmail.com 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 fred.co...@gmail.com 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) 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 ja...@tesla.io
 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 fred.co...@gmail.com wrote:
 
  Jason, PLEASE understand that you do NOT have a single user. Not even
  one.
  Nada. Zilch. You have developers

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

[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 ja...@tesla.io 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

[Fred Cooke]

Branches.


On Sat, Sep 14, 2013 at 8:47 PM, Jason van Zyl ja...@tesla.io 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 strub...@yahoo.de 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 aherit...@gmail.com
  To: Maven Developers List dev@maven.apache.org
  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 fred.co...@gmail.com 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 ja...@tesla.io
  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

[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 strub...@yahoo.de 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 fred.co...@gmail.com
  To: Maven Developers List dev@maven.apache.org
  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 ja...@tesla.io 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 strub...@yahoo.de 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 aherit...@gmail.com
To: Maven Developers List dev@maven.apache.org
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 fred.co...@gmail.com
  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
  ja...@tesla.io
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

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

[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 strub...@yahoo.de 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 aherit...@gmail.com
   To: Maven Developers List dev@maven.apache.org
   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 fred.co...@gmail.com 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 ja...@tesla.io
   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
 
  --



 --
 Sent from my phone

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

[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 denn...@apache.orgwrote:

 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 strub...@yahoo.de 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 fred.co...@gmail.com
  To: Maven Developers List dev@maven.apache.org
  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 strub...@yahoo.de
  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 aherit...@gmail.com
 To: Maven Developers List dev@maven.apache.org
 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
  fred.co...@gmail.com 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
  ja...@tesla.io
 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

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

[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 strub...@yahoo.de
  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 fred.co...@gmail.com
   To: Maven Developers List dev@maven.apache.org
   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

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

[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 ja...@tesla.io 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 fred.co...@gmail.com 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 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

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

[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 herve.bout...@free.fr 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 :/path, 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

 connectionscm:git:https://git-wip-us.apache.org/repos/asf/maven.git/conn
 ection
 developerConnectionscm:git:https://git-wip-us.apache.org/repos/asf/maven.
 git/developerConnection
 urlhttps://git-wip-us.apache.org/repos/asf?p=maven.git/url
 tagHEAD/tag
   /scm

 The head maven-3.0.x is at version 3.0.6-SNAPSHOT and has this in its
 pom.xml scm

 connectionscm:git:https://git-wip-us.apache.org/repos/asf/maven.git/conn
 ection
 developerConnectionscm:git:https://git-wip-us.apache.org/repos/asf/maven.
 git/developerConnection
 urlhttps://git-wip-us.apache.org/repos/asf?p=maven.git/url
 tagHEAD/tag
   /scm

 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 tag 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 tag, but to what? Would it involve
 

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

[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 m...@batmat.net 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 fred.co...@gmail.com 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 herve.bout...@free.fr
  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 :/path, 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
  
   connectionscm:git:https://git-wip-us.apache.org/repos/asf/maven.git
  /conn
   ection
   developerConnectionscm:git:
  https://git-wip-us.apache.org/repos/asf/maven.
   git

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

[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 denn...@apache.org wrote:

 On Fri, Aug 16, 2013 at 9:52 AM, sebb seb...@gmail.com wrote:

  On 16 August 2013 08:10, Dennis Lundberg denn...@apache.org wrote:
   On Fri, Aug 16, 2013 at 1:20 AM, sebb seb...@gmail.com wrote:
  
   On 15 August 2013 20:57, Dennis Lundberg denn...@apache.org wrote:
On Thu, Aug 15, 2013 at 9:27 PM, sebb seb...@gmail.com wrote:
   
On 15 August 2013 14:16, Jason van Zyl ja...@tesla.io 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 will always be in the format
${project.artifactId}-${project.version}
   
  
   My point is that it should be completely transparent, even to outside
   reviewers.
  
  
   I guess that this is the point that we'll have to agree to disagree on.
  My
   view is that if someone wants to to review a release from the Maven
   project, they'd have to have a basic understanding of how Maven works
 and
   how we do releases in 

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

[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 denn...@apache.orgwrote:

 On Fri, Aug 16, 2013 at 11:24 AM, sebb seb...@gmail.com wrote:

  On 16 August 2013 09:32, Dennis Lundberg denn...@apache.org wrote:
   On Fri, Aug 16, 2013 at 9:52 AM, sebb seb...@gmail.com wrote:
  
   On 16 August 2013 08:10, Dennis Lundberg denn...@apache.org wrote:
On Fri, Aug 16, 2013 at 1:20 AM, sebb seb...@gmail.com wrote:
   
On 15 August 2013 20:57, Dennis Lundberg denn...@apache.org
 wrote:
 On Thu, Aug 15, 2013 at 9:27 PM, sebb seb...@gmail.com wrote:

 On 15 August 2013 14:16, Jason van Zyl ja...@tesla.io 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

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

[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 fred.co...@gmail.com 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 denn...@apache.org
  wrote:
 
   On Fri, Aug 16, 2013 at 11:24 AM, sebb seb...@gmail.com wrote:
  
On 16 August 2013 09:32, Dennis Lundberg denn...@apache.org wrote:
 On Fri, Aug 16, 2013 at 9:52 AM, sebb seb...@gmail.com wrote:

 On 16 August 2013 08:10, Dennis Lundberg denn...@apache.org
  wrote:
  On Fri, Aug 16, 2013 at 1:20 AM, sebb seb...@gmail.com wrote:
 
  On 15 August 2013 20:57, Dennis Lundberg denn...@apache.org
   wrote:
   On Thu, Aug 15, 2013 at 9:27 PM, sebb seb...@gmail.com
  wrote:
  
   On 15 August 2013 14:16, Jason van Zyl ja...@tesla.io
  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

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

[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 denn...@apache.org 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 seb...@gmail.com wrote:
   On 14 August 2013 21:21, Dennis Lundberg denn...@apache.org wrote:
   On Wed, Aug 14, 2013 at 10:47 AM, sebb seb...@gmail.com wrote:
  
   On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org
 wrote:
On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote:
On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io 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