[ANN] Apache Maven Build cache extension

[Olivier Lamy]

The Apache Maven team is pleased to announce the release of the Apache
Maven Build cache extension, version 1.2.0

Build cache is an extension that makes large Maven builds more efficient.

A combination of features achieves that:
- Incremental builds work on the modified part of the project graph part only
- Project state restoration (partial) avoids repeating expensive tasks
like code generation
- etc...

More details available:
https://maven.apache.org/extensions/maven-build-cache-extension/

You can look at the configuration to use it:
https://maven.apache.org/extensions/maven-build-cache-extension/getting-started.html


Release Notes - Maven Build Cache Extension - Version 1.2.0

** Bug
* [MBUILDCACHE-76] - pom project version change not detected
* [MBUILDCACHE-79] - MBUILDCACHE-67 broke the partial restore process
* [MBUILDCACHE-80] - Incremental builds with a higher goal than
the highest cached goal is rebuilding the full project from scratch
* [MBUILDCACHE-81] - Add an option to include project version as
part of the cache hash key
* [MBUILDCACHE-88] - Tests in failure when ran on jdk21

** New Feature
* [MBUILDCACHE-90] - Configuration option to make mandatory the
use of the clean phase in order to cache the build result
* [MBUILDCACHE-93] - Command line configuration to disable saving in cache

** Improvement
* [MBUILDCACHE-71] - buildinfo.xml should be stored after storing
the project's artifacts
* [MBUILDCACHE-86] - Bugfix and enhancements with the restoration
of outputs on disk

Enjoy,

-The Apache Maven team

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

[ANN] Apache Maven Toolchains Plugin 3.2.0

[Olivier Lamy]

The Apache Maven team is pleased to announce the release of the Apache
Maven Toolchains Plugin, version 3.2.o

The Toolchains Plugins enable sharing tool configuration across
plugins. For example, to make sure that plugins like compiler,
surefire, and javadoc all use the same JDK for execution,
independently from JRE used to run Maven itself.

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

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


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


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

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

Release Notes - Maven Toolchains Plugin - Version 3.2.0

** Improvement
* [MTOOLCHAINS-49] - Automatic discovery of JDK toolchains

** Bug
* [MTOOLCHAINS-41] - Broken link to JDK toolchain version range definitions

** Task
* [MTOOLCHAINS-43] - Cleanup - Pom

** Dependency upgrade
* [MTOOLCHAINS-42] - Upgrade maven-plugin parent to 37
* [MTOOLCHAINS-45] - Upgrade maven-plugin parent to 39
* [MTOOLCHAINS-50] - Upgrade to maven parent 41
* [MTOOLCHAINS-51] - Upgrade to maven 3.9.6 at compile time and
3.6.3 at runtime

Enjoy,

-The Apache Maven team

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

[ANN] Apache Maven Invoker Plugin 3.6.1 Released

[Olivier Lamy]

Hi
The Apache Maven team is pleased to announce the release of the Apache
Maven Invoker Plugin, version 3.6.1

The Invoker Plugin is used to run a set of Maven projects. The plugin
can determine whether each project execution is successful and can
optionally verify the output generated from a given project execution.

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

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


  org.apache.maven.plugins
  maven-invoker-plugin
  3.6.1


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

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

Release Notes - Maven Invoker Plugin - Version 3.6.1

** Improvement
* [MINVOKER-352] - Remove usage commons-lang3

** Task
* [MINVOKER-355] - Update Groovy 4.0.18 to 4.0.20 to support jdk22
* [MINVOKER-356] - Various dependencies update via dependabot see
release notes on github

Enjoy,

-The Apache Maven team

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

Re: Build a maven-plugin on JDK-22 with Maven 3.9.6

[Olivier Lamy]

Sorry  for the confusion but you simply need to upgrade
maven-plugin-tools version in your pom as last  version already
include the upgraded asm version
It's usually a good practice to declare in your pom every plugins you are using.

On Mon, 4 Mar 2024 at 16:07, Olivier Lamy  wrote:
>
> actually this need a version of this
> https://github.com/apache/maven-plugin-tools which have the necessary
> upgrade of asm. (maybe you can test locally a snapshot to be sure it
> works)
> But bear in mind if you are using maven-invoker-plugin with some
> groovy scripts to verify, you will have some issues as last time I
> checked (few weeks ago) groovy didn't support yet a new version of
> asm.
> And sadly this is shaded within groovy jars so there is no way to
> override this :(
>
> On Mon, 4 Mar 2024 at 15:38, Sergi Vladykin  wrote:
> >
> > Hi,
> >
> > I'm trying to build a maven plugin with JDK-22
> > and DefaultMojoAnnotationsScanner fails with
> >
> > Caused by: java.lang.IllegalArgumentException: Unsupported class file major
> > version 66
> > at org.objectweb.asm.ClassReader. (ClassReader.java:199)
> >
> > I'm specifically trying to test the Java 22 release version, with 21 it
> > works fine.
> >
> > JDK-22 is going to be released in a couple of weeks, is there plan to
> > support it in Maven 3?
> >
> > Thanks!
> > Sergei

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

Re: Build a maven-plugin on JDK-22 with Maven 3.9.6

[Olivier Lamy]

actually this need a version of this
https://github.com/apache/maven-plugin-tools which have the necessary
upgrade of asm. (maybe you can test locally a snapshot to be sure it
works)
But bear in mind if you are using maven-invoker-plugin with some
groovy scripts to verify, you will have some issues as last time I
checked (few weeks ago) groovy didn't support yet a new version of
asm.
And sadly this is shaded within groovy jars so there is no way to
override this :(

On Mon, 4 Mar 2024 at 15:38, Sergi Vladykin  wrote:
>
> Hi,
>
> I'm trying to build a maven plugin with JDK-22
> and DefaultMojoAnnotationsScanner fails with
>
> Caused by: java.lang.IllegalArgumentException: Unsupported class file major
> version 66
> at org.objectweb.asm.ClassReader. (ClassReader.java:199)
>
> I'm specifically trying to test the Java 22 release version, with 21 it
> works fine.
>
> JDK-22 is going to be released in a couple of weeks, is there plan to
> support it in Maven 3?
>
> Thanks!
> Sergei

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

Re: Publishing to Maven Central and non-OSS plugin dependencies

[Olivier Lamy]

users will not be able to rebuild from sources.
is it a requirement? No real idea as already said in this thread, you
need to ask Sonatype.
But it breaks the concept of opensource as you cannot build from the sources :)

On Fri, 1 Mar 2024 at 02:25, Florent Biville  wrote:
>
> The real plugin is com.mycila:license-maven-plugin
>  and the non-OSS
> dependency brings a bunch of extra resources (authorized licenses,
> headers...).
>
> On Thu, Feb 29, 2024 at 2:14 PM Slawomir Jaranowski 
> wrote:
>
> > I can not fine mentioned plugin at all ...
> > https://repo.maven.apache.org/maven2/com/acme/
> >
> > What does it do ...?
> > Is it needed for the build project?
> > Can it be executed in profile?
> > Can it be replaced by something else ...?
> >
> > I will think about publishing projects which can not be build by outer
> > users, can not be a reproducible build check and so on ...
> >
> > So I would like to not publish something like this...
> >
> >
> >
> > czw., 29 lut 2024 o 13:41 Florent Biville 
> > napisał(a):
> >
> > > Yes, to clarify, our project has something like this:
> > >
> > > 
> > > com.acme.plugin
> > > plugin
> > > 4.2.42
> > > 
> > > 
> > > com.acme.plugin
> > > plugin-dep
> > > 42.4.2
> > > 
> > > 
> > > 
> > >
> > >
> > > On Thu, Feb 29, 2024 at 1:33 PM Tamás Cservenák 
> > > wrote:
> > >
> > > > Howdy,
> > > >
> > > > You would need to ask Sonatype about that, and check here:
> > > > https://central.sonatype.org/publish/requirements/
> > > >
> > > > IMHO best to ask them about it: IIUC you want to deploy artifacts to
> > > > central that has dependencies not available from Central
> > > > (nor any other public repository?)
> > > >
> > > > Thanks
> > > > T
> > > >
> > > >
> > > >
> > > > On Thu, Feb 29, 2024 at 1:31 PM Florent Biville <
> > > florent.bivi...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I'm working on an open-source project that we want to release to
> > Maven
> > > > > Central in the coming weeks.
> > > > >
> > > > > The project currently includes a plugin dependency that is NOT
> > > > open-source
> > > > > (nor in a public GitHub repository). Is that a blocker for releases
> > to
> > > > > Maven Central? I know it would be for regular dependencies and
> > plugins,
> > > > but
> > > > > I'm not 100% sure about plugin dependencies in particular (although I
> > > > would
> > > > > guess it's the same).
> > > > >
> > > > > Any input would be appreciated,
> > > > >
> > > > > Best regards,
> > > > > Florent
> > > > >
> > > >
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >

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

Re: Strange behavior using maven build-cache extension in maven-release-plugin goals

[Olivier Lamy]

interesting.
is the deploy goal executed twice as well when you run "mvn deploy"?
(as you marked as it as alwaysRun)

On Sun, 21 Jan 2024 at 23:00, Javier Gómez  wrote:
>
> Hi all,
>
> We are starting to apply the build-cache maven extension in our local and CI 
> environment,  and we have seen strange behavior in several maven projects, 
> when using the release plugin in conjunction with build-cache, which we have 
> been able to reproduce both locally and in CI.
>
> Our usual release plugin configuration is:
>
> 
>   org.apache.maven.plugins
>   maven-release-plugin
>   3.0.0
>   
> -DskipEnforceSnapshots -DskipITs -DskipTests 
> -DskipUTs
> deploy
> 
> SemVerVersionPolicy
> GithubReleaseStrategy
> @{prefix} Prepare release 
> @{releaseLabel}
> @{prefix} Prepare for next 
> development iteration
> @{project.version}
>   
>
> When we add the build-cache extension to the project, and execute the release 
> with: mvn release:prepare release:perform -DreleaseVersion=x.y.z we can 
> observe a strange behavior when maven is launching the release:perform goal, 
> we see that the deploy goal is executed 2 times for each artifact (in fact it 
> seems that the maven lifecycle restarts, once it reaches the deploy and 
> begins to execute the validate again) and when it reaches the 2nd execution 
> of deploy, it fails (since the user we use do not have permissions to 
> overwrite artifacts). Below I show an extract from the log:
>
> ...
>
> [INFO] [INFO] 
> 
> [INFO] [INFO] Reactor Build Order:
> [INFO] [INFO]
> [INFO] [INFO] temp.mectagcore:mectagcore [pom]
> [INFO] [INFO] temp.mectagcore:mectagcore-domain  [jar]
> [INFO] [INFO] temp.mectagcore:mectagcore-boot[jar]
> [INFO] [INFO] temp.mectagcore:jacoco-report-aggregate[pom]
> [INFO] [INFO]
> [INFO] [INFO] -< temp.mectagcore:mectagcore >-
> [INFO] [INFO] Building temp.mectagcore:mectagcore 1.0.0  [1/9]
> [INFO] [INFO]   from pom.xml
> [INFO] [INFO] [ pom 
> ]-
> [INFO] [INFO] Going to calculate checksum for project 
> [groupId=temp.mectagcore, artifactId=mectagcore]
> [INFO] [INFO] Project inputs calculated in 12 ms. SHA-256 checksum 
> [16534757c14aae9b1ff1961664995f0e7e9396fb88309d207a8a23c080c7f661] calculated 
> in 4 ms.
> [INFO] [INFO] Attempting to restore project temp.mectagcore:mectagcore from 
> build cache
> [INFO] [INFO] Local build found by checksum 
> 16534757c14aae9b1ff1961664995f0e7e9396fb88309d207a8a23c080c7f661
> [INFO] [INFO] Found cached build, restoring temp.mectagcore:mectagcore from 
> cache by checksum 
> 16534757c14aae9b1ff1961664995f0e7e9396fb88309d207a8a23c080c7f661
> [INFO] [INFO] Project temp.mectagcore:mectagcore restored partially. Highest 
> cached goal: verify, requested: deploy
> [INFO] role: 'org.apache.maven.plugin.Mojo', implementation: 
> 'org.apache.maven.plugin.failsafe.IntegrationTestMojo', role hint: 
> 'org.apache.maven.plugins:maven-failsafe-plugin:3.0.0:integration-test'
> [INFO] role: 'org.apache.maven.plugin.Mojo', implementation: 
> 'org.apache.maven.plugin.failsafe.VerifyMojo', role hint: 
> 'org.apache.maven.plugins:maven-failsafe-plugin:3.0.0:verify'
> [INFO] ---
> [INFO] [INFO] Skipping plugin execution (cached): enforcer:enforce
> [INFO] [INFO] Skipping plugin execution (cached): enforcer:enforce
> [INFO] [INFO] Skipping plugin execution (cached): build-helper:add-source
> [INFO] [INFO] Mojo execution is forced by project property: 
> amiga-assembly:amiga-assembly
> [INFO] [INFO]
> [INFO] [INFO] --- amiga-assembly:5.5.0:amiga-assembly 
> (amiga-assembly-execution) @ mectagcore ---
> [INFO] [INFO] Mojo execution is forced by project property: source:jar-no-fork
> [INFO] [INFO]
> [INFO] [INFO] --- source:3.2.1:jar-no-fork (attach-sources) @ mectagcore ---
> [INFO] [INFO] Skipping plugin execution (cached): failsafe:integration-test
> [INFO] [INFO] Skipping plugin execution (cached): failsafe:verify
> [INFO] [INFO]
> [INFO] [INFO] --- install:3.1.1:install (default-install) @ mectagcore ---
> [INFO] role: 'org.apache.maven.plugin.Mojo', implementation: 
> 'org.apache.maven.plugins.install.InstallMojo', role hint: 
> 'org.apache.maven.plugins:maven-install-plugin:3.1.1:install'
> [INFO] role: 'org.apache.maven.plugin.Mojo', implementation: 
> 'org.apache.maven.plugins.install.InstallFileMojo', role hint: 
> 'org.apache.maven.plugins:maven-install-plugin:3.1.1:install-file'
> [INFO] ---
> [INFO] [INFO] Installing 
> /tmp/mic-mectagcore/code/target/checkout/code/pom.xml to 
> /home/alambike/.m2/repository/temp/mectagcore/mectagcore/1.0.0/mectagcore-1.0.0.pom
> [INFO] [INFO]
> [INFO] [INFO] --- 

Re: what javac is actually used?

[Olivier Lamy]

Hi,
If by javac you mean the cli, per default m-compiler-p is not using
exactly this but in the process javax.tools.JavaCompiler.
If you want to really use javac (and so forking the compilation) you
must configure it via the fork option
(https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#fork)


On Mon, 4 Dec 2023 at 07:07, Dave Dyer  wrote:
>
>
> >
> >Maven, by default uses maven-compiler-plugin, but that plugin itself is
> >pluggable (can use javac, which is default, but also eclipse compiler, etc).
> >The plugin by default uses javac.
>
> The build I'm using seems to not be using javac - where is guidance
> to configuring it?
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

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

[ANN] Apache Maven Build Cache Extension 1.1.0

[Olivier Lamy]

Hi

The Apache Maven team is pleased to announce the release of the Apache
Maven Build Cache Extension 1.1.0.

Build cache is an extension that makes large Maven builds more efficient.

https://maven.apache.org/extensions/maven-build-cache-extension/

Release Notes - Maven Build Cache Extension - Version 1.1.0

** Bug
* [MBUILDCACHE-32] - Do not print exception when probing builds in
remote repo
* [MBUILDCACHE-61] - XXMM hash algorithm does not work on Java 17
* [MBUILDCACHE-64] - Apply global exclusions to folder names
* [MBUILDCACHE-66] - Mojo execution can be out of scope
* [MBUILDCACHE-67] - Any error in restoring from the cache should
resume the non cache build

** New Feature
* [MBUILDCACHE-62] - Add METRO hash implementation

** Task
* [MBUILDCACHE-75] - Upgrade Maven parent 41


Enjoy,

-The Apache Maven team

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

Re: Re: How to log in surefire which test classes are executed in which surefire thread?

[Olivier Lamy]

Please create a jira to attach files as this will not be displayed
here in the mailing list.

On Thu, 14 Sept 2023 at 17:50, Debraj Manna  wrote:
>
> Just to add, I am not sure if this is due to concurrent file access. Please 
> check the attached screenshot of the console logs. There it is saying Test 
> Run 5 but the AirInvoiceServiceTest contains only 1 test. And also the report 
> shows random data. For example, sometimes it says Test Run 5 , sometimes it 
> says Test Run 2, etc.
>
> On Wed, Sep 13, 2023 at 12:11 PM Debraj Manna  
> wrote:
>>
>> I am using a surefire dependency like below. Do I have to add anything in 
>> the plugin dependency for running tests in parallel using Junit5?
>>
>> 
>>   org.apache.maven.plugins
>>   maven-surefire-plugin
>>   3.1.2
>> 
>>
>> I will see if I can reproduce it in a small project. In the meantime, if I 
>> can share some debug logs from surefire which can help in debugging the 
>> issue let me know, and I can do that.
>>
>> Also, if there are any open issues related to this in Surefire, can you 
>> please share its link so that I can track them on my end?
>>
>> On Wed, Sep 13, 2023 at 2:19 AM Olivier Lamy  wrote:
>>>
>>> I'm using surefire 3.1.2 and junit 5.9.3 (Oh I have to upgrade :) )
>>> If you have a simple reproducer project, this would help
>>>
>>> On Wed, 13 Sept 2023 at 04:07, Debraj Manna  
>>> wrote:
>>> >
>>> > I am still facing the issue with
>>> > junit.jupiter.execution.parallel.config.fixed.parallelism=3, JUnit5 
>>> > Version
>>> > = 5.10.0 and surefire 3.1.2
>>> >
>>> > On Tue, Sep 12, 2023 at 6:34 PM Debraj Manna 
>>> > wrote:
>>> >
>>> > > Olivier
>>> > >
>>> > > Can you please let me know what version of Surefire and JUnit5 you are
>>> > > using?
>>> > >
>>> > > Thanks
>>> > >
>>> > > On Tue, Sep 12, 2023 at 5:16 PM Olivier Lamy  wrote:
>>> > >
>>> > >> Maybe concurrent access to files in surefire
>>> > >> I'm using this extensively but only with 3 max parallel test.
>>> > >> Can you try
>>> > >> junit.jupiter.execution.parallel.config.fixed.parallelism=3
>>> > >> And see if you still have the issues.
>>> > >> If not and if increasing this number is causing the issue. This sound
>>> > >> like a concurrent flle access issue with surefire.
>>> > >>
>>> > >> On Tue, 12 Sept 2023 at 18:02, Debraj Manna 
>>> > >> wrote:
>>> > >> >
>>> > >> > Hi
>>> > >> >
>>> > >> > I started using junit-platform.properties as suggested here. My
>>> > >> > configuration looks like below
>>> > >> >
>>> > >> > junit.jupiter.execution.parallel.enabled=true
>>> > >> > junit.jupiter.execution.parallel.config.strategy=fixed
>>> > >> > junit.jupiter.execution.parallel.config.fixed.parallelism=8
>>> > >> > junit.jupiter.execution.parallel.mode.default=same_thread
>>> > >> > junit.jupiter.execution.parallel.mode.classes.default=concurrent
>>> > >> >
>>> > >> > I am observing the surefire reports that are getting generated are 
>>> > >> > not
>>> > >> > correct
>>> > >> >
>>> > >> > I have a test class named
>>> > >> > com.spotnana.servicetests.backoffice.invoicing.AirInvoiceServiceTest
>>> > >> > contains just a single test, testAirTicketing().
>>> > >> >
>>> > >> > But in the report file,
>>> > >> >
>>> > >> TEST-com.spotnana.servicetests.backoffice.invoicing.AirInvoiceServiceTest.xml
>>> > >> >  I see like below
>>> > >> >
>>> > >> > http://www.w3.org/2001/XMLSchema-instance;
>>> > >> > xsi:noNamespaceSchemaLocation="
>>> > >> >
>>> > >> https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report-3.0.xsd
>>> > >> "
>>> > >> > version="3.0"
>>> > >> *name="com.spotnana.servicetests.backoffice.invoicing.AirInvoiceServiceTest"
>>> > 

Re: Re: How to log in surefire which test classes are executed in which surefire thread?

[Olivier Lamy]

I'm using surefire 3.1.2 and junit 5.9.3 (Oh I have to upgrade :) )
If you have a simple reproducer project, this would help

On Wed, 13 Sept 2023 at 04:07, Debraj Manna  wrote:
>
> I am still facing the issue with
> junit.jupiter.execution.parallel.config.fixed.parallelism=3, JUnit5 Version
> = 5.10.0 and surefire 3.1.2
>
> On Tue, Sep 12, 2023 at 6:34 PM Debraj Manna 
> wrote:
>
> > Olivier
> >
> > Can you please let me know what version of Surefire and JUnit5 you are
> > using?
> >
> > Thanks
> >
> > On Tue, Sep 12, 2023 at 5:16 PM Olivier Lamy  wrote:
> >
> >> Maybe concurrent access to files in surefire
> >> I'm using this extensively but only with 3 max parallel test.
> >> Can you try
> >> junit.jupiter.execution.parallel.config.fixed.parallelism=3
> >> And see if you still have the issues.
> >> If not and if increasing this number is causing the issue. This sound
> >> like a concurrent flle access issue with surefire.
> >>
> >> On Tue, 12 Sept 2023 at 18:02, Debraj Manna 
> >> wrote:
> >> >
> >> > Hi
> >> >
> >> > I started using junit-platform.properties as suggested here. My
> >> > configuration looks like below
> >> >
> >> > junit.jupiter.execution.parallel.enabled=true
> >> > junit.jupiter.execution.parallel.config.strategy=fixed
> >> > junit.jupiter.execution.parallel.config.fixed.parallelism=8
> >> > junit.jupiter.execution.parallel.mode.default=same_thread
> >> > junit.jupiter.execution.parallel.mode.classes.default=concurrent
> >> >
> >> > I am observing the surefire reports that are getting generated are not
> >> > correct
> >> >
> >> > I have a test class named
> >> > com.spotnana.servicetests.backoffice.invoicing.AirInvoiceServiceTest
> >> > contains just a single test, testAirTicketing().
> >> >
> >> > But in the report file,
> >> >
> >> TEST-com.spotnana.servicetests.backoffice.invoicing.AirInvoiceServiceTest.xml
> >> >  I see like below
> >> >
> >> > http://www.w3.org/2001/XMLSchema-instance;
> >> > xsi:noNamespaceSchemaLocation="
> >> >
> >> https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report-3.0.xsd
> >> "
> >> > version="3.0"
> >> *name="com.spotnana.servicetests.backoffice.invoicing.AirInvoiceServiceTest"
> >> > time="44.711" tests="2" errors="1" skipped="0" failures="0”>*
> >> >
> >> > …
> >> >
> >> >
> >> > *   >> >
> >> classname="com.spotnana.servicetests.analytics.ingestion.pnr.AirServiceTest"
> >> > time="5.789"/>   >> >
> >> classname="com.spotnana.servicetests.backoffice.invoicing.AirInvoiceServiceTest"
> >> > time="33.331”>*
> >> >
> >> > It seems to be picking tests from some other class like  AirServiceTest
> >> as
> >> > in this case.
> >> >
> >> > Can someone let me know what is going wrong here?
> >> >
> >> >
> >> >- Surefire Version - 3.0.0-M7
> >> >- JUnit Version -  5.9.3
> >> >
> >> > Thanks,
> >> >
> >> > On 2023/05/30 06:53:21 Karl Heinz Marbaise wrote:
> >> > > On 30.05.23 07:24, Debraj Manna wrote:
> >> > > > Thanks, Nils for replying.
> >> > > >
> >> > > > In JUnit5 it looks like running tests in parallel is still an
> >> > experimental
> >> > > > feature.
> >> > >
> >> > > Technically you are correct... but it's already a long time there I
> >> > > doubt that it will be removed.
> >> > >  > So I was checking if it is possible to do the same via Surefire.
> >> > >
> >> > > I recommend to use JUnit Jupiter...
> >> > >
> >> > > Btw: JUnit Jupiter is available in version 5.9.3 and also 5.10.0-M1 is
> >> > > available as milestone one...
> >> > >
> >> > > Furthermore the users guide of 5.10.0-M1
> >> > > (
> >> >
> >> https://junit.org/junit5/docs/5.10.0-M1/user-guide/index.html#writing-tests-parallel-execution
> >> > )
> >> > > shows that the WARNING abou

Re: Re: How to log in surefire which test classes are executed in which surefire thread?

[Olivier Lamy]

Maybe concurrent access to files in surefire
I'm using this extensively but only with 3 max parallel test.
Can you try
junit.jupiter.execution.parallel.config.fixed.parallelism=3
And see if you still have the issues.
If not and if increasing this number is causing the issue. This sound
like a concurrent flle access issue with surefire.

On Tue, 12 Sept 2023 at 18:02, Debraj Manna  wrote:
>
> Hi
>
> I started using junit-platform.properties as suggested here. My
> configuration looks like below
>
> junit.jupiter.execution.parallel.enabled=true
> junit.jupiter.execution.parallel.config.strategy=fixed
> junit.jupiter.execution.parallel.config.fixed.parallelism=8
> junit.jupiter.execution.parallel.mode.default=same_thread
> junit.jupiter.execution.parallel.mode.classes.default=concurrent
>
> I am observing the surefire reports that are getting generated are not
> correct
>
> I have a test class named
> com.spotnana.servicetests.backoffice.invoicing.AirInvoiceServiceTest
> contains just a single test, testAirTicketing().
>
> But in the report file,
> TEST-com.spotnana.servicetests.backoffice.invoicing.AirInvoiceServiceTest.xml
>  I see like below
>
> http://www.w3.org/2001/XMLSchema-instance;
> xsi:noNamespaceSchemaLocation="
> https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report-3.0.xsd;
> version="3.0" 
> *name="com.spotnana.servicetests.backoffice.invoicing.AirInvoiceServiceTest"
> time="44.711" tests="2" errors="1" skipped="0" failures="0”>*
>
> …
>
>
> *   classname="com.spotnana.servicetests.analytics.ingestion.pnr.AirServiceTest"
> time="5.789"/>   classname="com.spotnana.servicetests.backoffice.invoicing.AirInvoiceServiceTest"
> time="33.331”>*
>
> It seems to be picking tests from some other class like  AirServiceTest as
> in this case.
>
> Can someone let me know what is going wrong here?
>
>
>- Surefire Version - 3.0.0-M7
>- JUnit Version -  5.9.3
>
> Thanks,
>
> On 2023/05/30 06:53:21 Karl Heinz Marbaise wrote:
> > On 30.05.23 07:24, Debraj Manna wrote:
> > > Thanks, Nils for replying.
> > >
> > > In JUnit5 it looks like running tests in parallel is still an
> experimental
> > > feature.
> >
> > Technically you are correct... but it's already a long time there I
> > doubt that it will be removed.
> >  > So I was checking if it is possible to do the same via Surefire.
> >
> > I recommend to use JUnit Jupiter...
> >
> > Btw: JUnit Jupiter is available in version 5.9.3 and also 5.10.0-M1 is
> > available as milestone one...
> >
> > Furthermore the users guide of 5.10.0-M1
> > (
> https://junit.org/junit5/docs/5.10.0-M1/user-guide/index.html#writing-tests-parallel-execution
> )
> > shows that the WARNING about experimental feature has been removed...
> >
> >   https://junit.org/junit5/docs/current/user-guide/
> >
> > https://junit.org/junit5/
> >
> >
> > >
> > > On Mon, May 29, 2023 at 9:05 PM Nils Breunese  wrote:
> > >
> > >> I don’t have answers for your Surefire questions, but I wanted to
> mention
> > >> that you can also tell JUnit 5.9.2 to execute tests in parallel:
> > >> https://junit.org/junit5/docs/5.9.2/user-guide/index.html
> > >>
> > >> Nils.
> > >>
> > >>> Op 29 mei 2023 om 16:13 heeft Debraj Manna 
> > >> het volgende geschreven:
> > >>>
> > >>> I updated by command like below
> > >>>
> > >>> mvn test -Dorg.slf4j.simpleLogger.showThreadName=true
> > >>>
> > >>> But I am observing that all my test classes are being executed in
> > >>> ThreadStreamConsumer
> > >>>
> > >>> [ThreadedStreamConsumer] [INFO] Running
> > >>> com.spotnana.servicetests.profile.ProfileCreatePersonalUserTest
> > >>> ...
> > >>> [ThreadedStreamConsumer] [INFO] Running
> > >>> com.spotnana.servicetests.profile.PlanServiceTest
> > >>>
> > >>> So can someone let me know if this is the correct way of logging the
> > >>> parallel execution identifier in maven output logs? If yes then what
> am I
> > >>> doing wrong which is causing all test classes to execute in a single
> > >> thread?
> > >>>
> > >>> Junit Version - 5.9.2
> > >>>
> > >>>
> >  On Mon, May 29, 2023 at 6:53 PM Debraj Manna 
> >  wrote:
> > 
> >  I want to execute test classes concurrently in the same JVM. So my
> >  surefire-plugin config looks like below
> > 
> >  
> >    org.apache.maven.plugins
> >    maven-surefire-plugin
> >    3.0.0-M7
> >    
> >  
> >    $${surefire.forkNumber}
> >  
> >  
> >  
> >    -Xms512m -Xmx${surefire.max.heap}
> >    -XX:MaxDirectMemorySize=${surefire.max.direct.memory}
> >    -XX:MaxMetaspaceSize=${surefire.metaspace.size}
> >    -XX:+HeapDumpOnOutOfMemoryError @{argLine}
> >  
> >  suitesAndClasses
> >  false
> >  ${surefire.threadCount}
> >  1
> >  true
> >    
> >  
> > 
> >  Can someone let me know if there is a way for me to know which test
> >  classes are being executed in which surefire 

Re: Maven Compiler plugins does not support 21 yet?

[Olivier Lamy]

Hi
Please run your build using option -e and have a look at the stack.
I use 21, and it works fine.
This might be some restrictions with spring boot parent.
Or, according to the error message "error: release version 21 not
supported" you might not using a jdk 21.

On Tue, 12 Sept 2023 at 17:16, hantsy bai  wrote:
>
> I tried to update the compiler release to 21, and got a compiler error like
> this.
>
> Error: Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.11.0:compile
> (default-compile) on project spring6-sample-boot: Fatal error compiling:
> error: release version 21 not supported -> [Help 1]
> ---
>
> Regards,
>
> *Hantsy Bai*
>
> Self-employed consultant, fullstack developer, agile coach,
> freelancer/remote worker
>
> GitHub: https://github.com/hantsy
>
> Twitter: https://twitter.com/@hantsy
> Medium: https://medium.com/@hantsy

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

Re: maven-build-cache: extra attached directories output of target

[Olivier Lamy]

Hi

On Sat, 26 Aug 2023 at 04:40, Ben Tatham
 wrote:
>
> Hello,
> Is it possible to add extra attached directories that are not within the
> project build output directory (ie not in ./target?)

Currently no. A possible solution could be to create an extra artifact
containing what you need and attach it to the project.

>
> Based on the documentation and playing around with attachedOutputs
> ,
> those are relative to the project output directory (target). I want to
> preserve those, but also want to preserve a secondary directory with it.
> (In our case, we are doing an angular build as part of the project, which
> outputs into ./dist that we want to reload from the cache as well.
>
> Thanks,
> Ben
>
> [image: -] 
> [image: -]  [image: -]
> 
> [image:
> -] 
>
> Ben Tatham
> Principal Software Developer
> Nanometrics
> bentat...@nanometrics.ca
>
> --
> This message is intended exclusively for the individual or entity to which
> it is addressed. This communication may contain information that is
> proprietary, privileged, confidential or otherwise legally exempt from
> disclosure. If you are not the named addressee, or have been inadvertently
> and erroneously referenced in the address line, you are not authorized to
> read, print, retain, copy or disseminate this message or any part of it. If
> you have received this message in error, please notify the sender
> immediately by e-mail and delete all copies of the message.

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

Re: CVE-2021-26291 in maven-bundle plugin

[Olivier Lamy]

Hi
This plugin is maintained by the Apache Felix project so please refer
to them for any questions.
Anyway please read the description of the CVE so it's very unlikely
you are subject to a real security issue here.
Remember scanner is just "stupidly" looking at dependencies and most
of the time this doesn't mean you have a real problem.


On Sat, 19 Aug 2023 at 17:23, Debraj Manna  wrote:
>
> Hi
>
> In our scan maven-bundle plugin 5.1.5 is getting flagged for CVE-2021-26291
>  due to the presence
> of maven-compat 3.3.9. I am seeing that the latest version of maven-bundle
> plugin, 5.1.9 is also using maven-compat 3.3.9. Is there any plan to update
> maven-compat to 3.8.2 at least to get around this CVE?
>
> Thanks

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

Re: Questions about the build cache plugin

[Olivier Lamy]

On Sat, 17 Jun 2023 at 11:05, Hervé Boutemy  wrote:
>
> reading the discussion about maintenance branch and "who updates the cache", I
> think that:
>
> 1. maintenance branch is like main branch: with Olivier's nice strategy, you
> should build fully. In fact, the few long-lived branches should be built
> fully, only the many PR short-lived branches should be built quickly with
> cache

When I mean build fully for main branches, I mean only on CI but
locally the local cache is used on dev machine.

>
> 2. "updating" the cache makes you feel that it's like publishing a SNAPSHOT,
> ie the last publication wins over previous ones. With cache, any publication
> is just an addition of new content, indexed by input checksums. Then we don't
> really care about who is the first discovering a new input checksum, then
> filling the output cache for that new input checksum.
>
> Really nice feedback on build cache extension in real life!
>
> Thanks a lot to the contributor to this great feature
>
> Regards,
>
> Hervé
>
> Le mardi 13 juin 2023, 07:11:50 CEST Olivier Lamy a écrit :
> > On Mon, 12 Jun 2023 at 21:38, Benjamin Marwell  wrote:
> > > Am Mo., 12. Juni 2023 um 12:08 Uhr schrieb Olivier Lamy
> :
> > > > On Mon, 12 Jun 2023 at 18:53, Benjamin Marwell 
> wrote:
> > > > > Hello everyone!
> > > > >
> > > > > First of all thank you everyone working on the build cache plugin! It
> > > > > is amazing!
> > > > >
> > > > > At least some of  the following questions seem to be of interest to
> > > > > most users and might end up on the documentation, So here's a few
> > > > > things which came to my mind.
> > > > >
> > > > > 1.) Considering I always require PRs in my projects, would setting
> > > > > -Dmaven.build.cache.remote.save.enabled=true be a sensible thing only
> > > > > for the main branch?
> > > >
> > > > Personally, I would have the main branch always have a full build
> > > > without caching to be sure everything works fine but use cache only
> > > > for branches/PR :)
> > > > That's what we will do at Jetty project.
> > > > The build for 12 branch is around 50 minutes with the cache it goes
> > > > down to 8/9 minutes (only because something is always rebuilt and
> > > > retrigger a few small modules)
> > > > The idea is to reduce development/check of PR and use some incremental
> > > > build while the main is always fully build especially when the build
> > > > has few jdks as target.
> > > > But here it's up to you :)
> > >
> > > I can see your point, but who is updating the remote cache then?
> >
> > every PR potentially updates the cache. depending on changes per PR
> > some module cache will be shared or not with other PRs.
> > We (Jetty project) have decided to not have any publicity open remote
> > cache setup per default as we do not have the infra for this (but CI
> > use a private one)
> > but in a company context or if you have the infra for this it might be
> > a better option.
> >
> > > > > 2.) Can I maybe have  the branch name included in a path to a remote?
> > > > > This way I could have a different cache for maintenance branches. Just
> > > > > include the branch name into -Dmaven.build.cache.remote.url?
> > > >
> > > > why would need that?
> > > > if your branch has different sources (java, pom, etc..) the calculated
> > > > hash will be different so the hash key will be simply different no
> > > > need to configure a cache URL differently (well except if you want to
> > > > clean up caches per branch)
> > >
> > > It depends on what you might be trying to do. For projects with new
> > > major versions and some
> > > big refactoring done in the past, this did sound sensible to me.
> > > What is the cache worth if there's 0% hit on the maintenance branch?
> >
> > hit ratio will depend on the changes you do.
> > parent pom change -> everything will be rebuilt
> > single java source in a module: only this module and dependant will be
> > rebuilt. Finally, there is no single rule on how to use/configure the
> > cache, the usage depends on how a team is working, what sort of change they
> > often have, etc...
> > first, have your build working (if it's complicated one you may have
> > some extra configuration to add)
> >
> > > > > 3.) 

