Re: [ANN] Apache Maven Compiler Plugin 3.13.0 Released

[Mark Derricutt]

Interesting - I just hit:

Execution default-compile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.13.0:compile failed: An
API incompatibility was encountered while executing
org.apache.maven.plugins:maven-compiler-plugin:3.13.0:compile:
java.lang.NoSuchMethodError:
org.codehaus.plexus.compiler.javac.JavacCompiler.buildCompilerArguments(Lorg/codehaus/plexus/compiler/CompilerConfiguration;[Ljava/lang/String;)[Ljava/lang/String;
[ERROR] -
[ERROR] realm =
 plugin>org.apache.maven.plugins:maven-compiler-plugin:3.13.0
[ERROR] strategy =
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] =
file:/Users/amrk/.m2/repository/org/apache/maven/plugins/maven-compiler-plugin/3.13.0/maven-compiler-plugin-3.13.0.jar
[ERROR] urls[1] =
file:/Users/amrk/.m2/repository/org/ow2/asm/asm/9.6/asm-9.6.jar
[ERROR] urls[2] =
file:/Users/amrk/.m2/repository/org/codehaus/plexus/plexus-compiler-javac-errorprone/2.8.6/plexus-compiler-javac-errorprone-2.8.6.jar

on most of my projects.  Using Mvn 3.9.6




-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree


On Tue, Mar 19, 2024 at 7:20 AM Slawomir Jaranowski 
wrote:

> The Apache Maven team is pleased to announce the release of the Apache
> Maven Compiler Plugin, version 3.13.0
>
> The Compiler Plugin is used to compile the sources of your project.
>
> https://maven.apache.org/plugins/maven-compiler-plugin/
>
> You should specify the version in your project's plugin configuration:
>
> 
>   org.apache.maven.plugins
>   maven-compiler-plugin
>   3.13.0
> 
>
> You can download the appropriate sources etc. from the download page:
>
> https://maven.apache.org/plugins/maven-compiler-plugin/download.cgi
>
> Release Notes - Maven Compiler Plugin - Version 3.13.0
>
> ** Bug
> * [MCOMPILER-548] - JDK 21 throws annotations processing warning that
> can not be turned off
>
> ** New Feature
> * [MCOMPILER-582] - Automatic detection of release option for JDK < 9
> * [MCOMPILER-583] - Require Maven 3.6.3
>
> ** Improvement
> * [MCOMPILER-570] - Javadoc: Add link to javac references from JDK17
> * [MCOMPILER-574] - AbstractCompilerMojo::execute should propagate
> exception cause
> * [MCOMPILER-576] - Deprecate parameter "compilerVersion"
> * [MCOMPILER-577] - Rename parameter "forceJavacCompilerUse"
>
> ** Task
> * [MCOMPILER-584] - Refresh page - Using Non-Javac Compilers
> * [MCOMPILER-585] - Refresh plugins versions in ITs
>
> ** Dependency upgrade
> * [MCOMPILER-575] - Bump plexus-compiler to 2.15.0
>
> Enjoy,
> -The Apache Maven team
>

Re: [ANN] Apache Maven 4.0.0-alpha-7 released

[Mark Derricutt]

 On 28/08/2023 at 11:42:48 AM, Guillaume Nodet  wrote:

> I haven’t had a chance to look into this yet - but I wondered if anyone
> else had seen anything similar?
>
>
> No.  Can you check if you're using a recent surefire version ?
>

I’m using 3.1.2 here, which AFAIK is the latest.  Along with Junit
Jupiter 5.10.0 - interestingly I just set up a clean room project to check
with and it seemed fine - so there must be some other dependency that’s
confusing things along the way.

If I manage to reproduce it from a clean/example project I’ll update.

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: [ANN] Apache Maven 4.0.0-alpha-7 released

[Mark Derricutt]

 On 29/06/2023 at 3:16:24 PM, Guillaume Nodet  wrote:

> Maven 4.0.0-alpha-7 is available via https://maven.apache.org/download.cgi
>


Interesting - I noticed over the weekend that under 4.0.0-alpha-7 surefire
isn’t picking up any of my Junit 5 tests, but maven 3.9.4 is.

I haven’t had a chance to look into this yet - but I wondered if anyone
else had seen anything similar?


-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: [DISCUSS] Major changed for 4.x

[Mark Derricutt]

 Interesting - I see between alpha-5 and alpha-7 - tiles-maven-pllugin
seems to work again (noticed this building alpha-8-SNAPSHOT).

That’s good to know - will make evaluating the new mixins easier as well.

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree


On 24/08/2023 at 11:41:25 AM, Mark Derricutt  wrote:

> On 23/08/2023 at 9:46:16 PM, Guillaume Nodet  wrote:
>
>> The two ITs for mixins are available at
>>
>> https://github.com/apache/maven-integration-testing/pull/280/commits/13173969007b5e3b307ef5b191ac2d52a23dce6c
>>
>
>
> Nice - that looks like it should work - does that unfold into the
> effective-pom at all?  Look forward to trying it out - might have to go
> build up a SNAPSHOT for myself.
>
> Mark
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>
>

Re: [DISCUSS] Major changed for 4.x

[Mark Derricutt]

 On 23/08/2023 at 9:46:16 PM, Guillaume Nodet  wrote:

> The two ITs for mixins are available at
>
> https://github.com/apache/maven-integration-testing/pull/280/commits/13173969007b5e3b307ef5b191ac2d52a23dce6c
>


Nice - that looks like it should work - does that unfold into the
effective-pom at all?  Look forward to trying it out - might have to go
build up a SNAPSHOT for myself.

Mark

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: [DISCUSS] Major changed for 4.x

[Mark Derricutt]

 Definitely keen on seeing this, or the approach taken - as Maven 4.x
breaks the existing usage of tiles-maven-plugin so having something
supported, that covers the same featureset would be good.

Where in GIthub can I see the IT’s mentioned here?

On 22/08/2023 at 7:32:12 PM, Guillaume Nodet  wrote:

> The third one is the support for POM mixins [7].  That one is still a
> draft.  Two ITs have been written to leverage mixins using GAV or as
> relative paths [8].  This definitely needs some work, but the current state
> definitely shows that it can be implemented and introduced in the next
> alphas.
>


-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Mark Derricutt]

 On 31/05/2023 at 9:21:43 PM, Michael Osipov  wrote:

> even if we are in alpha phase now.
> I bet many people will stick for 3.9.x or even 3.8.x for the years to
> come.


Yep - unless 4.x can introduce some hook for extensions to modify the POM
model before becoming immutable, I don’t see us moving beyond for a long
time (or anyone else now using our tiles-maven-plugin - which I’ve
unfortunately not really had a chance to dive into seeing if/how we could
rework it to support M4).

Mark

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: [VOTE] Change to the voting process

[Mark Derricutt]

On 12 May 2023, at 22:01, Tamás Cservenák wrote:

> Again, my main goal is to stir voters up.
> And if unclear, of course I expect negative votes, but I DO EXPECT votes :D

My vague understanding here - if someone thus wanted to CANCEL the vote, the 
ruling would then still require it to be open for at LEAST 30 days before it 
could be cancelled, and another vote started.

I've not read the full rules for awhile, but does anything preclude concurrent 
open votes?

either way, -1 from me. I'd prefer faster turnarounds.



---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.chaliceofblood.net
http://www.theoryinpractice.net
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven 3.9.2

[Mark Derricutt]

Another +1 from me - does that make it a +2? :)

On 10 May 2023, at 20:40, Tamás Cservenák wrote:

> Mark,
>
> added this commit to release notes
> https://github.com/apache/maven-site/pull/414/commits/d3f0432573f97b6908bbbfbeaf22fd8524e1282c


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.chaliceofblood.net
http://www.theoryinpractice.net
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven 3.9.2

[Mark Derricutt]

On 9 May 2023, at 10:29, Mark Derricutt wrote:

> +1 Non binding - works fine on works OSGi / tiles-maven-plugin project ( 
> sadly, unlike M4 - still need to look into this ).

Actually - I noticed this at the end of my build ( which was still successful ):

[WARNING] Plugin validation issues were detected in 34 plugin(s)
[WARNING]
[WARNING]  * org.apache.maven.plugins:maven-assembly-plugin:3.4.0
[WARNING]  * org.apache.maven.plugins:maven-surefire-plugin:2.20

Looking at the verbose output I see a lot of internal maven plugins that need 
work - I see this is from MNG-7767 (tone down plugin validation report ), but I 
never saw it before in 3.9.1 so wondering when this came in? There doesn't seem 
to be any mention of the report in the 3.9.2 release notes?




---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.chaliceofblood.net
http://www.theoryinpractice.net
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven 3.9.2

[Mark Derricutt]

On 8 May 2023, at 22:40, Tamás Cservenák wrote:

> We solved 12 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12352958


+1 Non binding - works fine on works OSGi / tiles-maven-plugin project ( sadly, 
unlike M4 - still need to look into this ).



---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.chaliceofblood.net
http://www.theoryinpractice.net
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [ANN] Maven Checkstyle Plugin 3.2.2 released

[Mark Derricutt]

On 5 May 2023, at 16:21, Maxim Solodovnik wrote:

> While latest version ATM 10.9.3

Checkstyle 10.x requires Java 9+ which is good enough reason in my mind to not 
update it officially (yet).

You can however update the check style version by adding a `` 
declaration in the plugin.


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.chaliceofblood.net
http://www.theoryinpractice.net
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven 3.9.1

[Mark Derricutt]

+1 for me and $works project, running tiles and my custom resolver mojo.


I do note a new warning:

[INFO] --- build-helper:3.3.0:remove-project-artifact 
(com.smxemail.tiles_com.smxemail.tiles.release_2.2.67__remove-project-artifact-clean)
 @ smx3.mailproducts ---
[WARNING] Parameter 'localRepository' is deprecated core expression; Avoid use 
of ArtifactRepository type. If you need access to local repository, switch to 
'${repositorySystemSession}' expression and get LRM from it instead.

Which I'll report upstream later on for the build-helper plugin.

On 15 Mar 2023, at 23:14, Tamás Cservenák wrote:

> Howdy,
>
> We solved 29 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12352872
>
> There are still couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1888/
>
> Dev dist directory:
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.1/
>
> Source release checksums:
> apache-maven-3.9.1-src.zip sha512:
> 2b1f14d4d5fd4a9759ac2519dd8eb4fbfdec199a9fdc66b7995b606bb5548c4f10f431d02e725f10af4d89d55d575e6d8bc7c2e006bbfbbaa0f6349cfd699f9b
> apache-maven-3.9.1-src.tar.gz sha512:
> 726679381d4660150f88a727e16005cecd0fee6c03748ae8db889cfe88a2da7ac378f0d221bf237953bba3c49542d2bd7233888eb549cf7c10dd4e2deb2a3828
>
> Binary release checksums:
> apache-maven-3.9.1-bin.zip sha512:
> 4ae5a0d17f9e6cbe57640c481f426a9184dfb451c2bb7cc7db324da095f616a14e7c482a79240e5286e241d8cd2805ea1cd9c95e38954101c2fa4088baad9a1a
> apache-maven-3.9.1-bin.tar.gz sha512:
> d3be5956712d1c2cf7a6e4c3a2db1841aa971c6097c7a67f59493a5873ccf8c8b889cf988e4e9801390a2b1ae5a0669de07673acb090a083232dbd3faf82f3e3
>
> Staged site:
> https://maven.apache.org/ref/3-LATEST/
>
> Draft for release notes:
> https://github.com/apache/maven-site/pull/400
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72h
>
> [ ] +1
> [ ] +0
> [ ] -1


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.chaliceofblood.net
http://www.theoryinpractice.net
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: CVEs in maven-compat via toolchains

[Mark Derricutt]

On 15 Feb 2023, at 8:30, Tamás Cservenák wrote:


This artifact ceased to exist (well, to be produced) since.


Sweet - dropped the dependency and all good - and re-released.

Cheers,
Mark


---
"The ease with which a change can be implemented has no relevance at all 
to whether it is the right change for the (Java) Platform for all time." 
 Mark Reinhold.


Mark Derricutt
http://www.chaliceofblood.net
http://www.theoryinpractice.net
http://twitter.com/talios
http://facebook.com/mderricutt

Re: CVEs in maven-compat via toolchains

[Mark Derricutt]

On 15 Feb 2023, at 1:19, Elliotte Rusty Harold wrote:


That's extremely old and seems unmaintained and never released. You
probably want the maven-toolchains-plugin


Isn't that for USING toolchains - not adding tool chain support to a 
plugin? Will do some more digging.




---
"The ease with which a change can be implemented has no relevance at all 
to whether it is the right change for the (Java) Platform for all time." 
 Mark Reinhold.


Mark Derricutt
http://www.chaliceofblood.net
http://www.theoryinpractice.net
http://twitter.com/talios
http://facebook.com/mderricutt

CVEs in maven-compat via toolchains

[Mark Derricutt]

Hey all,

I was alerted the other day about a security issue with my 
clojure-maven-plugin apparently pulling in log4j 1.2, but using the 
dependency:tree plugin showed nothing.


Seems this is due to dependencies being overridden by newer maven 
versions, anyway - I use toolchains in the plugin and have this 
dependency tree:


```
[INFO] +- org.apache.maven:maven-toolchain:jar:3.0-alpha-2:compile
[INFO] |  +- (org.apache.maven:maven-core:jar:3.0-alpha-2:compile - 
omitted for conflict with 3.9.0)

[INFO] |  \- org.apache.maven:maven-compat:jar:3.0-alpha-2:compile
[INFO] | +- (org.apache.maven:maven-model:jar:3.0-alpha-2:compile - 
omitted for conflict with 3.9.0)
[INFO] | +- 
(org.codehaus.plexus:plexus-container-default:jar:1.0-beta-3.0.5:compile 
- omitted for duplicate)
[INFO] | +- 
(org.codehaus.plexus:plexus-component-annotations:jar:1.0-beta-3.0.5:compile 
- omitted for conflict with 1.5.5)

```

This trips up with:

```
[ERROR]   org.apache.maven:maven-compat:jar:3.0-alpha-2:compile; 
https://ossindex.sonatype.org/component/pkg:maven/org.apache.maven/maven-compat@3.0-alpha-2?utm_source=ossindex-client_medium=integration_content=1.8.1
[ERROR] * [CVE-2021-26291] CWE-346: Origin Validation Error (9.1); 
https://ossindex.sonatype.org/vulnerability/CVE-2021-26291?component-type=maven=org.apache.maven%2Fmaven-compat_source=ossindex-client_medium=integration_content=1.8.1

```

There doesn't appear to be a newer version of `maven-toolchain` at all - 
or is there and I'm just looking in the wrong place these days?


Cheers,
Mark






---
"The ease with which a change can be implemented has no relevance at all 
to whether it is the right change for the (Java) Platform for all time." 
 Mark Reinhold.


Mark Derricutt
http://www.chaliceofblood.net
http://www.theoryinpractice.net
http://twitter.com/talios
http://facebook.com/mderricutt

Re: [VOTE] Release Apache Maven 3.9.0

[Mark Derricutt]

+1 non-binding here.

After updating my internal plugin ( thanks Tamas ) I'm down with this 
release.



On 4 Feb 2023, at 20:20, Sylwester Lachiewicz wrote:


+1


---
"The ease with which a change can be implemented has no relevance at all 
to whether it is the right change for the (Java) Platform for all time." 
 Mark Reinhold.


Mark Derricutt
http://www.chaliceofblood.net
http://www.theoryinpractice.net
http://twitter.com/talios
http://facebook.com/mderricutt

Re: Maven 3.9,0 plan

[Mark Derricutt]

ile:/Users/amrk/.m2/repository/org/jdom/jdom2/2.0.6.1/jdom2-2.0.6.1.jar

Number of foreign imports: 1
import: Entry[import  from realm 
ClassRealm[project>com.smxemail:rangeresolver-maven-plugin:1.1.59-SNAPSHOT, 
parent: ClassRealm[maven.api, parent: null]]]

```

Mark






On 24 Jan 2023, at 21:22, Tamás Cservenák wrote:


Mark,

Can you provide more information about this error?

I understand if this plugin is internal (not OSS), but can you provide 
me


the POM of it, or at least the dependencies snippet related to Maven 
and


resolver?

"A required class is missing" is strange, especially as

BasicRepositoryConnectorFactory is provided by Maven itself?

Thanks

Tamas



---
"The ease with which a change can be implemented has no relevance at all 
to whether it is the right change for the (Java) Platform for all time." 
 Mark Reinhold.


Mark Derricutt
http://www.chaliceofblood.net
http://www.theoryinpractice.net
http://twitter.com/talios
http://facebook.com/mderricutt

Re: [VOTE] Release Apache Maven 4.0.0-alpha-4 release

[Mark Derricutt]

ker plugin calling the now 
immutable `setFile` - anyone know if theres an alpha/snapshot build of 
invoker that's compatible?


Mark



---
"The ease with which a change can be implemented has no relevance at all 
to whether it is the right change for the (Java) Platform for all time." 
 Mark Reinhold.


Mark Derricutt
http://www.chaliceofblood.net
http://www.theoryinpractice.net
http://twitter.com/talios
http://facebook.com/mderricutt

Re: Maven 3.9,0 plan

[Mark Derricutt]

On 24 Jan 2023, at 21:22, Tamás Cservenák wrote:


Mark,

Can you provide more information about this error?
I understand if this plugin is internal (not OSS), but can you provide 
me
the POM of it, or at least the dependencies snippet related to Maven 
and

resolver?
"A required class is missing" is strange, especially as
BasicRepositoryConnectorFactory is provided by Maven itself?

Thanks
Tamas


Have been meaning to get this open sourced for ages, I keep thinking "I 
should really clean up the code to be more presentable first" and it 
always goes on the backbench :)


Ironically - pulling out these dependencies, I think I see my problem - 
usage of this plugin rewrites dependencies to ban transitives, and lock 
ranges to `[]` - and well, the plugin is used on itself - so we're 
locking the dependency range of resolver.


I'll update it to relax the ranges in the plugin and see if that works.


```

  org.apache.maven
  maven-artifact
  [3.8.5]
  

  *
  *

  


  org.apache.maven
  maven-resolver-provider
  [3.8.5]
  


  org.apache.maven.resolver
  maven-resolver-api
  [1.7.3]
  


  org.apache.maven.resolver
  maven-resolver-connector-basic
  [1.7.3]
  


  org.apache.maven.resolver
  maven-resolver-impl
  [1.7.3]
  


  org.apache.maven.resolver
  maven-resolver-spi
  [1.7.3]
  


  org.apache.maven.resolver
  maven-resolver-transport-file
  [1.7.3]
  


  org.apache.maven.resolver
  maven-resolver-transport-http
  [1.7.3]
  


  org.apache.maven.resolver
  maven-resolver-util
  [1.7.3]
  

```



---
"The ease with which a change can be implemented has no relevance at all 
to whether it is the right change for the (Java) Platform for all time." 
 Mark Reinhold.


Mark Derricutt
http://www.chaliceofblood.net
http://www.theoryinpractice.net
http://twitter.com/talios
http://facebook.com/mderricutt

Re: Maven 3.9,0 plan

[Mark Derricutt]

On 19 Jan 2023, at 22:02, Tamás Cservenák wrote:


So, please anyone able to, test 3.9.0-SNAPSHOT if you can.



Seems to run fine for my normal projects - but crashes on in my main 
$work project, due to an internal Maven Plugin I have that uses the 
maven resolver - and I've not released a version of that which uses the 
newer dependency so gets:


```
[ERROR] Failed to execute goal 
com.smxemail:rangeresolver-maven-plugin:1.1.58:resolve-deps 
(default-cli) on project smx3.api: Execution default-cli of goal 
com.smxemail:rangeresolver-maven-plugin:1.1.58:resolve-deps failed: A 
required class was missing while executing 
com.smxemail:rangeresolver-maven-plugin:1.1.58:resolve-deps: 
org/eclipse/aether/connector/basic/BasicRepositoryConnectorFactory

[ERROR] -
[ERROR] realm =plugin>com.smxemail:rangeresolver-maven-plugin:1.1.58
[ERROR] strategy = 
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] = 
file:/Users/amrk/.m2/repository/com/smxemail/rangeresolver-maven-plugin/1.1.58/rangeresolver-maven-plugin-1.1.58.jar
[ERROR] urls[1] = 
file:/Users/amrk/.m2/repository/com/smxemail/com.smxemail.rangeresolver/1.1.34/com.smxemail.rangeresolver-1.1.34.jar
[ERROR] urls[2] = 
file:/Users/amrk/.m2/repository/com/google/guava/guava/31.1-jre/guava-31.1-jre.jar
[ERROR] urls[3] = 
file:/Users/amrk/.m2/repository/org/apache/commons/commons-lang3/3.12.0/commons-lang3-3.12.0.jar

```

Likely just requires me to update my plugin, but this will likely break 
other mojos that use aether/resolver.


Being a .0 release (even tho not a major) I think I'm fine with that - 
but it might be something we want to document?






---
"The ease with which a change can be implemented has no relevance at all 
to whether it is the right change for the (Java) Platform for all time." 
 Mark Reinhold.


Mark Derricutt
http://www.chaliceofblood.net
http://www.theoryinpractice.net
http://twitter.com/talios
http://facebook.com/mderricutt

Re: [VOTE] Release Apache Maven version 3.8.7

[Mark Derricutt]

On 25 Dec 2022, at 9:20, Michael Osipov wrote:


Hi,

We solved 19 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12352690


+1 non-binding.


---
"The ease with which a change can be implemented has no relevance at all 
to whether it is the right change for the (Java) Platform for all time." 
 Mark Reinhold.


Mark Derricutt
http://www.chaliceofblood.net
http://www.theoryinpractice.net
http://twitter.com/talios
http://facebook.com/mderricutt

Re: [VOTE] Release Apache Maven 4.0.0-alpha-3

[Mark Derricutt]

ojosExecutionStrategy:   
"org.apache.maven.plugin.MojosExecutionStrategy"
[ERROR] Named:"com.google.inject.name.Named"
[ERROR] PlexusBindingModule:  
"org.eclipse.sisu.plexus.PlexusBindingModule"
[ERROR] RemoteCacheRepository:
"org.apache.maven.buildcache.RemoteCacheRepository"
[ERROR] RemoteCacheRepositoryProvider:
"org.apache.maven.buildcache.RemoteCacheRepositoryProvider"
[ERROR] WireModule:   "org.eclipse.sisu.wire.WireModule"
[ERROR] 
[ERROR] End of classname legend:
[ERROR] : java.util.NoSuchElementException
[ERROR]   role: org.apache.maven.buildcache.RemoteCacheRepository
[ERROR]   roleHint: resolver
[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 verbose output
```








On 13 Dec 2022, at 2:19, Guillaume Nodet wrote:

> https://repository.apache.org/content/repositories/maven-1835


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.chaliceofblood.net
http://www.theoryinpractice.net
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [ANN] Apache Maven Build Cache Extension 1.0.0 Released

[Mark Derricutt]

 Congrats - look forward to trying it out.

I note however the site links to some missing files:

 https://maven.apache.org/extensions/resources/maven-build-cache-config.xml

from the
https://maven.apache.org/extensions/maven-build-cache-extension/getting-started.html
page
for one (which also still refers to 1.0.0-SNAPSHOT)

https://maven.apache.org/extensions/maven-build-cache-extension/usage.html also
mentioned “true” in the “disabling” section - counter to the property which
is false.


-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree


On 8/11/2022 at 3:45:06 AM, Guillaume Nodet  wrote:

> The Apache Maven team is pleased to announce the release of the Apache
> Maven Build Cache Extension version 1.0.0
>https://maven.apache.org/extensions/maven-build-cache-extension/
>
> You should specify the version in your project's configuration:
>
>
>   1. 
>   2. org.apache.maven.extensions
>   3. maven-build-cache-extension
>   4. 1.0.0
>   5. 
>
>
> either in pom.xml's // or in
> .mvn/extensions.xml
> 's .
>
> Release Notes Maven Build Cache Extension 1.0.0
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12351243=12324820
>
> Release Notes - Maven Build Cache Extension - Version 1.0.0
>
> ** Sub-task
>* [MBUILDCACHE-2] - Extract caching system out of maven-core
>* [MBUILDCACHE-3] - Use maven session properties instead of reading
> directly from system properties
>* [MBUILDCACHE-4] - Make opt-in as easy as possible using a command
> line option / system property
>* [MBUILDCACHE-5] - migrate from JAXB to Modello
>* [MBUILDCACHE-6] - Rename schemas to be inlined with other schemas
>* [MBUILDCACHE-7] - Rebase on top of master 4.x
>* [MBUILDCACHE-8] - Avoid guava usage
>* [MBUILDCACHE-9] - Remove the `Type` suffix on the generated model
> classes
>* [MBUILDCACHE-10] - Make the cache singletons reusable across maven
> sessions
>* [MBUILDCACHE-11] - Define a maven 4 Feature for the cache system
>* [MBUILDCACHE-12] - Remove usage of plexus logger
>
> ** Bug
>* [MBUILDCACHE-16] - Fix config file name
>* [MBUILDCACHE-17] - IllegalStateException: Cache is not initialized.
> Actual state: null
>* [MBUILDCACHE-21] - Caching does not check permissions
>* [MBUILDCACHE-24] - Cache cannot be processed in presence of forked
> executions
>
> ** New Feature
>* [MBUILDCACHE-1] - [Deutsche Bank contribution] Incremental build with
> local and remote(shared) cache
>* [MBUILDCACHE-22] - Add possibility to skip cache lookup
>
> ** Improvement
>* [MBUILDCACHE-18] - Use m-resolver transport layer instead of
> redefining another one
>* [MBUILDCACHE-19] - Upgrade to resolver 1.8.0
>
> ** Task
>* [MBUILDCACHE-13] - rename remote.cache.* properties to build.cache.*
>* [MBUILDCACHE-26] - Ensure the maven version is >= 3.9
>
> Enjoy,
> --
> 
> On behalf of the Apache Maven team
> Guillaume Nodet
>

Re: Logging in Maven Plugins - Bridging

[Mark Derricutt]

 On 6/11/2022 at 8:48:28 PM, Ralph Goers  wrote:

> But the biggest problems with JUL include requiring everything being
> wrapped with isEnabled type methods to avoid logging overhead


I believe that was one of things addressed in the Flogger benefits - with
their API using LOG.atDebug()... or LOG.atInfo()...
that when not at the appropriate level, they can return a NoOpLogger which
just does nothing, which avoids any over head formatting when logging (
unless you do nasty string concatenation I guess ).

Still flawed slightly IMHO tho.

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: Logging in Maven Plugins - Bridging

[Mark Derricutt]

 On 6/11/2022 at 8:31:45 PM, Ralph Goers  wrote:

> I can absolutely guarantee you that if Google is actually using JUL that
> they
> have written plenty of their own code on top of it since JUL is woefully
> incomplete.


Google came up with Flogger - their fluent logging API that wraps JUL ( and
now has pluggable backends ) but doesn’t seem to have any any updates for
awhile: https://google.github.io/flogger/

The benefits page ( https://google.github.io/flogger/benefits ) is quite
compelling, tho I find the API a bit cumbersome.

Mark

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: API changes - was [VOTE] Release Apache Maven 4.0.0-alpha-2

[Mark Derricutt]

 On 21/10/2022 at 12:41:54 AM, Mark Derricutt  wrote:

> Merged and I’ll release in the morning - and run our main projects thru
> with Maven 4.0.0 and see how it fares.
>


Doh - released the new tiles this morning ( should really have tested it
again $work’s main project first tho) ):

When running under 4.0.0-alpha-2 I now get:

org.apache.maven.InternalErrorException: Internal error:
com.google.inject.ProvisionException: Unable to provision, see the
following errors:

1) [Guice/ErrorInjectingConstructor]: NoSuchMethodError:
DefaultProjectBuilder: method 'void ()' not found
  at TilesProjectBuilder.(TilesProjectBuilder.groovy:29)
  while locating TilesProjectBuilder
  at ClassRealm[extension>io.repaint.maven:tiles-maven-plugin:2.31, parent:
ClassLoaders$AppClassLoader@5b37e0d2]
  \_ installed by: WireModule -> PlexusBindingModule
  while locating ProjectBuilder
  at LocatorWiring
  at
