[RESULT][VOTE] Require Java 17 for Maven 4

[Benjamin Marwell]

Hi all,

the vote has passed with the following result:

PMC +1: Anders Hammar, Arnaud Héritier, Benjamin Marwell, Guillaume
Nodet, Hervé Boutemy, Karl Heinz Marbaise, Konrad Windszus, ,Maarten
Mulders, Olivier Lamy, Romain Manni-Bucau, Sylwester Lachiewicz, Tamás
Cservenák

PMC majority quorum: reached.

Community results:

+1: A.J. Jarmoniuk, Bernd Eckenfels, Brian Demers, Ceki Gulcu,
Christian Stein, Christoph Läubrich, David Jencks, Dirk Olmes, Enrico
Olivelli, Frederik Boster, Gary Gregory, Giacomo Boccardo, Jacques
Etienne Beaudet, Jean-Baptiste Onofré, Jeremy Landis, Jesper Udby,
John Neffenger, Jorge Solórzano, Joseph Kesselman, Kemal Soysal, Kévin
Buntrock, Lasse Lindqvist, Manfred Moser, Mantas Gridinas, Manuel
Dahmen, Mark Eggers, Martin Desruisseaux, Mateusz Gajewski, Matthias
Bünger, Michael Bien, Niels Basjes, Robert Dean, Rodrigo Bourbon,
Slawomir Jaranowski, Stephane Nicoll, Thomas Matthijs, Thorsten Heit,
Tim te Beek, Van Hoa Phan, Xeno Amess, Yeikel Santana, zhongming hua

-1: Elliotte Rusty Harold

We will proceed with the transition of Maven 4 to a Java 17 baseline.
Plugins will also get a "plugin history" page where it will be
documented which version requires which Java version. As a general
rule, we will keep 3.x plugins on Java 8 (notable exception is the
m-jlink-p for obvious reasons).

Thanks everyone for voting and all your voices in the preceding discussions!

- Ben

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

[VOTE] Require Java 17 for Maven 4

[Benjamin Marwell]

Hi Maven Devs/Users/Committers and PMC members!

After several discussions on the mailing lists, I would like to
start a vote in favour of setting the minimal Java bytecode target
of Maven-Core 4 to 17 and hence require Java 17 for Maven 4.

This is a procedural majority vote [1*]:
You can also vote with fractions and negative votes are not vetoes.

Please also notice:
* Maven 3 will stay at Java 8 no matter what.
* We may raise Maven 4 to JDK 21 later if we feel like it (depending
on the release date).
  This is not part of this vote.
* The linked PR is not part of this vote (this is not a code vote).
  But you may take a look at it to understand the intended change.

PR: https://github.com/apache/maven/pull/1430

Maven-Parent will not be raised with this vote, the other PR is not
part of this vote.

Please refrain from starting discussions in this thread, but do
include a reasoning on downvotes and feel free to start a new
discussion on the mailing list, or comment on the existing ones.

---

Vote open for 72 hours:

[ ] +1 (set JDK17 min version for Maven 4.x)
[ ] +0
[ ] -1 (please include reasoning)

---

- Ben

[1*]: https://www.apache.org/foundation/voting.html

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

[ANN] Apache Maven JLink Plugin 3.2.0 Released

[Benjamin Marwell]

The Apache Maven team is pleased to announce the release of the Apache
Maven JLink Plugin, version 3.2.0

The JLink Plugin is intended to create modular Java Run-Time Images via jlink.

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

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


  org.apache.maven.plugins
  maven-jlink-plugin
  3.2.0


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

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

Release Notes - Maven JLink Plugin - Version 3.2.0

Bug

[MJLINK-62] - Replace ByteArrayOutputStream with StringWriter
[MJLINK-64] - Add-options double quoting

New Feature

[MJLINK-75] - Reproducibility of ZIP artifacts

Improvement

[MJLINK-69] - Update to Java 11
[MJLINK-76] - Upgrade maven-plugin parent to 41

Task

[MJLINK-77] - Update description and parameters of --compress to
reflect JDK21 changes

Dependency upgrade

[MJLINK-63] - Upgrade plexus-java
[MJLINK-66] - Update parent pom to 39
[MJLINK-70] - Update m-site-p to 3.12.1
[MJLINK-71] - Require Maven 3.6.3 as new baseline
[MJLINK-72] - Remove common-lang3
[MJLINK-74] - Update org.codehaus.plexus:plexus-archiver from 4.7.1 to 4.9.1


Enjoy,

-The Apache Maven team

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

Re: Keeping java's version in sync with project's version

[Benjamin Marwell]

Hi Joseph!

Not really sure what you mean by "keep java's version in sync".
Since you said "-version option on my project", I am guessing you have
a CLI app and you want to report the version which you specify in your
pom.xml file.

Now to do that and have it working with your project, here are the
steps I usually take.
This is just an extended version of what Alex already wrote.

If you have a multi-module project, and you want to access your
project version in many other modules, just create a dedicated module.
You can also apply the steps to a single-module project.

This module should have a class in its own package (Maybe Version.java).
It should load a file "version.properties" from the src/main/resources folder.
Now the trick: put it into the same directory structure as your
Version.java file's package.

For the file to get populated, add this line:
my.project.version=${project.version}

Now, enable resource filtering for your project [1].
When building the project, you should see the filtered file:
   ${module}/target/classes/path/to/package/version.properties (next
to the compiled Version.class).

In your Version.java, load the file using the standard Properties
mechanism and expose the version via a simple getter.
This way you can use the version in other modules, too.

If you want to add other properties, you can add plugins like the
build-number-maven-plugin to your build.

This way you do not need to rely on parsing xml or property files
which may be out of scope for your classes.

HTH,
- Ben

[1] - 
https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html


Am Do., 9. Nov. 2023 um 01:18 Uhr schrieb Joseph Kessselman
:
>
> For obvious reasons, if would be nice if the -version option on my
> project automatically reported the version I'd set in the pom.xml rather
> than my trying to synchronize the two manually.
>
> The best approaches I've found so far are in
> https://stackoverflow.com/questions/2712970/get-maven-artifact-version-at-runtime
> ... but there's a note that at least one of them doesn't work in all
> classloaders, or in openjdk.
>
> I'm willing to have the pom write this into a file that the Java code
> would query, if that's what it takes to have a portable solution, but
> I'm not sure what the best way to express that would be.
>
>
> There must be an established Best Practices solution for this, right?
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

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

Re: how to disable http 100-continue with 3.9 http-transport ?

[Benjamin Marwell]

Hi,

Disabling parallel put works for me.

https://maven.apache.org/resolver/configuration.html


On Fri, 27 Oct 2023, 20:08 Tamás Cservenák,  wrote:

> Howdy,
>
> Are you sure you have to disable use of http-continue? Isn't this something
> "legacy" or hack that you try to carry on maybe?
>
> Is it documented somewhere that Nexus3 does not support http-continue?
>
> If you have support contract, I'd ask your provider about this first...
>
> Thanks
> T
>
> On Fri, Oct 27, 2023, 18:37 Stefan CORDES  .invalid>
> wrote:
>
> > Hi,
> > we configured the 3.8 wagon transport to not send a http-continue as this
> > fails with our nexus3 to store the artifacts.
> >
> > Switching to maven 3.9 the new transport is taken where I cannot find how
> > to disable the http 100
> >
> >
> >
> https://github.com/apache/maven-resolver/blob/master/maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/LocalState.java#L82
> >
> > How can I disable sending
> > [DEBUG] org.apache.http.headers - http-outgoing-0 >> Expect: 100-continue
> > while using mvn deploy?
> >
> > Gruß,
> > Stefan
> >
> > P.S.:
> > Nexus http response is 500 with http-continue and nexus.log shows
> >
> > 2023-10-27 18:19:57,155+0200 WARN  [qtp804177152-23427]  x
> > org.sonatype.nexus.repository.httpbridge.internal.ViewServlet - Failure
> > servicing: PUT
> >
> /repository/Snapshots/com/canda/mule4/x-mule4-template/1.0.0-local-SNAPSHOT/x-mule4-template-1.0.0-local-20231027.161836-1-mule-application.jar
> > org.sonatype.nexus.blobstore.api.BlobStoreException: BlobId:
> > tmp$d7b33f72-f9be-4fc8-b444-73d98adde3f1, java.io.IOException:
> > java.util.concurrent.TimeoutException: Idle timeout expired: 3/3
> > ms, Cause: java.util.concurrent.TimeoutException: Idle timeout expired:
> > 3/3 ms
> > at
> >
> org.sonatype.nexus.blobstore.file.FileBlobStore.tryCreate(FileBlobStore.java:438)
> > at
> >
> org.sonatype.nexus.blobstore.file.FileBlobStore.create(FileBlobStore.java:368)
> > at
> >
> org.sonatype.nexus.blobstore.file.FileBlobStore.doCreate(FileBlobStore.java:348)
> > at
> >
> org.sonatype.nexus.blobstore.metrics.BlobStoreAnalyticsInterceptor.invoke(BlobStoreAnalyticsInterceptor.java:60)
> > at
> >
> org.sonatype.nexus.blobstore.BlobStoreSupport.create(BlobStoreSupport.java:125)
> > at
> >
> org.sonatype.nexus.common.stateguard.MethodInvocationAction.run(MethodInvocationAction.java:39)
> > at
> >
> org.sonatype.nexus.common.stateguard.StateGuard$GuardImpl.run(StateGuard.java:272)
> > at
> >
> org.sonatype.nexus.common.stateguard.GuardedInterceptor.invoke(GuardedInterceptor.java:54)
> > at
> >
> org.sonatype.nexus.blobstore.BlobStoreSupport.create(BlobStoreSupport.java:109)
> > at
> >
> org.sonatype.nexus.common.stateguard.MethodInvocationAction.run(MethodInvocationAction.java:39)
> > at
> >
> org.sonatype.nexus.common.stateguard.StateGuard$GuardImpl.run(StateGuard.java:272)
> > at
> >
> org.sonatype.nexus.common.stateguard.GuardedInterceptor.invoke(GuardedInterceptor.java:54)
> > at
> >
> org.sonatype.nexus.repository.storage.StorageFacetImpl.createTempBlob(StorageFacetImpl.java:266)
> > at
> >
> org.sonatype.nexus.repository.storage.StorageFacetImpl.createTempBlob(StorageFacetImpl.java:277)
> >
> >
> > C Services GmbH & Co. OHG | Wanheimer Straße 70 | D-40468 Düsseldorf |
> > Sitz: Düsseldorf | Registergericht: Düsseldorf HRA 12655 | Telefon: +49
> > (211) 9872-01
> > Persönlich haftende Gesellschafter: C Retail GmbH | Sitz: Baar/Schweiz
> |
> > UID: CHE-116.290.471
> > Geschäftsführung: Giny Boer, Christoph Hammer
> > FRM Participations S.A. | Sitz: Strassen/Luxemburg | Handels- und
> > Firmenregister Luxemburg: B 58158
> > Verwaltungsratsmitglieder: Dr. Christian Bank, Remco Gerlof, Dr.
> > Franz-Josef Leuchtenberg
> > Hinweise zur Verarbeitung Ihrer Daten finden Sie unter: www.c-a.com/GDPR
> <
> > http://www.c-a.com/GDPR>
> >
>

Re: Maven build error

[Benjamin Marwell]

If you browse their repo, you can see that 4.2.1 is indeed missing:
https://repository-master.mulesoft.org/nexus/content/repositories/releases/org/mule/tests/mule-tests/

Just use dependencyManagement to override the version or exclude it
(if it is transitive) from its parent dependency and add it back
manually.

HTH

- Ben

Am Do., 27. Juli 2023 um 19:46 Uhr schrieb Nils Breunese :
>
> Maven says it can’t find 
> org.mule.tests.plugin:mule-tests-component-plugin:jar:mule-plugin:4.2.1 at 
> https://repository-master.mulesoft.org/nexus/content/repositories/releases/
>
> I can’t find it myself either, because there is no tests directory under 
> https://repository-master.mulesoft.org/nexus/content/repositories/releases/org/mulesoft/
>
> You’ll either need to make sure that this artifact is present in this 
> repository, or configure an (additional) repository which contains this 
> artifact.
>
> Nils.
>
> > Op 27 jul. 2023 om 19:21 heeft Willfin David  het 
> > volgende geschreven:
> >
> > 
> > Hi,
> >
> > Im using maven as part of my mulesoft anytime studio platform.
> > When I run the below command from command prompt I get the error below.
> >
> > Let me know how to resolve this error.
> >
> > Command:
> > maven -U clean install
> >
> > Error:
> > [ERROR] Failed to execute goal on project mule-connectivity-parent: Could 
> > not resolve dependencies for project 
> > com.mulesoft.connectors:mule-connectivity-parent:pom:3.3.1-RUNTIME.4.2.1: 
> > Failed to collect dependencies at 
> > org.mule.tests.plugin:mule-tests-component-plugin:jar:mule-plugin:4.2.1: 
> > Failed to read artifact descriptor for 
> > org.mule.tests.plugin:mule-tests-component-plugin:jar:mule-plugin:4.2.1: 
> > The following artifacts could not be resolved: 
> > org.mule.tests:mule-tests:pom:4.2.1 (absent): Could not find artifact 
> > org.mule.tests:mule-tests:pom:4.2.1 in mule-releases 
> > (https://repository-master.mulesoft.org/nexus/content/repositories/releases/)
> >  -> [Help 1]
> >
> >
> >
> >
> >
> >
> > ___
> > The information contained in this communication is intended solely for the 
> > use of the individual or entity to whom it is addressed and others 
> > authorized to receive it. It may contain confidential or legally privileged 
> > information. If you are not the intended recipient you are hereby notified 
> > that any disclosure, copying, distribution or taking any action in reliance 
> > on the contents of this information is strictly prohibited and may be 
> > unlawful. If you have received this communication in error, please notify 
> > us immediately by responding to this email and then delete it from your 
> > system. EY is neither liable for the proper and complete transmission of 
> > the information contained in this communication nor for any delay in its 
> > receipt.

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

Re: Questions about the build cache plugin

[Benjamin Marwell]

Am Mo., 12. Juni 2023 um 12:08 Uhr schrieb Olivier Lamy :

> On Mon, 12 Jun 2023 at 18:53, Benjamin Marwell  wrote:
> >
> > Hello everyone!
> >
> > First of all thank you everyone working on the build cache plugin! It
> > is amazing!
> >
> > At least some of  the following questions seem to be of interest to
> > most users and might end up on the documentation, So here's a few
> > things which came to my mind.
> >
> > 1.) Considering I always require PRs in my projects, would setting
> > -Dmaven.build.cache.remote.save.enabled=true be a sensible thing only
> > for the main branch?
>
> Personally, I would have the main branch always have a full build
> without caching to be sure everything works fine but use cache only
> for branches/PR :)
> That's what we will do at Jetty project.
> The build for 12 branch is around 50 minutes with the cache it goes
> down to 8/9 minutes (only because something is always rebuilt and
> retrigger a few small modules)
> The idea is to reduce development/check of PR and use some incremental
> build while the main is always fully build especially when the build
> has few jdks as target.
> But here it's up to you :)

