Re: [VOTE] Require Java 17 for Maven 4

[Enrico Olivelli]

+1 (Non binding)

Enrico

Il Gio 29 Feb 2024, 09:01 Tim te Beek  ha scritto:

> +1  from occasional contributor
>
> Would unblock phasing out more utils methods & dependencies.
>
> On Thu, Feb 29, 2024 at 8:53 AM Thomas Matthijs  wrote:
>
> > +1
> >
> >
> > On Wed, Feb 28, 2024, at 08:30, Benjamin Marwell wrote:
> > > Hi Maven Devs/Users/Committers and PMC members!
> > >
> > > After several discussions on the mailing lists, I would like to
> > > start a vote in favour of setting the minimal Java bytecode target
> > > of Maven-Core 4 to 17 and hence require Java 17 for Maven 4.
> > >
> > > This is a procedural majority vote [1*]:
> > > You can also vote with fractions and negative votes are not vetoes.
> > >
> > > Please also notice:
> > > * Maven 3 will stay at Java 8 no matter what.
> > > * We may raise Maven 4 to JDK 21 later if we feel like it (depending
> > > on the release date).
> > >   This is not part of this vote.
> > > * The linked PR is not part of this vote (this is not a code vote).
> > >   But you may take a look at it to understand the intended change.
> > >
> > > PR: https://github.com/apache/maven/pull/1430
> > >
> > > Maven-Parent will not be raised with this vote, the other PR is not
> > > part of this vote.
> > >
> > > Please refrain from starting discussions in this thread, but do
> > > include a reasoning on downvotes and feel free to start a new
> > > discussion on the mailing list, or comment on the existing ones.
> > >
> > > ---
> > >
> > > Vote open for 72 hours:
> > >
> > > [ ] +1 (set JDK17 min version for Maven 4.x)
> > > [ ] +0
> > > [ ] -1 (please include reasoning)
> > >
> > > ---
> > >
> > > - Ben
> > >
> > > [1*]: https://www.apache.org/foundation/voting.html
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Surefire leaking ClassMethod

[Enrico Olivelli]

Il Mer 12 Lug 2023, 00:15 Clebert Suconic  ha
scritto:

> On Tue, Jul 11, 2023 at 6:13 PM Clebert Suconic
>  wrote:
> >
> > How tests are simulated within maven-surefire? is there any example?
>
> I mean... a test testing the test! Something that will call surefire
> and its unit tests and validate outcome?
>

There are many integration tests in the surefire repository.
Initially it is not straightforward to understand but it works.
Unfortunately it passed some time since I wrote tests for surefire.

I hope that others in this list my help

Enrico

>
> >
> > Would I be able to create an optional module where I do a test-leak
> > using my library to validate if it leaked or not?
> >
> > On Tue, Jul 11, 2023 at 5:33 PM Clebert Suconic
> >  wrote:
> > >
> > > I tried looking at how I would contribute a fix, but I lacked an
> > > understanding on how tests are performed in surefire.
> > >
> > > Also: would you accept a test that's using check-leak to prevent
> > > future leaks like this? (maybe a separate sub-module for this
> > > test?)... and where I would add such test?
> > >
> > > I would even dedicate my personal time into proposing a fix if I can
> > > get some basic understanding about this.
> > >
> > >
> > > Is there a chat channel I can ask questions about the codebase? or the
> > > user's or dev's list is a good place to start?
> > >
> > > On Tue, Jul 11, 2023 at 5:24 PM Enrico Olivelli 
> wrote:
> > > >
> > > > Clebert,
> > > >
> > > >
> > > >
> > > > Il Mar 11 Lug 2023, 15:55 Clebert Suconic 
> ha
> > > > scritto:
> > > >
> > > > > created a JIRA:
> > > > >
> > > > > https://issues.apache.org/jira/browse/SUREFIRE-2186
> > > >
> > > >
> > > >
> > > > Thanks.
> > > > Would you have time to contribute a fix?
> > > >
> > > > Enrico
> > > >
> > > > >
> > > > >
> > > > > On Tue, Jul 11, 2023 at 9:33 AM Clebert Suconic
> > > > >  wrote:
> > > > > >
> > > > > > You guys need to be careful with non static ThreadLocals.
> > > > > >
> > > > > >
> > > > > > ClassMethodIndexer has a non static ThreadLocal.
> > > > > >
> > > > > > threadLocals will create a hashEntry somewhere deep in the JDK.
> > > > > > Depending on the number of tests that are running you guys may
> break
> > > > > > things like ReadWriteLock because it will transverse a lot of
> entries.
> > > > > > (I have been bitten by this before).
> > > > > >
> > > > > >
> > > > > > Also, I have a reproducer:
> > > > > >
> > > > > >
> > > > > > git clone
> https://github.com/clebertsuconic/surefire-reproducer.git
> > > > > > cd surefire-reproducer
> > > > > > mvn install
> > > > > >
> > > > > >
> > > > > >
> > > > > > This little project is using check-leak to count the number of
> > > > > > instances of ClassObject. I have set the assertions as max 20
> > > > > > instances. I have a copy test that is validating this over
> and
> > > > > > over.
> > > > > >
> > > > > >
> > > > > > And it's always leaking inside a ConcurrentHashMap that's being
> held
> > > > > > by ClassMethodIndex which is used by JUnit4Listener.
> > > > > >
> > > > > >
> > > > > >
> > > > > > and you guys should really stop using non static ThreadLocals..
> I have
> > > > > > found another case where it was used but at least the remove was
> > > > > > called.. but still a bit scary to my test (It should just use a
> static
> > > > > > final... what's the point of a ThreadLocal if it's not static on
> a
> > > > > > class an associated to the instance?)
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Should I open a JIRA about this?
> > > > > >
> > > > > > On Mon, Jul 10, 2023 at 2:13 PM Clebert Suconic
> > > > > >  wrote:
> > > > &g

Re: Surefire leaking ClassMethod

[Enrico Olivelli]

Clebert,



Il Mar 11 Lug 2023, 15:55 Clebert Suconic  ha
scritto:

> created a JIRA:
>
> https://issues.apache.org/jira/browse/SUREFIRE-2186



Thanks.
Would you have time to contribute a fix?

Enrico

>
>
> On Tue, Jul 11, 2023 at 9:33 AM Clebert Suconic
>  wrote:
> >
> > You guys need to be careful with non static ThreadLocals.
> >
> >
> > ClassMethodIndexer has a non static ThreadLocal.
> >
> > threadLocals will create a hashEntry somewhere deep in the JDK.
> > Depending on the number of tests that are running you guys may break
> > things like ReadWriteLock because it will transverse a lot of entries.
> > (I have been bitten by this before).
> >
> >
> > Also, I have a reproducer:
> >
> >
> > git clone https://github.com/clebertsuconic/surefire-reproducer.git
> > cd surefire-reproducer
> > mvn install
> >
> >
> >
> > This little project is using check-leak to count the number of
> > instances of ClassObject. I have set the assertions as max 20
> > instances. I have a copy test that is validating this over and
> > over.
> >
> >
> > And it's always leaking inside a ConcurrentHashMap that's being held
> > by ClassMethodIndex which is used by JUnit4Listener.
> >
> >
> >
> > and you guys should really stop using non static ThreadLocals.. I have
> > found another case where it was used but at least the remove was
> > called.. but still a bit scary to my test (It should just use a static
> > final... what's the point of a ThreadLocal if it's not static on a
> > class an associated to the instance?)
> >
> >
> >
> >
> > Should I open a JIRA about this?
> >
> > On Mon, Jul 10, 2023 at 2:13 PM Clebert Suconic
> >  wrote:
> > >
> > > We have recently upgraded surefire into artemis  from 2.x, and
> > > strangely our testsuite started to crash because of memory.
> > >
> > >
> > > So, it happens that I had other memory leaks in the past and I became
> > > addicted into finding them, up to a point that I created a project
> > > that will track memory usage over a java app, or be used on test cases
> > > to make sure leaks are not happening:
> > >
> > >
> > > https://github.com/check-leak/check-leak
> > >
> > >
> > > So,
> > >
> > >
> > > I ran this testsuite from artemis:
> > >
> > > git clone g...@github.com:apache/activemq-artemis.git
> > > cd activemq-artemis
> > > mvn install -DskipTests=true
> > > cd tests/integration-tests
> > > mvn -Ptests tests
> > >
> > >
> > >
> > > get check-leak:
> > > curl
> https://github.com/check-leak/check-leak/releases/download/0.11/check-leak-0.11.jar
> > >
> > > so after finding the process ID for the surefire:
> > > java -jar check-leak-0.11.jar --sleep 5000 --pid 
> > > --report ./report-leak
> > >
> > >
> > >
> > > As the test progress, open ./report-leak/index.html
> > >
> > >
> > > you may refresh the page as the process go.
> > >
> > >
> > > and if you look at the objects  allocations for
> > > org.apache.maven.surefire.api.util.internal.ClassMethod, the
> > > allocations are only growing after the lates version, and never being
> > > released.
> > >
> > >
> > >
> > >
> > > is there any idea about what might be causing it?
> > >
> > >
> > > if you have a big project with many tests like I do, memory
> > > allocations may be an issue and I would need to use a bigger VM just
> > > because of this probably leak.
> >
> >
> >
> > --
> > Clebert Suconic
>
>
>
> --
> Clebert Suconic
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Maven 3.8 Difference between thread count and forkcount for suitsAndClasses parallelism

[Enrico Olivelli]

Debraj,
each module is running surefire independently.
I hope that this explains the behavior you are seeing


Enrico

Il giorno mar 7 giu 2022 alle ore 15:28 Debraj Manna
 ha scritto:
>
> I have asked the same in stackoverflow
> 
> also. Any one any thoughts?
>
> On Mon, Jun 6, 2022 at 7:25 PM Debraj Manna 
> wrote:
>
> > I read the link
> > 
> > .
> >
> > For parallel = classes, mvn test -T 5 , reuseForks = true & forkCount = 2
> > maven will build and run 5 modules in parallel. During the test phase of
> > each module surefire is getting called and surefire is spawning 2 JVM to
> > distribute the tests. Once all the tests are finished in module surefire
> > fork will be termintated. Again a new surefire fork will be created for
> > executing tests in another module. Only for a module, surefire fork will be
> > reused. Is my understanding correct?
> >
> > What happens for suitesAndClasses? How are the tests distributed?
> >
> >
> >
> > On Mon, Jun 6, 2022 at 1:19 PM Debraj Manna 
> > wrote:
> >
> >> Hi
> >>
> >> I am having a surefire configuration like below
> >>
> >> 
> >>  2
> >>  true
> >> false
> >> suitesAndClasses
> >> 
> >>
> >> In a multimodule maven project if I am executing mvn test -T 5 then how
> >> does parallelism work here? Will it be that in surefire fork1 5 tests
> >> classes will be running in parallel and same in fork2?
> >>
> >> Maven Version 3.8.4
> >> Surefire version 3.0.0-M6
> >>
> >>

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

Re: surefire and system.exit

[Enrico Olivelli]

Tim,
Usually I set a SecurityManager that prevents calls to System.exit. You
will have to allow Surefire (and probably also your IDE test runner) to
allow to use System.exit.

Enrico

Il giorno mer 28 lug 2021 alle ore 16:18 Tim Allison 
ha scritto:

> All,
>
>   I'm trying to upgrade the surefire plugin in Apache Tika, and I'm
> running into "forked vm terminated without properly saying goodbye"
> [0].
>
>   Tika uses a bunch of dependencies we have no control over.  At one
> point, we had a parser with a "feature" that called System.exit.  We
> have code that defends against this kind of thing by forking and
> monitoring the forked process for early termination, and we'd like to
> test this forking code.  Is there any way to test this with more
> recent versions of the surefire plugin, or is there a recommended
> workaround?
>
>   Thank you.
>
> Best,
>
>   Tim
>
> [0]
> http://maven.apache.org/surefire/maven-surefire-plugin/faq.html#vm-termination
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: apache-source-release-assembly-descriptor does not retain correctly file permissions

[Enrico Olivelli]

Hervé,

Il giorno mer 16 giu 2021 alle ore 07:43 Hervé BOUTEMY
 ha scritto:
>
> if you need to have consistent executable flags, you need to avoid getting it 
> from filesystem, because it is dependent on OS and user configuration
> that's why for example, on such requirements in Maven (core), we use a 
> dedicated assembly descriptor instead of the generic one [1]
>

thank you very much
very clear

Enrico

> HTH
>
> Hervé
>
> [1] 
> https://github.com/apache/maven/blob/master/apache-maven/src/assembly/maven/component.xml
>
> Le lundi 14 juin 2021, 09:16:57 CEST Enrico Olivelli a écrit :
> > Hello,
> > It looks like following this guide in order to create a good "source
> > bundle" for an ASF Project (in this case Apache Pulsar) leads to a
> > strange behaviour.
> > https://maven.apache.org/apache-resource-bundles/
> >
> > Basically some files miss the 'executable' flag, this way when the
> > user unpacks the released sources the build does not work because
> > there are scripts that are not executable.
> >
> > more context here
> > https://github.com/apache/pulsar/issues/10917
> >
> > Has anyone had the same experience ?
> >
> > Regards
> > Enrico
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

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

apache-source-release-assembly-descriptor does not retain correctly file permissions

[Enrico Olivelli]

Hello,
It looks like following this guide in order to create a good "source
bundle" for an ASF Project (in this case Apache Pulsar) leads to a
strange behaviour.
https://maven.apache.org/apache-resource-bundles/

Basically some files miss the 'executable' flag, this way when the
user unpacks the released sources the build does not work because
there are scripts that are not executable.

more context here
https://github.com/apache/pulsar/issues/10917

Has anyone had the same experience ?

Regards
Enrico

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

Re: Why does Maven Shade relocate modify unrelated classes?

[Enrico Olivelli]

Alexander,
thank you for moving forward with this and come to provide a patch

I am generally +1 with the patch, but I left some comment
https://github.com/apache/maven-shade-plugin/pull/95

let's follow up on the PR

Enrico

Il giorno ven 21 mag 2021 alle ore 11:41 Alexander Kriegisch
 ha scritto:
>
> Just so as to wrap it up here, in case anyone is interested in the topic
> as such instead on the meta discussion that ensued before:
>
> https://issues.apache.org/jira/browse/MSHADE-391
> https://github.com/apache/maven-shade-plugin/pull/95
>
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Alexander Kriegisch schrieb am 16.05.2021 09:41 (GMT +07:00):
>
> > When running Maven Shade with relocation, it works nicely. When
> > comparing JARs before and after relocation, I was surprised to see
> > that Shade not just modifies the relocated classes and classes
> > referencing them, but also a bunch of IMO completely unrelated
> > classes. In my case I am transforming an uber JAR containing ASM, and
> > I selectively relocate the ASM classes, intending to leave all others
> > untouched. I know that ASM classes are referred to by some of the
> > other classes, but by no means as many as are being modified. The byte
> > code is slightly different, probably still does the same thing, but it
> > makes comparisons and sanity checks or automatic verification steps
> > harder than necessary. BTW, the same Shade execution also relocates
> > the sources and really only changes source files referencing ASM, just
> > like I would have expected.
> >
> > Looking forward to your insights
>
> -
> 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: Trying out new verbose dependency tree: very slow result

[Enrico Olivelli]

Il giorno lun 3 mag 2021 alle ore 14:14 Nick Stolwijk
 ha scritto:
>
> Hi Enrico,
>
> I did a search and replace on our domain name. The Nexus instance at our
> company is a mirror for Maven Central.
>
> And it is the only repository used in the build. See the output for
> list-repositories in the last mail.

I also see these repo:
http://www.jasperforge.org/maven2
https://repository.apache.org/snapshots
https://community.jaspersoft.com/maven2

off topic: you can try to upgrade to Maven 3.8.1 in order to skip
accesses to non-https repositories and to pick up a few enhancements
about Repository management.


Enrico