TilesMavenLifecycleParticipant.projectBuilder(TilesMavenLifecycleParticipant.groovy:105)
  \_ for field projectBuilder
  while locating TilesMavenLifecycleParticipant
  while locating Object annotated with *


Larger trace:

at
com.google.inject.internal.InternalProvisionException.toProvisionException
(InternalProvisionException.java:251)
at com.google.inject.internal.InjectorImpl$1.get
(InjectorImpl.java:1104)
at org.eclipse.sisu.inject.Guice4$1.get (Guice4.java:162)
at org.eclipse.sisu.inject.LazyBeanEntry.getValue
(LazyBeanEntry.java:81)
at org.eclipse.sisu.plexus.LazyPlexusBean.getValue
(LazyPlexusBean.java:51)
at org.eclipse.sisu.wire.EntryListAdapter$ValueIterator.next
(EntryListAdapter.java:111)
at java.util.AbstractCollection.addAll (AbstractCollection.java:337)
at org.apache.maven.DefaultMaven.getProjectScopedExtensionComponents
(DefaultMaven.java:543)
at org.apache.maven.DefaultMaven.getExtensionComponents
(DefaultMaven.java:518)
at org.apache.maven.DefaultMaven.afterProjectsRead
(DefaultMaven.java:420)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:297)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:248)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:158)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:1004)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:307)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:204)
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
(DirectMethodHandleAccessor.java:104)
at java.lang.reflect.Method.invoke (Method.java:578)
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: java.lang.NoSuchMethodError:
org.apache.maven.project.DefaultProjectBuilder: method 'void ()' not
found
at io.repaint.maven.tiles.TilesProjectBuilder.
(TilesProjectBuilder.groovy)
at
io.repaint.maven.tiles.TilesProjectBuilder$$FastClassByGuice$$272625146.GUICE$TRAMPOLINE
()
at
io.repaint.maven.tiles.TilesProjectBuilder$$FastClassByGuice$$272625146.apply
()
at
com.google.inject.internal.DefaultConstructionProxyFactory$FastClassProxy.newInstance
(DefaultConstructionProxyFactory.java:82)
at com.google.inject.internal.ConstructorInjector.provision
(ConstructorInjector.java:114)
at com.google.inject.internal.ConstructorInjector.access$000
(ConstructorInjector.java:33)
at com.google.inject.internal.ConstructorInjector$1.call
(ConstructorInjector.java:98)
at
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision
(ProvisionListenerStackCallback.java:109)



I actually see the IT tests in the repo failing with the 4.0.0 release
(built via:

~/Applications/apache-maven-4.0.0-alpha-2/bin/mvn clean install
-Prun-its

I should set up GH action jobs for running with 4.x builds as well the 3.x
version.

Hrm

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: API changes - was [VOTE] Release Apache Maven 4.0.0-alpha-2

[Mark Derricutt]

 On 20/10/2022 at 11:49:48 PM, Tamás Cservenák  wrote:

> created PR that should restore compatibility, moreover, it remains mvn 3
> and 4 compatible
> (and some little cosmetic change to plexus xml)
>

Oh sweet!  Kudos.   Just triggered the build jobs with IT tests and all
passed.

Merged and I’ll release in the morning - and run our main projects thru
with Maven 4.0.0 and see how it fares.

Cheers
Mark

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: [DISCUSS] Change maven code style

[Mark Derricutt]

 On 20/10/2022 at 10:52:41 AM, Olivier Lamy  wrote:

> definitely +1 for palantir.
>

Having been trusted with clang-format on a few things - tried out
spotless/pantir on a small project.

+1 on that - it’s nice, tho - I wish it could be 2 space indents, going
back to 4 spaces I suspect will be disruptive for my own needs - but
probably not so Maven’s.

Interestingly - I see it doesn’t support the new Java text-blocks either
(one of my bugbears on clang-format currently).

Mark


-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: [VOTE] Release Apache Maven 4.0.0-alpha-2

[Mark Derricutt]

+1 one my projects not using tiles.


-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree


On 20/10/2022 at 10:38:47 AM, Olivier Lamy  wrote:

> +1
>
> I only have a small issue.
> I have this env var
> MAVEN_OPTS=-Djava.awt.headless=true -client -Xmx2048m -Xms2048m
>
> a project has .mvn/jvm.config with
> -Xmx1100m
>
> Maven 3.8.5 does this
>
> + exec
> /Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home/bin/java
> -Xmx1100m -Djava.awt.headless=true -client -Xmx2048m -Xms2048m
> -classpath
> /Users/olamy/softs/maven/apache-maven-3.8.5/boot/plexus-classworlds-2.6.0.jar
> -Dclassworlds.conf=/Users/olamy/softs/maven/apache-maven-3.8.5/bin/m2.conf
> -Dmaven.home=/Users/olamy/softs/maven/apache-maven-3.8.5
>
> -Dlibrary.jansi.path=/Users/olamy/softs/maven/apache-maven-3.8.5/lib/jansi-native
>
> 4.0.0-alpha-2 does this
>
> + exec
> /Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home/bin/java
> -Djava.awt.headless=true -client -Xmx2048m -Xms2048m -Xmx1100m
> -classpath
> /Users/olamy/softs/maven/apache-maven-4.0.0-alpha-2/boot/plexus-classworlds-2.6.0.jar
>
> -Dclassworlds.conf=/Users/olamy/softs/maven/apache-maven-4.0.0-alpha-2/bin/m2.conf
> -Dmaven.home=/Users/olamy/softs/maven/apache-maven-4.0.0-alpha-2
>
> -Dlibrary.jansi.path=/Users/olamy/softs/maven/apache-maven-4.0.0-alpha-2/lib/jansi-native
>
> which obviously fails
>
>
>
>
> On Sun, 16 Oct 2022 at 23:27, Guillaume Nodet  wrote:
>
>
> I've also deployed the distributions at
>
>
>
> https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-alpha-2/binaries/
>
>
> https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-alpha-2/sources/
>
>
> and the web site at:
>
>
>
> http://svn.apache.org/repos/asf/maven/website/components/ref/4-LATEST/index.html
>
>
> Guillaume
>
>
> Le sam. 15 oct. 2022 à 12:32, Slawomir Jaranowski 
>
> a écrit :
>
>
> > Hi,
>
> >
>
> > Link for biaries is:
>
> >
>
> >
> https://repository.apache.org/content/repositories/maven-1811/org/apache/maven/apache-maven/4.0.0-alpha-2/
>
> >
>
> > By the way binaries should be available at distribution area also ...
>
> > https://dist.apache.org/repos/dist/dev/maven/
>
> >
>
> > Did you publish a staging Maven site somewhere?
>
> >
>
> >
>
> > sob., 15 paź 2022 o 02:19 Guillaume Nodet 
> napisał(a):
>
> >
>
> > > I've staged a release candidate at
>
> > >   https://repository.apache.org/content/repositories/maven-1811
>
> > >
>
> > > The binaries are available at:
>
> > >
>
> > >
>
> > >
>
> >
> https://repository.apache.org/service/local/repositories/maven-1811/content/org/apache/maven/apache-maven/4.0.0-alpha-2/
>
> > >
>
> > > The tag is available at:
>
> > >   https://github.com/apache/maven/tree/maven-4.0.0-alpha-2
>
> > >
>
> > > Please review and vote !
>
> > >
>
> > > Cheers,
>
> > > Guillaume Nodet
>
> > >
>
> >
>
> >
>
> > --
>
> > Sławomir Jaranowski
>
> >
>
>
>
> --
>
> 
>
> Guillaume Nodet
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

API changes - was [VOTE] Release Apache Maven 4.0.0-alpha-2

[Mark Derricutt]

Trying out the new 4.0.0-alpha-2 release I see our tiles-maven-plugin
doesn’t work:

Caused by: java.lang.NoSuchMethodError:
org.apache.maven.project.DefaultProjectBuilder: method ()V not found
at io.repaint.maven.tiles.TilesProjectBuilder.
(TilesProjectBuilder.groovy)
at
io.repaint.maven.tiles.TilesProjectBuilder$$FastClassByGuice$$257858534.GUICE$TRAMPOLINE
()

Totally not a blocker for the release and will do additional tests on a
normal, but more a heads up of anyone with Mojos doing Project stuff -
guess I’ll be looking at a supporting version of tiles shortly.



-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree


On 15/10/2022 at 1:18:52 PM, Guillaume Nodet  wrote:

> I've staged a release candidate at
>  https://repository.apache.org/content/repositories/maven-1811
>
> The binaries are available at:
>
>
> https://repository.apache.org/service/local/repositories/maven-1811/content/org/apache/maven/apache-maven/4.0.0-alpha-2/
>
> The tag is available at:
>  https://github.com/apache/maven/tree/maven-4.0.0-alpha-2
>
> Please review and vote !
>
> Cheers,
> Guillaume Nodet
>

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Mark Derricutt]

 On 25/07/2022 at 10:38:34 AM, Michael Osipov  wrote:

> ...and their justification is? Don't tell me they will use Java 11
> features to sort a POM? Joke.



None -
https://github.com/Ekryd/sortpom/commit/080797dfee00b29839c2975348b5627911e2f5ad#commitcomment-78648749

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Mark Derricutt]

 For what it’s worth - I’m now finally starting to see a lot more libraries
updating their minimum supported versions to a mix of 11 and 17.

And now also encountering mojo updates ( sort pom hit he recently ) that
updated their minimum to 11 - and sadly all these changes are under
minor/patch versions which irk me beyond something ;p

Mark

On 25/07/2022 at 9:00:21 AM, Michael Osipov  wrote:

> I would lower the figure - keep in mind 95-99% of people also uses libs and
> are affected by what I described - but agree "most" would see it...at the
> cost of configuring toolchain and even just the test/compiler version in
> the pom which breaks our convention over config core design IMHO.
>


-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Mark Derricutt]

 Is that due to cold starting the JVM each time?

I wonder if mvnd supports toolchains effectively?  Or if that could be an
avenue to try.
-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

On 23/07/2022 at 8:13:23 PM, Delany  wrote:

> I tried toolchains but dropped it because of the exorbitant performance
> costs.
> A multi-module build that normally built in 3:50 took 10:34, and that's
> with toolchaining only maven-compiler-plugin.
>
>
>

Re: [ANN] Maven Resolver 1.8.0 released

[Mark Derricutt]

What version of maven can this be used under?  I call this from one of my
plugins and when updating to 1.8.0 I get:

Caused by: java.lang.NoSuchMethodError: 'java.util.List
org.eclipse.aether.spi.connector.layout.RepositoryLayout.getChecksumAlgorithmFactories()'
at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
(BasicRepositoryConnector.java:230)
at org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
(DefaultMetadataResolver.java:586)
at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
(RunnableErrorForwarder.java:75)
at org.eclipse.aether.internal.impl.DefaultMetadataResolver$1.execute
(DefaultMetadataResolver.java:510)
at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
(DefaultMetadataResolver.java:353)
at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata
(DefaultMetadataResolver.java:181)
at 
org.apache.maven.repository.internal.DefaultVersionRangeResolver.getVersions
(DefaultVersionRangeResolver.java:198)
at 
org.apache.maven.repository.internal.DefaultVersionRangeResolver.resolveVersionRange
(DefaultVersionRangeResolver.java:148)
at 
org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveVersionRange
(DefaultRepositorySystem.java:247)


when running under Maven 3.8.5 - I only updated the following deps:

resolved org.apache.maven.resolver:maven-resolver-api:1.8.0;
resolved org.apache.maven.resolver:maven-resolver-connector-basic:1.8.0;
resolved org.apache.maven.resolver:maven-resolver-impl:1.8.0;
resolved org.apache.maven.resolver:maven-resolver-spi:1.8.0;
resolved org.apache.maven.resolver:maven-resolver-transport-file:1.8.0;
resolved org.apache.maven.resolver:maven-resolver-transport-http:1.8.0;
resolved org.apache.maven.resolver:maven-resolver-util:1.8.0;


So maybe there’s something else I need to update?

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree


On 21/04/2022 at 4:26:22 AM, Michael Osipov  wrote:

> The Apache Maven team is pleased to announce the release of the Maven
> Resolver version 1.8.0.
>
> https://maven.apache.org/resolver/
>
> Release Notes - Maven Resolver - Version 1.8.0
>
> ** Bug
> * [MRESOLVER-241] - Resolver checksum calculation should be driven
> by layout
> * [MRESOLVER-242] - When no remote checksums provided by layout,
> transfer inevitably fails/warns
> * [MRESOLVER-250] - Usage of descriptors map in DataPool prevents
> gargabe collection
>
> ** New Feature
> * [MRESOLVER-236] - Make it possible to resolve .asc on a 'fail'
>  respository.
>
> ** Improvement
> * [MRESOLVER-240] - Using breadth-first approach to resolve Maven
> dependencies
> * [MRESOLVER-247] - Avoid unnecessary dependency resolution by a
> Skip solution based on BFS
> * [MRESOLVER-248] - Make DF and BF collector implementations coexist
>
> ** Task
> * [MRESOLVER-230] - Make supported checksum algorithms extensible
> * [MRESOLVER-231] - Extend "smart checksum" feature
> * [MRESOLVER-234] - Introduce "provided" checksums feature
> * [MRESOLVER-237] - Make all checksum mismatches handled same
> * [MRESOLVER-239] - Update and sanitize dependencies
> * [MRESOLVER-244] - Deprecate FileTransformer API
> * [MRESOLVER-245] - Isolate Hazelcast tests
>
> ** Dependency upgrade
> * [MRESOLVER-249] - Update Hazelcast to 5.1.1 in
> named-locks-hazelcast module
>
>
> 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: [DISCUSS] New Maven Core API for 4.x

[Mark Derricutt]

I’m wondering (off the cuff thought here) if having a stronger design
difference between a standard Mojo, and an Extension might be useful?

As general mojo/plugin - having an injected immutable MavenProject *view* is
probably fine, but for an extension I probably want a mutable
MavenProject.Builder or the like - that can be manipulated ( parents
injected/rewritten, additional tasks/plugins injected, dependencies vetted).

Or, a *subtle* change in terminology but with possible big-ups - rather
than *immutable*, have a *persistent* project model - similar to persistent
collections in Scala and other functional languages, they’re immutable, but
they have modification commands that return new, updated instances.