Re: Questions about the build cache plugin

[Olivier Lamy]

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

every PR potentially updates the cache. depending on changes per PR
some module cache will be shared or not with other PRs.
We (Jetty project) have decided to not have any publicity open remote
cache setup per default as we do not have the infra for this (but CI
use a private one)
but in a company context or if you have the infra for this it might be
a better option.

>
>
> > > 2.) Can I maybe have  the branch name included in a path to a remote?
> > > This way I could have a different cache for maintenance branches. Just
> > > include the branch name into -Dmaven.build.cache.remote.url?
> >
> > why would need that?
> > if your branch has different sources (java, pom, etc..) the calculated
> > hash will be different so the hash key will be simply different no
> > need to configure a cache URL differently (well except if you want to
> > clean up caches per branch)
>
> It depends on what you might be trying to do. For projects with new
> major versions and some
> big refactoring done in the past, this did sound sensible to me.
> What is the cache worth if there's 0% hit on the maintenance branch?
>

hit ratio will depend on the changes you do.
parent pom change -> everything will be rebuilt
single java source in a module: only this module and dependant will be rebuilt.
Finally, there is no single rule on how to use/configure the cache,
the usage depends on how a team is working, what sort of change they
often have, etc...
first, have your build working (if it's complicated one you may have
some extra configuration to add)


>
>
> > > 3.) Can I somehow use option 1 & 2 to make caches available for
> > > colleagues without making them manually configure the remote URL for
> > > each branch they are working on?
> >
> > cache will be used by colleagues' build as long as a module have the
> > same calculated hash any local differences will have a different
> > calculated hash
>
> Same as above:
> What about devs working on a maintenance branch when main has seen big
> refactoring?
>
>
> > > 4.) The docs say there's also XX and XXMM algorithms, but it doesn't
> > > say WHEN to use them (only that they may leverage performance). Are
> > > there some example cases or does someone already have some experience
> > > we could benefit from?
> >
> > I have yet to see huge differences.
> > currently with a build already down from 50 minutes to 8/9 minutes not
> > sure this was my primary goal
> > So I can't really tell :)
>
> Well, it is listed under "performance tuning", so I concluded it might
> make a difference.
> Will probably go for XX (because it is mentioned as performance tuning
> without any drawbacks)
>  and switch to Metro once it is there.
>
>
> > > 5.) The section "filtering out artifacts" might want to give a size of
> > > artifacts which should be regarded as too large, depending on the
> > > environment probably.
> > >
> >
> > definitely depends on your environment.
>
> Yup.
> I might use different settings in a corporate environment, my thought.
>
> > >
> > > -

Re: Questions about the build cache plugin

[Olivier Lamy]

On Mon, 12 Jun 2023 at 18:53, Benjamin Marwell  wrote:
>
> Hello everyone!
>
> First of all thank you everyone working on the build cache plugin! It
> is amazing!
>
> At least some of  the following questions seem to be of interest to
> most users and might end up on the documentation, So here's a few
> things which came to my mind.
>
> 1.) Considering I always require PRs in my projects, would setting
> -Dmaven.build.cache.remote.save.enabled=true be a sensible thing only
> for the main branch?

Personally, I would have the main branch always have a full build
without caching to be sure everything works fine but use cache only
for branches/PR :)
That's what we will do at Jetty project.
The build for 12 branch is around 50 minutes with the cache it goes
down to 8/9 minutes (only because something is always rebuilt and
retrigger a few small modules)
The idea is to reduce development/check of PR and use some incremental
build while the main is always fully build especially when the build
has few jdks as target.
But here it's up to you :)

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

why would need that?
if your branch has different sources (java, pom, etc..) the calculated
hash will be different so the hash key will be simply different no
need to configure a cache URL differently (well except if you want to
clean up caches per branch)

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

cache will be used by colleagues' build as long as a module have the
same calculated hash any local differences will have a different
calculated hash

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


I have yet to see huge differences.
currently with a build already down from 50 minutes to 8/9 minutes not
sure this was my primary goal
So I can't really tell :)

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

definitely depends on your environment.

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

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

[ANN] Apache Maven Build Cache extension 1.0.1

[Olivier Lamy]

Hi,
The Apache Maven team is pleased to announce the release of Apache
Maven Build Cache extension 1.0.1.

The Build cache is an extension targeted to simplify and make more
efficient work with large builds in Maven. With features such as
incremental builds work on the modified part of the project graph part
only, project state restoration (partial) to avoid expensive tasks
(code generation and similar), etc.
More details are available here:
https://maven.apache.org/extensions/maven-build-cache-extension/index.html

For a quick start please refer to the "Getting Started" page:
https://maven.apache.org/extensions/maven-build-cache-extension/getting-started.html

Release Notes - Maven Build Cache Extension - Version 1.0.1

** Bug
* [MBUILDCACHE-25] - Project processed multiple time in presence
of forked executions
* [MBUILDCACHE-42] - the CLI maven.build.cache.enabled=false is not honoured
* [MBUILDCACHE-44] - Running duplicate maven phase leads to
IllegalStateException and cache miss
* [MBUILDCACHE-51] - Broken link to maven-build-cache-config.xml
template on Getting Started page
* [MBUILDCACHE-56] - NPE with mojo parameters not declared as
fields (prevent any saving of cache)

** Improvement
* [MBUILDCACHE-34] - Improve IT test execution
* [MBUILDCACHE-46] - Add maven.build.cache.remote.enabled parameter
* [MBUILDCACHE-48] - Add ability to disable caching on a per-module level
* [MBUILDCACHE-52] - Use current latest release in Getting Started snippet
* [MBUILDCACHE-57] - Configure remote url/remote server id with
command line property

** Task
* [MBUILDCACHE-43] - Change the output directory from
`incremental-maven` to `build-cache`

** Dependency upgrade
* [MBUILDCACHE-39] - Upgrade to maven-parent pom 39
* [MBUILDCACHE-40] - Upgrade to maven 3.9.0



Have fun,
The Apache Maven team

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

Re: MavenCLI failing in Jenkins

[Olivier Lamy]

Hi
How are you running Maven in Jenkins? Pipeline? Maven job type?

On Thu, 20 Apr 2023 at 07:43, Javier Ortiz Bultron
 wrote:
>
> Code works perfectly on my Mac but not on Jenkins. I'm running this on the
> Maven official image: maven:3.9.1-eclipse-temurin-11
>
> I'm trying to figure out how to fix this issue:
>
> [2023-04-19 21:24:35.509] [ERROR] [main] o.a.m.c.MavenCli
> [MavenCli.java:965] Plugin
> org.apache.maven.plugins:maven-resources-plugin:3.3.0 or one of its
> dependencies could not be resolved: Failed to read artifact descriptor
> for org.apache.maven.plugins:maven-resources-plugin:jar:3.3.0: The
> following artifacts could not be resolved:
> org.apache.maven.plugins:maven-resources-plugin:pom:3.3.0 (present,
> but unavailable): Could not transfer artifact
> org.apache.maven.plugins:maven-resources-plugin:pom:3.3.0 from/to
> central (https://repo.maven.apache.org/maven2): No connector factories
> available -> [Help 1]
> [2023-04-19 21:24:35.511] [ERROR] [main] o.a.m.c.MavenCli [MavenCli.java:850]
> [2023-04-19 21:24:35.512] [ERROR] [main] o.a.m.c.MavenCli
> [MavenCli.java:853] To see the full stack trace of the errors, re-run
> Maven with the -e switch.
> [2023-04-19 21:24:35.512] [ERROR] [main] o.a.m.c.MavenCli
> [MavenCli.java:858] Re-run Maven using the -X switch to enable full
> debug logging.
> [2023-04-19 21:24:35.513] [ERROR] [main] o.a.m.c.MavenCli [MavenCli.java:863]
> [2023-04-19 21:24:35.513] [ERROR] [main] o.a.m.c.MavenCli
> [MavenCli.java:864] For more information about the errors and possible
> solutions, please read the following articles:
> [2023-04-19 21:24:35.514] [ERROR] [main] o.a.m.c.MavenCli
> [MavenCli.java:868] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException

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

Re: [External] : Re: NPE Exception with Surefire3.0.0

[Olivier Lamy]

Hi
Do you really need the dependencies section within the plugin section?
just use
  


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




On Tue, 18 Apr 2023 at 15:56, Sirisha Alla  wrote:
>
> I am using the maven version 3.8.7. pom.xml has other internal module 
> dependencies and below is the snippet from pom.xml for the junit tests added.
>
> 
> org.mockito
> mockito-core
> 4.11.0
>  test
> 
> 
> org.junit.jupiter
> junit-jupiter-api
> 5.9.2
> test
> 
>   
>
>   
> 
> 
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0
> 
> 
> org.apache.maven.surefire
> maven-surefire-common
> 3.0.0
> 
> 
> org.apache.maven.surefire
> surefire-booter
> 3.0.0
> 
> 
> org.apache.maven.surefire
> surefire-logger-api
> 3.0.0
> 
> 
> org.apache.maven.surefire
> surefire-api
> 3.0.0
> 
> 
> org.apache.maven.surefire
> surefire-extensions-api
> 3.0.0
> 
> 
> org.codehaus.plexus
> plexus-java
> 1.1.2
> 
> 
> org.apache.maven.surefire
> surefire-shared-utils
> 3.0.0
> 
> 
> org.apache.maven.shared
> maven-common-artifact-filters
> 3.3.2
> 
> 
> org.eclipse.aether
> aether-util
> 1.1.0
> 
> 
> org.apache.maven.surefire
> surefire-junit-platform
> 3.0.0
> 
> 
> org.junit.jupiter
> junit-jupiter-engine
> 5.9.2
> runtime
> 
> 
> org.junit.platform
> junit-platform-engine
> 1.9.2
> runtime
> 
>
> 
> 
> 
>   
>
> Thanks,
> Sirisha
>
> -Original Message-
> From: Benjamin Marwell 
> Sent: Tuesday, April 18, 2023 11:16 AM
> To: Maven Users List 
> Subject: [External] : Re: NPE Exception with Surefire3.0.0
>
> Which version of Maven are you using?
> Can you give us a relevant snippet of your pom.xml to reproduce the issue?
>
>
>
> On Mon, 17 Apr 2023, 17:07 Sirisha Alla,  wrote:
>
> > Hi All,
> >
> > I am using surefire 3.0.0 with Junit 5 (Jupiter-engine). However, I am
> > stumbling in to the Null Pointer Exception and could not trace the issue.
> > Has anyone faced this issue or any pointers that can help me proceed?
> > I am using JDK1.8.
> >
> > Caused by: java.lang.NullPointerException
> > at
> > org.apache.maven.plugin.surefire.AbstractSurefireMojo.hasGroupArtifact
> > Id
> > (AbstractSurefireMojo.java:1771)
> > at
> > org.apache.maven.plugin.surefire.AbstractSurefireMojo.retainInProcArti
> > factsUnique
> > (AbstractSurefireMojo.java:1757)
> > at
> > org.apache.maven.plugin.surefire.AbstractSurefireMojo.newStartupConfig
> > WithClasspath
> > (AbstractSurefireMojo.java:1735)
> > at
> > org.apache.maven.plugin.surefire.AbstractSurefireMojo.createStartupCon
> > figuration
> > (AbstractSurefireMojo.java:1701)
> > at
> > org.apache.maven.plugin.surefire.AbstractSurefireMojo.createForkStarte
> > r
> > (AbstractSurefireMojo.java:2165)
> > at
> > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider
> > (AbstractSurefireMojo.java:1192)
> > at
> > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPrec
> > onditionsChecked
> > (AbstractSurefireMojo.java:1055)
> > at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute
> > (AbstractSurefireMojo.java:871)
> > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> > (DefaultBuildPluginManager.java:137)
> > at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> > (MojoExecutor.java:370)
> > at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> > (MojoExecutor.java:351)
> > at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> > (MojoExecutor.java:215)

Re: some feedback

[Olivier Lamy]

On Mon, 17 Apr 2023 at 03:07, Nicolas Delsaux  wrote:
>
> Hi all,
>
> I've met Hervé Boutemy at Devoxx last week (well, I hope Hervé remember
> we discussed this subject wednesday evening), and we discussed about
> some maven subjects.
>
> Namely, Hervé was looking for some "interesting" projects.
>
> As a consequence, here is an open-source project I'm working on since
> quite some time https://github.com/Riduidel/aadarchi
>
> Why is it interesting ?
>
> a. For the packaging variety : the project contains some jars, but also
> a maven plugin, a gradle plugin (I don't know if it is a good one in
> this mailing-list), a maven archetype, and some documentation
>
> b. For the use (maybe not necessary) of CDI in maven, with maven
> properties used in CDI components (through the use of Deltaspike), and I
> think it could be cool to have it replaced with Guice (yup, that was
> part of the discussion with Hervé)

