Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Stephen Connolly]

I've been thinking about what to call the "consumer Pom"...

I think this is actually not a project object model, but the project
dependency trees

It should list each side artifact and their dependency trees...

So for example:

* the java doc artifacts should depend on the corresponding dependency java
doc artifacts (in an ideal world) because we expect {@link} references

* the source artifacts do not depend on anything else (normally) but for an
über jar (which yes is a bad pattern) you would actually be correct to
depend on the bundled artifacts source jars... So the concept still makes
sense

* the test jar artifact would have the full test dependency tree exposed as
this would allow for test reuse

Now I guess the question is if .pdt or .adt (artifact dependency trees) are
too entrenched in some other domain that we'd want to avoid using one
of those extensions

Next steps:

* start fleshing out a schema for the .pdt files
* start fleshing out a spec for the repository layout (should be "parsable"
by modelVersion 4.0.0 aware clients, but need to decide how to expose new
features)

On Tuesday 30 August 2016, Stephen Connolly 
wrote:

> On 29 August 2016 at 23:27, 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.
>>
>
> So the way I see this, different types of artifacts have different tree
> requirements.
>
> I may have one type of artifact (i.e. jar) where it really is not
> supported to have multiple versions of the same artifact on the same
> classpath at the same time.
>
> We currently view artifact dependency resolution as building a linear path
> from the dependency tree based on the assumption of single version of any
> dependency.
>
> In the JavaScript world... and even in the OSGi world... that assumption
> is simply not true.
>
> This implies - to me - that the consumer pom should contain the tree that
> was used at build time... *as a tree*
>
> By all means, each node could include the version range as well as the
> resolved version, e.g.
>
>  classifier="..." type="..." version="[1.0,2.0)" resolvedVersion="1.5.0">
>classifier="..." type="..." version="..." resolvedVersion="...">
> ...
>   
>   ...
>classifier="..." type="..." version="..." resolvedVersion="..."/>
> 
>
> The child elements are the dependencies of the resolved version.
>
> Now the consumer of the consumer pom has all the dependency information
> used at build time as well as the information to perform substitutions...
>
> This means that if I - as a consumer - am already pulling in a different
> resolvedVersion (but valid within the advertised range) of a child
> dependency and I am using the tree to produce a single-version classpath, I
> can prune the tree and know I have removed the unrequired dependencies.
>
> If I - as a consumer - need to produce a multi-version classpath - because
> I am producing for an OSGi container - I can build the correct tree rather
> than being forced to look at a flattened classpath that may not be aligned
> with the requirements of the dependency system I am using
>
> If I - as a consumer - decide that I want to push the ranges to newer, we
> still have the range information to allow for range validation... but by
> default I will be using the versions that were resolved at build time and
> consequently tested with by the builder.
>
> HTH
>
> -Stephen
>
>
>>
>> Regards,
>> --
>> Christian
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> 
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>>
>>
>

-- 
Sent from my phone

JUnit categories in surefire/failsafe

[Christopher]

tl;dr - A proposal for config independence for groups/excludeGroups
properties and some special keywords for ALL, NONE, and UNCATEGORIZED
groups.

***

In the Apache Accumulo project, we're currently in process of trying to
make use of JUnit categories to separate different classes of tests.

So, we're using the maven-surefire-plugin and maven-failsafe-plugin
configuration properties: groups, excludeGroups

One thing we noticed was that the user property is the same for both
plugins. This is a problem, because one cannot pass in a system property on
the command-line to affect one without affecting the other.

I propose that maven-surefire-plugin and maven-failsafe-plugin deprecate
the existing groups/excludeGroups properties, and replace them with
tests.groups/tests.excludeGroups, and it.groups/it.excludeGroups. (This
should probably be done for other shared properties as well.)

Users can simulate this by doing something like this:
${it.groups}

However, this may cause problems if the property is not defined I
haven't tested to be sure.

***

That leads me to a question and a second proposal:
Is there a way to specify uncategorized test classes? Or all test classes?
Or none?

