Maven Site vs Reporting Plugin workflows?

[Alex O'Ree]

Hi everyone, I'm trying to troubleshoot an issue with the PDF plugin,
https://issues.apache.org/jira/browse/MPDF-62. Root cause seems to be
that the reportPlugins:
@Parameter( readonly = true )
private org.apache.maven.reporting.exec.ReportPlugin[] reportPlugins;

are not injected to the Mojo plugin and that at some point in time the
behavior had changed. Does anyone know approximately when this
occurred or what version the change was in effect?

Moving on, I also checked out the maven-site plugin as it performs the
same task and found nearly identical code for the parts referring to
the reporting plugins, except that when ran, the reportPlugins
parameter is populated by maven. I'm not too sure what the delta is
here nor do I know where to look, but if anyone has any clues or
pointers to what could be wrong or areas to look at it, I'm all ears.
Is there perhaps some resource file or magic string in play?

Related question, where does the parameter injection happen?

Finally, I also didn't find any other references to how the site
plugin causes the report plugins to fire off. Is there any good
resources that I can read up on the current workflow and/or
architecture of all things related to report plugins and site
generation?

Thanks!

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

Re: [DISCUSS] Retrospective on Maven 3.5.0-alpha-1

[Jeff Jensen]

> The date of the commit is not the date it got committed to master, but the
date it got committed to some branch, no longer existing after the commit.
If this is the way GIT works, so be it. I just don't like it. It could not
be more confusing.

A couple of thoughts in case they help you.

1. Git has "author date" and "commit date" for each commit.
* author date is the original date of the first commit, never changes.
* commit date is the last time the commit was modified (e.g. amended,
committed to a branch).
Each date is useful, depending on the situation investigating.

To help with the date displays, which git client(s) do you use?
  * For SourceTree (free git UI client from Atlassian), it has a "Display
author date instead of commit date in log" config option.  It will also
show both dates in the commit details.

  * For CLI, use the log command's "pretty formatter" (use "git help log"
for lots of details in the "pretty formats" section).  e.g. "git log
--pretty=fuller" shows both author and commit dates (and authors).

2. DeepGit is a free tool that helps with tracing commits.  You may
appreciate it: http://www.syntevo.com/deepgit/
The same company also creates the git UI client "SmartGit", which is free
for non-commercial use.  You may appreciate using it or SourceTree.


Please ask for more git help if you like.  Many people on the list know it
well, and happy to help your productivity.
(I appreciate the issues you find and fix!)


On Mon, Mar 13, 2017 at 6:49 PM, Christian Schulte  wrote:

> Am 03/11/17 um 22:56 schrieb Stephen Connolly:
> > Hi all,
> >
> > I think it is a good thing if we take stock of where we are and how we
> are
> > doing. I would really appreciate if everyone could take a few minutes to
> > respond with their top three of two areas:
> >
> > * What is working well
>
> The Jenkins support has improved greatly. For me it's very cool to have
> the ITs run on Java 7+8 - Linux+Windows. Too few operating systems.
> Solaris is a must have. OS X would be nice to have. FreeBSD or OpenBSD
> also nice to have.
>
> > * What is not working well
>
> Turns out I just will never become a GIT fan. What works best for me has
> been Subversion on the server and GIT locally using git-svn. Very clean
> history on the Subversion server side because you can clean up commits
> locally (squash, reword, etc.) before committing to the Subversion
> repository. I find it quite hard to follow the commit history in GIT.
> The date of the commit is not the date it got committed to master, but
> the date it got committed to some branch, no longer existing after the
> commit. If this is the way GIT works, so be it. I just don't like it. It
> could not be more confusing.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Retrospective on Maven 3.5.0-alpha-1

[Christian Schulte]

Am 03/11/17 um 22:56 schrieb Stephen Connolly:
> Hi all,
> 
> I think it is a good thing if we take stock of where we are and how we are
> doing. I would really appreciate if everyone could take a few minutes to
> respond with their top three of two areas:
> 
> * What is working well

The Jenkins support has improved greatly. For me it's very cool to have
the ITs run on Java 7+8 - Linux+Windows. Too few operating systems.
Solaris is a must have. OS X would be nice to have. FreeBSD or OpenBSD
also nice to have.

> * What is not working well

Turns out I just will never become a GIT fan. What works best for me has
been Subversion on the server and GIT locally using git-svn. Very clean
history on the Subversion server side because you can clean up commits
locally (squash, reword, etc.) before committing to the Subversion
repository. I find it quite hard to follow the commit history in GIT.
The date of the commit is not the date it got committed to master, but
the date it got committed to some branch, no longer existing after the
commit. If this is the way GIT works, so be it. I just don't like it. It
could not be more confusing.