why not if you do not need new features provided by the new version of
the CDI specs (https://jakarta.ee/specifications/cdi/)
because bear in mind you will be limited to the version of DI
supported by Guice and sisu-plexus
Specs here (https://jakarta.ee/specifications/dependency-injection/)
no idea if Guice has plan to support version 2.0)



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

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

Re: How does reuseFork and forkCount behaves with maven parallel builds?

[Olivier Lamy]

On Thu, 23 Mar 2023 at 10:43 pm, Debraj Manna 
wrote:

> >
> > which means a maximum of 3 jvms running at the same time.
>
>
> I don't understand this. Why a maximum of 3? If I am running with -T 2
> there can be a maximum of 2 JVMs, right?


1 jvm for maven which can build 2 modules in parallel using this jvm
But surefire will fork 1 jvm per module so
1 + (2*1) = 3



>
> On Wed, Mar 22, 2023 at 4:51 PM Olivier Lamy  wrote:
>
> > Hi.
> > -Tx option will not change anything about how surefire works.
> > using this configuration (which is the default):
> > 1
> > true
> >
> > means surefire will create only one fork and reuse it BUT only for the
> > same maven module.
> > With -T2 you will have a maximum of 2 maven modules building in
> > parallel which means you can have potentially one surefire forked jvm
> > per module
> > which means a maximum of 3 jvms running at the same time.
> >
> >
> >
> > On Wed, 22 Mar 2023 at 18:53, Debraj Manna 
> > wrote:
> > >
> > > I have a multi-module project. My POM structure is like below
> > >
> > > root/pom.xml
> > >
> > > 
> > > 
> > > a
> > > b
> > > c
> > > d
> > > 
> > >
> > > I am running surefire with reuseForks = true, forkCount = 1. If I am
> > > executing all tests at the root level with mvn -T 2 test. How will
> tests
> > be
> > > executed?
> > >
> > > Assuming maven picks modules *a* and *b* to be executed first. Then
> > module
> > > *a* and Module *b* tests will be executed in two separate JVM and once
> > > those are finished. There will be two new JVM spawned which will
> execute
> > > all tests for module c and module d.
> > >
> > > Is my above understanding correct or the same two JVMs will be reused
> for
> > > executing tests for module *c* and module *d?*
> > >
> > > I am using surefire 3.0.0-M7. My entire surefire config in root/pom.xml
> > > looks like below.
> > >
> > > 
> > >   
> > > 
> > >   org.apache.maven.plugins
> > >   maven-surefire-plugin
> > >   3.0.0-M7
> > >   
> > > 
> > >   
> > >   false
> > >   false
> > >   
> > >   test
> > >   false
> > >
> > >
> 3
> > >   en
> > >   US
> > >   $${surefire.forkNumber}
> > > 
> > > 
> > > 
> > >   -Xms512m -Xmx3g -XX:MaxDirectMemorySize=512m
> > > -XX:MaxMetaspaceSize=768m
> > >   -XX:+HeapDumpOnOutOfMemoryError @{argLine}
> > >   
> > >   --add-modules=jdk.incubator.foreign
> > >   --add-opens=java.base/java.lang=ALL-UNNAMED
> > >   --add-opens=java.base/java.math=ALL-UNNAMED
> > >   --add-opens=java.base/java.util=ALL-UNNAMED
> > >   --add-opens=java.base/java.util.concurrent=ALL-UNNAMED
> > >   --add-opens=java.base/java.net=ALL-UNNAMED
> > >   --add-opens=java.base/java.text=ALL-UNNAMED
> > >   --add-opens=java.sql/java.sql=ALL-UNNAMED
> > >   
> > >   --add-opens=java.base/java.time=ALL-UNNAMED
> > >   
> > >
> > > --add-opens=java.xml/com.sun.org.apache.xpath.internal.jaxp=ALL-UNNAMED
> > > 
> > >
> > > 
> > > suitesAndClasses
> > > false
> > >
> > > 
> > >
> >  
> > >
> > >
> >
> 
> > >
> > > 
> > > 1
> > > true
> > >   
> > > 
> > > 
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: How does reuseFork and forkCount behaves with maven parallel builds?

[Olivier Lamy]

Hi.
-Tx option will not change anything about how surefire works.
using this configuration (which is the default):
1
true

means surefire will create only one fork and reuse it BUT only for the
same maven module.
With -T2 you will have a maximum of 2 maven modules building in
parallel which means you can have potentially one surefire forked jvm
per module
which means a maximum of 3 jvms running at the same time.



On Wed, 22 Mar 2023 at 18:53, Debraj Manna  wrote:
>
> I have a multi-module project. My POM structure is like below
>
> root/pom.xml
>
> 
> 
> a
> b
> c
> d
> 
>
> I am running surefire with reuseForks = true, forkCount = 1. If I am
> executing all tests at the root level with mvn -T 2 test. How will tests be
> executed?
>
> Assuming maven picks modules *a* and *b* to be executed first. Then module
> *a* and Module *b* tests will be executed in two separate JVM and once
> those are finished. There will be two new JVM spawned which will execute
> all tests for module c and module d.
>
> Is my above understanding correct or the same two JVMs will be reused for
> executing tests for module *c* and module *d?*
>
> I am using surefire 3.0.0-M7. My entire surefire config in root/pom.xml
> looks like below.
>
> 
>   
> 
>   org.apache.maven.plugins
>   maven-surefire-plugin
>   3.0.0-M7
>   
> 
>   
>   false
>   false
>   
>   test
>   false
>
> 3
>   en
>   US
>   $${surefire.forkNumber}
> 
> 
> 
>   -Xms512m -Xmx3g -XX:MaxDirectMemorySize=512m
> -XX:MaxMetaspaceSize=768m
>   -XX:+HeapDumpOnOutOfMemoryError @{argLine}
>   
>   --add-modules=jdk.incubator.foreign
>   --add-opens=java.base/java.lang=ALL-UNNAMED
>   --add-opens=java.base/java.math=ALL-UNNAMED
>   --add-opens=java.base/java.util=ALL-UNNAMED
>   --add-opens=java.base/java.util.concurrent=ALL-UNNAMED
>   --add-opens=java.base/java.net=ALL-UNNAMED
>   --add-opens=java.base/java.text=ALL-UNNAMED
>   --add-opens=java.sql/java.sql=ALL-UNNAMED
>   
>   --add-opens=java.base/java.time=ALL-UNNAMED
>   
>
> --add-opens=java.xml/com.sun.org.apache.xpath.internal.jaxp=ALL-UNNAMED
> 
>
> 
> suitesAndClasses
> false
>
> 
> 
>
> 
>
> 
> 1
> true
>   
> 
> 

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

Re: maven-surefire-plugin add artifact as additionalClasspathElement

[Olivier Lamy]

On Thu, 16 Feb 2023 at 20:52, Olivier Lamy  wrote:
>
> On Thu, 16 Feb 2023 at 20:07, Delany  wrote:
> >
> > Hi Stephane,
> >
> > You can do like this
> >
> > 
> >   maven-surefire-plugin
> >   3.0.0-M9
> >   
> > 
> >   org.apache.commons
> >   commons-email
> >   1.5
> > 
> >   
> > 
>
> this will add dependencies to the surefire plugin itself.
> I guess Stephane wants to add to the jvm running the tests?
>
> additionalClasspathElement expect a full path to a directory or a file
> to be added to the classpath
>
> should work with something such but you need to assume commons-email
> has been resolved locally as a dependency.
> ${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar
>
> another solution is to use dependency:copy to copy the commons-email
> dependency somewhere in ./target and use this path (see
> https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html)
>

a real example here :)
https://github.com/apache/maven-surefire/blob/master/surefire-providers/common-junit48/pom.xml

> hth
> Olivier
>
> >
> > On Thu, 16 Feb 2023 at 11:25, Stephane Passignat 
> > wrote:
> >
> > > Hello,
> > >
> > > Is it possible to add a maven artifact as an additionalClasspathElement ?
> > >
> > > I tried this syntax, inspired by the exclusion mechanism, but it's not
> > > working.
> > >
> > > 
> > > 
> > >
> > >   org.apache.maven.plugins
> > >   maven-surefire-plugin
> > >   3.0.0-M9
> > >   
> > >  
> > >
> > > org.apache.commons:commons-email:1.5
> > >  
> > >   
> > >
> > > 
> > > 
> > >
> > >
> > > thank you
> > >
> > > Stéphane
> > >

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

Re: maven-surefire-plugin add artifact as additionalClasspathElement

[Olivier Lamy]

On Thu, 16 Feb 2023 at 20:07, Delany  wrote:
>
> Hi Stephane,
>
> You can do like this
>
> 
>   maven-surefire-plugin
>   3.0.0-M9
>   
> 
>   org.apache.commons
>   commons-email
>   1.5
> 
>   
> 

this will add dependencies to the surefire plugin itself.
I guess Stephane wants to add to the jvm running the tests?

additionalClasspathElement expect a full path to a directory or a file
to be added to the classpath

should work with something such but you need to assume commons-email
has been resolved locally as a dependency.
${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar

another solution is to use dependency:copy to copy the commons-email
dependency somewhere in ./target and use this path (see
https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html)

hth
Olivier

>
> On Thu, 16 Feb 2023 at 11:25, Stephane Passignat 
> wrote:
>
> > Hello,
> >
> > Is it possible to add a maven artifact as an additionalClasspathElement ?
> >
> > I tried this syntax, inspired by the exclusion mechanism, but it's not
> > working.
> >
> > 
> > 
> >
> >   org.apache.maven.plugins
> >   maven-surefire-plugin
> >   3.0.0-M9
> >   
> >  
> >
> > org.apache.commons:commons-email:1.5
> >  
> >   
> >
> > 
> > 
> >
> >
> > thank you
> >
> > Stéphane
> >

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

[ANN] Release Apache Maven Surefire 3.0.0-M9

[Olivier Lamy]

Hi
The Apache Maven team is pleased to announce the availability of Maven
Surefire 3.0.0-M9.

Release Notes - Maven Surefire - Version 3.0.0-M9

** Bug
* [SUREFIRE-2065] - Test Reports Inconsistencies with
Parameterized and junit4
* [SUREFIRE-2095] - Fork crash doesn't fail build with
-Dmaven.test.failure.ignore=true when run with failsafe

** Improvement
* [SUREFIRE-2145] - Don't use Sink#figure()/Sink#figureCaption()
since it distorts the output
* [SUREFIRE-2146] - Don't draw border around reporting tables

Have fun
cheers
The Apache Maven team.

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

[ANN] Maven Invoker Plugin 3.4.0

[Olivier Lamy]

The Apache Maven team is pleased to announce the release of the Apache
Maven Invoker Plugin, version 3.4.0

The Invoker Plugin is used to run a set of Maven projects. The plugin
can determine whether each project execution is successful, and
optionally can verify the output generated from a given project
execution.
This plugin is particularly handy to perform integration tests for
other Maven plugins. The Invoker Plugin can be employed to run a set
of test projects that have been designed to assert certain features of
the plugin under test.

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

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


  org.apache.maven.plugins
  maven-invoker-plugin
  3.4.0


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

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

Release Notes - Maven Invoker Plugin - Version 3.4.0

** Bug
* [MINVOKER-306] - Bugfix for case if invoker.test parameter
contains only exclude-patterns


** New Feature
* [MINVOKER-289] - Support for shared invoker's Update-Snapshots Flag

** Improvement
* [MINVOKER-311] - Override reports directory in IT test


** Task
* [MINVOKER-316] - Refresh plugins versions in IT tests

** Dependency upgrade
* [MINVOKER-305] - Upgrade Groovy to 3.0.12
* [MINVOKER-310] - Upgrade Parent to 37
* [MINVOKER-312] - Upgrade Groovy to 4.x
* [MINVOKER-315] - Upgrade Maven Reporting API to 3.1.1/Maven
Reporting Impl to 3.2.0

Enjoy,

-The Apache Maven team

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

Re: Modular path vs. class path determination

[Olivier Lamy]

On Sat, 1 Oct 2022 at 01:22, Ceki Gülcü  wrote:
>
>
> Hello all,
>
> The logback is attempting to migrate to Junit 5. As a consequence of
> this migration, a handful of tests that were previously successful, now
> fail.
>
> For example, the ch.qos.logback.classic.net.DilutedSMTPAppenderTest
> recently failed with the following error:
>
> java.lang.NoClassDefFoundError: jakarta/mail/internet/AddressException
>
> During surefire execution, the j.m.i.AddressException class is not
> found. It is part of jakarta-mail.jar. I believe this artifact is on the
> module path but somehow is not resolved.
>
> Anyway, upgrading org.assertj:assertj-core from l.7.1 to 3.23.1 seems to
> help. Don't ask me why...
>
> I am also puzzled by the fact that many JMPS modularized artifacts are
> placed on the class path instead of the module path when the tests are run.

well maybe the problem is some are on module path and some others on
the class path..
when migrating the Jetty project from surefire M5 to M7 I had a lot of
jpms issues because some logic changed especially in this part.
I wanted to have some opinions on what sort of configurations we could
add but this didn't get much attention :)
(https://issues.apache.org/jira/browse/SUREFIRE-2097)
Maybe nobody really cares of jpms...


>
> Anyway, I think I may have stumbled upon a bug in Maven or the surefire
> plugin. Indeed, when I run mvn install from within the logback-classic
> module, the DilutedSMTPAppenderTest mentioned above succeeds.
>
> However, when I run it as
>
> mvn install -Dtest=ch.qos.logback.classic.net.DilutedSMTPAppenderTest
>
> the test fails with the following exception
>
> [ERROR]
> ch.qos.logback.classic.net.DilutedSMTPAppenderTest.testTriggeringPolicy
>  Time elapsed: 0.001 s  <<< ERROR!
> java.lang.NoClassDefFoundError: jakarta/mail/internet/AddressException
> at
> ch.qos.logback.classic@1.4.2-SNAPSHOT/ch.qos.logback.classic.net.DilutedSMTPAppenderTest.setUp(DilutedSMTPAppenderTest.java:41)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>
> [cut]...
> Caused by: java.lang.ClassNotFoundException:
> jakarta.mail.internet.AddressException
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 74 more
>
>
> Comparing the command line of the two executions, the 'mvn install'
> execution has jakarta-mail-api on the module-path, whereas the 'mvn test
> -D=..." has jakarta-mail-api on the class-path.
>
> If you wish to confirm this, I have created tag 'possible_mvn_issue'
> in the logback repository on github .
>
>   https://github.com/qos-ch/logback/releases/tag/possible_mvn_issue
>
> Let me know if this merits the creation of a Jira issue.
>
> Your feedback would be most appreciated.
>
> --
> Ceki Gülcü
>
> Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org

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

Re: Plans to deprecate or change the default value of maven compiler plugin's showWarnings

[Olivier Lamy]

On Thu, 15 Sept 2022 at 00:52, Florent Biville 
wrote:

> Hi everyone,
>
> A colleague of mine recently stumbled upon this
> <
> https://stackoverflow.com/questions/9192613/how-do-i-get-a-java-maven-build-to-fail-for-compiler-warnings/33823355#33823355
> >
> .
>
> Quoting the above Stackoverflow answer:
>
> > true is required. For reasons unknown, Maven
> > by default actively suppresses warnings with the -nowarn flag, so the
> > -Xlint and -Werror flags would be ignored.
> >
>
> I assume that warnings are suppressed by default because the default value
> of showWarnings is false?
>

correct.
the source for this is here
https://github.com/codehaus-plexus/plexus-compiler/blob/79d1a5fdd237a736ad58fd346a975d5d37046a15/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavacCompiler.java#L353

I agree this could be improved. Especially everything around the isShowLint
method


>
> If that's the case, I wonder why we need such an accessible option is
> necessary since the other related warning options would have to go through
> compilerArgs.
>

Historically (if I remember correctly) only the option '-nowarn' was
available then came new compiler options
well this could be done differently by fixing the use of isShowLint.
the option is to suppress quickly every "noise" (e.g warnings)


> I also realize my question is relevant to other settings.
>
> Is there a plan to deprecate this kind of settings and remove them at a
> next major version?
>

What other settings do you have in mind?


> In the specific case of showWarnings, if deprecation and removal are not an
> option, could changing the default value to true be considered for the next
> major version (or maybe some other value that means the setting is not
> initialized and should not interfere with warnings)?
>

sounds good to me to change to true.
changing from boolean to something might break some compatibility
especially because other compilers.


>
> Thanks for your help!
> Florent
>

Re: maven-shade-plugin: relocation of package names in resource files (unfortunately not in META-INF/services dir)

[Olivier Lamy]

You can create your own transformer implementation and add it as a
dependency of the plugin (see sources there [1] to see what interface to
implement). not tested but should work
Maybe you can use a feature of the resources plugin see
https://maven.apache.org/plugins/maven-resources-plugin/examples/custom-resource-filters.html

Another option is to use a feature of the resources plugin to create your
own filtering (see [2])
Note the documentation is not up2date. You should be able to use some
annotations such
@Singleton
@Named("itFilter")
public class ItFilter implements MavenResourcesFiltering

and so you do not need the plugin plexus-component-metadata

HTH
Olivier
[1]
https://github.com/apache/maven-shade-plugin/tree/master/src/main/java/org/apache/maven/plugins/shade/resource
[2]
https://maven.apache.org/plugins/maven-resources-plugin/examples/custom-resource-filters.html

On Mon, 5 Sept 2022 at 06:51, PJ Fanning 
wrote:

> Hi everyone,
>
> I have another question about maven-shade-plugin. I'm wondering if there
> is an equivalent of ServicesResourceTransformer that can be used on
> resource files that appear outside META-INF/services dir.
>
> My use case involves avro-compiler.jar. It has Velocity templates that are
> used to generate Java classes and I need to modify to relocate the package
> names - the same relocation that maven-shade-plugin already does for the
> class files.
>
> Any pointers would be appreciated.
>
> Regards,
> PJ
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: m-javadoc-plugin with JPMS

[Olivier Lamy]

On Tue, 19 Jul 2022 at 16:42, Maxim Solodovnik  wrote:

> On Tue, 19 Jul 2022 at 13:16, Daniel Widdis  wrote:
> >
> > > The only problem of having both is redundancy :)
> >
> > Technically speaking, you always have an automatic module name even if
> you don't explicitly name it.  It will use your jar filename to deduce
> one.   Unless you use a reserved word in your jar, and then the world
> breaks. __
>
> I thought maybe this is the issue in m-javadoc-plugin: it is weird to
> check `automatic module name` in manifest if module-info.java present
>

Sounds possibly a bug.
Do you have an easy project to reproduce you could provide?



>
>
> >
> > On 7/18/22, 11:07 PM, "Maxim Solodovnik"  wrote:
> >
> > Thanks for the answer Daniel :)
> >
> > On Tue, 19 Jul 2022 at 13:03, Daniel Widdis 
> wrote:
> > >
> > > I think you're asking on the right list.  And it's not a "basic"
> question but it isn't an obvious answer either.
> > >
> > > I'm not sure your question has enough detail for anyone to deduce
> the answer.  Linking to your project may help you get more attention on it.
> > >
> > > FWIW, I have both an automatic module name and module-info in my
> modular projects and it doesn't cause any problems, but that's clearly not
> your problem.
> >
> > The only problem of having both is redundancy :)
> > (and they should be in-sync)
> >
> > everything works as expected in case `Automatic-Module-Name` is in
> manifest
> >
> > I'll try to create simple project to illustrate the problem :)
> >
> > >
> > > On 7/18/22, 10:55 PM, "Maxim Solodovnik" 
> wrote:
> > >
> > > Hello,
> > >
> > > Is the question too basic?
> > > Or maybe I'm asking wrong list? :)
> > >
> > > On Fri, 15 Jul 2022 at 15:41, Maxim Solodovnik <
> solomax...@gmail.com> wrote:
> > > >
> > > > Hello All,
> > > >
> > > > I'm trying to migrate our project to JPMS
> > > > After adding module-info.java to my modules (and removing
> explicitly
> > > > set `Automatic-Module-Name`)
> > > > I'm getting:
> > > >
> > > > [INFO] --- maven-javadoc-plugin:3.4.0:javadoc-no-fork
> (default)
> > > > [ERROR] Creating an aggregated report for both named and
> unnamed
> > > > modules is not possible.
> > > > [ERROR] Ensure that every module has a module descriptor or
> is a jar
> > > > with a MANIFEST.MF containing an Automatic-Module-Name.
> > > >
> > > > I thought `Automatic-Module-Name` should be added only if
> > > > `module-info.java` is missing
> > > > Is it bug in maven-javadoc-plugin or maybe I'm doing
> something wrong? :)
> > > >
> > > > java 17
> > > > Apache Maven 3.8.5
> > > >
> > > > --
> > > > Best regards,
> > > > Maxim
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Maxim
> > >
> > >
>  -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> > >
> > >
> > >
> -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> >
> >
> > --
> > Best regards,
> > Maxim
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
>
> --
> Best regards,
> Maxim
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: JPMS – Test sources extra Java SE module dependencies

[Olivier Lamy]

be careful with " module-info.test in your test directory"
it's not supported by all IDE

On Sun, 3 Jul 2022 at 15:57, Stanimir Stamenkov 
wrote:

> Thank you for the wonderful reference and summary, Daniel!
>
> While I'm parsing the information along with all its references, indeed
> it seems a well-known path.  I'm glad people have taken it to that great
> extent, and have provided guidelines and solutions to newcomers like me.
>
> – Stanimir
>
>
> Sat, 02 Jul 2022 21:00:41 -0700, /Daniel Widdis/:
>
> > You are traveling a well-known path to many of us.
> >
> > I highly recommend taking a look at junit-platform-maven-plugin:
> > https://github.com/sormuras/junit-platform-maven-plugin
> >
> > Blog post outlining how to do what you'e doing is here:
> >
> https://sormuras.github.io/blog/2018-09-11-testing-in-the-modular-world.html
> >
> > TLDR:
> > 1. you keep the one module-info.java in your main project
> > 2. you add a module-info.test in your test directory with
> > appropriate command line entries for add-opens (to see your source
> > code) and add-reads (essentially replacing the additional
> > "requires")
> >
> >
> > On 7/2/22, 4:46 PM, "Stanimir Stamenkov" 
> wrote:
> >
> >  I can't figure out what's the best practice or just proper way for
> >  setting up a JPMS Maven project with test sources that have
> additional
> >  Java SE module dependencies to those of the main sources.
> > [...]
>
> --
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