>
> Hth,
>
> 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
>
>
> On Mon, May 3, 2021 at 2:02 PM Enrico Olivelli  wrote:
>
> > Il giorno lun 3 mag 2021 alle ore 13:56 Nick Stolwijk
> >  ha scritto:
> > >
> > > Hi Enrico,
> > >
> > > It looks like it is trying to update the world while using repositories I
> > > can't explain. ;-)
> >
> > Do you have references to several third party repositories ?
> >
> > it looks like https://nexus.example.com is not a good repo
> >
> > Enrico
> >
> > >
> > > [INFO] --- maven-dependency-plugin:3.1.4-SNAPSHOT:list-repositories
> > > (default-cli) @ commons-lang ---
> > > Downloading from public_nx3:
> > >
> > https://nexus.example.com/repository/public/com/example/bibliotheek/utilities/commons-lang/1.5.2-SNAPSHOT/maven-metadata.xml
> > > Downloaded from public_nx3: https://nexus.
> > >
> > example.com/repository/public/com/example/bibliotheek/utilities/commons-lang/1.5.2-SNAPSHOT/maven-metadata.xml
> > > (1.7 kB at 1.9 kB/s)
> > > [INFO] Repositories used by this build:
> > > [INFO]id: public_nx3
> > >   url: https://nexus.example.com/repository/public/
> > >layout: default
> > > snapshots: [enabled => true, update => daily]
> > >  releases: [enabled => true, update => daily]
> > >
> > > Output of Maven debug:
> > >
> > > [INFO] --- maven-dependency-plugin:3.1.4-SNAPSHOT:tree (default-cli) @
> > > commons-lang ---
> > > [DEBUG] Using mirror public_nx3 (
> > > https://nexus.example.com/repository/public/) for apache.snapshots (
> > > http://people.apache.org/maven-snapshot-repository).
> > > [DEBUG] Using mirror public_nx3 (
> > > https://nexus.example.com/repository/public/) for ow2-snapshot (
> > > http://repository.ow2.org/nexus/content/repositories/snapshots).
> > > [DEBUG] Dependency collection stats {ConflictMarker.analyzeTime=569300,
> > > ConflictMarker.markTime=273500, ConflictMarker.nodeCount=434,
> > > ConflictIdSorter.graphTime=329300, ConflictIdSorter.topsortTime=63200,
> > > ConflictIdSorter.conflictIdCount=93,
> > > ConflictIdSorter.conflictIdCycleCount=0,
> > > ConflictResolver.totalTime=2936900,
> > ConflictResolver.conflictItemCount=194,
> > > DefaultDependencyCollector.collectTime=347565200,
> > > DefaultDependencyCollector.transformTime=4219500}
> > > [DEBUG]
> > org.apache.maven.plugins:maven-dependency-plugin:jar:3.1.4-SNAPSHOT
> > > [DEBUG]org.apache.maven:maven-artifact:jar:3.1.1:compile
> > > [DEBUG]org.apache.maven:maven-plugin-api:jar:3.1.1:compile
> > > [DEBUG]
> >  org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M5:compile
> > > [DEBUG]  javax.enterprise:cdi-api:jar:1.0:compile
> > > [DEBUG] javax.annotation:jsr250-api:jar:1.0:compile
> > > [DEBUG] javax.inject:javax.inject:jar:1:compile
> > > [DEBUG]  com.google.guava:guava:jar:10.0.1:compile
> > > [DEBUG] com.google.code.findbugs:jsr305:jar:1.3.9:compile
> > > [DEBUG]  org.sonatype.sisu:sisu-guice:jar:no_aop:3.1.0:compile
> > > [DEBUG] aopalliance:aopalliance:jar:1.0:compile
> > > [DEBUG]
> > >  org.eclipse.sisu:org.eclipse.sisu.inject:jar:0.0.0.M5:compile
> > > [DEBUG]org.apache.maven:maven-model:jar:3.1.1:compile
> > > [DEBUG]org.apache.maven:maven-core:jar:3.1.1:compile
> > > [DEBUG]   org.apache.maven:maven-settings-builder:jar:3.1.1:compile
> > > [DEBUG]   org.apache.maven:maven-model-builder:jar:3.1.1:compile
> > > [DEBUG]   org.eclipse.aether:aether-impl:jar:0.9.0.M2:compile
> > > [DEBUG]   org

Re: Trying out new verbose dependency tree: very slow result

[Enrico Olivelli]

Il giorno lun 3 mag 2021 alle ore 13:56 Nick Stolwijk
 ha scritto:
>
> Hi Enrico,
>
> It looks like it is trying to update the world while using repositories I
> can't explain. ;-)

Do you have references to several third party repositories ?

it looks like https://nexus.example.com is not a good repo

Enrico

>
> [INFO] --- maven-dependency-plugin:3.1.4-SNAPSHOT:list-repositories
> (default-cli) @ commons-lang ---
> Downloading from public_nx3:
> https://nexus.example.com/repository/public/com/example/bibliotheek/utilities/commons-lang/1.5.2-SNAPSHOT/maven-metadata.xml
> Downloaded from public_nx3: https://nexus.
> example.com/repository/public/com/example/bibliotheek/utilities/commons-lang/1.5.2-SNAPSHOT/maven-metadata.xml
> (1.7 kB at 1.9 kB/s)
> [INFO] Repositories used by this build:
> [INFO]id: public_nx3
>   url: https://nexus.example.com/repository/public/
>layout: default
> snapshots: [enabled => true, update => daily]
>  releases: [enabled => true, update => daily]
>
> Output of Maven debug:
>
> [INFO] --- maven-dependency-plugin:3.1.4-SNAPSHOT:tree (default-cli) @
> commons-lang ---
> [DEBUG] Using mirror public_nx3 (
> https://nexus.example.com/repository/public/) for apache.snapshots (
> http://people.apache.org/maven-snapshot-repository).
> [DEBUG] Using mirror public_nx3 (
> https://nexus.example.com/repository/public/) for ow2-snapshot (
> http://repository.ow2.org/nexus/content/repositories/snapshots).
> [DEBUG] Dependency collection stats {ConflictMarker.analyzeTime=569300,
> ConflictMarker.markTime=273500, ConflictMarker.nodeCount=434,
> ConflictIdSorter.graphTime=329300, ConflictIdSorter.topsortTime=63200,
> ConflictIdSorter.conflictIdCount=93,
> ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=2936900, ConflictResolver.conflictItemCount=194,
> DefaultDependencyCollector.collectTime=347565200,
> DefaultDependencyCollector.transformTime=4219500}
> [DEBUG] org.apache.maven.plugins:maven-dependency-plugin:jar:3.1.4-SNAPSHOT
> [DEBUG]org.apache.maven:maven-artifact:jar:3.1.1:compile
> [DEBUG]org.apache.maven:maven-plugin-api:jar:3.1.1:compile
> [DEBUG]   org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M5:compile
> [DEBUG]  javax.enterprise:cdi-api:jar:1.0:compile
> [DEBUG] javax.annotation:jsr250-api:jar:1.0:compile
> [DEBUG] javax.inject:javax.inject:jar:1:compile
> [DEBUG]  com.google.guava:guava:jar:10.0.1:compile
> [DEBUG] com.google.code.findbugs:jsr305:jar:1.3.9:compile
> [DEBUG]  org.sonatype.sisu:sisu-guice:jar:no_aop:3.1.0:compile
> [DEBUG] aopalliance:aopalliance:jar:1.0:compile
> [DEBUG]
>  org.eclipse.sisu:org.eclipse.sisu.inject:jar:0.0.0.M5:compile
> [DEBUG]org.apache.maven:maven-model:jar:3.1.1:compile
> [DEBUG]org.apache.maven:maven-core:jar:3.1.1:compile
> [DEBUG]   org.apache.maven:maven-settings-builder:jar:3.1.1:compile
> [DEBUG]   org.apache.maven:maven-model-builder:jar:3.1.1:compile
> [DEBUG]   org.eclipse.aether:aether-impl:jar:0.9.0.M2:compile
> [DEBUG]   org.codehaus.plexus:plexus-interpolation:jar:1.19:compile
> [DEBUG]   org.codehaus.plexus:plexus-classworlds:jar:2.5.1:compile
> [DEBUG]
> org.codehaus.plexus:plexus-component-annotations:jar:2.0.0:compile (version
> managed from default)
> [DEBUG]   org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3:compile
> [DEBUG]  org.sonatype.plexus:plexus-cipher:jar:1.4:compile
> [DEBUG]org.apache.maven:maven-repository-metadata:jar:3.1.1:compile
> [DEBUG]org.apache.maven:maven-settings:jar:3.1.1:compile
> [DEBUG]org.apache.maven:maven-aether-provider:jar:3.1.1:compile
> [DEBUG]   org.eclipse.aether:aether-spi:jar:0.9.0.M2:compile
> [DEBUG]org.apache.maven.reporting:maven-reporting-api:jar:3.0:compile
> [DEBUG]org.apache.maven.reporting:maven-reporting-impl:jar:3.0.0:compile
> [DEBUG]
> org.apache.maven.doxia:doxia-decoration-model:jar:1.7.4:compile
> [DEBUG]commons-io:commons-io:jar:2.6:compile
> [DEBUG]org.apache.maven.doxia:doxia-sink-api:jar:1.9.1:compile
> [DEBUG]   org.apache.maven.doxia:doxia-logging-api:jar:1.9.1:compile
> [DEBUG]org.apache.maven.doxia:doxia-core:jar:1.9.1:compile
> [DEBUG]   org.codehaus.plexus:plexus-container-default:jar:1.7.1:compile
> [DEBUG]  org.apache.xbean:xbean-reflect:jar:3.7:compile
> [DEBUG]  com.google.collections:google-collections:jar:1.0:compile
> [DEBUG]   org.apache.httpcomponents:httpclient:jar:4.5.8:compile
> [DEBUG]  commons-logging:commons-logging:jar:1.2:compile
> [DEBUG]  commons-codec:commons-codec:jar:1.11:compile
> [DEBUG]   org.apache.httpcomponents:httpcore:jar:4.4.11:compile
> [DEBUG]org.apache.maven.doxia:doxia-site-renderer:jar:1.9.2:compile
> [DEBUG]   org.apache.maven.doxia:doxia-skin-model:jar:1.9.2:compile
> [DEBUG]   org.apache.maven.doxia:doxia-module-xhtml:jar:1.9.1:compile
> [DEBUG]   

Re: Trying out new verbose dependency tree: very slow result

[Enrico Olivelli]

Nick,
are you able to see what is doing Maven in those 30 minutes ?

you can  run with the "-X" flag to see Maven debug

also using jstack may be a good starting point if logs do not help.

Cheers
Enrico

Il giorno lun 3 mag 2021 alle ore 13:43 Nick Stolwijk
 ha scritto:
>
> Hi folks,
>
> I was curious about the new verbose functionality in the
> maven-dependency-plugin.[1] I cloned the repository and built a local
> snapshot of master.
>
> Even on a very simple project building the verbose dependency tree took 30
> minutes!
>
> I am using Maven 3.8.1 and Java 16.
>
> Is this a known issue? Is there something wrong with my local setup? Can I
> do something to analyse this?
>
> [INFO] Scanning for projects...
> [INFO]
> [INFO] < com.example.bibliotheek.utilities:commons-lang
> >-
> [INFO] Building Bibliotheek - Commons-Lang 1.5.2-SNAPSHOT
> [INFO] ---[ bundle
> ]---
> [INFO]
> [INFO] --- maven-dependency-plugin:3.1.4-SNAPSHOT:tree (default-cli) @
> commons-lang ---
> [INFO] com.example.bibliotheek.utilities:commons-lang:bundle:1.5.2-SNAPSHOT
> [INFO] +- org.apache.commons:commons-lang3:jar:3.12.0:compile
> [INFO] +- org.junit.jupiter:junit-jupiter-api:jar:5.7.1:test
> [INFO] +- org.assertj:assertj-core:jar:3.19.0:test
> [INFO] \- nl.jqno.equalsverifier:equalsverifier:jar:3.5.4:test
> [INFO]
> 
> [INFO] BUILD SUCCESS
> [INFO]
> 
> [INFO] Total time:  31:47 min
> [INFO] Finished at: 2021-05-03T12:51:06+02:00
> [INFO]
> 
>
> [1] https://issues.apache.org/jira/browse/MDEP-644
>
> 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

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

Re: maven release process and Integration test artifact version tracking

[Enrico Olivelli]

Zos,
you can also use preparationGoals and completionGoals in order to
update any other file that it is not in the pom.xml file
https://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html

This is an example of usage in Apache ZooKeeper project:
https://github.com/apache/zookeeper/pull/1162/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R831

Enrico

Il giorno ven 23 apr 2021 alle ore 22:38 Benjamin Marwell
 ha scritto:
>
> Hi Zos,
>
> you probably want to write
>   @project.version@
> for your artifact. It will get replaced with the version number of the
> enclosing module.
>
> It is listed in the usage page (as a side note):
> https://maven.apache.org/plugins/maven-invoker-plugin/usage.html
>
> Here is a random example of one of the maven plugins:
> https://github.com/apache/maven-jlink-plugin/blob/36cff867d5d6a74941e5131a20a7301b89fae65d/src/it/projects/MJLINK-41_addoptions-11/pom.xml#L53
>
> - Ben
>
> Am Mi., 21. Apr. 2021 um 10:00 Uhr schrieb Zos ROTHKO :
> >
> > Hello Maven's users
> >
> > I have a problem about tracking the new snapshot version of an jar
> > artifact within the integration test running the maven-invoker-plugin.
> >
> > Each integration test project is using the snapshot version of the jar
> > artifact as a runtime dependency of a 3rd party maven plugin. When there
> > is a maven release of the artifact, its version is changing to another
> > version which is specified at the release time. But since the IT pom are
> > not processed by the maven release plugin, the version of the jar
> > artifact stays as its previous shapshot version and not the new one.
> >
> > How could be know to the maven release plugin that it should also update
> > the version used in the IT pom?
> >
> > For those interested, the maven projects can be cloned from this git
> > repository: g...@github.com:javacc/javacc-8-java.git
> > 
> >
> > Rgds
> >
> > FA
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

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

Re: Using Internal Api's (jdk.javadoc) with Maven

[Enrico Olivelli]

Brandon,
which JDK are you using ?

I have a finding that is related to your issue and probably the solution
will be in common.
While testing the Apache ZooKeeper project in the scope of the Quality
Outreach JDK project I have encountered this issue and we are still
investigating.
https://bugs.openjdk.java.net/browse/JDK-8253996
It is about having jdk.javadoc module available to javac when we are using
maven-compiler-plugin and running javac in the same process as Maven (using
fork=true fixes the problem).
In fact from JDK16+ in order to be able to use -Xdoclint:-missing compiler
argument that jdk.javadoc module must be on the module path, but is it not
present while running Maven (is it because Maven is running with the
classpath and the module path ??)

Adding --add-modules=jdk.javadoc does not help.

I have not raised an issue to maven-compiler-plugin (or plexus compiler or
to Maven core) because the issue is still under triage by JDK team

hope that helps
Enrico


Il giorno lun 19 ott 2020 alle ore 07:27 Brandon Lax 
ha scritto:

> Hi,
>
> I was hoping to get some help with an issue I have been facing relating to
> the maven-compiler-plugin. I have been using the jdk.javadoc api as part of
> my project. The code can compile directly (by running javac on the main
> file), but when trying to build with maven I get error messages that the
> package jdk.javadoc can not be found. Previously, the solution had been to
> add the Tools.jar <
> https://stackoverflow.com/questions/3080437/jdk-tools-jar-as-maven-dependency>
> file as a dependency, as that jar contained headers for most of the
> internal apis, but that jar was removed in java 9. Does anyone know of how
> to setup the compiler plugin to access these internal apis.
>
> Best,
> Brandon
>
>

Re: 'mvn clean test' crashes

[Enrico Olivelli]

Something like this:

public class NoExitSecurityManager extends SecurityManager {

private final SecurityManager wrapped;

public static void setup() {
Policy.setPolicy(new Policy() {

final Permissions pc = new Permissions();

{
pc.add(new AllPermission());
}

@Override
public boolean implies(ProtectionDomain domain, Permission
permission) {
return true;
}

@Override
public PermissionCollection getPermissions(ProtectionDomain
domain) {
return pc;
}

@Override
public PermissionCollection getPermissions(CodeSource
codesource) {
return pc;
}

});
System.setSecurityManager(new NoExitSecurityManager());
}

public NoExitSecurityManager() {
wrapped = new SecurityManager();
}

public NoExitSecurityManager(SecurityManager wrapped) {
this.wrapped = wrapped;
}

@Override
public void checkExit(int status) {
StackTraceElement[] stackTrace =
Thread.currentThread().getStackTrace();
if (stackTrace != null) {
for (StackTraceElement el : stackTrace) {
String className = el.getClassName();
if (className != null
&&
className.startsWith("org.apache.maven.surefire.booter.ForkedBooter")
&& ("acknowledgedExit".equals(el.getMethodName())
|| "exit".equals(el.getMethodName( {
return;
}
}
}
throw new SecurityException("System.exit is disabled on unit
tests");

}

@Override
public void checkPermission(Permission perm) {
if (wrapped == null) {
return;
}
if (perm instanceof FilePermission) {
// preveniamo errori su Jenkins
return;
}
if (perm instanceof ReflectPermission) {
return;
}
wrapped.checkPermission(perm);
}

}

Il giorno ven 9 ott 2020 alle ore 09:19 Mukul Gandhi 
ha scritto:

> On Wed, Oct 7, 2020 at 9:09 PM Enrico Olivelli 
> wrote:
>
> > A good approach to workaround the presence of third party libraries that
> > call System.exit is to set a SecurityManager that prevents calls to
> > System.exit.
>
>
> I'll find it helpful, if you may share any code sample how to do this?
>
>
>
> --
> Regards,
> Mukul Gandhi
>

Re: 'mvn clean test' crashes

[Enrico Olivelli]

A good approach to workaround the presence of third party libraries that
call System.exit is to set a SecurityManager that prevents calls to
System.exit. I did it a few times with good results.
You will have to allow well known libraries like Eclipse test runner or
Surefire itself

Just my 2 cents

Enrico

Il giorno mer 7 ott 2020 alle ore 09:50 Mukul Gandhi 
ha scritto:

> Hi Tibor,
>
> On Wed, Sep 30, 2020 at 5:03 PM Tibor Digana 
> wrote:
>
> > Usually these errors appear in the test itself or the *libraries*.
> > As for instance, we found out that a Spring's library is implementing
> Kafka
> > stuff calling the "Runtime.getRuntime().halt(  )".
> > The same bad thing is to call the "System.exit()".
> > I have recognized this situation after I saw a crashed test in your logs.
> > The test is supposed to be crashed if the execution breaks abruptly
> without
> > receiving a JUnit/TestNG event about finishing the test, see this log:
> >
> > *[ERROR] Crashed tests: [ERROR] com.haldiram.business.helper.t*
> > *est.SuspiciousActivityHelperTe**st*
> >
>
> Nowhere within my code (that's been tested by junit) and within my unit
> tests, I've used things like 'Runtime.getRuntime().halt' or 'System.exit'.
>
> The following within the logs that I've shared,
>
> (i.e *[ERROR] Crashed tests: [ERROR] com.haldiram.business.helper.t*
> *est.SuspiciousActivityHelperTe**st*)
>
> that you've cited, doesn't indicate any of the things like use
> of 'Runtime.getRuntime().halt' or 'System.exit'. For the information, the
> name 'SuspiciousActivityHelper' is a business name within my application,
> and is not anything related to technical suspicious aspects within my
> application or test codebases.
>
> The issues that I've discussed within this thread, still causes the same
> problems to me.
>
>
>
>
> --
> Regards,
> Mukul Gandhi
>

Re: Maven Plugins & Confusing Versioning

[Enrico Olivelli]

Lukas,
The general rule is that we are not releasing unstable versions so it is
generally safe and good to upgrade to lasted version.

The 3.x means that the plugin is compatible with Maven 3.x (if you see 2.x
than it should work with Maven 3. But it was released when the reference
Maven version was 2.x)

The Mx suffix is only an internal version to the dev team of Maven. We mean
that it is a milestone in a sense that we would have wanted to deliver a
feature that is not implemented completely yet.
You should care about that only of you write extensions that depend of that
specific plugin.

We are usually cutting versions only from the master branch and the master
branch is continuously tested against a big matrix of OSs, Maven versions
and Java version.

I hope that helps
Enrico

Il Sab 3 Ott 2020, 09:30  ha scritto:

> Hi All & Maven Devs
>
>
>
> My name is Lukas, I'm a software engineer working at some very little
> company located in Switzerland (called Quatico).
>
> I wanted to let you know that the versioning that is used in (as far as I
> can see) all Maven Plugins (e.g. Apache Maven Install Plugin 3.0.0-M1) is
> very confusing .
>
> I can see on the corresponding Website (e.g.
> https://maven.apache.org/plugins/maven-install-plugin/download.cgi ) the
> these milestone releases are declared to be stable.
>
>
>
> My company did not upgrade plugin versions basically for some years now
> because (when just seeing the version itself) decided "Nope, its only a
> milestone, thus not stable".
>
> So in contrast to the maven plugin versions, the community is pretty clear
> about what x.y.z-M1 means: It's a pre-release for early testing purposes
> (e.g. see you "partner" projects explanation for it here
> https://en.wikipedia.org/wiki/Software_versioning ).
>
>
>
> I don't want to complain (I now know the versions are stable) but the usage
> of your new version would probably pike much quicker around the work if you
> followed the "regular" versioning scheme.
>
> Why use the Major part (3), then completely ignoring Minor (always 0) and
> Patch (always 0 as well) parts, to then fall back to Milestones? I cannot
> see an advantage in it.
>
>
>
> Hope the input might help!
>
>
>
> Cheers
>
> Lukas
>
>
>
>

Re: Strange maven sonar download warning?

[Enrico Olivelli]

Il Dom 30 Ago 2020, 05:52 Dan Tran  ha scritto:

> don't see similar warnings when using with sonar-maven-plugin-3.6.x
>
> -D
>
> On Sat, Aug 29, 2020 at 8:13 PM Dan Tran  wrote:
>
> >
> > Hello to all
> >
> > I am seeing the bellow warning at my build with no build failure.  Wonder
> > if anyone else sees the same thing?
> >
> > *19:22:30*  [WARNING] The POM for
> org.sonarsource.scanner.maven:sonar-maven-plugin:jar:?3.7.0.1746 is
> missing, no dependency information available*19:22:30*  [WARNING] Failed to
> retrieve plugin descriptor for
> org.sonarsource.scanner.maven:sonar-maven-plugin:?3.7.0.1746: Plugin
> org.sonarsource.scanner.maven:sonar-maven-plugin:?3.7.0.1746 or one of its
> dependencies could not be resolved: Failure to find
> org.sonarsource.scanner.maven:sonar-maven-plugin:jar:?3.7.0.1746 in
> https://my.inernal.maven .repo
> was cached in the local repository, resolution will not be reattempted
> until the update interval of brs has elapsed or updates are forced
>

Probably you had problems during the download of some file.

You can try to run your build with -U flag or clean up your .m2/repository
directory, this way you will start with a clean local repository (that's
basically a cache)

Enrico


>
> >
> > Thanks
> >
> >
> > -D
> >
> >
>

Re: New release of release plugin

[Enrico Olivelli]

I have added a comment to the PR.
Robert also did and the contributor is waiting for Robert's feedback


Enrico

Il Mer 5 Ago 2020, 10:42 Konrad Windszus  ha scritto:

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

Re: 'mvn clean test' crashes

[Enrico Olivelli]

I suggest you to debug that test, with an IDE or just by adding some
System.out.println

Enrico

Il Mer 1 Lug 2020, 09:41 Mukul Gandhi  ha scritto:

> Hi Enrico,
>
> On Wed, Jul 1, 2020 at 11:34 AM Enrico Olivelli 
> wrote:
>
> > Can you try to run one test at a time and see which test is crashing your
> > build?
> >
> > Use
> > mvn test -Dtest=NameOfTheTestClass
> >
>
> When I run all my tests, with command 'mvn clean test', my build failed
> with following message,
>
> [ERROR] Crashed tests:
> [ERROR] com.haldiram.business.helper.test.ApplnHelperTest
> ...
>
> When I run only the tests present in class
> com.haldiram.business.helper.test.ApplnHelperTest, with following command,
>
> mvn clean test -Dtest=com.haldiram.business.helper.test.ApplnHelperTest
>
> The Maven build emits following error,
>
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time:  24.624 s
> [INFO] Finished at: 2020-07-01T12:56:40+05:30
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test)
> on project Verimployee-core: No tests were executed!  (Set
> -DfailIfNoTests=false to ignore this error.)
>
> Therefore, I run the above command as follows,
>
> mvn clean test
> -Dtest=com.haldiram.business.helper.test.ApplnHelperTest
> -DfailIfNoTests=false
>
> And all the tests present in class
> com.haldiram.business.helper.test.ApplnHelperTest pass, and the Maven build
> succeeds.
>
> My problem, that I described originally in this thread, still remains. I
> hope, someone may help me further on this issue.
>
>
>
>
> --
> Regards,
> Mukul Gandhi
>

Re: 'mvn clean test' crashes

[Enrico Olivelli]

Can you try to run one test at a time and see which test is crashing your
build?

Use
mvn test -Dtest=NameOfTheTestClass


Enrico

Il Mer 1 Lug 2020, 07:37 Mukul Gandhi  ha scritto:

> Hi Enrico,
>
> On Wed, Jul 1, 2020 at 10:47 AM Enrico Olivelli 
> wrote:
>
>
> > Are you walking System.exit or System.halt in your tests?
> >
>
> I'm not using either of System.exit or System.halt within my tests code.
> I'm also neither, using these two statements within my business logic code.
>
>
>
> --
> Regards,
> Mukul Gandhi
>

Re: 'mvn clean test' crashes

[Enrico Olivelli]

Mukul
Are you walking System.exit or System.halt in your tests?


Enrico


Il Mer 1 Lug 2020, 07:09 Mukul Gandhi  ha scritto:

> Hi all,
> I've been facing some problem during last few weeks, when using the
> 'mvn clean test' command to run unit tests within my Maven project. At some
> point before when this issue is creating problem for me, the 'mvn clean
> test' command was working fine with me and all unit tests within my Maven
> project were passing. But I'm yet unable to find the reason, why 'mvn clean
> test' command is not working for me now.
>
> When I run the command 'mvn clean test' now, my Maven build fails and
> following error trace is emitted,
>
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time:  05:51 min
> [INFO] Finished at: 2020-07-01T09:44:06+05:30
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test)
> on project haldiram-restapis: There are test failures.
> [ERROR]
> [ERROR] Please refer to
>
> F:\eclipseWorkspaces\haldiram_backend_sprint-19_sts\haldiram-backend\haldiram-restapis\target\surefire-reports
> for the individual test results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash
> or System.exit called?
> [ERROR] Command was cmd.exe /X /C "C:\jdk1.8.0_241\jre\bin\java -jar
>
> C:\Users\mukul\AppData\Local\Temp\surefire7064994840408638817\surefirebooter5568422068326404815.jar
> C:\Users\mukul\AppData\Local\Temp\surefire7064994840408638817
> 2020-07-01T09-38-42_797-jvmRun1 surefire5010876784124620015tmp
> surefire_07470042422408053869tmp"
> [ERROR] Process Exit Code: 0
> [ERROR] Crashed tests:
> [ERROR] com.haldiram.business.helper.test.ApplnHelperTest
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The
> forked VM terminated without properly saying goodbye. VM crash or
> System.exit called?
> [ERROR] Command was cmd.exe /X /C "C:\jdk1.8.0_241\jre\bin\java -jar
>
> C:\Users\mukul\AppData\Local\Temp\surefire7064994840408638817\surefirebooter5568422068326404815.jar
> C:\Users\mukul\AppData\Local\Temp\surefire7064994840408638817
> 2020-07-01T09-38-42_797-jvmRun1 surefire5010876784124620015tmp
> surefire_07470042422408053869tmp"
> [ERROR] Process Exit Code: 0
> [ERROR] Crashed tests:
> [ERROR] com.haldiram.business.helper.test.ApplnHelperTest
> [ERROR] at
>
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:669)
> [ERROR] at
>
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> [ERROR] at
>
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> [ERROR] at
>
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
> [ERROR] at
>
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
> [ERROR] at
>
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:857)
> [ERROR] at
>
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> [ERROR] at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
> [ERROR] at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
> [ERROR] at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> [ERROR] at
>
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR] at
>
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR] at
>
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
> [ERROR] at
>
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
> [ERROR] at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
> [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957)
> [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289)
> [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:193)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> [ERROR] at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at
>
> 

Re: Surefire 3.0.0-M4 not failing build on errors

[Enrico Olivelli]

Il Sab 13 Giu 2020, 15:07 Jeff Jensen  ha scritto:

> Hi Enrico,
> Thanks for the reply.
>
> Surefire 2.22.2 correctly fails the build.  This is with Java 8 and JUnit
> 5.
>


This sounds interesting.

It looks like a big bug to me and it is worth a JIRA

It would help a lot if you could attach a simple reproducer for the problem.
If you know surefire codebase it would also help a lot to create the
reproducer as an integration test

Thanks

Enrico


>
> On Sat, Jun 13, 2020 at 12:41 AM Enrico Olivelli 
> wrote:
>
> > Jeff
> >
> > Il Sab 13 Giu 2020, 00:15 Jeff Jensen  >
> > ha scritto:
> >
> > > I looked for this issue in JIRA but haven't found anything yet.  Anyone
> > > know if this has been reported and/or fixed?
> > >
> > > Our scenario is a failure occurs at startup of tests but Surefire
> doesn't
> > > fail the build.  Specifically, Spring controller tests aren't failing
> > when
> > > there is a Spring configuration problem.
> > >
> > > Spring top-level thrown exception is:
> > >   java.lang.IllegalStateException: Failed to load ApplicationContext
> > >
> > > but Surefire doesn't report fail.  Surefire output results is:
> > >   Tests run: 0, Failures: 0, Errors: 0, Skipped: 0,
> > >
> > > Running the tests in an IDE correctly fail for the setup problem.
> > >
> >
> > Which IDE?
> >
> > Did  you try other versions of surefire? Like the latest from 2.x release
> > line?
> >
> > Regards
> > Enrico
> >
>

Re: Surefire 3.0.0-M4 not failing build on errors

[Enrico Olivelli]

Jeff

Il Sab 13 Giu 2020, 00:15 Jeff Jensen 
ha scritto:

> I looked for this issue in JIRA but haven't found anything yet.  Anyone
> know if this has been reported and/or fixed?
>
> Our scenario is a failure occurs at startup of tests but Surefire doesn't
> fail the build.  Specifically, Spring controller tests aren't failing when
> there is a Spring configuration problem.
>
> Spring top-level thrown exception is:
>   java.lang.IllegalStateException: Failed to load ApplicationContext
>
> but Surefire doesn't report fail.  Surefire output results is:
>   Tests run: 0, Failures: 0, Errors: 0, Skipped: 0,
>
> Running the tests in an IDE correctly fail for the setup problem.
>

Which IDE?

Did  you try other versions of surefire? Like the latest from 2.x release
line?

Regards
Enrico

Re: Recent troubles with release:prepare

[Enrico Olivelli]

Il Mer 6 Mag 2020, 08:29 Francesco Chicchiriccò  ha
scritto:

> Hi Enrico,
> see my replies below.
>
> Regards.
>
> On 2020/05/04 21:18:26, Enrico Olivelli  wrote:
> > Francesco,
> > which version of Maven are you using ? (you told you have tried different
> > Maven versions)
>
> I am normally using 3.6.3; tried 3.5.4 and 3.3.9.
>
> > what is so special in skipTests profile ?
>
> It is not evident to me, here is why I linked its definition below, maybe
> you can spot something I am not able to see.
>
> > did you update to latest version of Apache Parent pom ?
>
> Yes, as you can see from the linked pom, e.g.
>
> https://github.com/apache/syncope/blob/syncope-2.1.6/pom.xml#L32-L37
>
> > which version of the release plugin are you using ?
>
> Ah, this observation made me look more thoroughly: I found a mismatch
> between ASF parent pom version 3.0.0-M1 and local 2.5.3; after fixing this
> it seem everything is back working again.
>
> Thanks!
>

You are welcome

Cheers
Enrico



> > Il giorno lun 4 mag 2020 alle ore 15:36 Francesco Chicchiriccò <
> > ilgro...@apache.org> ha scritto:
> >
> > > Hi all,
> > > at Syncope we've been ordinarily using the Release Plugin as part of
> our
> > > release process [1] since the beginning, and it's been working
> flawlessly
> > > for > 90 releases.
> > >
> > > Unfortunately we had troubles with last two releases (Syncope 2.1.6 /
> > > 2.0.15) that we cut last week.
> > >
> > > For some reason, release:prepare was not advancing POM files as
> expected,
> > > e.g. after running
> > >
> > > mvn -P apache-release release:prepare -Darguments="-P
> skipTests,all,docker
> > > -DbuildNumber=syncope-2.1.6"
> > >
> > > and providing 2.1.6 as release version and 2.1.7-SNAPSHOT as next
> > > development version, the build started without changing the POM files,
> e.g.
> > >
> > > diff pom.xml pom.xml.releaseBackup
> > >
> > > was empty.
> > >
> > > In fact, the artifacts were produced for 2.1.6-SNAPSHOT, not for 2.1.6.
> > >
> > > I tried with different Release Plugin version, different Maven versions
> > > but nothing.
> > >
> > > I have just found, however, that if I am *not* passing the skipTests
> > > profile in -Darguments then it works as expected.
> > >
> > > The skipTests profile is defined as in [2]: any idea about the reason
> of
> > > the behavior described above?
> > >
> > > TIA
> > > Regards.
> > >
> > > [1] http://syncope.apache.org/release-process
> > > [2] https://github.com/apache/syncope/blob/2_1_X/pom.xml#L2710-L2755
> > >
> > > -
> > > 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: Recent troubles with release:prepare

[Enrico Olivelli]

Francesco,
which version of Maven are you using ? (you told you have tried different
Maven versions)

what is so special in skipTests profile ?
did you update to latest version of Apache Parent pom ?
which version of the release plugin are you using ?

Enrico


Il giorno lun 4 mag 2020 alle ore 15:36 Francesco Chicchiriccò <
ilgro...@apache.org> ha scritto:

> Hi all,
> at Syncope we've been ordinarily using the Release Plugin as part of our
> release process [1] since the beginning, and it's been working flawlessly
> for > 90 releases.
>
> Unfortunately we had troubles with last two releases (Syncope 2.1.6 /
> 2.0.15) that we cut last week.
>
> For some reason, release:prepare was not advancing POM files as expected,
> e.g. after running
>
> mvn -P apache-release release:prepare -Darguments="-P skipTests,all,docker
> -DbuildNumber=syncope-2.1.6"
>
> and providing 2.1.6 as release version and 2.1.7-SNAPSHOT as next
> development version, the build started without changing the POM files, e.g.
>
> diff pom.xml pom.xml.releaseBackup
>
> was empty.
>
> In fact, the artifacts were produced for 2.1.6-SNAPSHOT, not for 2.1.6.
>
> I tried with different Release Plugin version, different Maven versions
> but nothing.
>
> I have just found, however, that if I am *not* passing the skipTests
> profile in -Darguments then it works as expected.
>
> The skipTests profile is defined as in [2]: any idea about the reason of
> the behavior described above?
>
> TIA
> Regards.
>
> [1] http://syncope.apache.org/release-process
> [2] https://github.com/apache/syncope/blob/2_1_X/pom.xml#L2710-L2755
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Maven Surefire Forked Test Execution in a multimodule project

[Enrico Olivelli]

Manna

Il Gio 9 Apr 2020, 13:09 Debraj Manna  ha scritto:

> Hi
>
> I am reading the maven surefire documentation
> <
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html
> >
> about
> the forked test execution. It states
>
> *The default setting is forkCount=1/reuseForks=true, which means that
> maven-surefire-plugin creates one new JVM process to execute all tests in
> one Maven module.*
>
> *forkCount=1/reuseForks=false executes each test class in its own JVM
> process, one after another. It creates the highest level of separation for
> the test execution, but it would probably also give you the longest
> execution time of all the available options. Consider it as a last reso*rt.
>
>
> Can someone resolve my below doubts about the above para:
>
> In a maven multimodule project if I am setting forkcount=3 /
> reuseForks=true. Then does that mean maven-surefire-plugin will create 3
> new JVM processes and then execute tests from 3 modules in 3 JVM and all
> tests from a module will be running in the same JVM?
>

No.
If you want to run parallel execution of modules you have to use -T option
This is independent from surefire

Enrico

[ANN] Apache Maven Checkstyle Plugin 3.1.1 Released

[Enrico Olivelli]

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

The Checkstyle Plugin generates a report regarding the code style used by
the developers. For more information about Checkstyle, see
http://checkstyle.sourceforge.net/.

This version of the plugin uses Checkstyle 8 by default, requires
Java 8 and it does not support Checkstyle 6 anymore.

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

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


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


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

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


Release Notes - Maven Checkstyle Plugin - Version 3.1.1

** Bug
* [MCHECKSTYLE-380] - Issue tracking page for
maven-checkstyle-plugin is not available
* [MCHECKSTYLE-384] - Incompatibility to Checkstyle version >=
8.24  - Upgrade to 8.28

** New Feature
* [MCHECKSTYLE-371] - Add logViolationCountToConsole property

** Improvement
* [MCHECKSTYLE-381] - Remove usage of deprecated class loading
functionality from checkstyle
* [MCHECKSTYLE-390] - Upgrade to checkstyle 8.29

** Task
* [MCHECKSTYLE-391] - Update parent to 34

** Dependency upgrade
* [MCHECKSTYLE-388] - Update internal dependencies with low impact
* [MCHECKSTYLE-389] - MCHECKSTYLE-365 introduces regression with
'rules' aggregate count section on report


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: versioning by hashes to speedup multi-module build (a'la nix package manager)

[Enrico Olivelli]

(Apologises for top posting )

This thread is about a bunch of requested features (cache and parallel
executions of mojos) that we have been discussing on dev@ mailing list.
As said in this thread the first show stopper for Maven is that we do not
have a clear definition of input and outputs for each plugin.
There are proposals but actually no one is spending actively engineering
time on these topics.

Any help is very appreciated, please join us on dev@

Best regards
Enrico



Il Dom 2 Feb 2020, 18:57 Thomas Broyer  ha scritto:

> Le dim. 2 févr. 2020 à 17:48, Anton Vodonosov  a
> écrit :
>
> > Hello.
> >
> > In order to speed up the build of a multi-module project, I'd like to
> > reuse artifacts of modules that haven't changed.
> > Manual versioning is tedious and error-prone.
> >
> > Is it possible to automatically assign versions to modules computed as a
> > hash-of( hash-of(module sources) + hashes of all dependencies)?
> >
>
> Please define modules sources?
> Hint: you can't, at least not without knowing how all plugins work. Gradle
> Enterprise tries to have such knowledge fwiw to solve this exact issue.
>
> Also, you'll probably want to include system properties (or at least Maven
> properties) and some environment information (e.g. which JDK) in the hash.
>
> In this approach, every change in code will modify such hash-based version
> > of all dependent modules automatically.
> >
> > This would be similar to Nix package manager.
> >
> > How to do that in maven?
> >
>
> As said above, you could try Gradle Enterprise. Takari had something in the
> works too a few years ago.
> …or if that's really problematic for you, then migrate to another build
> tool, such as Gradle or Bazel.
>
>
> > Best regards,
> > - Anton
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Fwd: Unexpected behavior in maven

[Enrico Olivelli]

-- Forwarded message -
Da: Enrico Olivelli 
Date: Gio 23 Gen 2020, 14:01
Subject: Re: Unexpected behavior in maven
To: Oleg Kiktev 
Cc: 


Oleg
Do you Havel this problemi in your IDE or even using Maven from the command
line?
What does dependency:tree report?


Enrico

Il Gio 23 Gen 2020, 10:31 Oleg Kiktev  ha scritto:

> Hi Maven Team,
>
> I faced with some strange behavior in maven recently.
> Here are details:
> I have a project with one scope test dependency (D1). Then I added new
> dependency D2 which has the same dependency D1. But for D2 the D1 is needed
> for runtime. Currently maven rejects D1 from D2 and my application does not
> work because required library D2 has been rejected.
>
> On my point of view this is stupid. The test scope of my project
> overwrites compile scope of third-party. And I'm not able to even run
> application in my IDE (Tried Eclipse and intellij).
>
> So could someone explain is it expected behavior or a bug?
>
> Regards,
> Oleg
>

Re: Question about Apache Parent Pom and source-release-assembly

[Enrico Olivelli]

Il sab 18 gen 2020, 22:27 Hervé BOUTEMY  ha scritto:

> Le samedi 18 janvier 2020, 14:24:29 CET Enrico Olivelli a écrit :
> > Hervé
> > I don't know why but my change works as expected.
> >
> > I really can't change the artifact id of the main parent pom because it
> > will be a nuisance for consumers.
> >
> > So you think that my patch is working only because of a bug in Maven
> core?
> more than that, I'm sure it's the case and that MNG-5001 will fix the bug,
> then
> your build will fail
>
> >
> > I shouldn't be able to override finalName.
> yes, it's tempting to do so, but if this parameter is not documented, it's
> because it's read-only then is not expected to be overridden. And given
> you're
> not the first one I saw to override it, MNG-5001 is absolutely required
>

Just for info my IDE suggested that there is such parameter.
Maybe the IDE should not suggest to override read-only parameters

Not a big deal, if we enforce 'read only' then the build will fail


> >
> >  I could change finalName root property without changing the artifactid
> no, you can't, and this is for a reason: in the repository, every attached
> sub-artifact is expected to have the same artifactId, then have a filename
> starting with the artifactId. This is key to our convention, sorry.
>
> Looking at Zookeeper distribution [1], what about renaming
> zookeeper-assembly
> module to apache-zookeeper and publish its content to central? It would be
> the
> equivalent to our apache-maven module.
> And given you need a specific assembly for the bin distribution, this
> would not
> be an issue, isn't it?
>

I will try, thank you for this good suggestion


Enrico

>
> Regards,
>
> Hervé
>
> [1] https://www-us.apache.org/dist/zookeeper/current/
>
> >
> > Thanks for your help
> > Enrico
> >
> > Il sab 18 gen 2020, 12:46 Hervé BOUTEMY  ha
> scritto:
> > > WARNING: finalName is read-only
> > > There is a bug in Maven 3 that does not check, but this will be fixed
> in
> > > Maven
> > > 3.7.0 (see MNG-5001 [1]), then you'll get soon the expected failure
> > >
> > > Either you should rename parent artifact to zookeeper, then you'll
> have to
> > > rename the current zookeeper to zookeeper-server for example.
> > > Either you're stuck with your specific assembly.
> > >
> > > In Maven itself, we have 2 cases:
> > > - Maven core, that has a specific assembly in apache-maven module where
> > > source-
> > > release is published [2] with a specific src+bin and zip+tar.gz output
> > > - every other multi-module project (surefire, jxr, doxia, archetype,
> ...)
> > > use
> > > the standard Apache source-release assembly descriptor, with root
> reactor
> > > POM
> > > artifactId being the name of the project (without any "parent")
> > >
> > > Perhaps renaming your parent artifact to "apache-zookeeper" may be a
> > > solution,
> > > to avoid renaming the current zookeeper artifact, and getting a apache-
> > > zookeeper-*.tar.gz output
> > >
> > > HTH
> > >
> > > Hervé
> > >
> > > [1] https://issues.apache.org/jira/browse/MNG-5001
> > >
> > > [2]
> > >
> https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.6.3/
> > >
> > > Le vendredi 17 janvier 2020, 17:37:52 CET Enrico Olivelli a écrit :
> > > > Self answer, I have cloned the execution but I have reused the common
> > > > assembly descriptor. It is a trade off but it works
> > >
> > >
> https://github.com/apache/zookeeper/commit/9053f7c431bb17ed79c2be129b6ba4b
> > > a1>
> > > > 8d15ab1
> > > >
> > > > Enrico
> > > >
> > > > Il giorno ven 17 gen 2020 alle ore 08:50 Enrico Olivelli <
> > > >
> > > > eolive...@gmail.com> ha scritto:
> > > > > Hi,
> > > > > In Apache ZooKeeper community we want to switch to using the
> "source
> > > > > package" generated by the apache parent pom with the execution of
> > > > > "source-release-assembly".
> > > > >
> https://github.com/apache/maven-apache-parent/blob/master/pom.xml#L381
> > > > >
> > > > > What is the *best* way to achieve these goals (without redefining
> the
> > >
> > > full
> > >
> > > > > executi

Re: Question about Apache Parent Pom and source-release-assembly

[Enrico Olivelli]

Hervé
I don't know why but my change works as expected.

I really can't change the artifact id of the main parent pom because it
will be a nuisance for consumers.

So you think that my patch is working only because of a bug in Maven core?

I shouldn't be able to override finalName.

 I could change finalName root property without changing the artifactid

Thanks for your help
Enrico

Il sab 18 gen 2020, 12:46 Hervé BOUTEMY  ha scritto:

> WARNING: finalName is read-only
> There is a bug in Maven 3 that does not check, but this will be fixed in
> Maven
> 3.7.0 (see MNG-5001 [1]), then you'll get soon the expected failure
>
> Either you should rename parent artifact to zookeeper, then you'll have to
> rename the current zookeeper to zookeeper-server for example.
> Either you're stuck with your specific assembly.
>
> In Maven itself, we have 2 cases:
> - Maven core, that has a specific assembly in apache-maven module where
> source-
> release is published [2] with a specific src+bin and zip+tar.gz output
> - every other multi-module project (surefire, jxr, doxia, archetype, ...)
> use
> the standard Apache source-release assembly descriptor, with root reactor
> POM
> artifactId being the name of the project (without any "parent")
>
> Perhaps renaming your parent artifact to "apache-zookeeper" may be a
> solution,
> to avoid renaming the current zookeeper artifact, and getting a apache-
> zookeeper-*.tar.gz output
>
> HTH
>
> Hervé
>
> [1] https://issues.apache.org/jira/browse/MNG-5001
>
> [2]
> https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.6.3/
>
> Le vendredi 17 janvier 2020, 17:37:52 CET Enrico Olivelli a écrit :
> > Self answer, I have cloned the execution but I have reused the common
> > assembly descriptor. It is a trade off but it works
> >
> >
> https://github.com/apache/zookeeper/commit/9053f7c431bb17ed79c2be129b6ba4ba1
> > 8d15ab1
> >
> > Enrico
> >
> > Il giorno ven 17 gen 2020 alle ore 08:50 Enrico Olivelli <
> >
> > eolive...@gmail.com> ha scritto:
> > > Hi,
> > > In Apache ZooKeeper community we want to switch to using the "source
> > > package" generated by the apache parent pom with the execution of
> > > "source-release-assembly".
> > > https://github.com/apache/maven-apache-parent/blob/master/pom.xml#L381
> > >
> > > What is the *best* way to achieve these goals (without redefining the
> full
> > > execution):
> > > 1) create a tar.gz file ?
> > > 2) use a custom file name
> > >
> > >
> > > 1) We have historically always distributed the sources in tar.gz
> format,
> > > the ZIP file works well but if we keep the usual format we will give
> less
> > > troubles to downstream consumers
> > >
> > > 2) Such execution is bound to the root project, that has "parent" as
> > > artifact id, so the ZIP file name is like parent-3.6.0-sources.zip
> > > I would like it to be apache-zookeeper-3.6.0.tar.gz
> > >
> > > Any comment/help is appreciated.
> > >
> > > My personal solution would be to create a separate execution with a
> copy
> > > and paste of the Apache Parent POM, but if will it is not ideal
> > >
> > > Cheers
> > > Enrico
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Question about Apache Parent Pom and source-release-assembly

[Enrico Olivelli]

Self answer, I have cloned the execution but I have reused the common
assembly descriptor. It is a trade off but it works

https://github.com/apache/zookeeper/commit/9053f7c431bb17ed79c2be129b6ba4ba18d15ab1

Enrico

Il giorno ven 17 gen 2020 alle ore 08:50 Enrico Olivelli <
eolive...@gmail.com> ha scritto:

> Hi,
> In Apache ZooKeeper community we want to switch to using the "source
> package" generated by the apache parent pom with the execution of
> "source-release-assembly".
> https://github.com/apache/maven-apache-parent/blob/master/pom.xml#L381
>
> What is the *best* way to achieve these goals (without redefining the full
> execution):
> 1) create a tar.gz file ?
> 2) use a custom file name
>
>
> 1) We have historically always distributed the sources in tar.gz format,
> the ZIP file works well but if we keep the usual format we will give less
> troubles to downstream consumers
>
> 2) Such execution is bound to the root project, that has "parent" as
> artifact id, so the ZIP file name is like parent-3.6.0-sources.zip
> I would like it to be apache-zookeeper-3.6.0.tar.gz
>
> Any comment/help is appreciated.
>
> My personal solution would be to create a separate execution with a copy
> and paste of the Apache Parent POM, but if will it is not ideal
>
> Cheers
> Enrico
>

