RE: [EXTERNAL] [ANN] Apache Maven Version 3.5.0-alpha-1 Released

[Justin Georgeson]

Thanks for all the hard work that goes into maintaining and improving the tool!

Any chance the Aether work would somehow enable declaring server credentials 
only once in settings.xml and then reusing them for multiple 
build.repositories.repository nodes in pom.xml (such as when you have multiple 
independent repositories within the same authentication realm of a single 
host)? 

-Original Message-
From: stephen.alan.conno...@gmail.com [mailto:stephen.alan.conno...@gmail.com] 
On Behalf Of Stephen Connolly
Sent: Wednesday, March 1, 2017 11:10 AM
To: annou...@maven.apache.org; Maven Users List 
Cc: Maven Developers List 
Subject: [EXTERNAL] [ANN] Apache Maven Version 3.5.0-alpha-1 Released

External Sender: Use caution with links/attachments.



The Apache Maven team would like to announce the release of Maven 3.5.0-alpha-1.

https://urldefense.proofpoint.com/v2/url?u=http-3A__maven.apache.org_=DwIBaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=lM1dtQUOVnlEbaG-BvvxiSaA84FnZZtxyGWvRz4um_E=uxDjp7NPkWNGHWVqZzg9bAu8heEy1B3ZwWbXgvLKq7A=

NOTE: This is an ALPHA release. There is the potential that features may be 
added/removed between this release and the first GA release in the 3.5.x 
release line.
Please consult the Known Issues section below before use

You can download the appropriate sources, etc. from the archives section on the 
download page as Maven 3.3.9 is still the recommended GA release

https://urldefense.proofpoint.com/v2/url?u=https-3A__archive.apache.org_dist_maven_maven-2D3_3.5.0-2Dalpha-2D1_=DwIBaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=lM1dtQUOVnlEbaG-BvvxiSaA84FnZZtxyGWvRz4um_E=LedMpLI_nCjtY6oTmjvQ1eaJJf3HSz1rSRm8mMNENzc=

Known Issues

The following issues were identified during release testing of this ALPHA 
release but have not been deemed as release blockers:

* [MNG-6177] The `--file` and `-f` option to specify a `pom.xml` to use does 
not work if the path includes characters that need quoting such as whitespace 
or `&`.
* [MNG-6115] If Maven is installed in a writable location, every build will 
create a new `lib/ext/jansi-` file.

Why not Maven 3.4.0?

After Maven 3.3.9 was released, the Eclipse Aether project was retired and the 
code base was migrated to the Apache Maven project.

The original goal for the 3.4.0 release was to replace Aether with the exact 
same code after migration to the Apache Maven project and then proceed with bug 
fixes to the resolver code as well as other areas of Maven.

The migration of the code between the two foundations took longer than expected 
and as a result there were other changes committed to Maven core that were 
outside the scope of intent for 3.4.0.

In order to refocus on the original intent for 3.4.0, the decision was taken to 
revert the Maven core history to the point of the 3.3.9 release and merge in 
the desired changes one at a time.

Because there had been a lot of communication about different features being 
delivered and bugs fixed in Maven 3.4.0 and the new history may not contain 
them in the first release, the decision was taken to forever burn the 3.4.x 
release line.

More detail on this decision can be read in the [mailing list archive]( 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail-2Darchive.com_dev-40maven.apache.org_msg112103.html=DwIBaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=lM1dtQUOVnlEbaG-BvvxiSaA84FnZZtxyGWvRz4um_E=400J7D2MFpk6_R1xoqNaJueydenDV3DM0eRrVoejMp4=
 ).


Release Notes - Maven - Version 3.5.0-alpha-1

Bugs:
* [MNG-5297] - Site should tell 'prerequisites.maven is deprecated'
* [MNG-5368] - UnsupportedOperationException thrown when version range is 
not correct in dependencyManagement definitions
* [MNG-5629] - ClosedChannelException from DefaultUpdateCheckManager.read
* [MNG-5815] - "mvn.cmd" does not indicate failure properly when using "&&"
* [MNG-5823] - mvnDebug doesn't work with M2_HOME with spaces - missing 
quotes
* [MNG-5829] - mvn shell script fails with syntax error on Solaris 10
* [MNG-5836] - logging config is overridden by $M2_HOME/lib/ext/*.jar
* [MNG-5852] - mvn shell script invokes /bin/sh but requires Bash functions
* [MNG-5958] - java.lang.String cannot be cast to 
org.apache.maven.lifecycle.mapping.LifecyclePhase
* [MNG-5961] - Maven possibly not aware of log4j2
* [MNG-5962] - mvn.cmd fails when the current directory has spaces in 
between
* [MNG-5963] - mvn.cmd does not return ERROR_CODE
* [MNG-6022] - mvn.cmd fails if directory contains an ampersand (&)
* [MNG-6053] - Unsafe System Properties copy in MavenRepositorySystemUtils, 
causing NPEs
* [MNG-6105] -
properties.internal.SystemProperties.addSystemProperties() is not really 
thread-safe
* [MNG-6109] - PluginDescriptor doesn't read since value of parameter
   

Re: Defining a property designed to be overridden?

[Curtis Rueden]

Hi,

> Note how this is a module of the root project and therefore it'd be
> redundant to have to re-specify all of the information such as the
> contributors, SCM location [0], etc. I only provide the information
> that's specific to that module such as the OSGi manifest,
> dependencies, etc.

If what you want is to ensure the property is simply non-empty, or matching
a particular regex, then take a look at the requireProperty enforcer rule
[1].

Or if your goal is to make sure that a property value _differs_ from the
value defined in an ancestor, the requirePropertyDiverges rule [2] might be
for you.

In my case, I really wanted to make sure that all those properties were
(re)defined in the child POM, because otherwise, it was too easy for
downstream developers to accidentally forget to override things propertly.
E.g., the parent POM defines  as the issue tracker for
that parent POM itself—but this should never be inherited by the child;
instead, every child should define its own  for its own
issue tracker. (If you don't have an issue tracker, you can write
None to satisfy the
enforcer.)

Regards,
Curtis

[1] https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
[2] http://www.mojohaus.org/extra-enforcer-rules/
requirePropertyDiverges.html

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/


On Wed, Mar 1, 2017 at 2:17 PM,  wrote:

> On 2017-03-01T12:46:45 -0600
> Curtis Rueden  wrote:
> >
> > In this way, I ensure that all projects which extend our parent add all
> the
> > useful metadata and properties needed for successful builditude.
> >
>
> Hm, slight issue with this.
>
> If you take a look at how my projects are usually designed:
>
>   https://github.com/io7m/jtensors/blob/develop/pom.xml
>
> That's the root pom for the project. It defines all of the project's
> information such as plugin versions, dependency versions, metadata such
> as the SCM location, site, etc.
>
> Then, each module looks like this:
>
>   https://github.com/io7m/jtensors/blob/develop/io7m-jtensors-core/pom.xml
>
> Note how this is a module of the root project and therefore it'd be
> redundant to have to re-specify all of the information such as the
> contributors, SCM location [0], etc. I only provide the information
> that's specific to that module such as the OSGi manifest, dependencies,
> etc.
>
> Using the scijava-maven-plugin RequireElements rule would seem to
> require me to specify all of this information again in each module.
> Is there a way to avoid this?
>
> M
>
> [0] Although I do actually have to re-specify the SCM location due to
> an utterly ancient bug/design flaw in the site plugin.
>

Re: Defining a property designed to be overridden?

[org . apache . maven . user]

On 2017-03-01T12:46:45 -0600
Curtis Rueden  wrote:
> 
> In this way, I ensure that all projects which extend our parent add all the
> useful metadata and properties needed for successful builditude.
> 

Hm, slight issue with this.

If you take a look at how my projects are usually designed:

  https://github.com/io7m/jtensors/blob/develop/pom.xml

That's the root pom for the project. It defines all of the project's
information such as plugin versions, dependency versions, metadata such
as the SCM location, site, etc.

Then, each module looks like this:

  https://github.com/io7m/jtensors/blob/develop/io7m-jtensors-core/pom.xml

Note how this is a module of the root project and therefore it'd be
redundant to have to re-specify all of the information such as the
contributors, SCM location [0], etc. I only provide the information
that's specific to that module such as the OSGi manifest, dependencies,
etc.

Using the scijava-maven-plugin RequireElements rule would seem to
require me to specify all of this information again in each module.
Is there a way to avoid this?

M

[0] Although I do actually have to re-specify the SCM location due to
an utterly ancient bug/design flaw in the site plugin.


pgp5ZQu43yUl2.pgp
Description: OpenPGP digital signature

Re: Defining a property designed to be overridden?

[org . apache . maven . user]

On 2017-03-01T12:46:45 -0600
Curtis Rueden  wrote:
>
> In this way, I ensure that all projects which extend our parent add all the
> useful metadata and properties needed for successful builditude.
> 
> We released scijava-maven-plugin 1.0.0 on Maven Central; feel free to use
> it if it helps you.

Hah, well, I'm not sure you could have solved my problem any more
precisely than that! Looks like exactly what I need. Thanks very much!

M


pgpLYGw3U7Uf4.pgp
Description: OpenPGP digital signature

Re: Defining a property designed to be overridden?

[Curtis Rueden]

Hi,

> if a project forgets to override the property value, it won't get a
> sensible "You didn't define this property" error because it's already
> defined with an empty value in the parent.

The way I solved this problem with my project builds is to create a custom
requireElements enforcer rule, part of the scijava-maven-plugin [1], which
lets you require the existence of particular elements in the POM itself—not
an ancestor. Here is the configuration we use:

https://github.com/scijava/pom-scijava-base/blob/pom-
scijava-base-3.0.0/pom.xml#L610-L628

In this way, I ensure that all projects which extend our parent add all the
useful metadata and properties needed for successful builditude.

We released scijava-maven-plugin 1.0.0 on Maven Central; feel free to use
it if it helps you.

Regards,
Curtis

[1] https://github.com/scijava/scijava-maven-plugin/blob/
scijava-maven-plugin-1.0.0/src/main/java/org/scijava/maven/plugin/enforcer/
RequireElements.java#L55-L61

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Wed, Mar 1, 2017 at 12:35 PM, <org.apache.maven.u...@io7m.com> wrote:

> Hello.
>
> I'm looking to move to an organization-wide parent POM but am not sure
> how to handle the following configuration case.
>
> The japicmp [0] plugin takes a configuration parameter that specifies
> the previous version of a module against which the current version of
> the module will be checked for API compatibility. I believe it can
> sometimes infer the correct version by itself, but for the sake of
> explanation here, let's assume that it can't and that I need to specify
> it myself. This isn't a japicmp plugin issue, it's just a specific
> example of a more general problem regarding the scope and definitions
> of properties.
>
> I have a parent pom:
>
> https://github.com/io7m/maven-parent-properties-20170301/blo
> b/develop/pom.xml
>
> ... which contains a definition like this:
>
> 
>   ...
>   
> 
>   
>
>   ...
>
>   
> 
>   
> 
> 
>   com.github.siom79.japicmp
>   japicmp-maven-plugin
>   0.9.4
>   
> 
>   verify
>   
> cmp
>   
>   
> 
>   
> ${project.groupId}
> ${project.artifactId}
> ${io7m.previousVersion}
> jar
>   
> 
>   
> 
>   
> 
>   
> 
>   
> 
>
> I then have an example project that inherits from the parent:
>
> https://github.com/io7m/maven-parent-properties-20170301/blo
> b/develop/mod-a/pom.xml
>
> 
>   
> com.io7m.experimental
> maven-parent-properties-20170301
> 1.0.0
>   
>
>   mod-a
>   
> 0.9.0
>   
>
>   
> 
>   
> com.github.siom79.japicmp
> japicmp-maven-plugin
>   
> 
>   
> 
>
> Note that the child project must override the io7m.previousVersion
> property from the parent. Is this the correct way to handle this? The
> downside to this is that if a project forgets to override the property
> value, it won't get a sensible "You didn't define this property" error
> because it's already defined with an empty value in the parent. If I
> don't define the property in the parent, many IDEs get upset at the
> presence of an undefined property in the POM.
>
> Any advice would be appreciated.
>
> M
>
> [0] https://siom79.github.io/japicmp/MavenPlugin.html
>

Defining a property designed to be overridden?

[org . apache . maven . user]

Hello.

I'm looking to move to an organization-wide parent POM but am not sure
how to handle the following configuration case.

The japicmp [0] plugin takes a configuration parameter that specifies
the previous version of a module against which the current version of
the module will be checked for API compatibility. I believe it can
sometimes infer the correct version by itself, but for the sake of
explanation here, let's assume that it can't and that I need to specify
it myself. This isn't a japicmp plugin issue, it's just a specific
example of a more general problem regarding the scope and definitions
of properties.

I have a parent pom:

https://github.com/io7m/maven-parent-properties-20170301/blob/develop/pom.xml

... which contains a definition like this:


  ...
  

  

  ...

  

  


  com.github.siom79.japicmp
  japicmp-maven-plugin
  0.9.4
  

  verify
  
cmp
  
  

  
${project.groupId}
${project.artifactId}
${io7m.previousVersion}
jar
  

  

  

  

  


I then have an example project that inherits from the parent:

https://github.com/io7m/maven-parent-properties-20170301/blob/develop/mod-a/pom.xml


  
com.io7m.experimental
maven-parent-properties-20170301
1.0.0
  

  mod-a
  
0.9.0
  

  

  
com.github.siom79.japicmp
japicmp-maven-plugin
  

  


Note that the child project must override the io7m.previousVersion
property from the parent. Is this the correct way to handle this? The
downside to this is that if a project forgets to override the property
value, it won't get a sensible "You didn't define this property" error
because it's already defined with an empty value in the parent. If I
don't define the property in the parent, many IDEs get upset at the
presence of an undefined property in the POM.

Any advice would be appreciated.

M

[0] https://siom79.github.io/japicmp/MavenPlugin.html


pgpMdi3j13ccx.pgp
Description: OpenPGP digital signature

[ANN] Apache Maven Version 3.5.0-alpha-1 Released

[Stephen Connolly]

The Apache Maven team would like to announce the release of Maven
3.5.0-alpha-1.

http://maven.apache.org/

NOTE: This is an ALPHA release. There is the potential that features may be
added/removed between this release and the first GA release in the 3.5.x
release line.
Please consult the Known Issues section below before use

You can download the appropriate sources, etc. from the archives section on
the download page as Maven 3.3.9 is still the recommended GA release

https://archive.apache.org/dist/maven/maven-3/3.5.0-alpha-1/

Known Issues

The following issues were identified during release testing of this ALPHA
release but have not been deemed as release blockers:

* [MNG-6177] The `--file` and `-f` option to specify a `pom.xml` to use
does not work if the path includes characters that need quoting such as
whitespace or `&`.
* [MNG-6115] If Maven is installed in a writable location, every build will
create a new `lib/ext/jansi-` file.

Why not Maven 3.4.0?

After Maven 3.3.9 was released, the Eclipse Aether project was retired and
the code base was migrated to the Apache Maven project.

The original goal for the 3.4.0 release was to replace Aether with the
exact same code after migration to the Apache Maven project and then
proceed with bug fixes to the resolver code as well as other areas of Maven.

The migration of the code between the two foundations took longer than
expected and as a result there were other changes committed to Maven core
that were outside the scope of intent for 3.4.0.

In order to refocus on the original intent for 3.4.0, the decision was
taken to revert the Maven core history to the point of the 3.3.9 release
and merge in the desired changes one at a time.

Because there had been a lot of communication about different features
being delivered and bugs fixed in Maven 3.4.0 and the new history may not
contain them in the first release, the decision was taken to forever burn
the 3.4.x release line.

More detail on this decision can be read in the [mailing list archive](
http://www.mail-archive.com/dev@maven.apache.org/msg112103.html).


Release Notes - Maven - Version 3.5.0-alpha-1

Bugs:
* [MNG-5297] - Site should tell 'prerequisites.maven is deprecated'
* [MNG-5368] - UnsupportedOperationException thrown when version range
is not correct in dependencyManagement definitions
* [MNG-5629] - ClosedChannelException from
DefaultUpdateCheckManager.read
* [MNG-5815] - "mvn.cmd" does not indicate failure properly when using
"&&"
* [MNG-5823] - mvnDebug doesn't work with M2_HOME with spaces - missing
quotes
* [MNG-5829] - mvn shell script fails with syntax error on Solaris 10
* [MNG-5836] - logging config is overridden by $M2_HOME/lib/ext/*.jar
* [MNG-5852] - mvn shell script invokes /bin/sh but requires Bash
functions
* [MNG-5958] - java.lang.String cannot be cast to
org.apache.maven.lifecycle.mapping.LifecyclePhase
* [MNG-5961] - Maven possibly not aware of log4j2
* [MNG-5962] - mvn.cmd fails when the current directory has spaces in
between
* [MNG-5963] - mvn.cmd does not return ERROR_CODE
* [MNG-6022] - mvn.cmd fails if directory contains an ampersand (&)
* [MNG-6053] - Unsafe System Properties copy in
MavenRepositorySystemUtils, causing NPEs
* [MNG-6105] -
properties.internal.SystemProperties.addSystemProperties() is not really
thread-safe
* [MNG-6109] - PluginDescriptor doesn't read since value of parameter
* [MNG-6117] - ${session.parallel} not correctly set
* [MNG-6144] - DefaultWagonManagerTest#testGetMissingJarForced() passed
incorrect value
* [MNG-6166] - mvn dependency:go-offline fails due to missing
transitive dependency jdom:jdom:jar:1.1
* [MNG-6171] - REGRESSION: WARNING about usage of a non threadsafe
marked plugin is not showed anymore
* [MNG-6172] - Precedence of command-line system property options has
changed

Dependency upgrades:
* [MNG-5967] - Dependency updates
* [MNG-6110] - Upgrade Aether to Maven Resolver

Improvements:
* [MNG-5579] - Unify error output/check logic from shell and batch
scripts
* [MNG-5607] - Don't use M2_HOME in mvn shell/command scripts anymore
* [MNG-5883] - Silence unnecessary legacy local repository warning
* [MNG-5889] - .mvn directory should be picked when using --file
* [MNG-5904] - Remove the whole Ant build
* [MNG-5931] - Fixing documentation
* [MNG-5934] - String handling issues identified by PMD
* [MNG-5946] - Fix links etc. in README.txt which is part of the
delivery
* [MNG-5968] - Default plugin version updates
* [MNG-5975] - Use Java 7's SimpleDateFormat in
CLIReportingUtils#formatTimestamp
* [MNG-5977] - Improve output readability of our MavenTransferListener
implementations
* [MNG-5993] - Confusing error message in case of missing/empty
artifactId and version in pluginManagement
* [MNG-6001] - Replace %HOME% with %USERPROFILE% in mvn.cmd
* [MNG-6003] - Drastically reduce JAVA_HOME 

Treat maven warnings as errors

[Yaron Golan]

Hi,
Is there a way to treat the maven warnings as errors?