[ANN] Apache Maven Surefire 3.0.0-M7 Released

[Olivier Lamy]

Hi
The Apache Maven team is pleased to announce the release of the Apache
Maven Surefire version 3.0.0-M7.

https://maven.apache.org/surefire/index.html

Apache Maven Surefire is a test framework which include the surefire plugin
which is used during the test phase of your build.

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

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


  org.apache.maven.plugins
  maven-surefire-plugin
  3.0.0-M7


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

https://maven.apache.org/surefire/download.cgi

Release Notes - Maven Surefire - Version 3.0.0-M7


** New Feature
* [SUREFIRE-2086] - Management of temporary files


** Improvement
* [SUREFIRE-2055] - Always show random seed
* [SUREFIRE-2059] - includeJUnit5Engines and excludeJUnit5Engines have
wrong user property
* [SUREFIRE-2062] - Remove code corresponding to jdk 7 from IT tests
* [SUREFIRE-2066] - Wrong documentation "List of System properties to
pass to the JUnit tests." of systemProperties and systemPropertyVariables
* [SUREFIRE-2067] - Improve site configuration


** Bug
* [SUREFIRE-2056] - BufferOverflowException when encoding message with
null testId
* [SUREFIRE-2057] - JPMS Regression: requires static module not include
anymore
* [SUREFIRE-2058] - Corrupted STDOUT by directly writing to native
stream in forked JVM 1 with UTF-8 console logging
* [SUREFIRE-2061] - BLOCKED in surefire-forkedjvm-stream-flusher
* [SUREFIRE-2063] - Adding argLine with tab characters fails
* [SUREFIRE-2064] - Implementation of TestNG "parallel" option fails
with default value
* [SUREFIRE-2075] - Implementation of TestNG "threadCount" option
improperly overrides default value
* [SUREFIRE-2076] - BufferOverflowException when encoding message with
null runMode
* [SUREFIRE-2077] - argLine with two spaces doesn't work
* [SUREFIRE-2083] - Redundant configuration of maven-shade-plugin
* [SUREFIRE-2089] - Fail message with one non-ASCII characters and a
lot of characters lead to corruption

Enjoy,

-The Apache Maven team

Re: question java 1.7 support

[Olivier Lamy]

On Sat, 26 Mar 2022 at 2:06 pm, Nils Breunese  wrote:

> Olivier Lamy  wrote:
>
> > should be 1.7 not 1.17 ;)
>
> No, 1.7 is for Java 7. For Java 17 it should be just 17.


The email subject says “ question java 1.7 support”
But yeah should be simply 17
Use release flag rather than sources and target

>
>
> Nils.
>
> > On Sat, 26 Mar 2022 at 13:48, Alexander Ushakov <
> > alexander.ushakov.em...@gmail.com> wrote:
> >
> >> Hello!
> >>
> >> I am trying to play with Apache Kafka and craft next pom.xml
> >>
> >> ```xml
> >>
> >>  >> xmlns="http://maven.apache.org/POM/4.0.0;
> >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> >> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> >> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> >>   4.0.0
> >>   streams.examples
> >>   streams.examples
> >>   0.1
> >>   jar
> >>   Kafka Streams Demo Application
> >>   
> >>  UTF-8
> >>  3.1.0
> >>  1.7.7
> >>  1.2.17
> >>  1.17
> >>   
> >>   
> >>  
> >> apache.snapshots
> >> Apache Development Snapshot Repository
> >> 
> >> https://repository.apache.org/content/repositories/snapshots/
> >> 
> >>false
> >> 
> >> 
> >>true
> >> 
> >>  
> >>   
> >>   
> >>  
> >> 
> >>org.apache.maven.plugins
> >>maven-compiler-plugin
> >>3.1
> >>
> >>   1.17
> >>   1.17
> >>
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >>  
> >>   
> >>   
> >>  
> >> org.apache.kafka
> >> kafka-streams
> >> ${kafka.version}
> >>  
> >>  
> >> org.slf4j
> >> slf4j-api
> >> ${slf4j.version}
> >>  
> >>  
> >> org.slf4j
> >> slf4j-simple
> >> ${slf4j.version}
> >>  
> >>   
> >>
> >> ```
> >>
> >> command
> >>
> >> ```sh
> >> mvn clean package
> >> ```
> >>
> >> results with error
> >>
> >> ```
> >> [ERROR] Failed to execute goal
> >> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
> >> (default-compile) on project streams.examples: Fatal error compiling:
> >> error: invalid target release: 1.17 -> [Help 1]
> >> ```
> >>
> >> Java and Maven has been installed through SdkMan. Java 17.
> >>
> >> Can someone, please, suggest the solution?
> >>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: question java 1.7 support

[Olivier Lamy]

should be 1.7 not 1.17 ;)

On Sat, 26 Mar 2022 at 13:48, Alexander Ushakov <
alexander.ushakov.em...@gmail.com> wrote:

> Hello!
>
> I am trying to play with Apache Kafka and craft next pom.xml
>
> ```xml
>
>  xmlns="http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
>4.0.0
>streams.examples
>streams.examples
>0.1
>jar
>Kafka Streams Demo Application
>
>   UTF-8
>   3.1.0
>   1.7.7
>   1.2.17
>   1.17
>
>
>   
>  apache.snapshots
>  Apache Development Snapshot Repository
>  
> https://repository.apache.org/content/repositories/snapshots/
>  
> false
>  
>  
> true
>  
>   
>
>
>   
>  
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.1
> 
>1.17
>1.17
> 
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>   
>
>
>   
>  org.apache.kafka
>  kafka-streams
>  ${kafka.version}
>   
>   
>  org.slf4j
>  slf4j-api
>  ${slf4j.version}
>   
>   
>  org.slf4j
>  slf4j-simple
>  ${slf4j.version}
>   
>
>
> ```
>
> command
>
> ```sh
> mvn clean package
> ```
>
> results with error
>
> ```
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
> (default-compile) on project streams.examples: Fatal error compiling:
> error: invalid target release: 1.17 -> [Help 1]
> ```
>
> Java and Maven has been installed through SdkMan. Java 17.
>
> Can someone, please, suggest the solution?
>

[ANN] Apache Maven Compiler Plugin 3.10.1 Released

[Olivier Lamy]

The Apache Maven team is pleased to announce the release of the Apache
Maven Compiler Plugin, version 3.10.1

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.10.1


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.10.1

** Bug
* [MCOMPILER-346] - workaround to jdk bug: assertionError inside javac
when using javax.tools API
* [MCOMPILER-485] - Incorrect internal string format in generated
package-info.class files on Windows

** New Feature
* [MCOMPILER-426] - dedicated option for enabling preview feature

Enjoy,

-The Apache Maven team

[ANN] Apache Maven Compiler Plugin 3.10.0 Released

[Olivier Lamy]

Hi
The Apache Maven team is pleased to announce the release of the Apache
Maven Compiler Plugin, version 3.10.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.10.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.10.0

** Bug
* [MCOMPILER-205] - incremental compilation broken for package-info
classes
* [MCOMPILER-225] - javac.bat and args file added to archive when fork
and -X used
* [MCOMPILER-460] - Compiler doesn't show detailed information with the
Maven Toolchains
* [MCOMPILER-470] - -parameters doesn't work with --release
* [MCOMPILER-474] - Dependent modules are not recompiled if we run the
"package" goal
* [MCOMPILER-481] - JPMS Regression: cannot access  (requires
static module not include anymore)

** Improvement
* [MCOMPILER-479] - Clarify `compilerArgs` Javadoc

** Task
* [MCOMPILER-484] - Remove deprecated mojos

Enjoy,

-The Apache Maven team

Re: Need help for maven site plugin for Apache Helix

[Olivier Lamy]

Thanks Hervé!.
@Junkai I have merged Hervé's PR



On Sat, 20 Nov 2021 at 20:31, Hervé BOUTEMY  wrote:

> FYI, on the "SiteToolException: Error parsing site descriptor: TEXT must
> beimmediately followed by END_TAG and not START_TAG" error, the key Maven
> Site
> Plugin version is version 3.5, where the parsing of site.xml changed:
> previously it was parser as XML, and since 3.5 it is parsed as text
>
> the consequence is that in general, you need to surround head and footer
> data
> from site.xml (including parents) with 
>
> that's why Apache parent version is related to maven-site-plugin version
>
> HTH
>
> Hervé
>
> Le samedi 20 novembre 2021, 09:19:41 CET Hervé BOUTEMY a écrit :
> > Hi,
> >
> > Apache parent 13 is so old...
> >
> > see https://github.com/apache/helix/pull/1909
> > upgrading both Apache parent POM and maven-site-plugin seems to do the
> job
> >
> > Regards,
> >
> > Hervé
> >
> > Le jeudi 18 novembre 2021, 00:04:03 CET Junkai Xue a écrit :
> > > Hi,
> > >
> > > I was trying to deploy Apache Helix project website for new releases.
> Got
> > > exception on
> > >
> > > *SiteToolException: The site descriptor cannot be resolved from the
> > > repository: ArtifactResolutionException: Unable to locate site
> descriptor:
> > > Could not transfer artifact org.apache:apache:xml:site_en:13 from/to
> > > mvnrepository.com  (
> https://mvnrepository.com
> > > ): Access denied to:
> > > https://mvnrepository.com/org/apache/apache/13/apache-13-site_en.xml
> > > 
> ,
> > > ReasonPhrase:Forbidden.*
> > >
> > > [*ERROR*] *  org.apache:apache:xml:13*
> > >
> > > [*ERROR*]
> > >
> > > [*ERROR*] *from the specified remote repositories:*
> > >
> > > [*ERROR*] *  restlet.talend.com 
> > > (https://maven.restlet.talend.com ,
> > > releases=true, snapshots=false),*
> > >
> > > [*ERROR*] *  mvnrepository.com 
> > > (https://mvnrepository.com , releases=true,
> > > snapshots=false),*
> > >
> > > [*ERROR*] *  central (https://repo.maven.apache.org/maven2
> > > , releases=true,
> snapshots=false),*
> > >
> > > [*ERROR*] *  apache.snapshots (http://repository.apache.org/snapshots
> > > , releases=false,
> snapshots=true)*
> > >
> > >
> > > Was this recent change? I tried to upgrade to maven site plugin to
> 3.9.1.
> > > It got error on parsing:
> > >
> > > *SiteToolException: Error parsing site descriptor*: TEXT must be
> > > immediately followed by END_TAG and not START_TAG (position: START_TAG
> > > seen
> > > ...\n  

Re: Need help for maven site plugin for Apache Helix

[Olivier Lamy]

not sure what is the content of your ~/.m2/settings.xml but it may have
some references to some repositories?
such http://restlet.talend.com , http://repository.apache.org/snapshots.
note this http
the recent change might be you upgrading to the last maven core version?

[*INFO*] Generating "Dependencies" report---
maven-project-info-reports-plugin:2.9

[*WARNING*] The repository url 'https://mvnrepository.com' is invalid -
Repository 'mvnrepository.com' will be blacklisted.

this mean you should add a mirror in your ~/.m2/settings.xml

If you cannot deploy the website. Let me know and I can do it (I may still
have all karma on helix)

cheers
Olivier
On Thu, 18 Nov 2021 at 09:04, Junkai Xue  wrote:

> Hi,
>
> I was trying to deploy Apache Helix project website for new releases. Got
> exception on
>
> *SiteToolException: The site descriptor cannot be resolved from the
> repository: ArtifactResolutionException: Unable to locate site descriptor:
> Could not transfer artifact org.apache:apache:xml:site_en:13 from/to
> mvnrepository.com  (https://mvnrepository.com
> ): Access denied to:
> https://mvnrepository.com/org/apache/apache/13/apache-13-site_en.xml
>  ,
> ReasonPhrase:Forbidden.*
>
> [*ERROR*] *  org.apache:apache:xml:13*
>
> [*ERROR*]
>
> [*ERROR*] *from the specified remote repositories:*
>
> [*ERROR*] *  restlet.talend.com 
> (https://maven.restlet.talend.com ,
> releases=true, snapshots=false),*
>
> [*ERROR*] *  mvnrepository.com 
> (https://mvnrepository.com , releases=true,
> snapshots=false),*
>
> [*ERROR*] *  central (https://repo.maven.apache.org/maven2
> , releases=true, snapshots=false),*
>
> [*ERROR*] *  apache.snapshots (http://repository.apache.org/snapshots
> , releases=false, snapshots=true)*
>
>
> Was this recent change? I tried to upgrade to maven site plugin to 3.9.1.
> It got error on parsing:
>
> *SiteToolException: Error parsing site descriptor*: TEXT must be
> immediately followed by END_TAG and not START_TAG (position: START_TAG seen
> ...\n  

Re: jakarta ee 9 ear compatibility

[Olivier Lamy]

Hi
We should definitely support jakarta namespace as well.
Can you create an issue with a sample project?


On Tue, 15 Jun 2021 at 15:38, d kech  wrote:

> Hello,
>
> I have been trying to build an ear project after I upgraded it to jakarta
> ee 9  and tried to deploy it on Glassfish 6.1 but  it seems ear plugin does
> not support ee 9 yet. Specifically the war module was not getting packaged
> in contrast to the ejb module.
> I would like to know if  maven-ear-plugin is going to support  jakarta ee
> 9 soon or if there is any other way to build ear with maven.
>
> Thanks in advance.
> Dionysos
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Authentication Header (maven-metadata.xml)

[Olivier Lamy]

your repository can be protected even for reading and how Maven could know
it's not?
as long as there is an entry in ~/.m2/settings,xml with an id corresponding
to the same id in your pom the authz will be sent.
If this is really a problem (if you use https it shouldn't be) you can have
a look at some extra configuration here
https://maven.apache.org/guides/mini/guide-http-settings.html
HTH
--
Olivier

On Sun, 6 Jun 2021 at 22:29, Eduardo Souza 
wrote:

> Hi,
>
> Is there any reason to not send the authentication header when downloading
> the maven-metadata.xml file in the deploy phase when the artifact is
> snapshot?
>
> Eduardo Souza
> eduardomatoso...@gmail.com
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: HTTP/2 support in Maven

[Olivier Lamy]

There is some effort started here
https://github.com/jetty-project/jetty-maven-wagon
but this needs more tests/debug etc...
feel free to test,m report issues, propose fix etc...

On Fri, 23 Oct 2020 at 18:09, Jakub Bartecek  wrote:

> Hello,
> I'd like to ask if it is possible to turn on HTTP/2 support in Maven. I
> haven't found such an option.
>
> If not: Are there any plans to add the support?
>
> Regards,
> Kuba
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Javadoc aggregate fails with MDEP-187 with dependency plugin

[Olivier Lamy]

Hi
what are the prepareGoals/goals of the release plugin?
maybe you could use package javadoc:aggregate-jar deploy
I know this will trigger few times the same lifecycle/goals and will add
few times the same jar to the artifacts to deploy but it should work.

On Mon, 1 Jun 2020 at 22:33, Alex O'Ree  wrote:

> I'm attempting to, with a release profile, build javadoc jars for all
> modules in my project and generate a single aggregate javadoc jar for the
> whole project, preferable with just running 'mvn -PmyReleaseProfile
> install'. Is this possible?
>
> In my case i have a few modules that use the dependency plugin to copy
> dependencies to a specific location. This seems to interfer with the
> javadoc aggregate setup.I've attempted this a few times and keep getting
> the MDEP-187 error message. Removing the aggregate javadoc jar setup
> resolves the issue.
>
> Any suggestions on how to resolve this?
>
> using maven-dependency-plugin 3.0.0 and maven-javadoc-plugin 3.2.0
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: slf4j-jcl-1.0.1: Checksum validation failed

[Olivier Lamy]

Maven Central is managed by Sonatype read term of services
https://repo1.maven.org/terms.html

You should report this issue here
https://issues.sonatype.org/projects/MVNCENTRAL

On Sat, 23 May 2020 at 02:04, Tomo Suzuki 
wrote:

> Hi Maven users,
>
> Does anyone know why slf4j-jcl-1.0.1's checksum is invalid in Maven
> Central?
>
> I'm investigating the following warning message:
>
> [WARNING] Could not validate integrity of download from
>
> https://repo1.maven.org/maven2/org/slf4j/slf4j-jcl/1.0.1/slf4j-jcl-1.0.1.pom
> :
> Checksum validation failed, expected
> 7035ae7774a9a082a316a6943bbad9dfab6319b3 but is
> c5c0a3fff6071a4c720f1b7aa1b66cb9d0b26a21
>
> When I checked
>
> https://repo1.maven.org/maven2/org/slf4j/slf4j-jcl/1.0.1/slf4j-jcl-1.0.1.pom.sha1
> ,
> it has
>
> 7035ae7774a9a082a316a6943bbad9dfab6319b3
>
>  
> /home/projects/maven/repository-staging/to-ibiblio/maven2/org/slf4j/slf4j-jcl/1.0.1/slf4j-jcl-1.0.1.pom
>
> However, curl and sha1sum say otherwise:
>
> suztomo@suztomo:~/spring-cloud-gcp$ curl
>
> https://repo1.maven.org/maven2/org/slf4j/slf4j-jcl/1.0.1/slf4j-jcl-1.0.1.pom
> |sha1sum
> <https://repo1.maven.org/maven2/org/slf4j/slf4j-jcl/1.0.1/slf4j-jcl-1.0.1.pom%7Csha1sum>
>   % Total% Received % Xferd  Average Speed   TimeTime Time
>  Current
>  Dload  Upload   Total   SpentLeft
>  Speed
> 100   394  100   3940 0   4061  0 --:--:-- --:--:-- --:--:--
>  4104
> c5c0a3fff6071a4c720f1b7aa1b66cb9d0b26a21  -
>
> So from my perspective, the discrepancy is in line with the Maven warning
> message. Maven Central is hosting invalid checksum files. Does anyone know
> why this discrepancy happens slf4j-jcl-1.0.1?
>
> --
> Regards,
> Tomo
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Accessing a nexus repository requiring a client certificate

[Olivier Lamy]

You may have to change some APIs
 Wagon is a very old API (back to when Maven2 was born... yup that's long
time ago now :) )
so definitely it could be changed BUT we have to maintain a backward compat
as much as we can

On Mon, 18 May 2020 at 11:36, Alex O'Ree  wrote:

> Cool. i'll keep hacking away when i have time. Looks like it'll have to
> merged in order...
> wagon
> resolver
> maven proper
>
> assuming i can get it to work
>
>
> On Sun, May 17, 2020 at 8:15 PM Olivier Lamy  wrote:
>
> > Aether is now maven-resolver project so maintainers will look at your
> > proposal :)
> >
> > On Mon, 18 May 2020 at 10:11 am, Alex O'Ree  wrote:
> >
> > > Well after a few different experiments with what i've describe above,
> the
> > > issue i'm having setting ensuring that setting.xml parameters get
> passed
> > > into wagon. Currently, it looks like i need to change both maven core,
> > some
> > > of the wagon based code and aether wagonTransporter. Hopefully aether
> > > maintainers will be open to this
> > >
> > >
> > > On Sun, May 17, 2020 at 5:47 PM Michael Osipov 
> > > wrote:
> > >
> > > > It completely depends how Resolver is created and how/when a Wagon
> > > > instance is created. If Resolver exists once during a Maven session
> and
> > > > hopefully Wagon only once, but I don't know. Another issue with the
> > > > current code is that the client is never properly shut down. I.e.g,
> no
> > > > sockets are freed and the peer has to handle broken connections.
> > > >
> > > > M
> > > >
> > > > Am 2020-05-17 um 23:42 schrieb Olivier Lamy:
> > > > > Oh Yes I agree the current API would need major (breaking?)
> changes.
> > > > > But openConnectionInternal creating client would not reuse http
> > > > connection
> > > > > (or you have another idea?)
> > > > > It was a bit of hackish to have http connection pooling due to
> > current
> > > > > design but especially with https it saves some IO.
> > > > >
> > > > >
> > > > >
> > > > > On Mon, 18 May 2020 at 01:53, Michael Osipov 
> > > > wrote:
> > > > >
> > > > >> Alex, I will get back to you in a couple of days because it is a
> lot
> > > of
> > > > >> work. But already agree, the current approach in Wagon makes it
> > > > >> impossible to hook in TLS mutual auth and
> #openConnectionInternal()
> > > must
> > > > >> create the client upon call.
> > > > >>
> > > > >> M
> > > > >>
> > > > >> Am 2020-05-17 um 17:31 schrieb Alex O'Ree:
> > > > >>> Pinging you back again on this. Adding support for this (i think)
> > it
> > > > >> going
> > > > >>> to require some significant changes to the abstract http client
> > wagon
> > > > >>> class. Client certificate authentication, on a per endpoint
> > > basis,would
> > > > >>> require separate ssl socket factories, which is constructed
> before
> > > the
> > > > >>> pooling http client connection manager. Having everything static
> > > makes
> > > > >> this
> > > > >>> difficult to implement without potentially breaking any other
> > plugin
> > > > that
> > > > >>> uses this class programmatically. Would perhaps changing
> > > > >>> 'openConnectionInternal' be a better option for hooking this?
> I.e.
> > if
> > > > we
> > > > >>> have a user defined key/trust setup, make a new configuration
> > within
> > > > this
> > > > >>> method, otherwise fallback to the default static pool?
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On Mon, May 11, 2020 at 7:10 PM Alex O'Ree 
> > > > wrote:
> > > > >>>
> > > > >>>> I did some work on this over the weekend. Maintaining backwards
> > > > >>>> compatibility is going to be challenging due to the http
> > connection
> > > > pool
> > > > >>>> being static. Since the http client now needs to be specific to
> a
> > > > >>>

Re: Accessing a nexus repository requiring a client certificate

[Olivier Lamy]

Aether is now maven-resolver project so maintainers will look at your
proposal :)

On Mon, 18 May 2020 at 10:11 am, Alex O'Ree  wrote:

> Well after a few different experiments with what i've describe above, the
> issue i'm having setting ensuring that setting.xml parameters get passed
> into wagon. Currently, it looks like i need to change both maven core, some
> of the wagon based code and aether wagonTransporter. Hopefully aether
> maintainers will be open to this
>
>
> On Sun, May 17, 2020 at 5:47 PM Michael Osipov 
> wrote:
>
> > It completely depends how Resolver is created and how/when a Wagon
> > instance is created. If Resolver exists once during a Maven session and
> > hopefully Wagon only once, but I don't know. Another issue with the
> > current code is that the client is never properly shut down. I.e.g, no
> > sockets are freed and the peer has to handle broken connections.
> >
> > M
> >
> > Am 2020-05-17 um 23:42 schrieb Olivier Lamy:
> > > Oh Yes I agree the current API would need major (breaking?) changes.
> > > But openConnectionInternal creating client would not reuse http
> > connection
> > > (or you have another idea?)
> > > It was a bit of hackish to have http connection pooling due to current
> > > design but especially with https it saves some IO.
> > >
> > >
> > >
> > > On Mon, 18 May 2020 at 01:53, Michael Osipov 
> > wrote:
> > >
> > >> Alex, I will get back to you in a couple of days because it is a lot
> of
> > >> work. But already agree, the current approach in Wagon makes it
> > >> impossible to hook in TLS mutual auth and #openConnectionInternal()
> must
> > >> create the client upon call.
> > >>
> > >> M
> > >>
> > >> Am 2020-05-17 um 17:31 schrieb Alex O'Ree:
> > >>> Pinging you back again on this. Adding support for this (i think) it
> > >> going
> > >>> to require some significant changes to the abstract http client wagon
> > >>> class. Client certificate authentication, on a per endpoint
> basis,would
> > >>> require separate ssl socket factories, which is constructed before
> the
> > >>> pooling http client connection manager. Having everything static
> makes
> > >> this
> > >>> difficult to implement without potentially breaking any other plugin
> > that
> > >>> uses this class programmatically. Would perhaps changing
> > >>> 'openConnectionInternal' be a better option for hooking this? I.e. if
> > we
> > >>> have a user defined key/trust setup, make a new configuration within
> > this
> > >>> method, otherwise fallback to the default static pool?
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Mon, May 11, 2020 at 7:10 PM Alex O'Ree 
> > wrote:
> > >>>
> > >>>> I did some work on this over the weekend. Maintaining backwards
> > >>>> compatibility is going to be challenging due to the http connection
> > pool
> > >>>> being static. Since the http client now needs to be specific to a
> > >>>> repository or destination, i'm not sure if that configuration will
> > still
> > >>>> work. Anyhow, i ended up down a rat role of trying to understand why
> > >> some
> > >>>> of the unit tests were failing and making it worse in the process.
> > >>>>
> > >>>> On Wed, May 6, 2020 at 6:38 AM Michael Osipov 
> > >> wrote:
> > >>>>
> > >>>>> Am 2020-05-05 um 22:03 schrieb Alex O'Ree:
> > >>>>>> I was looking over the docs for the settings.xml file and noted
> that
> > >> it
> > >>>>>> looks like it's possible to access a nexus repository using a
> client
> > >>>>>> certificate of sorts. It's not clear the docs if a JKS can be used
> > or
> > >>>>> if it
> > >>>>>> must be a ssh private key or what.
> > >>>>>>
> > >>>>>> http://maven.apache.org/settings.html#servers
> > >>>>>>
> > >>>>>> I wanted to confirm that the linked docs is still accurate? I
> have a
> > >> few
> > >>>>>> different use cases and may need to reference a client cert key
> pair
> > >> in
> > >>>>> a
> > >>>>