Question about Apache Parent Pom and source-release-assembly

[Enrico Olivelli]

Hi,
In Apache ZooKeeper community we want to switch to using the "source
package" generated by the apache parent pom with the execution of
"source-release-assembly".
https://github.com/apache/maven-apache-parent/blob/master/pom.xml#L381

What is the *best* way to achieve these goals (without redefining the full
execution):
1) create a tar.gz file ?
2) use a custom file name


1) We have historically always distributed the sources in tar.gz format,
the ZIP file works well but if we keep the usual format we will give less
troubles to downstream consumers

2) Such execution is bound to the root project, that has "parent" as
artifact id, so the ZIP file name is like parent-3.6.0-sources.zip
I would like it to be apache-zookeeper-3.6.0.tar.gz

Any comment/help is appreciated.

My personal solution would be to create a separate execution with a copy
and paste of the Apache Parent POM, but if will it is not ideal

Cheers
Enrico

Re: Publishing Maven site as an docker image

[Enrico Olivelli]

Hi
What's the purpose of this new image?
Can you explain better please?

There is a mojo, site:run to run the website, so it should be easy to do
what you want.

Anyway the site is static so you can copy it to any web server

You can also deploy automatically the site via sftp or any provider
supported by Maven Wagon

Enrico

Il lun 23 dic 2019, 10:00 Nick Stolwijk  ha
scritto:

> Hi folks,
>
> Has anyone tried to publish the site generated by Maven as a docker image?
> Are there examples of such a setup?
>
> 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
>

Re: is there a maven plugin to identify ancient pom dependencies

[Enrico Olivelli]

Something like this:
https://www.mojohaus.org/versions-maven-plugin/display-dependency-updates-mojo.html

Hope that helps
Enrico

Il sab 21 dic 2019, 18:31 mark  ha scritto:

> On 2019-12-20 13:39, Marlow, Andrew wrote:
> >
> > Hello everyone,
> >
> > I am using the owasp maven dependency plugin to tell me when I am
> > using components that have CVEs. That’s great. I was wondering if
> > there was something similar that would tell me when I am using very
> > old components (where the judgement about what is old is configurable,
> > e.g number of years, months etc).
> >
>
> never seen one, it would be hard without querying the source repository
> for the release tag/branch for the moment the release was cut (which is
> problematic in case a minimal release pom is in use. The current pom
> does not have this/a timestamp for this and you cannot use the file date.
>
> I guess you could look at the date of the (class) files inside the
> artifact (jar) to determine build/release date, not sure how that would
> work out with shaded dependencies or provided manifest files
>
>
> -M
>
> > *Andrew Marlow*
> >
> > Software Engineer Specialist, Apex
> >
> > 38^th Floor, 25 Canada Square,
> >
> > Canary Wharf, London E14 5LQ
> >
> > *T*:  020-8081-2367 / 07966-451-521
> > *E*: andrew.mar...@fisglobal.com 
> >
> > *FIS | Advancing the way the world pays, banks and invests™ *
> >
> > cid:image004.png@01D542DF.1DA72090
> > cid:image005.png@01D542DF.1DA72090
> > cid:image008.png@01D542DF.1DA72090
> > 
> >
> > The information contained in this message is proprietary and/or
> > confidential jadajadajada...
>
>

Re: maven plugin to check open source licenses

[Enrico Olivelli]

You can configure a list of allowed / banned licenses

Enrico

Il sab 21 dic 2019, 07:52 Marlow, Andrew
 ha scritto:

> Hello everyone,
>
>
>
> I have just started looking at the plugin license-maven-plugin
> (org.codehaus.mojo) and have a question: is there a similar plugin to this
> that would check to see if any GNU-like licenses are in use?
>
>
>
> *Andrew Marlow*
>
> Software Engineer Specialist, Apex
>
> 38th Floor, 25 Canada Square,
>
> Canary Wharf, London E14 5LQ
>
> *T*:  020-8081-2367 / 07966-451-521
> *E*: andrew.mar...@fisglobal.com
>
>
>
> *FIS | Advancing the way the world pays, banks and invests™  *
>
> [image: cid:image004.png@01D542DF.1DA72090]
> [image:
> cid:image005.png@01D542DF.1DA72090] [image:
> cid:image008.png@01D542DF.1DA72090] 
>
>
> The information contained in this message is proprietary and/or
> confidential. If you are not the intended recipient, please: (i) delete the
> message and all copies; (ii) do not disclose, distribute or use the message
> in any manner; and (iii) notify the sender immediately. In addition, please
> be aware that any message addressed to our domain is subject to archiving
> and review by persons other than the intended recipient. FIS is a trading
> name of the following companies: Advanced Portfolio Technologies Ltd (No:
> 6312142) | Clear2Pay Limited (No: 5792457) | Decalog (UK) Limited (No:
> 2567370) | FIS Apex (International) Limited (No: 260) | FIS Apex (UK)
> Limited (No. 3573008) | FIS Consulting Services (UK) Limited (No: 2486794)
> | FIS Derivatives Utility Services (UK) Limited (No: 9398140) | FIS Energy
> Solutions Limited (No: 1889028) | FIS Global Execution Services Limited
> (No. 3127109) | FIS Global Trading (UK) Limited (No: 2523114) | FIS
> Investment Systems (UK) Limited (No: 1366010) | FIS Sherwood Systems Group
> Limited (No: 982833) | FIS Systems Limited (No: 1937159) | FIS Treasury
> Systems (Europe) Limited (No: 2624209) | FIS Treasury Systems (UK) Limited
> (No: 2893376) | GL Settle Limited (No: 2396127) | Integrity Treasury
> Solutions Europe Limited (No: 3289271) | Monis Software Limited (No:
> 2333925) | Reech Capital Limited (No: 3649490) | Solutions Plus Consulting
> Services Limited (No: 3839487) | Valuelink Information Services Limited
> (No: 3827424) all registered in England & Wales with their registered
> office at 25 Canada Square, London E14 5LQ | FIS Global Execution Services
> Limited is authorised and regulated by the Financial Conduct Authority |
> Certegy Card Services Limited (No: 3517639) | Certegy France Limited (No:
> 2557650) | eFunds International Limited (No: 1930117) | Fidelity
> Information Services Limited (No: 2225203) | FIS Payments (UK) Limited (No:
> 4215488) | Metavante Technologies Limited (No: 2659326) all registered in
> England & Wales with their registered office at 1st Floor Tricorn House,
> 51-53 Hagley Road, Edgbaston, Birmingham, West Midlands, B16 8TU, United
> Kingdom | FIS Payments (UK) Limited is authorised and regulated by the
> Financial Conduct Authority; some services are covered by the Financial
> Ombudsman Service (in the UK). Clear2Pay Limited, Registered in Scotland
> (No SC157659), Registered Office: Clear2Pay House, Pitreavie Court,
> Pitreavie Business Park Queensferry Rd, Dunfermline, Fife, SS, KY11 8UU,
> Scotland | FIS eProcess Intelligence LLC (UK Branch), UK Establishment
> Registered in England & Wales (No: FC16527/Branch No. BR000355), Registered
> Branch Office: 25 Canada Square, London, E14 5LQ; FIS eProcess Intelligence
> LLC is a limited liability company formed in the USA registered on file
> with the Office of the Delaware Secretary of State, Division of
> Corporations (File No. 2032143), Head Office: 601 Riverside Avenue,
> Jacksonville Florida, FL32204, USA | FIS Investment Systems LLC, UK
> Establishment Registered in England & Wales (No: FC033836/Branch No.
> BR018923), Registered Branch Office: 25 Canada Square, London, E14 5LQ; FIS
> Investment Systems LLC is a limited liability company formed in the USA
> registered on file with the Office of the Delaware Secretary of State,
> Division of Corporations (File No. 0881255), Head Office: 377 E.
> Butterfield Road, Suite 800, Lombard, IL 60148, USA | Calls to and from the
> companies may be recorded for quality purposes. | All of the named
> companies are part of FIS (Fidelity National Information Services, Inc.).
>

Re: Overriding plugin parameters via commandline

[Enrico Olivelli]

Il ven 29 nov 2019, 23:15 Marco Herrn  ha
scritto:

> Hi,
>
> if I try to call the following maven goal:
>
>   mvn kilt:reformat -Dformat=" = \n"
>
> the parameter `format` is correctly set to the given value for the
> `reformat` goal of the `kilt-maven-plugin`.
>
> However, if I specify this parameter also in the pom.xml:
>
>   
> de.poiu.kilt
> kilt-maven-plugin
> 0.4.0-SNAPSHOT
> 
>   key\t: value\n
> 
>   
>
> the value given in the pom.xml always takes precedence. The cmdline
> parameter is ignored in that case.
>
> What do I have to do to be able to override the values in the
> configuration? Do I need to specify the parameter in the ReformatMojo of
> the kilt-maven-plugin differently? It is currently specified as:
>
>   @Parameter(property="format", defaultValue = " = \\n",
> required = true)
>   private String format;
>
> Do I need to specify something differently to override a configation
> setting in the pom.xml via commandline flags?
>
> In case you are curios, I am talking about that plugin:
> https://github.com/hupfdule/kilt/tree/master/kilt-maven-plugin






Hi,
This is expected, you have to declare your own property in the 
section of your pom.xml with value equals to your 'default' value.
Then you configure the plugin to use your new properly
${myformat}

Cheers
Enrico

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

Re: Hooks on mvn release:prepare

[Enrico Olivelli]

Hello,
this is my final working example, it is using preparationGoals and
completionGoals in order to alter files and the commit them.

https://github.com/eolivelli/testreleaseplugin

@Stephen Connolly  I confirm you that a
'git commit' is really needed, "git add" is not enough, but using the Maven
SCM Plugin it very easy.

I feel that the Maven Release Plugin has already got all that is needed.

I will apply this practice to some real project then I will update the
Maven Release Plugin documentation with this example

Thank you so much !
Enrico

Il giorno sab 23 nov 2019 alle ore 17:32 Stephen Connolly <
stephen.alan.conno...@gmail.com> ha scritto:

> On Sat 23 Nov 2019 at 14:53, Enrico Olivelli  wrote:
>
> > Stephen
> >
> > Il sab 2 nov 2019, 11:00 Stephen Connolly <
> stephen.alan.conno...@gmail.com
> > >
> > ha scritto:
> >
> > > On Thu 3 Oct 2019 at 16:13, Enrico Olivelli 
> wrote:
> > >
> > > > Hello,
> > > > I am going to propose a new release procedure in Apache ZooKeeper
> > project
> > > > in the direction of using the Maven Release Plugin.
> > > > Usually with the Maven Release Plugin you are performing to tasks:
> > > >
> > > > mvn release:prepare -> change version + create tag
> > > > mvn release:perform  -> create final artifacts and deploy
> > > >
> > > > in the specific case of Apache ZooKeeper we have a C-client that
> > > contains
> > > > C sources under a mavenized project, so in src/c or something like
> > that,
> > > > not so important.
> > > >
> > > > The important fact is that I have the 'version' in pom.xml and in
> the C
> > > > client (make/configure based build).
> > > > I would like to introduce an hook that during "release:prepare" while
> > > > changing the version in all of the pom.xml files it changes the
> version
> > > > inside the C project.
> > > > I just need a way to invoke a bash script with a 'sed' command that
> has
> > > the
> > > > new VERSION variable in a shell environment.
> > > > I can also write some java code or whatever else
> > > >
> > > > But I need some "hook" during release:prepare.
> > > >
> > > > I can't find any documentation about this feature other then
> > > > "prepationGoals" but it is not documented and there is no good
> example
> > on
> > > > the Internet
> > > >
> > > >
> > >
> >
> https://maven.apache.org/maven-release/maven-release-plugin/examples/run-goals-before-commit.html
> > > >
> > > > Any idea or working example ?
> > >
> > >
> > > So if you are using GIT as your SCM, as long as you do `git add
> > > name-of-file` after changing the file inside preparationGoals then it
> > will
> > > get committed with the pom.xml changes.
> > >
> >
> >
> > This approach actually works
> > This is a sample project
> > https://gitbub.com/eolivelli/testreleaseplugin
> >
> > The only remaining problem is the 'preparationGoals' come into play only
> > while preparing the release and not while bumping the version to the new
> > one
>
>
> I believe I added completionGoals for that purpose :-D
>
>
> >
> >
> > Thank you
> >
> > Enrico
> >
> >
> > > A bit hacky, but works. My only use of it is closed source so cannot
> > share
> > >
> > >
> > > >
> > > > Thanks
> > > > Enrico
> > > >
> > > --
> > > Sent from my phone
> > >
> >
> --
> Sent from my phone
>

Re: Hooks on mvn release:prepare

[Enrico Olivelli]

Stephen

Il sab 2 nov 2019, 11:00 Stephen Connolly 
ha scritto:

> On Thu 3 Oct 2019 at 16:13, Enrico Olivelli  wrote:
>
> > Hello,
> > I am going to propose a new release procedure in Apache ZooKeeper project
> > in the direction of using the Maven Release Plugin.
> > Usually with the Maven Release Plugin you are performing to tasks:
> >
> > mvn release:prepare -> change version + create tag
> > mvn release:perform  -> create final artifacts and deploy
> >
> > in the specific case of Apache ZooKeeper we have a C-client that
> contains
> > C sources under a mavenized project, so in src/c or something like that,
> > not so important.
> >
> > The important fact is that I have the 'version' in pom.xml and in the C
> > client (make/configure based build).
> > I would like to introduce an hook that during "release:prepare" while
> > changing the version in all of the pom.xml files it changes the version
> > inside the C project.
> > I just need a way to invoke a bash script with a 'sed' command that has
> the
> > new VERSION variable in a shell environment.
> > I can also write some java code or whatever else
> >
> > But I need some "hook" during release:prepare.
> >
> > I can't find any documentation about this feature other then
> > "prepationGoals" but it is not documented and there is no good example on
> > the Internet
> >
> >
> https://maven.apache.org/maven-release/maven-release-plugin/examples/run-goals-before-commit.html
> >
> > Any idea or working example ?
>
>
> So if you are using GIT as your SCM, as long as you do `git add
> name-of-file` after changing the file inside preparationGoals then it will
> get committed with the pom.xml changes.
>


This approach actually works
This is a sample project
https://gitbub.com/eolivelli/testreleaseplugin

The only remaining problem is the 'preparationGoals' come into play only
while preparing the release and not while bumping the version to the next
one


Thank you

Enrico


> A bit hacky, but works. My only use of it is closed source so cannot share
>
>
> >
> > Thanks
> > Enrico
> >
> --
> Sent from my phone
>

Re: Hooks on mvn release:prepare

[Enrico Olivelli]

Thank you Stephen,
I will try and check which of the two ideas works better

Enrico

Il giorno sab 2 nov 2019 alle ore 11:03 Stephen Connolly <
stephen.alan.conno...@gmail.com> ha scritto:

> Less hacky.
>
> Could you use an #include directory search order that puts a
> target/generated-sources/c first.
>
> If you build without Maven, that dir will be empty and version.h will be
> found from the regular source sir and say “a snapshot”
>
> If you build with Maven, Maven will populate the generated source with a
> concrete version.h that gets found first and presto!
>
> On Sat 2 Nov 2019 at 09:59, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> >
> >
> > On Thu 3 Oct 2019 at 16:13, Enrico Olivelli  wrote:
> >
> >> Hello,
> >> I am going to propose a new release procedure in Apache ZooKeeper
> project
> >> in the direction of using the Maven Release Plugin.
> >> Usually with the Maven Release Plugin you are performing to tasks:
> >>
> >> mvn release:prepare -> change version + create tag
> >> mvn release:perform  -> create final artifacts and deploy
> >>
> >> in the specific case of Apache ZooKeeper we have a C-client that
> contains
> >> C sources under a mavenized project, so in src/c or something like that,
> >> not so important.
> >>
> >> The important fact is that I have the 'version' in pom.xml and in the C
> >> client (make/configure based build).
> >> I would like to introduce an hook that during "release:prepare" while
> >> changing the version in all of the pom.xml files it changes the version
> >> inside the C project.
> >> I just need a way to invoke a bash script with a 'sed' command that has
> >> the
> >> new VERSION variable in a shell environment.
> >> I can also write some java code or whatever else
> >>
> >> But I need some "hook" during release:prepare.
> >>
> >> I can't find any documentation about this feature other then
> >> "prepationGoals" but it is not documented and there is no good example
> on
> >> the Internet
> >>
> >>
> https://maven.apache.org/maven-release/maven-release-plugin/examples/run-goals-before-commit.html
> >>
> >> Any idea or working example ?
> >
> >
> > So if you are using GIT as your SCM, as long as you do `git add
> > name-of-file` after changing the file inside preparationGoals then it
> will
> > get committed with the pom.xml changes.
> >
> > A bit hacky, but works. My only use of it is closed source so cannot
> share
> >
> >
> >>
> >> Thanks
> >> Enrico
> >
> >
> >> --
> > Sent from my phone
> >
> --
> Sent from my phone
>

Re: Using Maven outside of L/M/WAMP environment

[Enrico Olivelli]

Hello,

Il mer 30 ott 2019, 22:27 New_Tech  ha scritto:

> I am a new programmer and have started the “on paper” design of my first
> project.  While reading a tutorial on linking a Java program to a MySQL DB,
> I was introduced to Maven as part of the conduit between Java and the DB. I
> have a couple of questions about this.
>
> 1. Is Maven an absolute requirement to allow communication between those
> two
> entities?
>

Usually you use a JDBC driver to connect to a database.
Maven is a build/project management tool

>
> 2. Can Maven be used outside of a *AMP environment? I may be
> misinterpreting
> the use of Maven in this way but with it being a part of the Apache
> Project,
> I’m assuming a *AMP server is required to create a system with Maven as a
> part of it.
>
Can you share a link to the doc you are reading about AMP?

>

> If this is the wrong place for this post please direct me to the correct
> area. Any helpful resources to understand Maven’s purpose and necessity are
> much appreciated.
>

You can start from the website
https://maven.apache.org



Enrico

>
> Thank you
>
>
>
> --
> 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
>
>

Spell check plugin for Maven

[Enrico Olivelli]

Hi all,
do you know any effective plugin for spell check at least for HTML files ?

The best would be a plugin for textlint (
https://github.com/textlint/textlint)

I have been googling a bit but I can find anything really useful

Cheers
Enrico

Re: Take threaddump on hung surefire tests

[Enrico Olivelli]

Il ven 4 ott 2019, 16:30 Debraj Manna  ha scritto:

> Enrico
>
> If I get the approach correctly then all my junit4 tests should have
> timeout specified (either via @Test or via @Rule) then only I can use the
> listener. But the problem is we are having more than 2000 tests and
> specifying a timeout in each of the tests/classes is cumbersome.
>


We don't have timeouts Rules in Bookkeeper. So there is something wrong
with your analysis.

I have other variations of that listener.
I don't have time this weekend to check.
I will check as soon as I can

Enrico

>
> Correct me if I have misunderstood anything.
>
>
>
> On Fri, Oct 4, 2019 at 3:18 PM Debraj Manna 
> wrote:
>
> > Yeah sure ... thanks.
> >
> > On Thu, Oct 3, 2019 at 7:50 PM Tibor Digana 
> > wrote:
> >
> >> Hi Debraj,
> >>
> >> There is nice technical idea from Enrico.
> >> If you apply it and you are convinced that it would work properly for
> all
> >> the Java community, feel free to show it and we can discuss it on how we
> >> would adopt your solution in Surefire project.
> >>
> >> Cheers
> >> Tibor17
> >>
> >> On Thu, Oct 3, 2019 at 2:49 PM Debraj Manna 
> >> wrote:
> >>
> >> > Sometimes I have maven surefire tests that get hung, due to either
> >> races or
> >> > deadlocks.
> >> >
> >> > When this happens I have to discover what slave is being used, and
> then
> >> I
> >> > have to log on that slave, sudo to jenkins account and execute either
> >> > jstack or kill -3
> >> >
> >> > I am looking for a simple solution like doing jstack / kill -3 when
> >> someone
> >> > presses abort button on the jenkins.
> >> >
> >> > Can someone suggest how can I automate this or some better way of
> >> handling
> >> > this?
> >> >
> >>
> >
>

Re: Hooks on mvn release:prepare

[Enrico Olivelli]

Il gio 3 ott 2019, 17:53 Anthony Whitford  ha scritto:

> Wouldn’t it make more sense to hook into the generate-sources or
> process-sources phase?
>

In this case I can't because C sources must be buildable even without maven


Enrico


> I would also think that the need to do that token replacement to set the
> version applies for any build — not just the release process.
>
>
> > On Oct 3, 2019, at 8:13 AM, Enrico Olivelli  wrote:
> >
> > Hello,
> > I am going to propose a new release procedure in Apache ZooKeeper project
> > in the direction of using the Maven Release Plugin.
> > Usually with the Maven Release Plugin you are performing to tasks:
> >
> > mvn release:prepare -> change version + create tag
> > mvn release:perform  -> create final artifacts and deploy
> >
> > in the specific case of Apache ZooKeeper we have a C-client that
> contains
> > C sources under a mavenized project, so in src/c or something like that,
> > not so important.
> >
> > The important fact is that I have the 'version' in pom.xml and in the C
> > client (make/configure based build).
> > I would like to introduce an hook that during "release:prepare" while
> > changing the version in all of the pom.xml files it changes the version
> > inside the C project.
> > I just need a way to invoke a bash script with a 'sed' command that has
> the
> > new VERSION variable in a shell environment.
> > I can also write some java code or whatever else
> >
> > But I need some "hook" during release:prepare.
> >
> > I can't find any documentation about this feature other then
> > "prepationGoals" but it is not documented and there is no good example on
> > the Internet
> >
> https://maven.apache.org/maven-release/maven-release-plugin/examples/run-goals-before-commit.html
> >
> > Any idea or working example ?
> >
> > Thanks
> > Enrico
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Hooks on mvn release:prepare

[Enrico Olivelli]

Hello,
I am going to propose a new release procedure in Apache ZooKeeper project
in the direction of using the Maven Release Plugin.
Usually with the Maven Release Plugin you are performing to tasks:

mvn release:prepare -> change version + create tag
mvn release:perform  -> create final artifacts and deploy

in the specific case of Apache ZooKeeper we have a C-client that  contains
C sources under a mavenized project, so in src/c or something like that,
not so important.

The important fact is that I have the 'version' in pom.xml and in the C
client (make/configure based build).
I would like to introduce an hook that during "release:prepare" while
changing the version in all of the pom.xml files it changes the version
inside the C project.
I just need a way to invoke a bash script with a 'sed' command that has the
new VERSION variable in a shell environment.
I can also write some java code or whatever else

But I need some "hook" during release:prepare.

I can't find any documentation about this feature other then
"prepationGoals" but it is not documented and there is no good example on
the Internet
https://maven.apache.org/maven-release/maven-release-plugin/examples/run-goals-before-commit.html

Any idea or working example ?

Thanks
Enrico

Re: Take threaddump on hung surefire tests

[Enrico Olivelli]

Hi,
you can create a simple Listener like this one:
https://github.com/apache/bookkeeper/blob/master/bookkeeper-common/src/test/java/org/apache/bookkeeper/common/testing/util/TimedOutTestsListener.java

check on the pom.xml file about how to enable it:
https://github.com/apache/bookkeeper/blob/2f996dcf0159f945f7ec97ce7402e5d293009444/bookkeeper-server/pom.xml#L212

hope that helps

Enrico

Il giorno gio 3 ott 2019 alle ore 14:49 Debraj Manna <
subharaj.ma...@gmail.com> ha scritto:

> Sometimes I have maven surefire tests that get hung, due to either races or
> deadlocks.
>
> When this happens I have to discover what slave is being used, and then I
> have to log on that slave, sudo to jenkins account and execute either
> jstack or kill -3
>
> I am looking for a simple solution like doing jstack / kill -3 when someone
> presses abort button on the jenkins.
>
> Can someone suggest how can I automate this or some better way of handling
> this?
>

Re: Failures building Eclipse 4.13 with maven-3.6.2

[Enrico Olivelli]

Any volunteer to work on a fix?

Enrico

Il sab 14 set 2019, 10:08 Jonathan Chen  ha scritto:

> Hi,
>
> I didn't find a matching issue, so I raised MNG-6765 so that it can be
> tracked.
> https://issues.apache.org/jira/browse/MNG-6765
>
> Cheers.
> --
> Jonathan Chen 
>
> On Sat, 14 Sep 2019 at 19:47, Jonathan Chen  wrote:
> >
> > Hi,
> >
> > Thanks for that. Is there a JIRA reference for this bug?
> >
> > Cheers.
> > --
> > Jonathan Chen 
> >
> > On Sat, 14 Sep 2019 at 17:39, Jeff MAURY  wrote:
> > >
> > > This is a know case between tycho pomless and maven 3.6.2
> > >
> > > Le sam. 14 sept. 2019 à 05:26, Jonathan Chen  a
> écrit :
> > >
> > > > Hi,
> > > >
> > > > I'm currently attempting to build Eclipse 4.13 from source using
> > > > maven-3.6.2, and I'm seeing these current failures:
> > > > [INFO] Scanning for projects...
> > > > [ERROR] [ERROR] Some problems were encountered while processing the
> POMs:
> > > > [FATAL] Non-readable POM
> > > >
> > > >
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation10/.polyglot.build.properties:
> > > > input contained no data @
> > > > [FATAL] Non-readable POM
> > > >
> > > >
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation11/.polyglot.build.properties:
> > > > input contained no data @
> > > > [FATAL] Non-readable POM
> > > >
> > > >
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.feature/.polyglot.build.properties:
> > > > input contained no data @
> > > > [FATAL] Non-readable POM
> > > >
> > > >
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se12/.polyglot.build.properties:
> > > > input contained no data @
> > > > [FATAL] Non-readable POM
> > > >
> > > >
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se13/.polyglot.build.properties:
> > > > input contained no data @
> > > > [FATAL] Non-readable POM
> > > >
> > > >
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se14/.polyglot.build.properties:
> > > > input contained no data @
> > > > [FATAL] Non-readable POM
> > > >
> > > >
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se15/.polyglot.build.properties:
> > > > input contained no data @
> > > > [FATAL] Non-readable POM
> > > >
> > > >
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase16/.polyglot.build.properties:
> > > > input contained no data @
> > > > [FATAL] Non-readable POM
> > > >
> > > >
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase17/.polyglot.build.properties:
> > > > input contained no data @
> > > > ...
> > > >
> > > > It appears that the pom-less builds are failing due to a missing
> > > > .polyglot.build.properties. These are transient files that are
> removed
> > > > once the compiling JVM exits. Something in the 3.6.2 lifecycle has
> > > > changed such that the files are not staying long enough to be
> > > > available for dependency-resolution.
> > > >
> > > > If I downgrade to maven-3.6.1 or maven-3.6.0, these errors do not
> arise.
> > > >
> > > > Cheers.
> > > > --
> > > > Jonathan Chen 
> > > >
> > > > -
> > > > 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: Same snapshot deploy number for entire build - possible

[Enrico Olivelli]

Dan,
Are you running a single 'mvn deploy' or do you have multiple runs?
I have never seen weird behaviours in multi module projects

Cheers
Enrico

Il ven 13 set 2019, 08:19 Dan Tran  ha scritto:

> Hello, Maven dev
>
> any suggestion/thoughts on this issue are very much appreciated
>
> Regards
>
> -D
>
> On Wed, Sep 11, 2019 at 7:06 PM Dan Tran  wrote:
>
> > Hello Maven Users and Development Team
> >
> > Currently, artifact deployed as snapshot at Maven repository has the
> > following format
> >
> >  artifactId-version-timestamp-NN
> >
> > where NN auto-incremented at each maven module and the number varies
> >
> > Is there a way to use same snapshot NN for the entire multi-module maven
> > build?
> >
> > If I have to implement a solution, would it be as an extension or I have
> > to tinker with maven-deploy-plugin?
> >
> > Very appreciated any advice
> >
> > -D
> >
> >
> >
> >
> >
>

[ANNOUNCE] Apache Maven 3.6.2 released

[Enrico Olivelli]

The Apache Maven team is proud to announce Apache Maven version
3.6.2.

Maven is a software project management and comprehension tool. Based on the
concept of a project object model (POM), Maven can manage a project’s
build, reporting, and documentation from a central place.

Highlights:

- This release focuses mostly performance improvements, better memory
footprint, and less CPU usage.

- We are continuing to convert Maven Core to use JSR 330 annotations
instead of Plexus (still not finished, see MNG-5577).

- New support for ‘release’ qualifier (see MNG-6655).

- The toolchain.xml file supports environment variables (see MNG-6665).


For Apache Maven release details and downloads, visit:

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


Maven 3.6.2 Release Notes are at:

https://maven.apache.org/docs/3.6.2/release-notes.html


We would like to thank the contributors that made the release possible.

Regards,

The Apache Maven Team

Re: Found Issues - Release Apache Maven Version 3.6.2

[Enrico Olivelli]

It may be due to any change regarding jsr 330 like
https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-6686


I think it is an issue for Idea and not for us.
It would be good to have some developer from Jetbrains on this list


Enrico

Il mer 28 ago 2019, 22:23 Tibor Digana  ha scritto:

> I do not have NPE in the log.
> Guice is certainly not CDI. Moving Guice to CDI must be painful.
> One reason why PathTranslator could not be found is that there are several
> bean instances of the same interface.
> Second problem might go with the Guice/CDI.
> See this inheritance:
>
> @Named
> @Singleton
> public class DefaultPathTranslator
> implements PathTranslator
> {
>
> public interface PathTranslator
> {
>
>
>
> On Wed, Aug 28, 2019 at 10:04 PM Filipe Sousa  wrote:
>
>> Hi,
>>
>> Not sure if it’s the same bug I commented in
>> https://issues.apache.org/jira/browse/MNG-6638?focusedCommentId=16852351=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16852351
>>
>> I reported to Jetbrains https://youtrack.jetbrains.com/issue/IDEA-215315
>>  and is supposed to be
>> fixed in 2019.3
>>
>> > On 28 Aug 2019, at 20:43, Tibor Digana  wrote:
>> >
>> > I used Maven 3.6.2 in the IntelliJ IDEA 2019.2.1 and I found these
>> errors
>> > in the log file:
>> > ~/.IntelliJIdea2019.2/system/log/idea.log
>> >
>> > 2019-08-28 21:31:32,072 [255937677]  ERROR -
>> #org.jetbrains.idea.maven
>> > - com.google.inject.CreationException: Unable to create injector, see
>> the
>> > following errors:
>> >
>> > 1) No implementation for org.apache.maven.model.path.PathTranslator was
>> > bound.
>> >  while locating org.apache.maven.model.path.PathTranslator
>> >for field at
>> >
>> org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.pathTranslator(Unknown
>> > Source)
>> >  at
>> >
>> org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)
>> >
>> > 2) No implementation for org.apache.maven.model.path.UrlNormalizer was
>> > bound.
>> >  while locating org.apache.maven.model.path.UrlNormalizer
>> >for field at
>> >
>> org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.urlNormalizer(Unknown
>> > Source)
>> >  at
>> >
>> org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)
>> >
>> > 2 errors
>> > java.lang.RuntimeException: com.google.inject.CreationException: Unable
>> to
>> > create injector, see the following errors:
>> >
>> > 1) No implementation for org.apache.maven.model.path.PathTranslator was
>> > bound.
>> >  while locating org.apache.maven.model.path.PathTranslator
>> >for field at
>> >
>> org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.pathTranslator(Unknown
>> > Source)
>> >  at
>> >
>> org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)
>> >
>> > 2) No implementation for org.apache.maven.model.path.UrlNormalizer was
>> > bound.
>> >  while locating org.apache.maven.model.path.UrlNormalizer
>> >for field at
>> >
>> org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.urlNormalizer(Unknown
>> > Source)
>> >  at
>> >
>> org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)
>> >
>> > 2 errors
>> > at
>> >
>> com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:543)
>> > at
>> >
>> com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:159)
>> > at
>> >
>> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:106)
>> > at com.google.inject.Guice.createInjector(Guice.java:87)
>> > at com.google.inject.Guice.createInjector(Guice.java:69)
>> > at com.google.inject.Guice.createInjector(Guice.java:59)
>> > at
>> >
>> org.codehaus.plexus.DefaultPlexusContainer.addComponent(DefaultPlexusContainer.java:344)
>> > at
>> >
>> org.codehaus.plexus.DefaultPlexusContainer.addComponent(DefaultPlexusContainer.java:332)
>> > at
>> >
>> org.jetbrains.idea.maven.server.Maven3XServerEmbedder.customizeComponents(Maven3XServerEmbedder.java:573)
>> > at
>> >
>> org.jetbrains.idea.maven.server.Maven3XServerEmbedder.customize(Maven3XServerEmbedder.java:542)
>> > at
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>> > Method)
>> > at
>> >
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> > at
>> >
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> > at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>> > at
>> >
>> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
>> > at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
>> > at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
>> > at 

