Re: Strange ServiceLoader issue with Surefire and JDK 21 bytecode

[Mark Raynsford]

On 2023-10-16T13:59:05 +0200
Romain Manni-Bucau  wrote:

> Yes, this is the one I had in mind, think it comes from plexus transitive
> deps.

For reference:

  

  

  org.apache.maven.plugins
  maven-surefire-plugin
  3.1.2
  

  org.ow2.asm
  asm
  9.6

  

  

  

... does indeed fix the problem. Thanks!

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



pgpIs_MHRxpyT.pgp
Description: OpenPGP digital signature

Re: Strange ServiceLoader issue with Surefire and JDK 21 bytecode

[Mark Raynsford]

On 2023-10-16T08:14:40 +0200
Romain Manni-Bucau  wrote:

> Hi,
> 
> Didn't check in details but it can be the bytecode reader version we have
> today in surefire is too old to read java 21 bytecode so it does not put
> your module on module path but classpath so then, without
> META-INF/services/x file it is not detected.
> 

That does sound likely.

Would this be asm? I had a brief look through the surefire sources but
didn't see it. I've more than once had to temporarily override asm for
various plugins when targeting a new bytecode version.

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



pgp5tNf1tsUSV.pgp
Description: OpenPGP digital signature

Strange ServiceLoader issue with Surefire and JDK 21 bytecode

[Mark Raynsford]

Hello!

I'm seeing test failures when javac produces JDK 21 bytecode as opposed
to JDK 20 bytecode:

https://github.com/io7m/surefire-20231015

You'll need JDK 21.

Essentially, `mvn package` will work, but `mvn
-Dio7m.java.targetJavaVersion=21 package` will cause a test failure.

The actual root symptom is that ServiceLoader.load() will return no
implementations, even though three implementations are registered in
the module descriptor. I don't know why this is a problem when the
bytecode version is 65, but not a problem when the bytecode version is
64.

The same tests work just fine in Intellij IDEA with any bytecode
version set.

Does anyone know what's going on here?

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



pgpbQI0Khleno.pgp
Description: OpenPGP digital signature

Adding extra "scope" type metadata to dependencies?

[Mark Raynsford]

Hello!

I'd like to be able to add extra metadata to dependencies in a POM file.
Specifically:

  1. I'd like to be able to specify whether a dependency goes on the
 class or module path rather than have Maven decide for me.

  2. I'd like to be able to specify that a dependency _doesn't_ go on
 either path (possibly because it's going to be added manually
 elsewhere during deployment as an OSGi bundle, or as part of a
 dynamically created module layer, or something similar).

Ideally, the second point would be handled properly by IDEs such that
clicking "Run" wouldn't result in artifacts being added to the
classpath/modulepath of the program the IDE runs.

I remember reading (possibly over a year ago now) that there might be
some possibility of an extension that allows for adding extra
information to a  element, but I'm now unable to find any
evidence this existed.

Is there some way to do this today? If not... Will there be some way in
Maven 4.0.0+?

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


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

Re: Testing plugins in JUnit 5

[Mark Raynsford]

On 2022-11-05T12:36:55 +0100
Maarten Mulders  wrote:
>
> One solution that I know of is the Integration Testing Framework 
> Extension [1] by Karl Heinz Marbaise. The documentation says the project 
> is in "an early state but already being useful and can be used for real 
> testing".
> 
>  From my own experience, I can confirm it's really usable and useful. I 
> am using it to test my own Maven plugin for generating images from 
> PlantUML sources [2]. See it's "test/" module for some examples.

Thanks! Giving it a try now.

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


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

Testing plugins in JUnit 5

[Mark Raynsford]

Hello!

As the subject says: Is there a documented way to write tests for
plugins under JUnit 5? The only thing I've been able to find is the
takari testing project:

  https://github.com/takari/takari-plugin-testing-project

There seems to be some preliminary support there, but it's not in any
of the available releases and nobody seems to have touched the project
for almost a year.

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


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

Re: uploading to central via ossrh is problematic

[Mark Raynsford]

On 2021-01-21T13:51:36 -0500
Brian Fox  wrote:

> OSSRH itself is in the
> process of being federated and large projects are given the
> opportunity to move to their own new, or separate instance so their
> load doesn't hurt the many thousands of other builds flowing through
> the system at any given time.

I'd love to hear more about this! I've been publishing to Central for
over a decade now without ever running my own Nexus instance, and what
goes on behind the APIs at Central is a bit of a mystery. :)

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



pgph49znorJhq.pgp
Description: OpenPGP digital signature

Re: provided as compileOnly

[Mark Raynsford]

On 2020-07-29T12:22:33 +0200
Michael Osipov  wrote:
>
> I think your usage is correct. Maybe the docs aren't sharp enough saying 
> that those case just examples which require a provided scope. You can, 
> of course, improve the docs in such a fashion.
> Out of couriosity, can you give you can example for your usecase?

I frequently use `provided` for compile-time only annotations. For
example, the immutables.org generator uses annotations to generate
immutable record types. The OSGi bundle annotations are processed by
the bnd-* plugin family and allow for adding extra information to OSGi
manifests in jar files. None of those annotations are retained, and we
don't expect anything to be available at runtime.

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



pgplTCSWArvcw.pgp
Description: OpenPGP digital signature

Re: The URL appending issue and Maven Central

[Mark Raynsford]

On 2019-07-09T08:16:14 +0200
Hervé BOUTEMY  wrote:

> you have created MVNCENTRAL-4841 [1] issue 2 months ago: this is where to 
> ping 
> for updates

Ah, thanks! Didn't know about that one. I'll comment on it and link to
my old ticket.

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



pgp7VwvITMR2_.pgp
Description: OpenPGP digital signature

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