I can see your point, but who is updating the remote cache then?



> > 2.) Can I maybe have  the branch name included in a path to a remote?
> > This way I could have a different cache for maintenance branches. Just
> > include the branch name into -Dmaven.build.cache.remote.url?
>
> why would need that?
> if your branch has different sources (java, pom, etc..) the calculated
> hash will be different so the hash key will be simply different no
> need to configure a cache URL differently (well except if you want to
> clean up caches per branch)

It depends on what you might be trying to do. For projects with new
major versions and some
big refactoring done in the past, this did sound sensible to me.
What is the cache worth if there's 0% hit on the maintenance branch?



> > 3.) Can I somehow use option 1 & 2 to make caches available for
> > colleagues without making them manually configure the remote URL for
> > each branch they are working on?
>
> cache will be used by colleagues' build as long as a module have the
> same calculated hash any local differences will have a different
> calculated hash

Same as above:
What about devs working on a maintenance branch when main has seen big
refactoring?


> > 4.) The docs say there's also XX and XXMM algorithms, but it doesn't
> > say WHEN to use them (only that they may leverage performance). Are
> > there some example cases or does someone already have some experience
> > we could benefit from?
>
> I have yet to see huge differences.
> currently with a build already down from 50 minutes to 8/9 minutes not
> sure this was my primary goal
> So I can't really tell :)

Well, it is listed under "performance tuning", so I concluded it might
make a difference.
Will probably go for XX (because it is mentioned as performance tuning
without any drawbacks)
 and switch to Metro once it is there.


> > 5.) The section "filtering out artifacts" might want to give a size of
> > artifacts which should be regarded as too large, depending on the
> > environment probably.
> >
>
> definitely depends on your environment.

Yup.
I might use different settings in a corporate environment, my thought.

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

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

Questions about the build cache plugin

[Benjamin Marwell]

Hello everyone!

First of all thank you everyone working on the build cache plugin! It
is amazing!

At least some of  the following questions seem to be of interest to
most users and might end up on the documentation, So here's a few
things which came to my mind.

1.) Considering I always require PRs in my projects, would setting
-Dmaven.build.cache.remote.save.enabled=true be a sensible thing only
for the main branch?

2.) Can I maybe have  the branch name included in a path to a remote?
This way I could have a different cache for maintenance branches. Just
include the branch name into -Dmaven.build.cache.remote.url?

3.) Can I somehow use option 1 & 2 to make caches available for
colleagues without making them manually configure the remote URL for
each branch they are working on?

4.) The docs say there's also XX and XXMM algorithms, but it doesn't
say WHEN to use them (only that they may leverage performance). Are
there some example cases or does someone already have some experience
we could benefit from?

5.) The section "filtering out artifacts" might want to give a size of
artifacts which should be regarded as too large, depending on the
environment probably.

Thanks!
- Ben

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

Re: NPE Exception with Surefire3.0.0

[Benjamin Marwell]

Which version of Maven are you using?
Can you give us a relevant snippet of your pom.xml to reproduce the issue?



On Mon, 17 Apr 2023, 17:07 Sirisha Alla,  wrote:

> Hi All,
>
> I am using surefire 3.0.0 with Junit 5 (Jupiter-engine). However, I am
> stumbling in to the Null Pointer Exception and could not trace the issue.
> Has anyone faced this issue or any pointers that can help me proceed? I am
> using JDK1.8.
>
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.hasGroupArtifactId
> (AbstractSurefireMojo.java:1771)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.retainInProcArtifactsUnique
> (AbstractSurefireMojo.java:1757)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.newStartupConfigWithClasspath
> (AbstractSurefireMojo.java:1735)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.createStartupConfiguration
> (AbstractSurefireMojo.java:1701)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.createForkStarter
> (AbstractSurefireMojo.java:2165)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider
> (AbstractSurefireMojo.java:1192)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked
> (AbstractSurefireMojo.java:1055)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute
> (AbstractSurefireMojo.java:871)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:370)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:351)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:171)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:163)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:210)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:195)
> at java.util.concurrent.FutureTask.run (FutureTask.java:266)
> at java.util.concurrent.Executors$RunnableAdapter.call
> (Executors.java:511)
> at java.util.concurrent.FutureTask.run (FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:624)
> at java.lang.Thread.run (Thread.java:748)
>
> Thanks,
> Sirisha
>
>
>

Re: plugin of a plugin

[Benjamin Marwell]

Maybe.

Some plugins, like jreleaser, just use Map. There's not
enough information for validation.

The other configuration (using POJOs) could probably be validated. However,
it's quite a bit of work (reflection, XML parsing).

If you're interested, why not just start a POC using an extension or a
plugin?






On Sat, 15 Apr 2023, 08:39 Delany,  wrote:

> Thanks, I keep forgetting about its custom nature. I've asked before, but
> do you think its possible for Maven to validate the configuration elements
> like Intellij does?
>

Re: plugin of a plugin

[Benjamin Marwell]

Hi,

doesn't look odd the moment you know plugin authors can name configuration
elements anything they want. They could call it , but that doesn't
make it an UFO.

That said, spotbugs seems to use the findbugs artifact as a dependency in a
plugin like manner. They just choose to call it that way.

What is odd is:
Usually you could just declare plugin dependencies, and they could have
discovered them automatically. I don't know why they chose this way instead.

tl;dr: it's a custom thing. You cannot declare plugin>config>plugins on any
other plugins.

HTH




On Fri, 14 Apr 2023, 09:44 Delany,  wrote:

> Hi. Two things look odd here
>
> 
>   com.github.spotbugs
>   spotbugs-maven-plugin
>   4.7.3.4
>   
> 
>   
> com.h3xstream.findsecbugs
> findsecbugs-plugin
> 1.12.0
>   
> 
>   
>
> Whats the difference between declaring plugins dependencies and declaring
> plugin plugins?
> Only dependencies are mentioned here:
> https://maven.apache.org/guides/mini/guide-configuring-plugins.html
>
> And why is findsecbugs-plugin-1.12.0.jar copied to
> ${project.build.directory} when I run mvn spotbugs:check?
>
> Kind regards,
> Delany
>

Re: How to configure Maven for an overloaded intranet repository?

[Benjamin Marwell]

There are two approaches for your issue.

First of all, you can try to use caches, so you don't need to download
dependencies over and over again. There are also settings which might help,
see the system properties in WAGON-545 [1]. E.g. retries and timeouts.

But.
To me it sounds from your description that your internal repo mirror needs
some HA / scaling set up.
Refer to the guides from nexus [2] and artifactory [3] for more
information. Have nodes near your locations and configure the LBs to prefer
near nodes.



[1] - https://issues.apache.org/jira/browse/WAGON-545
[2] -
https://help.sonatype.com/repomanager3/planning-your-implementation/resiliency-and-high-availability/high-availability-clustering-%28legacy%29/configuring-nodes
[3] - https://www.jfrog.com/confluence/display/JFROG/High+Availability


On Thu, 29 Sept 2022, 20:23 David Karr,  wrote:

> I work in a very large enterprise that uses a centralized intranet maven
> repository to get artifacts from.  It often has load issues that result in
> builds failing with "failed to respond".  The team that maintains it is
> working towards eventual mitigations for that, but it will be quite a while
> before that actually happens.
>
> What knobs or dials can I get to to make the connection to the remote
> repository more resilient?  The error "failed to respond" sounds like a
> connection timeout, not a read timeout, but I can't tell. What property
> values can I override that would help here?
>

Re: JUnit 5 in maven-plugin-testing-harness

[Benjamin Marwell]

Haven't seen a discussion in Slack or on the mailing list, so I guess no.

But I like the idea. Be aware that there are still Junit3 tests iirc.
Updating would be a breaking change, but that's okay for the upcoming Maven
4 release.







On Fri, 12 Aug 2022, 01:37 Vladimir V. Bychkov,  wrote:

> Hello everyone.
>
> Maven-plugin maven-plugin-testing-harness
> 
> still uses JUnit 4
> 
> . Are where plans upgrade it to JUnit 5 ?
>
> With regards,
> Vladimir V. Bychkov
>
>
>

Re: [ANN] Apache Maven Wrapper 3.1.1 Released

[Benjamin Marwell]

Thanks everyone involved, and thank you to Brian Demers for starting this
project in the first place!




On Sat, 14 May 2022, 16:07 Hervé Boutemy,  wrote:

> The Apache Maven team is pleased to announce the release of the Apache
> Maven
> Wrapper, version 3.1.1.
>
> The Maven Wrapper is an easy way to ensure a user of your Maven build has
> everything necessary to run your Maven build.
>
> This is the first release of this project in its Apache Maven new home: it
> was
> previously maintained by community at
> https://github.com/takari/maven-wrapper
> and was kindly donated to the Maven team. Thank you to all people who
> permitted this.
>
> See https://maven.apache.org/wrapper/ for instructions on how to use this
> updated Maven Wrapper.
>
> You can download the appropriate sources etc. from the download page:
>
> https://maven.apache.org/wrapper/download.cgi
>
>
> Release Notes - Maven Wrapper - Version 3.1.1
>
> ** Bug
> * [MWRAPPER-21] - Arbitrary file write during archive extraction ("Zip
> Slip") in wrapper
> * [MWRAPPER-38] - build from source-release has different result from
> Git
> * [MWRAPPER-40] - Wrapper Properties File License system dependant
> line
> separator
> * [MWRAPPER-41] - Goals documentation missing from site
> * [MWRAPPER-42] - maven-wrapper fails to self-update maven-wrapper.jar
> * [MWRAPPER-44] - maven-wrapper may use outdated
> MavenWrapperDownloader.class
> * [MWRAPPER-58] - curl cannot follow 302 code when downloading wrapper
> jar
>
> ** Improvement
> * [MWRAPPER-39] - release as maven-wrapper instead of
> maven-wrapper-parent
> * [MWRAPPER-43] - Download of jar must be quiet by default
> * [MWRAPPER-47] - Use name wrapperUrl consistently in Maven Wrapper
> files/
> scripts
> * [MWRAPPER-49] - add Wrapper version in mvnw/mvnw.cmd scripts
> * [MWRAPPER-51] - Refactor using Java Path API (NIO.2)
> * [MWRAPPER-53] - cygwin path tidy for java and class
>
> ** Task
> * [MWRAPPER-56] - Remove M2_HOME from mvnw script
>
> ** Dependency upgrade
> * [MWRAPPER-62] - Upgrade Parent to 35
> * [MWRAPPER-63] - Upgrade Parent to 36
>
>
> Enjoy,
>
> -The Apache Maven team
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: How can I tell what value of "maxmem" the maven-compiler-plugin is using by default?

[Benjamin Marwell]

Yes, it's using the javac compilers default.
It may differ depending on the JVM. OpenJ9, for example, will use up to 25%
of your memory by default. Others may use something between 64M and 512M.

Be aware that maxmem will only work if fork is set to true:
https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#maxmem

Otherwise (no forking) compiling is done in the same process as Maven is
running in. You can then use -Xmx (eg in the .mvn config) as usual.


 Ben

On Fri, 1 Apr 2022, 20:10 KARR, DAVID,  wrote:

> > -Original Message-
> > From: KARR, DAVID 
> > Sent: Friday, April 1, 2022 11:03 AM
> > To: Maven Users List 
> > Subject: How can I tell what value of "maxmem" the maven-compiler-plugin
> > is using by default?
> >
> > I noticed that we have one build that is trying to compile so many files
> > that it is running out of memory in the maven-compiler-plugin execution.
> > I see that I can set the "maxmem" property in that plugin's
> > configuration.  What would be nice to know is what the default value is.
> > I thought that perhaps "mvn -X" would tell me that, but that only tells
> > me that the default value is "${maven.compiler.maxmem}".  That doesn't
> > help me.  How can I get the default value of this property, or any
> > particular property, from a given pom?
>
> Self-answering, I guess if this is simply not providing a value if none is
> provided, that would leave it to the default maxmem for the jvm, which I
> guess is 256mb.  Is that what is happening here?
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

[ANN] taglist-maven-plugin v3.0.0 released!

[Benjamin Marwell]

Hi,

The Mojo team is pleased to announce the release of the
taglist-maven-plugin version 3.0.0.

The Taglist Maven Plugin generates a report on various tags found in
the code, like @todo or //TODO tags.

https://www.mojohaus.org/taglist-maven-plugin/

To get this update, simply specify the version in your project's
plugin configuration:


org.codehaus.mojo
taglist-maven-plugin
3.0.0


This is the first version to natively support Maven 3.

Release Notes

https://github.com/mojohaus/taglist-maven-plugin/releases/tag/taglist-maven-plugin-3.0.0


Enjoy,

The Mojo team.

- Ben

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

Re: Unable to clone the maven repositories

[Benjamin Marwell]

Hi Sandeep,

yesterday almost everyone had problems getting artifacts from maven
central, it should be resolved by now.
My guess is that a lot of developers pushed their updated artifacts
b/c of the log4j2 issue.

If you have a in internal build server and cannot accept downtimes,
you can install a repository mirror like
artifactory, nexus or Apache Archiva.

- Ben

Am Di., 14. Dez. 2021 um 18:27 Uhr schrieb Sandeep Sundarapu
:
>
> Hi Team ,
>  Could you please help me for the below issues
>
> -bash-4.2$ mvn package
> [INFO] Scanning for projects...
> [INFO]
> [INFO] --< oracle.km.provision:km-provision
> >--
> [INFO] Building km-provision 1.0.0-master-SNAPSHOT
> [INFO] [ jar
> ]-
> Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-resources-plugin/3.2.0/maven-resources-plugin-3.2.0.pom
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time:  02:10 min
> [INFO] Finished at: 2021-12-14T00:00:30-08:00
> [INFO]
> 
> [ERROR] Plugin org.apache.maven.plugins:maven-resources-plugin:3.2.0 or one
> of its dependencies could not be resolved: Failed to read artifact
> descriptor for org.apache.maven.plugins:maven-resources-plugin:jar:3.2.0:
> Could not transfer artifact
> org.apache.maven.plugins:maven-resources-plugin:pom:3.2.0 from/to central (
> https://repo.maven.apache.org/maven2): transfer failed for
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-resources-plugin/3.2.0/maven-resources-plugin-3.2.0.pom:
> Connect to repo.maven.apache.org:443 [repo.maven.apache.org/199.232.8.215]
> failed: Connection timed out (Connection timed out) -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
>
>
> Regards
> Sandeep

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

Re: Where is an exact syntax reference for the "nonProxyHosts" property?

[Benjamin Marwell]

Can be found in the repository guide:
https://maven.apache.org/guides/mini/guide-proxies.html

And in the settings reference:
https://maven.apache.org/settings.html

It is referenced in the configuration guide as link:
https://maven.apache.org/settings.html

In case I missed a reference, PRs are welcome:
https://maven.apache.org/guides/development/guide-maven-development.html#creating-and-submitting-a-patch

Ben


On Tue, 15 Jun 2021, 17:31 KARR, DAVID,  wrote:

> > -Original Message-
> > From: KARR, DAVID 
> > Sent: Tuesday, June 15, 2021 8:02 AM
> > To: Maven Users List 
> > Subject: Where is an exact syntax reference for the "nonProxyHosts"
> > property?
> >
> > I have been trying to find a fully complete specification for the syntax
> > of the "nonProxyHosts" property in the settings.xml file.  Every
> > statement I've found, even in Maven documentation, is vague and
> > incomplete.  Is this fully documented somewhere?
>
> I suppose I found this.  The statement in the Maven doc does mention "This
> matches the JDK configuration equivalent.", so I was able to find
> https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html
> which has a statement that is specific enough for me.  It would be better
> if this was clear in the Maven documentation.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Clarification on an end-version/end-date for maven plugins' support of JDK 1.7

[Benjamin Marwell]

By this time, you are probably not able to fix security holes. All common
libraries out there are are already Java 8.

Just calculate how much a total loss will cost due to security holes or
data loss, vs the cost of upgrading. That should work. 

Ben

On Wed, 9 Jun 2021, 08:43 Rick Hanton,  wrote:

> Thanks for the help and input Tamas and Ben!
>
> Yes, I wasn't demanding or expecting anything, just was curious if there
> was some broader "plan", but it sounds like it's up to the individual
> maintainers, which is fine. We too were hoping that our operations folks
> would get all the web application servers upgraded to Java 8 last year,
> which apparently didn't "quite" happen - thus I'm still supporting a few
> servers running [very ancient] versions of Java 1.7. I'll probably have a
> fun meeting with my bosses soon and perhaps I too can just say that no
> longer will any of the libraries I build be Java 1.7 compatible, so if one
> of those clients needs it, they can get their server upgraded or "too bad"
> - man that'd be great!
>
> Cheers,
> Rick
>
> E-mail: hant...@gmail.com
> Twitter: rack88 <http://www.twitter.com/rack88>
>
>
> On Tue, Jun 8, 2021 at 12:31 PM Benjamin Marwell 
> wrote:
>
> > Just FYI,
> >
> > IBM, Zulu, Oracle and Microsoft are giving extended support to paying
> > customers until the 2030s. I guess maven plugins will stay on 1.8 for
> quite
> > a while, but that's just a guess.
> > At least most libraries haven't moved to Java 11 yet (and afaik won't
> move
> > to Java 11 in the near future).
> >
> > There is no extended support available for Java 7 from most vendors
> (maybe
> > Zulu?), and due to updates to the TLS stack, Java 1.7 has become quite
> > unusable. I doubt that there is a good reason to support Java 1.7 now.
> > Updating to Java 8 shouldn't be a big issue and will get you quite some
> > performance gains.
> >
> > HTH
> > Ben
> >
> >
> >
> >
> > On Tue, 8 Jun 2021, 08:28 Tamás Cservenák,  wrote:
> >
> > > Howdy,
> > >
> > > Let me state several things in advance first:
> > > - ASF Maven project (the project) is an open source project maintained
> by
> > > volunteers in their spare time.
> > > - We (as a project) do not provide any kind of "support" or any of that
> > > stuff.
> > >
> > > That said, Java 7 is EOLd in 2015, while Java 8 is EOLd in 2019, and
> yes,
> > > we try to move to supported (read: freely available) Java versions.
> > >
> > > Hence, if you are stuck on Java 7, your best option is really to "lock
> > > down" your plugin versions as well, and accept the fact that you are
> > stuck
> > > on your tooling as well.
> > >
> > > We, as a Java project, have upstream dependencies, and time is pressing
> > us
> > > also, as more and more projects move to Java 8 (if not to Java 11),
> that
> > in
> > > the same way prevents us from consuming the latest dependencies, hence,
> > the
> > > whole "flock" (ecosystem) has to follow the moving target.
> > >
> > > So, while there is no "general guideline" (aside that Maven CLI 3.x is
> > Java
> > > 7, Maven 4.x CLI will be Java 8, etc), due to large ecosystem (plugins
> in
> > > ASF and outside) and plugin version numbers being "unbounded" (are per
> > > plugins, not really bounded to Maven CLI), we try our best when we
> switch
> > > plugin from Java 7 to something higher; it usually means minor or major
> > > version update (so will not happen in a "patch release"), and pretty
> much
> > > always will be present in release notes, just like it is in case of
> > > maven-javadoc-plugin:
> > > https://maven.apache.org/plugins/maven-javadoc-plugin/jira-report.html
> > >
> > > So, it is up to you to search thru release notes, and figure out which
> > > plugin requires which version of Java.
> > >
> > > HTH
> > > Tamas
> > >
> > >
> > > On Tue, Jun 8, 2021 at 6:43 AM Rick Hanton  wrote:
> > >
> > > > Hi folks,
> > > >
> > > > Just wondering if someone can point me to any documentation about one
> > of
> > > > the following things:
> > > >
> > > > 1) Is there a high level direction among apache projects and
> > particularly
> > > > apache maven plugin projects to no longer build using the version 1.7
> > > JDK?
> > 

Re: Clarification on an end-version/end-date for maven plugins' support of JDK 1.7

[Benjamin Marwell]

Just FYI,

IBM, Zulu, Oracle and Microsoft are giving extended support to paying
customers until the 2030s. I guess maven plugins will stay on 1.8 for quite
a while, but that's just a guess.
At least most libraries haven't moved to Java 11 yet (and afaik won't move
to Java 11 in the near future).

There is no extended support available for Java 7 from most vendors (maybe
Zulu?), and due to updates to the TLS stack, Java 1.7 has become quite
unusable. I doubt that there is a good reason to support Java 1.7 now.
Updating to Java 8 shouldn't be a big issue and will get you quite some
performance gains.

HTH
Ben




On Tue, 8 Jun 2021, 08:28 Tamás Cservenák,  wrote:

> Howdy,
>
> Let me state several things in advance first:
> - ASF Maven project (the project) is an open source project maintained by
> volunteers in their spare time.
> - We (as a project) do not provide any kind of "support" or any of that
> stuff.
>
> That said, Java 7 is EOLd in 2015, while Java 8 is EOLd in 2019, and yes,
> we try to move to supported (read: freely available) Java versions.
>
> Hence, if you are stuck on Java 7, your best option is really to "lock
> down" your plugin versions as well, and accept the fact that you are stuck
> on your tooling as well.
>
> We, as a Java project, have upstream dependencies, and time is pressing us
> also, as more and more projects move to Java 8 (if not to Java 11), that in
> the same way prevents us from consuming the latest dependencies, hence, the
> whole "flock" (ecosystem) has to follow the moving target.
>
> So, while there is no "general guideline" (aside that Maven CLI 3.x is Java
> 7, Maven 4.x CLI will be Java 8, etc), due to large ecosystem (plugins in
> ASF and outside) and plugin version numbers being "unbounded" (are per
> plugins, not really bounded to Maven CLI), we try our best when we switch
> plugin from Java 7 to something higher; it usually means minor or major
> version update (so will not happen in a "patch release"), and pretty much
> always will be present in release notes, just like it is in case of
> maven-javadoc-plugin:
> https://maven.apache.org/plugins/maven-javadoc-plugin/jira-report.html
>
> So, it is up to you to search thru release notes, and figure out which
> plugin requires which version of Java.
>
> HTH
> Tamas
>
>
> On Tue, Jun 8, 2021 at 6:43 AM Rick Hanton  wrote:
>
> > Hi folks,
> >
> > Just wondering if someone can point me to any documentation about one of
> > the following things:
> >
> > 1) Is there a high level direction among apache projects and particularly
> > apache maven plugin projects to no longer build using the version 1.7
> JDK?
> > I'm seeing similar changes to move away from Java 7 as I poke through
> some
> > projects like Surefire and maven-javadoc-plugin's latest builds/releases.
> > This is creating some chaos for my company, where we typically use the
> > maven-release plugin via the command-line, but rarely specify versions of
> > the plugins it is dependent upon in our pom.xml files (allowing maven to
> do
> > its normal process of using the latest+greatest release version(s)). I
> > presume other developers that still have code building with JDK 1.7 will
> be
> > in the same boat where their builds start failing with errors like the
> one
> > below.
> >
> > [INFO] [INFO]
> > [INFO] [INFO] >>> maven-source-plugin:3.2.1:jar (attach-sources) >
> > generate-sources @ xxx >>>
> > [INFO] [INFO]
> > [INFO] [INFO] <<< maven-source-plugin:3.2.1:jar (attach-sources) <
> > generate-sources @ xxx <<<
> > [INFO] [INFO]
> > [INFO] [INFO]
> > [INFO] [INFO] --- maven-source-plugin:3.2.1:jar (attach-sources) @
> xxx
> > ---
> > [INFO] [INFO]
> > [INFO] [INFO] --- maven-javadoc-plugin:3.3.0:jar (attach-javadocs) @
> > xxx ---
> > [INFO] [WARNING] Error injecting:
> > org.apache.maven.plugins.javadoc.JavadocJar
> > [INFO] java.lang.TypeNotPresentException: Type
> > org.apache.maven.plugins.javadoc.JavadocJar not present
> > [INFO] at org.eclipse.sisu.space.URLClassSpace.loadClass
> > (URLClassSpace.java:147)
> > [INFO] at org.eclipse.sisu.space.NamedClass.load
> (NamedClass.java:46)
> > [INFO] at org.eclipse.sisu.space.AbstractDeferredClass.get
> > (AbstractDeferredClass.java:48)
> > [INFO] at
> com.google.inject.internal.ProviderInternalFactory.provision
> > (ProviderInternalFactory.java:81)
> > [INFO] at
> >
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision
> > (InternalFactoryToInitializableAdapter.java:53)
> > [INFO] at com.google.inject.internal.ProviderInternalFactory$1.call
> > (ProviderInternalFactory.java:65)
> > [INFO] at
> >
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision
> > (ProvisionListenerStackCallback.java:115)
> > [INFO] at
> >
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision
> > (ProvisionListenerStackCallback.java:133)
> > [INFO] at
> > 

Re: maven-deploy-plugin:deploy-file Why a project is needed?

[Benjamin Marwell]

Can you run the same with -X? This will give more information.
You might want to try -DgeneratePom=true, although this should be the default.

Am Mi., 2. Juni 2021 um 08:19 Uhr schrieb Zos ROTHKO :
>
> Hello
>
> I want to deploy a file using the command below
>
> mvn org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy-file
> -Durl=https://nexus.metrixware.com/repository/
> -DrepositoryId=mis-external-libs -Dfile=C:/Program
> Files/IBM/HostAccessToolkit/14.0.0/toolkit/jars/java2/release/ha_en.jar
> -DartifactId=ha_en   -DgroupId=com.ibm.hod.hacl  -Dversion=14.0.0
> -Dpackaging=jar
>
> but maven is asking for a pom to be present. What I missed to avoid the
> local project requirement?
>
> C:\Users\fandre\Documents\MXW\TOOLS\IBM>mvn
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy-file
> -Durl=https://nexus.metrixware.com/repository/
> -DrepositoryId=mis-external-libs -Dfile=C:/Program
> Files/IBM/HostAccessToolkit/14.0.0/toolkit/jars/java2/release/ha_en.jar
> -DartifactId=ha_en   -DgroupId=com.ibm.hod.hacl  -Dversion=14.0.0
> -Dpackaging=jar
> [INFO] Scanning for projects...
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time:  0.082 s
> [INFO] Finished at: 2021-06-02T08:19:29+02:00
> [INFO]
> 
> [ERROR] The goal you specified requires a project to execute but there
> is no POM in this directory (C:\Users\fandre\Documents\MXW\TOOLS\IBM).
> Please verify you invoked Maven from the correct directory. -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MissingProjectException
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

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

Re: pvn package command dependencies error

[Benjamin Marwell]

Hey Mark,

I just browsed through the commits (git show :/block).
You can easily redirect to http like so as mirrors are not blocked:

  

  maven-snapshots-https
  maven-snapshots-https
  https://oss.sonatype.org/content/repositories/snapshots
  maven-snapshots


  maven-restlet-https
  maven-restlet-https
  https://maven.restlet.org
  maven-restlet


  apache.snapshots-https
  apache.snapshots-https
  https://repository.apache.org/snapshots
  apache.snapshots

  

It works… Kinda. The certificate of https://maven.restlet.org is expired.
But other than that, this is how you bypass the http block.

HTH

Am Di., 4. Mai 2021 um 15:42 Uhr schrieb Mark H. Wood :
>
> On Tue, May 04, 2021 at 12:29:20PM +0200, Benjamin Marwell wrote:
> > you need to use https URLs in your repositories. http URLs are now
> > blocked by default.
> > That should resolve the issue you are having.
>
> He can't.  The problem is with a transitive dependency of Solr 4.10.4
> and is in Solr's POM.  This is a known problem for DSpace:
>
>   https://stackoverflow.com/q/66962265/2916377
>
> It was activated by a recent Maven upgrade which blocks unencrypted
> repository accesses by default.
>
> > You should take a look at your $HOME/.m2/settings.xml, as well as
> > potential occurrences of repository tags in your pom.xml files.
>
> That won't help in this case, since the problem lies in a necessarily
> ancient version of a third-party dependency.  One could either
> override the block in .m2/settings.xml or manually acquire a copy of
> the restlet artifact and install it in one's local repository (perhaps
> using 'mvn install:install-file').
>
> There are breaking changes in newer releases of Solr which won't be
> accounted for in DSpace until the next major release (which should
> come soon).  Moving to a newer Solr release is a rather involved
> process due to those changes, and I don't know of anyone who has done
> it with a released version of DSpace.
>
> --
> Mark H. Wood
> Lead Technology Analyst
>
> University Library
> Indiana University - Purdue University Indianapolis
> 755 W. Michigan Street
> Indianapolis, IN 46202
> 317-274-0749
> www.ulib.iupui.edu

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

