[ANN] Apache Resource Bundles 1.7 Released

[Konrad Windszus]

The Apache Maven team is pleased to announce the release of the Apache Resource 
Bundles, version 1.7

https://maven.apache.org/apache-resource-bundles/


Release Notes - Apache Maven Resource Bundles - Version 1.7

** Bug
* [MASFRES-69] - All files having a filename containing "target" are 
excluded
* [MASFRES-70] - ITs in ASF Jenkins use wrong artifact for testing


** Improvement
* [MASFRES-67] - Exclude ".flattened-pom.xml" generated by 
flatten-maven-plugin
* [MASFRES-71] - Build fails in 
org.apache.maven.plugins:maven-surefire-report-plugin when running without clean


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: [VOTE] Require Java 17 for Maven 4

[Konrad Windszus]

+1

Konrad

> On 28. Feb 2024, at 08:30, Benjamin Marwell  wrote:
> 
> 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: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


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

Re: enforce module descriptions

[Konrad Windszus]

You can probably use 
https://www.mojohaus.org/extra-enforcer-rules/requirePropertyDiverges.html to 
enforce a distinct description per module.

Konrad

> On 9. Feb 2024, at 17:48, Delany  wrote:
> 
> Yes. I mean, of course, right? Description is like name and artifactId.
> These should never inherit.
> 
> On Thu, 8 Feb 2024, 22:42 ,  wrote:
> 
>>> I also want to require a description for each module.
>> 
>> you mean enforce a different description in a module vs its parent value?
>> 
>> - Mail original -
>> De: "Delany" 
>> À: "Maven Users List" 
>> Envoyé: Jeudi 8 Février 2024 06:27:55
>> Objet: enforce module descriptions
>> 
>> Hi. I'm using enforcer to require a project description
>> https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
>> 
>> But I also want to require a description for each module.
>> The description is inherited so they will always have a description.
>> 
>> Is this possible?
>> 
>> Thanks,
>> Delany
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 

Re: Authoring Maven Mojos for Maven 3.9.x - Maximum bytecode version=Java14

[Konrad Windszus]

I think we should revise the decision to not backport 
https://issues.apache.org/jira/projects/MNG/issues/MNG-7587 

 to Maven 3.9.x…

> On 16. Oct 2023, at 22:08, Garret Wilson  wrote:
> 
> On 10/16/2023 4:59 PM, Tamás Cservenák wrote:
>> You'd use Plexus?  In 2023?
> 
> I don't know what I'd use. I'm asking. I haven't written a Maven plugin yet. 
> I'm just reading the latest documentation, and the [Plugin Developers 
> Centre](https://maven.apache.org/plugin-developers/) seems to say at 
> https://maven.apache.org/maven-jsr330.html that I either have to use Plexus 
> or JSR-330, and you just told me I can't use JSR-330, so that leaves Plexus.
> 
> If I'm not understanding the documentation correctly, please point out what 
> I'm missing.
> 
>> …
>> In other words: whatever is "managed by sisu, should be max Java 14"
>> bytecode in current release Maven versions. Naturally, this does NOT apply
>> to ANY code, just those being JSR330 (and Mojo) annotated.
> 
> Maybe you are saying I can write a Maven plugin without using Plexus or 
> JSR-330? So dependency injection in Maven Plugins is optional? The page at 
> https://maven.apache.org/maven-jsr330.html makes it seem like dependency 
> injection in a Maven Plugin is a common thing.
> 
> (Maybe your announcement makes perfect sense to those who have written Maven 
> plugins before. In the meantime I'm reading the online documentation and 
> trying to understand how this will affect me once I write a plugin.)
> 
> Garret
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 

Re: release of depends-maven-plugin?

[Konrad Windszus]

Hi Julian, you would probably have to ask the ServiceMix team as it is their 
plug-in.
Maven committers in general cannot trigger releases there.

Konrad

> On 10. May 2023, at 13:37, Julian Reschke  wrote:
> 
> Hi there,
> 
> we'd like to update Jackrabbit Oak to reproducable builds, and it seems
> we need a version of the depends-maven-plugin containing the fix for
> https://issues.apache.org/jira/browse/SM-5021. Any chance this might
> come out anytime soon?
> 
> (And yes, I'm aware of the potential workaround)
> 
> Best regards, Julian
> 
> -
> 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: [m-site-plugin] Error reading site descriptor

[Konrad Windszus]

I created https://issues.apache.org/jira/browse/DOXIASITETOOLS-301 to handle 
this issue more gracefully.
Konrad

> On 4. Apr 2023, at 11:00, Michael Osipov  wrote:
> 
> On 2023/04/03 03:41:28 Maxim Solodovnik wrote:
>> Hello Michael,
>> 
>> surprisingly it helped!
>> Thanks a million! :))
> 
> Not a surprise, this is on purpose: 
> https://issues.apache.org/jira/browse/DOXIASITETOOLS-294
> Read the issue description. The resolution is now done right.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 

Re: Connection timeouts during GitHub Actions with Maven 3.9.x

[Konrad Windszus]

Thanks for the reproducer and sorry for not reading thoroughly before. Indeed 
the connection pool is not configurable yet with the native connector. 
According to 
https://hc.apache.org/httpcomponents-client-4.5.x/current/httpclient/apidocs/org/apache/http/impl/conn/PoolingHttpClientConnectionManager.html
 stale connections are checked after 2 seconds before being reused but probably 
the check does not work for some reason with Azure….

> Am 27.03.2023 um 09:49 schrieb Michael Vitz 
> :
> 
> Hi Konrad,
> 
> The only two timeout related properties are aether.connector.requestTimeout
> and aether.connector.connectTimeout.
> Both do not solve my problem.
> 
> I created a GitHub project (
> https://github.com/mvitz/maven-39-gh-actions-timeouts) which reproduces the
> problem.
> It declares many dependencies/plugins to make sure the complete HTTP pool
> is used before the tests, contains a test that runs in total about 6
> minutes to take longer than the four-minute Azure timeout and uses Maven
> 3.9.1.
> 
> The first build (
> https://github.com/mvitz/maven-39-gh-actions-timeouts/actions/runs/4524745997/jobs/7968775993)
> uses -Daether.connector.requestTimeout=27 which is longer than four
> minutes and fails.
> The second one (
> https://github.com/mvitz/maven-39-gh-actions-timeouts/actions/runs/4524925829/jobs/7969075725)
> uses -Daether.connector.connectTimeout=6
> -Daether.connector.requestTimeout=18 which is shorter but fails, too.
> 
> Both builds fail with:
> Error:  Failed to execute goal
> org.apache.maven.plugins:maven-jar-plugin:3.3.0:jar (default-jar) on
> project maven-39-gh-actions-timeouts: Execution default-jar of goal
> org.apache.maven.plugins:maven-jar-plugin:3.3.0:jar failed: Plugin
> org.apache.maven.plugins:maven-jar-plugin:3.3.0 or one of its dependencies
> could not be resolved: Failed to collect dependencies at
> org.apache.maven.plugins:maven-jar-plugin:jar:3.3.0 ->
> org.apache.maven.shared:file-management:jar:3.1.0: Failed to read artifact
> descriptor for org.apache.maven.shared:file-management:jar:3.1.0: The
> following artifacts could not be resolved:
> org.apache.maven.shared:file-management:pom:3.1.0 (absent): Could not
> transfer artifact org.apache.maven.shared:file-management:pom:3.1.0 from/to
> central (https://repo.maven.apache.org/maven2): Read timed out -> [Help 1]
> 
> I suspect that the HTTP pool is fully used before the tests, all
> connections are silently interrupted during the test run that takes longer
> than the Azure limit of four minutes, and the pool unable to recover any
> connection from that.
> 
> As told before when using wagon with -Dmaven.resolver.transport=wagon and
> configuring a pool time to love of 3 minutes via
> -Dmaven.wagon.httpconnectionManager.ttlSeconds=180 everything works as
> expected (
> https://github.com/mvitz/maven-39-gh-actions-timeouts/actions/runs/4529868249/jobs/7978093099
> ).
> 
> Regards,
> Michael
> 
> 
>> Am So., 26. März 2023 um 12:54 Uhr schrieb Konrad Windszus >> :
>> 
>> The timeouts are configurable even with new native connector:
>> https://maven.apache.org/resolver/configuration.html.
>> Please try if those settings help.
>> Konrad
>> 
>>> Am 25.03.2023 um 15:08 schrieb Michael Vitz > .invalid>:
>>> 
>>> Hi all,
>>> 
>>> We recently switched from Maven 3.8.x to 3.9.x and all of a sudden, we
>> ran
>>> into connection timeouts during downloading the maven-jar-plugin after
>> all
>>> tests passed.
>>> 
>>> After some digging, I suspect that it is a combination of GitHub Actions
>>> running on Azure which silently drops open connections after around four
>>> minutes (see discussion in
>>> https://github.com/actions/runner-images/issues/1499) and the switch to
>> the
>>> native HTTP transport in Maven 3.9.x.
>>> Our tests take quite some time and because the maven-jar-plugin is
>> freshly
>>> downloaded after these, the used connection was opened before the tests
>>> were started and is dropped by Azure meanwhile.
>>> 
>>> Our current workaround is switching to the old Wagon HTTP provider (with
>>> -Dmaven.resolver.transport=wagon) and setting a TTL for the used HTTP
>> pool
>>> (-Dmaven.wagon.httpconnectionManager.ttlSeconds=180) or disabling the
>> pool
>>> and keep alive (-Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false).
>>> 
>>> Unfortunately, the new HTTP transport does not allow changing the TTL
>>> (which by default is -1 which means forever) or disabling it altogether.
>> It
>>> would be nice if such settings would be added in one of the next
>> releases.
>>> 
>>> I would be happy to help/try to provide a patch on my own if this helps.
>>> 
>>> Regards,
>>> Michael
>> 

Re: Connection timeouts during GitHub Actions with Maven 3.9.x

[Konrad Windszus]

The timeouts are configurable even with new native connector: 
https://maven.apache.org/resolver/configuration.html. 
Please try if those settings help.
Konrad

> Am 25.03.2023 um 15:08 schrieb Michael Vitz 
> :
> 
> Hi all,
> 
> We recently switched from Maven 3.8.x to 3.9.x and all of a sudden, we ran
> into connection timeouts during downloading the maven-jar-plugin after all
> tests passed.
> 
> After some digging, I suspect that it is a combination of GitHub Actions
> running on Azure which silently drops open connections after around four
> minutes (see discussion in
> https://github.com/actions/runner-images/issues/1499) and the switch to the
> native HTTP transport in Maven 3.9.x.
> Our tests take quite some time and because the maven-jar-plugin is freshly
> downloaded after these, the used connection was opened before the tests
> were started and is dropped by Azure meanwhile.
> 
> Our current workaround is switching to the old Wagon HTTP provider (with
> -Dmaven.resolver.transport=wagon) and setting a TTL for the used HTTP pool
> (-Dmaven.wagon.httpconnectionManager.ttlSeconds=180) or disabling the pool
> and keep alive (-Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false).
> 
> Unfortunately, the new HTTP transport does not allow changing the TTL
> (which by default is -1 which means forever) or disabling it altogether. It
> would be nice if such settings would be added in one of the next releases.
> 
> I would be happy to help/try to provide a patch on my own if this helps.
> 
> Regards,
> Michael

Re: 3.9.0 not respecting proxy settings

[Konrad Windszus]

Why not changing Native to call 
https://hc.apache.org/httpcomponents-client-4.5.x/current/httpclient/apidocs/org/apache/http/impl/client/HttpClientBuilder.html#useSystemProperties()
 by default (if nothing conflicting is explicitly configured)?
That way it would be more compatible with the Wagon impl.

> Am 24.02.2023 um 08:31 schrieb Tamás Cservenák :
> 
> Howdy,
> 
> Maven 3.9.0 changes default transport from Wagon to Native HTTP. Native
> would respect proxy IF set in settings.xml, that as you explain, does not
> fit your use case.
> 
> For now, with 3.9.0 you can fallback to Wagon using this
> "-Dmaven.resolver.transport=wagon"
> 
> HTH
> Tamas
> 
>> On Fri, Feb 24, 2023 at 8:16 AM Max Allan  wrote:
>> 
>> Hi,
>> 
>> I've got 2 separate maven builds configured like :
>> 
>> mvn clean install -Dhttps.proxyHost=$HTTPS_PROXY_HOST
>> -Dhttps.proxyPort=$HTTPS_PROXY_PORT -Dhttp.proxyHost=$HTTP_PROXY_HOST
>> -Dhttp.proxyPort=$HTTP_PROXY_PORT
>> 
>> That works fine on maven 3.8.7 but does not seem to even be trying to
>> connect to the proxy on 3.9.0.
>> 
>> The job fails with a load of errors like :
>> 
>> [FATAL] Non-resolvable parent POM for com.obfuscated:ldap:1.0.0-SNAPSHOT:
>> Could not transfer artifact
>> org.springframework.boot:spring-boot-starter-parent:pom:3.0.2 from/to
>> gitlab-maven (https://gitlab.domain/api/v4/groups/123/-/packages/maven):
>> Connect to gitlab.domain:443 [gitlab.domain/192.1.2.61] failed: Connect
>> timed out and 'parent.relativePath' points at wrong local POM @ line 6,
>> column 11
>> (URLs and paths obfuscated)
>> 
>> I cannot easily set the values in a settings.xml or elsewhere because the
>> proxy host is always different for each build and the proxy settings are
>> only needed in CICD, so adding them to settings would break local developer
>> builds.
>> 
>> If I move to a machine that has access to my GitLab without a proxy, then
>> the job works in 3.9.0. Even though there is no proxy and it should be
>> trying to use it. (so it should fail).
>> 
>> Is there a new requirement for specifying proxies in 3.9.0 or is it broken?
>> 
>> Max
>> 

Re: Artifact Resolver configuration documentation - server.xml ?

[Konrad Windszus]

Thanks for the pointer, fixed in 
https://github.com/apache/maven-resolver/commit/18a16c8313ccef934301d56696254cf4f9962410.

Konrad

On 2023/02/19 17:29:31 Tamás Cservenák wrote:
> Yup,
> 
> Is mistake, it meant settings.xml, not server.xml.
> 
> Hth
> T
> 
> On Sun, Feb 19, 2023, 16:58 Dominique Comte 
> wrote:
> 
> > Hi,
> >
> > The page https://maven.apache.org/resolver/configuration.html mentions at
> > the very end a “server.xml” file:
> >
> > Sometimes Maven uses different default values than the Maven Resolver
> > itself or tries to extract certain values from the server.xml. For details
> > refer to
> > https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java
> > .
> >
> > But the linked source file only reads “settings.xml” on line 175.
> > Is that a documentation mistake ? I cannot find a mention of a
> > “server.xml” file anywhere else in the configuration pages of Maven.
> >
> >
> > Regards,
> > Dominique
> 

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

Re: Named Lock implementation for Maven with Jenkins

[Konrad Windszus]

Hi Mirko,
Right, but isn’t “file-lock” relying internally on 
https://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileLock.html which 
says: "This file-locking API is intended to map directly to the native locking 
facility of the underlying operating system. Thus the locks held on a file 
should be visible to all programs that have access to the file, regardless of 
the language in which those programs are written.”

Therefore I assume “file-lock” should work also cross VMs or is that assumption 
not correct?

Konrad

> On 21. Jun 2022, at 11:57, mfriedenha...@gmx.de wrote:
> 
> Hi Konrad,
> 
> citing the linked web site: "Local named locks are only suited within one JVM 
> with a multithreaded build. Sharing a local repository between multiple Maven 
> processes (i.e., on a busy CI server) requires a distributed named lock!"
> 
> Best Regards 
> Mirko Friedenhagen
> — 
> Sent from my mobile
> 
> Am 21.06.22 um 10:20 schrieb Konrad Windszus
> 
>> Thanks for that suggestion. I know about that workaround. But to speed up 
>> builds and to reduce disk space usage I would really like to use a shared 
>> repo.
>> 
>> I was wondering if there is any experience with the simple "file-lock” [1]. 
>> That has the advantage that it doesn’t need additional libraries (IIUC). 
>> Configuration should be as easy as setting 
>> “aether.syncContext.named.factory” to “file-lock” [2]. Unfortunately even 
>> Maven 3.8.6 still ships with Resolver 1.6.3 [3] and it seems the suggested 
>> branch https://github.com/apache/maven/commits/maven-3.8.x-resolver-1.7.x is 
>> a bit outdated now…
>> 
>> Konrad
>> 
>> [1] - 
>> https://github.com/apache/maven-resolver/blob/2af7bff2a5238bf2597cd7a46b60a12779ee31a3/maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/providers/FileLockNamedLockFactory.java
>> [2] - https://maven.apache.org/resolver/configuration.html
>> [3] - https://maven.apache.org/components/resolver/maven-3.8.x.html
>> 
>> 
>>> On 21. Jun 2022, at 10:01, Lasse Lindqvist  
>>> wrote:
>>> 
>>> Hi. If you want to have pipeline build safely, you also have an
>>> alternative. With the withMaven clause (Pipeline Maven Integration Plugin)
>>> you can use something like
>>> 
>>> 
>>> 
>>> *withMaven(maven: 'Maven123', mavenLocalRepo:
>>> '$WORKSPACE/../../.m2/$EXECUTOR_NUMBER/repository') { // Run my Maven
>>> commands here*
>>> * }*
>>> It will use the workspace folder, travel out of it to a parent location and
>>> make a sibling .m2 folder and unique subfolder there based on the executor
>>> number. This way the folders used are executor specific and there will be
>>> no concurrency problems. The downside is that it will use more disk space
>>> because many artifacts are stored multiple times.
>>> 
>>> ti 21. kesäk. 2022 klo 10.51 Konrad Windszus (k...@apache.org) kirjoitti:
>>> 
>>>> Hi,
>>>> By default Jenkins uses a global Maven repository which is accessed in
>>>> parallel by multiple jobs running in dedicated VMs. To prevent race
>>>> conditions one should probably configure one of the distributed named locks
>>>> outlined in
>>>> https://maven.apache.org/resolver/maven-resolver-named-locks/index.html <
>>>> https://maven.apache.org/resolver/maven-resolver-named-locks/index.html>.
>>>> Is there any recommendation which one to pick and also some concrete hints
>>>> how to set that up with Jenkins (Pipelines, leveraging
>>>> https://www.jenkins.io/doc/pipeline/steps/pipeline-maven/ <
>>>> https://www.jenkins.io/doc/pipeline/steps/pipeline-maven/>)
>>>> 
>>>> Is ASF Jenkins using named locks already?
>>>> Thanks for any pointers
>>>> 
>>>> Konrad
>>>> 
>>>> 
>> 
>> 
>> -
>> 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

Re: Named Lock implementation for Maven with Jenkins

[Konrad Windszus]

Thanks for that suggestion. I know about that workaround. But to speed up 
builds and to reduce disk space usage I would really like to use a shared repo.

I was wondering if there is any experience with the simple "file-lock” [1]. 
That has the advantage that it doesn’t need additional libraries (IIUC). 
Configuration should be as easy as setting “aether.syncContext.named.factory” 
to “file-lock” [2]. Unfortunately even Maven 3.8.6 still ships with Resolver 
1.6.3 [3] and it seems the suggested branch 
https://github.com/apache/maven/commits/maven-3.8.x-resolver-1.7.x is a bit 
outdated now…

Konrad

[1] - 
https://github.com/apache/maven-resolver/blob/2af7bff2a5238bf2597cd7a46b60a12779ee31a3/maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/providers/FileLockNamedLockFactory.java
[2] - https://maven.apache.org/resolver/configuration.html
[3] - https://maven.apache.org/components/resolver/maven-3.8.x.html


> On 21. Jun 2022, at 10:01, Lasse Lindqvist  
> wrote:
> 
> Hi. If you want to have pipeline build safely, you also have an
> alternative. With the withMaven clause (Pipeline Maven Integration Plugin)
> you can use something like
> 
> 
> 
> *withMaven(maven: 'Maven123', mavenLocalRepo:
> '$WORKSPACE/../../.m2/$EXECUTOR_NUMBER/repository') { // Run my Maven
> commands here*
> * }*
> It will use the workspace folder, travel out of it to a parent location and
> make a sibling .m2 folder and unique subfolder there based on the executor
> number. This way the folders used are executor specific and there will be
> no concurrency problems. The downside is that it will use more disk space
> because many artifacts are stored multiple times.
> 
> ti 21. kesäk. 2022 klo 10.51 Konrad Windszus (k...@apache.org) kirjoitti:
> 
>> Hi,
>> By default Jenkins uses a global Maven repository which is accessed in
>> parallel by multiple jobs running in dedicated VMs. To prevent race
>> conditions one should probably configure one of the distributed named locks
>> outlined in
>> https://maven.apache.org/resolver/maven-resolver-named-locks/index.html <
>> https://maven.apache.org/resolver/maven-resolver-named-locks/index.html>.
>> Is there any recommendation which one to pick and also some concrete hints
>> how to set that up with Jenkins (Pipelines, leveraging
>> https://www.jenkins.io/doc/pipeline/steps/pipeline-maven/ <
>> https://www.jenkins.io/doc/pipeline/steps/pipeline-maven/>)
>> 
>> Is ASF Jenkins using named locks already?
>> Thanks for any pointers
>> 
>> Konrad
>> 
>> 


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

Named Lock implementation for Maven with Jenkins

[Konrad Windszus]

Hi,
By default Jenkins uses a global Maven repository which is accessed in parallel 
by multiple jobs running in dedicated VMs. To prevent race conditions one 
should probably configure one of the distributed named locks outlined in 
https://maven.apache.org/resolver/maven-resolver-named-locks/index.html 
.
Is there any recommendation which one to pick and also some concrete hints how 
to set that up with Jenkins (Pipelines, leveraging 
https://www.jenkins.io/doc/pipeline/steps/pipeline-maven/ 
)

Is ASF Jenkins using named locks already?
Thanks for any pointers

Konrad

Re: [ANN] Versions Maven Plugin 2.9.0 Released

[Konrad Windszus]

Hi,
first of all thanks a lot for the release.
Unfortunately, I also experienced display-plugin-updates hanging and reported 
this in https://github.com/mojohaus/versions-maven-plugin/issues/538 
.
Hopefully this regression can be fixed soon.
Konrad

> On 21. Jan 2022, at 12:28, Delany  wrote:
> 
> Hi. I still can't display plugin updates with the latest version of the
> plugin (2.9.0)
> 
> `./mvnw -N versions:display-plugin-updates -DgenerateBackupPoms=false -X`
> 
> In the output I see
> 
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository).
> 
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> snapshots (http://snapshots.maven.codehaus.org/maven2).
> 
> [DEBUG] Using mirror presto-central (
> http://presto:8081/repository/maven-central/) for central (
> http://repo1.maven.org/maven2).
> 
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> apache.snapshots (http://people.apache.org/maven-snapshot-repository).
> 
> Presto is mine, but what are these other repositories?
> 
> And further down
> 
> [DEBUG] super-pom version map
> 
> 
>org.apache.maven.plugins:maven-clean-plugin:2.5
> 
> 
>org.apache.maven.plugins:maven-install-plugin:2.4
> 
> 
>org.apache.maven.plugins:maven-deploy-plugin:2.7
> 
> 
>org.apache.maven.plugins:maven-site-plugin:3.3
> 
> 
>org.apache.maven.plugins:maven-antrun-plugin:1.3
> 
> 
>org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5
> 
> 
>org.apache.maven.plugins:maven-dependency-plugin:2.8
> 
> 
>org.apache.maven.plugins:maven-release-plugin:2.5.3
> 
> 
>org.apache.maven.plugins:maven-source-plugin:null
> 
> 
>org.apache.maven.plugins:maven-javadoc-plugin:null
> 
> 
> [DEBUG] parent version map
> 
> 
> [DEBUG] aggregate version map
> 
> 
>org.apache.maven.plugins:maven-clean-plugin:2.5
> 
> 
>org.apache.maven.plugins:maven-release-plugin:2.5.3
> 
> 
>org.apache.maven.plugins:maven-install-plugin:2.4
> 
> 
>org.apache.maven.plugins:maven-dependency-plugin:2.8
> 
> 
>org.apache.maven.plugins:maven-site-plugin:3.3
> 
> 
>org.apache.maven.plugins:maven-source-plugin:null
> 
> 
>org.apache.maven.plugins:maven-javadoc-plugin:null
> 
> 
>org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5
> 
> 
>org.apache.maven.plugins:maven-deploy-plugin:2.7
> 
> 
>org.apache.maven.plugins:maven-antrun-plugin:1.3
> 
> 
> [DEBUG] final aggregate version map
> 
> 
>org.apache.maven.plugins:maven-release-plugin:2.5.3
> 
> 
>org.apache.maven.plugins:maven-javadoc-plugin:null
> 
> at which point it hangs using all of a CPU core and no network. What's up
> here?
> 
> Thanks,
> Delany
> 
> 
> On Fri, 21 Jan 2022 at 12:05, Stefan Seifert
>  wrote:
> 
>> Hi,
>> 
>> The Mojo team is pleased to announce the release of the Versions Maven
>> Plugin version 2.9.0.
>> 
>> The Versions Plugin is used when you want to manage the versions of
>> artifacts in a project's POM.
>> 
>> https://www.mojohaus.org/versions-maven-plugin/
>> 
>> To get this update, simply specify the version in your project's plugin
>> configuration:
>> 
>> 
>>  org.codehaus.mojo
>>  versions-maven-plugin
>>  2.9.0
>> 
>> 
>> Release Notes
>> 
>> https://github.com/mojohaus/versions-maven-plugin/releases/tag/versions-maven-plugin-2.9.0
>> 
>> Enjoy,
>> 
>> The Mojo team.
>> 
>> stefan
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 

Re: [maven-gpg-plugin] Unable to sign artifacts with SHA-256 or higher

[Konrad Windszus]

Look at https://issues.apache.org/jira/browse/MPOM-244 
 which should solve this for 
ASF projects.
Konrad

> On 27. May 2021, at 13:29, Janardhan  wrote:
> 
> Thank you, for the generous response.
> 
> The file hashes are created by maven-resolver, which supports SHA-512 since
>> version 1.5.0 ( https://issues.apache.org/jira/browse/MRESOLVER-56 ).
>> If I remember correctly maven-resolver 1.5+ is included since Maven 3.8.1.
>> So you would have to update your Maven to 3.8.1 and `
>> -Daether.checksums.algorithms=SHA-512 ` should work then.
> 
> 
> This works like a charm Frederik.
> 
> The complete command I have used is
> 
> ```sh
> mvn -P'distribution,rat' deploy -Daether.checksums.algorithms=SHA-512
> ```
> 
> This is not signing, this is just a checksum for transport bitrot.
> 
> 
> Thanks Michael for clarification.
> 
> I think this usage can be documented (explicitly). What do you think?
> I am open to giving a PR since all the apache projects use this
> functionality. :)
> 
> Regards,
> Janardhan
> 
> 
> On Thu, May 27, 2021 at 1:27 PM Michael Osipov  wrote:
> 
>> Am 2021-05-26 um 09:14 schrieb Janardhan:
>>> Hi Maven team,
>>> 
>>> TL;DR: Can we sign (SHA-512) artifacts with gpg plugin and how?. Thanks.
>> 
>> This is not signing, this is just a checksum for transport bitrot.
>> If you need SHA-2 hashes use Resolver's new property for this.
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 

Re: Release of maven-gpg-plugin

[Konrad Windszus]

Thanks a lot.

> On 5. May 2021, at 18:35, Hervé BOUTEMY  wrote:
> 
> ok, I'll try againt to do a release: I hope users tested during that year, so 
> I won't have to cancel the vote again...
> 
> Regards,
> 
> Hervé
> 
> Le mercredi 5 mai 2021, 15:02:10 CEST Konrad Windszus a écrit :
>> Hi,
>> the current release 1.6 is from 2015 and I am suffering from
>> https://issues.apache.org/jira/browse/MGPG-66
>> <https://issues.apache.org/jira/browse/MGPG-66> which has been fixed in
>> MGPG-66. Currently there are no open issues for the upcoming release 3.0.1
>> (https://issues.apache.org/jira/projects/MGPG/versions/12348086
>> <https://issues.apache.org/jira/projects/MGPG/versions/12348086>).
>> 
>> The last release attempt 3.0 has been cancelled last April due to
>> https://issues.apache.org/jira/browse/MGPG-78
>> <https://issues.apache.org/jira/browse/MGPG-78> (fixed meanwhile) and there
>> has been no further release candidate. More than one year later it would be
>> great to see a new release.
>> 
>> Thanks in advance,
>> Konrad
> 
> 
> 
> 
> 
> -
> 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

Release of maven-gpg-plugin

[Konrad Windszus]

Hi,
the current release 1.6 is from 2015 and I am suffering from 
https://issues.apache.org/jira/browse/MGPG-66 
 which has been fixed in MGPG-66.
Currently there are no open issues for the upcoming release 3.0.1 
(https://issues.apache.org/jira/projects/MGPG/versions/12348086 
).

The last release attempt 3.0 has been cancelled last April due to 
https://issues.apache.org/jira/browse/MGPG-78 
 (fixed meanwhile) and there has 
been no further release candidate.
More than one year later it would be great to see a new release. 

Thanks in advance,
Konrad

New release of release plugin

[Konrad Windszus]

Hi,
as the last release of the m-release-plugin (3.0.0-M2) failed due to 
https://issues.apache.org/jira/browse/MRELEASE-1042 
  and a PR has been 
provided with a fix for quite some time now 
(https://github.com/apache/maven-release/pull/56 
) without any review I am 
wondering if a new 3.0.0-M2 or M3 can soon be released (after review of 
https://github.com/apache/maven-release/pull/56 
 of course)
A lot of relevant issues have been fixed compared to 3.0.0-M1 
(https://issues.apache.org/jira/projects/MRELEASE/versions/12348049 
) so it 
would be great to have a new release soon.

TIA
Konrad

SHA512/256 checksum generation not support though Maven Plugins

[Konrad Windszus]

Hi,
I am a bit confused which Maven Plugin/Module is supposed to calculate 
checksums.

With https://issues.apache.org/jira/browse/MINSTALL-143 and 
https://issues.apache.org/jira/browse/MDEPLOY-231 the checksum calculation is 
now being performed in maven-artifact-transfer 
(https://github.com/apache/maven-artifact-transfer/blob/d4df3387215336eb52358f054e742ad44ad9e88f/src/main/java/org/apache/maven/shared/transfer/project/deploy/internal/DefaultProjectDeployer.java#L130)
 but only for MD5 and SHA1. Currently there is no way to disable that 
generation.

That leads to the fact that although SHA512/256 support has been added to Nexus 
in https://issues.sonatype.org/browse/NEXUS-21802 recently one cannot correctly 
create/deploy those checksums with Maven standard plugins due to 
https://issues.apache.org/jira/browse/MSHARED-704 and 
https://issues.apache.org/jira/browse/MDEPLOY-271.

Which Maven part should be responsible for creating those checksums in the 
future? Is it 

a) maven-artifact-transfer or rather 
b) maven-resolver 
(https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultDeployer.java#L80)
 or is it a 
c) completely separate plugin?

Currently none of those options are viable though as a) does not support 
generating SHA256/512 yes (https://issues.apache.org/jira/browse/MSHARED-704),  
nor does maven-resolver support creating those checksum (couldn't find an issue 
for that though). c) cannot be used because one cannot currently prevent 
SHA1/MD5 from being generated even for attached checksum artifacts in 
(https://issues.apache.org/jira/browse/MDEPLOY-271), so you always end up with 
default SHA1/MD5 even for SHA512/256.


As Gradle 5 already supports generating SHA512/256 checksum for artifacts 
uploaded to Maven repo, I think native Maven plugins should support that soon 
as well.
Or maybe I just missed how to do it properly? Any pointer are highly 
appreciated 


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

Distribution of buildinfo together with artifacts to Maven Central

[Konrad Windszus]

Hi,
the buildinfo file (generated by 
https://github.com/apache/maven-studies/tree/maven-buildinfo-plugin 
) is 
useful to check reproducability.
Is it supposed to be uploaded to Maven Central along with the artifact (with 
which classifier?) Or is that information deemed redundant and everyone should 
generate that file by herself/himself in case of executing a reproducing build?

Thanks in advance for your input,
Konrad

Maven Project Info Reports Plugin 3.0.2

[Konrad Windszus]

Hi, 
Unfortunately release 3.0.1 never got published due to a failed vote in August 
last year: 
https://lists.apache.org/list.html?d...@maven.apache.org:lte=12M:%5BVOTE%5D%20Release%20Maven%20Project%20Info%20Reports%20Plugin%20version%203.0.1
 


Still a lot of fixes are resolved in this version: 
https://issues.apache.org/jira/projects/MPIR/versions/12344828 

Any chance to get a 3.0.2 soon?

To me it is not really clear what is missing, because the issue reported in 
https://lists.apache.org/thread.html/c695a357db250df6d4f574661df8efd8cf16f8839f2213cfdc74%40%3Cdev.maven.apache.org%3E
 

 never made it to a JIRA ticket.
Only there is https://issues.apache.org/jira/browse/MPIR-384 
 but it is tagged for 3.1.0, so 
what is missing for a 3.0.2?

Thanks in advance,
Konrad

Re: versioning by hashes to speedup multi-module build (a'la nix package manager)

[Konrad Windszus]

Hi,
just look at http://maven.apache.org/maven-ci-friendly.html.
Konrad


> Am 01.02.2020 um 16:08 schrieb Anton Vodonosov :
> 
> Hello.
> 
> In order to speed up the build of a big multi-module project,
> I'd like to reuse the artifacts of modules that haven't changed.
> Manual versioning is tedious and error-prone.
> 
> Is it possible to automatically assign versions so that
> versions only change if module sources or dependencies change?
> In result, only those modules will be recompiled and retested,
> and all other modules will be reused from artifact repository.
> 
> For example, this could be done if versions are computed as
> hash-of( hash-of(module sources) + hashes of all dependencies).
> 
> In this approach, every change in code will modify such
> hash-based version of all dependent modules automatically.
> 
> This would be similar to Nix package manager.
> 
> How such things (has based or to do that in maven?
> 
> Best regards,
> - Anton  
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 

Re: Release Maven Doxia Plugin 1.9.1?

[Konrad Windszus]

Ping, any update?

Maybe there is a workaround to make md code statements work, but I currently 
fail to see it, therefore a release to fix this regression would be highly 
appreciated.

Konrad

> On 20. Dec 2019, at 12:03, Michael Osipov  wrote:
> 
> Am 2019-12-20 um 11:52 schrieb Konrad Windszus:
>> Hi,
>> is a bugfix release of Doxia planned soon which contains 
>> https://issues.apache.org/jira/browse/DOXIA-597? 
>> <https://issues.apache.org/jira/browse/DOXIA-597?>
>> Or is there any other workaround known to get markdown code statements 
>> (`...`) work correctly with the latest maven-site-plugin?
> 
> I won't be able to release anything before Christmas. If someone is faster, 
> so be it.
> 
> -
> 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

Release Maven Doxia Plugin 1.9.1?

[Konrad Windszus]

Hi,
is a bugfix release of Doxia planned soon which contains 
https://issues.apache.org/jira/browse/DOXIA-597? 

Or is there any other workaround known to get markdown code statements (`...`) 
work correctly with the latest maven-site-plugin?

Thanks,
Konrad

Re: [VOTE] Retire Maven OSGi

[Konrad Windszus]

Hi, just for the record:
There is a replacement for most of the classes in bnd: 
https://github.com/bndtools/bnd/blob/9a4d7bcc04c2377641911b517ca8b1915f763a9a/biz.aQute.bndlib/src/aQute/bnd/version/MavenVersion.java

I just replaced the code using maven-osgi with bndlib in Apache Sling : 
https://issues.apache.org/jira/browse/SLING-8656.

Konrad

On 2019/08/23 17:43:53, Tibor Digana  wrote: 
> Hi Dirk,
> 
> This project is not worth a plugin, it is a pure converter of single class.
> In this case it is legal to adopt this code according to the license.
> Anyway the Maven is not the OSGi. The OSGi is not our key API we deliver to
> our customers.
> We have to save our energy on what makes Maven The Maven.
> 
> Cheers
> Tibor17
> 
> On Fri, Aug 23, 2019 at 5:21 PM Dirk Mahler 
> wrote:
> 
> > Hi,
> >
> > I'm not using it but just for curiosity I checked on Maven Central if
> > some artifacts have been pushed there recently that declare a dependency
> > to this artifact (maven-osgi):
> >
> > "0.2.0" "org.glassfish.hk2:consolidatedbundle-maven-plugin:pom:2.6.0"
> > "2019-07-31T22:22:29Z"
> > "0.2.0" "org.glassfish.hk2:osgiversion-maven-plugin:pom:2.6.0"
> > "2019-07-31T22:21:55Z"
> > "0.2.0" "org.apache.sling:slingstart-maven-plugin:pom:1.8.4"
> > "2019-06-13T11:29:18Z"
> > "0.2.0" "org.apache.sling:slingfeature-maven-plugin:pom:1.0.4"
> > "2019-06-13T09:52:03Z"
> > ...
> >
> > Hope it helps for voting.
> >
> > Cheers
> >
> > Dirk
> >
> > -- Originalnachricht --
> > Von: "Robert Scholte" 
> > An: "Apache Maven Dev" 
> > Cc: "Apache Maven Users" 
> > Gesendet: 23.08.2019 15:17:23
> > Betreff: [VOTE] Retire Maven OSGi
> >
> > >Hi,
> > >
> > >The Apache Maven project consist of about 90 (sub)projects. Due to the
> > small number of volunteers and the huge amount of code to maintain we're
> > missing enough space to make real progress on all these projects,
> > including our ambitious ideas for the next major version(s) of Maven
> > itself.
> > >To be able to gain more focus we need to criticize the current
> > subprojects  and decide if it is worth maintaining.
> > >
> > >https://maven.apache.org/shared/maven-osgi/ describes the main purpose
> > in  one line: Library for Maven-OSGi integration.
> > >There have been only 2 releases: 0.1.0 in July 2007 and 0.2.0 in
> > December  2007 and just one open issue by Stuart McCulloch regarding an
> > unclosed jar.
> > >It is unclear to me if this library is still used. The library is based
> > on  just 3 files: interface, default implementation and dedicated exception.
> > >Either the library is complete or never used anymore. In both cases I
> > see  no real reason to maintain it.
> > >
> > >I therefore propose that we retire the maven-osgi library.
> > >
> > >I don't think it makes sense to do a final release. Instead we should
> > update the documentation and freeze the codebase.
> > >
> > >The process for retiring a plugin is described here:
> > >https://maven.apache.org/developers/retirement-plan-plugins.html  [
> > https://maven.apache.org/developers/retirement-plan-plugins.html]
> > >
> > >The vote is open for 72 hours.
> > >[ ] +1 Yes, it's about time
> > >[ ] -1 No, because...
> > >
> > >-
> > >To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> 

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

Re: Error with mvn site:stage-deploy

[Konrad Windszus]

This seems to be related to the merged PR from 
https://github.com/apache/maven-wagon/pull/51/files 
.
Not sure why the error happens though...

> On 8. Jan 2019, at 17:27, Enrico Olivelli  wrote:
> 
> Hi,
> I have this error with Maven 3.6.0 and maven-site-plugin 3.7.1 and
> wagon-webdav-jackrabbit 3.3.1
> 
> java.lang.NoSuchMethodError:
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.getBufferCapacityForTransfer(J)I
>at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.access$000
> (AbstractHttpClientWagon.java:112)
>at 
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon$RequestEntityImplementation.writeTo
> (AbstractHttpClientWagon.java:185)
>at org.apache.http.impl.DefaultBHttpClientConnection.sendRequestEntity
> (DefaultBHttpClientConnection.java:156)
> 
> 
> Is there anyworkaround ?
> I am trying to force all of the dependencies in the site plugin
> 
> 
>org.apache.maven.plugins
>maven-site-plugin
>3.7.1
>
>
>  org.apache.maven.wagon
>  wagon-http
>  3.3.1
>
>
>  org.apache.maven.wagon
>  wagon
>  3.3.1
>  pom
>
>
>  org.apache.maven.wagon
>  wagon-http-shared
>  3.3.1
>
>
>  org.apache.maven.wagon
>  wagon-webdav-jackrabbit
>  3.3.1
>
>  
> 
> But no result...
> 
> Thanks
> 
> Enrico
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 

How to validate SHA512/SHA256 checksums during a release of an ASF project

[Konrad Windszus]

Hi,
I am committer of the ASF project Sling which heavily relies on Maven. We 
obviously have to follow the ASF policy as well to distribute SHA512 or SHA256 
checksums along with our source releases. 
While the first support for this has been made by 
https://issues.apache.org/jira/browse/MPOM-205 
 (thanks a lot for that) I am 
still not supposed to upload the checksums to the ASF Staging Repo (Nexus) 
because Nexus will not detect those as checksums and will generate sha1 and md5 
files for my custom checksum as well.

You guys are basically saying that the sha512 checksum is not supposed to be 
uploaded to the Staging repo (also in 
https://issues.apache.org/jira/browse/MINSTALL-138 
), but then I wonder how to 
validate a release based on the staging repository? At least the checksum you 
can no longer (half-automatically) validate. The only way to validate would be 
to include the checksum as text in the vote email and everyone verifying would 
need to check against his own build. That is a lot of overhead compared to 
previously just automatically checking the generated SHA1/MD5 checksums.

Also we often have the situation that the release managers are not PMC members 
and therefore need to ask other people to push to dist. These steps were fairly 
easy in the past as it was only required to download the staged repo and push 
that to the according SVN repo. But now it would rather require to check 
out/clone the tagged release from the SCM and build by your own, which can be 
pretty time consuming and also makes the staging partly useless.

How do you guys at Maven live the ASF release process with SHA512 checksums? 
The guidelines are 
https://maven.apache.org/developers/release/maven-project-release-procedure.html
 

 are a littlebit fuzzy in that regard.
Thanks in advance for any input,

Konrad

How to enforce running my Maven Plugin with a certain Java version

[Konrad Windszus]

How can I enforce that my custom Maven Plugin (or only a certain Mojo within) 
is only executed with at least a certain Java version (i.e. Java8 due to the 
use of class files being only compatible with Java8+). The prerequisites 
section which seems like the natural way to define that only allows me to 
require a minimum Maven version 
(http://maven.apache.org/ref/3.5.0/maven-model/maven.html#class_prerequisites). 
which is not what I want here.

The failure message is rather unintuitive whenever my Maven Mojo is used in a 
project with an incompatible Java version (which cannot read my Mojos class 
files).

I know that in all Projects using the Maven Plugin the maven-enforcer-plugin 
could theoretically be used, but then each consuming projects needs to manually 
figure out the minimum java version based on the documentation of all Maven 
Plugins. Isn't there a better/more automated way, which let's Maven check this 
requirement prior to executing any Mojos from a plugin?

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

Re: Replacement for org.apache.maven.monitor.event.EventDispatcher?

[Konrad Windszus]

Just to conclude here: I found that the AbstractMavenLifecycleParticipant is 
just enough, since that provides a callback method at the end of the build 
(thanks to https://issues.apache.org/jira/browse/MNG-5389 being implemented).
That can be leveraged from build extensions and does not require a core 
extension.
Konrad

> On 25 Aug 2016, at 15:45, Konrad Windszus <konra...@gmx.de> wrote:
> 
> That is only accessible when being placed in maven.ext.class.path. I am 
> looking for something which can be registered only through a pom.xml.
> Registering such an extension via the extensions section of the pom.xml does 
> not work though.
> Konrad
> 
>> On 25 Aug 2016, at 10:44, Robert Scholte <rfscho...@apache.org> wrote:
>> 
>> Hi Konrad,
>> 
>> Have a look at 
>> https://maven.apache.org/ref/3.3.9/maven-core/apidocs/org/apache/maven/eventspy/EventSpy.html
>> 
>> thanks,
>> Robert
>> 
>> On Fri, 19 Aug 2016 17:33:15 +0200, Konrad Windszus <konra...@gmx.de> wrote:
>> 
>>> The EventDispatcher support was completely removed with the commit 
>>> https://github.com/apache/maven/commit/505423e666b9a8814e1c1aa5d50f4e73b8d710f4
>>>  for Maven 3.0.
>>> Currently I instead use a JVM Shutdown Hook to perform some tasks at the 
>>> end of the build which is not recommended either for obvious reasons (see 
>>> https://maven.apache.org/plugin-developers/common-bugs.html#Using_Shutdown_Hooks).
>>> 
>>> What is the recommended way on how to perform some tasks at the end of the 
>>> reactor build?
>>> Thanks,
>>> Konrad
>>> 
>>> 
>>> 
>>> -
>>> 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
> 


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

Re: Replacement for org.apache.maven.monitor.event.EventDispatcher?

[Konrad Windszus]

That is only accessible when being placed in maven.ext.class.path. I am looking 
for something which can be registered only through a pom.xml.
Registering such an extension via the extensions section of the pom.xml does 
not work though.
Konrad

> On 25 Aug 2016, at 10:44, Robert Scholte <rfscho...@apache.org> wrote:
> 
> Hi Konrad,
> 
> Have a look at 
> https://maven.apache.org/ref/3.3.9/maven-core/apidocs/org/apache/maven/eventspy/EventSpy.html
> 
> thanks,
> Robert
> 
> On Fri, 19 Aug 2016 17:33:15 +0200, Konrad Windszus <konra...@gmx.de> wrote:
> 
>> The EventDispatcher support was completely removed with the commit 
>> https://github.com/apache/maven/commit/505423e666b9a8814e1c1aa5d50f4e73b8d710f4
>>  for Maven 3.0.
>> Currently I instead use a JVM Shutdown Hook to perform some tasks at the end 
>> of the build which is not recommended either for obvious reasons (see 
>> https://maven.apache.org/plugin-developers/common-bugs.html#Using_Shutdown_Hooks).
>> 
>> What is the recommended way on how to perform some tasks at the end of the 
>> reactor build?
>> Thanks,
>> Konrad
>> 
>> 
>> 
>> -
>> 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

Re: Replacement for org.apache.maven.monitor.event.EventDispatcher?

[Konrad Windszus]

Hi Robert,
thanks, exactly what I was looking for. Can you add that link to the 
deprecation notice of 
https://maven.apache.org/ref/3.3.9/maven-core/apidocs/org/apache/maven/monitor/event/EventDispatcher.html
 
<https://maven.apache.org/ref/3.3.9/maven-core/apidocs/org/apache/maven/monitor/event/EventDispatcher.html>
 and 
https://maven.apache.org/ref/3.3.9/maven-core/apidocs/org/apache/maven/execution/MavenSession.html#getEventDispatcher()
 
<https://maven.apache.org/ref/3.3.9/maven-core/apidocs/org/apache/maven/execution/MavenSession.html#getEventDispatcher()>
 and make clearer that since Maven 3.0.0 the latter will always returns null.
Thanks,
Konrad

> On 25 Aug 2016, at 10:44, Robert Scholte <rfscho...@apache.org> wrote:
> 
> Hi Konrad,
> 
> Have a look at 
> https://maven.apache.org/ref/3.3.9/maven-core/apidocs/org/apache/maven/eventspy/EventSpy.html
> 
> thanks,
> Robert
> 
> On Fri, 19 Aug 2016 17:33:15 +0200, Konrad Windszus <konra...@gmx.de> wrote:
> 
>> The EventDispatcher support was completely removed with the commit 
>> https://github.com/apache/maven/commit/505423e666b9a8814e1c1aa5d50f4e73b8d710f4
>>  for Maven 3.0.
>> Currently I instead use a JVM Shutdown Hook to perform some tasks at the end 
>> of the build which is not recommended either for obvious reasons (see 
>> https://maven.apache.org/plugin-developers/common-bugs.html#Using_Shutdown_Hooks).
>> 
>> What is the recommended way on how to perform some tasks at the end of the 
>> reactor build?
>> Thanks,
>> Konrad
>> 
>> 
>> 
>> -
>> 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
> 

Replacement for org.apache.maven.monitor.event.EventDispatcher?

[Konrad Windszus]

The EventDispatcher support was completely removed with the commit 
https://github.com/apache/maven/commit/505423e666b9a8814e1c1aa5d50f4e73b8d710f4 

 for Maven 3.0.
Currently I instead use a JVM Shutdown Hook to perform some tasks at the end of 
the build which is not recommended either for obvious reasons (see 
https://maven.apache.org/plugin-developers/common-bugs.html#Using_Shutdown_Hooks
 
).

What is the recommended way on how to perform some tasks at the end of the 
reactor build?
Thanks,
Konrad

Replacement for org.apache.maven.monitor.event.EventDispatcher?

[Konrad Windszus]

The EventDispatcher support was completely removed with the commit 
https://github.com/apache/maven/commit/505423e666b9a8814e1c1aa5d50f4e73b8d710f4 
for Maven 3.0.
Currently I instead use a JVM Shutdown Hook to perform some tasks at the end of 
the build which is not recommended either for obvious reasons (see 
https://maven.apache.org/plugin-developers/common-bugs.html#Using_Shutdown_Hooks).

What is the recommended way on how to perform some tasks at the end of the 
reactor build?
Thanks,
Konrad



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

Exchange data in memory between different mojo executions in different modules of the same plugin

[Konrad Windszus]

To exchange data between several executions of my mojo I wanted to leverage 
AbstractMojo.getPluginContext(). Unfortunately although the map is being shared 
among multiple executions targeting the same project it is not shared among 
different projects in a multi-module build. 
Which API can I leverage to share data between multiple mojo executions even 
across project borders?

The only way I could get that working was using 
MavenSession.getExecutionProperties(), but that was deprecated a long time ago 
and also that doesn't seem to be thread-safe (i.e. if the modules are built at 
the same time in different threads you run into issues, because multiple 
modules could get a different Properties object.

Any hints onto which object I could bind myself to share arbitrary Java objects 
among all mojo executions?

Maybe there is some existing Plexus Component (which is only instantiated once) 
which I could inject and which allows to write/read arbitrary objects from/to 
it.
Thanks for any help,
Konrad
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org