Regards,
-- 
Christian


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

Contributing Javadoc (was Re: [DISCUSS] Retrospective on Maven 3.5.0-alpha-1)

[Christian Schulte]

Am 03/13/17 um 23:22 schrieb Laird Nelson:
> On Mon, Mar 13, 2017 at 2:26 PM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
> 
> Gentle reminder. If you can see this thread, you are entitled to
> contribute. This thread is about discovering where the Maven project can
> improve how we work in order to grow our community.
> 
> I'll bite.  (I can see the dev list, but I don't think I have commit
> privileges.)
> 
> One of the ways that I would like to contribute is to improve Javadoc
> throughout the core of Maven.  Even documenting simple things—like what the
> difference between an artifact and a dependency is—could go a long ways
> towards improving Maven's standing in the world.  What would be the best
> way to do this?

Just create corresponding issues in JIRA and either attach patch files
there or add links to Github pull requests there. Can be any public git
repository. The apache repositories are synced to Github just for
convenience.

Regards,
-- 
Christian


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

Re: New Branch SUREFIRE-1342

[Tibor Digana]

We have performance tests. This means your machine should run only this
build. The GC may affect the success therefore my fine tuning is
MAVEN_OPTC=-server -Xmx768m -XX:MaxMetaspaceSize=864m.
Of course MaxMetaspaceSize is available in JDK8. Use MaxPemSize in JDK7 or
JDK6.
The ideal would be to have 4 Core CPU x64, SSD where the build takes only
45 minutes.
$ mvn -P run-its install

On Mon, Mar 13, 2017 at 11:04 PM, Guillaume Boué  wrote:

> Hi,
>
> I finished setting up a FreeBSD VM with a couple of Maven and JDK
> versions, so I'll be testing this extensively (on Ubuntu as well). Thanks
> for the work!
>
> Guillaume
>
>
>
> Le 13/03/2017 à 10:46, Tibor Digana a écrit :
>
>> Hi All,
>>
>> The new branch SUREFIRE-1342 solves an issue when entire testset completed
>> however the surefire's forked JVM  finished printing serious issue. We
>> know
>> that the JVM did not crash however it looks so:
>>
>> The forked VM terminated without saying properly goodbye. VM crash or
>> System.exit called ?
>>
>>
>> The problem is solved in the branch and ready to be tested.
>>
>> The entire problem was concurrency issue where the forked JVM sent "bye"
>> event to the Maven process via stdout but Maven process has not drained
>> shared memory yet and Maven process was therefore slower to receive the
>> event than the forked process which exited. Due to the "bye" event was not
>> determined by Maven process in particular time, this error came up.
>> We implemented ACK command which confirms such event has been received by
>> Maven process. The shared memory is drained directly by Maven process.
>>
>> Cheers
>> Tibor
>>
>>
>
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le
> logiciel antivirus Avast.
> https://www.avast.com/antivirus
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Cheers
Tibor

Re: [ANN] GitPubSub multi-branch notification now working on builds.apache.org

[Stephen Connolly]

Not yet

On Mon 13 Mar 2017 at 22:15, Guillaume Boué  wrote:

> How does this play with pull requests on GitHub?
>
> Guillaume
>
>
> Le 12/03/2017 à 09:59, Stephen Connolly a écrit :
> > My weekend project:
> https://github.com/stephenc/asf-gitpubsub-jenkins-plugin
> > was a success
> >
> > (Need to find a home for it at the ASF (as it doesn't make sense at
> Jenkins
> > / outside of ASF)
> >
> > Now when you push a change to maven.git the branch / commit should
> trigger
> > a build within seconds.
> >
> > There are still some fine-tunings to further optimize the process, but
> that
> > should shave off the average 7.5 minutes / max 15 minutes we had to wait
> as
> > well as significantly reducing the load on the ASF infra.
> >
> > This same GitPubSub is available to any multibranch based project running
> > off Git hosted on ASF hardware, so if we add Jenkinsfile to surefire, etc
> > they will get it too
> >
> > (Next project is getting better email notification and JIRA integration
> for
> > pipeline jobs)
> >
> > -Stephen
> >
>
>
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le
> logiciel antivirus Avast.
> https://www.avast.com/antivirus
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: [DISCUSS] Retrospective on Maven 3.5.0-alpha-1

[Laird Nelson]

On Mon, Mar 13, 2017 at 2:26 PM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

Gentle reminder. If you can see this thread, you are entitled to
contribute. This thread is about discovering where the Maven project can
improve how we work in order to grow our community.

I'll bite.  (I can see the dev list, but I don't think I have commit
privileges.)