Re: pvn package command dependencies error

[Benjamin Marwell]

Hi,

you need to use https URLs in your repositories. http URLs are now
blocked by default.
That should resolve the issue you are having.

You should take a look at your $HOME/.m2/settings.xml, as well as
potential occurrences of repository tags in your pom.xml files.

Best regards,
Ben

Am Mo., 3. Mai 2021 um 22:43 Uhr schrieb Compte Messagerie
:
>
> hello,
> i try to install dspace 6.3 on centos8 with apache-maven-3.8.1 and
> openjdk11
> where i execute $mvn package -X//for debug
> it ends with:
>
> [INFO] --< org.dspace.modules:solr
> >---
> [INFO] Building DSpace SOLR :: Local Customizations 6.3
> [9/11]
> [INFO] [ war
> ]-
> [INFO]
> 
> [INFO] Reactor Summary for DSpace Assembly and Configuration 6.3:
> [INFO]
> [INFO] DSpace Addon Modules ... SUCCESS [
> 0.612 s]
> [INFO] DSpace Kernel :: Additions and Local Customizations  SUCCESS [
> 3.153 s]
> [INFO] DSpace XML-UI (Manakin) :: Local Customizations  SUCCESS [03:51
> min]
> [INFO] DSpace JSP-UI :: Local Customizations .. SUCCESS [02:12
> min]
> [INFO] DSpace RDF :: Local Customizations . SUCCESS [03:20
> min]
> [INFO] DSpace REST :: Local Customizations  SUCCESS [02:22
> min]
> [INFO] DSpace SWORD :: Local Customizations ... SUCCESS [03:08
> min]
> [INFO] DSpace SWORD v2 :: Local Customizations  SUCCESS [02:56
> min]
> [INFO] DSpace SOLR :: Local Customizations  FAILURE [
> 0.209 s]
> [INFO] DSpace OAI-PMH :: Local Customizations . SKIPPED
> [INFO] DSpace Assembly and Configuration .. SKIPPED
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time:  17:56 min
> [INFO] Finished at: 2021-05-03T14:36:24+01:00
> [INFO]
> 
>
> [ERROR] Failed to execute goal on project solr: Could not resolve
> dependencies for project org.dspace.modules:solr:war:6.3: Failed to collect
> dependencies at org.dspace:dspace-solr:jar:classes:6.3 ->
> org.apache.solr:solr-core:jar:4.10.4 ->
> org.restlet.jee:org.restlet:jar:2.1.1: Failed to read artifact descriptor
> for org.restlet.jee:org.restlet:jar:2.1.1: Could not transfer artifact
> org.restlet.jee:org.restlet:pom:2.1.1 from/to maven-default-http-blocker (
> http://0.0.0.0/): Blocked mirror for repositories: [maven-snapshots (
> http://oss.sonatype.org/content/repositories/snapshots, default,
> snapshots), maven-restlet (http://maven.restlet.org, default,
> releases+snapshots), apache.snapshots (
> http://repository.apache.org/snapshots, default, disabled)] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project solr: Could not resolve dependencies for project
> org.dspace.modules:solr:war:6.3: Failed to collect dependencies at
> org.dspace:dspace-solr:jar:classes:6.3 ->
> org.apache.solr:solr-core:jar:4.10.4 ->
> org.restlet.jee:org.restlet:jar:2.1.1
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> 

Re: maven release process and Integration test artifact version tracking

[Benjamin Marwell]

Hi Zos,

you probably want to write
  @project.version@
for your artifact. It will get replaced with the version number of the
enclosing module.

It is listed in the usage page (as a side note):
https://maven.apache.org/plugins/maven-invoker-plugin/usage.html

Here is a random example of one of the maven plugins:
https://github.com/apache/maven-jlink-plugin/blob/36cff867d5d6a74941e5131a20a7301b89fae65d/src/it/projects/MJLINK-41_addoptions-11/pom.xml#L53

- Ben

Am Mi., 21. Apr. 2021 um 10:00 Uhr schrieb Zos ROTHKO :
>
> Hello Maven's users
>
> I have a problem about tracking the new snapshot version of an jar
> artifact within the integration test running the maven-invoker-plugin.
>
> Each integration test project is using the snapshot version of the jar
> artifact as a runtime dependency of a 3rd party maven plugin. When there
> is a maven release of the artifact, its version is changing to another
> version which is specified at the release time. But since the IT pom are
> not processed by the maven release plugin, the version of the jar
> artifact stays as its previous shapshot version and not the new one.
>
> How could be know to the maven release plugin that it should also update
> the version used in the IT pom?
>
> For those interested, the maven projects can be cloned from this git
> repository: g...@github.com:javacc/javacc-8-java.git
> 
>
> Rgds
>
> FA
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

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

Re: Core plugins, milestone versions

[Benjamin Marwell]

Hi Antoine,

That's probably a typical YMMV question.
>From my experience with surefire, I'd say rather stick with the 2.x
versions as long as you don't need an explicit feature of the 3.x Milestone
version.
If something doesn't work or is missing, open up a ticket or ask on this
list.

If you find a milestone version good enough, just post it here and ask for
a release. We did that with the jpackage plugin and might do this with
others as well.

- Ben


On Tue, 30 Mar 2021, 18:39 Antoine Mottier,  wrote:

> Hello,
>
> While looking at https://maven.apache.org/plugins/index.html I
> realized that many core plugin versions are actually milestone version
> (e.g. deploy: 3.0.0-M1).
>
> It seems that some of them are release quite a long time ago (e.g.
> deploy: 2018-09-23). I was wondering what is the recommendation:
> should I use the latest version even if it is a milestone version? Or
> should I use the latest "stable" version (e.g. 2.8.2 for deploy plugin)?
>
> Thanks.
>
> --
> Antoine Mottier
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Maven compiler plugin Unsupported major.minor version

[Benjamin Marwell]

Hi Andrea,

best thing is to comment in both Issues I created.
Preferably a code tag with the stack trace in it, so we have the
information where we need it.

Thanks!

Am Do., 11. Feb. 2021 um 12:51 Uhr schrieb Andrea Vacondio
:
>
> Hi Benjamin,
> yes, that simple repo indeed works with version 1.0.6. I also created a
> simple multi module version and it works as well.
> Unfortunately I tested on my real life repo and got:
> Caused by: org.apache.maven.plugin.PluginContainerException: A required
> class was missing while executing
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile:
> org/codehaus/plexus/languages/java/jpms/ResolvePathsResult$ModuleNameSource
>
> From what I can tell that's happening because ModuleNameSource enum has
> been moved between plexus-java version used in maven-compiler 3.8.1 and
> plexus-java 1.0.6. This error doesn't show in the test repos so I assume
> I'm going into an execution path that is not covered in that repos.
>
> Next test I checked out the latest snapshot 3.9.0 of the compiler plugin,
> installed locally and used that in my real life repo together with
> plexus-java 1.0.6 and I got a warning and a compilation error:
> [WARNING] Can't extract module name from classes: Unsupported major.minor
> version 59.65535
> Compilation failure
> [ERROR]
> /home/torakiki/repos/pdf-black/pdfblack-model/src/main/java/module-info.java:[20,22]
> error: module not found: black.pdf.i18n
>
> So I managed to set up a test multi module repo with a parent and 2
> children where child2 depends on child1 https://github.com/torakiki/test
> and I get the same result, using maven compiler 3.9.0-SNAPSHOT and
> plexus-java 1.0.6:
> [WARNING] Can't extract module name from classes: Unsupported major.minor
> version 59.0
> Compilation failure
> [ERROR]
> /home/torakiki/repos/test/testme-child2/src/main/java/module-info.java:[5,17]
> error: module not found: test.me.child
>
> From what I can see from the logs child1 module is actually missing from
> the module path. Is there anything misconfigred?
> Andrea
>
>
>
>
> Il giorno gio 11 feb 2021 alle ore 08:42 Benjamin Marwell <
> bmarw...@apache.org> ha scritto:
>
> > Hi Andrea,
> >
> > Robert was sure the new plexus dependency fixes your issue. He tried
> > it, and it worked. Same for me.
> >
> > Can you please double check you added the dependency to your *compiler
> > plugin*, not to the
> > general dependency section?
> >
> > I created a PR so you can see the changes:
> > https://github.com/torakiki/testme/pull/1
> >
> > This will probably make it into one of the next versions of the
> > compiler plugin, if you would rather want to wait.
> >
> > Best regards,
> > - Ben
> >
> > Am Mi., 10. Feb. 2021 um 14:33 Uhr schrieb Benjamin Marwell
> > :
> > >
> > > Hi Andrea,
> > >
> > > thank you very much! I can confirm that this should not happen.
> > > The error seems to be that the preparePaths method tries to parse the
> > > existing module-info.class, but does not use the Toolchain provided
> > > JDK for this.
> > >
> > > The issue for this: https://issues.apache.org/jira/browse/MCOMPILER-455
> > > cc to the dev mailing list. Issue is free to grab. Probably needs to
> > > be fixed in plexus java, therefore also created
> > > https://github.com/codehaus-plexus/plexus-languages/issues/64.
> > >
> > > Am Mi., 10. Feb. 2021 um 12:51 Uhr schrieb Andrea Vacondio
> > > :
> > > >
> > > > Ok, I created a super simple repo here
> > https://github.com/torakiki/testme
> > > >
> > > > The pom is stripped to the minimum, here are the steps I use to
> > reproduce:
> > > > - git clone https://github.com/torakiki/testme.git
> > > > - mvn compile
> > > > - mvn compile
> > > >
> > > > The first compilation works, the second doesn't unless I clean.
> > > > The error is pretty much the same:
> > > > Execution default-compile of goal
> > > > org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile failed:
> > > > Unsupported major.minor version 59.0
> > > >
> > > > Using Maven 3.6.3
> > > > My toolchain.xml:
> > > > 
> > > >   
> > > > jdk
> > > > 
> > > >   15
> > > >   openjdk
> > > > 
> > > > 
> > > >   /usr/lib/jvm/jdk-15.0.1+9
> > > > 
> > > >   
> > > > 
> > > > My .

Re: Maven compiler plugin Unsupported major.minor version

[Benjamin Marwell]

Hi Andrea,

Robert was sure the new plexus dependency fixes your issue. He tried
it, and it worked. Same for me.

Can you please double check you added the dependency to your *compiler
plugin*, not to the
general dependency section?

I created a PR so you can see the changes:
https://github.com/torakiki/testme/pull/1

This will probably make it into one of the next versions of the
compiler plugin, if you would rather want to wait.

Best regards,
- Ben

Am Mi., 10. Feb. 2021 um 14:33 Uhr schrieb Benjamin Marwell
:
>
> Hi Andrea,
>
> thank you very much! I can confirm that this should not happen.
> The error seems to be that the preparePaths method tries to parse the
> existing module-info.class, but does not use the Toolchain provided
> JDK for this.
>
> The issue for this: https://issues.apache.org/jira/browse/MCOMPILER-455
> cc to the dev mailing list. Issue is free to grab. Probably needs to
> be fixed in plexus java, therefore also created
> https://github.com/codehaus-plexus/plexus-languages/issues/64.
>
> Am Mi., 10. Feb. 2021 um 12:51 Uhr schrieb Andrea Vacondio
> :
> >
> > Ok, I created a super simple repo here https://github.com/torakiki/testme
> >
> > The pom is stripped to the minimum, here are the steps I use to reproduce:
> > - git clone https://github.com/torakiki/testme.git
> > - mvn compile
> > - mvn compile
> >
> > The first compilation works, the second doesn't unless I clean.
> > The error is pretty much the same:
> > Execution default-compile of goal
> > org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile failed:
> > Unsupported major.minor version 59.0
> >
> > Using Maven 3.6.3
> > My toolchain.xml:
> > 
> >   
> > jdk
> > 
> >   15
> >   openjdk
> > 
> > 
> >   /usr/lib/jvm/jdk-15.0.1+9
> > 
> >   
> > 
> > My .mavenrc:
> > export JAVA_HOME=/usr/lib/jvm/jdk-11
> >
> >
> > I'm on Linux but I tested on Windows 7 and got the same result.
> > A side note, while with this simple project the first compile works, the
> > second doesn't, in my multi-module project with a parent module plus 8
> > child modules it fails on the second module with 'mvn clean compile' from
> > the parent.
> >
> > I hope it helps.
> > Andrea
> >
> > Il giorno mar 9 feb 2021 alle ore 21:46 Benjamin Marwell <
> > bmarw...@apache.org> ha scritto:
> >
> > > Hi,
> > >
> > > do you have a public repository to share? Have you tried other JVM
> > > implementations? Have you tried cooling without preview features?
> > >
> > > On Mon, 8 Feb 2021, 15:30 Andrea Vacondio, 
> > > wrote:
> > >
> > > > Thanks for the reply. I tried that and I got:
> > > > [ERROR] Failed to execute goal
> > > > org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> > > > (default-compile) on project pdfblack-model: Execution default-compile 
> > > > of
> > > > goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> > > failed: A
> > > > required class was missing while executing
> > > > org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile:
> > > >
> > > org/codehaus/plexus/languages/java/jpms/ResolvePathsResult$ModuleNameSource
> > > > [ERROR] -
> > > > [ERROR] realm =
> > > > plugin>org.apache.maven.plugins:maven-compiler-plugin:3.8.1
> > > > [ERROR] strategy =
> > > > org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> > > > [ERROR] urls[0] =
> > > >
> > > file:/home/torakiki/.m2/repository/org/apache/maven/plugins/maven-compiler-plugin/3.8.1/maven-compiler-plugin-3.8.1.jar
> > > > [ERROR] urls[1] =
> > > >
> > > file:/home/torakiki/.m2/repository/org/codehaus/plexus/plexus-java/0.9.11/plexus-java-0.9.11.jar
> > > > [ERROR] urls[2] =
> > > >
> > > file:/home/torakiki/.m2/repository/org/ow2/asm/asm/7.0-beta/asm-7.0-beta.jar
> > > > [ERROR] urls[3] =
> > > >
> > > file:/home/torakiki/.m2/repository/com/thoughtworks/qdox/qdox/2.0-M9/qdox-2.0-M9.jar
> > > > [ERROR] urls[4] =
> > > >
> > > file:/home/torakiki/.m2/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
> > > > [ERROR] urls[5] =
> > > >
> > > file:/home/torakiki/.m2/repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
> > > > [ERROR] ur

Re: Maven compiler plugin Unsupported major.minor version

[Benjamin Marwell]

Hi Andrea,

thank you very much! I can confirm that this should not happen.
The error seems to be that the preparePaths method tries to parse the
existing module-info.class, but does not use the Toolchain provided
JDK for this.

The issue for this: https://issues.apache.org/jira/browse/MCOMPILER-455
cc to the dev mailing list. Issue is free to grab. Probably needs to
be fixed in plexus java, therefore also created
https://github.com/codehaus-plexus/plexus-languages/issues/64.

Am Mi., 10. Feb. 2021 um 12:51 Uhr schrieb Andrea Vacondio
:
>
> Ok, I created a super simple repo here https://github.com/torakiki/testme
>
> The pom is stripped to the minimum, here are the steps I use to reproduce:
> - git clone https://github.com/torakiki/testme.git
> - mvn compile
> - mvn compile
>
> The first compilation works, the second doesn't unless I clean.
> The error is pretty much the same:
> Execution default-compile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile failed:
> Unsupported major.minor version 59.0
>
> Using Maven 3.6.3
> My toolchain.xml:
> 
>   
> jdk
> 
>   15
>   openjdk
> 
> 
>   /usr/lib/jvm/jdk-15.0.1+9
> 
>   
> 
> My .mavenrc:
> export JAVA_HOME=/usr/lib/jvm/jdk-11
>
>
> I'm on Linux but I tested on Windows 7 and got the same result.
> A side note, while with this simple project the first compile works, the
> second doesn't, in my multi-module project with a parent module plus 8
> child modules it fails on the second module with 'mvn clean compile' from
> the parent.
>
> I hope it helps.
> Andrea
>
> Il giorno mar 9 feb 2021 alle ore 21:46 Benjamin Marwell <
> bmarw...@apache.org> ha scritto:
>
> > Hi,
> >
> > do you have a public repository to share? Have you tried other JVM
> > implementations? Have you tried cooling without preview features?
> >
> > On Mon, 8 Feb 2021, 15:30 Andrea Vacondio, 
> > wrote:
> >
> > > Thanks for the reply. I tried that and I got:
> > > [ERROR] Failed to execute goal
> > > org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> > > (default-compile) on project pdfblack-model: Execution default-compile of
> > > goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> > failed: A
> > > required class was missing while executing
> > > org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile:
> > >
> > org/codehaus/plexus/languages/java/jpms/ResolvePathsResult$ModuleNameSource
> > > [ERROR] -
> > > [ERROR] realm =
> > > plugin>org.apache.maven.plugins:maven-compiler-plugin:3.8.1
> > > [ERROR] strategy =
> > > org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> > > [ERROR] urls[0] =
> > >
> > file:/home/torakiki/.m2/repository/org/apache/maven/plugins/maven-compiler-plugin/3.8.1/maven-compiler-plugin-3.8.1.jar
> > > [ERROR] urls[1] =
> > >
> > file:/home/torakiki/.m2/repository/org/codehaus/plexus/plexus-java/0.9.11/plexus-java-0.9.11.jar
> > > [ERROR] urls[2] =
> > >
> > file:/home/torakiki/.m2/repository/org/ow2/asm/asm/7.0-beta/asm-7.0-beta.jar
> > > [ERROR] urls[3] =
> > >
> > file:/home/torakiki/.m2/repository/com/thoughtworks/qdox/qdox/2.0-M9/qdox-2.0-M9.jar
> > > [ERROR] urls[4] =
> > >
> > file:/home/torakiki/.m2/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
> > > [ERROR] urls[5] =
> > >
> > file:/home/torakiki/.m2/repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
> > > [ERROR] urls[6] =
> > >
> > file:/home/torakiki/.m2/repository/org/codehaus/plexus/plexus-utils/2.0.4/plexus-utils-2.0.4.jar
> > > [ERROR] urls[7] =
> > >
> > file:/home/torakiki/.m2/repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
> > > [ERROR] urls[8] =
> > >
> > file:/home/torakiki/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
> > > [ERROR] urls[9] =
> > >
> > file:/home/torakiki/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.7.1/plexus-component-annotations-1.7.1.jar
> > > [ERROR] urls[10] =
> > >
> > file:/home/torakiki/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> > > [ERROR] urls[11] =
> > >
> > file:/home/torakiki/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> > > [ERROR] urls[12] =
> > >
> > file:/home/torakiki/.m2/re

Re: Maven compiler plugin Unsupported major.minor version

[Benjamin Marwell]

Hi,

do you have a public repository to share? Have you tried other JVM
implementations? Have you tried cooling without preview features?

On Mon, 8 Feb 2021, 15:30 Andrea Vacondio, 
wrote:

> Thanks for the reply. I tried that and I got:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project pdfblack-model: Execution default-compile of
> goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile failed: A
> required class was missing while executing
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile:
> org/codehaus/plexus/languages/java/jpms/ResolvePathsResult$ModuleNameSource
> [ERROR] -
> [ERROR] realm =
> plugin>org.apache.maven.plugins:maven-compiler-plugin:3.8.1
> [ERROR] strategy =
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] =
> file:/home/torakiki/.m2/repository/org/apache/maven/plugins/maven-compiler-plugin/3.8.1/maven-compiler-plugin-3.8.1.jar
> [ERROR] urls[1] =
> file:/home/torakiki/.m2/repository/org/codehaus/plexus/plexus-java/0.9.11/plexus-java-0.9.11.jar
> [ERROR] urls[2] =
> file:/home/torakiki/.m2/repository/org/ow2/asm/asm/7.0-beta/asm-7.0-beta.jar
> [ERROR] urls[3] =
> file:/home/torakiki/.m2/repository/com/thoughtworks/qdox/qdox/2.0-M9/qdox-2.0-M9.jar
> [ERROR] urls[4] =
> file:/home/torakiki/.m2/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
> [ERROR] urls[5] =
> file:/home/torakiki/.m2/repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
> [ERROR] urls[6] =
> file:/home/torakiki/.m2/repository/org/codehaus/plexus/plexus-utils/2.0.4/plexus-utils-2.0.4.jar
> [ERROR] urls[7] =
> file:/home/torakiki/.m2/repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
> [ERROR] urls[8] =
> file:/home/torakiki/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
> [ERROR] urls[9] =
> file:/home/torakiki/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.7.1/plexus-component-annotations-1.7.1.jar
> [ERROR] urls[10] =
> file:/home/torakiki/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> [ERROR] urls[11] =
> file:/home/torakiki/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> [ERROR] urls[12] =
> file:/home/torakiki/.m2/repository/org/apache/maven/shared/maven-shared-utils/3.2.1/maven-shared-utils-3.2.1.jar
> [ERROR] urls[13] =
> file:/home/torakiki/.m2/repository/commons-io/commons-io/2.5/commons-io-2.5.jar
> [ERROR] urls[14] =
> file:/home/torakiki/.m2/repository/org/apache/maven/shared/maven-shared-incremental/1.1/maven-shared-incremental-1.1.jar
> [ERROR] urls[15] =
> file:/home/torakiki/.m2/repository/org/codehaus/plexus/plexus-compiler-api/2.8.4/plexus-compiler-api-2.8.4.jar
> [ERROR] urls[16] =
> file:/home/torakiki/.m2/repository/org/codehaus/plexus/plexus-compiler-manager/2.8.4/plexus-compiler-manager-2.8.4.jar
> [ERROR] urls[17] =
> file:/home/torakiki/.m2/repository/org/codehaus/plexus/plexus-compiler-javac/2.8.4/plexus-compiler-javac-2.8.4.jar
> [ERROR] Number of foreign imports: 1
> [ERROR] import: Entry[import  from realm ClassRealm[maven.api, parent:
> null]]
> [ERROR]
> [ERROR] -
>
> I get this error even if I move plexus-java up of one minor version to
> plexus-java 0.9.11.
> I also tried to update asm with:
> 
> 
>org.ow2.asm
>   asm
>   9.1
> 
> 
> so pexus-java 0.9.10 and asm latest but I got the same original error.
> Andrea
>
>
> On 2021/02/07 20:19:40, Benjamin Marwell  wrote:
> > Hi Andrea,
> >
> > looking at the maven-compiler-plugin, it uses plexus-java 0.9.10 which
> > in turn uses an old 6.x asm version.
> >
> > Try adding a more recent version of plexus-java (which uses asm 9.0)
> > and see if that works.
> > 
> > org.apache.maven.plugins
> > maven-compiler-plugin
> > 3.8.1
> > 
> > 15
> > 
> > --enable-preview
> > 
> > 
> > 
> > org.codehaus.plexus
> > plexus-java
> > 1.0.6
> > 
> > 
> >
> > If it works, please kindly open a ticket at
> > http://issues.apache.org/jira/projects/MCOMPILER with the full stack
> > trace.
> >
> > - Ben
> >
> > Am Sa., 6. Feb. 2021 um 08:47 Uhr schrieb Andrea Vacondio
> > :
> > >
> > > Hi,
> > > I hope this is the right channel.
> &g