If not, I would like to propose that some special keywords be created which
can represent:
_ALL_, _NONE_, _UNCATEGORIZED_ (or similar)

That way, users can do things like:
my.special.Category,_UNCATEGORIZED_
_NONE_
or
_NONE_
or
_ALL_

These keywords may require some support from the underlying test framework,
like JUnit, so I can understand if these keywords cannot happen.

Even if the keywords cannot be made to work, I still think it'd be good to
deprecate-and-separate the properties for the two plugins, so they can be
controlled independently with user properties.

Thanks.

Re: [SUREFIRE] Surefire provider for JUnit 5?

[Tibor Digana]

Benedikt, let's go to IRC freenode.net for developers.

On Tue, Aug 30, 2016 at 10:44 PM, Tibor Digana 
wrote:

> I would like to help you but currently I can't because I am in hurry with
> release and few issues and then I have to fix one IT in Surefire 3.0 which
> fails because of unresolved transitive dependencies. So this may take some
> time for me.
>
> On Tue, Aug 30, 2016 at 10:06 PM, Benedikt Ritter [via Maven] <
> ml-node+s40175n587945...@n5.nabble.com> wrote:
>
> > Hello Tibor,
> >
> > Tibor Digana <[hidden email]
> > > schrieb am Mo.,
> > 29. Aug. 2016 um
> > 12:56 Uhr:
> >
> > > Hi Benedikt,
> > >
> > > I found out that JUNit 5 was release with ALPHA version in Maven
> > Central.
> > > I guess there is no need to rush in Surefire yet.
> > > The JUnit team should contribute in JUnit code line in the artifact
> > > project org.junit.surefire-junit5 and test that provider. AFter the it
> > > is stable with non-alpha and non-beta version we can take over, but
> > > the next question would be license of JUnit 5.
> > >
> >
> > I think the team has enough to do with getting JUnit 5 out of the door.
> > That's why they would be happy if the provider would be moved to the
> maven
> > project.
> >
> >
> > > JUnit 5 is developed with license Eclipse Public License v1.0.
> > > We can accept ASF 2.0 license.
> > > See http://repo1.maven.org/maven2/org/junit/surefire-junit5/
> > >
> > >
> > EPL falls under the category of weak-copy left licenses. So this may be
> an
> > issue [1]. Would probably be best to check with legal before importing
> any
> > code.
> >
> > Regards,
> > Benedikt
> >
> > [1] http://www.apache.org/legal/resolved.html#category-b
> >
> >
> > > --
> > > Cheers
> > > Tibor
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > > http://maven.40175.n5.nabble.com/SUREFIRE-Surefire-
> provider-for-JUnit-5-
> > tp5879054p5879245.html
> > > Sent from the Maven Developers mailing list archive at Nabble.com.
> >
> >
> > --
> > If you reply to this email, your message will be added to the discussion
> > below:
> > http://maven.40175.n5.nabble.com/SUREFIRE-Surefire-provider-for-JUnit-5-
> > tp5879054p5879457.html
> > To start a new topic under Maven Developers, email
> > ml-node+s40175n142166...@n5.nabble.com
> > To unsubscribe from Maven Developers, click here
> >  macro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3
> wxNDIxNjZ8LTI4OTQ5MjEwMg==>
> > .
> > NAML
> >  macro=macro_viewer=instant_html%21nabble%3Aemail.naml&
> base=nabble.naml.namespaces.BasicNamespace-nabble.view.
> web.template.NabbleNamespace-nabble.view.web.template.
> NodeNamespace=notify_subscribers%21nabble%
> 3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_
> instant_email%21nabble%3Aemail.naml>
> >
>
>
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.
> com/SUREFIRE-Surefire-provider-for-JUnit-5-tp5879054p5879471.html
> Sent from the Maven Developers mailing list archive at Nabble.com.
>

Re: [SUREFIRE] Surefire provider for JUnit 5?

[Tibor Digana]

I would like to help you but currently I can't because I am in hurry with
release and few issues and then I have to fix one IT in Surefire 3.0 which
fails because of unresolved transitive dependencies. So this may take some
time for me.

On Tue, Aug 30, 2016 at 10:06 PM, Benedikt Ritter [via Maven] <
ml-node+s40175n587945...@n5.nabble.com> wrote:

> Hello Tibor,
>
> Tibor Digana <[hidden email]
> > schrieb am Mo.,
> 29. Aug. 2016 um
> 12:56 Uhr:
>
> > Hi Benedikt,
> >
> > I found out that JUNit 5 was release with ALPHA version in Maven
> Central.
> > I guess there is no need to rush in Surefire yet.
> > The JUnit team should contribute in JUnit code line in the artifact
> > project org.junit.surefire-junit5 and test that provider. AFter the it
> > is stable with non-alpha and non-beta version we can take over, but
> > the next question would be license of JUnit 5.
> >
>
> I think the team has enough to do with getting JUnit 5 out of the door.
> That's why they would be happy if the provider would be moved to the maven
> project.
>
>
> > JUnit 5 is developed with license Eclipse Public License v1.0.
> > We can accept ASF 2.0 license.
> > See http://repo1.maven.org/maven2/org/junit/surefire-junit5/
> >
> >
> EPL falls under the category of weak-copy left licenses. So this may be an
> issue [1]. Would probably be best to check with legal before importing any
> code.
>
> Regards,
> Benedikt
>
> [1] http://www.apache.org/legal/resolved.html#category-b
>
>
> > --
> > Cheers
> > Tibor
> >
> >
> >
> >
> > --
> > View this message in context:
> > http://maven.40175.n5.nabble.com/SUREFIRE-Surefire-provider-for-JUnit-5-
> tp5879054p5879245.html
> > Sent from the Maven Developers mailing list archive at Nabble.com.
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/SUREFIRE-Surefire-provider-for-JUnit-5-
> tp5879054p5879457.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/SUREFIRE-Surefire-provider-for-JUnit-5-tp5879054p5879471.html
Sent from the Maven Developers mailing list archive at Nabble.com.

[GitHub] maven-surefire pull request #116: Documented multi-lined exception message h...

[cowwoc]

Github user cowwoc closed the pull request at:

https://github.com/apache/maven-surefire/pull/116


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

[GitHub] maven-surefire issue #116: Documented multi-lined exception message handling...

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/116
  
Thank you for your pull request. Let's keep them coming. Pls close it.


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

Re: [SUREFIRE] Surefire provider for JUnit 5?

[Benedikt Ritter]

Hello Tibor,

Tibor Digana  schrieb am Mo., 29. Aug. 2016 um
12:56 Uhr:

> Hi Benedikt,
>
> I found out that JUNit 5 was release with ALPHA version in Maven Central.
> I guess there is no need to rush in Surefire yet.
> The JUnit team should contribute in JUnit code line in the artifact
> project org.junit.surefire-junit5 and test that provider. AFter the it
> is stable with non-alpha and non-beta version we can take over, but
> the next question would be license of JUnit 5.
>

I think the team has enough to do with getting JUnit 5 out of the door.
That's why they would be happy if the provider would be moved to the maven
project.


> JUnit 5 is developed with license Eclipse Public License v1.0.
> We can accept ASF 2.0 license.
> See http://repo1.maven.org/maven2/org/junit/surefire-junit5/
>
>
EPL falls under the category of weak-copy left licenses. So this may be an
issue [1]. Would probably be best to check with legal before importing any
code.

Regards,
Benedikt

[1] http://www.apache.org/legal/resolved.html#category-b


> --
> Cheers
> Tibor
>
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/SUREFIRE-Surefire-provider-for-JUnit-5-tp5879054p5879245.html
> Sent from the Maven Developers mailing list archive at Nabble.com.

[GitHub] maven-surefire pull request #116: Documented multi-lined exception message h...

[cowwoc]

GitHub user cowwoc opened a pull request:

https://github.com/apache/maven-surefire/pull/116

Documented multi-lined exception message handling introduced in versi…

…on 2.19

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

$ git pull https://github.com/cowwoc/maven-surefire multilined-exceptions

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

https://github.com/apache/maven-surefire/pull/116.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 #116


commit f93a37edd52d7c93f2e3dedf17bd772136515d11
Author: Gili Tzabari 
Date:   2016-08-30T19:02:10Z

Documented multi-lined exception message handling introduced in version 2.19




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

Re: Questions about how to contribute to Plexus

[Robert Scholte]

Hi,

all development on Plexus and Modello is done at  
https://github.com/codehaus-plexus
Since Maven is probably one of the few projects still using this, we  
haven't invested in all the infra related stuff like mailinglists, etc.

So we have the sources and the documentation, that's about it.
This project is maintained by a subset of the Apache Maven team, so we can  
fix our own issues.
Best way is to create pull requests there and ping us if you're waiting  
too long for a response.


thanks,
Robert

On Mon, 29 Aug 2016 19:57:19 +0200, Plamen Totev   
wrote:



Hi,

Recently I was granted write access to the plexus-io and plexus-archiver  
GitHub repositories. I'm not sure where I can found any guides for  
contributors. Also I can't found the plexus project mail list - not sure  
where to write if I have questions related to the project. I would love  
to contribute to the project and help it with the maintenance but not  
sure about what to do so I'll be very grateful if you could give me some  
directions where I can get more info or help.


Thanks,

Plamen Totev

-
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

ApacheCon Seville CFP closes September 9th

[Rich Bowen]

It's traditional. We wait for the last minute to get our talk proposals
in for conferences.

Well, the last minute has arrived. The CFP for ApacheCon Seville closes
on September 9th, which is less than 2 weeks away. It's time to get your
talks in, so that we can make this the best ApacheCon yet.

It's also time to discuss with your developer and user community whether
there's a track of talks that you might want to propose, so that you
have more complete coverage of your project than a talk or two.

For Apache Big Data, the relevant URLs are:
Event details:
http://events.linuxfoundation.org/events/apache-big-data-europe
CFP:
http://events.linuxfoundation.org/events/apache-big-data-europe/program/cfp

For ApacheCon Europe, the relevant URLs are:
Event details: http://events.linuxfoundation.org/events/apachecon-europe
CFP: http://events.linuxfoundation.org/events/apachecon-europe/program/cfp

This year, we'll be reviewing papers "blind" - that is, looking at the
abstracts without knowing who the speaker is. This has been shown to
eliminate the "me and my buddies" nature of many tech conferences,
producing more diversity, and more new speakers. So make sure your
abstracts clearly explain what you'll be talking about.

For further updated about ApacheCon, follow us on Twitter, @ApacheCon,
or drop by our IRC channel, #apachecon on the Freenode IRC network.

-- 
Rich Bowen
WWW: http://apachecon.com/
Twitter: @ApacheCon

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

[ANN] Apache Maven Plugin Tools 3.5 Released

[Robert Scholte]

The Apache Maven team is pleased to announce the release of the Apache  
Maven Plugin Tools, version 3.5, including Apache Maven Plugin Plugin 3.5


The Maven Plugin Tools contains the necessary tools to generate  
rebarbative content like descriptor, help and documentation. In addition,  
it provides tools to write Maven Plugins in scripting languages like Ant  
or Beanshell.


The Maven Plugin Plugin is used to create a Maven plugin descriptor for  
any Mojo's found in the source tree, to include in the JAR. It is also  
used to generate report files for the Mojos as well as for updating the  
plugin registry, the artifact metadata and generating a generic help goal.


https://maven.apache.org/plugin-tools/
https://maven.apache.org/plugin-tools/maven-plugin-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-plugin-plugin
  3.5


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins-tools/download.cgi


Release Notes - Maven Plugin Tools - Version 3.5

** Bug
* [MPLUGIN-292] - HelpMojo contains malformed HTML which causes  
javadoc to fail under JDK 8
* [MPLUGIN-296] - java.lang.ClassNotFoundException:  
org.apache.maven.plugins.annotations.Execute

* [MPLUGIN-299] - Help mojo cannot display goal details
* [MPLUGIN-303] - Plugin Plugin breaks when ASM6.0_ALPHA is configured  
as dependency
* [MPLUGIN-307] - The "alias" field on the annotation "@Parameter" is  
not considered for goal "plugin:report"

* [MPLUGIN-309] - Upgrade to maven-parent-30
* [MPLUGIN-310] - PluginReport should use generated plugin.xml by  
default
* [MPLUGIN-312] - maven-plugin-tools-annotations visitors fail  
scanning java8 annotations


** Improvement
* [MPLUGIN-275] - Move LifecycleMapping and ArtifactHandler from  
maven-core to target packaging plugin

* [MPLUGIN-289] - better output when extracting info
* [MPLUGIN-295] - Upgrade Maven Invoker Plugin version to 1.10
* [MPLUGIN-300] - Prepare taglets for Java9
* [MPLUGIN-301] - The text  
http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html  
should be improved

* [MPLUGIN-304] - MojoAnnotationsScanner should ignore special classes
* [MPLUGIN-305] - MojoAnnotationsScanner should have better control  
over dependency scanning


** Task
* [MPLUGIN-288] - refactoring: change plugin-tools' model package to  
org.apache.maven.tools.plugin.extractor.model


Enjoy,

-The Apache Maven team

-
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

[Stephen Connolly]

On 29 August 2016 at 23:27, 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.
>

So the way I see this, different types of artifacts have different tree
requirements.

I may have one type of artifact (i.e. jar) where it really is not supported
to have multiple versions of the same artifact on the same classpath at the
same time.

We currently view artifact dependency resolution as building a linear path
from the dependency tree based on the assumption of single version of any
dependency.

In the JavaScript world... and even in the OSGi world... that assumption is
simply not true.

This implies - to me - that the consumer pom should contain the tree that
was used at build time... *as a tree*

By all means, each node could include the version range as well as the
resolved version, e.g.


  
...
  
  ...
  


The child elements are the dependencies of the resolved version.

Now the consumer of the consumer pom has all the dependency information
used at build time as well as the information to perform substitutions...

This means that if I - as a consumer - am already pulling in a different
resolvedVersion (but valid within the advertised range) of a child
dependency and I am using the tree to produce a single-version classpath, I
can prune the tree and know I have removed the unrequired dependencies.

If I - as a consumer - need to produce a multi-version classpath - because
I am producing for an OSGi container - I can build the correct tree rather
than being forced to look at a flattened classpath that may not be aligned
with the requirements of the dependency system I am using

If I - as a consumer - decide that I want to push the ranges to newer, we
still have the range information to allow for range validation... but by
default I will be using the versions that were resolved at build time and
consequently tested with by the builder.

HTH

-Stephen


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

[RESULT] [VOTE] Release Apache Maven Plugin Tools version 3.5

[Robert Scholte]

Hi,

The vote has passed with the following result:

+1 : Robert Scholte, Karl Heinz Marbaise, Tibor Digana, Hervé BOUTEMY

PMC quorum: reached

I will promote the artifacts to the central repo.


On Sat, 27 Aug 2016 00:40:42 +0200, Robert Scholte   
wrote:



Hi,

We solved 16 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317820=12331169=Text

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317820%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1286
https://repository.apache.org/content/repositories/maven-1286/org/apache/maven/plugin-tools/maven-plugin-tools/3.5/maven-plugin-tools-3.5-source-release.zip

Source release checksum(s):
maven-plugin-tools-3.5-source-release.zip sha1:  
1c36a5e66cd4f0305050559e98c9a06d45bf5a6b

Staging site:
https://maven.apache.org/plugin-tools-archives/plugin-tools-LATEST/index.html

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

-
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