Re: The URL appending issue and Maven Central

[Mark Raynsford]

On 2019-07-08T19:46:38 +0200
"Robert Scholte"  wrote:

> Hi Mark,
> 
> I'm working on some improvements which might be related to this.
> My main question: is the pom containing the special attributes part of the  
> Maven Multimodule project?

Not quite sure how to interpret this one. In my case, I'd specify those
attributes on a distant ancestor POM and then inherit from that POM in
the root POMs of many of separate multi-module projects.

> If so, I should be able to calculate the right URL based on the local  
> folder structure instead of pom inheritence via parent, right?

I think calculating is the whole problem: I actually specifically don't
want any calculation going on. I've specified the URIs myself and I'd
prefer it if Maven both inherited the values directly from parents, and
left the URL values alone without any appending or other mangling. :)

-- 
Mark Raynsford | http://www.io7m.com



pgpN_el3zCG14.pgp
Description: OpenPGP digital signature

Re: The URL appending issue and Maven Central

[Robert Scholte]

Hi Mark,

I'm working on some improvements which might be related to this.
My main question: is the pom containing the special attributes part of the  
Maven Multimodule project?
If so, I should be able to calculate the right URL based on the local  
folder structure instead of pom inheritence via parent, right?


thanks,
Robert

On Mon, 08 Jul 2019 12:23:57 +0200, Mark Raynsford  
 wrote:



Hello!

This is still a problem:

  https://issues.apache.org/jira/browse/MNG-5951
  https://issues.apache.org/jira/browse/MNG-6059

The problem isn't that the behaviour hasn't been fixed, but instead
that the POM files that use the new attributes can't be deployed to
Maven Central. I reported the issue to Sonatype, but it's been eight
months [0] and nothing has been done about it. I think it might be case
of the Sonatype people waiting to see what the Maven people will do, and
the Maven people waiting to see what the Sonatype people will do. :)

I wonder if, instead, we could just turn off this URL appending
behaviour with a property? Ideally the property would be specified in
the POM file and the model would stay entirely backwards compatible.
If you don't set the property to true, you get the old url-mangling
behaviour.

 
  
true
  
  ...

I'm *still* in the situation where I can either add the attributes to
my projects and get correct metadata but be unable to publish to
Central, or avoid using the attributes and get wildly incorrect
metadata but be able to publish to Central. Both choices are
pretty much unacceptable. Free to publish garbage, or prevented from
publishing non-garbage!

I'd like to see some movement on this... What do I need to do to get
this sorted out?

[0] https://blog.io7m.com/2018/11/23/lurking-between-releases.xhtml


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

Re: The URL appending issue and Maven Central

[Mark Raynsford]

On 2019-07-08T11:23:57 +0100
Mark Raynsford  wrote:
>
> I'd like to see some movement on this... What do I need to do to get
> this sorted out?

To be clear, I'm offering my time and resources here. I'm not just
demanding that other people do work on my behalf.

-- 
Mark Raynsford | http://www.io7m.com



pgp6gdYo5jfs3.pgp
Description: OpenPGP digital signature

maven-assembly-plugin 3.1.2 release?

[Eric Lilja]

Hi! When could we see a release of maven-assembly-plugin 3.1.2? In Jira,
eight issues are associated with version 3.1.2, and they are all resolved.
We're keen to see 3.1.2 released, as it contains important dependency
upgrades, like MASSEMBLY-910 [1]

Best regards,
Eric L

[1] https://issues.apache.org/jira/browse/MASSEMBLY-910

JDK 13 , JDK 14 & Valhalla Early Access builds are available.