Re: Maven compiler plugin Unsupported major.minor version

[Benjamin Marwell]

Hi Andrea,

looking at the maven-compiler-plugin, it uses plexus-java 0.9.10 which
in turn uses an old 6.x asm version.

Try adding a more recent version of plexus-java (which uses asm 9.0)
and see if that works.

org.apache.maven.plugins
maven-compiler-plugin
3.8.1

15

--enable-preview



org.codehaus.plexus
plexus-java
1.0.6



If it works, please kindly open a ticket at
http://issues.apache.org/jira/projects/MCOMPILER with the full stack
trace.

- Ben

Am Sa., 6. Feb. 2021 um 08:47 Uhr schrieb Andrea Vacondio
:
>
> Hi,
> I hope this is the right channel.
> I have a multi module project that I'm trying to modularize in the JPMS
> sense.
> It's configured to run maven with java 11 and run the compiler plugin using
> java 15 through the toolchain plugin and this is what I get:
>
> [INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @
> pdfblack-model ---
> [INFO] Toolchain in maven-compiler-plugin: JDK[/usr/lib/jvm/jdk-15.0.1+9]
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time:  1.141 s
> [INFO] Finished at: 2021-02-05T18:07:26+01:00
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project pdfblack-model: Execution default-compile of
> goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile failed:
> Unsupported major.minor version 59.65535 -> [Help 1]
>
> I attached the full stacktrace at the bottom.
> It seems to me the plugin is using jdk11 to do something where it should
> use jdk15 from the toolchain but before digging deeper I wanted to double
> check if I'm doing anything wrong or if maybe my expectations are wrong.
> This is my configuration, nothing special there:
> 
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.8.1
> 
> 15
> 
> --enable-preview
> 
> 
> 
>
> This is the stacktrace:
> Execution default-compile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile failed:
> Unsupported major.minor version 59.65535
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-compile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile failed:
> Unsupported major.minor version 59.65535
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:148)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> 

[ANN] Apache Maven JLink Plugin 3.1.0 Released

[Benjamin Marwell]

The Maven team is pleased to announce the release of the Apache Maven JLink
Plugin, version 3.1.0

The JLink Plugin is intended to create a Modular Java Run-Time Images via
jlink.

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

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


  org.apache.maven.plugins
  maven-jlink-plugin
  3.1.0



Release Notes - Apache Maven JLink Plugin - Version 3.1.0

Bug
  [MJLINK-54] - Compiler source/target for site generating does not work
with 8
  [MJLINK-55] - Pre Release Marker in Site must be changed

New Feature
  [MJLINK-40] - Add support for --include-locales option
  [MJLINK-41] - Add support for launcher script

Improvement
  [MJLINK-36] - Use JLink via ToolProvider
  [MJLINK-49] - Add support for single maven projects
  [MJLINK-52] - Add support for classifiers
  [MJLINK-53] - ITs should fail if no jlink binary is available
  [MJLINK-56] - Convert unit tests to Junit5
  [MJLINK-58] - Remove usage of plexus utils, use commons lang or native
java instead.

Task
  [MJLINK-60] - Website still shows PRE-RELEASE watermark

Dependency upgrade
  [MJLINK-47] - Upgrade plexus-archiver to 4.2.3


Enjoy,

-The Maven team

Re: mvn encrypted password and maven plugin properties

[Benjamin Marwell]

Hi Volker,

the issue you opened at github is correct [2].

The plugin actually needs to retrieve the password from the settings, like
the wagon plugin does [1].

HTH with your upstream issue.


  [1]:
https://github.com/mojohaus/wagon-maven-plugin/blob/5701bacc30828fee63c54a33536e5054ea453fc3/src/main/java/org/codehaus/mojo/wagon/shared/DefaultWagonFactory.java#L91-L118
  [2]: https://github.com/tomasbjerre/git-changelog-maven-plugin/issues/22


Am Di., 15. Dez. 2020 um 19:45 Uhr schrieb Volker Hochstein <
v.hochst...@highstone.de>:

> Hi,
>
> I ve configured plugin property jirapassword of maven plugin:
> https://github.com/tomasbjerre/git-changelog-maven-plugin
> with an encrypted password (using mvn encrypt).
>
> It s working in same project for other plugins, eg sonar maven plugin.
>
> However, git-changelog-maven-plugin is not able to successfully
> authorize with my jira system.
> If I use a cleartext password it s working without any issue.
>
> My question would be:
>
> Does a maven plugin need to add extra code to "decrypt" properties or is
> that managed transparently for maven centrally ?
>
> Thanks a lot for your support in advance.
>
> --
> Volker
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: HTTP/2 support in Maven

[Benjamin Marwell]

Hi Michael,

I do not think it is necessary to download ALL of them serially. H2
Server push might become a big advantage as already mentioned.
e.g. if requesting a pom, it might push the jar and its dependencies
right away with it.
THAT would probably save a lot of connections (and time).

The only problem is that we would need server support for this (h2 push) first.