[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

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

Re: Maven Core Release 3.6.1

[Mark Raynsford]

On 2018-12-30T16:24:50 +0100
Hervé BOUTEMY  wrote:

> here is the status on the Maven core side:
> - MNG-6059 was implemented, which means the attributes were renamed: see 
> MNG-6059 issue description [1] to get the new child.(x).
> (y).inherit.append.path names ((x) and (y) were missing in 3.6.0, forgotten 
> by 
> inadvertance...)
> - MNG-6505 was implemented = inheritance of these attributes
> 
> on checks when publishing to Central, via Apache repository or via OSSHR, 
> we'll need to check once Maven 3.6.1 is released and work together if you 
> find 
> an issue

Sounds good, thanks!

I'm looking forward to testing 3.6.1.

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



pgp413Zo1kKBq.pgp
Description: OpenPGP digital signature

Re: Maven Core Release 3.6.1

[Mark Raynsford]

On 2018-12-29T21:04:33 +0100
Karl Heinz Marbaise  wrote:

> Hi to all,
> 
> I want to cut a Core Release within two weeks (about 14.01.2019) if that 
> is Ok for everyone? If any objections please raise your hand.

One for Hervé: Where did we leave things with MNG-6059? I ran into that
issue a while back where I was unable to deploy to Central with the new
attributes [0]. I've sort of been operating under the vague hope that
3.6.1 will allow me to both have those attributes inherited across all
my POMs from a single ancestor, and also to deploy those POMs to
Central. I'm fairly sure I tested a post-3.6.0 snapshot to verify that
the attributes were inherited (they weren't in 3.6.0), but my memory is
failing me...

[0] http://blog.io7m.com/2018/11/01/you-cannot-put-that-there.xhtml

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



pgpXtivdG_XNi.pgp
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven Shared Component: Maven Dependecy Analyzer Version 1.11.1

[Mark Raynsford]

+1 (non-binding)

(anxious for a new dependency plugin release :))

On 2018-12-25T23:28:15 +0100
Karl Heinz Marbaise  wrote:

> Hi,
> 
> We solved 1 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12344667
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20XX%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1480/
> https://repository.apache.org/content/repositories/maven-1480/org/apache/maven/shared/maven-dependency-analyzer/1.11.1/maven-dependency-analyzer-1.11.1-source-release.zip
> 
> Source release checksum(s):
> maven-dependency-analyzer-1.11.1-source-release.zip sha512: 
> 7d8880bac7cfb5f9f01f0b82e6d1dc1b9a4e0f79e0c76f9d807182fcad5e3e8c57c0c019cb1177b87a1e85f92aff3770585422be691f5cfafb529e633af35600
> 
> Staging site:
> http://maven.apache.org/shared-archives/maven-dependency-analyzer-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


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



pgpmLuZEtvhk8.pgp
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven Shared Component: Maven Dependency Analyzer 1.11.0

[Mark Raynsford]

+1 (non-binding)

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



pgp3rVLfVx5Vr.pgp
Description: OpenPGP digital signature

Re: Inheritance behaviour for MNG-5951 attributes?

[Mark Raynsford]

> On 2018-11-10T16:47:59 +0100
> Hervé BOUTEMY  wrote:
> 
> > ok, I investigated more in details and added a little trick in [1]: 
> > child.site.url.inherit.append.path is inherited independantly from 
> > id/name/url
> > 
> > this will manage your edge case, which I can understand is expected
> > 
> > do you think it is ok?  

11312d5b275260fbd2b3ed3294da3ccff5413d42 gives me the results I'd
expect:

$ unzip -p b/c/target/com.io7m.c-1.0.0.jar META-INF/MANIFEST.MF
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven 3.6.1-SNAPSHOT
Built-By: rm
Build-Jdk: 11
Field-SCM: https://github.com/io7m/mng-6059-examples
Field-Site: https://www.io7m.com/software/mng-6059-examples
Field-URL: http://www.io7m.com/

Nice work!

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



pgpyk0uIF120T.pgp
Description: OpenPGP digital signature

Re: Inheritance behaviour for MNG-5951 attributes?

[Mark Raynsford]

On 2018-11-10T16:47:59 +0100
Hervé BOUTEMY  wrote:

> ok, I investigated more in details and added a little trick in [1]: 
> child.site.url.inherit.append.path is inherited independantly from id/name/url
> 
> this will manage your edge case, which I can understand is expected
> 
> do you think it is ok?

I'll build and test this shortly! Thanks.

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



pgpvwGCrqoTfn.pgp
Description: OpenPGP digital signature

Re: Inheritance behaviour for MNG-5951 attributes?

[Mark Raynsford]

'Ello.

On 2018-11-06T00:03:53 +0100
Hervé BOUTEMY  wrote:

> Hi Mark,
> 
> even if this is somewhat a corner case (while overriding everything in b, you 
> can override the attribute also), it is strange...

I'm not sure it's a corner case, exactly. It reflects the real-life
situation I'm in: Consider a tree where 'a' is the root, and there are
a large number of projects (at the depth of 'b') that all inherit from
'a'. In my case "large" means "more than seventy" so, as you can
imagine, I'm not enthusiastic about going through all of those projects
and adding an attribute just to to fix a bug in Maven. :) In my case,
there are over 400 modules at the depth of 'c' spread across all of the
'b'-level projects.

> I can reproduce the issue in an inheritance unit test (no-append-urls in 
> maven-model-builder), but still need to investigate why it does not work as 
> intended by ModelMerger.mergeSite(...): you can easily check by removing 
> "name" field in b, you'll see that merge for other fields does not work

Good to know it's reproducible in tests.

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



pgpQFR5MgaNQ5.pgp
Description: OpenPGP digital signature

Re: Inheritance behaviour for MNG-5951 attributes?

[Mark Raynsford]

On 2018-11-04T15:05:19 +
Mark Raynsford  wrote:

> On 2018-11-04T15:34:11 +0100
> Hervé BOUTEMY  wrote:
> 
> > you can build https://github.com/apache/maven/tree/MNG-6059 with quick 
> > build 
> > instruction at the end of README
> >   
> 
> Thanks. I've built 523db580468bc2b9d8420470bb24f5f688220701 and it
> seems to be working for all but the
> project/distributionManagement/site/@child.site.url.inherit.append.path
> element.

Here's a more isolated example:

  https://github.com/io7m/mng-6059-examples/tree/develop/abc

Note that the jar in the 'c' module has the following fields:

  Manifest-Version: 1.0
  Archiver-Version: Plexus Archiver
  Created-By: Apache Maven 3.6.1-SNAPSHOT
  Built-By: rm
  Build-Jdk: 11
  Field-SCM: https://github.com/io7m/mng-6059-examples
  Field-Site: https://www.io7m.com/software/mng-6059-examples/com.io7m.c
  Field-URL: http://www.io7m.com/

The Field-SCM and Field-URL attributes have the automatic appending
correctly disabled, but the Field-Site attribute still has the module
appended despite the fact that the site element in
distributionManagement has child.site.url.inherit.append.path="false". 

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



pgpxh8S2wTqA0.pgp
Description: OpenPGP digital signature

Re: Inheritance behaviour for MNG-5951 attributes?

[Mark Raynsford]

On 2018-11-04T15:34:11 +0100
Hervé BOUTEMY  wrote:

> you can build https://github.com/apache/maven/tree/MNG-6059 with quick build 
> instruction at the end of README
> 

Thanks. I've built 523db580468bc2b9d8420470bb24f5f688220701 and it
seems to be working for all but the
project/distributionManagement/site/@child.site.url.inherit.append.path
element. I have this in my organization-wide POM:

  https://github.com/io7m/primogenitor/blob/release/3.0.0-beta0019/pom.xml#L126

I then use the property in BND bundle manifests:

  https://github.com/io7m/primogenitor/blob/release/3.0.0-beta0019/pom.xml#L433

The $[...] syntax is just BND-speak for "expand this property as late
as possible". Using the traditional ${...} syntax can cause those
properties to be expanded too early, resulting in the values as they
appeared in the parent being used in child modules.

Then, in a descendant project:

  https://github.com/io7m/junreachable/blob/release/3.0.0/pom.xml#L39
  https://github.com/io7m/junreachable/blob/release/3.0.0/pom.xml#L60

If I look at the resulting OSGi manifest for the
com.io7m.junreachable.core module, I see:

Bundle-Description   Exception types for marking 
unreachable/unimplemented code (Core)
Bundle-DocURL
https://www.io7m.com/software/junreachable/com.io7m.junreachable.core
Bundle-ManifestVersion   2  
 
Bundle-Name  com.io7m.junreachable.core 3.0.0 - 
Exception types for marking unreachable/unimplemented code (Core)
Bundle-SCM   https://github.com/io7m/junreachable   
 
Bundle-SymbolicName  com.io7m.junreachable.core 
 
Bundle-Vendorio7m.com   
 
Bundle-Version   3.0.0  
 
Export-Package   com.io7m.junreachable;version="3.0.0"  
 
Implementation-Build 
e519345f73b1d2f4c9393eadbf9909ac361a0751
Implementation-Title com.io7m.junreachable.core 
 
Implementation-Vendorio7m.com   
 
Implementation-Vendor-Id com.io7m.junreachable  
 
Implementation-Version   3.0.0  
 
Manifest-Version 1.0
 
Require-Capability   
osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=11))"
Sealed   true   
 
Specification-Title  com.io7m.junreachable.core 
 
Specification-Vendor io7m.com   
 
Specification-Version3.0.0

So you can see that the Bundle-SCM field, which is built from
${project.scm.url}, has the correct non-appended value. However,
Bundle-DocURL, which is built from
${project.distributionManagement.site.url}, still has the module
name appended to it.

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



pgp6FuZNQ7QE_.pgp
Description: OpenPGP digital signature

Re: Inheritance behaviour for MNG-5951 attributes?

[Mark Raynsford]

On 2018-11-04T13:34:39 +0100
Hervé BOUTEMY  wrote:

> Hi Mark,
> 
> Seems you found one more thing that I forgot when merging MNG-6059: 
> inheritance of these child.inherit.append.path configurations...
> 
> I created MNG-6505 [1] and added the fix to MNG-6059 branch.
> 
> Can you check that it works as you expect? (notice: with the new 
> child.x.y.inherit.append.path names...)

Can do! Which code should I be building? Not sure if this work is
happening on a branch somewhere.

> Thank you for the tests and reports: this really helps a lot to improve 
> quality.

You're welcome!

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



pgpylTSF2dq7s.pgp
Description: OpenPGP digital signature

Inheritance behaviour for MNG-5951 attributes?

[Mark Raynsford]

Let's say I have the following:


  4.0.0
  com.example
  a
  1.0.0
  pom
  
https://example.com/a
scm:git:https://example.com/a
scm:git:https://example.com/a
  


And then:


  4.0.0
  
com.example
a
1.0.0
  
  com.example
  b
  1.0.0
  pom
  
https://example.com/b
scm:git:https://example.com/b
scm:git:https://example.com/b
  


And then:


  4.0.0
  
com.example
b
1.0.0
  
  com.example
  c
  1.0.0
  jar


So that's com.example:a:1.0.0 → com.example:b:1.0.0 →
com.example:c:1.0.0.

Would you expect com.example:c:1.0.0 to have
child.inherit.append.path="true" for the (inherited)  element? It
wasn't clear exactly what semantics were intended to be. What I *think*
is happening right now is that the  element in com.example:b:1.0.0
is assigned a value of child.inherit.append.path="true", because "true"
is the default if something isn't specified and it overrides the value
specified in com.example:a:1.0.0.

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



pgp2RRx3ShuCO.pgp
Description: OpenPGP digital signature

Re: [VOTE] Maven Plugin Tools 3.6.0

[Mark Raynsford]

On 2018-10-29T14:34:12 +1000
Olivier Lamy  wrote:
> Hi
> I'd like to release Maven plugin Tools 3.6.0
> We solved 5 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12343309=Text=12317820

+1 (non binding)

I've just tested this on a new plugin project that targets JDK 11
bytecode. This now works! The old version didn't, even with an
ASM version override.

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



pgpG6kyGIGDku.pgp
Description: OpenPGP digital signature

Re: Maven Core Release 3.5.5/3.6.0?

[Mark Raynsford]

On 2018-09-13T22:20:06 +0200
Karl Heinz Marbaise  wrote:

> Hi,
> based on the issues have been solved..
> 
> from my point of view waiting at the moment for the following issues:
> 
> 
>   * MNG-6311
>   * MNG-6391
> 
> Afterwards I would like to cut a release of Maven Core...
> 
> This results into the question:
> 
> Should we call it 3.6.0 or 3.5.5..?

I'd really like to see MNG-5951 make it into something soon, as I've
been bitten by this issue and was publishing bad metadata in OSGi
bundles without realizing. From what I understand, it already did make
it into 3.4.0, but 3.4.0 ended up not happening. I'm not sure how
closely Maven follows semantic versioning, but I assume that would
require calling the release 3.6.0?

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



pgp76APvDSmfj.pgp
Description: OpenPGP digital signature

Re: Using Maven's configured proxy in a plugin?

[Mark Raynsford]

On 2018-05-21T20:02:22 +0200
Michael Osipov <micha...@apache.org> wrote:
>
> It is pretty good that Robert raised the example with the Javadoc mojo 
> because it is broken. Our current approach does not scale and the 
> Javadoc Mojo will fail if your activ proxy is for HTTP, but the 
> resources are HTTPS and vice versa. Settings needs an overhaul. I 
> constantly suffer from broken Javadoc URLs at work because of this.
> 
> Upshot: don't rely on #getActiveProxy(), but iterate manually and get 
> *all* protocols you need.

It seems fairly complicated to get all of the details correct
especially when adding in things like support for authentication. Seems
like something that should be part of the Maven libraries somewhere.

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



pgpmcUbvnLn8l.pgp
Description: OpenPGP digital signature

Re: Using Maven's configured proxy in a plugin?

[Mark Raynsford]

On 2018-05-21T19:46:26 +0200
"Robert Scholte" <rfscho...@apache.org> wrote:

> Of course :)
> 
> This is probably a good example:
> https://github.com/apache/maven-javadoc-plugin/blob/master/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L3582

Hah, thanks! That's a pretty direct example!

For future visitors:

1. Inject a Settings instance using the normal injection mechanisms:

  @Parameter( defaultValue = "${settings}", readonly = true, required
  = true ) 
  private Settings settings;

2. Proxy activeProxy = settings.getActiveProxy();

 \o/

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



pgp2lrmDMogwD.pgp
Description: OpenPGP digital signature

Using Maven's configured proxy in a plugin?

[Mark Raynsford]

I have a plugin that uses URL.openStream to load external content:

  
https://github.com/io7m/minisite/blob/develop/com.io7m.minisite.maven_plugin/src/main/java/com/io7m/minisite/maven_plugin/MinSiteMojo.java#L362

It seems that although the Maven instance is configured to use a proxy
in .m2/settings.xml, the plugin doesn't know about this proxy setting
and tries to connect directly. This obviously doesn't work in the
typical corporate firewall setting. Maven itself uses the proxy
correctly; it downloads artifacts through the proxy as expected.

Is there a way to get access to a Proxy instance configured from
Maven's settings that I can use in the plugin?

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



pgptTW8ChjiXy.pgp
Description: OpenPGP digital signature

Re: Speeding up Maven

[Mark Raynsford]

With absolutely impeccable timing, I've had a couple of hardware
failures. It is theoretically possible that this was the cause of the
performance issues - although there were no error messages logged
anywhere.

I'm waiting for replacement parts, so it'll be a week or so before I
can continue pulling on this thread.

Thanks for the responses, all!

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



pgp59tyM9YdvY.pgp
Description: OpenPGP digital signature

Re: Speeding up Maven

[Mark Raynsford]

On 2018-04-14T09:02:55 +
Bernd Eckenfels <e...@zusammenkunft.net> wrote:

> Hello,
> 
> Maven is not the fastest, but in your case it sounds unusual slow. What are 
> your machine specs? Any SSD? Do you happen to have a on-access malware 
> scanner active? They react very bad to Java scanning large number of JAR 
> files.

Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz, 8GB RAM, 7200 RPM non-SSD
drive.

No malware scanner (I'm on Linux).

Going to try to set up another workstation today to see if I can
duplicate the problem there.

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



pgpU96xgptTQI.pgp
Description: OpenPGP digital signature

Re: Speeding up Maven

[Mark Raynsford]

On 2018-04-13T16:29:27 -0400
Paul Hammant <p...@hammant.org> wrote:

> Mark,
> 
> Assuming a pre-filled Maven local cache, I've a 16 second build that's only
> longer when I run a screen recorder in order to make the video show here -
> https://paulhammant.com/2017/02/05/a-16-second-java-webapp-build-including-webdriver-tests/
> 
> That one runs three WebDriver tests too after the unit and service tests -
> meaning (implicitly) it's testing JavaScript as well as Java in that time.
> 
> In order to make it fast I've abandoned the fail-safe plugin and do all
> parts of the test-pyramid in surefire (see the pom).

'Ello.

So you're saying it's my problem? ;)

I'm also assuming a pre-filled Maven local cache, but this example
project (with no dependencies) takes about six seconds to build with
(usually) about ten seconds of Maven churning before the build even
begins. This is for a build that compiles one tiny file, produces a
jar, and does nothing else.

I assumed that it was happening for everyone, but apparently it isn't.

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



pgp0AU5kw2b8y.pgp
Description: OpenPGP digital signature

Re: Speeding up Maven

[Mark Raynsford]

On 2018-04-13T21:48:58 +0200
Karl Heinz Marbaise <khmarba...@gmx.de> wrote:

> Hi Mark,

'Ello.

> On 13/04/18 21:20, Mark Raynsford wrote:
> 
> First it would be good to know which Maven version are you using? And on 
> which JDK you are running?

Hah, I purposefully left out details in the hope that it wouldn't be my
problem specifically. From the one second build you've described, it
appears that perhaps it might be.

My system:

Linux copperhead.int.arc7.info 4.15.14-1-ARCH #1 SMP PREEMPT Wed Mar 28
17:34:29 UTC 2018 x86_64 GNU/Linux

Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz, 8GB ram.

openjdk version "9.0.4"
OpenJDK Runtime Environment (build 9.0.4+11)
OpenJDK 64-Bit Server VM (build 9.0.4+11, mixed mode)

Apache Maven 3.5.2 (NON-CANONICAL_2017-10-25T13:09:52+03:00_root;
2017-10-25T10:09:52Z) Maven home: /opt/maven
Java version: 9.0.4, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-9-openjdk
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.15.14-1-arch", arch: "amd64", family:
"unix"

> Maybe I misunderstand you ...are you running it from plain command line 
> or from inside your IDE ?

The command line in the log is:

  mvn -Dmaven.tests.skip=true -DskipTests=true package

Although in the IDE in real projects, I'm skipping more plugin
executions than that.

> 
> What are you memory settings? How is your JDK configured ? Which command 
> line options ? (MAVEN_OPTS?):??

I'm both running it from the command line and from the IDE. My point
was that 16 seconds for a command line build is tolerable (although 
still pretty damn high for a project that only compiles one Java file 
and doesn't do anything else), but running the same build from within 
an IDE is painful (because in the IDE, I'm hoping for instant gratification
when I click "Run..." and I don't care about producing a full build
that someone else will use).

$ env | grep MAVEN
MAVEN_OPTS=-Xmx512m

My JDK is essentially unconfigured. Whatever the default settings are
for Linux AMD64, OpenJDK 9.

> Depending on your JVM and the configuration that can be quite large 
> different time on startup...there are several configurations which can 
> be used to improve that...

I'm open to suggestions. I'm fairly confident that it's not JVM startup
time that's the issue. For example, if I add the -X flag to Maven, you
can see that control reaches whatever passes for Maven's main() function
in roughly one second:

2018-04-13 21:00:01.455570500 
2018-04-13 21:00:02.740905500 Apache Maven 3.5.2 
(NON-CANONICAL_2017-10-25T13:09:52+03:00_root; 2017-10-25T10:09:52Z)
2018-04-13 21:00:02.741034500 Maven home: /opt/maven
2018-04-13 21:00:02.741192500 Java version: 9.0.4, vendor: Oracle Corporation
2018-04-13 21:00:02.741333500 Java home: /usr/lib/jvm/java-9-openjdk
2018-04-13 21:00:02.741454500 Default locale: en_GB, platform encoding: UTF-8
2018-04-13 21:00:02.741829500 OS name: "linux", version: "4.15.14-1-arch", 
arch: "amd64", family: "unix"
2018-04-13 21:00:06.841656500 [DEBUG] Created new class realm maven.api
2018-04-13 21:00:06.842724500 [DEBUG] Importing foreign packages into class 
realm maven.api
2018-04-13 21:00:06.844680500 [DEBUG]   Imported: javax.annotation.* < 
plexus.core
2018-04-13 21:00:06.847413500 [DEBUG]   Imported: javax.enterprise.inject.* < 
plexus.core
2018-04-13 21:00:06.847911500 [DEBUG]   Imported: javax.enterprise.util.* < 
plexus.core
2018-04-13 21:00:06.848473500 [DEBUG]   Imported: javax.inject.* < plexus.core
2018-04-13 21:00:06.849076500 [DEBUG]   Imported: org.apache.maven.* < 
plexus.core
2018-04-13 21:00:06.849575500 [DEBUG]   Imported: org.apache.maven.artifact < 
plexus.core
2018-04-13 21:00:06.850103500 [DEBUG]   Imported: org.apache.maven.classrealm < 
plexus.core
2018-04-13 21:00:06.850619500 [DEBUG]   Imported: org.apache.maven.cli < 
plexus.core
2018-04-13 21:00:06.851178500 [DEBUG]   Imported: 
org.apache.maven.configuration < plexus.core
2018-04-13 21:00:06.851678500 [DEBUG]   Imported: org.apache.maven.exception < 
plexus.core
2018-04-13 21:00:06.852183500 [DEBUG]   Imported: org.apache.maven.execution < 
plexus.core
2018-04-13 21:00:06.852685500 [DEBUG]   Imported: 
org.apache.maven.execution.scope < plexus.core
2018-04-13 21:00:06.853183500 [DEBUG]   Imported: org.apache.maven.lifecycle < 
plexus.core
2018-04-13 21:00:06.853653500 [DEBUG]   Imported: org.apache.maven.model < 
plexus.core
2018-04-13 21:00:06.854292500 [DEBUG]   Imported: org.apache.maven.monitor < 
plexus.core
2018-04-13 21:00:06.854777500 [DEBUG]   Imported: org.apache.maven.plugin < 
plexus.core
2018-04-13 21:00:06.855287500 [DEBUG]   Imported: org.apache.maven.profiles < 
plexus.core
2018-04-13 21:00:06.855786500 [DEBUG]   Imported: org.apache.maven.project < 
plexus.core
2018-04-13 21:00:06.856284500 [DEB

Speeding up Maven

[Mark Raynsford]

Hello.

Is there any way I might speed up Maven? I've been using it for years
and, for the first time, I'm actually executing it from an IDE rather
than using the IDE's built-in compiler. It seems like there's a rather
large and apparently fixed amount of overhead per invocation. Take the
following "could not be simpler" project:

  https://github.com/io7m/maven-minimal-20180413

I piped the output through tai64n [1] to give a better indication of
exactly how long everything is taking. That's a project that compiles a
single Java file and produces a jar. It doesn't run any tests, it
doesn't include any resources. 16 seconds total execution [2]!

Now for an infrequent command-line build, that's not *too* obnoxious.
For a "click a button in the IDE because I want to try this bit of code
now" build, that's a world of suffering.

It seems like Maven first spends ten entire seconds doing not very
much. That cannot be attributed to JVM startup time (Hello World on my
system takes about 100ms to reach user code, and even the largest Java
application I still takes less than a second to reach user code after
all the classes have loaded).

Is there anything I can do to cut this down? If not, is this something
that's intended to be addressed in the near future?

[1] http://cr.yp.to/daemontools/tai64n.html
[2] The Maven output claims 6 seconds, but that doesn't include the
time it took for the build to start.

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



pgpfIHio6nPxi.pgp
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven Dependency Plugin version 3.1.0

[Mark Raynsford]

+1

Tested on multiple Java 9 projects with all sorts of Java 9
dependencies. No issues.


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



pgpnlcDViWCTx.pgp
Description: OpenPGP digital signature

Re: Maven Dependency Plugin ( was: Re: [RESULT] [VOTE] Release Shared Component Dependency Analyzer 1.9 - Take 2)

[Mark Raynsford]

On 2018-03-28T21:54:32 +0200
Karl Heinz Marbaise <khmarba...@gmx.de> wrote:
>
> If you check via:
> 
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.maven.shared%22%20AND%20a%3A%22maven-dependency-analyzer%22
> 
> and see a 1.9 version you can use the following SNAPSHOT of 
> maven-dependency-plugin: (I think tomorrow it will be available)..
> 
>  
> https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-dependency-plugin/3.1.0-SNAPSHOT/maven-dependency-plugin-3.1.0-20180328.194924-1.jar
> 

I've tested this on a few multi-module Java 9 projects (with Java 9
dependencies) and haven't seen any issues so far. The problem with
parsing 9 bytecode definitely seems to have been corrected.

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



pgp7YCMyzRHEp.pgp
Description: OpenPGP digital signature

Re: Maven Dependency Plugin ( was: Re: [RESULT] [VOTE] Release Shared Component Dependency Analyzer 1.9 - Take 2)

[Mark Raynsford]

On 2018-03-28T21:29:08 +0200
Karl Heinz Marbaise <khmarba...@gmx.de> wrote:

> Hi Mark,
> 
> just a question do you have the chance to test a SNAPSHOT version before 
> I start the VOTE of maven-dependency-plugin so we are sure it will fix 
> things...

Yes indeed, I can test as soon as you publish one.

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



pgpdfHQzD3Tw5.pgp
Description: OpenPGP digital signature

Re: [RESULT] [VOTE] Release Shared Component Dependency Analyzer 1.9 - Take 2

[Mark Raynsford]

On 2018-03-28T20:48:21 +0200
Karl Heinz Marbaise <khmarba...@gmx.de> wrote:

> Hi,
> 
> The vote has passed with the following result:
> 
> +1 : Hervé Boutemy, Robert Scholte, Karl Heinz Marbaise
> 
> PMC quorum: reached.
> 
> I will promote the artifacts to the central repo.

Nice work!

Can we have a new dependency plugin now? ;)

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



pgpHjAjKXjb9d.pgp
Description: OpenPGP digital signature

Non-deprecated way to get list of artifact versions

[Mark Raynsford]

Hello.

What is the correct, non-deprecated way to get a list of available
artifact versions given a group/artifact/type/classifier tuple?

It seems that previously, I would have talked to an
ArtifactMetadataSource, but this interface is either in a legacy
package or is deprecated, depending on which artifacts you depend on.

What's the modern way to do this?

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


pgpmiradkO7E9.pgp
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven Dependency Analyzer version 1.8

[Mark Raynsford]

+0.5 (non binding)

I haven't tested, but I'd like to see the dependency plugin move
forward, and this is needed to do it!

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



pgp4RJWgRf8Fi.pgp
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven Javadoc Plugin version 3.0.0 (take 3)

[Mark Raynsford]

On 2017-12-03T22:50:42 +0100
"Robert Scholte" <rfscho...@apache.org> wrote:
>
> We solved 27 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529=12330875=Text
> 

+1 (non-binding)

Pretty heavily tested on multiple projects. Both the javadoc and
aggregation goals have been tested with no issues.

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



pgpcZcihnqwm4.pgp
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven Javadoc Plugin version 3.0.0 (take 2)

[Mark Raynsford]

On 2017-11-18T17:44:23 +0100
Hervé BOUTEMY <herve.bout...@free.fr> wrote:

> JDK javadoc seems to cover the "aggregated javadocs" scenario: in Java 9 
> terms, that's "multi-modules" = exactly the case for JDK 9 javadoc [1]
> I don't know what's the command line to produce this, but looks feasible from 
> javadoc side
> 

It looked like a bug in the JavaDoc tool because the generation went
ahead and yet packages were placed into the wrong modules in the
output, but I think it might just be a matter of perspective. I think
the tool maybe worked correctly based on what it was given (a pile of
sources with some important module descriptors taken out).

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



pgpMYYDKLLnLf.pgp
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven Javadoc Plugin version 3.0.0 (take 2)

[Mark Raynsford]

On 2017-11-18T16:14:04 +
Mark Raynsford <org.apache.maven.u...@io7m.com> wrote:
> Presumably, with the module-info.java files
> excluded, it reverts back to plain classpath style JavaDoc.

Actually, it results in sort of weird looking JavaDoc that only
contains a single module, and claims that all packages are in
that module:

  http://outland.iw.int.arc7.info/2017/11/18/apidocs/index.html

That behaviour seems like it might be a bug in the actual JavaDoc tool
itself.

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



pgpvXwKtxV4Ds.pgp
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven Javadoc Plugin version 3.0.0 (take 2)

[Mark Raynsford]

On 2017-11-18T17:04:12 +0100
"Robert Scholte" <rfscho...@apache.org> wrote:

> That's similar to MJAVADOC-479[1]
> 
> Seems like all Java 9 issues are not resolved yet.
> I don't mind canceling the vote if we can fix this as well.
> 
> thanks,
> Robert
> 
> [1] https://issues.apache.org/jira/browse/MJAVADOC-479

Yeah, that does seem to be the one.

I think it'd be best to fix this. If I could apply a workaround, I'd
vote to release, but it seems that the workaround (excluding
module-info.java files) results in JavaDoc that doesn't contain any
module information. Presumably, with the module-info.java files
excluded, it reverts back to plain classpath style JavaDoc.

Your call!

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



pgpW6Drpb7mP9.pgp
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven Javadoc Plugin version 3.0.0 (take 2)

[Mark Raynsford]

Hello!

I'd like to vote on this issue, but I still have a remaining problem
and am not sure if it's because the plugin is broken due to the new
module changes, or just because my project setup is slightly
unusual.

See here:

https://github.com/io7m/maven-javadoc-bug-20171118

The "c" module attempts to aggregate the javadoc of the other modules
in the reactor into a single directory. It fails because the plugin
attempts to load the module descriptors of the other projects,
resulting in a "too many module descriptors" error.

This is a simplified version of a real project here (all of my
projects follow the same basic structure):

  https://github.com/io7m/jequality

The javadoc of all of the modules is aggregated into a directory and
combined with some other documentation into a .zip for deployment.

I'd could use the "aggregate" goal, but that causes too many problems
due to the way that the goal forks and re-runs previous goals bound to
the compile phase. Apart from anything, in larger projects with lots of
modules, re-running all of those goals takes unacceptably long.

It's not clear to me if this is actually a problem with the current
plugin, or just because I'm not supposed to do things this way.

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



pgp4jK7aghfEo.pgp
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven Javadoc Plugin version 3.0.0

[Mark Raynsford]

On 2017-11-17T19:00:54 +
Mark Raynsford <org.apache.maven.u...@io7m.com> wrote:

> -1 (non-binding)
> 
> The staged version still fails with a basic module setup:
> 
>   https://github.com/io7m/maven-javadoc-bug-20171117

I've submitted a PR that I believe fixes the issue, but I'm not sure if
it's already too late to get it into 3.0.0:

  https://github.com/apache/maven-plugins/pull/137

Releasing 3.0.0 as is simply won't work for multi-module builds (and
may be broken elsewhere, I don't know).

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



pgpQO_QFj9uyK.pgp
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven Javadoc Plugin version 3.0.0

[Mark Raynsford]

-1 (non-binding)

The staged version still fails with a basic module setup:

  https://github.com/io7m/maven-javadoc-bug-20171117

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



pgpI76h0Nsf03.pgp
Description: OpenPGP digital signature

Re: Any ETA for maven-javadoc-plugin 3.0.0?

[Mark Raynsford]

On 2017-11-12T15:15:49 +0100
"Robert Scholte" <rfscho...@apache.org> wrote:

> MJAVADOC-475 is about replacing a parameter, which makes it as critical as  
> MJAVADOC-457.
> We just consider 3.0.0 to be THE version to be able to do a cleanup, hence  
> MJAVADOC-475 must be fixed as well.
> 
> The good news is: MJAVADOC-457 and MJAVADOC-475 are finished. I don't see  
> any deprecated parameters anymore.
> 
> MJAVADOC-499 is a too dangerous proposal for me. So I don't mind moving  
> that issue forward, it is not critical for 3.0.0, there is a workaround  
> (or preferred solution depending on who you ask) for this issue.
> 
> Which means I can prepare the release this week.
> Just need to ensure all CI servers still accept the changes.

OK, thanks!

I look forward to it.

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



pgp71b_cipRhU.pgp
Description: OpenPGP digital signature

Re: Any ETA for maven-javadoc-plugin 3.0.0?

[Mark Raynsford]

'Ello.

On 2017-11-11T14:40:16 +0100
"Robert Scholte" <rfscho...@apache.org> wrote:

> I'd hope to do a release this month. Not sure if it'll be a M2 or not,  
> depends if all 3.0.0 prerequisites are met.

Right.

From what I can see, only MJAVADOC-475 is not really *critical* to the
release as it's just a new feature. The other two issues, MJAVADOC-457
and MJAVADOC-499, seem to be important. The former has been fixed, and
the latter appears to be leaning towards being rejected. I would really
appreciate an M2 release if MJAVADOC-475 is going to otherwise delay
3.0.0.

If there's anything I can do to assist, I'm available. Right now,
MJAVADOC-498 would appear to prevent the deployment of any modular
project to Maven Central: If module A in the project depends
on module B, then JavaDoc cannot be generated. This would necessitate
adding a temporary workaround that submits an empty javadoc jar to
Central (otherwise the Central ruleset rejects the deployment due to
missing JavaDoc). I have some 30-40 projects that are itching to be
deployed but can't be unless I add a workaround or build and deploy a
custom version of the plugin myself. I'd obviously prefer not to have
to do that.

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



pgpFD0e4jmvUj.pgp
Description: OpenPGP digital signature

Any ETA for maven-javadoc-plugin 3.0.0?

[Mark Raynsford]

'Lo.

I'm in the process of converting a ton of projects to Java 9 and am
currently blocked on MJAVADOC-498[0]. The issue has actually been
fixed, it just hasn't made it to a release yet.

If 3.0.0 isn't due for a while yet, is there any chance of getting a
3.0.0-M2?

[0] https://issues.apache.org/jira/browse/MJAVADOC-498

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



pgpXoz5sX6p9X.pgp
Description: OpenPGP digital signature

Re: maven-plugin-plugin due any time soon?

[Mark Raynsford]

On 2017-10-26T14:05:01 +
Mark Raynsford <org.apache.maven.u...@io7m.com> wrote:
>
> I'm running into what I think is MPLUGIN-304 [0] when upgrading
> several of my Maven plugins to JDK 9. The issue has been fixed, but I
> don't think that fix has made it into any release yet.

Sorry for the noise: I made a mistake. I thought I was using 3.5 but it
turns out I was actually using 3.4. Upgrading to 3.5 fixed the issue.

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



pgpCOflAsuqcU.pgp
Description: OpenPGP digital signature

maven-plugin-plugin due any time soon?

[Mark Raynsford]

Hello.

I'm running into what I think is MPLUGIN-304 [0] when upgrading
several of my Maven plugins to JDK 9. The issue has been fixed, but I
don't think that fix has made it into any release yet. Is there a
release of maven-plugin-plugin due any time soon?

Apologies if this information is online somewhere... I have no idea
where to look!

[0] https://issues.apache.org/jira/browse/MPLUGIN-304

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



pgpGx73hjdIs0.pgp
Description: OpenPGP digital signature

Re: Maven plugins, Java 9, and split packages

[Mark Raynsford]

On 2017-10-20T14:43:52 +0200
"Robert Scholte" <rfscho...@apache.org> wrote:
>
> > This looks to be a case of split packages amongst all of the various
> > Maven artifacts. I'm adding dependency exclusions to try to work around
> > the issues, but I'm not confident that'll actually work.
> >
> > Are there efforts underway to clean this stuff up?  
> 
> No, Maven has its own modular system long before the Java Platform Modular  
> System (JPMS)...

OK, makes sense. I was seeing errors related to Class.byName in some of
the exceptions I was seeing, so I mistakenly assumed that there was
some degree of modularization underway that possibly wasn't quite
complete yet. I suspect the actual problems I'm seeing here are just
out-of-date dependencies.

> > The reason I'm modularizing the plugin is due to this:
> >
> >   "To build and run japicmp under Java 1.9, you must add the following  
> > module: java.xml.bind. This can be done for the maven plugin for example  
> > by:
> >
> > export MAVEN_OPTS="--add-modules java.xml.bind"  
> 
> IIUC this doesn't mean you have to introduce a module descriptor (i.e.  
> module-info.java ).
> 
> The reason is that this module is marked as deprecated and won't be  
> activated by the JDK/JRE by default. By adding this argument it is loaded  
> anyway.
> 
> What you should try to do instead is add the following dependency:
> 
>  javax.xml.bind
>  jaxb-api
>  2.3.0
> 

Noted, thanks! I'll be testing this out today.

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



pgpm9GhabWg7Q.pgp
Description: OpenPGP digital signature

Maven plugins, Java 9, and split packages

[Mark Raynsford]

 maven.artifact reads package 
org.apache.maven.artifact.repository.layout from both maven.artifact and 
maven.core
[ERROR] module maven.artifact reads package org.apache.maven.artifact.metadata 
from both maven.artifact and maven.core
[ERROR] module maven.artifact reads package org.apache.maven.artifact.handler 
from both maven.artifact and maven.core
[ERROR] module maven.artifact reads package 
org.apache.maven.artifact.handler.manager from both maven.artifact and 
maven.core
[ERROR] module maven.artifact reads package org.apache.maven.artifact.factory 
from both maven.artifact and maven.core
[ERROR] module com.google.common reads package org.apache.maven.plugin from 
both maven.plugin.api and maven.core
[ERROR] module com.google.common reads package org.apache.maven.artifact from 
both maven.artifact and maven.core
[ERROR] module com.google.common reads package 
org.apache.maven.artifact.resolver from both maven.artifact and maven.core
[ERROR] module com.google.common reads package 
org.apache.maven.artifact.resolver.filter from both maven.artifact and 
maven.core
[ERROR] module com.google.common reads package 
org.apache.maven.artifact.repository from both maven.artifact and maven.core
[ERROR] module com.google.common reads package 
org.apache.maven.artifact.repository.metadata from both maven.artifact and 
maven.core
[ERROR] module com.google.common reads package 
org.apache.maven.artifact.repository.layout from both maven.artifact and 
maven.core
[ERROR] module com.google.common reads package 
org.apache.maven.artifact.metadata from both maven.artifact and maven.core
[ERROR] module com.google.common reads package 
org.apache.maven.artifact.handler from both maven.artifact and maven.core
[ERROR] module com.google.common reads package 
org.apache.maven.artifact.handler.manager from both maven.artifact and 
maven.core
[ERROR] module com.google.common reads package 
org.apache.maven.artifact.factory from both maven.artifact and maven.core

This looks to be a case of split packages amongst all of the various
Maven artifacts. I'm adding dependency exclusions to try to work around
the issues, but I'm not confident that'll actually work.

Are there efforts underway to clean this stuff up?

The reason I'm modularizing the plugin is due to this:

  "To build and run japicmp under Java 1.9, you must add the following module: 
java.xml.bind. This can be done for the maven plugin for example by:

export MAVEN_OPTS="--add-modules java.xml.bind"

I'd rather not have to do this as I'm committed to having all of my
project builds run without needing extra Maven flags: "mvn clean install"
*must* just work on every system, no exceptions.

Am I undertaking a fool's errand trying to get this stuff to work cleanly?
If not, is there any documentation on modularizing existing plugins?

[0] https://github.com/siom79/japicmp/

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



pgp_PxSu3QvkH.pgp
Description: OpenPGP digital signature

Re: Starting a pure Java 9 modular project

[Mark Raynsford]

On 2017-09-18T19:44:54 +0200
"Robert Scholte" <rfscho...@apache.org> wrote:

> For every deliverable you will have one Maven project (and 1 pom.xml).
> So for a Maven point of view it doesn't make sense to support the jigsaw  
> multi module option.

Good! That's what I'd suspected (and hoped!)

> Here are the things you *DON'T* have to change:
> - folder structure
> - dependencies of your pom.xml (you don't specify which jars are modules  
> and which aren't, Maven will resolve that for you.
> 
> You only have to add the module-info.java to the source root and use at  
> least maven-compiler-plugin 3.7.0

Got it.

Presumably I also need to tell the compiler that I want to produce code
for release 9 via the plugin equivalent of the new --release flag?
Assuming there is one, that is. I understand the bytecode version has
been incremented again, so I'd want to be producing 9 bytecode.

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


pgpEBxYq3Hgxj.pgp
Description: OpenPGP digital signature

Re: Starting a pure Java 9 modular project

[Mark Raynsford]

On 2017-09-18T19:06:12 +0200
Karl Heinz Marbaise <khmarba...@gmx.de> wrote:

> Hi Mark,
> 
> On 18/09/17 17:11, Mark Raynsford wrote:
> > 
> > The directory layout is "src/com.me.mymodule/module-info.java". This
> > obviously doesn't match the "src/main/java" convention that Maven uses.  
> 
> That is the same which comes to my mind if I see such examples...
> 
> But I don't see any requirement for that nor do I see any advantage 
> about this approache?...

Me neither. I get the feeling they just made one up as they modularized
the JDK. I've built the JDK quite a few times, but I never actually
looked into what they're using to build the Java sources. It appears
that it's just Makefiles, so they presumably didn't have the
conventions of any existing tool to work with.

> What I've seen in OSGi is to name the directories according to the 
> modules (bundle names) but this often leads into duplication
> like:

Yep, I actually adopted this convention myself at the start of the
year. I think the one advantage to this over the short form is that it
can make it slightly easier to find modules in the filesystem if you
have a lot of source trees:

  $ find . -name 'com.io7m.example' -type d

> I think the best suggestion I can give is to keep the conventions 
> ...cause from my current point of view you don't have disadvantages...
>
> But we would be very interested if there are some if you make 
> experiences in that way...

Yeah, I would prefer to stick to the Maven conventions.

> > Is the intention to map Maven modules 1:1 with Jigsaw modules? Or if
> > not 1:1, then perhaps "no more than one Jigsaw module per Maven module".  
> 
> I think one Jigsaw module per Maven module otherwise you need to leave 
> the conventions based on module-info.javaetc...

Right.

> > Is there documentation available anywhere that describes how new pure
> > Java 9 (multi-module!) projects should be set up?
> >   
> 
> I think it's time to make some docs based on the current state of 
> experience and if you like please add information or begin with such 
> docs about that..we would appreciate such things...

Well, in a few weeks time, I'll have at least attempted to modularize
some 60 different projects. They're all OSGi compatible, so the
difficult work has already been done. Just need to write module
descriptors and update plugins and definitions to produce 9 bytecode.

I can certainly write something up. Where would I be putting this
documentation?

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


pgpCIzRns9WNt.pgp
Description: OpenPGP digital signature

Starting a pure Java 9 modular project

[Mark Raynsford]

Hello.

With Java 9 due out in a few days time, I'm looking at moving all of my
60+ projects to Java 9. I have no intention of keeping support for any
version of Java less than 9, so the projects will become pure Java 9
(modularized) projects.

I'm curious as whether Java 9 changes any of the conventions that I've
been used to in Maven for the past five or so years. For example, one
thing I see frequently in Java 9 tutorials is that they use a
directory layout that differs from the Maven standard. For example,
consider this tutorial:

  https://dzone.com/articles/java-9-tutorial-step-by-step-from-zero-to-modules

The directory layout is "src/com.me.mymodule/module-info.java". This
obviously doesn't match the "src/main/java" convention that Maven uses.

Is the intention to map Maven modules 1:1 with Jigsaw modules? Or if
not 1:1, then perhaps "no more than one Jigsaw module per Maven module".

Is there documentation available anywhere that describes how new pure
Java 9 (multi-module!) projects should be set up?

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


pgpjkh2DBOXmG.pgp
Description: OpenPGP digital signature

Re: Improvements to analyze goal of maven-dependency-plugin

[Mark Raynsford]

On 2017-06-14T11:51:46 +
Jonathan Haber  wrote:
> Here an is example of the output before and after:
>
> https://gist.github.com/jhaber/d8204829fe61569e0034250df74300fb
> 
> Do you think this feature adds value? Any suggestions?

This is wonderful! Nice work.

M


pgp9I3Nk8m4p4.pgp
Description: OpenPGP digital signature