Having a defined model processor could go:  baseModel -> extension A ->
extension B -> reactor -> build-all-the-things.


-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree


On 29/03/2022 at 7:28:15 PM, Romain Manni-Bucau 
wrote:

> I think the number of plugin doing it is not that small, now the question
> is: what's the difference (technically) between a project you can mutate
> and a project manager mutating the project state? Idea behind is to NOT
> inject the MavenProject in any mojo but inject a proxy/decorated instance
> which can handle the manager and actual project usage as expected by maven.
> The impact being: no change in any plugin nor plugin api but same goal
> being reached. In other words we have:
>
> 1. maven-core which uses whatever he wants to reach the programming model
> we think is good (immutability)
> 2. @Parameter MavenProject which becomes an API delegating to 1 (but is
> never the internal MavenProject instance)
>
> (indeed same applies to all models, just took project as an example which
> is likely more familiar)
>
>
>

Re: [DISCUSS] New Maven Core API for 4.x

[Mark Derricutt]

 We’re over at https://github.com/repaint-io/maven-tiles


What we’re doing is essential “evil” and mixing in “tiles” as implicit
parents.

It’s it’s no longer possible with 4.x - and if 4.x could provide something
similar, with a transition path we could document, I’m down with sunsetting
the project for 4.x+.

Mark

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree


On 29/03/2022 at 8:53:06 AM, Guillaume Nodet  wrote:

> Le lun. 28 mars 2022 à 21:22, Mark Derricutt  a écrit :
>
>  I wonder how much of this will break what we do with the
>
> tiles-maven-plugin, where we essentially “inject” parents into the model
>
> via a maven extension.
>
>
>
> Interesting. Do you have a pointer to that plugin's source code ?
>
> Guillaume
>
>

Re: [DISCUSS] New Maven Core API for 4.x

[Mark Derricutt]

 I wonder how much of this will break what we do with the
tiles-maven-plugin, where we essentially “inject” parents into the model
via a maven extension.

I remember I was seeing some odd issues under earlier builds of 4.x as well
some time ago but will need to refresh my memory on what that was now.
Something about properties no longer passing down to those injected parents
if I recall.

Mark

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree


On 29/03/2022 at 6:30:24 AM, Guillaume Nodet  wrote:

> What I have in mind is that plugins that use the new api would receive the
> immutable model, while plugins that use the old (3.x) api would receive a
> model that would wrap the immutable one. However, I think mutating the
> model or the maven project should be done via services provided by the
> maven api. That will allow controlling concurrent access, interception,
> logging, etc...
> For example, adding a source directory in the new api is done using the
> ProjectManager, which I think should be the place where the project is
> mutated:
>

Re: [VOTE] Release Apache Maven version 3.8.1

[Mark Derricutt]

+1 non-binding

   - bistro zips are in the /dev/ tree
   - my multi-repo osgi maven tiles weirdo build works fine.




From: Robert Scholte  
Reply: Maven Developers List  
Date: 31 March 2021 at 9:58:56 AM
To: dev@maven.apache.org  
Subject:  [VOTE] Release Apache Maven version 3.8.1

Hi,

For the details about this release, please read
https://maven.apache.org/docs/3.8.1/release-notes.html
Also please provide feedback on the release notes. (as you know, these are
published separately from the release, so it doesn't have to block the
release itself)

We solved 6 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12350032=Text

Staging repo:
https://repository.apache.org/content/repositories/maven-1634/
https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.1/binaries/apache-maven-3.8.1-bin.zip
https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.1/source/apache-maven-3.8.1-src.zip

Source release checksum(s):
apache-maven-3.8.1-bin.zip sha512:
c585847bfbcf8647aeabfd3e8bf0ac3f67a037bd345545e274766f144c2b978b3457cbc3e31545e62c21ad69e732695de01ec96ea2580e5da67bd85df095c0f4

apache-maven-3.8.1-src.zip
sha512: 
893988635349985074c88ce5ef27ac5ccb62fcdf58846209eee8a7ea5515238288b91c202347ca42e201ab336c14d83f3f5fd8194070e57b9366bcce2414614d


Knows issues:
When building with the sources with JDK-16 and above, the unittest
MavenCliTest#testStyleColors will fail. This will be fix with MNG-7127[1],
but is left out to keep focus on the real purpose of this release.

Staging site:
https://maven.apache.org/ref/3-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1


---
[1] https://issues.apache.org/jira/browse/MNG-7127

Re: [VOTE] Release Apache Maven version 3.8.0

[Mark Derricutt]

Mostly reads good to me, only minor niggle to me is:

Then once the vote passed, svn move to release

which I think might be grammatically better:

“Once the vote has passed, svn move to the release tree ”

+1.5 non-binding :)




From: Hervé BOUTEMY  
Reply: Maven Developers List  
Date: 27 March 2021 at 2:19:48 PM
To: Maven Developers List  
Subject:  Re: [VOTE] Release Apache Maven version 3.8.0

first pass of documentation improvement done in
github.com/apache/maven-site/commit/ec73b445adc7012e1384cf1b89af3f0a6f5eee17
please all review and see if anything you read may be mis-interpreted when
reading fast

Re: [VOTE] Release Apache Maven version 3.8.0

[Mark Derricutt]

I notice in the vote email we have mentioned:

dist.apache.org/repos/dist/release/maven/maven–3/3.8.0/binaries/apache-maven–3.8.0-bin.zip


which doesn’t really highlight anywhere that this is a staging/unreleased
version.

Tho changing that probably won’t change too much here.

*ponders*




From: Gary Gregory  
Reply: Maven Developers List  
Date: 26 March 2021 at 2:13:05 PM
To: Maven Developers List  
Subject:  Re: [VOTE] Release Apache Maven version 3.8.0

It's pretty clear to me that the Maven release process is broken when
people are getting new versions they think are real and valid when in fact
it is a release candidate vote in in progress. Gary

Re: [VOTE] Release Apache Maven version 3.8.0

[Mark Derricutt]

+1 non-binding from me, tho I have (potential) concerns.

I’d missed seeing the emails about the release vote, but DID notice that
Mac Homebrew had upgraded me magically to 3.8.0.

Which led me to tweeting that it seemed the download page wasn’t updated (
then a followup about home-brew jumping the gun):

https://twitter.com/talios/status/1374188445380214784

Carlo Cabrera responded that he reverted the change in Homebrew:

https://twitter.com/carlocab_/status/1374230372112867330

tho, anyone who happened to download the update, still has that update
installed.

Downloading the zip here, and checking:

~/Downloads/Download Sync/apache-maven-3.8.0 ❯ ./bin/mvn -version
Apache Maven 3.8.0 (6aa1f4acf5d6323e9aa08b763cb9933dc96749b9)
Maven home: /Users/amrk/Downloads/Download Sync/apache-maven-3.8.0
Java version: 1.8.0_282, vendor: Azul Systems, Inc., runtime:
/Users/amrk/.sdkman/candidates/java/8.0.282-zulu/zulu-8.jdk/Contents/Home/jre
Default locale: en_NZ, platform encoding: UTF-8
OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
~/Downloads/Download Sync/apache-maven-3.8.0 took 3s ❯ mvn --version
Apache Maven 3.8.0 (6aa1f4acf5d6323e9aa08b763cb9933dc96749b9)
Maven home: /usr/local/Cellar/maven/3.8.0/libexec
Java version: 1.8.0_282, vendor: Azul Systems, Inc., runtime:
/Users/amrk/.sdkman/candidates/java/8.0.282-zulu/zulu-8.jdk/Contents/Home/jre
Default locale: en_NZ, platform encoding: UTF-8
OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"

both releases have the same SHA1 for the build - so in this instance I’m
happy for a +1.

Tho I wonder what the recourse would be if needing to respin the release -
3.8.1 version bump or?

Is there anyway to prevent this happening again? ( Probably off-thread
replies would be best ).

Mark




From: Tibor Digana  
Reply: Maven Developers List  
Date: 26 March 2021 at 8:05:51 AM
To: Maven Developers List  
Subject:  Re: [VOTE] Release Apache Maven version 3.8.0

here is mine +1.
The amount of work means more for me than the version 3.7.0 we skipped. We
can improve it in the future of course!
Regarding the issues found with the Warning on the console, these issues
can be fixed as always, right after.
T

On Mon, Mar 22, 2021 at 8:40 PM Robert Scholte 
wrote:

> Hi,
>
> For the details about this release, please read
> https://maven.apache.org/docs/3.8.0/release-notes.html
> Also please provide feedback on the release notes. (as you know, these
are
> published separately from the release, so it doesn't have to block the
> release itself)
>
> We solved 5 issues:
>
>
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12350003=Text
>
> There are still a couple of issues left in JIRA:
>
>
https://issues.apache.org/jira/issues/?jql=project%20%3D%2012316922%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1633/
>
>
>
https://dist.apache.org/repos/dist/release/maven/maven-3/3.8.0/binaries/apache-maven-3.8.0-bin.zip
>
>
https://dist.apache.org/repos/dist/release/maven/maven-3/3.8.0/source/apache-maven-3.8.0-src.zip
>
>
> Source release checksum(s):
>
> apache-maven-3.8.0-bin.zip sha512:
b56da9a0efa45e084e4882b795787fc7b61970d19835635b2db099b91a9854f14e3776a01d569e3f7af9db946a05af91abbfad41cdc5ac09e90df25077dec01e

>
> apache-maven-3.8.0-src.zip sha512:
51a1570894e8fb1ef52cb19ce472866745ccae2720e45304edd3cabc212cdf105937c76502558fe87995aea81c41402d7f581cc8e9393af234b64696e9a45893

>
>
> Staging site:
> https://maven.apache.org/ref/3-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: [DISCUSS] Allow attributes shorthand in pom.xml

[Mark Derricutt]

Spoken just like someone who deals with people from high school in 2005.

I certainly care about reproducible builds - maybe not to the level of
some, but when working on projects that span multiple years, have multiple
deployments in different data centres for different customers, with
different versions deployed - that all need to be able to be maintained.

Being able to check out the version of the project that would deployed 2
years ago, and rebuild it with the exact same packages and get the same
build back - makes patching so much easier.

With a project made up on around 90 repos/artifacts ( non multi module - so
different releasee cadences across the board ), being able to check out
that old version - build it, reproduce the problem, patch one, maybe two
modules, and rebuild the platform for distribution with the minimum of
surface area change possible - for that patch release - and being able to
do that without major issue, in a short period of time - is a god send.

Sure, it MAY incur some upfront and ongoing costs - but the pay off, when
needed - is wonderful.

the level of frustration people have with Maven and its enthrallment with
XML at this point

I see a lot of folk grumble about XML, or mostly - the over use of elements
vs attributes, however, knowing that *everything* is an element (config
aside in a few plugins) is also a godsend for both tooling, and consistency.

I see far more people grumble about Gradle’s blend of DSL and Groovy
programming, and the dark majick that obscures where one changes from the
other ( I believe this is mitigated largely with the Kotlin DSL ).

You won’t have to look far to find someone, even those on the dev team who
don’t agree that the POM needs to change - but adoption, and usage is now
far far *beyond* merely just “Apache Maven” itself - so it’s not the
easiest thing to change.

You mention that 12 line SBT build - that’s great, but the moment you need
to deviate from something normal - it can deviate quite quickly IMHO.




From: Hunter C Payne 

Reply: Maven Developers List  
Date: 14 December 2020 at 10:06:25 AM
To: Maven Developers List  
Subject:  Re: [DISCUSS] Allow attributes shorthand in pom.xml

Hunter PS I've never even heard someone want a repeatable build.  I have no
idea why that would even be that desirable.

Re: Hello from mvnd

[Mark Derricutt]

I just wanna say kudos to mvnd - found it the other day on r/java (or
r/programming) and I must say - this is awesome.

It even plays well with our tiles-maven-plugin which I was sure it would
play up on.

Mark




From: Peter Palaga  
Reply: Maven Developers List  
Date: 14 October 2020 at 8:55:14 AM
To: dev@maven.apache.org  
Cc: Guillaume Nodet  
Subject:  Hello from mvnd

I think we can say that the project left the PoC phase recently. We use it
for our daily work, we made it available via SDKMAN and we are solving
issues coming from the users.

Re: [VOTE] Release Maven Resolver version 1.6.1

[Mark Derricutt]

+1 Non-binding.  Seems to be working fine on my custom artefact resolving
plugin/library.

On 3 October 2020 at 7:32:20 AM, Osipov Michael (micha...@apache.org) wrote:

Hi,

We solved 25 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12348853

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/projects/MRESOLVER/issues?filter=allopenissues

Staging repo:
https://repository.apache.org/content/repositories/maven-1607/
https://repository.apache.org/content/repositories/maven-1607/org/apache/maven/resolver/maven-resolver/1.6.1/maven-resolver-1.6.1-source-release.zip

Source release checksum(s):
maven-resolver-1.6.1-source-release.zip
ab45c772e9af4061977feb4fb48e3ae9ddd8cbebe41ada40f2a762504e96fd4c0fd4a939ab707667d9888caf92ab9fa354abe0624031c7049b7a2cb133421ddd


Staging site:
https://maven.apache.org/resolver-archives/resolver-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Note: This Resolver offers salvation from a 13.5 years old feature
request: MNG-2802
Yes, you can have now concurrent-safe access to your local Maven
repository synchronized with Redis.

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

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

Re: [RESULT] [VOTE] Release Maven Resolver version 1.5.0

[Mark Derricutt]

Hervé, Michael - missed the email about the vote earlier, just went hunting
for the repo details to try it out on our internal range resolver/locking
tool.

+1 NON Binding here - passes my unit tests on my library, and the maven
mojo that uses it runs fine as works as expected.

Mark


On 22 July 2020 at 6:05:39 PM, Hervé BOUTEMY (herve.bout...@free.fr) wrote:

hey, keep cool, take time: 72h is the minimum, not the period after which
the vote stops there was some discussions, people are on vacation, it takes
more time than usual, nothing that a little bit of time won't solve
Regards, Hervé Le mardi 21 juillet 2020, 20:32:49 CEST Michael Osipov a
écrit : > Hi, > > The vote has passed and failed to reach a quorum. Only
one, non-binding > vote has been cast. Therefore, I cancel the release and
will drop the > staging repo tomorrow. > > Michael