Am Mo., 9. Nov. 2020 um 16:35 Uhr schrieb Michael Osipov :
>
> Am 2020-11-05 um 16:49 schrieb Jakub Bartecek:
> > Hi,
> > I did a performance test of HTTP/2 and its comparison with HTTP/1.1 and I
> > would like to share my results with you.
> >
> > I wrote a Python script [1] to download 100 artifacts in parallel using
> > asynchronous HTTP client supporting both HTTP/1.1 and HTTP/2. I chose 100
> > artifacts [2] from Maven Central, which were downloaded when I did a clean
> > build of one of my projects.
> >
> > All 100 artifacts were downloaded using HTTP/1.1 and also HTTP/2 and I
> > stored the results in this file [3]. I did 10 experiments and measured its
> > performance. In the middle I switch the order of HTTP/1.1 and HTTP/2
> > requests to avoid a possible bias. I run it from my laptop connected to 160
> > Mbit/s network.
> >
> > The experiments showed massive performance improvements when using HTTP/2
> > instead of HTTP/1.1
> > *:*
> >
> > - *The average download time using HTTP/1.1 was 3753.7 ms and using
> > HTTP/2 971.8 ms* [4]
> >
> >
> > - *In average the artifacts were downloaded 3.86 times faster using
> > HTTP/2 than using HTTP/1.1* [5]
> >
> >
> > Kuba
> >
> > [1]: https://github.com/jbartece/http2performance/blob/main/http2PerfTest.py
> > [2]: https://github.com/jbartece/http2performance/blob/main/centralUrls.txt
> > [3]: https://github.com/jbartece/http2performance/blob/main/testResults.txt
> > [4]:
> > https://github.com/jbartece/http2performance/blob/main/finalResults.txt#L26
> > [5]:
> > https://github.com/jbartece/http2performance/blob/main/finalResults.txt#L32
>
> This testing is logically wrong/incomplete. You have to download
> serially maven-metadata.xml, its checksum files, POM, its checkfiles and
> artifact itself and its checksum files. Please redo, I would to to test
> this too then. Enable HttpClient debug logging to see that more than
> just the JAR is downloaded.
>
> Michael
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

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

Re: HTTP/2 support in Maven

[Benjamin Marwell]

Well, if central supported h2 push, that would be a benefit!

E.g. request shiro-web.jar and all the other dependencies would be pushed:
shiro-core.jar/.pom etc.

Maven would need to figure out which one it needed, so it doesn't
redownload existing artifacts.

So, no (or only marginal) gain without h2 server push.

There may be other interesting mechanisms, but from what I've heard, push
is the most beneficial. And that's what I observed so far.

On Thu, 5 Nov 2020, 19:49 Bernd Eckenfels,  wrote:

> Hello,
>
> I don’t really see where http/2 should have a speed performance compared
> to http/1.1 as long as both use keepalive. For larger artifacts even the
> header reduction should be negectible. Having said that, it is of course a
> good idea to go with the new protocols, but I would not expect much
> advantage. Especially not if you limit yourself to one or two tcp
> connections per repository.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> Von: Jakub Bartecek 
> Gesendet: Thursday, November 5, 2020 6:28:05 PM
> An: Maven Users List 
> Betreff: Re: HTTP/2 support in Maven
>
> Hi,
> I'll look at it tomorrow and try to verify it really downloads the whole
> content, I did some checks on POM files and it really downloaded it.
>
> Thanks for testing it from your machine. It's interesting to see that you
> have completely different results. Honestly I'm not sure how that is
> possible, but I'll think about it more tomorrow. I'm about to call it a day
> now.
>
> Kuba
>
> On Thu, Nov 5, 2020 at 6:10 PM Tamás Cservenák 
> wrote:
>
> > (short disclaimer: am not a python speaking person, so the change I did
> > above with intent to "consume response body, the artifact bytes" may not
> > did what I wanted :D)
> >
>

Re: Java11 and javadoc plugin

[Benjamin Marwell]

Hi Thomas,

Those test sources are neither in the project we talked about earlier, nor
do they have javadocs.

Let's keep focused on the project you mentioned earlier. Please take a look
at my explanations and the PR they resulted in.