One of the ways that I would like to contribute is to improve Javadoc
throughout the core of Maven.  Even documenting simple things—like what the
difference between an artifact and a dependency is—could go a long ways
towards improving Maven's standing in the world.  What would be the best
way to do this?

Best,
Laird

Re: [DISCUSS] Retrospective on Maven 3.5.0-alpha-1

[Tibor Digana]

>>What is working well
1. Maven still continues developing new visions and milestones.
2. The discipline to start code review of a branch.
3. Jenkinsfile + automatically tested branches

>>What is not working well
1. long discussions on ML.
I would like to kindly ask you to prefer Pull Requests in GitHub and put
your comments directly on the code itself.
2. missing FreeBSD or Solaris, OSX in our CI


On Mon, Mar 13, 2017 at 10:26 PM, stephenconnolly [via Maven] <
ml-node+s40175n5901835...@n5.nabble.com> wrote:

> Gentle reminder. If you can see this thread, you are entitled to
> contribute. This thread is about discovering where the Maven project can
> improve how we work in order to grow our community.
>
> Everyone's opinions are welcome...
>
> We just ask that at this phase you just provide up to 3 sentences on areas
> where we work well and up to 3 sentences on areas where we don't (in your
> view of the order of importance)
>
> On 11 March 2017 at 21:56, Stephen Connolly <[hidden email]
> 
> > wrote:
>
> > Hi all,
> >
> > I think it is a good thing if we take stock of where we are and how we
> are
> > doing. I would really appreciate if everyone could take a few minutes to
> > respond with their top three of two areas:
> >
> > * What is working well
> >
> > * What is not working well
> >
> > I'll consolidate the responses after 72h and see if there are any themes
> > that can be identified
> >
> > On the stuff that is not working well, I'll try and pick the three most
> > popular themes, we can then have a round of discussion on those three
> > themes to see if anyone has any ideas to improve those aspects of how we
> > work and hopefully we can have some votes to change things for the
> better.
> >
> > By the way, this is open to anyone in any way what so ever involved with
> > the Maven 3.5.0-alpha-1 effort (assuming you are paying attention to the
> > dev list ;-) )
> >
> > Thanks in advance for your time,
> >
> > -Stephen
> >
> > P.S. As alpha-2 is near, I'll probably wait until after 3.5.0 before I
> try
> > this again (assuming people like this idea)
> >
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/DISCUSS-Retrospective-on-
> Maven-3-5-0-alpha-1-tp5901602p5901835.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://maven.40175.n5.nabble.com/DISCUSS-Retrospective-on-Maven-3-5-0-alpha-1-tp5901602p5901861.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: [ANN] GitPubSub multi-branch notification now working on builds.apache.org

[Guillaume Boué]

How does this play with pull requests on GitHub?

Guillaume


Le 12/03/2017 à 09:59, Stephen Connolly a écrit :

My weekend project: https://github.com/stephenc/asf-gitpubsub-jenkins-plugin
was a success

(Need to find a home for it at the ASF (as it doesn't make sense at Jenkins
/ outside of ASF)

Now when you push a change to maven.git the branch / commit should trigger
a build within seconds.

There are still some fine-tunings to further optimize the process, but that
should shave off the average 7.5 minutes / max 15 minutes we had to wait as
well as significantly reducing the load on the ASF infra.

This same GitPubSub is available to any multibranch based project running
off Git hosted on ASF hardware, so if we add Jenkinsfile to surefire, etc
they will get it too

(Next project is getting better email notification and JIRA integration for
pipeline jobs)

-Stephen




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: New Branch SUREFIRE-1342

[Guillaume Boué]

Hi,

I finished setting up a FreeBSD VM with a couple of Maven and JDK 
versions, so I'll be testing this extensively (on Ubuntu as well). 
Thanks for the work!


Guillaume


Le 13/03/2017 à 10:46, Tibor Digana a écrit :

Hi All,

The new branch SUREFIRE-1342 solves an issue when entire testset completed
however the surefire's forked JVM  finished printing serious issue. We know
that the JVM did not crash however it looks so:

The forked VM terminated without saying properly goodbye. VM crash or
System.exit called ?


The problem is solved in the branch and ready to be tested.

The entire problem was concurrency issue where the forked JVM sent "bye"
event to the Maven process via stdout but Maven process has not drained
shared memory yet and Maven process was therefore slower to receive the
event than the forked process which exited. Due to the "bye" event was not
determined by Maven process in particular time, this error came up.
We implemented ACK command which confirms such event has been received by
Maven process. The shared memory is drained directly by Maven process.

Cheers
Tibor




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [DISCUSS] Retrospective on Maven 3.5.0-alpha-1

[Guillaume Boué]

What is working well:

1. Despite the mess that resulted in the birth of 3.5.0, the project was 
set back on track successfully.
2. There is good feedback on the version, which sets up solid grounds 
for the future.

3. Not the only one for this point but... colorized logging is truly great!

What is not working well:

1. We don't have a proper testing protocol (locally before Jenkins, 
which OS, which JDK versions...)
2. Still lacking some discussions, notably on the issues that sparked 
the reset.
3. There are still a lot of untriaged JIRA issues, for the core, the 
plugins or other components. We might need a plan on how to handle them.


Guillaume


Le 11/03/2017 à 22:56, Stephen Connolly a écrit :

Hi all,

I think it is a good thing if we take stock of where we are and how we are
doing. I would really appreciate if everyone could take a few minutes to
respond with their top three of two areas:

* What is working well

* What is not working well

I'll consolidate the responses after 72h and see if there are any themes
that can be identified

On the stuff that is not working well, I'll try and pick the three most
popular themes, we can then have a round of discussion on those three
themes to see if anyone has any ideas to improve those aspects of how we
work and hopefully we can have some votes to change things for the better.

By the way, this is open to anyone in any way what so ever involved with
the Maven 3.5.0-alpha-1 effort (assuming you are paying attention to the
dev list ;-) )

Thanks in advance for your time,

-Stephen

P.S. As alpha-2 is near, I'll probably wait until after 3.5.0 before I try
this again (assuming people like this idea)




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [DISCUSS] Retrospective on Maven 3.5.0-alpha-1

[Stephen Connolly]

Gentle reminder. If you can see this thread, you are entitled to
contribute. This thread is about discovering where the Maven project can
improve how we work in order to grow our community.

Everyone's opinions are welcome...

We just ask that at this phase you just provide up to 3 sentences on areas
where we work well and up to 3 sentences on areas where we don't (in your
view of the order of importance)

On 11 March 2017 at 21:56, Stephen Connolly  wrote:

> Hi all,
>
> I think it is a good thing if we take stock of where we are and how we are
> doing. I would really appreciate if everyone could take a few minutes to
> respond with their top three of two areas:
>
> * What is working well
>
> * What is not working well
>
> I'll consolidate the responses after 72h and see if there are any themes
> that can be identified
>
> On the stuff that is not working well, I'll try and pick the three most
> popular themes, we can then have a round of discussion on those three
> themes to see if anyone has any ideas to improve those aspects of how we
> work and hopefully we can have some votes to change things for the better.
>
> By the way, this is open to anyone in any way what so ever involved with
> the Maven 3.5.0-alpha-1 effort (assuming you are paying attention to the
> dev list ;-) )
>
> Thanks in advance for your time,
>
> -Stephen
>
> P.S. As alpha-2 is near, I'll probably wait until after 3.5.0 before I try
> this again (assuming people like this idea)
>

Re: Timeline for 3.5.0-alpha-2 / MNG-6057

[Christian Schulte]

Am 03/13/17 um 08:33 schrieb Hervé BOUTEMY:
>> The flatten-maven-plugin solution appears to me like a workaround for
>> some missing support in Maven core. Also a good reason to split build
>> pom from deployed pom. Maybe all of this better be postponed to model
>> version 5.0.0?
> splitting build pom from deployed (or consumer) pom IMHO is:
> 1. not a workaround
> 2. exactly what we need *before* working on model 5.0.0

I did not object to anything. I am just wondering how compatible that is
to that "the model version 4.0.0 ship has sailed" statement. If a pom
gets deployed to central using a version expression, no one can consume
such a project. The warnings about "version must be a constant" were
there for a reason. Allowing just a few expressions is not different to
allowing all kinds of expressions. We could allow expressions in
versions like in Maven 2 again and make that a supported feature, if
Maven core can deal with it correctly (by never allowing anything like
that to appear in any repository).

Regards,
-- 
Christian


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

[GitHub] maven pull request #108: Added some javadoc

[LuboVarga]

GitHub user LuboVarga opened a pull request:

https://github.com/apache/maven/pull/108

Added some javadoc