Re: Accessing a nexus repository requiring a client certificate

[Olivier Lamy]

Oh Yes I agree the current API would need major (breaking?) changes.
But openConnectionInternal creating client would not reuse http connection
(or you have another idea?)
It was a bit of hackish to have http connection pooling due to current
design but especially with https it saves some IO.



On Mon, 18 May 2020 at 01:53, Michael Osipov  wrote:

> Alex, I will get back to you in a couple of days because it is a lot of
> work. But already agree, the current approach in Wagon makes it
> impossible to hook in TLS mutual auth and #openConnectionInternal() must
> create the client upon call.
>
> M
>
> Am 2020-05-17 um 17:31 schrieb Alex O'Ree:
> > Pinging you back again on this. Adding support for this (i think) it
> going
> > to require some significant changes to the abstract http client wagon
> > class. Client certificate authentication, on a per endpoint basis,would
> > require separate ssl socket factories, which is constructed before the
> > pooling http client connection manager. Having everything static makes
> this
> > difficult to implement without potentially breaking any other plugin that
> > uses this class programmatically. Would perhaps changing
> > 'openConnectionInternal' be a better option for hooking this? I.e. if we
> > have a user defined key/trust setup, make a new configuration within this
> > method, otherwise fallback to the default static pool?
> >
> >
> >
> >
> > On Mon, May 11, 2020 at 7:10 PM Alex O'Ree  wrote:
> >
> >> I did some work on this over the weekend. Maintaining backwards
> >> compatibility is going to be challenging due to the http connection pool
> >> being static. Since the http client now needs to be specific to a
> >> repository or destination, i'm not sure if that configuration will still
> >> work. Anyhow, i ended up down a rat role of trying to understand why
> some
> >> of the unit tests were failing and making it worse in the process.
> >>
> >> On Wed, May 6, 2020 at 6:38 AM Michael Osipov 
> wrote:
> >>
> >>> Am 2020-05-05 um 22:03 schrieb Alex O'Ree:
> >>>> I was looking over the docs for the settings.xml file and noted that
> it
> >>>> looks like it's possible to access a nexus repository using a client
> >>>> certificate of sorts. It's not clear the docs if a JKS can be used or
> >>> if it
> >>>> must be a ssh private key or what.
> >>>>
> >>>> http://maven.apache.org/settings.html#servers
> >>>>
> >>>> I wanted to confirm that the linked docs is still accurate? I have a
> few
> >>>> different use cases and may need to reference a client cert key pair
> in
> >>> a
> >>>> JKS or perhaps from the windows certificate store for authentication
> to
> >>> the
> >>>> nexus repository. Is still a supported configuration by maven? I found
> >>> some
> >>>> references to support here:
> >>> https://issues.apache.org/jira/browse/MNG-1560
> >>>> which references setting maven options for javax.net.ssl.* settings.
> >>>> Considering the environment, i'll probably need to be able to specify
> >>> the
> >>>> key alias name too, just in case there's multiple certificates
> >>> available.
> >>>>
> >>>
> >>> MNG-5583. I have intentionally closed this one since no was willing to
> >>> work on it. If someone wants to work on it, I'd be happy to discuss.
> >>>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Launching full Maven programmatically

[Olivier Lamy]

yup but as I said it's only bug to fix but it's something which can
be embedded. As I understand this is what Andres need.
Most of the project can be loaded with it as long as long they are simple
(i.e no core extension in .mvn etc...)
maven-flatten-plugin will not really help as it's already a maven plugin so
the mojo can access all the maven mechanism (components etc...) so you need
to already start maven.
We probably need to know more about the Andres's context

On Fri, 17 Apr 2020 at 19:26, Matthieu BROUILLARD 
wrote:

> Sorry but it is fully in the subject of the thread.
> Andres wants a way to programatically load a POM object. I guess he wants a
> way to load a correctly resolved POM not a partially resolved one.
>
> On Fri, Apr 17, 2020 at 11:02 AM Olivier Lamy  wrote:
>
> > yes maybe some stuff to fix (feel free to send a PR :P )
> > But it's not the subject of the thread :)
> > But did you try without all the Jenkins but only the mentioned library?
> > It's not too hard to fix (the code pointed in this thread may have the
> same
> > issue)
> >
> >
> > On Fri, 17 Apr 2020 at 18:49, Matthieu BROUILLARD <
> matth...@brouillard.fr>
> > wrote:
> >
> > > Olivier,
> > >
> > > If the project you are pointing is what is behind "Maven Integration"
> in
> > > Jenkins then it does things wrong by not taking into account maven
> > > core-extensions.
> > >
> > > I just retested now:
> > > - download Jenkins.war 2.232
> > > - launch as java -jar
> > > - default installation
> > > - add plugin "Maven integration"
> > > - in settings add a local JDK 11
> > > - in settings add a default maven 3.6.3
> > > - create new job "jgitver in jenkins"
> > > - set git url : https://github.com/jgitver/jgitver.git
> > > - set goal : validate
> > > - run the job
> > >
> > > You will see in the output that the version of the project is 0 whereas
> > it
> > > should have been computed by a core extension.
> > >
> > > ...
> > > [INFO] -< fr.brouillard.oss:jgitver
> > > >--
> > > [INFO] Building GIT versioning using jgit 0
> > > [INFO] [ jar
> > > ]-
> > > ...
> > >
> > >
> > > If you do the same in CMD/sh you should see the automatic computation
> > >
> > > [INFO] Using jgitver configuration file:
> > > C:\workspace\projects\oss\jgitver\jgitver-lib\.mvn\jgitver.config.xml
> > > [INFO] Using jgitver-maven-plugin [1.5.1] (sha1:
> > > e45d1669b39cedb98720dd33cc14d0185b455ca1)
> > > [INFO] version '0.12.1-SNAPSHOT' computed in 15595 ms
> > > [INFO]
> > > [INFO] Scanning for projects...
> > > [INFO] jgitver-maven-plugin is about to change project(s) version(s)
> > > [INFO] fr.brouillard.oss::jgitver::0 -> 0.12.1-SNAPSHOT
> > > [INFO]
> > > [INFO] -< fr.brouillard.oss:jgitver
> > > >--
> > > [INFO] Building GIT versioning using jgit 0.12.1-SNAPSHOT
> > > [INFO] [ jar
> > > ]-
> > > ...
> > >
> > > This is not particular to jgitver but to any core extension (takari
> > > polyglot, tycho pom less, ...).
> > > The way this jenkins project loads the Maven Project Object Model is
> > > somehow wrong or at least not complete.
> > >
> > > IMO the POM loading is better done in maven-flatten-plugin.
> > >
> > > Matthieu
> > >
> > > On Fri, Apr 17, 2020 at 6:00 AM Olivier Lamy  wrote:
> > >
> > > > Hi,
> > > >
> > > > That's the way to do it
> > > > There is a library to ease that here
> > > > https://github.com/jenkinsci/lib-jenkins-maven-embedder/tree/master
> > > >
> > > > cheers
> > > > Olivier
> > > >
> > > >
> > > > On Fri, 17 Apr 2020 at 13:04, Tomo Suzuki  >
> > > > wrote:
> > > >
> > > > > I'm interested in that problem too. In the project below, we use
> > > > > PlexusContainer to instantiate MavenProject class from pom file:
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/master/dependencies/src/main/java/com/go

Re: Launching full Maven programmatically

[Olivier Lamy]

yes maybe some stuff to fix (feel free to send a PR :P )
But it's not the subject of the thread :)
But did you try without all the Jenkins but only the mentioned library?
It's not too hard to fix (the code pointed in this thread may have the same
issue)


On Fri, 17 Apr 2020 at 18:49, Matthieu BROUILLARD 
wrote:

> Olivier,
>
> If the project you are pointing is what is behind "Maven Integration" in
> Jenkins then it does things wrong by not taking into account maven
> core-extensions.
>
> I just retested now:
> - download Jenkins.war 2.232
> - launch as java -jar
> - default installation
> - add plugin "Maven integration"
> - in settings add a local JDK 11
> - in settings add a default maven 3.6.3
> - create new job "jgitver in jenkins"
> - set git url : https://github.com/jgitver/jgitver.git
> - set goal : validate
> - run the job
>
> You will see in the output that the version of the project is 0 whereas it
> should have been computed by a core extension.
>
> ...
> [INFO] -< fr.brouillard.oss:jgitver
> >--
> [INFO] Building GIT versioning using jgit 0
> [INFO] [ jar
> ]-
> ...
>
>
> If you do the same in CMD/sh you should see the automatic computation
>
> [INFO] Using jgitver configuration file:
> C:\workspace\projects\oss\jgitver\jgitver-lib\.mvn\jgitver.config.xml
> [INFO] Using jgitver-maven-plugin [1.5.1] (sha1:
> e45d1669b39cedb98720dd33cc14d0185b455ca1)
> [INFO] version '0.12.1-SNAPSHOT' computed in 15595 ms
> [INFO]
> [INFO] Scanning for projects...
> [INFO] jgitver-maven-plugin is about to change project(s) version(s)
> [INFO] fr.brouillard.oss::jgitver::0 -> 0.12.1-SNAPSHOT
> [INFO]
> [INFO] -< fr.brouillard.oss:jgitver
> >--
> [INFO] Building GIT versioning using jgit 0.12.1-SNAPSHOT
> [INFO] [ jar
> ]-
> ...
>
> This is not particular to jgitver but to any core extension (takari
> polyglot, tycho pom less, ...).
> The way this jenkins project loads the Maven Project Object Model is
> somehow wrong or at least not complete.
>
> IMO the POM loading is better done in maven-flatten-plugin.
>
> Matthieu
>
> On Fri, Apr 17, 2020 at 6:00 AM Olivier Lamy  wrote:
>
> > Hi,
> >
> > That's the way to do it
> > There is a library to ease that here
> > https://github.com/jenkinsci/lib-jenkins-maven-embedder/tree/master
> >
> > cheers
> > Olivier
> >
> >
> > On Fri, 17 Apr 2020 at 13:04, Tomo Suzuki 
> > wrote:
> >
> > > I'm interested in that problem too. In the project below, we use
> > > PlexusContainer to instantiate MavenProject class from pom file:
> > >
> > >
> >
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/master/dependencies/src/main/java/com/google/cloud/tools/opensource/dependencies/RepositoryUtility.java#L209
> > >
> > > I hope there's a better way to achieve this.
> > >
> > > On Thu, Apr 16, 2020 at 6:55 AM Andres Almiray 
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > I'm looking for a way to launch Maven programmatically in such a way
> > > that I
> > > > can get access to fully resolved Model and MavenProject instances,
> and
> > > not
> > > > just for a single project but also for all projects that belong to a
> > > > Reactor.
> > > >
> > > > At first I used this code
> > > >
> > > > try {
> > > > FileReader reader = new FileReader(pom);
> > > > MavenXpp3Reader mavenReader = new MavenXpp3Reader();
> > > > return new MavenProject(mavenReader.read(reader));
> > > > } catch (Exception e) {
> > > > throw new IllegalArgumentException(e);
> > > > }
> > > >
> > > > But of course that's not enough. Next I tried using the
> > > maven-model-builder
> > > > APIs directly but not all references get resolved (such as parent
> POMs)
> > > as
> > > > a custom ModelResolver is required and the default one is not
> intended
> > to
> > > > be used in standalone fashion.
> > > >
> > > > Ideally I would call some sort of embeddable Maven API that can give
> me
> > > the
> > > > answers I seek, something like this
> > > >
> > > > MavenProject project =
> > > EmbeddableMaven.launch(propsOrFlags).file(pomFile);
> > > >
> > > > or alternatively something like
> > > >
> > > > MavenReactor reactor =
> > > EmbeddableMaven.launch(propsOrFlags).file(pomFile);
> > > > for(MavenProject project : reactor.getProjects()) { /* do stuff */ }
> > > >
> > > > Of course I'm making up these types and method names as I do not know
> > if
> > > > something like this exist or not, hence why I'm asking here.
> > > >
> > > > Thanks in advance.
> > > >
> > > > Cheers
> > > > Andres
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Tomo
> > >
> >
> >
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Launching full Maven programmatically

[Olivier Lamy]

Hi,

That's the way to do it
There is a library to ease that here
https://github.com/jenkinsci/lib-jenkins-maven-embedder/tree/master

cheers
Olivier


On Fri, 17 Apr 2020 at 13:04, Tomo Suzuki 
wrote:

> I'm interested in that problem too. In the project below, we use
> PlexusContainer to instantiate MavenProject class from pom file:
>
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/master/dependencies/src/main/java/com/google/cloud/tools/opensource/dependencies/RepositoryUtility.java#L209
>
> I hope there's a better way to achieve this.
>
> On Thu, Apr 16, 2020 at 6:55 AM Andres Almiray  wrote:
>
> > Hi,
> >
> > I'm looking for a way to launch Maven programmatically in such a way
> that I
> > can get access to fully resolved Model and MavenProject instances, and
> not
> > just for a single project but also for all projects that belong to a
> > Reactor.
> >
> > At first I used this code
> >
> > try {
> > FileReader reader = new FileReader(pom);
> > MavenXpp3Reader mavenReader = new MavenXpp3Reader();
> > return new MavenProject(mavenReader.read(reader));
> > } catch (Exception e) {
> > throw new IllegalArgumentException(e);
> > }
> >
> > But of course that's not enough. Next I tried using the
> maven-model-builder
> > APIs directly but not all references get resolved (such as parent POMs)
> as
> > a custom ModelResolver is required and the default one is not intended to
> > be used in standalone fashion.
> >
> > Ideally I would call some sort of embeddable Maven API that can give me
> the
> > answers I seek, something like this
> >
> > MavenProject project =
> EmbeddableMaven.launch(propsOrFlags).file(pomFile);
> >
> > or alternatively something like
> >
> > MavenReactor reactor =
> EmbeddableMaven.launch(propsOrFlags).file(pomFile);
> > for(MavenProject project : reactor.getProjects()) { /* do stuff */ }
> >
> > Of course I'm making up these types and method names as I do not know if
> > something like this exist or not, hence why I'm asking here.
> >
> > Thanks in advance.
> >
> > Cheers
> > Andres
> >
>
>
> --
> Regards,
> Tomo
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

[ANN] Apache Maven Javadoc Plugin 3.2.0 Released

[Olivier Lamy]

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

The Javadoc Plugin uses the Javadoc tool to generate javadocs for the
specified project

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

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


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


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

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

Release Notes - Maven Javadoc Plugin - Version 3.2.0

** Bug
* [MJAVADOC-607] - followLinks fix to get redirect target breaks for
certain sites
* [MJAVADOC-609] - Include jars for which module name cannot be
determined on the classpath
* [MJAVADOC-612] - UnsupportedOperationException for javadoc:aggregate
with multi modules with jpms
* [MJAVADOC-616] - JavadocReportTest.testOptionsUmlautEncoding fails on
Windows with default ecnoding that does not support umlauts
* [MJAVADOC-620] - Maven Javadoc Plugin fails to resolve the
dependencies when used with Java 11
* [MJAVADOC-639] - aggregate should use all requires static from maven
modules

** Improvement
* [MJAVADOC-613] - Exclude some modules with aggregate goals
* [MJAVADOC-626] - Detect stale files and skip generation if not needed
* [MJAVADOC-632] - agggregate using jpms and non jar module is failing
* [MJAVADOC-636] - Exclude some modules when building aggregate
* [MJAVADOC-637] - make build Reproducible
* [MJAVADOC-640] - Ability to exclude maven modules from javadoc
aggregate goals

** New Feature
* [MJAVADOC-627] - Reproducible Builds: make entries in output jar
files reproducible (order + timestamp)

Enjoy,
-The Apache Maven team

[ANN] Apache Maven Javadoc Plugin 3.1.1 Released

[Olivier Lamy]

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

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

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


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


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

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

Release Notes - Maven Javadoc Plugin - Version 3.1.1

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

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

Enjoy,

-The Apache Maven team

Re: Maven 3.6.1 & Central Sync Requirements

[Olivier Lamy]

Hi
You have to report this here https://issues.sonatype.org/projects/MVNCENTRAL
and/or the mailing list ossrh-us...@sonatype.org
HTH
Olivier

On Fri, 10 May 2019 at 11:34, Anthony Whitford  wrote:

> My open source project upgraded to Maven 3.6.1 and added
> child.scm.url.inherit.append.path=“false” to the scm tag to correct the
> Source Code Management links:
>
>   http://oss.sonatype.org/>:
> Sources Validation
> POM Validation
> Javadoc Validation
>
> Each validation reports:
>
> > Illegal POM: /org/projectlombok/lombok-maven/
> 1.18.8.0/lombok-maven-1.18.8.0.pom Unknown attribute
> 'child.scm.url.inherit.append.path' for tag 'scm' (position: START_TAG seen
> .../modules>\n\n scm child.scm.url.inherit.append.path="false">...
> @39:50)
>
> Who needs to fix this?  Is this on anyones radar?
>
>

-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: windows 10 scm git authentication

[Olivier Lamy]

Hi
The jgitflow plugin is not maintained here.
You should ask here
https://bitbucket.org/atlassian/jgit-flow

HTH
Olivier

On Tue, 18 Dec 2018 at 8:35 pm, Matthew Broadhead
 wrote:

> i have recently switched from ubuntu to windows 10 and i am having
> problems authenticating the scm from either a command prompt or git shell.
> mvn jgitflow:release-start
>
> it fails with
> [ERROR] Failed to execute goal
> external.atlassian.jgitflow:jgitflow-maven-plugin:1.0-m5.1:release-start
> (default-cli) on project case-management: Error starting release: Error
> starting release: org.eclipse.jgit.api.errors.TransportException:
> g...@www.kissy.me.uk:matthew.broadhead/case-management.git: Auth fail ->
> [Help 1]
>
> if i run with the -X switch it shows it is using my settings.xml
> [DEBUG] Reading global settings from
> C:\Java\apache-maven-3.6.0\conf\settings.xml
> [DEBUG] Reading user settings from C:\Users\Matthew
> Broadhead\.m2\settings.xml
> [DEBUG] Reading global toolchains from
> C:\Java\apache-maven-3.6.0\conf\toolchains.xml
> [DEBUG] Reading user toolchains from C:\Users\Matthew
> Broadhead\.m2\toolchains.xml
> [DEBUG] Using local repository at C:\Users\Matthew Broadhead\.m2\repository
> [DEBUG] Using manager EnhancedLocalRepositoryManager with priority 10.0
> for C:\Users\Matthew Broadhead\.m2\repository
>
> in settings.xml i have added a link to my private key like the below.  i
> have tried every combination i can think of for this including passwords
> etc.
> 
>  www.kissy.me.uk
>  git -->
> ${user.home}/.ssh/id_rsa
>  
>
> the debugging doesn't give me much information as to what is actually
> failing
> Caused by: com.jcraft.jsch.JSchException: Auth fail
>  at com.jcraft.jsch.Session.connect (Session.java:512)
>  at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession
> (JschConfigSessionFactory.java:116)
>  at org.eclipse.jgit.transport.SshTransport.getSession
> (SshTransport.java:136)
>  at
> org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.
> (TransportGitSsh.java:262)
>  at org.eclipse.jgit.transport.TransportGitSsh.openFetch
> (TransportGitSsh.java:161)
>  at org.eclipse.jgit.transport.FetchProcess.executeImp
> (FetchProcess.java:136)
>  at org.eclipse.jgit.transport.FetchProcess.execute
> (FetchProcess.java:122)
>  at org.eclipse.jgit.transport.Transport.fetch (Transport.java:1138)
>  at org.eclipse.jgit.api.FetchCommand.call (FetchCommand.java:130)
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

[ANN] Apache Maven Shade Plugin 3.2.1 Released

[Olivier Lamy]

The Apache Maven team is pleased to announce the release of the Apache
Maven Shade Plugin, version 3.2.1

Repackages the project classes together with their dependencies into a
single uber-jar, optionally renaming classes or removing unused classes.

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

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


  org.apache.maven.plugins
  maven-shade-plugin
  3.2.1


Release Notes - Apache Maven Shade Plugin - Version 3.2.1

Bug

* [MSHADE-302] maven-shade-plugin fails to minimize JAR with Java 11
* [MSHADE-291] shadedPattern applied multiples times when relocating the
contents of META-INF/services files

Improvement

* [MSHADE-303] Suppress module-info.class warning if the file if filtered

Task

* [MSHADE-301] java11 support
* [MSHADE-299] Upgrade maven-dependency-tree to 3.0.1

Enjoy,
-The Apache Maven team

[ANN] Maven Plugin Tools 3.6.0

[Olivier Lamy]

Hi

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

The Maven Plugin Plugin is used to create a Maven plugin descriptor for any
Mojo's found in the source tree, to include in the JAR

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

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


org.apache.maven.plugins
maven-plugin-plugin
3.6.0


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

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

Release Notes - Maven Plugin Plugin - Version 3.6.0

** Bug
* [MPLUGIN-336] - broken in JDK 10/JDK 11 - IllegalArgumentException
* [MPLUGIN-337] - Try to derive JDK requirements also from release
parameter

** Task
* [MPLUGIN-332] - remove plugin:updateRegistry goal, which is unused in
Maven 3
* [MPLUGIN-344] - Upgrade plexus-archiver 3.6.0

** Dependency upgrade
* [MPLUGIN-342] - Upgrade maven-parent to 33

Enjoy,

-The Apache Maven team

[ANN] Apache Maven PMD Plugin 3.11.0 Released

[Olivier Lamy]

The Maven team is pleased to announce the release of the Apache Maven PMD
Plugin, version 3.11.0


A Maven plugin for the PMD toolkit, that produces a report on both code
rule violations and detected copy and paste fragments, as well as being
able to fail the build based on these metrics.


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


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




  org.apache.maven.plugins

  maven-pmd-plugin

  3.11.0





Release Notes - Apache Maven PMD Plugin - Version 3.11.0


Bug

* [MPMD-268] Missing warnings about deprecated rules

* [MPMD-266] Aggregate report in multi-module projects doesn't use correct
auxclasspath


New Feature

* [MPMD-272] Support ignoreAnnotations options for CPD


Task

* [MPMD-271] Upgrade pmd 6.8.0

* [MPMD-270] JDK 11 compatibility



Enjoy,


-The Maven team

[ANN] Apache Maven Invoker Plugin 3.1.0 Released

[Olivier Lamy]

Hi

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

The Invoker Plugin is used to run a set of Maven projects. The plugin can
determine whether each project execution is successful, and optionally can
verify the output generated from a given project execution.