The new project (https://github.com/yagee-de/javadoc-test/
<https://github.com/yagee-de/javadoc-test/tree/master/src/test/java/de/yagee/test>)
does not contain most of the pom.xml changes I suggested, eg setting some
plugin versions.

So, what is unclear in the PR I mentioned in the previous email? I'm happy
to help.

Ben

On Fri, 30 Oct 2020, 15:03 Thomas Scheffler, 
wrote:

> Hi Benajmin,
>
> yes I have test sources present in that directory:
> https://github.com/yagee-de/javadoc-test/tree/master/src/test/java/de/yagee/test
>
> Ironically „mvn javadoc:test-javadoc“ runs without any issues and without
> „test“ or „compile“ running before the „test-javadoc“ goal. No way to get
> it working during „mvn site“ though!
>
> kind regards
>
> Thomas
>
> Am 29.10.2020 um 15:57 schrieb Benjamin Marwell :
>
> Hi Thomas,
>
> | Exit code: 2 - javadoc: error - No source files for package de.yagee.test
>
> You do not have a folder "/project/src/test/java" with any test sources!
>
> I set up an example here:
> https://github.com/FIUS/jvk/pull/123/files
>
> Please be aware that you still cannot create test javadocs nor javadoc
> from dependency sources. As said, please kindly create two issues for
> this.
>
> Am Do., 29. Okt. 2020 um 08:10 Uhr schrieb Thomas Scheffler
> :
>
>
> Hi Benjamin,
>
> you may have done something differently because „mvn test site“ does not
> work here. Could you recheck or give me a hint, what I could have done
> wrong?
>
> kind regards,
>
> Thomas
>
> Am 28.10.2020 um 20:05 schrieb Benjamin Marwell :
>
> Hi Thomas,
>
> no worry, that is as easy to fix as the previous one.
>
> Read carefully:
>
> Error generating maven-javadoc-plugin:3.2.0:test-aggregate-no-fork
>
>
> The javadoc-plugin executes "test-aggregate-no-fork".
>
> Which means: It creates javadoc for your TEST classes from src/test/java.
> That again requires the "test" goal to be run first [1].
>
> Requires dependency resolution of artifacts in scope: test.
>
>
> I rarely found it useful to generate, validate and publish javadoc for
> test classes.
>
> Long story short:
> mvn test site # (test includes compile).
>
> Although imho, you will always want to execute "mvn verify" (or "mvn
> clean verify") anyway, wouldn’t you? ;-)
> This is considered a good habit by Robert Scholte iirc.
>
> If you need more information on the "why", don’t hesitate to ask! :)
>
> [1]
> https://maven.apache.org/plugins/maven-javadoc-plugin/test-aggregate-no-fork-mojo.html
>
> Am Mi., 28. Okt. 2020 um 14:45 Uhr schrieb Thomas Scheffler
> :
>
>
> Hi,
>
> thanks for looking into it. I updated the project a bit so that you can
> easily switch the version with „-Djavadoc.plugin.version=3.0.1“ to see it
> working nice with „mvn site“ and „mvn javadoc:javadoc“. My problem is, that
> I don’t know how to make „site“ run again. „mvn compile site“ will prevent
> the errors for the main javadocs but will fail on test javadocs (Junit
> tests):
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.9.1:site (default-site) on
> project test: Error generating
> maven-javadoc-plugin:3.2.0:test-aggregate-no-fork report:
> [ERROR] Exit code: 2 - javadoc: error - No source files for package
> de.yagee.test
> [ERROR]
> [ERROR] Command line was: /Users/yagee/Java/Home/14/bin/javadoc @options
> @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/Users/yagee/git/javadoc-test/target/site/testapidocs' dir.
> [ERROR] -> [Help 1]
>
> I can stick with 3.0.1 for a while, but of cause I want to move forward. I
> set up the minimal project to get this figured out, but I lost.
>
> Looking at
> https://maven.apache.org/plugins/maven-javadoc-plugin/usage.html, there
> is even no hint on suddenly requiring „compile“ starting with version
> 1.1.0. Still the site issue drives me nuts, too.
>
> Thanks again for helping me!
>
> kind regards,
>
> Thomas
>
> Am 27.10.2020 um 19:55 schrieb Benjamin Marwell :
>
> Hi Thomas,
>
> I tested your configuration and found the same issue – however, it may
> not be an issue after all.
>
> You configured your javadoc plugin as part of the reporting section.
> This usually requires the compile goal.
>
> Even if you add the jar goal to the default build->plugin section, it
> will still require compile to be executed. This is expect

Re: Java11 and javadoc plugin

[Benjamin Marwell]

Hi Thomas,

| Exit code: 2 - javadoc: error - No source files for package de.yagee.test

You do not have a folder "/project/src/test/java" with any test sources!

I set up an example here:
https://github.com/FIUS/jvk/pull/123/files

Please be aware that you still cannot create test javadocs nor javadoc
from dependency sources. As said, please kindly create two issues for
this.

Am Do., 29. Okt. 2020 um 08:10 Uhr schrieb Thomas Scheffler
:
>
> Hi Benjamin,
>
> you may have done something differently because „mvn test site“ does not work 
> here. Could you recheck or give me a hint, what I could have done wrong?
>
> kind regards,
>
> Thomas
>
> > Am 28.10.2020 um 20:05 schrieb Benjamin Marwell :
> >
> > Hi Thomas,
> >
> > no worry, that is as easy to fix as the previous one.
> >
> > Read carefully:
> >> Error generating maven-javadoc-plugin:3.2.0:test-aggregate-no-fork
> >
> > The javadoc-plugin executes "test-aggregate-no-fork".
> >
> > Which means: It creates javadoc for your TEST classes from src/test/java.
> > That again requires the "test" goal to be run first [1].
> >> Requires dependency resolution of artifacts in scope: test.
> >
> > I rarely found it useful to generate, validate and publish javadoc for
> > test classes.
> >
> > Long story short:
> > mvn test site # (test includes compile).
> >
> > Although imho, you will always want to execute "mvn verify" (or "mvn
> > clean verify") anyway, wouldn’t you? ;-)
> > This is considered a good habit by Robert Scholte iirc.
> >
> > If you need more information on the "why", don’t hesitate to ask! :)
> >
> > [1] 
> > https://maven.apache.org/plugins/maven-javadoc-plugin/test-aggregate-no-fork-mojo.html
> >
> > Am Mi., 28. Okt. 2020 um 14:45 Uhr schrieb Thomas Scheffler
> > :
> >>
> >> Hi,
> >>
> >> thanks for looking into it. I updated the project a bit so that you can 
> >> easily switch the version with „-Djavadoc.plugin.version=3.0.1“ to see it 
> >> working nice with „mvn site“ and „mvn javadoc:javadoc“. My problem is, 
> >> that I don’t know how to make „site“ run again. „mvn compile site“ will 
> >> prevent the errors for the main javadocs but will fail on test javadocs 
> >> (Junit tests):
> >>
> >> [ERROR] Failed to execute goal 
> >> org.apache.maven.plugins:maven-site-plugin:3.9.1:site (default-site) on 
> >> project test: Error generating 
> >> maven-javadoc-plugin:3.2.0:test-aggregate-no-fork report:
> >> [ERROR] Exit code: 2 - javadoc: error - No source files for package 
> >> de.yagee.test
> >> [ERROR]
> >> [ERROR] Command line was: /Users/yagee/Java/Home/14/bin/javadoc @options 
> >> @packages
> >> [ERROR]
> >> [ERROR] Refer to the generated Javadoc files in 
> >> '/Users/yagee/git/javadoc-test/target/site/testapidocs' dir.
> >> [ERROR] -> [Help 1]
> >>
> >> I can stick with 3.0.1 for a while, but of cause I want to move forward. I 
> >> set up the minimal project to get this figured out, but I lost.
> >>
> >> Looking at 
> >> https://maven.apache.org/plugins/maven-javadoc-plugin/usage.html, there is 
> >> even no hint on suddenly requiring „compile“ starting with version 1.1.0. 
> >> Still the site issue drives me nuts, too.
> >>
> >> Thanks again for helping me!
> >>
> >> kind regards,
> >>
> >> Thomas
> >>
> >> Am 27.10.2020 um 19:55 schrieb Benjamin Marwell :
> >>
> >> Hi Thomas,
> >>
> >> I tested your configuration and found the same issue – however, it may
> >> not be an issue after all.
> >>
> >> You configured your javadoc plugin as part of the reporting section.
> >> This usually requires the compile goal.
> >>
> >> Even if you add the jar goal to the default build->plugin section, it
> >> will still require compile to be executed. This is expected and
> >> documented in [2]:
> >> "Requires dependency resolution of artifacts in scope: compile. &&
> >> Binds by default to the lifecycle phase: package."
> >>
> >> Same description for the javadoc:javadoc goal.
> >>
> >> "mvn package site" will work because "package" includes the "compile"
> >> goal from the default lifecycle.
> >>
> >> site (on its own) however is it's own lifecycle and goal and does not
> >&

Re: Dependency plugin unpack plugin dependencies

[Benjamin Marwell]

Hi Alexander,

this is an old thread, but no one has replied yet.
While I think this is possible – what are you trying to achieve?
Or in other words: WHY do you need the dependencies unpacked? What do
you do with them?


Regards,
Ben

On 2020/08/19 18:23:06, Alexander Broekhuis  wrote:
> Hi all,
>
> I currently have a setup in which I have some custom artifacts that I use
> as dependencies and unpack using unpack-dependencies.
> This all works great, but now I also have a custom plugin which needs one
> of the custom artifacts as dependency. I don't see those dependencies being
> unpacked.  Is this correct, or am I doing something wrong?
>
> I know I can add the dependency as "regular" dependency as workaround, but
> I'd like to be able to define the plugin in a parent's pluginManagement
> with it's dependencies so that dependant project can enable the plugin when
> needed without having to define the dependency, or always have it being
> unpacked even if not needed.
>
> Basically my pom looks like this (meta):
>
> // Those are unpacked as expected
> 
> 
> 
>
> // Those dependencies are not unpacked
> 
> 
> 
> 
> 
> 
> 
>
> --
> Met vriendelijke groet,
>
> Alexander Broekhuis
>

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

Re: Need help: maven-javadoc-plugin: includeDependencySource: error: module not found on module source path

[Benjamin Marwell]

Hi Thomas,

I investigated a bit further. It seems from the debug output, that the
remote sources were fetched.  Thus, the error seems misleading:

[DEBUG] Expanding:
$USER/.m2/repository/de/uni-stuttgart/informatik/fius/ICGE-Simulation/2.3.6/ICGE-Simulation-2.3.6-sources.jar
into 
$USER/git/apache/jvk/project/target/distro-javadoc-sources/ICGE-Simulation-2.3.6-sources
[DEBUG] Trying to add links for modules...
[ERROR] no reactor project: de.uni-stuttgart.informatik.fius:ICGE-Simulation


So I tried to add this path manually like this:


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


--show-packages=all

de.unistuttgart.informatik.fius.jvk.tasks:de.unistuttgart.informatik.fius.jvk.verifier
+
true

true


https://fius.github.io/ICGE2/${icge.version}

+
${sourcepath}:target/distro-javadoc-sources/ICGE-Simulation-2.3.6-sources




And:
BUILD SUCCESS

So I think you found a bug where module sources are not being added to
the javadoc source path AND there is a misleading error message.
Would you kindly open two issues?

Am Mi., 28. Okt. 2020 um 20:18 Uhr schrieb Benjamin Marwell
:
>
> Hi Tim,
>
> this lines makes me wonder:
>
> > [ERROR] no reactor project:  > of my project>
>
> I think this means that  will only work with
> dependencies from the same reactor project. Thus your
> "group_id:artifact_id of the single dependency of my project" seems to
> be a foreign project?
>
> But then from the goal description [1] it does not mention "must be on
> the same reactor project".
> Do you see a message that "group_id:artifact_id:source:jar could not
> be fetched" or similar?
>
>
> [1] https://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html
>
> Am Sa., 17. Okt. 2020 um 18:08 Uhr schrieb Tim Neumann
> :
> >
> > Hello everybody,
> >
> > I'm struggling to get javadoc generation with includeDependencySource
> > working in my project.
> >
> > When setting includeDependencySource to true in the pom and running mvn
> > clean install javadoc:aggregate or mvn clean install javadoc:javadoc
> >
> > I get the following errors:
> >
> > First: [ERROR] no reactor project:  > dependency of my project>
> >
> > And a few lines later a BUILD FAILURE because the javadoc tool exited
> > with the following error:
> > Exit code: 1 -
> > /path/to/my/project/target/distro-javadoc-sources/--sources/module-info.java:10:
> > error: module not found on module source path
> >
> > But the source of the dependency seems to be fetched and unpacked
> > correctly to
> > /path/to/my/project/target/distro-javadoc-sources/--sources/
> > The line (10) where the error is is the module definition of the single
> > in that project.
> >
> > The generated javdoc options file contains only one module-source-path:
> > /path/to/my/project/target/site/apidocs/src which contains a single
> > empty folder named like the module of my project (not the dependency).
> >
> > Did anyone have a similar problem before? Any ideas what to try?
> >
> > If anyone wants to look at the whole pom or try to reproduce it, the
> > project is on github: https://github.com/fius/jvk in the folder project.
> > The only dependency of that project is also on github:
> > https://github.com/FIUS/ICGE2
> > For trying to get this to work I made some changes to both, which are
> > not merged yet. See these pull-requests:
> > https://github.com/FIUS/ICGE2/pull/186 and
> > https://github.com/FIUS/jvk/pull/71
> > For this testing I'm using version 2.3.5-Snapshot of the dependency and
> > just locally running mvn clean install in it instead of uploading it to
> > a maven repository.
> >
> > Regards,
> > Tim
> >
> > --
> > Tim Neumann (GPG-Key: B5BD 17C3 BD4A 7BA4)
> > stv. Referent für IT Betreung
> > Studierendenvertretung Uni Stuttgart
> > https://stuvus.uni-stuttgart.de
> >
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >

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

Re: Need help: maven-javadoc-plugin: includeDependencySource: error: module not found on module source path

[Benjamin Marwell]

Hi Tim,

this lines makes me wonder:

> [ERROR] no reactor project:  my project>

I think this means that  will only work with
dependencies from the same reactor project. Thus your
"group_id:artifact_id of the single dependency of my project" seems to
be a foreign project?

But then from the goal description [1] it does not mention "must be on
the same reactor project".
Do you see a message that "group_id:artifact_id:source:jar could not
be fetched" or similar?


[1] https://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html

Am Sa., 17. Okt. 2020 um 18:08 Uhr schrieb Tim Neumann
:
>
> Hello everybody,
>
> I'm struggling to get javadoc generation with includeDependencySource
> working in my project.
>
> When setting includeDependencySource to true in the pom and running mvn
> clean install javadoc:aggregate or mvn clean install javadoc:javadoc
>
> I get the following errors:
>
> First: [ERROR] no reactor project:  dependency of my project>
>
> And a few lines later a BUILD FAILURE because the javadoc tool exited
> with the following error:
> Exit code: 1 -
> /path/to/my/project/target/distro-javadoc-sources/--sources/module-info.java:10:
> error: module not found on module source path
>
> But the source of the dependency seems to be fetched and unpacked
> correctly to
> /path/to/my/project/target/distro-javadoc-sources/--sources/
> The line (10) where the error is is the module definition of the single
> in that project.
>
> The generated javdoc options file contains only one module-source-path:
> /path/to/my/project/target/site/apidocs/src which contains a single
> empty folder named like the module of my project (not the dependency).
>
> Did anyone have a similar problem before? Any ideas what to try?
>
> If anyone wants to look at the whole pom or try to reproduce it, the
> project is on github: https://github.com/fius/jvk in the folder project.
> The only dependency of that project is also on github:
> https://github.com/FIUS/ICGE2
> For trying to get this to work I made some changes to both, which are
> not merged yet. See these pull-requests:
> https://github.com/FIUS/ICGE2/pull/186 and
> https://github.com/FIUS/jvk/pull/71
> For this testing I'm using version 2.3.5-Snapshot of the dependency and
> just locally running mvn clean install in it instead of uploading it to
> a maven repository.
>
> Regards,
> Tim
>
> --
> Tim Neumann (GPG-Key: B5BD 17C3 BD4A 7BA4)
> stv. Referent für IT Betreung
> Studierendenvertretung Uni Stuttgart
> https://stuvus.uni-stuttgart.de
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

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

Re: Java11 and javadoc plugin

[Benjamin Marwell]

Hi Thomas,

no worry, that is as easy to fix as the previous one.

Read carefully:
> Error generating maven-javadoc-plugin:3.2.0:test-aggregate-no-fork

The javadoc-plugin executes "test-aggregate-no-fork".

Which means: It creates javadoc for your TEST classes from src/test/java.
That again requires the "test" goal to be run first [1].
> Requires dependency resolution of artifacts in scope: test.

I rarely found it useful to generate, validate and publish javadoc for
test classes.

Long story short:
mvn test site # (test includes compile).

Although imho, you will always want to execute "mvn verify" (or "mvn
clean verify") anyway, wouldn’t you? ;-)
This is considered a good habit by Robert Scholte iirc.

If you need more information on the "why", don’t hesitate to ask! :)

[1] 
https://maven.apache.org/plugins/maven-javadoc-plugin/test-aggregate-no-fork-mojo.html

Am Mi., 28. Okt. 2020 um 14:45 Uhr schrieb Thomas Scheffler
:
>
> Hi,
>
> thanks for looking into it. I updated the project a bit so that you can 
> easily switch the version with „-Djavadoc.plugin.version=3.0.1“ to see it 
> working nice with „mvn site“ and „mvn javadoc:javadoc“. My problem is, that I 
> don’t know how to make „site“ run again. „mvn compile site“ will prevent the 
> errors for the main javadocs but will fail on test javadocs (Junit tests):
>
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-site-plugin:3.9.1:site (default-site) on 
> project test: Error generating 
> maven-javadoc-plugin:3.2.0:test-aggregate-no-fork report:
> [ERROR] Exit code: 2 - javadoc: error - No source files for package 
> de.yagee.test
> [ERROR]
> [ERROR] Command line was: /Users/yagee/Java/Home/14/bin/javadoc @options 
> @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in 
> '/Users/yagee/git/javadoc-test/target/site/testapidocs' dir.
> [ERROR] -> [Help 1]
>
> I can stick with 3.0.1 for a while, but of cause I want to move forward. I 
> set up the minimal project to get this figured out, but I lost.
>
> Looking at https://maven.apache.org/plugins/maven-javadoc-plugin/usage.html, 
> there is even no hint on suddenly requiring „compile“ starting with version 
> 1.1.0. Still the site issue drives me nuts, too.
>
> Thanks again for helping me!
>
> kind regards,
>
> Thomas
>
> Am 27.10.2020 um 19:55 schrieb Benjamin Marwell :
>
> Hi Thomas,
>
> I tested your configuration and found the same issue – however, it may
> not be an issue after all.
>
> You configured your javadoc plugin as part of the reporting section.
> This usually requires the compile goal.
>
> Even if you add the jar goal to the default build->plugin section, it
> will still require compile to be executed. This is expected and
> documented in [2]:
> "Requires dependency resolution of artifacts in scope: compile. &&
> Binds by default to the lifecycle phase: package."
>
> Same description for the javadoc:javadoc goal.
>
> "mvn package site" will work because "package" includes the "compile"
> goal from the default lifecycle.
>
> site (on its own) however is it's own lifecycle and goal and does not
> contain the default's lifecycle compile goal. See [1].
>
> Everything you reported works as expected. From what I can tell it
> shouldn’t have worked with other java versions and/or other javadoc
> plugin versions either.
>
> Does this help you? If not, maybe you might want to explain your
> execution idea instead. This will help us getting an idea of what you
> are trying to achieve.
>
> Best regards,
> Ben
>
> [1] 
> https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
> [2] https://maven.apache.org/plugins/maven-javadoc-plugin/jar-mojo.html
>
> Am Mo., 26. Okt. 2020 um 12:49 Uhr schrieb Thomas Scheffler
> :
>
>
> Hi,
>
> I have serious problems getting any maven-javadoc-plugin >= 3.1.0 to work 
> with simply Java 11 test case:
>
> Neither will „mvn javadoc:javadoc“ nor „mvn javadoc:jar“ nor „mvn site“ work 
> out-of-the-box. I have to add „compile“ in the middle to get the 
> javadoc-plugin work but this will not fix the site generation.
>
> What’s wrong with the pom.xml or with maven (using version 3.6.3)?
>
> I created a small test project on github: 
> https://github.com/yagee-de/javadoc-test
>
> The output I get is like:
>
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-javadoc-plugin:3.2.0:jar (default-cli) on 
> project test: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 - error: module not found: de.yagee.test
> [ERROR]
> [ERROR] Command line was: /Users/yagee/Java/

Re: Java11 and javadoc plugin

[Benjamin Marwell]

Hi Thomas,

I tested your configuration and found the same issue – however, it may
not be an issue after all.

You configured your javadoc plugin as part of the reporting section.
This usually requires the compile goal.

Even if you add the jar goal to the default build->plugin section, it
will still require compile to be executed. This is expected and
documented in [2]:
"Requires dependency resolution of artifacts in scope: compile. &&
Binds by default to the lifecycle phase: package."

Same description for the javadoc:javadoc goal.

"mvn package site" will work because "package" includes the "compile"
goal from the default lifecycle.

site (on its own) however is it's own lifecycle and goal and does not
contain the default's lifecycle compile goal. See [1].

Everything you reported works as expected. From what I can tell it
shouldn’t have worked with other java versions and/or other javadoc
plugin versions either.

Does this help you? If not, maybe you might want to explain your
execution idea instead. This will help us getting an idea of what you
are trying to achieve.

Best regards,
Ben

[1] 
https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
[2] https://maven.apache.org/plugins/maven-javadoc-plugin/jar-mojo.html

Am Mo., 26. Okt. 2020 um 12:49 Uhr schrieb Thomas Scheffler
:
>
> Hi,
>
> I have serious problems getting any maven-javadoc-plugin >= 3.1.0 to work 
> with simply Java 11 test case:
>
> Neither will „mvn javadoc:javadoc“ nor „mvn javadoc:jar“ nor „mvn site“ work 
> out-of-the-box. I have to add „compile“ in the middle to get the 
> javadoc-plugin work but this will not fix the site generation.
>
> What’s wrong with the pom.xml or with maven (using version 3.6.3)?
>
> I created a small test project on github: 
> https://github.com/yagee-de/javadoc-test
>
> The output I get is like:
>
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-javadoc-plugin:3.2.0:jar (default-cli) on 
> project test: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 - error: module not found: de.yagee.test
> [ERROR]
> [ERROR] Command line was: /Users/yagee/Java/Home/11/bin/javadoc @options 
> @packages @argfile
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in 
> '/Users/yagee/git/javadoc-test/target/apidocs' dir.
> [ERROR]
> [ERROR] -> [Help 1]
>
> Any help is highly appreciated!
>
> Kind regards,
>
> Thomas

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

Re: HTTP/2 support in Maven

[Benjamin Marwell]

http/2 is not available before Java 8.
ALPN and TLS 1.3 are requirements for h2.

I saw httpClient 5 implemented http/2. That's fine and that's why you may
have successfully connected tomcat with a http/2 client.

Try another application server which does not use httpClient, e.g.
OpenLiberty. You will not be able to have a http/2 server side protocol
support.


I hope this helped for clarification. Thus, I consider my previous mail
*not* nonsense.

If maven didn't use httpClient (which I was not aware of at time of
writing), my statement would have been true: just use Java 9+ and it will
connect via http/2.

I am sorry this caused confusion, but I did not like your response which
did sound "aggressive" to me. I will therefore not contribute to this
project soon.


On Sun, 25 Oct 2020, 19:54 Michael Osipov,  wrote:

> Am 2020-10-25 um 19:09 schrieb Benjamin Marwell:
> > While TLS 1.3 and ALPN (and ciphers) may have been backported, I am not
> > aware of http2 being backported to Java 8. Even if it was, it would not
> be
> > part of EVERY JVM implementation, eg Eclipse OpenJ9.
>
> You are talking non-sense. Don't mix lower level protocols like TLS with
> application protocols. Moreover, there is still h2c.
>
> Tomcat 8.5+ just works fine with h2 and h2c when connected via curl.
>
> > On Sun, 25 Oct 2020, 09:52 Michael Osipov,  wrote:
> >
> >> Am 2020-10-24 um 14:25 schrieb Benjamin Marwell:
> >>> You need at least java 9 for http/2. Java 11 is a current LTS release
> >> which
> >>> supports h2.
> >>
> >> Why? TLS 1.3 and ALPN have been backported to Java 8 recently.
> >>
> >>> Is there anything in the transport code preventing h2 transport?
> >>
> >> Yes, your participation to do the work!
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: HTTP/2 support in Maven

[Benjamin Marwell]

While TLS 1.3 and ALPN (and ciphers) may have been backported, I am not
aware of http2 being backported to Java 8. Even if it was, it would not be
part of EVERY JVM implementation, eg Eclipse OpenJ9.





On Sun, 25 Oct 2020, 09:52 Michael Osipov,  wrote:

> Am 2020-10-24 um 14:25 schrieb Benjamin Marwell:
> > You need at least java 9 for http/2. Java 11 is a current LTS release
> which
> > supports h2.
>
> Why? TLS 1.3 and ALPN have been backported to Java 8 recently.
>
> > Is there anything in the transport code preventing h2 transport?
>
> Yes, your participation to do the work!
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: HTTP/2 support in Maven

[Benjamin Marwell]

You need at least java 9 for http/2. Java 11 is a current LTS release which
supports h2.