Added javadoc help for making easier to compare two versions in command 
line.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/LuboVarga/maven patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven/pull/108.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #108


commit 10a18cfee7a981a41c1f571ef3c60138d40e839e
Author: LuboVarga 
Date:   2017-03-13T12:23:04Z

Added some javadoc

Added javadoc help for making easier to compare two versions in command 
line.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

New Branch SUREFIRE-1342

[Tibor Digana]

Hi All,

The new branch SUREFIRE-1342 solves an issue when entire testset completed
however the surefire's forked JVM  finished printing serious issue. We know
that the JVM did not crash however it looks so:

The forked VM terminated without saying properly goodbye. VM crash or
System.exit called ?


The problem is solved in the branch and ready to be tested.

The entire problem was concurrency issue where the forked JVM sent "bye"
event to the Maven process via stdout but Maven process has not drained
shared memory yet and Maven process was therefore slower to receive the
event than the forked process which exited. Due to the "bye" event was not
determined by Maven process in particular time, this error came up.
We implemented ACK command which confirms such event has been received by
Maven process. The shared memory is drained directly by Maven process.

Cheers
Tibor

Re: Timeline for 3.5.0-alpha-2 / MNG-6057

[Hervé BOUTEMY]

> The flatten-maven-plugin solution appears to me like a workaround for
> some missing support in Maven core. Also a good reason to split build
> pom from deployed pom. Maybe all of this better be postponed to model
> version 5.0.0?
splitting build pom from deployed (or consumer) pom IMHO is:
1. not a workaround
2. exactly what we need *before* working on model 5.0.0

Regards,

Hervé

Le lundi 13 mars 2017, 02:00:24 CET Christian Schulte a écrit :
> Am 03/12/17 um 15:36 schrieb Karl Heinz Marbaise:
> > Hi,
> > 
> > So after I finalized the implementation which seemed to be ok for
> > now...the IT's are currently not working based on particular reason
> > (explanations later).
> > 
> > I would like to know the opinion of the Maven DEV's about this:
> > 
> > The following scenario:
> > 
> > This feature has been introduced in Maven 3.2.1 but with some issues
> > (ordering in reactor etc.).
> > 
> > By using this branch MNG-6057 (MNG-6090, MNG-5895) you can use things
> > like ${revision}, ${sha1} and/or ${changelist} in your version tag of
> > your pom.
> > This means you can define the revision by simply using it for the whole
> > multi module build (also for a single project) and you can defined a
> > revision of your artifacts by simply using a property in your pom file
> > (only a single one). Take a look at an example[1].
> > 
> > You can build everything. It is also possible to overwrite the revision
> > via command line like this: mvn clean package -Drevision=2.4.5 or using
> > .mvn/maven.config file..for this instead of using the pom file property.
> > 
> > The only thing which is cirtical from my point of view if you will do an
> > mvn install or mvn deploy...
> > 
> > The problem is simply that at the moment the pom's which will be
> > installed into local cache or in a remote repository having the
> > ${revision} etc. in their version tag and the placeholders
> > revision,sha1,changelist are not being replaced with the current literal
> > version.
> 
> This is a very long standing issue. Quite a lot of people gave up on
> some "feature" because it lead to non-deployable projects.
> 
> > This can be solved by using the flatten-maven-plugin (I think this
> > should be integrated into Maven itself in the furture maybe in Maven
> > 3.6.0?? but this is a different story.).
> > 
> > If you take this change you can define the version of your build
> > artifacts either by command line or with a single property which several
> > people asked for...which would make it very convenient to build
> > different branches by using different versions ...etc.
> > 
> > This leaves some questions from my side:
> > 
> > 1. How can I use the flatten-maven-plugin inside the IT's ? (It looks
> > like I oversight something here).
> > 
> > 2. WDYT about? Should I postpone that and improve the solution?
> 
> I would go for improving this until everything has landed in Maven core
> and Maven gets the job done automatically without anyone having to setup
> some special plugins changing the in memory effective model temporarily.
> The flatten-maven-plugin solution appears to me like a workaround for
> some missing support in Maven core. Also a good reason to split build
> pom from deployed pom. Maybe all of this better be postponed to model
> version 5.0.0?
> 
> > 3. Should I integrate the current state into the current 3.5.0-alpha-2 ?
> 
> Commit it now, and you will never have a chance to improve the solution
> later. Once released, it's nearly impossible to even fix a simple bug
> ;-) If it got released with Maven 3.3.9, things already are messed up
> and I wonder how this could get released when even simple bugfixes were
> reverted lately.
> 
> Regards,



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