Re: [VOTE] Retire Maven OSGi

[Enrico Olivelli]

+1
Thank you Dirk for checking

Enrico

Il giorno ven 23 ago 2019 alle ore 20:48 Arnaud Héritier <
aherit...@gmail.com> ha scritto:

> +1
>
> Le ven. 23 août 2019 à 15:17, Robert Scholte  a
> écrit :
>
> > Hi,
> >
> > The Apache Maven project consist of about 90 (sub)projects. Due to the
> > small number of volunteers and the huge amount of code to maintain we're
> > missing enough space to make real progress on all these projects,
> > including our ambitious ideas for the next major version(s) of Maven
> > itself.
> > To be able to gain more focus we need to criticize the current
> > subprojects
> > and decide if it is worth maintaining.
> >
> > https://maven.apache.org/shared/maven-osgi/ describes the main purpose
> > in
> > one line: Library for Maven-OSGi integration.
> > There have been only 2 releases: 0.1.0 in July 2007 and 0.2.0 in December
> > 2007 and just one open issue by Stuart McCulloch regarding an unclosed
> jar.
> > It is unclear to me if this library is still used. The library is based
> > on
> > just 3 files: interface, default implementation and dedicated exception.
> > Either the library is complete or never used anymore. In both cases I see
> > no real reason to maintain it.
> >
> > I therefore propose that we retire the maven-osgi library.
> >
> > I don't think it makes sense to do a final release. Instead we should
> > update the documentation and freeze the codebase.
> >
> > The process for retiring a plugin is described here:
> > https://maven.apache.org/developers/retirement-plan-plugins.html
> > [https://maven.apache.org/developers/retirement-plan-plugins.html]
> >
> > The vote is open for 72 hours.
> > [ ] +1 Yes, it's about time
> > [ ] -1 No, because...
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>

[ANN] Apache Maven JDeps Plugin 3.1.2 Released

[Enrico Olivelli]

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

The JDeps Plugin uses the jdeps tool to analyze classes for internal API
calls. For more information about the standard jdeps tool,
please refer to
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool

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

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


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


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

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

Release Notes - Maven JDeps Plugin - Version 3.1.2

** Improvement
* [MJDEPS-23] - The parameter multiRelease should have a user property
so that you can set it from the command line

** Dependency upgrade
* [MJDEPS-17] - Upgrade maven-plugins parent to version 33

Enjoy,

-The Apache Maven team

Re: [VOTE] Retire Maven Downloader

[Enrico Olivelli]

+1
Enrico

Il ven 7 giu 2019, 15:37 James Gough  ha scritto:

> +1
>
> > On 7 Jun 2019, at 14:34, Tibor Digana  wrote:
> >
> > +1
> >
> > On Fri, Jun 7, 2019 at 3:32 PM Robert Scholte 
> wrote:
> >
> >> Hi,
> >>
> >> The Apache Maven project consist of about 90 (sub)projects. Due to the
> >> small number of volunteers and the huge amount of code to maintain we're
> >> missing enough space to make real progress on all these projects,
> including
> >> our ambitious ideas for the next major version(s) of Maven itself.
> >> To be able to gain more focus we need to criticize the current
> subprojects
> >> and decide if it is worth maintaining.
> >>
> >> https://maven.apache.org/shared/maven-downloader/ [
> >> https://maven.apache.org/shared/maven-downloader/] describes the main
> >> purpose in one line: Provide a super simple interface for downloading a
> >> single artifact. Well, right now the preferred library to do so is
> either
> >> maven-resolver or maven-artifact-transfer.
> >> There have been only 2 releases, the last one was in December 2006.
> >>
> >> I therefore propose that we retire the maven-downloader.
> >>
> >> I don't think it makes sense to do a final release. Instead we should
> >> update the documentation and freeze the codebase.
> >>
> >> The process for retiring a plugin is described here:
> >> https://maven.apache.org/developers/retirement-plan-plugins.html [
> >> https://maven.apache.org/developers/retirement-plan-plugins.html]
> >>
> >> The vote is open for 72 hours.
> >> [ ] +1 Yes, it's about time
> >> [ ] -1 No, because...
> >>
> >>
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Retire Maven Ant Plugin

[Enrico Olivelli]

+1 ( non binding )

Enrico

Il mar 28 mag 2019, 21:43 Tibor Digana  ha scritto:

> +1
>
> On Tue, May 28, 2019 at 8:55 PM Robert Scholte 
> wrote:
>
> > Hi,
> >
> > The Apache Maven project consist of about 100 (sub)projects. Due to the
> > small number of volunteers and the huge amount of code to maintain we're
> > missing enough space to make real progress on all these projects,
> including
> > our ambitious ideas for the next major version(s) of Maven itself.
> > To be able to gain more focus we need to criticize the current
> subprojects
> > and decide if it is worth maintaining.
> >
> > The goal of the Apache Maven Ant Plugin it to generate Ant build files
> > based on a pom.xml and was released for the last time in December 2014.
> Due
> > to the different ways that Ant and Maven work I don't think it makes
> > sense anymore to maintain a plugin to transform Maven files to Ant.
> > See https://maven.apache.org/plugins/maven-ant-plugin/ [
> > https://maven.apache.org/plugins/maven-ant-plugin/]
> >
> > To be clear, this is NOT the plugin you can use to run Ant within Maven;
> > that's the maven-antrun-plugin.
> >
> > I therefore propose that we retire the maven-ant-plugin.
> >
> > I don't think it makes sense to do a final release. Instead we should
> > update the documentation and freeze the codebase.
> >
> > The process for retiring a plugin is described here:
> > https://maven.apache.org/developers/retirement-plan-plugins.html
> >
> > The vote is open for 72 hours.
> > [ ] +1 Yes, it's about time
> > [ ] -1 No, because...
>

[ANN] Apache Maven Checkstyle Plugin 3.1.0 Released

[Enrico Olivelli]

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

The Checkstyle Plugin generates a report regarding the code style used by
the developers. For more information about Checkstyle, see
http://checkstyle.sourceforge.net/.

This version of the plugin uses Checkstyle 8 by default, requires
Java 8 and it does not support Checkstyle 6 anymore.

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

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


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


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

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

Release Notes - Maven Checkstyle Plugin - Version 3.1.0

** Bug
* [MCHECKSTYLE-323] - usage of checkstyle 7.0 (jdk8 is required)
* [MCHECKSTYLE-344] - StringIndexOutOfBoundsException in RuleUtil
* [MCHECKSTYLE-347] - StringIndexOutOfBoundsException when
checkstyle.violation.ignore set to empty value
* [MCHECKSTYLE-365] - Site Report, Rules: Violation count incorrect for
duplicate rules when one uses default severity

** Improvement
* [MCHECKSTYLE-326] - Running mvn install works first time second it
does not
* [MCHECKSTYLE-350] - Lock version of animal-sniffer-maven-plugin
* [MCHECKSTYLE-353] - Don't resolve any dependencies
* [MCHECKSTYLE-374] - Replace deprecated methods in Checkstyle
* [MCHECKSTYLE-375] - Upgrade all test XML doctypes

** Dependency upgrade
* [MCHECKSTYLE-349] - Upgrade to parent pom 31
* [MCHECKSTYLE-359] - Upgrade maven-plugins parent to version 32
* [MCHECKSTYLE-360] - Upgrade maven-site-plugin to 3.7.1 for
integration tests
* [MCHECKSTYLE-366] - Upgrade checkstyle to a more recent version

Enjoy,

-The Apache Maven team

Re: [VOTE] Retired Maven Artifact Resolution API (Maven2)

[Enrico Olivelli]

+1

Enrico

Il gio 9 mag 2019, 08:32 Bernd Prager  ha scritto:

> +1
>
> On 9/5/62 01:25, Robert Scholte wrote:
> > Hi,
> >
> > The Apache Maven project consist of about 100 (sub)projects. Due to the
> small number of volunteers and the huge amount of code to maintain we're
> missing enough space to make real progress on all these projects, including
> our ambitious ideas for the next major version(s) of Maven itself.
> > To be able to gain more focus we need to criticize the current
> subprojects and decide if it is worth maintaining.
> >
> > The Maven Artifact Resolution API (maven-artifact-resolver) is a shared
> component that could be used to easily resolve Maven project dependencies.
> The last (and only) released version is 1.0 in September 2009.(
> https://maven.apache.org/shared/maven-artifact-resolver/ [
> https://maven.apache.org/shared/maven-artifact-resolver/] ).
> > This library should not be confused with Artifact Resolver
> (maven-resolver), previously known as Aether. As you can see the naming
> will cause confusion.
> > The library that aims the same goal for Artifact Resolver is another
> shared component called maven-artifact-transfer (which by now is not just
> the transfer part or Artifact Resolver, but a bridge for both Sonatype
> Aether as used in Maven 3.0.x and Eclipse Aether as used in Maven 3.1.x+.
> This way Maven plugins and extensions can be compatible with any Maven 3
> release)
> >
> > I therefore propose that we retire the maven-artifact-resolver.
> >
> > I don't think it makes sense to do a final release. Instead we should
> update the documentation and the freeze the codebase.
> >
> > The process for retiring a plugin is described here:
> > https://maven.apache.org/developers/retirement-plan-plugins.html [
> https://maven.apache.org/developers/retirement-plan-plugins.html]
> >
> > The vote is open for 72 hours.
> >
> > [ ] +1 Yes, it's about time
> > [ ] -1 No, because...
> --
> Bernd Prager
>
> Mobile: +66.91.770.5758
> Skype: bernd.pra...@outlook.com
> PGP Public
> Key: https://pgp.mit.edu/pks/lookup?op=get=0xBDA6C225628DB3CD
> PGP Fingerprint: 0AA3 952C F211 E98A CD18 9E55 BDA6 C225 628D B3CD
>
>
>
>

[ANN] Apache Maven Surefire Plugin 2.22.2 Released

[Enrico Olivelli]

The Apache Maven team is pleased to announce the release of the Apache
Maven Surefire Plugin, version 2.22.2.

The release contains 1 bug fix about JUnit 5 Compatibility

Again we received contributions from the community in form of bug reports
and bug fixes.
Thank you and keep them coming!

http://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
  2.22.2


or for failsafe:


  org.apache.maven.plugins
  maven-failsafe-plugin
  2.22.2


or for surefire-report:


  org.apache.maven.plugins
  maven-surefire-report-plugin
  2.22.2



You can download the appropriate sources etc. from the download page:
https://maven.apache.org/surefire/download.cgi


Release Notes - Maven Surefire - Version 2.22.2

** Bug
* [SUREFIRE-1614] - JUnit Runner that writes to System.out corrupts
Surefire's STDOUT when using JUnit's Vintage Engine


Enjoy,

-The Apache Maven team

Re: Issue: maven-jarsigner-plugin 3.0.0 unreliable when contacting timestamp service over unreliable network

[Enrico Olivelli]

Andrew,
Thanks for reporting your issue.

Can you please create a JIRA ticket?

If you have cycles to implement your idea we will be happy to guide you and
eventually commit your patch.

Here you can find a guide
https://maven.apache.org/guides/development/guide-helping.html

Enrico

Il mar 23 apr 2019, 19:24 Marlow, Andrew
 ha scritto:

> Hello everyone,
>
>
>
> The signing plugin fails in the presence of an unreliable network. Could
> retries be added please? I am thinking of something like up to 3 retries,
> sleeping for one second between.
>
>
>
> I have just started to use this plugin and this is a major issue. It makes
> my overnight builds fail more often than not. Prior to me making this
> change the project produced unsigned jars during the java build and later
> on via a python script added the signing. Once the unreliable network issue
> was identified the python script was changed, adding retries (the network
> issue will most likely never be fixed). Retries in the python script fixed
> the issue. Now I am using the maven plugin the issue is back.
>
>
>
> Some people might think that if this is happening in a wired corporate
> network then the network issue ought to be identified and resolved. Well,
> maybe. But this issue could easily strike on networks that are inherently
> less reliable such as wifi and mobile. So I really think that the retries
> should be there to cater for that. Do people think this is a reasonable
> enhancement request?
>
>
>
> *Andrew Marlow*
>
> Consultant developer, Apex
>
> 38th Floor, 25 Canada Square,
>
> Canary Wharf, London E14 5LQ
>
> *T*:  020-8081-2367 / 07966-451-521
> *E*: andrew.mar...@fisglobal.com
> *FIS | Empowering the Financial World* [image:
> cid:image001.png@01D112FA.C4A77D90] [image:
> cid:image002.png@01D112FA.C4A77D90] [image:
> cid:image003.png@01D112FA.C4A77D90] 
>
> FIS Apex (UK) Limited * Registered in England and Wales No. 3573008 *
> Registered Office: 38th floor, 25 Canada Square, London, E14 5LQ, United
> Kingdom
>
> [image: 50_3]
>
>
> The information contained in this message is proprietary and/or
> confidential. If you are not the intended recipient, please: (i) delete the
> message and all copies; (ii) do not disclose, distribute or use the message
> in any manner; and (iii) notify the sender immediately. In addition, please
> be aware that any message addressed to our domain is subject to archiving
> and review by persons other than the intended recipient. FIS is a trading
> name of the following companies: Fidelity Information Services Ltd
> (registered in England No.02225203), FIS Payments (UK) Ltd (No.04215488),
> FIS Asiapacrim Holdings Ltd (No.06707320), Certegy Card Services Ltd
> (No.03517639) and Efunds International Ltd (No.01930117), all with their
> registered office at Floor 1, 51/53 Hagley Road, Birmingham B16 8TU, United
> Kingdom; and FIS Payments (Ireland) Ltd (registered in Ireland No.126879),
> with its registered office at 25/28 North Wall Quay, Dublin 1, D01 H104,
> Ireland. FIS Payments (UK) Ltd is authorised and regulated by the Financial
> Conduct Authority; some services are covered by the Financial Ombudsman
> Service (in the UK). Calls to and from the companies may be recorded for
> quality purposes. All of the above companies are part of FIS (Fidelity
> National Information Services Inc.).
>

Re: Maven sure fire report skip count issue

[Enrico Olivelli]

Atul,

Il mer 27 mar 2019, 18:43 Atul Hake  ha
scritto:

>
> Dear team,
>
> I am re running failed TC using IRetryAnalyzer.
> If i have 3 TC . 1st pass 2nd fail..retried.again fail.
> so run count is 3   , pass=1,fail =1 , skip =1.   Its correct.
> now i want to remove skip count from report so i have written code at
> OnFinish method [see attachmen] to remove skip count...so individual Test-
> .xml [Target/junitreport] does not contain any skip count.
> but final Test-Testsuit.xml [target] contains skip count .   which is
> obstacle.
>
> what is the way to remove skip count from final Test-Testsuit.xml ?
>

Removing that count usually is dangerous.


is it any version issue?
> [i want to remove skip count because it disturbing success percentage of
> report]
>

Do you have a fixed number of skipped tests?
Hiding that value may hide you problems in your test suite.
Can't you adapt your report?

Regards
Enrico


>
>
>
>
>
> Thanks & regards
> Atul Hake
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org

Re: Re: Error with mvn site:stage-deploy

[Enrico Olivelli]

Il giorno mar 8 gen 2019 alle ore 19:28 Michael Osipov
<1983-01...@gmx.net> ha scritto:
>
> Please file an issue, I will take a look.

Here it is
https://issues.apache.org/jira/browse/MSITE-832

Thank you
Enrico


>
> > Gesendet: Dienstag, 08. Januar 2019 um 17:37 Uhr
> > Von: "Konrad Windszus" 
> > An: "Maven Users List" 
> > Betreff: Re: Error with mvn site:stage-deploy
> >
> > This seems to be related to the merged PR from 
> > https://github.com/apache/maven-wagon/pull/51/files 
> > <https://github.com/apache/maven-wagon/pull/51/files>.
> > Not sure why the error happens though...
> >
> > > On 8. Jan 2019, at 17:27, Enrico Olivelli  wrote:
> > >
> > > Hi,
> > > I have this error with Maven 3.6.0 and maven-site-plugin 3.7.1 and
> > > wagon-webdav-jackrabbit 3.3.1
> > >
> > > java.lang.NoSuchMethodError:
> > > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.getBufferCapacityForTransfer(J)I
> > >at 
> > > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.access$000
> > > (AbstractHttpClientWagon.java:112)
> > >at 
> > > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon$RequestEntityImplementation.writeTo
> > > (AbstractHttpClientWagon.java:185)
> > >at org.apache.http.impl.DefaultBHttpClientConnection.sendRequestEntity
> > > (DefaultBHttpClientConnection.java:156)
> > >
> > >
> > > Is there anyworkaround ?
> > > I am trying to force all of the dependencies in the site plugin
> > >
> > > 
> > >org.apache.maven.plugins
> > >maven-site-plugin
> > >3.7.1
> > >
> > >
> > >  org.apache.maven.wagon
> > >  wagon-http
> > >  3.3.1
> > >
> > >
> > >  org.apache.maven.wagon
> > >  wagon
> > >  3.3.1
> > >  pom
> > >
> > >
> > >  org.apache.maven.wagon
> > >  wagon-http-shared
> > >  3.3.1
> > >
> > >
> > >  org.apache.maven.wagon
> > >  wagon-webdav-jackrabbit
> > >  3.3.1
> > >
> > >  
> > >
> > > But no result...
> > >
> > > Thanks
> > >
> > > Enrico
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> >
> >
>
> -
> 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

Error with mvn site:stage-deploy

[Enrico Olivelli]

Hi,
I have this error with Maven 3.6.0 and maven-site-plugin 3.7.1 and
wagon-webdav-jackrabbit 3.3.1

 java.lang.NoSuchMethodError:
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.getBufferCapacityForTransfer(J)I
at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.access$000
(AbstractHttpClientWagon.java:112)
at 
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon$RequestEntityImplementation.writeTo
(AbstractHttpClientWagon.java:185)
at org.apache.http.impl.DefaultBHttpClientConnection.sendRequestEntity
(DefaultBHttpClientConnection.java:156)


Is there anyworkaround ?
I am trying to force all of the dependencies in the site plugin


org.apache.maven.plugins
maven-site-plugin
3.7.1


  org.apache.maven.wagon
  wagon-http
  3.3.1


  org.apache.maven.wagon
  wagon
  3.3.1
  pom


  org.apache.maven.wagon
  wagon-http-shared
  3.3.1


  org.apache.maven.wagon
  wagon-webdav-jackrabbit
  3.3.1

  

But no result...

Thanks

Enrico

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

Multi Release Jars and reactors and 'test'

[Enrico Olivelli]

Hi,
I have a problem with a multi-module project.
This is the setup (you can find it here [1]):
- I have a module which produces a multi-release jar when built using jdk10+ [2]


jdk10

[10,)





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


jdk10

compile


10

${project.basedir}/src/main/java10

${project.build.outputDirectory}/META-INF/versions/10





org.apache.maven.plugins
maven-jar-plugin


default-jar



true










- a second module depends on the first one

if I run "mvn test" from the root of the reactor it seems that
surefire is picking
ONLY the directory which the jdk10+ special classes

so in the example in herddb-net project surefire uses as classpath
only a part of classes of herddb-utils (the module with produces the
multi-release jar)

Running "mvn verify" works well, and herddb-net is picking up the JAR

Enrico

[1] https://github.com/diennea/herddb/
[2] https://github.com/diennea/herddb/blob/master/herddb-utils/pom.xml

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

[ANN] Apache Maven Assembly Plugin 3.1.1 Released

[Enrico Olivelli]

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

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


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

** Bug
* [MASSEMBLY-675] - Maven Assembly packaging wildcard-excluded dependencies
* [MASSEMBLY-762] - Assembly plugin doesn't exclude transitive
dependencies when excluded by wildcards in dependencies section
* [MASSEMBLY-799] - Exclusion on wildcard, then the assembly would
still package to include the excluded libraries
* [MASSEMBLY-861] - exclusion * also packaged
* [MASSEMBLY-873] - Maven-Assembly-Plugin freezes when building
jar-with-dependencies of project depending on
org.bouncycastle:bcprov-jdk15on:1.58
* [MASSEMBLY-893] - Typo in FAQ

** Task
* [MASSEMBLY-885] - remove unused unpack code
* [MASSEMBLY-898] - upgrade to plexus-io 3.1.1
* [MASSEMBLY-899] - Make deprecated and non used of parameter
useJvmChmod parameter (plugin is now 1.7)
* [MASSEMBLY-901] - Fix trivial javadocs HTML errors
* [MASSEMBLY-902] - Some Integration tests fails if launched with
an very large UID

** Dependency upgrade
* [MASSEMBLY-876] - Upgrade parent to 31
* [MASSEMBLY-882] - Upgrade mave-surefire/failsafe-plugin 2.21.0
* [MASSEMBLY-884] - Upgrade plexus-archiver to 3.6.0
* [MASSEMBLY-890] - Upgrade plexus-interpolation to 1.25
* [MASSEMBLY-892] - Upgrade maven-plugins parent to version 33
* [MASSEMBLY-900] - Upgrade plexus-archiver to 4.0.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: NetBeans - the UI for Maven

[Enrico Olivelli]

Martin,

Il sab 24 nov 2018, 11:29 Martin Desruisseaux <
martin.desruisse...@geomatys.com> ha scritto:

> I think differently. In Apache SIS for example, we maintain both a Maven
> and Ant project. The root source code directory is a classical Maven
> project with pom.xml file [1], but we also maintain a sub-directory with
> NetBeans Ant project configuration [2]. The official project
> configuration is the Maven one, but the Ant project configuration is
> keep in sync and takes its dependencies directly from the
> ~/.m2/repository directory. This means that the project needs to be
> built with Maven once before we can use the Ant project. We do that for
> the following reasons:
>
>   * NetBeans Ant project builds faster.
>   * Application and debugging sessions start faster in NetBeans Ant
> project. This is very convenient when we do a lot of "modify - test"
> cycles.
>   * Allow to commit configurations that can not be done in Maven (header
> license, hints, additional words for check speller).
>   * NetBeans Ant Jigsaw project configuration offers better
> compatibility with Jigsaw (more on it below).
>
> A major issue is that since Jigsaw, Maven standard directory layout is
> incompatible with java, javac and javadoc "--module-path" option, which
> is making me look for alternatives (Gradle?). I describe the issue at
> [3]. I would like to try changes in maven-compiler, maven-javadoc,
> maven-jar and maven-deploy plugins for supporting Jigsaw, but did not
> had the time to start yet. As far as I can see, I can not modularize my
> projects the way I want with Maven at it stands today.
>
> I also feel more concerned about Maven standard directory layout not
> only because of its incompatibility with Jigsaw module paths, but also
> because it does not seem well suited to project mixing two or more
> languages. For example in the given directory layout:
>
>   * src/main/java
>   * src/main/cpp
>   * src/main/resources
>

Have you already shared your thoughts and needs with Apache Maven group ?

Cheers
Enrico


> Does the resources applies to Java, to C++ or both?
>
> So Maven is a great tool, but its speed is not yet the same than the
> NetBeans Ant project configuration (admittedly it may be improved with
> time) and - more importantly - I think that the Maven standard directory
> layout needs to be modified at least for Jigsaw compatibility, maybe for
> better multi-language support.
>
> Regards,
>
> Martin
>
> [1] https://github.com/apache/sis
> [2]
> https://github.com/apache/sis/tree/master/ide-project/NetBeans/nbproject
> [3] https://github.com/Geomatys/maven-plugins/wiki
>
> --


-- Enrico Olivelli

Re: Java 11 and java.xml.bin, etc.

[Enrico Olivelli]

Il giorno mer 19 set 2018 alle ore 14:15 Sverre Moe 
ha scritto:

> Would it work running JAXB 2.3.0 on Java 8? I understand this version of
> JAXB has been modularized for Java 9.
> Java 6 = JAXB Version 2.0
> Java 7 = JAXB Version 2.2.3
> Java 8 = JAXB Version 2.2.8
> Java 9 = JAXB Version 2.3.0
>


I am deploying such JAR together with my applications, this way they can
run both on JDK8 and JDK10.
On JDK8 system classes are loaded before additional JARs so having that
JARs is mostly like an NOOP.

But you should test the effective behavior before going to production.
The presence of a SecurityManager or a Web Contains may also affect the way
system classes can be overridden.

In most of all that specs/libraries the way a Factory/Provider is loaded
from the classpath is hard to understand sometimes, because there is no
common rule.

In my experience it seems safe to put those jars on the classpath and run
on JDK8.

Cheers
Enrico



>
> /Sverre
>
>
> Den ons. 19. sep. 2018 kl. 14:01 skrev Enrico Olivelli <
> eolive...@gmail.com
> >:
>
> > I suggest to use Glassfish artifacts and use 2.3.0 or later.
> > Actually the 2.3.0 version is the best replacement for jdk8 APIs
> >
> > Enrico
> >
> > Il mer 19 set 2018, 13:55 Sverre Moe  ha scritto:
> >
> > > This is what we have done for our legacy application running Java 8.
> > >
> > > By adding the dependencies for JAXB we where able to run our
> application
> > > with Java 9 and 10 without any other changes needed and still keep
> > > compatibility with Java 8.
> > >
> > > We don't have the compile scope, as we deploy with Java Web Start and
> > need
> > > the JAXB dependencies there in case some client is running Java 9+.
> > >
> > > 
> > > javax.xml.bind
> > > jaxb-api
> > > 2.2.11
> > > 
> > >
> > > 
> > > com.sun.xml.bind
> > > jaxb-core
> > > 2.2.11
> > > 
> > >
> > > 
> > > com.sun.xml.bind
> > > jaxb-impl
> > > 2.2.11
> > > 
> > >
> > > 
> > > javax.activation
> > > activation
> > > 1.1.1
> > > 
> > >
> > > This is the Sun JAXB implementation. There is alternatives from
> Glassfish
> > > and Eclipselink.
> > >
> > > Den tir. 18. sep. 2018 kl. 21:46 skrev Robert Scholte <
> > > rfscho...@apache.org
> > > >:
> > >
> > > > Add them as compile scoped dependencies. The JRE implementation will
> be
> > > > picked up first, so there should be no issues here.
> > > > AFAIK this is what the jigsaw team suggests to do. (this is actually
> > not
> > > > a
> > > > buildtool specific issue but a general Java issue)
> > > >
> > > > thanks,
> > > > Robert
> > > >
> > > >
> > > > On Fri, 14 Sep 2018 01:21:52 +0200, Bernd Eckenfels
> > > >  wrote:
> > > >
> > > > > And in addition to Jörgs Questions, do we also have a canonical
> > > > > representation which replacements are actually preferred in ASL
> land?
> > > > >
> > > > > Gruss
> > > > > Bernd
> > > > > --
> > > > > http://bernd.eckenfels.net
> > > > >
> > > > > 
> > > > > Von: Jörg Schaible 
> > > > > Gesendet: Freitag, September 14, 2018 1:16 AM
> > > > > An: users@maven.apache.org
> > > > > Betreff: Java 11 and java.xml.bin, etc.
> > > > >
> > > > > Hi,
> > > > >
> > > > > now with Java 11 not containing several jave.ee modules, what's
> the
> > > best
> > > > > approach for a library that supports still Java 8? I guess profiles
> > > based
> > > > > on the current Java version declaring the missing stuff as
> dependency
> > > are
> > > > > a bad idea. Should a library developer add the new dependencies
> > > > > nevertheless with compile/runtime scope or as provided or optional
> to
> > > > > move
> > > > > the responsibility to the library users? What do you recommend?
> > > > >
> > > > > Cheers,
> > > > > Jörg
> > > > >
> > > > >
> > > > >
> > > > >
> -
> > > > > 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
> > > >
> > > >
> > >
> > --
> >
> >
> > -- Enrico Olivelli
> >
>

Re: Java 11 and java.xml.bin, etc.

[Enrico Olivelli]

I suggest to use Glassfish artifacts and use 2.3.0 or later.
Actually the 2.3.0 version is the best replacement for jdk8 APIs

Enrico

Il mer 19 set 2018, 13:55 Sverre Moe  ha scritto:

> This is what we have done for our legacy application running Java 8.
>
> By adding the dependencies for JAXB we where able to run our application
> with Java 9 and 10 without any other changes needed and still keep
> compatibility with Java 8.
>
> We don't have the compile scope, as we deploy with Java Web Start and need
> the JAXB dependencies there in case some client is running Java 9+.
>
> 
> javax.xml.bind
> jaxb-api
> 2.2.11
> 
>
> 
> com.sun.xml.bind
> jaxb-core
> 2.2.11
> 
>
> 
> com.sun.xml.bind
> jaxb-impl
> 2.2.11
> 
>
> 
> javax.activation
> activation
> 1.1.1
> 
>
> This is the Sun JAXB implementation. There is alternatives from Glassfish
> and Eclipselink.
>
> Den tir. 18. sep. 2018 kl. 21:46 skrev Robert Scholte <
> rfscho...@apache.org
> >:
>
> > Add them as compile scoped dependencies. The JRE implementation will be
> > picked up first, so there should be no issues here.
> > AFAIK this is what the jigsaw team suggests to do. (this is actually not
> > a
> > buildtool specific issue but a general Java issue)
> >
> > thanks,
> > Robert
> >
> >
> > On Fri, 14 Sep 2018 01:21:52 +0200, Bernd Eckenfels
> >  wrote:
> >
> > > And in addition to Jörgs Questions, do we also have a canonical
> > > representation which replacements are actually preferred in ASL land?
> > >
> > > Gruss
> > > Bernd
> > > --
> > > http://bernd.eckenfels.net
> > >
> > > 
> > > Von: Jörg Schaible 
> > > Gesendet: Freitag, September 14, 2018 1:16 AM
> > > An: users@maven.apache.org
> > > Betreff: Java 11 and java.xml.bin, etc.
> > >
> > > Hi,
> > >
> > > now with Java 11 not containing several jave.ee modules, what's the
> best
> > > approach for a library that supports still Java 8? I guess profiles
> based
> > > on the current Java version declaring the missing stuff as dependency
> are
> > > a bad idea. Should a library developer add the new dependencies
> > > nevertheless with compile/runtime scope or as provided or optional to
> > > move
> > > the responsibility to the library users? What do you recommend?
> > >
> > > Cheers,
> > > Jörg
> > >
> > >
> > >
> > > -
> > > 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
> >
> >
>
-- 


-- Enrico Olivelli

Re: [SUREFIRE] No JUnit test run when TestNG is in class path

[Enrico Olivelli]

In Surefire 2.22 we integrated junit5 into the core of the plugin so this
was a big refactor.

I hope Tibor and Chris could help better in this case.

Do you need some feature in 2.22 ? Or can you stay with 2.21 until we find
the cause?

Your contribution will be really welcome, with a simple reproducer or a
patch.

Enrico

Il sab 23 giu 2018, 01:51 Dan Tran  ha scritto:

> with older surefire 2.21, I had to add  junit-platform-surefire-provider as
> sufirefire dependency, so this issue only shows up at 2.22
>
> Thanks
>
> -D
>
> On Fri, Jun 22, 2018 at 1:49 PM, Enrico Olivelli 
> wrote:
>
> > Hi Dan,
> > Did you have the same problem with an older version of surefire?
> > Enrico
> >
> > Il ven 22 giu 2018, 22:21 Dan Tran  ha scritto:
> >
> > > I went ahead to file a jira issue at
> > > https://issues.apache.org/jira/browse/SUREFIRE-1527
> > >
> > > On Wed, Jun 20, 2018 at 8:39 PM, Dan Tran  wrote:
> > >
> > > > and I am using latest surefire 2.22.0
> > > >
> > > > -D
> > > >
> > > > On Wed, Jun 20, 2018 at 8:39 PM, Dan Tran  wrote:
> > > >
> > > >>
> > > >> Hi
> > > >>
> > > >> I have junit4/5 and testng in the classpath and none of my junit
> tests
> > > >> got invoked
> > > >>
> > > >> I this a correct behavior?
> > > >>
> > > >> I ended up to directly add junit-platform-surefire-provider  to
> > > >> surefire's dependency
> > > >>
> > > >> and I cant remove testng since we have legacy none test code  uses
> > > testng
> > > >> assert
> > > >>
> > > >> Thanks
> > > >>
> > > >> -Dan
> > > >>
> > > >
> > > >
> > >
> > --
> >
> >
> > -- Enrico Olivelli
> >
>
-- 


-- Enrico Olivelli

Re: [SUREFIRE] No JUnit test run when TestNG is in class path

[Enrico Olivelli]

Hi Dan,
Did you have the same problem with an older version of surefire?
Enrico

Il ven 22 giu 2018, 22:21 Dan Tran  ha scritto:

> I went ahead to file a jira issue at
> https://issues.apache.org/jira/browse/SUREFIRE-1527
>
> On Wed, Jun 20, 2018 at 8:39 PM, Dan Tran  wrote:
>
> > and I am using latest surefire 2.22.0
> >
> > -D
> >
> > On Wed, Jun 20, 2018 at 8:39 PM, Dan Tran  wrote:
> >
> >>
> >> Hi
> >>
> >> I have junit4/5 and testng in the classpath and none of my junit tests
> >> got invoked
> >>
> >> I this a correct behavior?
> >>
> >> I ended up to directly add junit-platform-surefire-provider  to
> >> surefire's dependency
> >>
> >> and I cant remove testng since we have legacy none test code  uses
> testng
> >> assert
> >>
> >> Thanks
> >>
> >> -Dan
> >>
> >
> >
>
-- 


-- Enrico Olivelli

Re: Maven Assembly Plugin renaming jar

[Enrico Olivelli]

Sam,
I am not an expert but dod you try not using 8.0.0-SNAPSHOT,9.0.0-SNAPSHOT)
but a defined version ?

Enrico

Il ven 15 dic 2017, 17:51 Wilson, Sam <sawil...@akamai.com> ha scritto:

> Sorry to bump and old thread, but I’d appreciate it if someone had any
> insight.
>
> Sam
>
> From: Sam Wilson <sawil...@akamai.com>
> Reply-To: Maven Users List <users@maven.apache.org>
> Date: Friday, November 24, 2017 at 11:12 AM
> To: "users@maven.apache.org" <users@maven.apache.org>
> Subject: Re: Maven Assembly Plugin renaming jar
>
> Oh, I should mention that I've tried this with maven-assembly-plugin 2.4
> and 3.1.0.
>
> Sam
>
> On 11/24/2017 11:07 AM, Wilson, Sam wrote:
> Hey!
> Hopefully you can help me out. Maven assembly plugin seems to be renaming
> a jar file without being told to, and it’s messing up my MANIFEST.MF
> classpath.
> You notice in the snippet of mvn -X below the assembly plugin seems to be
> getting version 8.0.2, but it renames it to 8.0.0.
> Thanks,
> Sam
> ---
> mvn -X package
> --
> […]
> [DEBUG] Adding dependency artifact com.example:MyArtifact:jar:8.0.0.
> [DEBUG] Adding artifact: com.example:MyArtifact:jar:8.0.0 with file:
> /Users/me/.m2/repository/com/example/MyArtifact/8.0.2/MyArtifact-8.0.2.jar
> to assembly location: lib/MyArtifact-8.0.0.jar.
> [DEBUG] Adding file:
> /Users/me/.m2/repository/com/example/MyArtifact/8.0.2/MyArtifact-8.0.2.jar
> to archive location: Project/lib/MyArtifact-8.0.0.jar
> […]
> ---
> Project/pom.xml
> ---
> 
>  
>  
>  
>  
>  com.example
>  MyArtifact
>  [8.0.0-SNAPSHOT,9.0.0-SNAPSHOT)
>  
>  
>  
>  
>  
>  org.apache.maven.plugins
>  maven-jar-plugin
>  2.4
>  
>  
>  
>  true
>  lib/
>  com.example.MainClass
>  
>  
>  
>  
>  
>  org.apache.maven.plugins
>  maven-assembly-plugin
>  2.2
>  
>  
>  package
>  
>  single
>  
>  
>  
>  ${project.artifactId}
>  
>  
>  false
>  
>  
>
>  src/assembly/bin.xml
>  
>  false
>  
>  
>  
>  
> 
> ---
> Project/src/assembly/bin.xml
> ---
>   xmlns="
> http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0;
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>  xsi:schemaLocation="
> http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
> http://maven.apache.org/xsd/assembly-1.1.0.xsd;<
> http://maven.apache.org/xsd/assembly-1.1.0.xsd%22>>
>  bin
>  ${artifactId}
>  
>  tar.gz
>  dir
>  
>  
>  
>  false
>  false
>  runtime
>  lib
>  
>  
>  
>  
>
>  target/${artifactId}-${version}.${packaging}
>  /
>  ${artifactId}.${packaging}
>  
>  
>
>  src/main/resources/ProjectConfiguration.properties
>  ${artifactId}.properties
>      /
>  
>  
>  log4j2.xml
>  /
>  
>  
> 
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org users-unsubscr...@maven.apache.org>
> For additional commands, e-mail: users-h...@maven.apache.org users-h...@maven.apache.org>
>
>
> --


-- Enrico Olivelli

Re: Doxia 1.7.4 Site tools fails on Java 9

[Enrico Olivelli]

which is the broken dependency ?
maybe you could override the dependency of the plugin directly in your pom
so you won't be stopped ?

-- Enrico

2017-09-26 12:59 GMT+02:00 Martijn Verburg :

> Hi all,
>
> Doxia site-tools uses an old apache commons lib (which is fixed in
> 1.7.5-SNAPSHOT), any chance of a release of the site-tools (and
> consequently) site plugin to support Java 9?
>
> Cheers,
> Martijn
>