Re: Maven moving to the next level: the build/consumer pom

[Mark Derricutt]

Hervé,

If you configure IntelliJ (projecting much Mark?) to use Maven
3.7.0-SNAPSHOT as it’s maven version, does that work?

I tend to configure my IJ to use my built SNAPSHOT when testing out Maven
releases.

Mark

On 6 July 2020 at 8:21:57 PM, Hervé BOUTEMY (herve.bout...@free.fr) wrote:

What is expected is IDE maintainers to check what they need to do at IDE
level to support these new POMs that only build with Maven 3.7.0-SNAPSHOT.

Re: Maven moving to the next level: the build/consumer pom

[Mark Derricutt]

Robert Scholte:
There is a feature toggle, see
https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/feature/Features.java#L34



Awesome - I’ll get that a play and report back.

Does this mean that the install:install did work?
That would be interesting.
I am not aware of that issue. Is there already a JIRA ticket for it,
because this must be solved before the next release.


Install worked fine, just the deploy - we do have a custom mojo that has a
dependency on aether/maven-resolver, so may be I’ll need to update that,
altho I assume that should be in different class loaders.

I’ll try with a totally clean project, and introduce things we have in our
builds piece by piece and try make a minimum test case.

Mark

Re: Maven moving to the next level: the build/consumer pom

[Mark Derricutt]

I thought I’d responded - this has been a long time coming, and has been
discussed numerous times over the past few years, and I’m quite excited to
give it a bash, and see how well it works, and see if/what any implications
this has for our tiles-maven-plugin.

I still need to find time to dig into this.

Robert - is there anything specific one does to “enable” this currently -
or is the current merge simply the machinery to take the build pom (even if
its a 4.0.0 model) and produce the consumer pom.

Currently I don’t see any diffs between my pom.xml, and the pom.xml that
gets included inside the .jar file, I tried doing a “mvn deploy” to check
the version that got deployed, but yields an missing class exception using
2.8.2:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy)
on project smx3.reporting: Execution default-deploy of goal
org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy failed: A
required class was missing while executing
org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy:
org/eclipse/aether/transform/FileTransformer
[ERROR] -
[ERROR] realm =plugin>org.apache.maven.plugins:maven-deploy-plugin:2.8.2

(I’m unable to currently use 3.0.0-M1 for the same reason either).

Hrm.
Mark


From: Jaroslav Tulach 

Reply: Maven Developers List  
Date: 4 July 2020 at 5:35:37 PM
To: dev  
Cc: dev@maven.apache.org  ,
us...@maven.apache.org  ,
m2e-...@eclipse.org  ,
openc...@microsoft.com  
Subject:  Re: Maven moving to the next level: the build/consumer pom

Hello Robert,
I am not sure how to deal with your announcement and given no reaction on
the dev@netbeans mailing list, I am probably not alone. Can you formulate

Re: 'modelVersion' is missing.

[Mark Derricutt]

On 30 Jan 2020, at 10:53, Robert Scholte wrote:

> I assume these are parent pom's right?
> Are they part of the reactor or are they poms from a remote repository?
>
> The order of resolving parents has changed a bit: it used to look in the 
> cache based on GAV, followed by matching the path of this modelSource.
> Now it is kind of the other way around: look in cache by relativePath or read 
> by relativePath, next match the GAV.
>
> Were these poms generated?

They're "tiles" - using our tiles-maven-plugin to provide mixin support, 
essentially they do get injected as parents into the model tho.

We read the tile.xml artefact we publish/manually write and inject that as 
parents.

https://github.com/repaint-io/maven-tiles


For now I've dropped back to pre-that commit and everything works, I'll do some 
further testing later on and see if things break once I add those 
modelVersion's into the tiles.



---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.chaliceofblood.net
http://www.theoryinpractice.net
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

'modelVersion' is missing.

[Mark Derricutt]

Hey all,


Interesting - I just rebuilt my maven dev snapshot ( last build yesterday 
worked fine ) and now I hit:


[ERROR] Error executing Maven.
org.apache.maven.model.building.ModelBuildingException: 2 problems were 
encountered while building the effective model for 
smx3:smx3.upstream.testing.bill-of-materials:1.0.46-SNAPSHOT
[ERROR] 'modelVersion' is missing. @ 
com.smxemail.tiles:com.smxemail.tiles.release:2.1.71
[ERROR] 'modelVersion' is missing. @ 
com.smxemail.tiles:com.smxemail.tiles.enforcements:3.1.18


This looks to have been introduced/tripped by commit:

716cc1fe026618 [MNG-5669] same pom.xml is read multiple times

Interesting, it does seem I'm missing the `modelVersion` element in my maven 
tiles, so I'm actually fine with this blowing up as I can easily add that and 
rerelease our tiles.

I suspect this was from:

```
-modelRequest.setModelSource( new FileModelSource( 
pomArtifact.getFile() ) );
+modelRequest.setModelSource( new ArtifactModelSource( 
pomArtifact.getFile(),
+  
pomArtifact.getGroupId(),
+  
pomArtifact.getArtifactId(),
+  
pomArtifact.getVersion() ) );
```

Just thought I'd query this, and maybe we can note it somewhere in some release 
notes or something...

Cheers,
Mark

---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

**Mark Derricutt** | Senior Developer
**Phone**: +64 9 302 0515 Fax: +64 9 302 0518
**Mobile**: +64 21 562 533 Freephone: 0800 SMX SMX (769 769)
**Twitter**: @talios
**SMX Limited**: Level 10, 19 Victoria Street West, Auckland, New Zealand
**Web**: http://smxemail.com