Is there anything in the transport code preventing h2 transport?

Ben






On Fri, 23 Oct 2020, 11:28 Olivier Lamy,  wrote:

> There is some effort started here
> https://github.com/jetty-project/jetty-maven-wagon
> but this needs more tests/debug etc...
> feel free to test,m report issues, propose fix etc...
>
> On Fri, 23 Oct 2020 at 18:09, Jakub Bartecek  wrote:
>
> > Hello,
> > I'd like to ask if it is possible to turn on HTTP/2 support in Maven. I
> > haven't found such an option.
> >
> > If not: Are there any plans to add the support?
> >
> > Regards,
> > Kuba
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: Access or generate a classpath for dependency not in any scope but attached to plugin.

[Benjamin Marwell]

Feature requests can be created here:
https://issues.apache.org/jira/projects/MCHECKSTYLE

You are welcome to create a pull request.

Looking at the ant configuration, you could just use the plugin
classpath in your java task:
https://maven.apache.org/plugins/maven-antrun-plugin/examples/classpaths.html


Am Do., 25. Juni 2020 um 09:16 Uhr schrieb LINUS FERNANDES
:
>
> I would like to create a feature request---evidently.
>
> This is something that impacts the ant and Gradle tasks as well.
>
> I'm not sure where to make this request.
>
> Should it be on the Checkstyle Github repo or will I have to make three
> separate requests, one for each of the above?
>
> The feature is available on the CLI using the -g option.
>
> I intend to use this during the Maven build, not from my code.
>
> Since I already had Ant configured to do exactly that, I preferred to use
> the Ant Run plugin to reproduce the functionality within Maven.
>
> The pom file is located at:
>
> https://github.com/Fernal73/DSAlgos/blob/master/pom.xml
>
> I have no interest in creating my own plugin given the attendant issues of
> maintaining it and for just this feature.
>
> This should really be part of the Maven, Ant and Gradle configurations.
>
> Perhaps, it's because the feature is still considered experimental and
> there's no pressure from users to add the ability to generate Xpath
> suppressions in the other ways to use Checkstyle.
>
> I find it very useful, though although it's complicated to set it up in its
> current Avatar.
>
> Regards,
> Linus.
>
>
>
>
> On Thu, 25 Jun 2020, 11:56 Benjamin Marwell,  wrote:
>
> > Well, you could write your own plugin which has checkstyle as a dependency.
> > But it might be the easiest to just create a PR for the checkstyle plugin.
> > The checkstyle plugin is maintained by maven. So why not just create a
> > feature request?
> >
> > Also, where do you want to execute the "new goal"? In the maven build
> > or inside your java code? This will also make a difference.
> > If it is the latter, you can just pull in the plugin as a regular
> > dependency.
> > You can make it optional or provided (or both) if you do not need it at
> > runtime.
> >
> > Am Do., 25. Juni 2020 um 03:49 Uhr schrieb LINUS FERNANDES
> > :
> > >
> > > My usecase is that I need to execute a feature available in Checkstyle
> > > that's not provided as a goal in its plugin.
> > >
> > > For that, I need access to the dependency classpath (latest version
> > > always).
> > >
> > > Then I can execute the feature using the Ant Run plugin.
> > >
> > >
> > >
> > >
> > > On Thu, 25 Jun 2020, 06:51 LINUS FERNANDES, 
> > > wrote:
> > >
> > > > Is it possible to generate a classpath for a dependency not placed in
> > the
> > > > dependencyManagement and/or dependencies section but is attached to a
> > > > plugin used by the project?
> > > >
> > > > I know it's possible to generate a path to the local repository and
> > look
> > > > for the latest version directory and specify the jars under it but is
> > there
> > > > any other way to do this preferably via a Maven plugin and one of its
> > goals?
> > > >
> > > > build-classpath from the Maven dependency plugin will only generate
> > > > classpaths for dependencies listed in the project's dependencies, not a
> > > > plugin's direct dependencies.
> > > >
> > > > I don't wish to add a plugin's specific dependencies to the project's
> > > > dependencies.
> > > >
> > > > Regards,
> > > > Linus.
> > > >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >

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

Re: Access or generate a classpath for dependency not in any scope but attached to plugin.

[Benjamin Marwell]

Well, you could write your own plugin which has checkstyle as a dependency.
But it might be the easiest to just create a PR for the checkstyle plugin.
The checkstyle plugin is maintained by maven. So why not just create a
feature request?

Also, where do you want to execute the "new goal"? In the maven build
or inside your java code? This will also make a difference.
If it is the latter, you can just pull in the plugin as a regular dependency.
You can make it optional or provided (or both) if you do not need it at runtime.

Am Do., 25. Juni 2020 um 03:49 Uhr schrieb LINUS FERNANDES
:
>
> My usecase is that I need to execute a feature available in Checkstyle
> that's not provided as a goal in its plugin.
>
> For that, I need access to the dependency classpath (latest version
> always).
>
> Then I can execute the feature using the Ant Run plugin.
>
>
>
>
> On Thu, 25 Jun 2020, 06:51 LINUS FERNANDES, 
> wrote:
>
> > Is it possible to generate a classpath for a dependency not placed in the
> > dependencyManagement and/or dependencies section but is attached to a
> > plugin used by the project?
> >
> > I know it's possible to generate a path to the local repository and look
> > for the latest version directory and specify the jars under it but is there
> > any other way to do this preferably via a Maven plugin and one of its goals?
> >
> > build-classpath from the Maven dependency plugin will only generate
> > classpaths for dependencies listed in the project's dependencies, not a
> > plugin's direct dependencies.
> >
> > I don't wish to add a plugin's specific dependencies to the project's
> > dependencies.
> >
> > Regards,
> > Linus.
> >

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

Re: Conditional import of Java class based on dependency version

[Benjamin Marwell]

Well, if the Dependency version changed with the target java  Bytecode
version, you could create a multirelease jar and manage the dependencies
via profiles.

But that would seem not feasible to me.
What's your use case?
Or maybe you could refactor that class(es) into modules instead?

Best regards,
Ben




On Tue, 9 Jun 2020, 13:51 Jagat Singh,  wrote:

> Hi,
>
> I wanted to learn what is the pattern in maven when we have to change the
> import at the top of class based on dependency version.
>
> Example in Java code
>
> If dependency version is 1.0
> Then import path
>
> import com.hello.Class
>
> If dependency version is 2.0
> Then import path
>
> import com.hello2.Class
>
>
> Thanks in advance.
>

Re: JVM Arguments not working for JDK11

[Benjamin Marwell]

Hi Ankit,

the appassembler-maven-plugin [1] is maintained by mojohaus, they have
a different mailing list on google groups:
https://www.mojohaus.org/mail-lists.html

HTH
Ben

[1] https://www.mojohaus.org/appassembler/appassembler-maven-plugin/

Am Do., 4. Juni 2020 um 00:46 Uhr schrieb Ankit Tomar
:
>
> Missed plugin name, I am using appassembler-maven-plugin
> I have tried  and  but both are not
> working.
>
> Thanks & Regards,
> Ankit
>
>
> On Tue, Jun 2, 2020 at 11:21 PM Ankit Tomar 
> wrote:
>
> > Hi Team,
> >
> > I need to pass jvmArguments in the plugin but they are not working.
> > We are using embedded cassandra in our application and it tries to access
> > JDK's internal classes and after JDK 11 Java has put strict checks on
> > internal class access using reflection . There is one work-around for it
> > that is to pass packages to access using *--add-exports *option .
> >
> > I need to pass below option to plugin:
> >
> > -Djdk.attach.allowAttachSelf=true --add-exports
> > java.base/jdk.internal.misc=ALL-UNNAMED --add-exports
> > java.base/jdk.internal.ref=ALL-UNNAMED --add-exports 
> > java.base/sun.nio.ch=ALL-UNNAMED
> > --add-exports
> > java.management.rmi/com.sun.jmx.remote.internal.rmi=ALL-UNNAMED
> > --add-exports java.rmi/sun.rmi.registry=ALL-UNNAMED --add-exports
> > java.rmi/sun.rmi.server=ALL-UNNAMED --add-exports
> > java.sql/java.sql=ALL-UNNAMED  --add-opens
> > java.base/java.lang.module=ALL-UNNAMED --add-opens
> > java.base/jdk.internal.loader=ALL-UNNAMED --add-opens
> > java.base/jdk.internal.ref=ALL-UNNAMED --add-opens
> > java.base/jdk.internal.reflect=ALL-UNNAMED --add-opens
> > java.base/jdk.internal.math=ALL-UNNAMED --add-opens
> > java.base/jdk.internal.module=ALL-UNNAMED --add-opens
> > java.base/jdk.internal.util.jar=ALL-UNNAMED --add-opens
> > jdk.management/com.sun.management.internal=ALL-UNNAMED
> >
> > Please suggest how to pass these arguments.
> >
> > Thanks & Regards,
> > Ankit
> >
> >

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

[compiler-plugin] Question about multiple compiler executions

[Benjamin Marwell]

Hi everyone,

In a project, I currently configured three executions of the maven
compiler plugin.

1. proc:only, generate annotations for org.immutable
2. proc:only, generate annotations for hibernate-static-metamodel (not
all modules)
3. proc:none, i.e. compile everything.

For this to work, I have to set
false to use
incremental compilation (reversed property, this is a known issue).
On the shell it works just fine.

My question is: Is this setup "using maven the intended way"? I am
asking, because no IDE supports this right now. Each time I touch a
file which will be processed by an annotation processor, I need to
execute "mvn clean compile -DskipTests". Clean IS necessary, because
maven does not know that the resulting output of the generated sources
will be different. Setting useIncrementalCompilation=true (or not
setting it) will also not work, they will just overwrite each other -
the third compilation execution will not find any generated sources.

I would be happy to hear your experiences with this topic.

Thanks,
Ben

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

Re: Maven Dependencies Pop Quiz

[Benjamin Marwell]

Great quiz!

I got 12/14 because I was a bit lazy in the beginning.
Forgot my twitter handle, please add @bmarwell - thanks!

If you had some experience with wrong or mixed dependency versions, it
is pretty straightforward.
But if you never had these problems, it is very hard to solve!

Thanks for sharing!

Am Do., 26. März 2020 um 18:01 Uhr schrieb Andres Almiray :
>
> Hello everyone!
>
> If I can ask you for 15 minutes of your time, I've put of a 14 question pop
> quiz on dependency resolution. I'm hopeful that this quiz will let us
> realize a few things about the dependency resolution mechanism and its
> rules, perhaps address concerns in the future and make Maven better as a
> result.
>
> The quiz can be found at https://bit.ly/maven-dependencies-popquiz and is
> totally anonymous (no email address collected). Unless you feel like
> sharing your name ;-)
>
> Some preliminary numbers to this date:
>
>  - 3 people have 13 correct answers
>  - 3 people have 12correct answers
>  - 10 people have 11 correct answers
>
> The current median is 8. Some quick feedback left:
>
>  - pretty tricky, even for an almost 20 year maven dude. good job!
>  - I've never seen documentation on this
>  - Good food for thought. I guess I generally hope Maven does what I expect
> and when it doesn't, I start specifying more exactly what I want.
>
> Please feel free to share it with your colleagues and friends. More entries
> mean more data and better results. Thank you!
>
> Cheers,
> Andres
>
> ---
> Java Champion; Groovy Enthusiast
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.

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

Re: maven-ear-plugin: Cannot copy a directory

[Benjamin Marwell]

Hi,

I think I found the reason.

In the verify phase, I am executing errorprone, which uses the
maven-compiler-plugin.

Although I compile to target/classes-ep (instead of target/classes),
somehow this seems to un-append artifacts.

I think that the execution of an addition compilation should not
un-append artifacts from the project build, should it?

Ben

Am Mo., 3. Feb. 2020 um 11:08 Uhr schrieb Benjamin Marwell :
>
> Hi all,
>
> since today my ear-plugin configuration does not work anymore and
> stops with an exception.
>
> I pull in a dependency (type war) from another module in the same
> reactor. I also pull the same dependency in again with a classifier
> and another type to be used with the maven-assembly-plugin.
>
> Anyway, maven-ear-plugin does not try to pull in the war file, but the
> target/classes directory instead:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-ear-plugin:3.0.1:ear (default-ear) on
> project ear: Cannot copy a directory:
> $HOME/svn/project/web/ui-v2/target/classes; Did you package/install
> project:webui-v2:war:1.4.0-SNAPSHOT:compile? -> [Help 1]
>
> As I am using verify as goal. I checked that both the packages were
> created in the referenced module.
>
> Any ideas where to look next?
>
> Thanks,
> Ben

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

maven-ear-plugin: Cannot copy a directory

[Benjamin Marwell]

Hi all,

since today my ear-plugin configuration does not work anymore and
stops with an exception.

I pull in a dependency (type war) from another module in the same
reactor. I also pull the same dependency in again with a classifier
and another type to be used with the maven-assembly-plugin.

Anyway, maven-ear-plugin does not try to pull in the war file, but the
target/classes directory instead:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-ear-plugin:3.0.1:ear (default-ear) on
project ear: Cannot copy a directory:
$HOME/svn/project/web/ui-v2/target/classes; Did you package/install
project:webui-v2:war:1.4.0-SNAPSHOT:compile? -> [Help 1]

As I am using verify as goal. I checked that both the packages were
created in the referenced module.

Any ideas where to look next?

Thanks,
Ben

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

Re: maven enforcer ensure javadoc attached

[Benjamin Marwell]

Hi Jon,

I think you could use the verifier-plugin for checking file existence.

https://maven.apache.org/plugins/maven-verifier-plugin/verify-mojo.html

Am So., 2. Feb. 2020 um 17:55 Uhr schrieb Jon Harper :
>
> Hi list,
>
> I would like to use maven-enforcer-plugin to ensure that javadocs are
> attached in release mode before installing. That's because I use
> $ mvn package javadoc:aggregate-jar deploy
> to build, so if someone forgets to call the aggregate-jar goal, the
> release will be missing the javadoc.
>
> I don't see any rule to enforce this (the closest I found is
> https://github.com/elastic/attached-artifact-enforcer which does the
> opposite, ensure that something is not attached).
>
> Is it possible to do what I want using the standard rules ? If not,
> would you consider to add new rules for this ?
>
> Thanks,
> Jon
>
> Note: I need to use javadoc:aggregate-jar on the command line and not
> part of the lifecycle because:
> - I want the aggregated javadoc to be attached to the root pom
> artifact, not some child "distribution"-like artifact
> - I want the aggregated javadoc to be created after the submodules
> have been built.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

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