This plugin is in particular handy to perform integration tests for Maven
plugins. The Invoker Plugin can be employed to run a set of test projects
that have been designed to assert certain features of the plugin under test.

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

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


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


Release Notes - Maven Invoker Plugin - Version 3.1.0

** Bug
* [MINVOKER-191] - “Artifact is not fully assembled” error with
maven-invoker-plugin in parallel/multi thread build
* [MINVOKER-224] - Unable to set cloneProjectsTo to null

** New Feature
* [MINVOKER-233] - Call an invoker with a given timeout

** Improvement
* [MINVOKER-236] - improve display of setup jobs

** Task
* [MINVOKER-228] - Improve documentation: "Using with other integration
test frameworks" page
* [MINVOKER-237] - Upgrade to JDK 7 minimum.

** Dependency upgrade
* [MINVOKER-232] - Upgrade parent to 31
* [MINVOKER-234] - Upgrade maven-shared-utils to 3.2.1
* [MINVOKER-235] - Upgrade plexus-utils 3.1.0
* [MINVOKER-238] - Upgrade maven-invoker to 3.0.1

Have fun,
 --
The Apache Maven team

Re: Maven Plugin Testing Tools deprecated

[Olivier Lamy]

Hi
Better to user maven-invoker-plugin:
http://maven.apache.org/plugins/maven-invoker-plugin/
Our plugins sources have plenty of examples

On 2 March 2018 at 07:29, Basin Ilya <basini...@gmail.com> wrote:

> Hi.
> I want to invoke a maven build as part of the unit test. I thought that
> http://maven.apache.org/plugin-testing/maven-plugin-testing-tools/ was
> the right tool, but its javadoc is completly deprecated and no
> replacement mentioned.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Problems configuring wagon-webdav-jackrabbit

[Olivier Lamy]

try a dav url such
dav:http(s)://my.webdav.server/

On 27 February 2018 at 21:52, Svensson, Lars <l.svens...@dnb.de> wrote:

> On Tuesday, February 27, 2018 12:34 PM, Olivier Lamy [mailto:
> ol...@apache.org] wrote:
>
> > On 27 February 2018 at 21:29, Svensson, Lars <l.svens...@dnb.de> wrote:
> >
> > > Hi Olivier and thanks for your quick reply!
> > >
> > > On Tuesday, February 27, 2018 11:54 AM, Olivier Lamy [mailto:
> > > ol...@apache.org] wrote:
> > >
> > > > webdav is not a plugin but a protocol supported by wagon
> > > > you're right using extension tag
> > > > If you want to deploy your artifacts just configure
> > > distributionManagement
> > > > to use dav protocol: dav:https://thewebdavurl/
> > > > Otherwise have a look at this plugin:
> > > > http://www.mojohaus.org/wagon-maven-plugin/usage.html (which I
> think you
> > > > want to achieve)
> > >
> > > distributionManagement is not quite what I need since my use case is to
> > > copy some generated files to a remote location.
> > >
> > > I had been looking at the wagon-maven-plugin but didn't get it to work
> > > since the jars are not available.
> > >
> > > Now my pom looks like this (as specified in [1]):
> > >
> > > 
> > >   
> > > 
> > >   
> > > org.apache.maven.wagon
> > > wagon-webdav
> > > 2.8
> > >   
> > > 
> > >
> >
> >
> > change to wagon-webdav-jackrabbit
>
> OK. It loads the jar but brings us back where we started:
>
> [ERROR] Failed to execute goal org.codehaus.mojo:wagon-maven-plugin:1.0:upload
> (default-cli) on project rdf: The parameters 'url' for goal
> org.codehaus.mojo:wagon-maven-plugin:1.0:upload are missing or invalid ->
> [Help 1]
>
> > > 
> > >   
> > > org.codehaus.mojo
> > > wagon-maven-plugin
> > >  1.0
> > >  
> > >
> > >   upload-artefacts-to-webdav
> > >  deploy
> > >  
> > > target/path/to/files
> > >*
> > >dav://my.webdav.server/
> > >standards
> > >  
> > >  
> > >upload
> > >  
> > >
> > >  
> > >
> > >  
> > >   
> > > 
>
> /Lars
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Problems configuring wagon-webdav-jackrabbit

[Olivier Lamy]

On 27 February 2018 at 21:29, Svensson, Lars <l.svens...@dnb.de> wrote:

> Hi Olivier and thanks for your quick reply!
>
> On Tuesday, February 27, 2018 11:54 AM, Olivier Lamy [mailto:
> ol...@apache.org] wrote:
>
> > webdav is not a plugin but a protocol supported by wagon
> > you're right using extension tag
> > If you want to deploy your artifacts just configure
> distributionManagement
> > to use dav protocol: dav:https://thewebdavurl/
> > Otherwise have a look at this plugin:
> > http://www.mojohaus.org/wagon-maven-plugin/usage.html (which I think you
> > want to achieve)
>
> distributionManagement is not quite what I need since my use case is to
> copy some generated files to a remote location.
>
> I had been looking at the wagon-maven-plugin but didn't get it to work
> since the jars are not available.
>
> Now my pom looks like this (as specified in [1]):
>
> 
>   
> 
>   
> org.apache.maven.wagon
> wagon-webdav
> 2.8
>   
> 
>


change to wagon-webdav-jackrabbit



> ...
> 
>   
> org.codehaus.mojo
> wagon-maven-plugin
>  1.0
>  
>
>   upload-artefacts-to-webdav
>  deploy
>  
> target/path/to/files
>*
>dav://my.webdav.server/
>standards
>  
>  
>upload
>  
>
>  
>
>  
>   
> 
>
> And maven claims that it cannot find wagon-webdav:jar:2.8 (and it's darn
> right, since the most recent version in apache maven repo is 1.0-beta-2 [2])
>
> [ERROR] Unresolveable build extension: Plugin
> org.apache.maven.wagon:wagon-webdav:2.8 or one of its dependencies could
> not be resolved: Could not find artifact 
> org.apache.maven.wagon:wagon-webdav:jar:2.8
> in central (https://repo.maven.apache.org/maven2) -> [Help 2]
>
> [1] http://www.mojohaus.org/wagon-maven-plugin/usage.html
> [2] https://repo.maven.apache.org/maven2/org/apache/maven/wagon/
> wagon-webdav/
>
> Best,
>
> Lars
>
> > On 27 February 2018 at 20:34, Svensson, Lars <l.svens...@dnb.de> wrote:
> >
> > > Greetings,
> > >
> > > This is my first post to this list so please bear with me if I'm
> ignoring
> > > something obvious...
> > >
> > > I'm trying to deploy a set of files to a webdav server using Maven
> Wagon,
> > > but the plugin does not pick up the configuration specified in my POM.
> If I
> > > specify the URL parameter on the command line (using -Dwagon.url etc.)
> it
> > > works fine.
> > >
> > > I could not find any specific examples on how to configure wagon for
> > > webdav, so I looked at the standard plugin configuration [1] and came
> up
> > > with the following:
> > >
> > > 
> > > ...
> > >   
> > > 
> > >   
> > > org.apache.maven.wagon
> > > wagon-webdav-jackrabbit
> > > 3.0.0
> > >   
> > > 
> > > ...
> > > 
> > >   
> > > org.apache.maven.wagon
> > > wagon-webdav-jackrabbit
> > > 3.0.0
> > >   
> > > 
> > >   upload-artefacts-to-webdav
> > >   deploy
> > >   
> > > target/path/to/files
> > > *
> > > dav://my.webdav.server/
> > > standards
> > >   
> > >   
> > > upload
> > >   
> > > 
> > >   
> > > 
> > >   
> > >
> > > 
> > >
> > > When I execute mvn wagon:upload, it first issues a warning
> > >
> > > [WARNING] Failed to retrieve plugin descriptor for
> > > org.apache.maven.wagon:wagon-webdav-jackrabbit:3.0.0: Failed to parse
> > > plugin descriptor for org.apache.maven.wagon:wagon-
> webdav-jackrabbit:3.0.0
> > > (D:\Workspace\m2repo\org\apache\maven\wagon\wagon-
> > > webdav-jackrabbit\3.0.0\wagon-webdav-jackrabbit-3.0.0.jar): No plugin
> > > descriptor found at META-INF/maven/plugin.xml
> > >
> > > And then goes on to say
> > >
> > > [ERROR] Failed to execute goal org.codehaus.mojo:wagon-maven-
> plugin:1.0:upload
> > > (default-cli) on project myProject: The parameters 'url' for goal
> > > org.codehaus.mojo:wagon-maven-plugin:1.0:upload are missing or
> invalid ->
> > > [Help 1]
> > >
> > > Any help on the correct configuration would be very helpful.
> > >
> > > [1] https://maven.apache.org/guides/mini/guide-configuring-
> > > plugins.html#Configuring_Build_Plugins
> > >
> > > Thanks,
> > >
> > > Lars
> > >
> > >
> >
> >
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
>



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Problems configuring wagon-webdav-jackrabbit

[Olivier Lamy]

Hi,
webdav is not a plugin but a protocol supported by wagon
you're right using extension tag
If you want to deploy your artifacts just configure distributionManagement
to use dav protocol: dav:https://thewebdavurl/
Otherwise have a look at this plugin:
http://www.mojohaus.org/wagon-maven-plugin/usage.html (which I think you
want to achieve)
HTH
Olivier

On 27 February 2018 at 20:34, Svensson, Lars <l.svens...@dnb.de> wrote:

> Greetings,
>
> This is my first post to this list so please bear with me if I'm ignoring
> something obvious...
>
> I'm trying to deploy a set of files to a webdav server using Maven Wagon,
> but the plugin does not pick up the configuration specified in my POM. If I
> specify the URL parameter on the command line (using -Dwagon.url etc.) it
> works fine.
>
> I could not find any specific examples on how to configure wagon for
> webdav, so I looked at the standard plugin configuration [1] and came up
> with the following:
>
> 
> ...
>   
> 
>   
> org.apache.maven.wagon
> wagon-webdav-jackrabbit
> 3.0.0
>   
> 
> ...
> 
>   
> org.apache.maven.wagon
> wagon-webdav-jackrabbit
> 3.0.0
>   
> 
>   upload-artefacts-to-webdav
>   deploy
>   
> target/path/to/files
> *
> dav://my.webdav.server/
> standards
>   
>   
> upload
>   
> 
>   
> 
>   
>
> 
>
> When I execute mvn wagon:upload, it first issues a warning
>
> [WARNING] Failed to retrieve plugin descriptor for
> org.apache.maven.wagon:wagon-webdav-jackrabbit:3.0.0: Failed to parse
> plugin descriptor for org.apache.maven.wagon:wagon-webdav-jackrabbit:3.0.0
> (D:\Workspace\m2repo\org\apache\maven\wagon\wagon-
> webdav-jackrabbit\3.0.0\wagon-webdav-jackrabbit-3.0.0.jar): No plugin
> descriptor found at META-INF/maven/plugin.xml
>
> And then goes on to say
>
> [ERROR] Failed to execute goal org.codehaus.mojo:wagon-maven-plugin:1.0:upload
> (default-cli) on project myProject: The parameters 'url' for goal
> org.codehaus.mojo:wagon-maven-plugin:1.0:upload are missing or invalid ->
> [Help 1]
>
> Any help on the correct configuration would be very helpful.
>
> [1] https://maven.apache.org/guides/mini/guide-configuring-
> plugins.html#Configuring_Build_Plugins
>
> Thanks,
>
> Lars
>
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Running tomcat maven plugin in a multi modules project

[Olivier Lamy]

Hi,
Well to be fair Jetty Maven Plugin has now this feature as well...

On 14 January 2018 at 03:25, Thomas Broyer <t.bro...@gmail.com> wrote:

> On Sat, Jan 13, 2018 at 3:20 PM Thomas Broyer <t.bro...@gmail.com> wrote:
>
> > Tomcat Maven plugin has built-in support for reactors, so run it at root
> > rather than within the web submodule (possibly with "-pl web -am"). It
> will
> > automatically compile all (needed) submodules and launch Tomcat, and with
> > auto-deploy will automatically reload the webapp to pickup changes in any
> > submodule.
> >
>
> From https://tomcat.apache.org/maven-plugin-2.2/run-mojo-features.html
> > NOTE If you have a multi module Maven project and use Maven3,
> > you don't need to install all modules before using the run goal, just
> > use tomcat6/7:run from the root module and the plugin will auto
> > detect the build output directory from various modules and replace
> > dependencies with those directories in the webapp classloader.
>
> (too bad there's been no new release for 4 years though, this is probably
> one of the best thought-out Maven plugin out there in terms of usability
> wrt multi-module projects, and without being "hackish"; without that,
> people keep having to install all their snapshots into their local repo and
> rebuilding them over and over again, if only to make sure they're the ones
> for the correct commit / code state)
>
>
> > Le sam. 13 janv. 2018 03:33, Sigmond Hola <sigmund@gmail.com> a
> > écrit :
> >
> >> I have a multi-module project like this:
> >>
> >> ROOT:pom
> >> --- web:war
> >> --- domain:jar
> >> --- service:jar
> >> --- dao:jar
> >>
> >> And i configure tomcat7-maven-plugin in pom.xml of module *web *so that
> I
> >> can using tomcat:run to run this web application.
> >>
> >> But if I change something in other module, for example, add a new entity
> >> class in module domain, I have to install the ROOT to local repo first
> >> before I run tomcat:run within module web, otherwise a error: cannot
> find
> >> symbol will be reported if I run tomcat:run directly.
> >>
> >> So how can I install other modules first before I run tomcat:run within
> >> module web if I change something in other modules?
> >>
> >> Thanks in advance.
> >>
> >> Best regards.
> >>
> >
>



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Best way to deploy a specific file and declare its dependencies

[Olivier Lamy]

Hi
Why not attaching the produced artifact?
See
http://www.mojohaus.org/build-helper-maven-plugin/attach-artifact-mojo.html

HTH
Olivier

On 1 December 2017 at 07:49, Francois MAROT <francois.ma...@gmail.com>
wrote:

> Hello all,
>
> I have a need to explain to a third party how to deploy a jar on my
> repository (Archiva). But
> - this jar is not generated by Maven (it contains DLLs to be loaded through
> JNA)
> - I'd like the third party to be able to declare dependencies of this jar
> (some zip containing some DLLs). So that by declaring a dependency on this
> jar I will also get it's dependencies
> - the goal is for me to make the third party totally independant and able
> to
> update his artifact or it's dependencies without my supervision
>
> I came with the following pom that he may use runnning:
> mvn install -Drevision=1.0.0-WIN64-SNAPSHOT
> -DfileToDeploy=some-jar_master.jar
>
> Question is, is there anything simpler ? :)
>
> 
> http://www.w3.org/2001/XMLSchema-instance;
> xmlns="http://maven.apache.org/POM/4.0.0;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd;>
> 4.0.0
>
>
>
> com.oleamedical.io
> test-breast
> ${revision}
>
> jar
>
> 
> UTF-8 sourceEncoding>
> TO-OVERRIDE-ON-COMMAND-LINE
> TO-OVERRIDE-ON-COMMAND-LINE
> 
>
> 
>
>
> 
> thirdparties.intel
> redist-cpp
> 2017.5.267
> natives-win
> runtime
> zip
> 
>
> 
>
> 
>
> 
> 
>
> maven-antrun-
> plugin
> 1.8
> 
> 
> package
> 
> 
>  file="${fileToDeploy}"
> tofile="${project.build.directory}/${project.build.finalName}.jar"
> overwrite="true" />
> 
> 
> 
> run
> 
> 
> 
> 
>
> 
>
> org.codehaus.mojo
> flatten-maven-
> plugin
> 1.0.1
> 
> true updatePomFile>
> 
> 
> 
> flatten
> process-resources phase>
> 
>
> flatten
> 
> 
> 
> flatten.clean
> clean
> 
> clean
> 
> 
>         
> 
>
> 
> 
>
> 
>
>
>
> --
> Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Maven-Indexer 6.0 Release

[Olivier Lamy]

Hi,
Sounds good.
Sorry I haven't tested that but can we still read Central index?


On 27 November 2017 at 08:23, Tamás Cservenák <ta...@cservenak.net> wrote:

> More fixes made by Hervé and me.
>
> Are we ready for 6.0.0?
>
> On Sun, Nov 26, 2017, 01:10 Olivier Lamy <ol...@apache.org> wrote:
>
> > sounds good! (thanks to make Hervé happy :P )
> >
> > On 25 November 2017 at 01:54, Tamás Cservenák <ta...@cservenak.net>
> wrote:
> >
> > > Hi,
> > >
> > > All merged, but there is one more thing:
> > >
> > > I'd like to fully reformat indexer codebase to maven codestyle before
> > > release:
> > > https://github.com/apache/maven-indexer/pull/23
> > > (not much to see, but someone eyeball please)
> > >
> > > Main reason is not only annoying checkstyle errors (this PR gets rid of
> > > most but not all of them, javadoc ones still remain :), but also to
> align
> > > formatting of sources, makes IDEs not loose their sanity. Currently we
> > have
> > > one pending PR (the lucene 7) but rebasing it against master (once this
> > > reformat PR is merged) should be easy, if the other problems are fixed.
> > >
> > > Am not "blocking" the release with reformat -- so am fine doing 6.0
> > without
> > > it --, but i think would be "nice thing to do", and would ease later PR
> > > reviews too, by having codestyle aligned across whole project.
> > >
> > > WDYT?
> > >
> > > T
> > >
> > > On Fri, Nov 24, 2017 at 11:01 AM Olivier Lamy <ol...@apache.org>
> wrote:
> > >
> > > > sounds good!
> > > > Thanks!
> > > > Olivier
> > > >
> > > > On 24 November 2017 at 02:14, Tamás Cservenák <ta...@cservenak.net>
> > > wrote:
> > > >
> > > > > Hi there,
> > > > >
> > > > > I think with this PR 6.0 should be ready to go:
> > > > > https://github.com/apache/maven-indexer/pull/21
> > > > >
> > > > > Then, we can "jump" to 7 :)
> > > > > - make it java8
> > > > > - consume the lucene update PR
> > > > > https://github.com/apache/maven-indexer/pull/19
> > > > >
> > > > >
> > > > > WDYT?
> > > > >
> > > > >
> > > > > On Tue, Nov 21, 2017 at 3:13 PM Andreas Sewe <
> > > > > s...@st.informatik.tu-darmstadt.de> wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > > I am "ressurecting" an old topic. I wonder if it is
> possible
> > to
> > > > > have
> > > > > > some news for 6.0 release of maven indexer.
> > > > > > >
> > > > > > > The old version of maven indexer make a plugin fail at
> > runtime
> > > > with
> > > > > > maven 3.1.1+  (see [2]). And works well with 6.0.
> > > > > >
> > > > > > FWIW, I'm also quite keen on proper release of 6.0 (currently
> > working
> > > > > > with a locally-built 6.0 snapshot).
> > > > > >
> > > > > > Best wishes,
> > > > > >
> > > > > > Andreas
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > Thanks,
> > > > > ~t~
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Olivier Lamy
> > > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > > >
> > > --
> > > Thanks,
> > > ~t~
> > >
> >
> >
> >
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
> --
> Thanks,
> ~t~
>



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Maven-Indexer 6.0 Release

[Olivier Lamy]

sounds good! (thanks to make Hervé happy :P )

On 25 November 2017 at 01:54, Tamás Cservenák <ta...@cservenak.net> wrote:

> Hi,
>
> All merged, but there is one more thing:
>
> I'd like to fully reformat indexer codebase to maven codestyle before
> release:
> https://github.com/apache/maven-indexer/pull/23
> (not much to see, but someone eyeball please)
>
> Main reason is not only annoying checkstyle errors (this PR gets rid of
> most but not all of them, javadoc ones still remain :), but also to align
> formatting of sources, makes IDEs not loose their sanity. Currently we have
> one pending PR (the lucene 7) but rebasing it against master (once this
> reformat PR is merged) should be easy, if the other problems are fixed.
>
> Am not "blocking" the release with reformat -- so am fine doing 6.0 without
> it --, but i think would be "nice thing to do", and would ease later PR
> reviews too, by having codestyle aligned across whole project.
>
> WDYT?
>
> T
>
> On Fri, Nov 24, 2017 at 11:01 AM Olivier Lamy <ol...@apache.org> wrote:
>
> > sounds good!
> > Thanks!
> > Olivier
> >
> > On 24 November 2017 at 02:14, Tamás Cservenák <ta...@cservenak.net>
> wrote:
> >
> > > Hi there,
> > >
> > > I think with this PR 6.0 should be ready to go:
> > > https://github.com/apache/maven-indexer/pull/21
> > >
> > > Then, we can "jump" to 7 :)
> > > - make it java8
> > > - consume the lucene update PR
> > > https://github.com/apache/maven-indexer/pull/19
> > >
> > >
> > > WDYT?
> > >
> > >
> > > On Tue, Nov 21, 2017 at 3:13 PM Andreas Sewe <
> > > s...@st.informatik.tu-darmstadt.de> wrote:
> > >
> > > > Hi,
> > > >
> > > > > I am "ressurecting" an old topic. I wonder if it is possible to
> > > have
> > > > some news for 6.0 release of maven indexer.
> > > > >
> > > > > The old version of maven indexer make a plugin fail at runtime
> > with
> > > > maven 3.1.1+  (see [2]). And works well with 6.0.
> > > >
> > > > FWIW, I'm also quite keen on proper release of 6.0 (currently working
> > > > with a locally-built 6.0 snapshot).
> > > >
> > > > Best wishes,
> > > >
> > > > Andreas
> > > >
> > > >
> > > >
> > > > --
> > > Thanks,
> > > ~t~
> > >
> >
> >
> >
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
> --
> Thanks,
> ~t~
>



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Maven-Indexer 6.0 Release

[Olivier Lamy]

sounds good!
Thanks!
Olivier

On 24 November 2017 at 02:14, Tamás Cservenák <ta...@cservenak.net> wrote:

> Hi there,
>
> I think with this PR 6.0 should be ready to go:
> https://github.com/apache/maven-indexer/pull/21
>
> Then, we can "jump" to 7 :)
> - make it java8
> - consume the lucene update PR
> https://github.com/apache/maven-indexer/pull/19
>
>
> WDYT?
>
>
> On Tue, Nov 21, 2017 at 3:13 PM Andreas Sewe <
> s...@st.informatik.tu-darmstadt.de> wrote:
>
> > Hi,
> >
> > > I am "ressurecting" an old topic. I wonder if it is possible to
> have
> > some news for 6.0 release of maven indexer.
> > >
> > > The old version of maven indexer make a plugin fail at runtime with
> > maven 3.1.1+  (see [2]). And works well with 6.0.
> >
> > FWIW, I'm also quite keen on proper release of 6.0 (currently working
> > with a locally-built 6.0 snapshot).
> >
> > Best wishes,
> >
> > Andreas
> >
> >
> >
> > --
> Thanks,
> ~t~
>



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Maven classloader change / Maven integrator contacts?

[Olivier Lamy]

Hi,
The Apache Maven team is working on a classloader so we'd like to have some
testing by people who are embedding Maven and could have issues with this
change.
Furthermore we'd like to have contacts from those projects. (simply reply
to priv...@maven.apache.org )

The change is: https://issues.apache.org/jira/browse/MNG-6275

We have lists which could be enhanced (or cleaned as well :-) )

Let us know and have a great weekend!!


 [IDE] (https://maven.apache.org/ide.html)
 Eclipse
 Intellij
 Netbeans (maybe apache dev mailing list?)

 [CI] (https://maven.apache.org/continuous-integration.html)
 Bamboo (Atlassian)
 BuildHive (CloudBees)
 CODESHIP?
 Cruise Control?
 Hudson
 Jenkins

 [QA]
 Sonar Qube

-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: maven-plugin-testing-harness

[Olivier Lamy]

Hi
IMHO using the maven invoker plugin is a better way as you can easily test
your plugin with different core versions.
but it's only my POV :-)

On 23 August 2017 at 18:03, ahardy42 <adam.ha...@cyberspaceroad.com> wrote:

> After a concentrated stint of experimentation, I have setup my tests using
> the maven-plugin-testing-harness so that the tests run with a live remote
> repository and have all the resources provided in the target/test-classes
> directory.
>
> The solution is here:
> https://stackoverflow.com/questions/45241317/hard-time-
> mojo-testing-with-maven-plugin-testing-harness/45833419#answer-45833419
>
> Sorry if the question title betrays my frustration. The limited feedback I
> got here on this user list was also surprising. Obviously with no feedback
> to speak of, I have no idea why no-one from the maven community wanted to
> communicate on this subject. I would of course be grateful now to get some
> feedback of any kind. I'm not asking for anyone to spend more than a minute
> to write a reply - I have essentially finished my work with the testing
> harness.
>
> Why was it so difficult? Are the inner workings all in the process of
> re-development for maven 4?
>
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.
> com/maven-plugin-testing-harness-tp5911556p5912964.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

[ANN] Apache Maven Wagon 3.0.0

[Olivier Lamy]

Hi,
The Apache Maven team is pleased to announce the Apache Maven Wagon version
3.0.0
Maven Wagon is a transport abstraction that is used in Maven's artifact and
repository handling code.
Website: http://maven.apache.org/components/wagon/

Release Notes - Maven Wagon - Version 3.0.0

** Improvement
* [WAGON-488] - Upgrade WebDAV Wagon to a more recent HttpClient
version (4.5.3)
* [WAGON-489] - Java 7 required

** Bug
* [WAGON-363] - wagon-ftp fails to create non-existing directory when
path contains "/../"
* [WAGON-490] - FTP over HTTP proxy wagon


Enjoy
-- 
Apache Maven Team

[ANN] Apache Maven Compiler Plugin 3.6.2

[Olivier Lamy]

Hi
The Apache Maven team is pleased to announce the release of the Apache
Maven Compiler plugin, version 3.6.2.
http://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.6.2


Release Notes - Maven Compiler Plugin - Version 3.6.2

** Bug
* [MCOMPILER-290] - Fix invalid comment out in the examples of the
module-info documentation
* [MCOMPILER-301] - Upgrade QDox

** Improvement
* [MCOMPILER-298] - Support "-parameters" compiler option as a
configuration key

Enjoy!
-- 
The Apache Maven team

[ANN] Apache Maven Invoker plugin 3.0.1 Released

[Olivier Lamy]

Hi,
The Apache Maven team is pleased to announce the release of the Apache
Maven Invoker Plugin, version 3.0.1

The Invoker Plugin is used to run a set of Maven projects. The plugin can
determine whether each project execution is successful, and optionally can
verify the output generated from a given project execution.

This plugin is in particular handy to perform integration tests for other
Maven plugins. The Invoker Plugin can be employed to run a set of test
projects that have been designed to assert certain features of the plugin
under test.

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

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


org.apache.maven.plugins
maven-invoker-plugin
3.0.1


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

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

Release Notes - Maven Invoker Plugin - Version 3.0.1

** Bug
* [MINVOKER-220] - when description is too long, 2 spaces before status
instead of 1
* [MINVOKER-223] - postBuildHookScript must be executed even if the
maven build fail

** Improvement
* [MINVOKER-149] - Possibility to have different settings.xml per IT
* [MINVOKER-221] - improve "run script" message with description of
which script



Enjoy
-- 
The Apache Maven Team

[ANN] Apache Maven Shade Plugin 3.0.0 Released

[Olivier Lamy]

Hi,
The Apache Maven team is pleased to announce the release of the Apache
Maven Shade Plugin, version 3.0.0

This plugin provides the capability to package the artifact in an uber-jar,
including its dependencies and to shade - i.e. rename - the packages of
some of the dependencies.

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

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


org.apache.maven.plugins
maven-shade-plugin
3.0.0


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

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

Release Notes - Maven Shade Plugin - Version 3.0.0


** Improvement
* [MSHADE-219] - Update XSD location of POM to the new one in POMWriter
* [MSHADE-224] - Preserve last modified time in resources files.
* [MSHADE-225] - Writing output only once
* [MSHADE-232] - Introduce ResourceBundleAppendingTransformer
* [MSHADE-241] - Groovy extension module transformer
* [MSHADE-246] - Switch to maven-artifact-transfer to support both
Aether implementations

** Bug
* [MSHADE-182] - ServicesResourceTransformer incorrectly ignores given
Relocators
* [MSHADE-223] - Endless processing when
promoteTransitiveDependencies=true
* [MSHADE-228] - Shade can incorrectly re-write an InterfaceMethodRef
in the constant pool to a MethodRef
* [MSHADE-237] - ServicesResourceTransformer relocates excluded classes
* [MSHADE-239] - Shaded Source JAR not following finalName pattern
* [MSHADE-240] - support relocation pom.properties and pom.xml
descriptors in shaded jars

** Task
* [MSHADE-222] - Dependency updates.

Enjoy,

-The Apache Maven team

[ANN] Apache Maven Assembly Plugin 3.0.0 Released

[Olivier Lamy]

Hi,
The Apache Maven team is pleased to announce the release of the Apache
Maven Assembly Plugin, version 3.0.0

The Assembly Plugin for Maven is primarily intended to allow users to
aggregate the project output along with its dependencies, modules, site
documentation, and other files into a single distributable archive.

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

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


org.apache.maven.plugins
maven-assembly-plugin
3.0.0


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

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

Release Notes - Maven Assembly Plugin - Version 3.0.0

** Bug
* [MASSEMBLY-756] - escapeString doesn't work correctly for the 2nd
filtering
* [MASSEMBLY-773] - MetaInfServicesHandler catalog is not cleared
between invocations in multimodule projects
* [MASSEMBLY-777] - The assembly plugin refuses to copy a file named
lexicon.filtered or lexicon.formatted
* [MASSEMBLY-789] - assembly:single with repacking tar.gz results in
UndeclaredThrowableException
* [MASSEMBLY-802] - Dependencies version conflict leads to run-time
exception when creating archive
* [MASSEMBLY-824] - Use of appendAssemblyId and finalName can cause
problems
* [MASSEMBLY-829] - fileMode on a dependencySet with unpack does not
work
* [MASSEMBLY-834] - Maven assembly plugin fails with Java 9
* [MASSEMBLY-836] - Remove link to non-existing Codehaus wiki

** Improvement
* [MASSEMBLY-704] - Remove all goals which are marked deprecated
* [MASSEMBLY-770] - List of XSD's on the main site is cluttered.
* [MASSEMBLY-790] - Upgrade
maven-archiver/maven-filtering/maven-common-artifact-filters to 3.0.0
* [MASSEMBLY-792] - Expose merge manifest mode from the plexus archiver
* [MASSEMBLY-793] - Remove cluttering System.out.println statements
* [MASSEMBLY-795] - Upgrade file-management to 3.0.0
* [MASSEMBLY-796] - Upgrade maven-shared-io to 3.0.0
* [MASSEMBLY-797] - Upgrade plexus-archiver from 3.0.1 to 3.0.3
* [MASSEMBLY-801] - Upgrade plexus-archiver from 3.0.3 to 3.1
* [MASSEMBLY-807] - Upgrade maven-plugins to version 30
* [MASSEMBLY-808] - Upgrade of 'plexus-archiver' to version 3.3.
* [MASSEMBLY-810] - Upgrade com.google.code.findbugs:jsr305 to 3.0.0
* [MASSEMBLY-813] - Upgrade maven-archiver to 3.1.0
* [MASSEMBLY-814] - Upgrade maven-filtering to 3.1.1
* [MASSEMBLY-817] - Make finalName readonly parameter
* [MASSEMBLY-818] - Remove deprecated parameters for the single goal
* [MASSEMBLY-819] - Update to release version if Maven Artifact
Transfer Component released?
* [MASSEMBLY-823] - Documentation refers to deprecated goals

** New Feature
* [MASSEMBLY-780] - Snappy supported

** Task
* [MASSEMBLY-744] - Use the same namespace pattern for
assembly/component format as the rest of Maven
* [MASSEMBLY-745] - Give the component format schema file a better name
* [MASSEMBLY-794] - Update and revise documentation for 3.0.0 release
* [MASSEMBLY-804] - Dependency updates.
* [MASSEMBLY-806] - Use new Modello home in MDO files
* [MASSEMBLY-816] - Fix problem with building Maven site
* [MASSEMBLY-820] - Upgrade of plexus-archiver to 3.4.
* [MASSEMBLY-821] - Upgrade of maven-archiver to 3.1.1.
* [MASSEMBLY-837] - Revise features page on site

Enjoy,

-The Apache Maven team

Re: Jenkins and Maven

[Olivier Lamy]

Hehe
Thanks Benson to put some coins in the troll machine :-)
Well if evil is really ease the user's life so this plugin can be
considered evil :-)
You have some very convenient features such building dependent projects,
javadoc etc..
So it's just a matter of not spending too long on configuring Jenkins using
a ui :-)

Olivier (will not troll more)




On 14 October 2016 at 03:33, Manfred Moser  wrote:

> I agree with Stephen .. avoid the Maven job type. In fact I would install
> Daniel's
>
> https://github.com/daniel-beck/hide-maven-plugin\
>
> I have spent many hours trying to fix broken builds with the Maven job
> type only to switch to Freestyle jobs and they just work. There is a reason
> why Eclipse Hudson declared the job type legacy and has an improved Maven
> freestyle integration (but thats kind of beside the point when you look at
> Jenkins).
>
> Also in terms of settings management and such I suggest to use the config
> file provider plugin.
>
> I recorded a demo video about that stuff some while ago (for Sonatype in
> the context of deploying to Nexus but applies generically). Its part of the
> tips from the trenches series
>
> http://www.sonatype.org/nexus/members-only/video-gallery-2/
> free-training-sonatype-nexus-and-clm-tips-from-the-trenches/
>
> Here are the two Jenkins videos
>
> https://www.youtube.com/watch?v=JpXksHynouk
> https://www.youtube.com/watch?v=xHJrqKf0cLk
>
> Also if you want to invoke maven from a shell script or so you might want
> to look at the wrapper.
>
> https://github.com/takari/maven-wrapper
>
> Hth
>
> Manfred
>
>
>
> Benson Margulies wrote on 2016-10-13 06:59:
>
> > We've about had it with bamboo, and are dusting off our old Jenkins
> instance.
> >
> > I recall some messages here about things _not_ to do with Jenkins and
> > Maven. Do we avoid the 'maven build type' altogether and just run
> > Maven from the shell, or is my memory faulty? Anything else.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Mojos that instrument classes

[Olivier Lamy]

Hi
Process-classes sounds a good place in the lifecycle for this purpose

HTH
Olivier

On Thursday, 15 September 2016, offbynull-maven <
offbynull-ma...@offbynull.com> wrote:

> What should the defaultPhase be for a Maven plugin that instruments
> classes? Should it be PROCESS_CLASSES / PROCESS_TEST_CLASSES, or should it
> be COMPILE / TEST_COMPILE?
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Cobertura Maven Plugin works locally, but not in Jenkins

[Olivier Lamy]

Hi
Do you have a sample project to reproduce the issue?

On Wednesday, 13 July 2016, Hohl, Gerrit  wrote:

> Hello everyone,
>
>
>
> I faced an odd problem today:
>
> We have a Maven Build which also includes the creation of a
> documentation.
>
> One of the plugins creating the reports is the Cobertura Maven Plugin.
>
> If I execute it on my local machine it works perfectly.
>
> Also the project has no code at all (it's more an Ant and aggregation
> project) it creates the documentation and also deploys it.
>
>
>
> But if I try to build the same project in our Jenkins build service the
> Maven jobs just days while trying to execute the Cobertura Maven Plugin.
>
> I added --debug, but also if the debug messages are enabled I don't see
> an error, stack trace or whatever in the log.
>
> On my local machine the output looks like this:
>
>
>
> [...]
>
> [DEBUG] resolving version for org.codehaus.mojo:cobertura-maven-plugin
>
> [DEBUG] resolved org.codehaus.mojo:cobertura-maven-plugin version from
> the reporting.plugins section: 2.7
>
> [INFO] configuring report plugin
> org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [...]
>
> [DEBUG] org.codehaus.mojo:cobertura-maven-plugin:jar:2.7:
>
> [DEBUG]net.sourceforge.cobertura:cobertura:jar:2.1.1:compile
>
> [DEBUG]   org.ow2.asm:asm:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-tree:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-commons:jar:5.0.1:compile
>
> [...]
>
> [DEBUG]org.apache.maven.shared:maven-invoker:jar:2.0.11:compile
>
> [DEBUG] Created new class realm
> plugin>org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [DEBUG] Importing foreign packages into class realm
> plugin>org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [DEBUG]   Imported:  < maven.api
>
> [DEBUG]   Imported: org.apache.maven.doxia.logging.Log <
> plugin>org.apache.maven.plugins:maven-site-plugin:3.5.1
>
> [DEBUG]   Imported: org.apache.maven.doxia.logging.LogEnabled <
> plugin>org.apache.maven.plugins:maven-site-plugin:3.5.1
>
> [...]
>
>
>
> The output with the Jenkins server looks like this:
>
>
>
> [...]
>
> [DEBUG] resolving version for org.codehaus.mojo:cobertura-maven-plugin
>
> [DEBUG] resolved org.codehaus.mojo:cobertura-maven-plugin version from
> the reporting.plugins section: 2.7
>
> [INFO] configuring report plugin
> org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [...]
>
> [DEBUG] org.codehaus.mojo:cobertura-maven-plugin:jar:2.7:
>
> [DEBUG]net.sourceforge.cobertura:cobertura:jar:2.1.1:compile
>
> [DEBUG]   org.ow2.asm:asm:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-tree:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-commons:jar:5.0.1:compile
>
> [...]
>
> [DEBUG]org.apache.maven.shared:maven-invoker:jar:2.0.11:compile
>
> [JENKINS] Archiving site from c:\jenkins_data\workspace\target\site to
> C:\.jenkins\jobs\xxx\site
>
>
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logResult
>
> INFORMATION:
> 
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logResult
>
> INFORMATION: BUILD FAILURE
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logStats
>
> INFORMATION:
> 
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logStats
>
> INFORMATION: Total time: 35.284s
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logStats
>
> INFORMATION: Finished at: Tue Jul 12 15:43:15 CEST 2016
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logStats
>
> INFORMATION: Final Memory: 24M/174M
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> sessionEnded
>
> INFORMATION:
> 
>
> [...]
>
>
>
> And that is it. No errors, no stack traces, no messages.
>
> Jenkins uses the same Java version and same Maven version like my local
> build.
>
> We use an internal Nexus server as proxy for the artifacts.
>
> Means my local Maven installation as well as the one Jenkins uses are
> using the same artifact repository.
>
>
>
> Any ideas on this?
>
>
>
> Regards,
>
> Gerrit
>
>
>
>

-- 
Olivier

Re: SCM APIs cause "ref HEAD is not a symbolic ref"

[Olivier Lamy]

Hi
ohhh sorry for confusion, the release before which should 1.9.2 :-)
Well as others say you must work with branches from the tag!!
Olivier


On 16 June 2016 at 01:45, Simone Tripodi <simonetrip...@apache.org> wrote:

> Salut mon ami!
> And thanks for jumping in to help!
> Looks like maven-scm-provider-gitexe-1.9.3 does not exist[1]...
>
> I am not worried about the time the operations are performed, given the
> users environment gitexe is the simpler options because I don't have to
> adjust the jgit settings...
>
> Thanks!
> -Simo
>
> [1]
>
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.maven.scm%22%20AND%20a%3A%22maven-scm-provider-gitexe%22
>
>
> http://people.apache.org/~simonetripodi/
> http://twitter.com/simonetripodi
>
> On Wed, Jun 15, 2016 at 1:49 PM, Olivier Lamy <ol...@apache.org> wrote:
>
> > Hi Simone,
> > Did it work with 1.9.3?
> > More generally, I would recommend you to use the jgit provider which will
> > be probably faster (not forking any cli etc..)
> >
> > Cheers
> > Olivier
> >
> >
> >
> >
> >
> > On 15 June 2016 at 09:13, Simone Tripodi <simonetrip...@apache.org>
> wrote:
> >
> > > Hi all mates,
> > > I've been happily using the Maven SCM APIs to perform few operations
> > "under
> > > the hood" for my users, everything was working fine until stumbled in
> the
> > > SCMException "Detecting the current branch failed: fatal: ref HEAD is
> > not a
> > > symbolic ref"
> > > The scenario is: I am using the libraries below
> > >
> > >
> > > org.apache.maven.scm
> > > maven-scm-api
> > > ${maven.scm.version}
> > > 
> > > 
> > > org.apache.maven.scm
> > > maven-scm-provider-gitexe
> > > ${maven.scm.version}
> > > 
> > > where 1.9.4, the sequence of
> > > operations that cause the error are:
> > >
> > > ScmVersion version = new ScmTag(version);
> > > ScmResult result = scmManager.checkOut(repository, new
> > > ScmFileSet(appDir), version);
> > > ...
> > > result = scmManager.add(repository, new ScmFileSet(appDir,
> > > newFile), commitMessage);
> > > ...
> > >result = scmManager.checkIn(repository, new ScmFileSet(
> > > quickstartDir), version, commitMessage);
> > > The error happens when invoking the checkIn, do you have any
> > recommendation
> > > on how to modify the operations sequence in order to make it working,
> > when
> > > checking out a tag?
> > >
> > > Many thanks in advance, all the best!
> > > -Simo
> > >
> > > http://people.apache.org/~simonetripodi/
> > > http://twitter.com/simonetripodi
> > >
> >
> >
> >
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
>

Re: SCM APIs cause "ref HEAD is not a symbolic ref"

[Olivier Lamy]

Hi Simone,
Did it work with 1.9.3?
More generally, I would recommend you to use the jgit provider which will
be probably faster (not forking any cli etc..)

Cheers
Olivier





On 15 June 2016 at 09:13, Simone Tripodi <simonetrip...@apache.org> wrote:

> Hi all mates,
> I've been happily using the Maven SCM APIs to perform few operations "under
> the hood" for my users, everything was working fine until stumbled in the
> SCMException "Detecting the current branch failed: fatal: ref HEAD is not a
> symbolic ref"
> The scenario is: I am using the libraries below
>
>
> org.apache.maven.scm
> maven-scm-api
> ${maven.scm.version}
> 
> 
> org.apache.maven.scm
> maven-scm-provider-gitexe
> ${maven.scm.version}
> 
> where 1.9.4, the sequence of
> operations that cause the error are:
>
> ScmVersion version = new ScmTag(version);
> ScmResult result = scmManager.checkOut(repository, new
> ScmFileSet(appDir), version);
> ...
> result = scmManager.add(repository, new ScmFileSet(appDir,
> newFile), commitMessage);
> ...
>result = scmManager.checkIn(repository, new ScmFileSet(
> quickstartDir), version, commitMessage);
> The error happens when invoking the checkIn, do you have any recommendation
> on how to modify the operations sequence in order to make it working, when
> checking out a tag?
>
> Many thanks in advance, all the best!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://twitter.com/simonetripodi
>



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: how can i upload version 1.1.0.1 of tomcat-jdbc

[Olivier Lamy]

Try this one:
http://repo.maven.apache.org/maven2/org/apache/tomcat/tomcat-jdbc/

HTH
Olivier

On 25 August 2015 at 03:18, Magnanao, Hector hector.magna...@sap.com
wrote:

 I need to compile with 1.1.0.1.  whenever I try to compile with this
 version,  it says the
 [WARNING] The POM for org.apache.tomcat:tomcat-jdbc:jar:1.1.0.1 is
 missing, no dependency information available

 Is there another url or group that I can grab this version from ? Or do I
 need download this locally ?

 Hector Magnanao Jr.
 SCM Analyst

 Fieldglass, Inc.
 O: (331) 702-6142
 M: (773) 474-3051
 hector.magna...@sap.com
 www.fieldglass.com

 Fieldglass is now part of SAP

 This email contains confidential information.  If you are not the intended
 recipient, do not read, distribute or reproduce this transmission
 (including any attachments). If you have received this email in error,
 please notify the sender by email reply.




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Codehaus Mojo repository

[Olivier Lamy]

Use github issues

On 3 June 2015 at 17:23, Cemo cemalettin@gmail.com wrote:

 Thanks Wolf and Olivier.

 Will there be a new JIRA or we can file issues directly to github?

 Cheers,
 Cemo


 On 3 June 2015 at 10:19, Wolf Geldmacher wolf.geldmac...@abacus.ch
 wrote:

  ... and for those in search of the documentation formerly hosted at
  codehaus: some/most of it can be found at
 
  http://www.mojohaus.org
 
  Cheers,
  Wolf
 




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Codehaus Mojo repository

[Olivier Lamy]

Hi
Have a look here https://github.com/mojohaus/

Olivier

On 3 June 2015 at 16:57, Curtis Rueden ctrue...@wisc.edu wrote:

 Hi everyone,

 It looks like Codehaus SVN is finally kaput:

 $ svn checkout http://svn.codehaus.org/mojo
 svn: E175011: Unable to connect to a repository at URL '
 http://svn.codehaus.org/mojo'
 svn: E175011: Repository moved temporarily to 'http://www.codehaus.org
 ';
 please relocate

 But the mojo repository is not yet populated on GitHub:
 https://github.com/codehaus/mojo

 Is it planned to populate that repository? Where does the code live in the
 meantime?

 Thanks,
 Curtis




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: 409 Error Code with deploy-file

[Olivier Lamy]

file:// means it's deployed to your file system :-)


On 21 May 2015 at 16:05, Zk W mpc8...@gmail.com wrote:

 Hi Olivier


 Thanks for responding.

 It is unclear why when using file:// syntax for url argument, the upload
 messages showed.

 But when I tried looking for the artifact in local repo of Artifactory
 snapshot-local, it isnt there.


 Log below:

 [INFO] Scanning for projects...

 [INFO]


 [INFO]
 

 [INFO] Building Maven Stub Project (No POM) 1

 [INFO]
 

 [INFO]

 [INFO] --- maven-deploy-plugin:2.5:deploy-file (default-cli) @
 standalone-pom ---

 Uploading: file://
 abc.com:8080/artifactory/snapshot-local/gxxx/ayyy/1.1.1.1/ayyy-1.1.1.1.zip

 Uploaded: file://
 abc.com:8080/artifactory/snapshot-local/gxxx/ayyy/1.1.1.1/ayyy-1.1.1.1.zip
 (18656 KB at 34166.8 KB/sec)

 Uploading: file://
 abc.com:8080/artifactory/snapshot-local/gxxx/ayyy/1.1.1.1/ayyy-1.1.1.1.pom

 Uploaded: file://
 abc.com:8080/artifactory/snapshot-local/gxxx/ayyy/1.1.1.1/ayyy-1.1.1.1.pom
 (423 B at 206.5 KB/sec)

 Downloading: file://
 abc.com:8080/artifactory/snapshot-local/gxxx/ayyy/maven-metadata.xml

 Downloaded: file://
 abc.com:8080/artifactory/snapshot-local/gxxx/ayyy/maven-metadata.xml (304
 B
 at 148.4 KB/sec)

 Uploading: file://
 abc.com:8080/artifactory/snapshot-local/gxxx/ayyy/maven-metadata.xml

 Uploaded: file://
 abc.com:8080/artifactory/snapshot-local/gxxx/ayyy/maven-metadata.xml (304
 B
 at 296.9 KB/sec)

 [INFO]
 

 [INFO] BUILD SUCCESS

 [INFO]
 

 [INFO] Total time: 1.068s

 [INFO] Finished at: Wed May 20 22:58:20 PDT 2015

 [INFO] Final Memory: 3M/227M

 [INFO]
 

 On Wed, May 20, 2015 at 8:59 PM, Olivier Lamy ol...@apache.org wrote:

  I think you need to have a look at your repository manager (which looks
 to
  be artifactory)
  You got 409 http response which means conflict.
  From your parameters I can imagine different reasons (
  -DrepositoryId=snapshots
  -DgroupId=gxxx -DartifactId=ayyy -Dversion=1.1.1.1
  -Dpackaging=zip -Durl=http://abc.com:8080/artifactory/snapshot-local ) :
  * you try deploying a non snapshot version to a snapshot repository
  * you redeploy a non snapshot version (which is usually forbidden and
  definitely a bad idea)
 
  HTH
  Olivier
 
 
 
 
 
  On 21 May 2015 at 13:55, Zk W mpc8...@gmail.com wrote:
 
   Hi All
  
   We tried
  
   mvn -X deploy:deploy-file -Dfile=ayyy.zip -DgeneratePom=true
   -DrepositoryId=snapshots -DgroupId=gxxx -DartifactId=ayyy
  -Dversion=1.1.1.1
   -Dpackaging=zip -Durl=http://abc.com:8080/artifactory/snapshot-local
  
  
   but we got error when trying to upload the artifact to Artifactory.
   We tried different options and none worked
   1)  Add nonProxyHosts in settings.xml
   2) In Artifactory snapshot-local repo, set Suppress POM Consistency
  Checks
   3) In Artifactory, set Checksum policy to Trust Server Generated
 Checksum
  
   Is there something to do with Wagon file that we need to download ?
  
   We are using Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800)
  
   Thanks for your help.
  
  
   Error log below:
  
   [INFO] Final Memory: 35M/227M
  
   [INFO]
  
 
  
   [ERROR] Failed to execute goal
   org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy-file
  (default-cli)
   on project standalone-pom: Failed to deploy artifacts: Could not
 transfer
   artifact gxxx:ayyy:zip:1.1.1.1 from/to snapshots (
   http://abc.com:8080/artifactory/snapshot-local): Failed to transfer
  file:
  
  
 
 http://abc.com:8080/artifactory/snapshot-local/gxxx/ayyy/1.1.1.1/ayyy-1.1.1.1.zip
   .
   Return code is: 409 - [Help 1]
  
   org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
 execute
   goal org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy-file
   (default-cli) on project standalone-pom: Failed to deploy artifacts:
  Could
   not transfer artifact gxxx:ayyy:zip:1.1.1.1 from/to snapshots (
   http://abc.com:8080/artifactory/snapshot-local): Failed to transfer
  file:
  
  
 
 http://abc.com:8080/artifactory/snapshot-local/gxxx/ayyy/1.1.1.1/ayyy-1.1.1.1.zip
   .
   Return code is: 409
  
   at
  
  
 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
  
   at
  
  
 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
  
   at
  
  
 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
  
   at
  
  
 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
  
   at
  
  
 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject

Re: 409 Error Code with deploy-file

[Olivier Lamy]

 at

 org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:141)

 at

 org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:236)

 ... 21 more

 Caused by: org.sonatype.aether.deployment.DeploymentException: Failed to
 deploy artifacts: Could not transfer artifact gxxx:ayyy:zip:1.1.1.1 from/to
 snapshots (http://abc.com:8080/artifactory/snapshot-local): Failed to
 transfer file:

 http://abc.com:8080/artifactory/snapshot-local/gxxx/ayyy/1.1.1.1/ayyy-1.1.1.1.zip
 .
 Return code is: 409

 at

 org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:284)

 at

 org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:215)

 at

 org.sonatype.aether.impl.internal.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:480)

 at

 org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:137)

 ... 22 more

 Caused by: org.sonatype.aether.transfer.ArtifactTransferException: Could
 not transfer artifact gxxx:ayyy:zip:1.1.1.1 from/to snapshots (
 http://abc.com:8080/artifactory/snapshot-local): Failed to transfer file:

 http://abc.com:8080/artifactory/snapshot-local/gxxx/ayyy/1.1.1.1/ayyy-1.1.1.1.zip
 .
 Return code is: 409

 at

 org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap(WagonRepositoryConnector.java:949)

 at

 org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap(WagonRepositoryConnector.java:940)

 at

 org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.flush(WagonRepositoryConnector.java:864)

 at

 org.sonatype.aether.connector.wagon.WagonRepositoryConnector.put(WagonRepositoryConnector.java:466)

 at

 org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:278)

 ... 25 more

 Caused by: org.apache.maven.wagon.TransferFailedException: Failed to
 transfer file:

 http://abc.com:8080/artifactory/snapshot-local/gxxx/ayyy/1.1.1.1/ayyy-1.1.1.1.zip
 .
 Return code is: 409

 at

 org.apache.maven.wagon.providers.http.LightweightHttpWagon.finishPutTransfer(LightweightHttpWagon.java:205)

 at org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:413)

 at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:392)

 at org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:365)

 at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:163)

 at

 org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:825)

 at

 org.sonatype.aether.connector.wagon.WagonRepositoryConnector.put(WagonRepositoryConnector.java:465)

 ... 26 more

 [ERROR]




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: about source and target in maven-compiler-plugin

[Olivier Lamy]

On 30 March 2015 at 16:46, Lin Ma lin...@gmail.com wrote:

 Hello Maven masters,

 For maven-compiler-plugin(a sample below), have a quick question. I read
 this document (http://maven.apache.org/plugins/maven-compiler-plugin/),
 and
 confused what means source and target 1.5 here, it seems it is an internal
 version number of Maven, independent of JDK?


No. You should read here
http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#source
.
Linked to
http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#options
see source and target options

HTH
Olivier




 plugin
 artifactIdmaven-compiler-plugin/artifactId
 version2.3.2/version
 configuration
 source1.5/source
 target1.5/target
 /configuration
 /plugin

 thanks in advance,
 Lin




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

[ANN] Apache Archiva 2.2.0 Released

[Olivier Lamy]

The Apache Archiva team is pleased to announce the release of Archiva
2.2.0. Archiva is available for download from the web site.

Archiva is an application for managing one or more remote
repositories, including administration, artifact handling, browsing
and searching.

If you have any questions, please consult:

the web site: http://archiva.apache.org/
the archiva-user mailing list: http://archiva.apache.org/mail-lists.html

Apache Archiva 2.2.0 is a bugs fix release:

NOTE: jdk 1.7 is now prerequisite with Apache Archiva 2.2.0

Compatibility Changes

If upgrading from earlier versions of Archiva, the list of libraries
in wrapper.conf has changed. If you have customized your copy of
wrapper.conf, please update it for compatibility with the version
distributed with the current release.
As the database storage has been removed, you can remove the JNDI
entry for jdbc/archiva. After upgrading from a previous version, you
will have to run a full scan to populate the new JCR Repository. This
will be done on first start of Archiva.

Refer to the Upgrading Archiva guide for more information.

Release Notes



** Improvement
* [MRM-1390] - Generic metadata should be searcheable in Archiva search
* [MRM-1844] - Allow LDAP groupOfNames

** New Feature
* [MRM-1867] - Adding a find jar by checksum functionality to the REST api

** Bug
* [MRM-770] - Archiva web client does not recognize classifier
* [MRM-813] - Audit log is reporting Modify File (proxied) when
no proxy connectors exist and the file has not changed
* [MRM-837] - Cannot download SNAPSHOT version
* [MRM-935] - Archiva doesn't supports artifact with
versionSNAPSHOT/version
* [MRM-1145] - RSS tests do not correctly check responses
* [MRM-1311] - Logging in ArtifactMissingChecksumsConsumer does
not appear in the logs even if configured properly
* [MRM-1486] - ldap.config.mapper.attribute.user.filter using ldap
not working correctly with commas.
* [MRM-1767] - When selecting a specific repository to browse, I
get an error  that I don't have sufficient privileges.
* [MRM-1807] - Archiva wrapper fail to start
* [MRM-1810] - LDAP - groups config not available in Users Runtime
Configuration - Properties
* [MRM-1811] - Users - Manage section: pagination needs to change
* [MRM-1846] - Regression in 2.0.1 : uniqueVersion false not supported
* [MRM-1848] - download links for files mult-dot extensions
incorrect in Browse view
* [MRM-1851] - generic metadata GUI broken
* [MRM-1860] - ClassNotFound exception with JBoss
* [MRM-1863] - RepositoryGroup URL is not build using the Application URL
* [MRM-1864] - Default configuration for central should now use SSL
* [MRM-1871] - ConcurrentModificationException in
DefaultRepositoryProxyConnectors
* [MRM-1873] - archiva doesn't recognise ldap-group to ldap-users mapping


** Task
* [MRM-1359] - Remove Maven 1.x functionality
* [MRM-1865] - remove isPermanent from Consumer API


Have fun!
-- 
The Apache Archiva Team

Re: takari-plugin-integration-testing requires one takari-jar project ?

[Olivier Lamy]

On 27 February 2015 at 06:00, Manfred Moser manf...@mosabuam.com wrote:

 Cristiano,

 You can have them all in one project. E.g. the Android Maven Plugin does
 that.

 https://github.com/simpligility/android-maven-plugin

 Olivier,

 I thought this is a Maven users mailing list and as such open to all
 questions regarding usage of Maven. I would understand the need to separate
 things out if there is tons of traffic ( 100 posts a day or so) but as it
 stands the list is rather quiet so I think it should be fine to discuss
 anything related to Maven usage here.

 Do you agree?


I didn't want to be rude (sorry if it looks like).
As it looks the question is related to an other project which is not hosted
within the Apache Maven project neither developed by Apache Maven
committers.
I believe this mailing list is related to the Apache Maven project.
So my goal was only to help Cristiano and tell him to ask in the place
where this project is hosted and to the people who maintained it.
It's probably better to have more accurate answers.






 Manfred

 Olivier Lamy wrote on 25.02.2015 18:23:

  Hi,
  AFAIK this Takari project is not hosted neither maintained here at Apache
  by Apache Maven developers.
  So for any questions please ask directly maintainers or find a user group
  related to it (maybe it's documented on their website).
 
  Cheers
  Olivier
 
  On 26 February 2015 at 03:52, Cristiano Gavião cvgav...@gmail.com
 wrote:
 
  Hi,
 
  It is necessary to concentrate the maven plugin integration tests in its
  own  takari-jar project ?
 
  I'm asking because I have test poms inside src/test/projects being
  duplicated on both Plugin and Plugin IT projects.
  Maybe I could put both UT and IT in the same plugin project ?
 
  thanks,
 
  Cristiano
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
 
  --
  Olivier Lamy
  http://twitter.com/olamy | http://linkedin.com/in/olamy
 

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




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: takari-plugin-integration-testing requires one takari-jar project ?

[Olivier Lamy]

Hi,
AFAIK this Takari project is not hosted neither maintained here at Apache
by Apache Maven developers.
So for any questions please ask directly maintainers or find a user group
related to it (maybe it's documented on their website).

Cheers
Olivier

On 26 February 2015 at 03:52, Cristiano Gavião cvgav...@gmail.com wrote:

 Hi,

 It is necessary to concentrate the maven plugin integration tests in its
 own  takari-jar project ?

 I'm asking because I have test poms inside src/test/projects being
 duplicated on both Plugin and Plugin IT projects.
 Maybe I could put both UT and IT in the same plugin project ?

 thanks,

 Cristiano

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




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Jitpack?

[Olivier Lamy]

On 20 February 2015 at 13:19, Laird Nelson ljnel...@gmail.com wrote:

 Has anyone else seen this? https://jitpack.io/  Or am I just living under
 a
 rock as usual?

 Anyway, I thought it was kind of interesting.


Yup interesting



 Best,
 Laird

 --
 http://about.me/lairdnelson




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: E-Book Beter Builds with Maven seems to be missing

[Olivier Lamy]

links fixed.

On 25 November 2014 at 13:14, Russell Gold r...@gold-family.us wrote:
 I found it on Scribd - I assume this is the one you mean.

 http://www.scribd.com/doc/238927/Better-Builds-With-Maven

 On Nov 11, 2014, at 3:09 AM, Nick Stolwijk nick.stolw...@gmail.com wrote:

 Hi all,

 It seems the link from the External Resources[1] to the e-book Beter
 Builds with Maven'[2] is broken.

 Is this still being hosted elsewhere? (I couldn't find it with a quick
 search) Or should we remove it from our site?

 [1] http://maven.apache.org/articles.html
 [2] http://www.maestrodev.com/better-build-maven

 With regards,

 Nick Stolwijk

 ~~~ Try to leave this world a little better than you found it and, when
 your turn comes to die, you can die happy in feeling that at any rate you
 have not wasted your time but have done your best ~~~

 Lord Baden-Powell

 -
 Author, Getting Started with Apache Maven 
 http://www.packtpub.com/getting-started-with-apache-maven/video
 Author, HttpUnit http://www.httpunit.org and SimpleStub 
 http://simplestub.meterware.com

 Come read my webnovel, Take a Lemon http://www.takealemon.com,
 and listen to the Misfile radio play 
 http://www.fuzzyfacetheater.com/misfile/!









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




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

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

Re: [ANN] Apache Maven Wagon 2.8

[Olivier Lamy]

Hi,
Pushed in master.


On 17 November 2014 19:51, Jeroen Hoek jer...@lable.org wrote:
 Hello,

 Maven Wagon 2.7 (and presumably 2.8) fixes a bug in Maven related to
 client-side SSL certificates by upgrading its dependencies to a newer
 version of Apache HttpComponents httpclient. This is great, because it
 is now possible to use Maven with a private artefact repository
 secured with two-way SSL verification.

 However Apache Maven itself still depends on Wagon 2.6, at least in
 the stable release and on its git master. When might there be a stable
 Maven release depending on Maven Wagon 2.7 or 2.8?

 2014-11-17 1:15 GMT+01:00 Olivier Lamy ol...@apache.org:
 Hi,
 The Apache Maven team is pleased to announce the release of Apache
 Maven Wagon 2.8.
 Apache Maven Wagon is a transport abstraction that is used in Maven's
 artifact and repository handling code.

 Web site: http://maven.apache.org/wagon/

 Release Notes - Maven Wagon - Version 2.8

 ** Bug
 * [WAGON-416] - Lightweight HTTP Wagon doesn't set
 Proxy-Authorization header
 * [WAGON-422] - HTTP wagon AuthScope is not definable from settings


 Have fun
 --
 The Apache Maven Team

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


 Kind regards,

 Jeroen Hoek
 Lable

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




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

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

[ANN] Apache Maven Wagon 2.8

[Olivier Lamy]

Hi,
The Apache Maven team is pleased to announce the release of Apache
Maven Wagon 2.8.
Apache Maven Wagon is a transport abstraction that is used in Maven's
artifact and repository handling code.

Web site: http://maven.apache.org/wagon/

Release Notes - Maven Wagon - Version 2.8

** Bug
* [WAGON-416] - Lightweight HTTP Wagon doesn't set
Proxy-Authorization header
* [WAGON-422] - HTTP wagon AuthScope is not definable from settings


Have fun
-- 
The Apache Maven Team

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

Re: Need help regarding apache maven

[Olivier Lamy]

Hi,
No idea what is your setup or your Maven distribution but you use a
wagon implementation which is not supported here:
com.ning.http.client.providers.netty 

Cheers
Olivier

On 2 October 2014 04:09, sameer chandekar sameerchandekar2...@gmail.com wrote:
 Hi,

 Please help me to resolve issue I am facing with apache maven.

 I am trying to implement continuous integration.For which i am using apache
 maven with build server. I have setup a repository using visual svn
 server.I've created build using maven now when I try to deploy the build on
 remote repository I am facing issue.
 I am getting error code as 409 confilct  unable to deploy artifact . I've
 attached the error logs in the attachment. I've tried to find similar issue
 in apache mailing list but didn't find any solution.

 Waiting for your reply and thanks in advance.

 Regards,
 Sameer Chandekar


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



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

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

[ANN] Apache Maven Wagon 2.7 Released

[Olivier Lamy]

The Apache Maven team is pleased to announce the release of Apache
Maven Wagon 2.7.

Maven Wagon is a transport abstraction that is used in Maven's
artifact and repository handling code.
http://maven.apache.org/wagon/

Release Notes - Maven Wagon - Version 2.7


** New Feature
* [WAGON-420] - Implements RFC 6585 (return code 429: too many requests)

** Bug
* [WAGON-407] - wagon-maven-plugin ITs fail with missing class:
org.apache.commons.io.IOUtils
* [WAGON-418] - Changes from WAGON-388 broke the WebDAV Wagon
* [WAGON-419] - HTTP wagons incorrectly encode blank space in URLs
causing resources to be uploaded/looked up with a + sign

Have fun!
-- 
The Apache Maven Team

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

Re: nonProxyHosts not working

[Olivier Lamy]

sounds more a tomcat maven plugin rather than a maven issue.
Can you log an issue here: https://issues.apache.org/jira/browse/MTOMCAT


On 9 September 2014 03:56,  john.e.gr...@wellsfargo.com wrote:
 All,

 I've tried Maven 3.1.1 and 3.2.3 but can't get nonProxyHosts in settings.xml 
 to work in some cases.  I'm trying to deploy a war to Tomcat using the Tomcat 
 Maven plugin version 2.3.  It works fine if I set active=false in the proxy 
 config.

 I think this works:

   proxies
 proxy
   activetrue/active
   protocolhttp/protocol
   hostproxy.mycompany.com/host
   port80/port
   nonProxyHosts*.mycompany.com/nonProxyHosts
 /proxy
   /proxies

 This does not:

   proxies
 proxy
   activetrue/active
   protocolhttp/protocol
   hostproxy.mycompany.com/host
   port80/port
   nonProxyHostslocalhost|*.mycompany.com/nonProxyHosts
 /proxy
   /proxies

 Likewise, using just localhost, my machine name, and commas instead of pipes 
 doesn't work, either.  The plugin tries to upload the war to my company's 
 proxy, which eventually responds with a 404 The hostname localhost cannot 
 be found.  Please check the URL you are trying to reach to verify that it is 
 spelled correctly.

 This is in the log:

 [INFO] Deploying war to http://localhost:8080/coherence-extend-web
 Uploading: 
 http://localhost:8080/manager/text/deploy?path=%2Fcoherence-extend-web
 Uploaded: 
 http://localhost:8080/manager/text/deploy?path=%2Fcoherence-extend-web (8409 
 KB at 3024.7 KB/sec)

 [ERROR] Tomcat return http status error: 404, Reason Phrase: Not Found

 That looks correct except the error isn't quite right because Tomcat isn't 
 even being hit.  I get the same error if Tomcat isn't running.  It's the 
 proxy server that is returning the error.

 I know everything else is correct because if I set active=false, the deploy 
 succeeds.

 Thanks

 John




-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

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

[ANN] Apache Archiva 2.1.1 Released

[Olivier Lamy]

The Apache Archiva team is pleased to announce the release of Archiva
2.1.1. Archiva is available for download from the web site.

Archiva is an application for managing one or more remote
repositories, including administration, artifact handling, browsing
and searching.

If you have any questions, please consult:

the web site: http://archiva.apache.org/
the archiva-user mailing list: http://archiva.apache.org/mail-lists.html

Apache Archiva 2.1.1 is a bugs fix release:

NOTE: jdk 1.7 is now prerequisite with Apache Archiva 2.1.1

Compatibility Changes

If upgrading from earlier versions of Archiva, the list of libraries
in wrapper.conf has changed. If you have customized your copy of
wrapper.conf, please update it for compatibility with the version
distributed with the current release.
As the database storage has been removed, you can remove the JNDI
entry for jdbc/archiva. After upgrading from a previous version, you
will have to run a full scan to populate the new JCR Repository. This
will be done on first start of Archiva.

Refer to the Upgrading Archiva guide for more information.

Release Notes

Bug

[MRM-1832] - RepositoryScannerTest#testDefaultRepositoryScanner fails
on Linux with src release zip
[MRM-1853] - On first start up, you get a perpetual loading indicator.
[MRM-1854] - Last modified date is epoch on directory listing for a group
[MRM-1855] - Loading button never disappears when no one is logged
in in some browsers
[MRM-1856] - archiva-cli does not work


Have fun!
-- 
The Apache Archiva Team

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

[ANN] Apache Archiva 2.1.0

[Olivier Lamy]

Hi,

The Apache Archiva team would like to announce the release of Archiva
2.1.0. Archiva is available for download from the web site (
http://archiva.apache.org )

Archiva is an application for managing one or more remote
repositories, including administration, artifact handling, browsing
and searching.

If you have any questions, please consult:

the web site: http://archiva.apache.org/
the archiva-user mailing list: http://archiva.apache.org/mail-lists.html

New in Archiva 2.1.0

Apache Archiva 2.1.0 is a bugs fix release:

NOTE: jdk 1.7 is now prerequisite with Apache Archiva 1.7

Compatibility Changes

If upgrading from earlier versions of Archiva, the list of libraries
in wrapper.conf has changed. If you have customized your copy of
wrapper.conf, please update it for compatibility with the version
distributed with the current release.
As the database storage has been removed, you can remove the JNDI
entry for jdbc/archiva. After upgrading from a previous version, you
will have to run a full scan to populate the new JCR Repository. This
will be done on first start of Archiva.

Refer to the Upgrading Archiva guide for more information.

Release Notes

The Archiva 2.1.0 features set can be seen in the feature tour.

Changes in Archiva 2.1.0

Released: 20th July 2014

Improvement

[MRM-1210] - Dependency tree should include the artifact type
[MRM-1558] - Please provide some UI element which shows degraded
and/or badly connected remote repository
[MRM-1802] - Find a cache solution for browsing part (especially root browsing)
[MRM-1829] - Change default value of of AysncLogger strategy for log4j async
[MRM-1834] - Add limit to index search query to prevent unnecessary calculations
[MRM-1836] - Make search limit (maxCount) configurable via UI
[MRM-1843] - provide mechanism to obtain the latest version of an artifact

Bug

[MRM-887] - Start script has no valid uname option
[MRM-1809] - Users - Manage section sort by name doesn't work as expected
[MRM-1812] - Users - Manage section needs Sort by User Name, Sort by
Full Name, and Sort by Email buttons
[MRM-1813] - Users - Manage section filters don't seem to work
[MRM-1823] - java 1.7 as prerequisite
[MRM-1824] - metadata storage using Cassandra
[MRM-1825] - MD5 hashes are for wrong file name
[MRM-1826] - Force Internet Explorer into Standards Mode
[MRM-1830] - Charset applied to binary repository HTTP responses
[MRM-1833] - Nullpointer when browsing artifacts which have
dependencies with scope import
[MRM-1837] - DefaultArchivaConfiguration holds references to classes
[MRM-1841] - Remember me not working
[MRM-1842] - Remove per default log4j2 Async Logging
[MRM-1846] - Regression in 2.0.1 : uniqueVersion false not supported
[MRM-1849] - Unable to download -SNAPSHOT jars after 2.0.1 Upgrade



Have fun!
-- 
The Apache Archiva Team

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

Re: Unable to download maven ant tasks

[Olivier Lamy]

I just fixed that.

Cheers
Olivier

On 21 May 2014 21:52, Andreas Sandberg andreasf...@hotmail.com wrote:
 http://maven.apache.org/ant-tasks/download.cgi

 When trying to download the latest Maven ant tasks Ant plugin I retrieve an 
 403 forbidden error.

 BR!
 // Andreas








-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

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

[ANN] Apache Maven Shade Plugin 2.3 Released

[Olivier Lamy]

The Apache Maven team is pleased to announce the release of the Apache
Maven Shade Plugin, version 2.3.

This plugin provides the capability to package the artifact in an
uber-jar, including its dependencies and to shade - i.e. rename - the
packages of some of the dependencies.

http://maven.apache.org/plugins/maven-shade-plugin/

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

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-shade-plugin/artifactId
  version2.3/version
/plugin

Release Notes - Maven Shade Plugin - Version 2.3

** Bug
* [MSHADE-166] - maven-shade-plugin not compatible with Java 8

** Improvement
* [MSHADE-167] - [PATCH] When individual classes are renamed, they
are not debuggable


Have Fun!
--
The Apache Maven team

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