![Cloud Email Hosting & Security](http://smxemail.com/images/smxsig.png)


signature.asc
Description: OpenPGP digital signature

Re: [ANN] Apache Maven Release Plugin 3.0.0-M1 Released

[Mark Derricutt]

On 16 Dec 2019, at 21:02, Hervé Boutemy wrote:

> 
>   org.apache.maven.plugins
>   maven-release-plugin
>   3.0.0-M1
> 

Him, updating my projects to use this and got:

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-release-plugin:3.0.0-M1:prepare (default-cli) on 
project smx3.bill-of-materials: Execution default-cli of goal 
org.apache.maven.plugins:maven-release-plugin:3.0.0-M1:prepare failed: A 
required class was missing while executing 
org.apache.maven.plugins:maven-release-plugin:3.0.0-M1:prepare: 
org/apache/maven/shared/release/env/ReleaseEnvironment

This is configured in an import tile from out tiles project configured as:

  
default
  
  ...
  
org.apache.maven.plugins
maven-release-plugin
2.5.3

  
clean
reproducible:apply
sortpom:sort
tidy:pom
rangeresolver:lock-deps
install
  
  deploy
  
reproducible:clear
sortpom:sort
tidy:pom
  
  
${projectVersionPolicyId}
  true
  false
  true


  
com.smxemail
qualified-version-policy
1.0.2
  

  

We do have a custom projectVersionPolicy that we configure, defaulting to 
'default'.

I note in the changeling:

* [MRELEASE-975] - NPE when using an unknown project versionpolicy id
* [MRELEASE-956] - Release Strategy Interface

Is there a documented set of changes? MRELEASE-956 seems to imply the the 
current API is still there?

Mark





---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Reproducible Builds for Maven

[Mark Derricutt]

On 28 Sep 2019, at 18:21, Hervé BOUTEMY wrote:

> I'll share shortly a discussion on a choice we need to do together to define 
> how to configure reproducible builds (property name and value/format of 
> current source-date-epoch defined in PoC)

Now that support for this has been released as part of the source/jar plugins, 
but not yet the release plugin, I whipped up this morning a quick plugin to use 
in the meantime:

  https://github.com/talios/reproducible-maven-plugin

Basically to be included in preparationGoals/completionGoals using the 
apply/clear goal in each.

So far based on very quick, rudimentary tests this seems to work well (altho 
I've not yet done it as part of a release, but using apply and then 
building/checking my jars.

I'd be keen on any feedback...

Interestingly, whilst the class files INSIDE the jar have the correct date, the 
jar this has todays - which makes sense, but I wonder if it shouldn't be the 
same time for one extra step of "the exact same output"...

Mark



---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: last review of Reproducible Builds proposal

[Mark Derricutt]

On 6 Oct 2019, at 9:14, Hervé BOUTEMY wrote:

> if anybody cares about the exact value: but
> who really looks at the timestamp of entries in release zips/jars/tar.gz
> honestly?

I've actually done so in the past trying to find differences between two 
versions of a jar for repair reasons.

VERY infrequent tho - if you're wanting to generate a delta-patch between two 
jars/zips then I guess it might also be handy (altho you might be better off 
going direct for checksumdifferences  there ).


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Reproducible Builds for Maven

[Mark Derricutt]

On 24 Sep 2019, at 23:37, Tomo Suzuki wrote:

> versions, rather than ranges. Would you share the background why your tool
> records the ranges?

The full examples is at:

  https://github.com/HalBuilder/halbuilder-support-4.x/blob/master/pom.deps

It resolves the locked down versions, but also retains the desired ranges for 
controlled updates.

We tend to keep ranges between major versions, i.e. [1.0.0,2.0.0) for a 
semblance of semver.

When I reresolve the bill of materials, I find I'll often look at the git diff 
and see what new versions of libraries have been updated, and decide which ( 
and when ) we pull them in to use - often committing those changes individually.



---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Reproducible Builds for Maven

[Mark Derricutt]

Oh right! I missed the second half of our pom.deps file:

   blacklisted org.hibernate:hibernate-ehcache:4.2.19.Final from 
smx3:smx3.bill-of-materials:2.1.1;
   deprecated org.hibernate:hibernate-search-engine:4.4.0.Final from 
smx3:smx3.bill-of-materials:2.1.1;
   resolved org.hibernate:hibernate-search-orm:4.4.0.Final from 
smx3:smx3.bill-of-materials:2.1.1;
   locked org.hibernate:hibernate-validator:4.3.1.Final from 
smx3:smx3.upstream.bill-of-materials:1.0.16;


I provide 4 types of resolution, deprecated/blacklisted means the build 
will fail, unless you specifically opt-in to deprecated/blacklisted 
dependencies.


On resolve, anything that's changed moves from `locked` to either 
resolved/deprecated/blacklisted, and on release anything resolved goes 
to locked.


In the end user projects, we "import" the bill of materials .deps 
artifact which pulls in any locked version, but I also have support for 
adding:


   allow unlocked /^.*someregex.*$/;

which will trigger a re-resolve, which we use for our own internal 
artifacts, so we pick up the latest internal releases IF we re-resolve.


The whole process seems to work well, it does cause some annoying round 
trip releases or quirks now and then, but for the most part - it's 
really solved a heap of issues where we've needed to back a quick 
backport fix in a production environment.


Since we publish the pom.deps file for each artifact, when doing the 
backports, we simply import the deps used in the distribution version 
we're patching, and manually allow any updated deps that we need to fix.


Tomo Suzuki wrote:


For reproducible builds, I expected the lock file contains specific
versions, rather than ranges. Would you share the background why your tool
records the ranges?

Re: Reproducible Builds for Maven

[Mark Derricutt]

Tomo Suzuki wrote on 23/09/19 3:56 PM:

Does your approach use such file to record library versions?
I don't know about what Hervé is doing, but internally we have a tool I 
wrote for handling this, we have a pom.deps file that looks like:


    repository http://nexus.XX as public;

    import smx3:smx3.upstream.bill-of-materials:1.1.22;

    resolve highest org.jetbrains:annotations:[16.0.3,17.0.0) via public;
    resolve highest 
org.apache.maven.plugins:maven-jar-plugin:[3.1.2,4.0.0) via public;
    resolve highest org.apache.cxf:cxf-codegen-plugin:[3.3.3,4.0.0) via 
public;


which when we resolve, will find the highest, snapshot, or lowest 
version in a given range - also allowing filtering out annoying things 
like beta/alpha/CR from central, and rewriting the pom.xml's.


Our tooling also has an 'import' option shown above that lets us 
standardize the versions we resolving, and breaking it up - so we have 
'upstream.bill-of-materials' and 'upstream.testing.bill-of-materials`.


As part of this we also add in  to ban all transitive build 
deps, and [] range all version references.


I keep meaning to push for open sourcing it, but just haven't had the time.

Mark


--
Sent from Postbox 

Commits on the repo?

[Mark Derricutt]

Hey all,

Just a quick query - I haven't seen any commits on the 
https://gitbox.apache.org/repos/asf/maven.git ( at least, on `master` ) since 
`9dd4732b7425f6`:

```
commit 9dd4732b7425f6fdbcae1fddfa9b3e47b8f45b8d
Refs: [master], {origin/master}, {origin/HEAD}, maven-3.6.0-45-g9dd4732b7
Author: Michael Osipov 
AuthorDate: Sun Feb 17 20:30:25 2019 +0100
Commit: Michael Osipov 
CommitDate: Sun Feb 17 20:30:25 2019 +0100

Revert "[MNG-6548] Lifecycle plugin version upgrades
```

am I looking in the wrong place or has nothing just been merged on `master` 
lately?

Cheers,
Mark




---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [ANN] Apache Maven Install Plugin Version 3.0.0-M1 Released

[Mark Derricutt]

On 2 Oct 2018, at 4:32, Karl Heinz Marbaise wrote:

>  * [MINSTALL-118] - MavenProject with only attachments must have packaging 
> "pom"

Ik, this just hit me with the `karaf-assembly` packaging - and seemingly not 
setting a main file it seems.

Time to go lock that install plugin back down, and raise a ticket for Karaf.

Mark


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Maven 4.0.0

[Mark Derricutt]

On 12 Nov 2017, at 23:06, Stephen Connolly wrote:

> That could end up duplicating the local repo cache... unless we default the
> cache to ~/.m2/repository anyway... otoh a concurrency safe local repo
> cache may mandate a new location... but double the downloads for inter-op
> with older Maven installs on the same machine seems not so good to me.

If we're talking restructuring the local repo, I've long wanting to separate 
out locally "mvn install"'d items from those downloaded, essentially this would 
keep ( for the most part ) local SNAPSHOTs separate from anything downloaded.

I guess what I really want there is a local releases/snaphshots repo 
separation, often it's handy to just blow away all snapshots and rebuild into a 
known state.  It does make for more complexity tho.



---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Maven 4.0.0

[Mark Derricutt]

On 5 Nov 2017, at 10:42, Robert Scholte wrote:

> I would like to drop strict scopes in general and give plugins the 
> opportunity to depend on
> specific scoped dependencies.

How would this help with annotations tho? The main issue I'm facing is having a 
standard m-c-p plugin definition in a parent ( or tile ) but needing different 
annotation processors used per project. With the current plugin, this means 
either listing them as standard dependencies and have them auto-scanned, and 
pollute the compilation classpath, or list every possible annotation processor 
dependency we may use in our projects in the parent, which is less than ideal.

> I hope you are aware that modules already end up on the modulepath based on 
> the moduledescriptor(s). So I don't see the need for this scope. (unless you 
> have this wish that in the end Maven will create the module descriptor based 
> on this, but I still think we shouldn't do that)

I remembered reading something about this, and assumed it was the case if there 
was a module-info.class, but what if its a standard jar with an 
Automatic-Module-Name header? Does that fall into the module path or classpath? 
Having control for this case may be useful.


> I recognize this wish. The best solution is to make the dependency optional.

The problem with this is that the dependency is still on the classpath for say 
surefire, which can influence behaviour.

Mark



---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: JDK 10 b29 Early Access is available on jdk.java.net

[Mark Derricutt]

On 3 Nov 2017, at 22:48, Rory O'Donnell wrote:

> JDK 10 Early Access  build 29 is available at : - jdk.java.net/10/

Looks like Surefire is the first casualty:

Caused by: java.lang.NullPointerException
at 
org.apache.maven.surefire.shade.org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast
 (SystemUtils.java:1626)
at org.apache.maven.plugin.surefire.AbstractSurefireMojo.getEffectiveJvm 
(AbstractSurefireMojo.java:2107)
at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.getForkConfiguration 
(AbstractSurefireMojo.java:1976)
at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider 
(AbstractSurefireMojo.java:)
at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked
 (AbstractSurefireMojo.java:954)
at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute 
(AbstractSurefireMojo.java:832)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
(DefaultBuildPluginManager.java:134)

I guess that new-new version string change is gonna bite everyone



---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Maven 4.0.0

[Mark Derricutt]

Would adding support for 2 new scopes be viable without changing the pom
model ( the DTD/XSD doesn't actually define the values so that should be
ok).

Specifically I'm thinking 'annotation' ( having annotationPaths on m-c-p
was a workaround, but kinda horrible in practice ), and maybe "module" for
the new module path?

On the topic of scopes, I'd love to see an _actual_ compile-time-only
scope, thats only at compilation.  I wonder, since the scope values are not
actually set in the DTD/XSDs, could the internals be altered to say a CSV
of scopes, with the default being "compile,test" which would cover current
behaviour - but if you specifically say "this is a compile only dependency"
then it literally is.

Mark

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

On Sun, Nov 5, 2017 at 1:20 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> The past two days, Hervé, Robert and I have been discussing our next steps.
>
> I think we have a semi-consensus which I want to bring back to the list:
>
> We keep 3.5.x as a stable branch with critical bug fixes only
>
> We switch master to 4.0.0 and start to burn down a release scope.
>
> 4.0.0 will not change the pom modelVersion
>
> The 4.0.0 scope should probably be:
>
> Required:
> * drop Java 7, switch codebase to Java 8 idioms (while maintaining binary
> api compatibility for plugins)
> * specify the classloader behaviour and fix impl to align with spec (may
> need a plugin flag to allow plugins to opt in to spec behaviour)
> * specify the extension spec
> * allow limited mutation of the runtime model (reducing transitive
> dependencies for consumers within the reactor, only for plugin goals that
> declare intent) use case: shade plugin
> * better CI integration hooks
> * nice error message for newer pom modelVersion
>
> Optional:
> * (damn I forgot, maybe Robert remembers)
> --
> Sent from my phone
>

Re: [VOTE] Release Apache Maven 3.5.2

[Mark Derricutt]

+1 looking good from here on my projects/releases.

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

On Wed, Oct 18, 2017 at 11:50 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Hi,
>
> We solved 26 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> version=12338964=Text=12316922
>
> There are 357 issues left in JIRA for Maven core:
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1373/
>
> The distributable binaries and sources can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1373/org/apache/maven/apache-maven/3.5.2/
>
> Specifically the zip, tarball and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1373/org/apache/maven/apache-maven/3.5.2/apache-maven-3.5.2-bin.zip
> https://repository.apache.org/content/repositories/maven-
> 1373/org/apache/maven/apache-maven/3.5.2/apache-maven-3.5.2-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-
> 1373/org/apache/maven/apache-maven/3.5.2/apache-maven-3.5.2-src.zip
> https://repository.apache.org/content/repositories/maven-
> 1373/org/apache/maven/apache-maven/3.5.2/apache-maven-3.5.2-src.tar.gz
>
> Source release checksum(s):
> apache-maven-3.5.2-src.tar.gz sha1: 97d6d7b18485b7906dd7f313cdd411
> 91d16dde46
> apache-maven-3.5.2-src.zip: sha1: dc8caa5cdacb400943d2491a020f742a518e8f08
>
> Git tag:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> 138edd61fd100ec658bfa2d307c43b76940a5d7d
>
> Staging site:
> https://maven.apache.org/components/ref/3-LATEST/
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Thanks,
>
> Stephen.
>

Re: [VOTE] Release Apache Maven 3.5.1

[Mark Derricutt]

Would it be possible to handle this in a somewhat similar way to threadSafe
mojos - some form of plugin flag that says "extensionSafe" [1], that if the
plugin has true declared and doesn't declare
itself as being extensionSafe/extensionAware then we log a build warning -
it wouldn't solve anything, other than giving some feedback to users some
indication of WHY their build fails under 3.5.1 - and to either remove
 or fix/update their plugins.

[1] Or even just infer the applicability of extensions by the presence of
custom lifecycles, or Mojos implementing the extension interfaces ( it's
midnight, and a hazy tired thought ).

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

On Sat, Sep 16, 2017 at 12:22 AM, Anders Hammar  wrote:

> Based on Igor's feedback I'm changing my vote to +1.
>
> Having this class loader change in a bug fix release is probably not
> (semver) ideal though.
>
> /Anders
>
> On Fri, Sep 15, 2017 at 2:12 PM, Igor Fedorenko 
> wrote:
>
> > I answered in more details on m2e-dev, but I believe we can compensate
> > for the change from m2e end. In the worst case we'll bundle hacked
> > version of DefaultClassRealmManager with m2e, not ideal, but not the end
> > of the world either.
> >
> > --
> > Regards,
> > Igor
> >
> > On Fri, Sep 15, 2017, at 07:21 AM, Anders Hammar wrote:
> > > On Fri, Sep 15, 2017 at 8:29 AM, Anders Hammar 
> > wrote:
> > >
> > > > Reporting back from tests of m2e with embedded Maven 3.5.1, we see
> > problem
> > > > with the jaxws-maven-plugin mojo. We're two people seeing the issue
> > > > independently, but unfortunately Fred Bricon hasn't been able to
> > reproduce.
> > > >
> > >
> > > To follow up on this, my tests indicate that Maven 3.5.1 causes changed
> > > class loading that could cause issues for plugins in m2e. I've asked
> for
> > > input from the m2e devs if it is possible to handle in m2e but they
> > > haven't
> > > responded yet.
> > >
> > > /Anders
> > >
> > >
> > > >
> > > > So currently I'm 0 on the voting but I'll investigate some more.
> > > >
> > > > /Anders
> > > >
> > > > On Wed, Sep 13, 2017 at 9:26 AM, Anders Hammar 
> > wrote:
> > > >
> > > >>
> > > >>
> > > >> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
> > > >> stephen.alan.conno...@gmail.com> wrote:
> > > >>
> > > >>> Have we got any feedback from the embedder integrations yet?
> > > >>>
> > > >>
> > > >> I haven't heard anything from the m2e people. Maybe we need to ping
> > them
> > > >> directly. I can contact Fred Bricon.
> > > >>
> > > >> /Anders
> > > >>
> > > >>
> > > >>>
> > > >>> On Mon 11 Sep 2017 at 22:57, Hervé BOUTEMY 
> > > >>> wrote:
> > > >>>
> > > >>> > just for the records: it is Windows + Git Bash (MINGW64) only
> > > >>> >
> > > >>> > and there is a chance that adding -Djansi.force=true can force
> > JAnsi
> > > >>> > activation (even if JAnsi fails to detect that it should
> > auto-activate)
> > > >>> >
> > > >>> > details on issue in https://issues.apache.org/
> jira/browse/MNG-6282
> > ,
> > > >>> and a
> > > >>> > future JAnsi issue...
> > > >>> >
> > > >>> > Regards,
> > > >>> >
> > > >>> > Hervé
> > > >>> >
> > > >>> > Le lundi 11 septembre 2017, 12:53:46 CEST Stephen Connolly a
> écrit
> > :
> > > >>> > > So that is windows only, or were they lost on other OSes for
> you.
> > > >>> > >
> > > >>> > > I have colours on linux (via docker) and os-x
> > > >>> > >
> > > >>> > > On 11 September 2017 at 12:35, dejan2...@gmail.com <
> > > >>> dejan2...@gmail.com>
> > > >>> > >
> > > >>> > > wrote:
> > > >>> > > > +1 (conditionally).
> > > >>> > > >
> > > >>> > > > Tested via project that includes dozen of plugins: 1st tier,
> > > >>> MojoHaus
> > > >>> > and
> > > >>> > > > few 3rd party plugins (so to say).
> > > >>> > > >
> > > >>> > > > Everything looks good with one notable regression:
> > > >>> > > > https://issues.apache.org/jira/browse/MNG-6282 Console
> output
> > has
> > > >>> no
> > > >>> > > > colors (regression in Maven 3.5.1)
> > > >>> > > >
> > > >>> > > > Regards,
> > > >>> > > > Dejan
> > > >>> > > >
> > > >>> > > > On 2017-09-10 17:39, Stephen Connolly <
> > > >>> stephen.alan.conno...@gmail.com
> > > >>> > >
> > > >>> > > >
> > > >>> > > > wrote:
> > > >>> > > > > Hi,
> > > >>> > > > >
> > > >>> > > > > We solved 25 issues:
> > > >>> > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > > >>> > > >
> > > >>> > > > version=12338964=Text=12316922
> > > >>> > > >
> > > >>> > > > > There are 350 issues left in JIRA for Maven core:
> > > >>> > > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > >>> > > >
> > > >>> > > > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> > > >>> > > > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > > >>> > > >
> > > >>> > > > > Staging repo:
> > > >>> > > > > https://repository.apache.org/content/repositories/maven-
> > 

Re: [VOTE] Release Apache Maven 3.5.1

[Mark Derricutt]

> +2 non-binding from Mark!

I was discussing this with a coworker and he made the comment that if this
change could break Mojos, maybe it shouldn't be in a point release - whats
the policy on changes that may potentially break existing plugins?

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

On Thu, Sep 14, 2017 at 10:29 AM, Mark Derricutt <m...@talios.com> wrote:

> On 14 Sep 2017, at 10:26, Mark Derricutt wrote:
>
> Calling -2 for vote if not too late.
>
> Actually - looking at the commit diff, I see in our code we did have
> true for the jasmine-maven-plugin which we don't
> actually need. Removing that from the mojo definition and running my build
> with the staged 3.5.1 release and everything builds fine.
>
> +2 non-binding from Mark!
>
> Mark
> --
>
> "The ease with which a change can be implemented has no relevance at all
> to whether it is the right change for the (Java) Platform for all time." —
> Mark Reinhold.
>
> Mark Derricutt
> http://www.theoryinpractice.net
> http://www.chaliceofblood.net
> http://plus.google.com/+MarkDerricutt
> http://twitter.com/talios
> http://facebook.com/mderricutt
>

Re: [VOTE] Release Apache Maven 3.5.1

[Mark Derricutt]

On 14 Sep 2017, at 10:26, Mark Derricutt wrote:

> Calling -2 for vote if not too late.

Actually - looking at the commit diff, I see in our code we did have 
`true` for the `jasmine-maven-plugin` which we don't 
actually need. Removing that from the mojo definition and running my build with 
the staged 3.5.1 release and everything builds fine.

+2 non-binding from Mark!

Mark


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven 3.5.1

[Mark Derricutt]

Calling -2 for vote if not too late.

Have git bisected from 3.5.0 to HEAD and found the commit that introduced the 
behaviour:

ec629f7d511eb910b4e80112a9fbe85ed8786f10 is the first bad commit
commit ec629f7d511eb910b4e80112a9fbe85ed8786f10
Author: Igor Fedorenko <ifedore...@apache.org>
Date:   Tue Apr 11 07:59:34 2017 -0700

MNG-6209 better executeMojo thread context classloader

Signed-off-by: Igor Fedorenko <ifedore...@apache.org>

:04 04 570fa9308365b0ee98d57ac3f8006691bd9ade4d 
3c6791665c9d41f0e4a3893ea99621cc50e8b91b M  maven-core


Not exactly sure what/why/how this problem manifests in a testable manner yet 
however.

Mark




On 11 Sep 2017, at 23:19, Mark Derricutt wrote:

> On 11 Sep 2017, at 18:10, Stephen Connolly wrote:
>
>> I wonder if mng-6275 is affecting that plugin
>
> Didn't manage to get a chance to look into this tonight :( Tho that ticket 
> mentions nashorn, phantonjs is a C/native headless browser library, so it 
> doesn't feel like it could be related.
>
> If there's a build available with a fix for that, welcome to give it a bash.
>
> I'll try carve out some time in the morning to see if I can make a simple 
> standalone project...
>
> ---
> "The ease with which a change can be implemented has no relevance at all to 
> whether it is the right change for the (Java) Platform for all time."  
> Mark Reinhold.
>
> Mark Derricutt
> http://www.theoryinpractice.net
> http://www.chaliceofblood.net
> http://plus.google.com/+MarkDerricutt
> http://twitter.com/talios
> http://facebook.com/mderricutt


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven 3.5.1

[Mark Derricutt]

On 11 Sep 2017, at 18:10, Stephen Connolly wrote:

> I wonder if mng-6275 is affecting that plugin

Didn't manage to get a chance to look into this tonight :( Tho that ticket 
mentions nashorn, phantonjs is a C/native headless browser library, so it 
doesn't feel like it could be related.

If there's a build available with a fix for that, welcome to give it a bash.

I'll try carve out some time in the morning to see if I can make a simple 
standalone project...

---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven 3.5.1

[Mark Derricutt]

+0 non-commital -

Tested on our tiles/osgi based projects and all seems to work, but for some 
reason - one project that uses the 
org.openqa.selenium.phantomjs.PhantomJSDriverService seems to blowing up when 
using 3.5.1 - need to do some more digging and see if I can spot whats going on.

Will try and dig into this after work tonight.

Mark


On 11 Sep 2017, at 8:01, Arnaud Héritier wrote:

> Tested on several projects
>
> +1
>
> On Sun, Sep 10, 2017 at 5:39 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> Hi,
>>
>> We solved 25 issues:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> version=12338964=Text=12316922
>>
>> There are 350 issues left in JIRA for Maven core:
>> https://issues.apache.org/jira/issues/?jql=project%20%
>> 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
>> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1364/
>>
>> The distributable binaries and sources can be found here:
>> https://repository.apache.org/content/repositories/maven-
>> 1364/org/apache/maven/apache-maven/3.5.1/
>>
>> Specifically the zip, tarball and source archives can be found here:
>> https://repository.apache.org/content/repositories/maven-
>> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.zip
>> https://repository.apache.org/content/repositories/maven-
>> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-bin.tar.gz
>> https://repository.apache.org/content/repositories/maven-
>> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.zip
>> https://repository.apache.org/content/repositories/maven-
>> 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-src.tar.gz
>>
>> Source release checksum(s):
>> apache-maven-3.5.1-src.tar.gz sha1: 9eb821f153c7667194aa11ccd099b7
>> bd2059560d
>> apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab69e698eb0e
>>
>> Git tag:
>> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
>> 094e4e31a5af55bb17be87675da41d9aeca062f3
>>
>> Staging site:
>> https://maven.apache.org/components/ref/3-LATEST/
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> Thanks,
>>
>> Stephen.
>>
>
>
>
> -- 
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven Compiler Plugin version 3.7.0

[Mark Derricutt]

The problems with errorprone have been fixed in the recent 2.1.1 release so
you could update the tests with that maybe?

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

On Sat, Sep 2, 2017 at 11:30 PM, Robert Scholte 
wrote:

> Hi Karl Heinz,
>
> this is a problem with the error-prone-compiler[1], a specific
> implementation of the compiler-api and also where this must be fixed.
> You might wonder if it should be tested here, but now we are at least
> aware that current error-prone-compiler is not Java9 compatible. It should
> not be a blocker for the maven-compiler-plugin itself.
>
> thank,
> Robert
>
> [1] https://github.com/codehaus-plexus/plexus-compiler/tree/mast
> er/plexus-compilers/plexus-compiler-javac-errorprone
>
>
>
> On Sat, 02 Sep 2017 13:23:50 +0200, Karl Heinz Marbaise 
> wrote:
>
> Hi,
>>
>> I have tested the following combinations:
>>
>> jdk1.7.0_79.jdk
>>apache-maven-3.0.5
>>apache-maven-3.1.1
>>apache-maven-3.2.5
>>apache-maven-3.3.1
>>apache-maven-3.3.9
>>apache-maven-3.5.0
>> jdk1.8.0_131.jdk
>>apache-maven-3.0.5
>>apache-maven-3.1.1
>>apache-maven-3.2.5
>>apache-maven-3.3.1
>>apache-maven-3.3.9
>>apache-maven-3.5.0
>> jdk1.8.0_144.jdk
>>apache-maven-3.0.5
>>apache-maven-3.1.1
>>apache-maven-3.2.5
>>apache-maven-3.3.1
>>apache-maven-3.3.9
>>apache-maven-3.5.0
>> jdk1.9.0_ea+181.jdk
>>apache-maven-3.0.5 FAILED!!
>>apache-maven-3.1.1 FAILED!!
>>apache-maven-3.2.5 FAILED!!
>>apache-maven-3.3.1 FAILED!!
>>apache-maven-3.3.9 FAILED!!
>>apache-maven-3.5.0 FAILED!!
>>
>>
>> But the JDK1.9.0_ea+181 have show the following result (for all Maven
>> versions):
>>
>> [ERROR] Failed to execute goal 
>> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile
>> (default-compile) on project error-prone-compiler: Fatal error compiling:
>> CompilerException: InvocationTargetException: 
>> java.nio.file.NotDirectoryException:
>> /Library/Java/JavaVirtualMachines/jdk1.9.0_ea+181.jdk/Contents/Home/lib/modules
>> -> [Help 1]
>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed
>> to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile
>> (default-compile) on project error-prone-compiler: Fatal error compiling
>> at org.apache.maven.lifecycle.int
>> ernal.MojoExecutor.execute(MojoExecutor.java:217)
>> at org.apache.maven.lifecycle.int
>> ernal.MojoExecutor.execute(MojoExecutor.java:153)
>> at org.apache.maven.lifecycle.int
>> ernal.MojoExecutor.execute(MojoExecutor.java:145)
>> at org.apache.maven.lifecycle.int
>> ernal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>> at org.apache.maven.lifecycle.int
>> ernal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>> at org.apache.maven.lifecycle.int
>> ernal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>> at org.apache.maven.lifecycle.int
>> ernal.LifecycleStarter.execute(LifecycleStarter.java:161)
>> at org.apache.maven.DefaultMaven.
>> doExecute(DefaultMaven.java:320)
>> at org.apache.maven.DefaultMaven.
>> execute(DefaultMaven.java:156)
>> at org.apache.maven.cli.MavenCli.
>> execute(MavenCli.java:537)
>> at org.apache.maven.cli.MavenCli.
>> doMain(MavenCli.java:196)
>> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
>> at java.base/jdk.internal.reflect
>> .NativeMethodAccessorImpl.invoke0(Native Method)
>> at java.base/jdk.internal.reflect
>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at java.base/jdk.internal.reflect
>> .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso
>> rImpl.java:43)
>> at java.base/java.lang.reflect.Me
>> thod.invoke(Method.java:564)
>> at org.codehaus.plexus.classworld
>> s.launcher.Launcher.launchEnhanced(Launcher.java:290)
>> at org.codehaus.plexus.classworld
>> s.launcher.Launcher.launch(Launcher.java:230)
>> at org.codehaus.plexus.classworld
>> s.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>> at org.codehaus.plexus.classworld
>> s.launcher.Launcher.main(Launcher.java:352)
>> Caused by: org.apache.maven.plugin.MojoExecutionException: Fatal
>> error compiling
>> at org.apache.maven.plugin.compil
>> er.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1086)
>> at org.apache.maven.plugin.compil
>> er.CompilerMojo.execute(CompilerMojo.java:168)
>> at org.apache.maven.plugin.Defaul
>> tBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>> at org.apache.maven.lifecycle.int
>> 

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