[Rory O'Donnell]

 Hi Robert ,

**OpenJDK* 13 Early Access build **28 is now available **at : - 
jdk.java.net/13/*


 * These early-access, open-source builds are provided under the GNU
   General Public License, version 2, with the Classpath Exception
   .
 * Changes in this build 28 [1]


*Reminder of a change in b24 - A jrt URI can only encode paths to files 
in /modules tree **(JDK-8224946 
)*


A |jrt| URL is a hierarchical URI with syntax |jrt:/[$MODULE[/$PATH]]|. 
When using the |jrt| file system, a |java.net.URI| object can be created 
with the |java.nio.file.Path::toUri| method to encode a normalized path 
to a file in the |/modules| tree. A |jrt| URL cannot encode a path to a 
file in the |/packages| tree. The |jrt| file system provider has changed 
in this release so that |toUri| fails with |IOError| when it is not 
possible to encode the file path as a jrt URI. *This change may impact 
tools have been making use of URLs that are not compliant with the 
syntax. Tools with paths to files in **|/packages|**can use the 
**|toRealPath()|**method to obtain the real path (in **|/modules|**) 
before attempting to convert the file path to a URI.*


*OpenJDK 14 **Early Access build 4 **is now available **at : - 
jdk.java.net/14/*


 * These early-access, open-source builds are provided under the GNU
   General Public License, version 2, with the Classpath Exception
   .
 * Changes in this build [2]


*Project Valhalla "L-World Inline Types" Early-Access Builds*

 * Build jdk-14-valhalla+1-8
 * These early-access builds are provided under the GNU General Public
   License, version 2, with the Classpath Exception
   .
 * Please send feedback via e-mail to valhalla-...@openjdk.java.net
   . To send e-mail to this
   address you must first subscribe to the mailing list.


*The Skara tooling is now open source *[3]
we are happy to announce that the tooling for project Skara is now open 
source and available at


 * https://github.com/openjdk/skara 

The Skara tooling includes both server-side tools (so called "bots") as 
well as several command-line tools **

If you have any questions, feedback etc. send them to Skara mailing list [4]

Rgds, Rory


[1] JDK 13 - Changes in b28 here 

[2] JDK 14 - Changes in b4 here 


[3] https://mail.openjdk.java.net/pipermail/skara-dev/2019-June/47.html
[4] https://mail.openjdk.java.net/mailman/listinfo/skara-dev

--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland

Re: The URL appending issue and Maven Central

[Mark Raynsford]

On 2019-07-08T11:34:02 +0100
Mark Raynsford  wrote:
>
> automatically propagate to all ancestors
 ^

Clearly I meant *descendants*. Sorry!

-- 
Mark Raynsford | http://www.io7m.com



pgpNW3WO0T2GH.pgp
Description: OpenPGP digital signature

Re: The URL appending issue and Maven Central

[Mark Raynsford]

On 2019-07-08T11:23:57 +0100
Mark Raynsford  wrote:
>
> I wonder if, instead, we could just turn off this URL appending
> behaviour with a property? Ideally the property would be specified in
> the POM file and the model would stay entirely backwards compatible.
> If you don't set the property to true, you get the old url-mangling
> behaviour.

I forgot to point out that specifying this in a parent POM should, by
my understanding of Maven's property inheritance rules, automatically
propagate to all ancestors. This would be ideal for me given that I
have ~900 pom.xml files that would otherwise have to be updated by
hand. :)

-- 
Mark Raynsford | http://www.io7m.com



pgpwwKJvF2boX.pgp
Description: OpenPGP digital signature

The URL appending issue and Maven Central

[Mark Raynsford]

Hello!

This is still a problem:

  https://issues.apache.org/jira/browse/MNG-5951
  https://issues.apache.org/jira/browse/MNG-6059

The problem isn't that the behaviour hasn't been fixed, but instead
that the POM files that use the new attributes can't be deployed to
Maven Central. I reported the issue to Sonatype, but it's been eight
months [0] and nothing has been done about it. I think it might be case
of the Sonatype people waiting to see what the Maven people will do, and
the Maven people waiting to see what the Sonatype people will do. :)

I wonder if, instead, we could just turn off this URL appending
behaviour with a property? Ideally the property would be specified in
the POM file and the model would stay entirely backwards compatible.
If you don't set the property to true, you get the old url-mangling
behaviour.

 
  
true
  
  ...

I'm *still* in the situation where I can either add the attributes to
my projects and get correct metadata but be unable to publish to
Central, or avoid using the attributes and get wildly incorrect
metadata but be able to publish to Central. Both choices are
pretty much unacceptable. Free to publish garbage, or prevented from
publishing non-garbage!

I'd like to see some movement on this... What do I need to do to get
this sorted out?

[0] https://blog.io7m.com/2018/11/23/lurking-between-releases.xhtml

-- 
Mark Raynsford | http://www.io7m.com


pgpHn7JBhe4zX.pgp
Description: OpenPGP digital signature

[ANN] Apache Maven Javadoc Plugin 3.1.1 Released

[Olivier Lamy]

The Apache Maven team is pleased to announce the release of the Apache
Maven Javadoc Plugin, version 3.1.1

https://maven.apache.org/plugins/maven-javadoc-plugin/

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


org.apache.maven.plugins
maven-javadoc-plugin
3.1.1


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

https://maven.apache.org/plugins/maven-javadoc-plugin/download.cgi

Release Notes - Maven Javadoc Plugin - Version 3.1.1

** Bug
* [MJAVADOC-539] - Upgrading plugin from 3.0.0 to 3.0.1 and 3.1.0
breaks certain external javadoc links
* [MJAVADOC-589] - JDK 12 Classes Not Automatically Linked
* [MJAVADOC-591] - javadoc fails with maven.compiler.release=8 and
Automatic-Module-Name
* [MJAVADOC-599] - javadoc:aggregate-jar does not create the jar when
executed as build plugin

** Improvement
* [MJAVADOC-516] - Replace usage of deprecated HttpClient code

Enjoy,

-The Apache Maven team

Re: [maven-site-plugin] 01/01: [MSITE-844] Downgrade to Java 7

[Olivier Lamy]

On Mon, 8 Jul 2019 at 17:31, Tibor Digana  wrote:

> Hello Olivier,
>
> After seen the repo, it was obvious that Jetty was developed in three code
> lines namely 9.2.x, 9.3.x and 9.4.x.
> The next fact is that the Maven team agreed to use Java compiler 1.7. The
> user can use JDK 1.8 or higher with security patches.
> These two facts mean that we can stick to the minimum requirements and
> atill the user wil have the most modern jetty-security artifact.
>
> Nobody said that Maven does not want to modernize code but we obviously do
> it in some stages.
> We first modernized Maven and plugins with Java 1.7 and there was a strong
> reason - NIO2.
> I remember that we could not solve file system I/O issues related to the
> implementation of JDK 1.8 without upgrading the compiler to Java 1.7.
>
> Not sure if it is not visible enough but I see that Maven 3.7.0 is
> enclosing plugins with Java 1.7.
> Especially, the Maven lifecycle plugins are important, like the
> maven-site-plugin.


> I have no idea when the team want to cut the release of Maven 3.7.0 and
> consequently the plugins based on Java 1.8 but I hope it will be soon.
> I understand it this way, the sooner we finish Maven 3.7.0 the sooner we
> trigger Java compiler 1.8 in plugins and we would not have these conflicts.
> I do not think that somebody would not allow you updating the table in
> MNG-6169 with good fixes of maven-site-plugin.
>

AFAIK site plugin is not part of the default lifecycle. so not part
of MNG-6169...
Or maybe I missed something?


>
> Cheers
> Tibor17
>
>
>
> On Mon, Jul 8, 2019 at 1:41 AM Olivier Lamy  wrote:
>
> > Please update the jira[1] with a more descriptive title really saying
> what
> > it does. (maybe saying "We are not ready to use java 8 that's modern for
> > us..")
> > Sorry to be so sarcastic but It's really ridiculous "Back to the future"
> > change..
> > Please note first I wanted to veto this commit but honestly I don't want
> to
> > waste my time.
> > With such change we clearly say to potential contributors they will be
> > stuck to use old java if they want to help contribute/contribute
> >
> > [1] https://issues.apache.org/jira/browse/MSITE-843
> >
> >
> > On Mon, 8 Jul 2019 at 03:53,  wrote:
> >
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > > michaelo pushed a commit to branch MSITE-844
> > > in repository
> https://gitbox.apache.org/repos/asf/maven-site-plugin.git
> > >
> > > commit 435b018720c83688f6223d7b490cec4442439600
> > > Author: tibordigana 
> > > AuthorDate: Fri Jul 5 12:47:53 2019 +0200
> > >
> > > [MSITE-844] Downgrade to Java 7
> > >
> > > This closes #10
> > > ---
> > >  Jenkinsfile|  2 +-
> > >  pom.xml|  2 +-
> > >  .../maven/plugins/site/deploy/SiteStageMojo.java   | 14 +++
> > >  .../site/render/AbstractSiteRenderingMojo.java | 28
> > > --
> > >  4 files changed, 27 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/Jenkinsfile b/Jenkinsfile
> > > index 81caf8c..5a994fd 100644
> > > --- a/Jenkinsfile
> > > +++ b/Jenkinsfile
> > > @@ -17,4 +17,4 @@
> > >   * under the License.
> > >   */
> > >
> > > -asfMavenTlpPlgnBuild(jdk:['8','11','12'], maven:['3.0.x', '3.2.x',
> > > '3.3.x', '3.5.x'])
> > > +asfMavenTlpPlgnBuild(jdk:['7','8','11','12'], maven:['3.0.x', '3.2.x',
> > > '3.3.x', '3.5.x'])
> > > diff --git a/pom.xml b/pom.xml
> > > index 4e749b9..13db5f1 100644
> > > --- a/pom.xml
> > > +++ b/pom.xml
> > > @@ -196,7 +196,7 @@ under the License.
> > >
> > >
> > >  3.0
> > > -8
> > > +7
> > >  
> > >  1.9
> > >  1.9.1
> > > diff --git
> > > a/src/main/java/org/apache/maven/plugins/site/deploy/SiteStageMojo.java
> > > b/src/main/java/org/apache/maven/plugins/site/deploy/SiteStageMojo.java
> > > index c3d10ab..a9b8848 100644
> > > ---
> > a/src/main/java/org/apache/maven/plugins/site/deploy/SiteStageMojo.java
> > > +++
> > b/src/main/java/org/apache/maven/plugins/site/deploy/SiteStageMojo.java
> > > @@ -164,10 +164,14 @@ public class SiteStageMojo
> > >  return null;
> > >  }
> > >
> > > -return reactorProjects //
> > > -.stream() //
> > > -.filter( mavenProject -> mavenProject.isExecutionRoot() )
> //
> > > -.findFirst().get();
> > > -
> > > +// todo Lambda Java 1.8
> > > +for ( MavenProject reactorProject : reactorProjects )
> > > +{
> > > +if ( reactorProject.isExecutionRoot() )
> > > +{
> > > +return reactorProject;
> > > +}
> > > +}
> > > +return null;
> > >  }
> > >  }
> > > diff --git
> > >
> >
> a/src/main/java/org/apache/maven/plugins/site/render/AbstractSiteRenderingMojo.java
> > >
> >
> b/src/main/java/org/apache/maven/plugins/site/render/AbstractSiteRenderingMojo.java
> > > index 0d89700..7336d0f 100644
> > > ---
> > >
> >
> 

Re: [maven-site-plugin] 01/01: [MSITE-844] Downgrade to Java 7

[Tibor Digana]

Hello Olivier,

After seen the repo, it was obvious that Jetty was developed in three code
lines namely 9.2.x, 9.3.x and 9.4.x.
The next fact is that the Maven team agreed to use Java compiler 1.7. The
user can use JDK 1.8 or higher with security patches.
These two facts mean that we can stick to the minimum requirements and
atill the user wil have the most modern jetty-security artifact.

Nobody said that Maven does not want to modernize code but we obviously do
it in some stages.
We first modernized Maven and plugins with Java 1.7 and there was a strong
reason - NIO2.
I remember that we could not solve file system I/O issues related to the
implementation of JDK 1.8 without upgrading the compiler to Java 1.7.

Not sure if it is not visible enough but I see that Maven 3.7.0 is
enclosing plugins with Java 1.7.
Especially, the Maven lifecycle plugins are important, like the
maven-site-plugin.

I have no idea when the team want to cut the release of Maven 3.7.0 and
consequently the plugins based on Java 1.8 but I hope it will be soon.
I understand it this way, the sooner we finish Maven 3.7.0 the sooner we
trigger Java compiler 1.8 in plugins and we would not have these conflicts.
I do not think that somebody would not allow you updating the table in
MNG-6169 with good fixes of maven-site-plugin.

Cheers
Tibor17



On Mon, Jul 8, 2019 at 1:41 AM Olivier Lamy  wrote:

> Please update the jira[1] with a more descriptive title really saying what
> it does. (maybe saying "We are not ready to use java 8 that's modern for
> us..")
> Sorry to be so sarcastic but It's really ridiculous "Back to the future"
> change..
> Please note first I wanted to veto this commit but honestly I don't want to
> waste my time.
> With such change we clearly say to potential contributors they will be
> stuck to use old java if they want to help contribute/contribute
>
> [1] https://issues.apache.org/jira/browse/MSITE-843
>
>
> On Mon, 8 Jul 2019 at 03:53,  wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > michaelo pushed a commit to branch MSITE-844
> > in repository https://gitbox.apache.org/repos/asf/maven-site-plugin.git
> >
> > commit 435b018720c83688f6223d7b490cec4442439600
> > Author: tibordigana 
> > AuthorDate: Fri Jul 5 12:47:53 2019 +0200
> >
> > [MSITE-844] Downgrade to Java 7
> >
> > This closes #10
> > ---
> >  Jenkinsfile|  2 +-
> >  pom.xml|  2 +-
> >  .../maven/plugins/site/deploy/SiteStageMojo.java   | 14 +++
> >  .../site/render/AbstractSiteRenderingMojo.java | 28
> > --
> >  4 files changed, 27 insertions(+), 19 deletions(-)
> >
> > diff --git a/Jenkinsfile b/Jenkinsfile
> > index 81caf8c..5a994fd 100644
> > --- a/Jenkinsfile
> > +++ b/Jenkinsfile
> > @@ -17,4 +17,4 @@
> >   * under the License.
> >   */
> >
> > -asfMavenTlpPlgnBuild(jdk:['8','11','12'], maven:['3.0.x', '3.2.x',
> > '3.3.x', '3.5.x'])
> > +asfMavenTlpPlgnBuild(jdk:['7','8','11','12'], maven:['3.0.x', '3.2.x',
> > '3.3.x', '3.5.x'])
> > diff --git a/pom.xml b/pom.xml
> > index 4e749b9..13db5f1 100644
> > --- a/pom.xml
> > +++ b/pom.xml
> > @@ -196,7 +196,7 @@ under the License.
> >
> >
> >  3.0
> > -8
> > +7
> >  
> >  1.9
> >  1.9.1
> > diff --git
> > a/src/main/java/org/apache/maven/plugins/site/deploy/SiteStageMojo.java
> > b/src/main/java/org/apache/maven/plugins/site/deploy/SiteStageMojo.java
> > index c3d10ab..a9b8848 100644
> > ---
> a/src/main/java/org/apache/maven/plugins/site/deploy/SiteStageMojo.java
> > +++
> b/src/main/java/org/apache/maven/plugins/site/deploy/SiteStageMojo.java
> > @@ -164,10 +164,14 @@ public class SiteStageMojo
> >  return null;
> >  }
> >
> > -return reactorProjects //
> > -.stream() //
> > -.filter( mavenProject -> mavenProject.isExecutionRoot() ) //
> > -.findFirst().get();
> > -
> > +// todo Lambda Java 1.8
> > +for ( MavenProject reactorProject : reactorProjects )
> > +{
> > +if ( reactorProject.isExecutionRoot() )
> > +{
> > +return reactorProject;
> > +}
> > +}
> > +return null;
> >  }
> >  }
> > diff --git
> >
> a/src/main/java/org/apache/maven/plugins/site/render/AbstractSiteRenderingMojo.java
> >
> b/src/main/java/org/apache/maven/plugins/site/render/AbstractSiteRenderingMojo.java
> > index 0d89700..7336d0f 100644
> > ---
> >
> a/src/main/java/org/apache/maven/plugins/site/render/AbstractSiteRenderingMojo.java
> > +++
> >
> b/src/main/java/org/apache/maven/plugins/site/render/AbstractSiteRenderingMojo.java
> > @@ -61,7 +61,6 @@ import java.util.LinkedHashMap;
> >  import java.util.List;
> >  import java.util.Locale;
> >  import java.util.Map;
> > -import java.util.stream.Collectors;
> >
> >  import static