[Mark Derricutt]

+1 from me. Tested on JDK9 without any changes to dependencies - works a treat.

Reverted back to 3.0.0 in test and observed the failing build. So bring on the 
new release!


On 30 Aug 2017, at 22:51, Robert Scholte wrote:

> Hi,
>
> We solved 4 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319223=12341415=Text
>
> There is still one issue left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012319223%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1358/
> https://repository.apache.org/service/local/repositories/maven-1358/content/org/apache/maven/plugins/maven-jdeps-plugin/3.1.0/maven-jdeps-plugin-3.1.0-source-release.zip
>
> Source release checksum(s):
> maven-jdeps-plugin-3.1.0-source-release.zip sha1: 
> 25a568612b63d25a76e554e622624bffc1f2eece
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: maven-jdeps-plugin and JDK9 - no love :(

[Mark Derricutt]

On 28 Aug 2017, at 22:07, Robert Scholte wrote:

> Can you share these 23? Maybe worth sharing at <https://s.apache.org/maven-j9>

Ack - I was meaning to write 23 DAYS on the countdown ( at 
http://www.java9countdown.xyz/ )

Mark


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: maven-jdeps-plugin and JDK9 - no love :(

[Mark Derricutt]

On 28 Aug 2017, at 18:11, Enrico Olivelli wrote:

> Mark,
> IMHO It seems just a 'well known' problem of commons lang. Maybe just
> updating the dependency for the plugin in your pom may help.

Sweet that worked - will go raise a ticket about it so we can get a PR made and 
another release...

23 on the countdown to Java 9 :)

Mark


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

maven-jdeps-plugin and JDK9 - no love :(

[Mark Derricutt]

ng.substring(String.java:1885)
at 
org.apache.commons.lang.SystemUtils.getJavaVersionAsFloat(SystemUtils.java:1133)
at org.apache.commons.lang.SystemUtils.(SystemUtils.java:818)
... 24 more
```

Looks like the version comparison is biting this plugin as well. What was the 
solution to this in the other plugins? An alternate means of comparing/getting 
the java version?

Mark




---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

What became of Aether/Ant tasks...

[Mark Derricutt]

Hey all,

Now that Aether has moved it's way back to Apache as the Maven Resolver, what's 
become of the Aether/Ant taks?

https://wiki.eclipse.org/Aether/Ant_Tasks

Mark


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Using "annotationProcessorPaths" together with version ranges

[Mark Derricutt]

On 24 Aug 2017, at 9:49, Andreas Gudian wrote:

> Yupp, I'm afraid neither version ranges nor information from any
> dependencyManagement sections are considered.
>
> Only the plain versions or properties work, and transitive dependencies are
> pulled in

Yeh, we use properties as a workaround here - we actually resolve our ranges 
external to Maven - in a `pom.deps` files, which in part is used to bootstrap 
version properties ( the actual `pom.xml` files get there `` elements 
of plugins/dependencies rewritten to hard locked `[xxx]` versions as well.

Also since we shared compiler plugin settings across projects, it means I have 
to list all possible combinations of annotationProcessors we know we support ( 
which is not many, but would be nice to control per project ).

Mark


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Using "annotationProcessorPaths" together with version ranges

[Mark Derricutt]

On 17 Aug 2017, at 19:33, Cristian Spiescu wrote:

> When using maven-compiler-plugin with "annotationProcessorPaths", and I 
> specify a dependency with a version range: it doesn't seem to work. I have 
> done some debugging, and I see that the general dependency solving mechanism 
> (that does

I really wish we could have a new 'annotation' scope and NOT use 
'annotationProcessorPaths', it makes things really ik to work with when using 
parents/tiles and common compiler plugin settings.

Interestingly, the DTD doesn't actually specify a strict set of scopes, and 
neither does the documentation it seems.

Mark

---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [ANN] MMaven Resolver 1.1.0 released

[Mark Derricutt]

On 7 Jul 2017, at 13:34, Mark Derricutt wrote:

> when running out of Maven 3.5. Odd thing is - it happened 3 times, and now I 
> can't reproduce it. Bizarre...

Actually can reproduce it all the time down, I was running my build in slightly 
different ways between tests, when adding -U to for SNAPSHOT updates my mojo 
kicks in a different way and forces the resolver to resolve, and we hit this.


---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [ANN] MMaven Resolver 1.1.0 released

[Mark Derricutt]

On 7 Jul 2017, at 8:47, Michael Osipov wrote:

>
> Release Notes - Maven Resolver - Version Maven Artifact Resolver 1.1.0
> ** Bug
> * [MRESOLVER-13] - Exceptions are suppressed incorrectly when closing 
> resources fails
> * [MRESOLVER-19] - DefaultRepositorySystem resolveDependencies() can 
> yield a NullPointerException

Ewps - somehow I pre-emptively sent the message accidentally.

Interesting, updating one of my mojos which use this to 1.1.0 and I get:

Exception in thread "main" java.lang.NoSuchMethodError: 
org.eclipse.aether.transfer.TransferResource.(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/io/File;Lorg/eclipse/aether/RequestTrace;)V
at 
org.eclipse.aether.connector.basic.BasicRepositoryConnector.newTransferResource(BasicRepositoryConnector.java:309)
at 
org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:239)
at 
org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:529)
at 
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:430)
at 
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:255)
at 
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:232)
at 
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:268)

when running out of Maven 3.5. Odd thing is - it happened 3 times, and now I 
can't reproduce it.  Bizarre...



---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [ANN] MMaven Resolver 1.1.0 released

[Mark Derricutt]

On 7 Jul 2017, at 8:47, Michael Osipov wrote:

>
> Release Notes - Maven Resolver - Version Maven Artifact Resolver 1.1.0
> ** Bug
> * [MRESOLVER-13] - Exceptions are suppressed incorrectly when closing 
> resources fails
> * [MRESOLVER-19] - DefaultRepositorySystem resolveDependencies() can 
> yield a NullPointerException

Interesting, updating one of my mojo which use this to 1.1.0 and I get:



---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [RESULT] [VOTE] Release Apache Maven Enforcer version 1.4.2

[Mark Derricutt]

On 23 Jun 2017, at 7:48, Stephen Connolly wrote:

> Ok, I'm dropping this and respinning as 3.0.0

Does 1.4.2/3.0.0 work with Java 9?

I was just testing a build and hit:

Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
com.smxemail.tiles:com.smxemail.tiles.enforcements:3.0.64::enforce-versions of 
goal org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce failed: An 
API incompatibility was encountered while executing 
org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce: 
java.lang.ExceptionInInitializerError: null



at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:181)
... 21 more
Caused by: java.lang.ExceptionInInitializerError
at 
org.apache.maven.plugins.enforcer.RequireJavaVersion.execute(RequireJavaVersion.java:52)
at 
org.apache.maven.plugins.enforcer.EnforceMojo.execute(EnforceMojo.java:193)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
... 21 more
Caused by: java.lang.StringIndexOutOfBoundsException: begin 0, end 3, length 1
at java.base/java.lang.String.checkBoundsBeginEnd(String.java:3116)
at java.base/java.lang.String.substring(String.java:1885)
at 
org.apache.commons.lang.SystemUtils.getJavaVersionAsFloat(SystemUtils.java:1122)
at org.apache.commons.lang.SystemUtils.(SystemUtils.java:818)
... 24 more


I guess the version of commons-lang used doesn't like the new Java 9 version 
string.




---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven 3.5.0

[Mark Derricutt]

+1 Non Binding.

Bring. It. On.


On 4 Apr 2017, at 10:14, Stephen Connolly wrote:

> Hi,
>
> We solved 86 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12336084=Text

-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: All go for 3.5.0

[Mark Derricutt]

On 2 Apr 2017, at 2:02, Stephen Connolly wrote:

> If anyone wants to take some final manual testing of core, please do so as
> my plan is to shoot direct for 3.5.0 rather than spinning RCs... this means
> if there's a blocker then it will be on to 3.5.1

Latest nightly builds all seem good on my OSGi/Tiles/freak-of-unholy-nature 
builds :)


-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven 3.5.0-beta-1

[Mark Derricutt]

On 21 Mar 2017, at 7:18, Stephen Connolly wrote:

> Vote open for 72 hours.

+1 non binding for me on my OSGi / tiles related builds.


-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: rat-check failures...

[Mark Derricutt]

On 22 Mar 2017, at 17:38, Olivier Lamy wrote:

> maven-aether-provider has been moved to maven-resolver-provider
> so simply delete maven-aether-provider directory first (git didn't clean
> target directory)

Ah so it did. All good now :)


-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

rat-check failures...

[Mark Derricutt]

Hey all,

I was about to start testing the beta-1 release when I noticed my nightly 
snapshots were out of date by a month or so (not so nightly ).

Looking at my builds I see:


[ERROR] Failed to execute goal org.apache.rat:apache-rat-plugin:0.11:check 
(rat-check) on project maven: Too many files with unapproved license: 29 See 
RAT report in: /Users/amrk/IdeaProjects/upstream/maven/target/rat.txt -> [Help 
1]

This is with a HEAD of `27ab7503a7196a` with a message of "[MNG-6190] 
maven-resolver-provider's DefaultArtifactDescriptorReader has mismatched 
constructor and initService methods".


Looking at the rat report I see 'maven-aether-provider' seems to be a problem?

Unapproved licenses:

  maven-aether-provider/target/.plxarc
  maven-aether-provider/target/checkstyle-cachefile
  maven-aether-provider/target/checkstyle-header.txt
  maven-aether-provider/target/checkstyle-result.xml
  maven-aether-provider/target/classes/META-INF/plexus/components.xml
  maven-aether-provider/target/components.xml
  
maven-aether-provider/target/local-repo/org/apache/maven/its/dep-mng5324/07.20.3-SNAPSHOT/resolver-status.properties
  
maven-aether-provider/target/local-repo/org/apache/maven/its/dep-mng5459/0.4.0-SNAPSHOT/resolver-status.properties
  
maven-aether-provider/target/local-repo/ut/simple/artifact/1.0/_remote.repositories
  
maven-aether-provider/target/local-repo/ut/simple/dependency/1.0/_remote.repositories
  
maven-aether-provider/target/local-repo/ut/simple/parent/1.0/_remote.repositories
  
maven-aether-provider/target/maven-status/maven-compiler-plugin/compile/default-compile/createdFiles.lst
  
maven-aether-provider/target/maven-status/maven-compiler-plugin/compile/default-compile/inputFiles.lst
  
maven-aether-provider/target/maven-status/maven-compiler-plugin/testCompile/default-testCompile/createdFiles.lst
  
maven-aether-provider/target/maven-status/maven-compiler-plugin/testCompile/default-testCompile/inputFiles.lst
  maven-aether-provider/target/rat.txt
  
maven-aether-provider/target/surefire-reports/org.apache.maven.repository.internal.DefaultArtifactDescriptorReaderTest-output.txt
  
maven-aether-provider/target/surefire-reports/org.apache.maven.repository.internal.DefaultArtifactDescriptorReaderTest.txt
  
maven-aether-provider/target/surefire-reports/org.apache.maven.repository.internal.DefaultVersionResolverTest-output.txt
  
maven-aether-provider/target/surefire-reports/org.apache.maven.repository.internal.DefaultVersionResolverTest.txt
  
maven-aether-provider/target/surefire-reports/org.apache.maven.repository.internal.MavenRepositorySystemUtilsTest.txt
  
maven-aether-provider/target/surefire-reports/org.apache.maven.repository.internal.RemoteSnapshotMetadataTest.txt
  
maven-aether-provider/target/surefire-reports/org.apache.maven.repository.internal.RepositorySystemTest-output.txt
  
maven-aether-provider/target/surefire-reports/org.apache.maven.repository.internal.RepositorySystemTest.txt
  
maven-aether-provider/target/surefire-reports/TEST-org.apache.maven.repository.internal.DefaultArtifactDescriptorReaderTest.xml
  
maven-aether-provider/target/surefire-reports/TEST-org.apache.maven.repository.internal.DefaultVersionResolverTest.xml
  
maven-aether-provider/target/surefire-reports/TEST-org.apache.maven.repository.internal.MavenRepositorySystemUtilsTest.xml
  
maven-aether-provider/target/surefire-reports/TEST-org.apache.maven.repository.internal.RemoteSnapshotMetadataTest.xml
  
maven-aether-provider/target/surefire-reports/TEST-org.apache.maven.repository.internal.RepositorySystemTest.xml

***

Archives:

 + 
maven-aether-provider/target/local-repo/ut/simple/artifact/1.0/artifact-1.0-classifier.zip
 + 
maven-aether-provider/target/local-repo/ut/simple/artifact/1.0/artifact-1.0.jar
 + 
maven-aether-provider/target/local-repo/ut/simple/artifact/1.0/artifact-1.0.zip
 + maven-aether-provider/target/maven-aether-provider-3.5.0-SNAPSHOT.jar
 + 
maven-aether-provider/target/test-classes/repo/ut/simple/artifact/1.0/artifact-1.0-classifier.zip
 + 
maven-aether-provider/target/test-classes/repo/ut/simple/artifact/1.0/artifact-1.0.jar
 + 
maven-aether-provider/target/test-classes/repo/ut/simple/artifact/1.0/artifact-1.0.zip
 + 
maven-aether-provider/target/test-classes/repo/ut/simple/dependency/1.0/dependency-1.0-sources.jar
 + 
maven-aether-provider/target/test-classes/repo/ut/simple/dependency/1.0/dependency-1.0.jar



**Mark Derricutt** | Senior Developer
**Phone**: +64 9 302 0515 Fax: +64 9 302 0518
**Mobile**: +64 21 562 533 Freephone: 0800 SMX SMX (769 769)
**Twitter**: @talios
**SMX Limited**: Level 15, 19 Victoria Street West, Auckland, New Zealand
**Web**: http://smxemail.com

![Cloud Email Hosting & Security](http://smxemail.com/images/smxsig.png)


signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven 3.5.0-alpha-1

[Mark Derricutt]

On 28 Feb 2017, at 7:11, Hervé BOUTEMY wrote:

> I already voted, but I'll redo:
>
> +1

+200 from me :)


-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: I think we are ready for 3.5.0-alpha-1

[Mark Derricutt]

On 9 Feb 2017, at 9:01, Stephen Connolly wrote:

> I toyed with spinning RCs but I'm thinking alpha and beta are better terms

Have been using the nightly builds without issue on our projects - no perceived 
issues anywhere so far.

Can I preload a +1? :)

-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

[Mark Derricutt]

On 5 Jan 2017, at 1:16, Stephen Connolly wrote:

> As this involves a --force push on the `master` branch, we want to get the
> approval of the committers before continuing.

You _could_ branch at the point you want to reset to, then use an ours/theirs 
merge strategy which creates a merge commit that ONLY takes one side.  
Effectively resetting, keeping the fact we did this reversal, and doesn't force 
everyone to re-clone.

From https://git-scm.com/docs/merge-strategies:

**ours:** This resolves any number of heads, but the resulting tree of the 
merge is always that of the current branch head, effectively ignoring all 
changes from all other branches. It is meant to be used to supersede old 
development history of side branches. Note that this is different from the 
-Xours option to the 'recursive' merge strategy.

Would something like this be better than force pushing?

-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: POM 5: The problems with mixins

[Mark Derricutt]

On 6 Dec 2016, at 4:17, Jochen Wiedmann wrote:

> You have personal experience with a feature, that doesn't even exist?
> I am impressed...

I need to read thru this thread fully and write up a longer response - but 
we've been using the tiles plugin ( which myself and Richard Vowles took over ) 
to provide mixin like behaviour to Maven and despite a few minor teething 
issues, it works wonderfully.

The win - composition and reuse. The simple static inheritance chain doesn't 
really provide that.

Mark

-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Mark Derricutt]

On 26 Aug 2016, at 22:07, Tibor Digana wrote:

> One or two years ago I watched mvn dev hangouts videos with Jason and

Were they really that long ago? Wow.  I was actually thinking about them the 
other day, wondering when/why they petered out, I ended up having to stop 
joining due to timezone issues ( it conflicted with my morning commute to work 
) but enjoyed the discussions.

Mark

-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Mark Derricutt]

On 17 Aug 2016, at 12:32, Christian Schulte wrote:

> There is an easy way to solve this. Maven validates the model version in
> the POM to match "4.0.0". Based on that version, Maven can decide how to
> behave. I am thinking about introducing model version "4.1.0" in Maven
> 3.4. All existing 4.0.0 POMs will work the same way as before. Model

Would the deployed POM be a 4.1.0 or 4.0.0 Model? I seem to recall a long time 
ago when we were doing the Google Hangouts discussions about a mental 
separation of build/deploy POM.

If deployed as 4.1.0 then you'd be forcing all consumers of that dependency to 
use Maven 3.4.0 itself ( IMHO not in itself a bad idea ), but that might hurt 
any consuming applications like Sonar, Jenkins, or other build tools.



-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Mark Derricutt]

On Sat, Jul 23, 2016 at 3:27 AM, Karl Heinz Marbaise 
wrote:

> This is only a current state of development (Git hash:
> 90f26c279af9738735be8f84f60dcf21b6244e24) to get some feedback from the
> community...
>

Have been using daily HEAD builds as my daily driver for the past few
weeks, so far no issues on any of our projects, so here's my pre-emptive +2
:)

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: Support for Java 9 builds?

[Mark Derricutt]

On 9 Jul 2016, at 10:29, Robert Scholte wrote:

> However, looking at the stacktrace this doesn't seem to be the issue for you.
> It probably has to do with the calculation of the java version, which is 
> already fixed.
> So please add a newer version of plexus-archiver to the maven-javadoc-plugin 
> and verify if this works.

Thats works!  Also had to bump the javadoc plugin to .4 ( I was still using .3 
) - excellent.


-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: 3.4.0 SNAPSHOT breaks Log4j build

[Mark Derricutt]

On Thu, Jul 7, 2016 at 8:21 AM, Ralph Goers 
wrote:

> With scope set to test I would expect that the non-test classes that need
> them would fail to compile.


Sadly this falls into one of my biggest pet-peeves with maven. IMHO neither
compile or test scope should ever be transitive. Sadly, such a change would
break 99% of central - the only work around to that IMHO would be a
different scope, say "build" that literally meant, this dep is solely for
building THIS project ( ideally, also a scope for annotation processors,
rather than messing with the compiler plugin ).

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: MNG-4883

[Mark Derricutt]

On 5 Jul 2016, at 8:37, Stephen Connolly wrote:

> 1.0 is just a hint, hints can be overridden
> [1.0] is a hard requirement

The later also forces maven to download the metadata, and check the version 
exists in said metadata, which - even if its in the repository, but the 
meta-data is broken ( and that, sadly, happens often ), then you can't even 
download the dependency.



-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Maven plugin - some licensing questions

[Mark Derricutt]

When I was writing my LifecycleExtension recently I hit this same issue,
with the two different logger classes depending on where my common code was
being called from.

I just changed my base code to accept a Consumer and passed in
getLog()::info and the relevant other method from the other logger as
method references. Worked a charm in my small use case anyway.

On Sat, Jul 2, 2016 at 12:35 AM, Grzegorz Słowikowski <
gslowikow...@gmail.com> wrote:

> I didn't want to depend on 'maven-embedder', so my first thought was to
> copy this class, change 'org.slf4j.Logger' class of the 'logger'
> variable to 'org.apache.maven.plugin.logging.Log', I have (in
> 'AbstractMojo')
>
> Advantage - I control the class
> Disadvantages - e.g. no colors in future Maven versions (because using
> class from Maven not supporting colors yet), licensing questions
>



-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: Roadmap Maven 3.4.0

[Mark Derricutt]

On 16 Jun 2016, at 8:42, Uwe Barthel wrote:

> The custom implementation could be placed in {maven.home}/lib/ext or maybe 
> also as extension in .mvn/ per project.

Hmm, this is actually want I want to do ( re my post on problems with lifecycle 
extensions ).  But was told that ./mvn extensions should not change the 
behaviour of the build.  I guess this change is allowing for changing that idea 
tho.

We have an extension in .mvn/extensions that loads/sets user properties to be 
used in the pom, IntelliJ doesn't recognise any of those properties tho, so 
resolution/project loading breaks.  If you're going also change resolution via 
a .mvn/extension.xml entry, quite possibly IntelliJ will ignore that as well.

Mark


-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Maven Embedder and Lifecycle extensions

[Mark Derricutt]

On 15 Jun 2016, at 23:30, Igor Fedorenko wrote:


extensions.xml was meant for "non-functional" extensions, things like
Takari SmartBuilder, which improves multi-threaded build scheduling 
but



does not affect overall build results. If your extensions change build
behaviour in non-trivial ways, your build is not Maven any more and 
you

should expect to have to change tooling around the build.


Thing is, it is changing it in a trivial way - it just sets user 
properties, we're just wanting to externalise the `` 
definition from the pom.xml file.


Ideally I'd much rather put it in:



or a

true

block but it seems neither of those options want to run with 
`afterProjectsRead`, however - even if it did - by that stage the 
project has been read and variables already interpolated, which is why I 
was looking at afterSessionStart - only, the only way for that to run is 
from `.mvn/extensions.xml`.


Unless there's another way I could intercept POM reading and resolve 
properties - in a "maven safe" manner.


Mark

--
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt