Is there any debug output available that shows mvn checking artifact checksums?

[KARR, DAVID]

I wanted to experiment with the "checksumPolicy" property in each repository in 
the "~/.m2/settings.xml" file.  Our intranet repo seems to make it hard to 
simulate a corrupted checksum (this is good, in general).  I don't see any way 
to get "mvn" to tell me that it is checking the checksum, even with "-X". Is 
there any way to make it show that?

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

RE: Re: Custom auth plugin/extension - how to?

[David Grieve]

A “maven-rfc” repo is a good idea if the issue of governance can be worked out. 
There will be a good deal of overhead related to maintaining, gatekeeping, and 
administration of such a repository. If RFC’s were just specs with problem 
statements, decision records that might be easier. An RFC should also be 
sponsored/owned by a committer. The work could happen in a fork somewhere that 
was established by the sponsor who could then manage whether to leave it wide 
open for contribution or to a select few.

As for Bernd’s question and the “Handling sensitive data in Maven” wiki, 
couldn’t this problem be solved by injecting an implementation of 
org.apache.maven.settings.building.SettingsBuilder to suite your needs? For 
example, I could have a SettingsBuilder that gets settings from some on-line 
storage (imagine a build environment where “settings.xml" is centralized).

On 2024/06/05 20:31:40 Tamás Cservenák wrote:
> Asf wiki is not the best place for brainstorming, as is usable only for
> people w asf accounts (i guess).
>
> What if we create a repo like "maven-rfc", where anyone can raise PRs (new
> functionality, change requests or just ideas), these would be like
> "proposals", that we discuss and modify specs w PRs, and once proposal
> considered "complete", it can be moved to "to be implemented" state (those
> could be plain directories), maybe even version those things?
>
> And then implementation can happen based on documented
> requirements/functionality?
>
> T
>
> On Wed, Jun 5, 2024, 20:27 Tamás Cservenák 
> mailto:ta...@cservenak.net>> wrote:
>
> > Howdy,
> >
> > Bernd, I would be very interested to collect some ideas to solve exactly
> > this problem...
> > When I revamped maven-gpg-plugin re "worst practices", I started tinkering
> > about this...
> >
> > Created page just to gather ideas...
> >
> > https://cwiki.apache.org/confluence/display/MAVEN/Handling+sensitive+data+in+Maven
> >
> > Unsure is this editable for you... we may want some other place for
> > brainstorming?
> >
> > Thanks
> > T
> >
> > On Wed, Jun 5, 2024 at 7:24 PM Bernd Eckenfels 
> > mailto:ec...@zusammenkunft.net>>
> > wrote:
> >
> >> BTW Speaking of “custom”, I would be very interested in
> >> a token based authentication, at least for read access to
> >> our repository server and mirror, we currently ship a static
> >> read-only login, and also we don’t want to allow putting
> >> their write (LDAP Login) credentials into files.
> >>
> >> If the maven ecosystem would have a OS/Token method
> >> like requestin a JWT token from a distribution point which
> >> uses native Kerberos SSPI or user certificates that would
> >> greatly improve this,
> >>
> >> What’s your plan for that auth, can you upstream it?
> >>
> >> Gruß
> >> Bernd
> >>
> >> David Grieve wrote on 4. June 2024 20:33 (GMT +02:00):
> >>
> >> > Thank you for the hint, Tamás.
> >> >
> >> > The problem I’m trying to solve is that I want a custom Authentication
> >> > for a particular server. I do not want to re-implement HttpTransporter.
> >> > Here are the important bits of what I’ve come up with.
> >> > --
> >> > public class MyTransporterFactory implements TransporterFactory {
> >> >
> >> > // copied from
> >> > org.eclipse.aether.transport.http.HttpTransporterFactory
> >> > private static Map
> >> > getManuallyCreatedExtractors() {
> >> > HashMap map = new HashMap<>();
> >> > map.put(Nexus2ChecksumExtractor.NAME, new
> >> > Nexus2ChecksumExtractor());
> >> > map.put(XChecksumChecksumExtractor.NAME, new
> >> > XChecksumChecksumExtractor());
> >> > return Collections.unmodifiableMap(map);
> >> > }
> >> >
> >> > // I’m not happy with this...
> >> > private final HttpTransporterFactory httpTransporterFactory = new
> >> > HttpTransporterFactory(getManuallyCreatedExtractors());
> >> >
> >> > @Override
> >> > public Transporter newInstance(RepositorySystemSession session,
> >> > RemoteRepository repository)  throws NoTransporterException {
> >> >
> >> > if (requiresSpecialAuth(repository)) {
> >> > repository = new Re

Re: [EXTERNAL] Re: Re: Custom auth plugin/extension - how to?

[David Grieve]

Thanks again, Tamás. It is comforting to know that my implementation was not 
far off.

From: Tamás Cservenák 
Date: Wednesday, June 5, 2024 at 3:38 AM
To: Maven Users List 
Subject: [EXTERNAL] Re: Re: Custom auth plugin/extension - how to?

[You don't often get email from ta...@cservenak.net. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

Howdy,

I'd do it as this:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fcstamas%2F5c787875fc3196dbd200e3bd24692c98&data=05%7C02%7CDavid.Grieve%40microsoft.com%7Cc5e5dc98de28474fb72808dc85328934%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638531699300812986%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=GYJefX6wgOXA0SDH%2BuNpHqlYYq9hp26r6bfGRttFrf4%3D&reserved=0<https://gist.github.com/cstamas/5c787875fc3196dbd200e3bd24692c98>

Facts:
- make priority higher than than of HTTP - this makes sure your transport
will be always asked before Http one
- just delegate/reuse http transport, no need to reimplement anything (make
it also a JSR330 component!)
- in newInstance there is a check (copied from http transport) to ensure
httpTransport will not throw, then do your thing, and call into
httpTransport

HTH
T

On Tue, Jun 4, 2024 at 8:34 PM David Grieve
 wrote:

> Thank you for the hint, Tamás.
>
> The problem I’m trying to solve is that I want a custom Authentication for
> a particular server. I do not want to re-implement HttpTransporter. Here
> are the important bits of what I’ve come up with.
> --
> public class MyTransporterFactory implements TransporterFactory {
>
> // copied from org.eclipse.aether.transport.http.HttpTransporterFactory
> private static Map
> getManuallyCreatedExtractors() {
> HashMap map = new HashMap<>();
> map.put(Nexus2ChecksumExtractor.NAME, new
> Nexus2ChecksumExtractor());
> map.put(XChecksumChecksumExtractor.NAME, new
> XChecksumChecksumExtractor());
> return Collections.unmodifiableMap(map);
> }
>
> // I’m not happy with this...
> private final HttpTransporterFactory httpTransporterFactory = new
> HttpTransporterFactory(getManuallyCreatedExtractors());
>
> @Override
> public Transporter newInstance(RepositorySystemSession session,
> RemoteRepository repository)  throws NoTransporterException {
>
> if (requiresSpecialAuth(repository)) {
> repository = new RemoteRepository.Builder(repository)
> .setAuthentication(new MyAuthentication(repository))
> .build();
> }
> return httpTransporterFactory.newInstance(session, repository);
> }
> --
>
> Then “MyAuthentication” does the right thing for the fill method.
>
> This approach is working for me, but I’d be interested to know if there is
> a better way. I do not want to re-implement HttpTransport!
>
>
> On 2024/06/03 20:25:48 Tamás Cservenák wrote:
> > Howdy,
> >
> > What are you trying to do? You may go better if you implement custom
> > (resolver) transport maybe?
> >
> > Thanks
> > T
> >
> > On Mon, Jun 3, 2024, 22:22 David Grieve  <mailto:da...@microsoft.com.inva>lid>
> > wrote:
> >
> > > My questions are: Is this doable and, if so, how would one go about it?
> > >
> > > I’m trying to cobble together a plugin/extension that will either get
> an
> > > auth token for resolving an artifact before the artifact is resolved,
> or
> > > will get an auth token if the resolution returns a 401.
> > > The plugin route happens too late in the execution, but I’ve found that
> > > with an AbstractMavenLifecycleParticipant at least afterProjectsRead
> gets
> > > called before artifact resolution. However, I can’t seem to affect the
> > > server password in a way that allows artifact resolution to  succeed.
> > > I’ve also tried overriding some default implementations, but I don’t
> see
> > > the extension getting invoked (I see that Maven is aware of the
> extension,
> > > but it doesn’t get used AFAICT).
> > >
> >
>
>

RE: Re: Custom auth plugin/extension - how to?

[David Grieve]

Thank you for the hint, Tamás.

The problem I’m trying to solve is that I want a custom Authentication for a 
particular server. I do not want to re-implement HttpTransporter. Here are the 
important bits of what I’ve come up with.
--
public class MyTransporterFactory implements TransporterFactory {

// copied from org.eclipse.aether.transport.http.HttpTransporterFactory
private static Map 
getManuallyCreatedExtractors() {
HashMap map = new HashMap<>();
map.put(Nexus2ChecksumExtractor.NAME, new Nexus2ChecksumExtractor());
map.put(XChecksumChecksumExtractor.NAME, new 
XChecksumChecksumExtractor());
return Collections.unmodifiableMap(map);
}

// I’m not happy with this...
private final HttpTransporterFactory httpTransporterFactory = new 
HttpTransporterFactory(getManuallyCreatedExtractors());

@Override
public Transporter newInstance(RepositorySystemSession session, 
RemoteRepository repository)  throws NoTransporterException {

if (requiresSpecialAuth(repository)) {
repository = new RemoteRepository.Builder(repository)
.setAuthentication(new MyAuthentication(repository))
.build();
}
return httpTransporterFactory.newInstance(session, repository);
}
--

Then “MyAuthentication” does the right thing for the fill method.

This approach is working for me, but I’d be interested to know if there is a 
better way. I do not want to re-implement HttpTransport!


On 2024/06/03 20:25:48 Tamás Cservenák wrote:
> Howdy,
>
> What are you trying to do? You may go better if you implement custom
> (resolver) transport maybe?
>
> Thanks
> T
>
> On Mon, Jun 3, 2024, 22:22 David Grieve 
> mailto:da...@microsoft.com.inva>lid>
> wrote:
>
> > My questions are: Is this doable and, if so, how would one go about it?
> >
> > I’m trying to cobble together a plugin/extension that will either get an
> > auth token for resolving an artifact before the artifact is resolved, or
> > will get an auth token if the resolution returns a 401.
> > The plugin route happens too late in the execution, but I’ve found that
> > with an AbstractMavenLifecycleParticipant at least afterProjectsRead gets
> > called before artifact resolution. However, I can’t seem to affect the
> > server password in a way that allows artifact resolution to  succeed.
> > I’ve also tried overriding some default implementations, but I don’t see
> > the extension getting invoked (I see that Maven is aware of the extension,
> > but it doesn’t get used AFAICT).
> >
>

Custom auth plugin/extension - how to?

[David Grieve]

My questions are: Is this doable and, if so, how would one go about it?

I’m trying to cobble together a plugin/extension that will either get an auth 
token for resolving an artifact before the artifact is resolved, or will get an 
auth token if the resolution returns a 401.
The plugin route happens too late in the execution, but I’ve found that with an 
AbstractMavenLifecycleParticipant at least afterProjectsRead gets called before 
artifact resolution. However, I can’t seem to affect the server password in a 
way that allows artifact resolution to  succeed.
I’ve also tried overriding some default implementations, but I don’t see the 
extension getting invoked (I see that Maven is aware of the extension, but it 
doesn’t get used AFAICT).

maven-checkstyle-plugin using project dependencies?

[David Hoffer]

Is it possible to configure maven-checkstyle-plugin to use one of the
project's modules as the source of the checkstyle XML file?

E.g. I have the plugin configured like this:


org.apache.maven.plugins
maven-checkstyle-plugin
${maven-checkstyle-plugin.version}


com.puppycrawl.tools
checkstyle
10.12.3


com.bs.arm.a2dl
a2dl-build-tools
${project.version}



a2dl/google_checks.xml
true
true
false



verify-checkstyle
verify

check






The problem is the plugin is looking in my .m2 folder or Maven proxy server
for this dependency.

 
com.bs.arm.a2dl
a2dl-build-tools
${project.version}
 

But it doesn't exist there yet as its a module of my/this project so its
one of the modules in the Maven build reactor.  Is it possible to configure
the plugin to use the project modules for this?

-Dave

mvn as used in Eclipse m2e gets parse error because of mistake in Maven 4.0.0 schema

[David Karr]

I have a feeling this has been covered before, but I'll ask just in case.

I have a pom.xml that inherits from a parent pom, and the child pom has the
following plugin definition:
--

  maven-compiler-plugin
  3.8.0
  
11

  
org.projectlombok
lombok
1.18.30
  

  

--

Notice the "combine.self" attribute. In a command line mvn build, this does
exactly what it needs to, completely overriding the plugin configuration
inherited from the parent pom.  If I don't have that, it results in errors
because it "merges" the plugin configs by default.

What's annoying is that if I open this pom.xml in Eclipse, with the m2e
plugin, I get the following error on that line:

cvc-complex-type.3.2.2: Attribute 'combine.self' is not allowed to
appear in element 'configuration'.

I, along with multiple other people, assumed that this indicates a bug in
m2e, because it clearly works in the command-line build.  However, it was
pointed out that m2e is actually USING the defined schema defined in the
boilerplate of a pom.xml, instead of ignoring it, and if you open up that
schema, it clearly shows the lack of an "attribute" element in the
"configuration" complex-type.

So, clearly mvn is using that attribute, but I'm guessing it's not doing
any schema validation, or builds using that attribute would fail.

I have a feeling this situation has been in place for a long time.

Re: Why does one of our archetypes work, and the other gets "The defined artifact is not an archetype"

[David Karr]

Any more thoughts about this?  I think the key clue is at the end of my
previous response, indicating that it doesn't even recognize that packaging
type. That clearly means there are unexpected versions of something being
used here, but I'm not sure what it would be.

On Mon, Oct 9, 2023 at 10:56 AM David Karr 
wrote:

> Ok, I'll address some points in order.  My current command line is this:
> --
> mvn -e archetype:generate -DgroupId=com.att.idp -DartifactId=MyApplication
> -Dpackage=com.att.idp -DarchetypeGroupId=com.att.idse
> -DarchetypeArtifactId=idse-springmvc-archetype
> -DarchetypeVersion=2.0.0-SNAPSHOT
> --
>
> And this is a relevant excerpt of the pom.xml from the archetype:
> --
>  com.att.idse
> idse-springmvc-archetype
> 2.0.0-SNAPSHOT
>
> IDP Jersey Archetype
> Maven Archetype for creating the IDP microservices
> project
>
> jar
> 
>
> Note that it uses the "jar" packaging, but I'll come back to that later in
> this message.
>
> Running this results in the following:
> --
> 10:41:09 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-archetype-plugin:3.2.1:generate
> (default-cli) on project standalone-pom: The defined artifact is not an
> archetype -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-archetype-plugin:3.2.1:generate
> (default-cli) on project standalone-pom: The defined artifact is not an
> archetype
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:972)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native
> Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.MojoFailureException: The defined
> artifact is not an archetype
> at
> org.apache.maven.archetype.mojos.CreateProjectFromArchetypeMojo.execute
> (CreateProjectFromArchetypeMojo.java:225)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>

Re: Why does one of our archetypes work, and the other gets "The defined artifact is not an archetype"

[David Karr]

uncher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)
Caused by:
org.apache.maven.archetype.exception.ArchetypeGenerationConfigurationFailure:
The defined artifact is not an archetype
at
org.apache.maven.archetype.ui.generation.DefaultArchetypeGenerationConfigurator.configureArchetype
(DefaultArchetypeGenerationConfigurator.java:171)
at
org.apache.maven.archetype.mojos.CreateProjectFromArchetypeMojo.execute
(CreateProjectFromArchetypeMojo.java:209)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:972)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)
-

Next, if we attempt to change the "packaging" to "maven-archetype" as you
state, and as shown in the examples, I get this when I try to "mvn install"
that:
--
Unknown packaging: maven-archetype @ line 14, column 13
--

I am using Maven v3.8.2. I tried testing with v3.9.2, and it gets the same
error.


On Sat, Oct 7, 2023 at 3:05 AM Herve Boutemy  wrote:

> it looks you're getting an issue finding your archetype jar in your local
> repository, and the message is misleading: I'd love to improve it
>
> can you share the stacktrace of your failed execution (add -e to your
> command line)?
>
> You can in parallel look at simple archetypes source code, to see the
> happy path, like
> https://maven.apache.org/archetypes/maven-archetype-simple/ and its
> source
> https://github.com/apache/maven-archetypes/tree/master/maven-archetype-simple
>
> look at its pom.xml (that has maven-archetype packaging): I hope your own
> archetype project uses this packaging), do "mvn install" to install
> 1.5-SNAPSHOT, and "mvn archetype:generate
> -DarchetypeGroupId=org.apache.maven.archetypes
> -DarchetypeArtifactId=maven-archetype-simple
> -DarchetypeVersion=1.5-SNAPSHOT" to generate a project from it
>
> Regards,
>
> Hervé
>
> On 2023/10/06 16:11:36 David Karr wrote:
> > Thanks for the responses. I've gone through this, but I still don't see a
> > solution.
> >
> > In our archetype project, I am running the
> "archetype:create-from-project"
> > goal and then running "mvn install", and then referencing the installed
> > archetype in a work directory, which fails with the given error. I'm
> > thinking that running "c-f-p" in the root of the archetype project is not
> > exactly what is required, but I have no idea.
> >
> > I still have no idea why it's saying it's not an archetype, but I imagine
> > you would conclude the same thing.
> >
> > On Thu, Oct 5, 2023 at 4:32 PM Herve Boutemy 
> wrote:
> >
> > > reading the mini guide
> > >  https://maven.apache.org/guides/mini/guide-creating-archetypes.html
> > > I see that it mixes the archetype = the jar that is stored to the
> > > repository and the archetype project = the Maven project that will
> create
> > > the archetype jar
> > &

Re: Why does one of our archetypes work, and the other gets "The defined artifact is not an archetype"

[David Karr]

Thanks for the responses. I've gone through this, but I still don't see a
solution.

In our archetype project, I am running the "archetype:create-from-project"
goal and then running "mvn install", and then referencing the installed
archetype in a work directory, which fails with the given error. I'm
thinking that running "c-f-p" in the root of the archetype project is not
exactly what is required, but I have no idea.

I still have no idea why it's saying it's not an archetype, but I imagine
you would conclude the same thing.

On Thu, Oct 5, 2023 at 4:32 PM Herve Boutemy  wrote:

> reading the mini guide
>  https://maven.apache.org/guides/mini/guide-creating-archetypes.html
> I see that it mixes the archetype = the jar that is stored to the
> repository and the archetype project = the Maven project that will create
> the archetype jar
>
> please look at the schema in the plugin page:
> https://maven.apache.org/archetype/maven-archetype-plugin/
> It shows the full lifecycle:
> - from an eventual sample project
> - to an archetype project
> - to the built archetype
> - an finally to the project generated from the archetype
> and it lists the goals of the maven-artifact-plugin to go from one step to
> the next one
>
> The mini guide only covers writing the archetype project by hand, and
> building it to get the archetype jar
>
> I hope this will help understanding the wider logic, before digging into
> eventual bugs or not clear messages when something gets wrong
>
> Regards,
>
> Hervé
>
> On 2023/10/05 23:15:50 Herve Boutemy wrote:
> > documentation probably also needs love:
> > you found the mini-guide, but not the plugin reference documentation
> that explains much more:
> https://maven.apache.org/archetype/maven-archetype-plugin/index.html
> >
> > I'm not sure mini guide was updated as it should
> >
> > Regards,
> >
> > Hervé
> >
> > On 2023/10/05 20:38:20 David Karr wrote:
> > > I support and maintain a platform used by a couple hundred
> > > SpringBoot/JAX-RS/Maven/K8S services.  When new services are created, a
> > > Maven archetype is used to create the service skeleton.  This has
> worked
> > > fine for quite a while.
> > >
> > > We're now working on a variation using SpringMVC instead of JAX-RS, and
> > > eventually making that the default.
> > >
> > > One of my team members took the existing Jersey/JAX-RS archetype
> project,
> > > made a copy, and then changed a bunch of things for SpringMVC instead
> of
> > > JAX-RS.  We installed that archetype in our local maven repo for
> initial
> > > testing, using "mvn install".
> > >
> > > We run a command line like the following:
> > >
> > > mvn archetype:generate -DgroupId=com.org.idp
> -DartifactId=MyApplication
> > > -Dpackage=com.org.idp -DarchetypeGroupId=com.org.idse
> > > -DarchetypeArtifactId=idse-springmvc-archetype
> > > -DarchetypeVersion=2.0.0-SNAPSHOT
> > >
> > > The "archetypeVersion" property value corresponds to the version
> attribute
> > > in the pom.xml of the archetype.
> > >
> > > This produces the following output:
> > > 
> > >  [INFO] Generating project in Batch mode
> > > [WARNING] Archetype not found in any catalog. Falling back to central
> > > repository.
> > > [WARNING] Add a repository with id 'archetype' in your settings.xml if
> > > archetype's repository is elsewhere.
> > > Downloading from nexus:
> > >
> https://repocentral.it.att.com:8443/nexus/content/groups/att-public-group/com/att/idse/idse-springmvc-archetype/2.0.0-SNAPSHOT/maven-metadata.xml
> > > [INFO]
> > >
> 
> > > [INFO] BUILD FAILURE
> > > [INFO]
> > >
> 
> > > [INFO] Total time:  52.232 s
> > > [INFO] Finished at: 2023-10-04T13:33:46-07:00
> > > [INFO]
> > >
> 
> > > [ERROR] Failed to execute goal
> > > org.apache.maven.plugins:maven-archetype-plugin:3.2.1:generate
> > > (default-cli) on project standalone-pom: The defined artifact is not an
> > > archetype -> [Help 1]
> > > [ERROR]
> > > [ERROR] To see the full stack trace of the errors, re-run Maven with
> the -e
> > > switch.
> > > [ERROR] Re-run Maven using t

Why does one of our archetypes work, and the other gets "The defined artifact is not an archetype"

[David Karr]

I support and maintain a platform used by a couple hundred
SpringBoot/JAX-RS/Maven/K8S services.  When new services are created, a
Maven archetype is used to create the service skeleton.  This has worked
fine for quite a while.

We're now working on a variation using SpringMVC instead of JAX-RS, and
eventually making that the default.

One of my team members took the existing Jersey/JAX-RS archetype project,
made a copy, and then changed a bunch of things for SpringMVC instead of
JAX-RS.  We installed that archetype in our local maven repo for initial
testing, using "mvn install".

We run a command line like the following:

mvn archetype:generate -DgroupId=com.org.idp -DartifactId=MyApplication
-Dpackage=com.org.idp -DarchetypeGroupId=com.org.idse
-DarchetypeArtifactId=idse-springmvc-archetype
-DarchetypeVersion=2.0.0-SNAPSHOT

The "archetypeVersion" property value corresponds to the version attribute
in the pom.xml of the archetype.

This produces the following output:

 [INFO] Generating project in Batch mode
[WARNING] Archetype not found in any catalog. Falling back to central
repository.
[WARNING] Add a repository with id 'archetype' in your settings.xml if
archetype's repository is elsewhere.
Downloading from nexus:
https://repocentral.it.att.com:8443/nexus/content/groups/att-public-group/com/att/idse/idse-springmvc-archetype/2.0.0-SNAPSHOT/maven-metadata.xml
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time:  52.232 s
[INFO] Finished at: 2023-10-04T13:33:46-07:00
[INFO]

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-archetype-plugin:3.2.1:generate
(default-cli) on project standalone-pom: The defined artifact is not an
archetype -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException


This doesn't tell me WHY it thinks this is not an archetype.

I find some confusing docs about creating and installing archetypes.

I found this page:
https://maven.apache.org/guides/mini/guide-creating-archetypes.html .
This example is curious, as the pom.xml for the archetype references the
"archetype-packaging" extension, but the text says nothing about this. In
fact, it clearly says "All you need to specify is a groupId, artifactId and
version". Neither our working archetype or the new one references that
extension.

I also found this issue: https://issues.apache.org/jira/browse/ARCHETYPE-529
. No one ever responded to this, so perhaps the reporter is way off. I see
that this mentions the "create-from-project" goal. This is not mentioned in
the previous doc page.

What else can I look at to debug this problem?

How to control ordering of transient dependencies?

[David Karr]

I support a large number of SpringBoot services built with Maven.

I recently noticed that one of our transient dependencies has a conflict
with another transient dependency, as it has several FQCNs that are
identical to ones in the second artifact, but with different content.  In
most of those services, the first artifact ended up in the classpath after
the second artifact, so the "good" version of those classes was obtained
from the second artifact.

In a couple of services, the order was reversed, causing fatal startup
problems.

I thought perhaps that if I moved the "top-level" dependency that
references the transient artifact to the bottom of the dependencies list in
the pom.xml, it might control where that transient artifact ends up in the
classpath. This unfortunately had no effect. It's possible this has an
effect on the ordering of the "top-level" dependencies, but it didn't do
anything for the transient dependencies.

I had thought that perhaps fixing this required changing the SpringBoot
"classpath.idx" file that specifies the order that SpringBoot would load
dependencies, so I created this issue:
https://github.com/spring-projects/spring-boot/issues/37125

However, I think the responder is correct that the ordering in this file
really should reflect the "Maven view" of dependency ordering.

In the particular case where this came up, I have resolved the problem the
only way available to me, which is simply editing the problematic jar,
removing the FQCNs that are duplicates, and creating a new artifact that
services will use instead of the original jar. This is obviously a hack,
and might not be possible in other situations.

Re: JAXB2 Maven Plugin XJC Goal JDK17 Question

[David Hoffer]

That one works great as a general purpose XJC tool and supports JAXB4 but
unfortunately to use any of the plugin options

-XtoString
-Xequals
-XhashCode
-Xcopyable

Requires the use of jaxb2-basics according to the
docs which is ancient and stuck in JDK8 and prior.  So, not an option for a
JDK17 Java EE 10 application.

If anyone knows of newer plugin extensions that can support JDK17 let me
know.

Thanks,
-David

On Tue, Aug 22, 2023 at 2:46 PM Delany  wrote:

> This one has JAXB4 support
> https://github.com/phax/maven-jaxb2-plugin
> Delany
>
>
>
> On Tue, 22 Aug 2023 at 22:04, David Hoffer  wrote:
>
> > I think that is based on:
> >
> > org.jvnet.jaxb2.maven2
> > maven-jaxb2-plugin
> >
> > Which, I can't get to work with JDK17 and to be compatible with the rest
> of
> > my app has to be at Java EE 10.
> >
> > I'm currently trying to use:
> >
> > org.codehaus.mojo
> > jaxb2-maven-plugin
> > 3.1.0
> >
> > As it's current; seems to support JDK17 Java 10 well.  But it seems they
> > dropped support for -X argument options.  Or I just can't find how it's
> > supported.
> >
> > I have also tried:
> >
> > org.apache.cxf
> > cxf-xjc-plugin
> > 4.0.0
> >
> > And it too is current, supports JDK17 and Java 10.  It does have
> extension
> > support for:
> >
> > toString
> > defaultValue
> >
> > But does not have support for:
> > equals
> > hashCode
> >
> > And those I would really like to have.  Trying to find a way to have all
> 4
> > of those options.
> >
> > -Dave
> >
> > On Tue, Aug 22, 2023 at 1:31 PM Delany 
> wrote:
> >
> > > Try here https://stackoverflow.com/a/32336886/2746335
> > > Delany
> > >
> > > On Tue, 22 Aug 2023 at 21:16, David Hoffer  wrote:
> > >
> > > > I'm wanting to use the JAXB2 Maven Plugin's XJC goal in a JDK17
> > project.
> > > > I'm using version 3.1.0.  I can get it to generate the Java code but
> > > can't
> > > > find any way to add support for optional things like:
> > > >
> > > > toString
> > > > equals
> > > > hashCode
> > > > defaultValue
> > > >
> > > > Can someone point me in the right direction on how to add these very
> > > useful
> > > > options to the generated code.
> > > >
> > > > Thanks,
> > > > -Dave
> > > >
> > >
> >
>

Re: JAXB2 Maven Plugin XJC Goal JDK17 Question

[David Hoffer]

I think that is based on:

org.jvnet.jaxb2.maven2
maven-jaxb2-plugin

Which, I can't get to work with JDK17 and to be compatible with the rest of
my app has to be at Java EE 10.

I'm currently trying to use:

org.codehaus.mojo
jaxb2-maven-plugin
3.1.0

As it's current; seems to support JDK17 Java 10 well.  But it seems they
dropped support for -X argument options.  Or I just can't find how it's
supported.

I have also tried:

org.apache.cxf
cxf-xjc-plugin
4.0.0

And it too is current, supports JDK17 and Java 10.  It does have extension
support for:

toString
defaultValue

But does not have support for:
equals
hashCode

And those I would really like to have.  Trying to find a way to have all 4
of those options.

-Dave

On Tue, Aug 22, 2023 at 1:31 PM Delany  wrote:

> Try here https://stackoverflow.com/a/32336886/2746335
> Delany
>
> On Tue, 22 Aug 2023 at 21:16, David Hoffer  wrote:
>
> > I'm wanting to use the JAXB2 Maven Plugin's XJC goal in a JDK17 project.
> > I'm using version 3.1.0.  I can get it to generate the Java code but
> can't
> > find any way to add support for optional things like:
> >
> > toString
> > equals
> > hashCode
> > defaultValue
> >
> > Can someone point me in the right direction on how to add these very
> useful
> > options to the generated code.
> >
> > Thanks,
> > -Dave
> >
>

JAXB2 Maven Plugin XJC Goal JDK17 Question

[David Hoffer]

I'm wanting to use the JAXB2 Maven Plugin's XJC goal in a JDK17 project.
I'm using version 3.1.0.  I can get it to generate the Java code but can't
find any way to add support for optional things like:

toString
equals
hashCode
defaultValue

Can someone point me in the right direction on how to add these very useful
options to the generated code.

Thanks,
-Dave

Re: Confused about how to override a transient artifact version

[David Karr]

We actually already use several different BOMs, both internal and external.
It didn't occur to me to look for a jackson-bom, and that's a good idea.
However, I assumed that would just be a cosmetic change, but on the first
try it seemed like that made it work. I need to do some cleanup, but I
think this will work. Thanks.

On Fri, Jul 28, 2023 at 5:21 PM Nick Stolwijk 
wrote:

> Hi David,
>
> You could try to add the Jackson BOM in the parent dependencyManagement.
> That would override all versions in the (transitive) dependencies of the
> child modules. For a nice explanation of BOM files, see Baeldungs blog post
> [1].
>
> 
> 4.0.0
> baeldung
> Test
> 0.0.1-SNAPSHOT
> pom
> Test
>
> 
> 
> 
> com.fasterxml.jackson
> jackson-bom
> 2.13.5
> pom
> import
> 
> 
> 
> 
>
>
> [1] https://www.baeldung.com/spring-maven-bom
> 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 Sat, 29 Jul 2023 at 01:29, David Karr 
> wrote:
>
> > In general, I know how to override transient artifact versions. You add
> an
> > "exclusion" for the artifact on the dependency that is including that
> > dependency, and then you manually add that dependency in the same pom
> where
> > you added the exclusion.  In my case, the version I want is defined in a
> > bom in our parent pom, so I don't have to specify the version in that
> > dependency.
> >
> > This works fine, if I do this exclusion and inclusion in the overall
> "child
> > pom".
> >
> > However, I maintain the parent pom and platform, and there will be dozens
> > of "child poms" that will need to do this.  I would much rather do this
> > "fixup" in the poms for the libraries in our platform.  Those poms
> specify
> > the dependencies whose versions I need to control.
> >
> > I've been struggling with trying to do this, along with trying to
> > understand the output of "mvn dependency:tree" and the apparently
> > functionally similar output in the "Dependency Hierarchy" view in Eclipse
> > using the m2e plugin.  Although I can loosely see the hierarchical output
> > from these, I find determining the actual details of where dependencies
> are
> > coming from is very mystifying.
> >
> > To get down to actual details, my problem is that I'm ending up with
> > different versions of "jackson-core" and "jackson-databind".  I need to
> > ensure that I have the same versions of both.  I am getting v2.14.1 of
> > jackson-databind and v2.13.5 of jackson-core.  We are specifying v2.13.5
> in
> > our parent pom, but somehow something in the tree is giving us v2.14.1 of
> > jackson-databind.
> >
> > I'm going to include here a small excerpt of the "dependency:tree" output
> > for our child pom:
> >
> >  com.att.idp:RiskAssessmentMS:jar:2.8.0
> > +- com.att.idp:idp-seed-sdk-core:jar:2.8.0:compile
> > +- org.jasypt:jasypt:jar:1.9.3:compile
> > +- com.io7m.xom:xom:jar:1.2.10:compile
> > +- com.att.idp:idp-health:jar:2.8.0:compile
> > |  +- org.springframework.boot:spring-boot-actuator:jar:2.7.5:compile
> > |  +- com.att.idp:idp-logging-core:jar:2.8.0:compile (version selected
> from
> > constraint [2.8.0,2.8.100))
> > |  |  \- ch.qos.logback:logback-core:jar:1.2.9:compile
> > |  +- redis.clients:jedis:jar:3.8.0:compile
> > |  |  \- org.apache.commons:commons-pool2:jar:2.11.1:compile
> > |  +- com.github.fppt:jedis-mock:jar:0.1.23:compile
> > |  |  \- com.google.auto.value:auto-value-annotations:jar:1.6.2:compile
> > |  \- com.att.idp.voltage:vibesimplejava:jar:6.21.0.0:compile
> > +- com.fasterxml.jackson.core:jackson-core:jar:2.13.4:compile
> > +- com.fasterxml.jackson.core:jackson-databind:jar:2.14.1:compile
> >
> > The "idp-health" library is one of our wrapper libraries.  That specifies
> > dependencies that pull in jackson-databind, and in those dependencies I
> > have excluded jackson-databind and included a specific dependency for
> > jackson-databind. As the bom imported from the parent pom specifies
> v2.13.5
> > for that, I would expect I would get jackson-databind v2.13.5, but I'm
> > still getting v2.14.1.
> >
> > I'm very confused.
> >
> > I think I remember seeing discussions in the dev list about improving the
> > output of dependency:tree to be clearer, I don't know if there's been any
> > progress on that.
> >
>

Confused about how to override a transient artifact version

[David Karr]

In general, I know how to override transient artifact versions. You add an
"exclusion" for the artifact on the dependency that is including that
dependency, and then you manually add that dependency in the same pom where
you added the exclusion.  In my case, the version I want is defined in a
bom in our parent pom, so I don't have to specify the version in that
dependency.

This works fine, if I do this exclusion and inclusion in the overall "child
pom".

However, I maintain the parent pom and platform, and there will be dozens
of "child poms" that will need to do this.  I would much rather do this
"fixup" in the poms for the libraries in our platform.  Those poms specify
the dependencies whose versions I need to control.

I've been struggling with trying to do this, along with trying to
understand the output of "mvn dependency:tree" and the apparently
functionally similar output in the "Dependency Hierarchy" view in Eclipse
using the m2e plugin.  Although I can loosely see the hierarchical output
from these, I find determining the actual details of where dependencies are
coming from is very mystifying.

To get down to actual details, my problem is that I'm ending up with
different versions of "jackson-core" and "jackson-databind".  I need to
ensure that I have the same versions of both.  I am getting v2.14.1 of
jackson-databind and v2.13.5 of jackson-core.  We are specifying v2.13.5 in
our parent pom, but somehow something in the tree is giving us v2.14.1 of
jackson-databind.

I'm going to include here a small excerpt of the "dependency:tree" output
for our child pom:

 com.att.idp:RiskAssessmentMS:jar:2.8.0
+- com.att.idp:idp-seed-sdk-core:jar:2.8.0:compile
+- org.jasypt:jasypt:jar:1.9.3:compile
+- com.io7m.xom:xom:jar:1.2.10:compile
+- com.att.idp:idp-health:jar:2.8.0:compile
|  +- org.springframework.boot:spring-boot-actuator:jar:2.7.5:compile
|  +- com.att.idp:idp-logging-core:jar:2.8.0:compile (version selected from
constraint [2.8.0,2.8.100))
|  |  \- ch.qos.logback:logback-core:jar:1.2.9:compile
|  +- redis.clients:jedis:jar:3.8.0:compile
|  |  \- org.apache.commons:commons-pool2:jar:2.11.1:compile
|  +- com.github.fppt:jedis-mock:jar:0.1.23:compile
|  |  \- com.google.auto.value:auto-value-annotations:jar:1.6.2:compile
|  \- com.att.idp.voltage:vibesimplejava:jar:6.21.0.0:compile
+- com.fasterxml.jackson.core:jackson-core:jar:2.13.4:compile
+- com.fasterxml.jackson.core:jackson-databind:jar:2.14.1:compile

The "idp-health" library is one of our wrapper libraries.  That specifies
dependencies that pull in jackson-databind, and in those dependencies I
have excluded jackson-databind and included a specific dependency for
jackson-databind. As the bom imported from the parent pom specifies v2.13.5
for that, I would expect I would get jackson-databind v2.13.5, but I'm
still getting v2.14.1.

I'm very confused.

I think I remember seeing discussions in the dev list about improving the
output of dependency:tree to be clearer, I don't know if there's been any
progress on that.

Maven build error

[Willfin David]

Hi,

Im using maven as part of my mulesoft anytime studio platform.
When I run the below command from command prompt I get the error below.

Let me know how to resolve this error.

Command:
maven -U clean install

Error:
[ERROR] Failed to execute goal on project mule-connectivity-parent: Could not 
resolve dependencies for project 
com.mulesoft.connectors:mule-connectivity-parent:pom:3.3.1-RUNTIME.4.2.1: 
Failed to collect dependencies at 
org.mule.tests.plugin:mule-tests-component-plugin:jar:mule-plugin:4.2.1: Failed 
to read artifact descriptor for 
org.mule.tests.plugin:mule-tests-component-plugin:jar:mule-plugin:4.2.1: The 
following artifacts could not be resolved: org.mule.tests:mule-tests:pom:4.2.1 
(absent): Could not find artifact org.mule.tests:mule-tests:pom:4.2.1 in 
mule-releases 
(https://repository-master.mulesoft.org/nexus/content/repositories/releases/) 
-> [Help 1]


[cid:image001.jpg@01D9C0DC.1D8F02B0]



___
The information contained in this communication is intended solely for the use 
of the individual or entity to whom it is addressed and others authorized to 
receive it. It may contain confidential or legally privileged information. If 
you are not the intended recipient you are hereby notified that any disclosure, 
copying, distribution or taking any action in reliance on the contents of this 
information is strictly prohibited and may be unlawful. If you have received 
this communication in error, please notify us immediately by responding to this 
email and then delete it from your system. EY is neither liable for the proper 
and complete transmission of the information contained in this communication 
nor for any delay in its receipt.

[ANN] native2ascii-maven-plugin 2.1.0 Released

[David Matějček]

Hi,

The MojoHaus team is pleased to announce the release of the 
native2ascii-maven-plugin version 2.1.0.

The plugin converts files with characters in any supported character encoding 
to one with ASCII and/or Unicode escapes.

https://github.com/mojohaus/native2ascii-maven-plugin

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


    org.codehaus.mojo
native2ascii-maven-plugin
    2.1.0


See https://github.com/mojohaus/native2ascii-maven-plugin/releases/tag/v2.1.0 
for the Release Notes.

Enjoy,

The MojoHaus team.

--
David Matějček

How to get Maven to give me ALL the dependency errors, instead of just the first one

[David Karr]

We have a situation in our build environment where Maven concludes it can't
get certain artifacts, resulting in a build failure message like this:

[ERROR] Failed to execute goal on project ..: Could not resolve
dependencies for project ...:jar:1.1.0-SNAPSHOT: The following
artifacts could not be resolved: ...: Could not find artifact ... ->
[Help 1]


The problem happens to be a corruption of the artifact on the local maven
repo on the build node (the jar file fails to download for some reason).

We are working on a robust solution to prevent these, but right now each
one of these incidents is resolved by purging that particular artifact on
the particular build node and letting the build rerun.

The problem is (among others) is that when this happens, it almost always
happens with more than one artifact.  As a result, when I run the build
after the offending artifact is purged, it only shows me the next artifact
it fails on. This goes on for several iterations before it finally works
again.

What I want to know is whether there is any way to tell "mvn" to give me
ALL of these errors at once, instead of stopping the build at the first one.

Is this what "--fail-at-end" would do for me, or would that have other
unintended consequences?

Questions about frequency of "Progress" log lines while downloading artifacts

[David Karr]

We're looking at performance issues with the intranet repository in our
enterprise.  I was looking at some Maven build output while downloading
artifacts, and I wanted to be clear on exactly what is indicated by some
output while downloading artifacts.

Here is a somewhat elided block of build output:
-
Downloading from nexus: https://
:8443/nexus/content/groups//org/apache/commons/commons-lang3/3.7/commons-lang3-3.7.jar
Downloaded from nexus:
https://:8443/nexus/content/groups//com/google/guava/guava/28.2-android/guava-28.2-android.jar
(2.6 MB at 1.2 MB/s)
Downloaded from nexus:
https://:8443/nexus/content/groups//org/checkerframework/checker-compat-qual/2.5.5/checker-compat-qual-2.5.5.jar
(5.9 kB at 2.7 kB/s)
Downloaded from nexus:
https://:8443/nexus/content/groups//com/google/guava/listenablefuture/.0-empty-to-avoid-conflict-with-guava/listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar
(2.2 kB at 994 B/s)
Progress (2): 8.8 kB | 4.1/500 kB

Downloaded from nexus:
https://:8443/nexus/content/groups//com/google/j2objc/j2objc-annotations/1.3/j2objc-annotations-1.3.jar
(8.8 kB at 3.9 kB/s)
Progress (1): 7.5/500 kB
Progress (1): 12/500 kB
Progress (1): 16/500 kB
... couple hundred similar lines deleted ...
Progress (1): 496/500 kB
Progress (1): 500 kB

Downloaded from nexus:
https://:8443/nexus/content/groups//org/apache/commons/commons-lang3/3.7/commons-lang3-3.7.jar
(500 kB at 210 kB/s)
---

As an example, I'm focusing on the download of the commons-lang3-3.7.jar
artifact.  The file size was 500kb. The output shows "Progress" lines,
about every 4 kb (about 125 of them). At the end, it said that the
resulting download speed for that artifact was 210 kb/s.

In the code that prints these "Progress" log lines, does it print that
every N time periods?  If that download rate is accurate, it should have
taken just over 2 seconds.  I think it's taking much longer than that.

Can anyone give me any background on this?

How to configure Maven for an overloaded intranet repository?

[David Karr]

I work in a very large enterprise that uses a centralized intranet maven
repository to get artifacts from.  It often has load issues that result in
builds failing with "failed to respond".  The team that maintains it is
working towards eventual mitigations for that, but it will be quite a while
before that actually happens.

What knobs or dials can I get to to make the connection to the remote
repository more resilient?  The error "failed to respond" sounds like a
connection timeout, not a read timeout, but I can't tell. What property
values can I override that would help here?

RE: JUnit 5 test suites not running again

[KARR, DAVID]

I'd still appreciate more elaboration on your comments, but I guess what I'm 
going to attempt is to add exclusions in my parent pom for ALL of the 
junit-platform and junit-jupiter artifacts (because the spring starter 
artifacts include all of those) and then iteratively test removing the 
exclusions for only "junit-platform-suite-engine" and "junit-jupiter-engine" 
and see what doesn't work.

Note that our use cases are more complicated than that simple example.  We have 
to support both Junit 5 and Junit 4 mixed tests at this time.  That will 
definitely mean the junit-vintage-engine" will have to be included.

> -----Original Message-
> From: KARR, DAVID 
> Sent: Friday, July 8, 2022 4:59 PM
> To: Maven Users List ; i...@soebes.de; David
> Karr 
> Subject: RE: JUnit 5 test suites not running again
> 
> Inline.
> 
> > -Original Message-
> > From: Karl Heinz Marbaise 
> > Sent: Friday, July 8, 2022 9:21 AM
> > To: David Karr ; i...@soebes.de
> > Cc: Maven Users List 
> > Subject: Re: JUnit 5 test suites not running again
> >
> > On 08.07.22 18:09, David Karr wrote:
> > > Inline.
> > >
> > > On Fri, Jul 8, 2022 at 8:17 AM Karl Heinz Marbaise
> > > mailto:khmarba...@gmx.de>> wrote:
> > >
> > > Hi,
> > >
> > > On 08.07.22 16:18, David Karr wrote:
> > >  > I had gotten help here with our JUnit 5 transition, and I
> > thought
> > > I had it
> > >  > all working, but now I see that I'm back to the state where
> our
> > > JUnit 5
> > >  > test suites are being ignored.
> > >  >
> > >  >>From what I understood, I had to ensure that
> > > "junit-platform-runner" was
> > >  > excluded as a dependency.  What I have seems to have done
> this,
> > > but only
> > >  > halfway.  The "dependency-tree" doesn't have that artifact.
> > > However, when
> > >  > I generated the effective pom, I DID see that artifact. I'm
> not
> > > sure what
> > >  > that means.
> > >  >
> > >  > I run this command line:
> > >  >
> > >  >      mvn -U -Dtest=ComponentTestSuite test
> > >  >
> > >  > Here's an excerpt of the output:
> > >  > --
> > >  > [INFO] --- maven-surefire-plugin:3.0.0-M7:test (default-test)
> @
> > >  > PlatformPilotMs ---
> > >  > [INFO] Using auto detected provider
> > >  > org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> > >  > [INFO]
> > >  > [INFO] --
> -
> > >  > [INFO]  T E S T S
> > >  > [INFO] --
> -
> > >  > [INFO]
> > >  > [INFO] Results:
> > >  > [INFO]
> > >  > [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> > >  > --
> > >  >
> > >  > As you can see, I'm using v3.0.0-M7 of Surefire. I'm using
> > v1.8.2 of
> > >  > junit-platform, and v5.8.2 of junit-jupiter.
> > >  >
> > >  > I've designed a parent pom hierarchy that looks like this:
> > >  >
> > >  > sdk-java-parent:
> > >  >    dependencyManagement includes "ext-bom" pom with scope
> > "import"
> > >  >    dependencies has a block like this:
> > >  > --
> > >  > 
> > >  >       ...
> > >  >       seed-sdk-core
> > >  >              
> > >  >                  
> > >  >                      org.junit.platform
> > >  >                      junit-platform-
> > runner
> > >  >                  
> > >  >              
> > >  >      
> > >  > --
> > >  >
> > >  > The effective pom also has this:
> > >  > --
> > >  > 
> > >  >      org.apache.maven.plugins
> > >  >      maven-surefire-plugin
> > >  >      3.0.0-M7
> > >  >      
> > >  >                      1
> > >  >                      false
> > > 

RE: JUnit 5 test suites not running again

[KARR, DAVID]

Inline.

> -Original Message-
> From: Karl Heinz Marbaise 
> Sent: Friday, July 8, 2022 9:21 AM
> To: David Karr ; i...@soebes.de
> Cc: Maven Users List 
> Subject: Re: JUnit 5 test suites not running again
> 
> On 08.07.22 18:09, David Karr wrote:
> > Inline.
> >
> > On Fri, Jul 8, 2022 at 8:17 AM Karl Heinz Marbaise  > <mailto:khmarba...@gmx.de>> wrote:
> >
> > Hi,
> >
> > On 08.07.22 16:18, David Karr wrote:
> >  > I had gotten help here with our JUnit 5 transition, and I
> thought
> > I had it
> >  > all working, but now I see that I'm back to the state where our
> > JUnit 5
> >  > test suites are being ignored.
> >  >
> >  >>From what I understood, I had to ensure that
> > "junit-platform-runner" was
> >  > excluded as a dependency.  What I have seems to have done this,
> > but only
> >  > halfway.  The "dependency-tree" doesn't have that artifact.
> > However, when
> >  > I generated the effective pom, I DID see that artifact. I'm not
> > sure what
> >  > that means.
> >  >
> >  > I run this command line:
> >  >
> >  >      mvn -U -Dtest=ComponentTestSuite test
> >  >
> >  > Here's an excerpt of the output:
> >  > --
> >  > [INFO] --- maven-surefire-plugin:3.0.0-M7:test (default-test) @
> >  > PlatformPilotMs ---
> >  > [INFO] Using auto detected provider
> >  > org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> >  > [INFO]
> >  > [INFO] ---
> >  > [INFO]  T E S T S
> >  > [INFO] ---
> >  > [INFO]
> >  > [INFO] Results:
> >  > [INFO]
> >  > [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> >  > --
> >  >
> >  > As you can see, I'm using v3.0.0-M7 of Surefire. I'm using
> v1.8.2 of
> >  > junit-platform, and v5.8.2 of junit-jupiter.
> >  >
> >  > I've designed a parent pom hierarchy that looks like this:
> >  >
> >  > sdk-java-parent:
> >  >    dependencyManagement includes "ext-bom" pom with scope
> "import"
> >  >    dependencies has a block like this:
> >  > --
> >  > 
> >  >       ...
> >  >       seed-sdk-core
> >  >              
> >  >                  
> >  >                      org.junit.platform
> >  >                      junit-platform-
> runner
> >  >                  
> >  >              
> >  >      
> >  > --
> >  >
> >  > The effective pom also has this:
> >  > --
> >  > 
> >  >      org.apache.maven.plugins
> >  >      maven-surefire-plugin
> >  >      3.0.0-M7
> >  >      
> >  >                      1
> >  >                      false
> >  >
> >  > true
> >  >      ${surefireArgLine}
> >  >      false
> >  >      
> >  >          **/contract/*.java
> >  >          **/integration/*.java
> >  >          **/component/*.java
> >  >      
> >  >      
> >  > 
> >  > ---
> >  >
> >  > What could we be missing?
> >  >
> >
> >
> > Which dependencies do you have defined for running junit jupiter
> tests?
> >
> >
> > These are the resulting junit-jupiter dependencies in the effective
> pom:
> >
> >          junit-jupiter
> >          junit-jupiter-api
> >          junit-jupiter-engine
> >          junit-jupiter-migrationsupport
> >          junit-jupiter-params
> 
> 
> Migrationsupport means JUnit 4... not JUnit Jupiter..

Can you please say a little more about this?  How am I supposed to interpret 
this statement?

Note that I’m not including these dependencies explicitly.  I'm just including 
spring-boot-starter-test as a dependency, and I believe that is specifying all 
of the junit-platform and junit-jupiter dependencies.

> Check the example:
> 
> https://urldefense.com/v3/

Re: JUnit 5 test suites not running again

[David Karr]

Inline.

On Fri, Jul 8, 2022 at 8:17 AM Karl Heinz Marbaise 
wrote:

> Hi,
>
> On 08.07.22 16:18, David Karr wrote:
> > I had gotten help here with our JUnit 5 transition, and I thought I had
> it
> > all working, but now I see that I'm back to the state where our JUnit 5
> > test suites are being ignored.
> >
> >>From what I understood, I had to ensure that "junit-platform-runner" was
> > excluded as a dependency.  What I have seems to have done this, but only
> > halfway.  The "dependency-tree" doesn't have that artifact.  However,
> when
> > I generated the effective pom, I DID see that artifact. I'm not sure what
> > that means.
> >
> > I run this command line:
> >
> >  mvn -U -Dtest=ComponentTestSuite test
> >
> > Here's an excerpt of the output:
> > --
> > [INFO] --- maven-surefire-plugin:3.0.0-M7:test (default-test) @
> > PlatformPilotMs ---
> > [INFO] Using auto detected provider
> > org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> > [INFO]
> > [INFO] ---
> > [INFO]  T E S T S
> > [INFO] ---
> > [INFO]
> > [INFO] Results:
> > [INFO]
> > [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> > --
> >
> > As you can see, I'm using v3.0.0-M7 of Surefire. I'm using v1.8.2 of
> > junit-platform, and v5.8.2 of junit-jupiter.
> >
> > I've designed a parent pom hierarchy that looks like this:
> >
> > sdk-java-parent:
> >dependencyManagement includes "ext-bom" pom with scope "import"
> >dependencies has a block like this:
> > --
> > 
> >   ...
> >   seed-sdk-core
> >  
> >  
> >  org.junit.platform
> >  junit-platform-runner
> >  
> >  
> >  
> > --
> >
> > The effective pom also has this:
> > --
> > 
> >  org.apache.maven.plugins
> >  maven-surefire-plugin
> >  3.0.0-M7
> >  
> >  1
> >  false
> >
> > true
> >  ${surefireArgLine}
> >  false
> >  
> >  **/contract/*.java
> >  **/integration/*.java
> >  **/component/*.java
> >  
> >  
> > 
> > ---
> >
> > What could we be missing?
> >
>
>
> Which dependencies do you have defined for running junit jupiter tests?
>

These are the resulting junit-jupiter dependencies in the effective pom:

junit-jupiter
junit-jupiter-api
junit-jupiter-engine
junit-jupiter-migrationsupport
junit-jupiter-params

And these are the resulting junit-platform dependencies (still not sure why
junit-platform-runner is in here, when I'm excluding it AND it doesn't
appear in dependency:tree):

junit-platform-commons
junit-platform-console
junit-platform-engine
junit-platform-jfr
junit-platform-launcher
junit-platform-reporting
junit-platform-runner
junit-platform-suite
junit-platform-suite-api
junit-platform-suite-commons
junit-platform-suite-engine
junit-platform-testkit

>
> Why do you think you need to exclude junit jupiter runner?
>

Not jupiter, but "junit-platform-runner". Looking at the message history, I
see that "Slawomir Jaranowski" at least, had said this.


> Do you use the dependency junit-jupiter-engine as a dependency:
>
> Are you using @Suite annotation of JUnit Jupiter?
>
> Have you defined a class for example `ComponentTestSuite` like this:
>
> @Suite
> @SelectPackages("package.xxx")
> @IncludeClassNamePatterns(".*Pattern")
> class SuiteDemoTests {
>
> }..
>

This is an excerpt of my test suite:

import org.junit.platform.suite.api.SelectClasses;
import org.junit.platform.suite.api.Suite;

@Suite
@SelectClasses({...
--

>
>
> If you like to run suites you have to have two dependencies:
>
>  
>org.junit.platform
>junit-platform-suite-engine
>test
>  
>  
>org.junit.jupiter
>junit-jupiter-engine
>test
>  
>
>
> Kind regards
> Karl Heinz Marbaise
>

JUnit 5 test suites not running again

[David Karr]

I had gotten help here with our JUnit 5 transition, and I thought I had it
all working, but now I see that I'm back to the state where our JUnit 5
test suites are being ignored.

>From what I understood, I had to ensure that "junit-platform-runner" was
excluded as a dependency.  What I have seems to have done this, but only
halfway.  The "dependency-tree" doesn't have that artifact.  However, when
I generated the effective pom, I DID see that artifact. I'm not sure what
that means.

I run this command line:

mvn -U -Dtest=ComponentTestSuite test

Here's an excerpt of the output:
--
[INFO] --- maven-surefire-plugin:3.0.0-M7:test (default-test) @
PlatformPilotMs ---
[INFO] Using auto detected provider
org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
[INFO]
[INFO] ---
[INFO]  T E S T S
[INFO] ---
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
--

As you can see, I'm using v3.0.0-M7 of Surefire. I'm using v1.8.2 of
junit-platform, and v5.8.2 of junit-jupiter.

I've designed a parent pom hierarchy that looks like this:

sdk-java-parent:
  dependencyManagement includes "ext-bom" pom with scope "import"
  dependencies has a block like this:
--

 ...
 seed-sdk-core


org.junit.platform
junit-platform-runner



--

The effective pom also has this:
--

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

1
false

true
${surefireArgLine}
false

**/contract/*.java
**/integration/*.java
**/component/*.java



---

What could we be missing?

Re: How to properly override junit-platform and junit-jupiter in a parent pom

[David Karr]

On Sat, Jun 18, 2022 at 4:17 PM Nils Breunese  wrote:

> David Karr  wrote:
>
> > We have a bunch of services running Spring Boot 2.3.12, which by default
> > uses junit-platform 1.6.3 and junit-jupiter 5.6.3.
> >
> > We are trying to instead use junit-platform 1.8.2 and junit-jupiter
> 5.8.2.
> > All the artifacts and versions we need are in junit-bom-5.8.2.
> >
> > We want to control this in our parent pom(s), as we have dozens of
> similar
> > services all using the same parent pom.
>
> Spring Boot dependencies for version 2.3.12.RELEASE (
> https://search.maven.org/artifact/org.springframework.boot/spring-boot-dependencies/2.3.12.RELEASE/pom)
> sets the junit-jupiter.version property to 5.6.3, but you can override that
> property in your own project.
>
> I would consider upgrading to a more recent version of Spring Boot,
> because 2.3.x reached end of OSS support on May 20, 2021 (
> https://spring.io/projects/spring-boot#support). Spring Boot 2.7.0 (
> https://search.maven.org/artifact/org.springframework.boot/spring-boot-dependencies/2.7.0/pom)
> comes with JUnit Jupiter 5.8.2 by default.
>

Yup, I'm aware of all that.  We have a large number of services running our
internal platform.  It takes us a while to implement an upgrade.  We
started planning for it a couple of weeks ago, and it will take quite a
while to move everything.

Re: Surefire not running JUnit 5 tests after fixing how junit-bom artifacts are specified

[David Karr]

In my case, it appears that all I had to do after adding the correct
junit-bom version import before the import of the
"spring-boot-dependencies" bom was figure out where to exclude
junit-platform-runner. I can see where the junit-{platform,jupiter}
dependencies are in the tree, but it's a little harder to tell what bom
they came from (is that one of the points about a recent discussion about
improvements to dependency:tree?)

On Sat, Jun 18, 2022 at 3:03 AM Karl Heinz Marbaise 
wrote:

> Hi,
>
>
> On 17.06.22 20:46, David Karr wrote:
> > Ok, what is the proper way to do that, considering I have the following
> in
> > a bom imported by my parent pom:
> > 
> >  
> >  org.junit
> >  junit-bom
> >  import
> >  pom
> >  5.8.2
> >  
> >  
> >  
> >org.springframework.boot
> >spring-boot-dependencies
> >${spring-boot.version}
> >pom
> >import
> >  
> > 
> > Do I add an exclusion to one or both of these?
>
>
> This is to have the available dependencies.
> You have to add junit-jupiter-engine
>
> like this (not inside dependencyManagement):
>
>
>  
>  
>  org.junit.jupiter
>  junit-jupiter-engine
>  test
>  
>  
>  org.springframework.boot
>  spring-boot-starter-test
>  test
>  
>
>
> If you have a mix of JUNit 4 and JUnit 5 you have to go this way:
>
>  
>  
>  org.junit.jupiter
>  junit-jupiter-engine
>  test
>  
>  
>  org.junit.vintage
>  junit-vintage-engine
>  test
>  
>  
>  org.springframework.boot
>  spring-boot-starter-test
>  test
>  
>
> The vintage-engine is responsible for executing the JUnit 4 tests.
>
>
> I have made an simple example with Spring Boot using JUnit 4 and JUnit 5.
>
> Also added exemplary integration tests where one is JUnit 4 based and
> one JUnit 5 based.
>
> https://github.com/khmarbaise/minimal-junit4-junit5
>
>
> Furthermore you shouldn't define the provider for surefire explicit
> because it's identifying it itself. (In the given example I have not
> defined the provider).
>
>
> Kind regards
> Karl Heinz Marbaise
> >
> > On Fri, Jun 17, 2022 at 11:37 AM Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> > wrote:
> >
> >> Do you have on your classpath - junit-platform-runner?
> >> Please remove it.
> >>
> >>
> >> pt., 17 cze 2022 o 20:23 David Karr 
> >> napisał(a):
> >>
> >>> I'm posting a new note, as this might be a different issue.
> >>>
> >>> I recently got good advice on this list about how to properly specify
> the
> >>> version overrides for the junit-bom artifacts.  When I implemented
> that,
> >> I
> >>> saw that I was consistently getting the correct versions for those
> >>> artifacts.
> >>>
> >>> However, I'm now confused by the behavior that I'm seeing from
> >> Surefire.  I
> >>> currently have a mix of JUnit 4 and JUnit 5 tests.  I'm pretty sure
> that
> >> I
> >>> had this working before, but now I see that it is not running any of
> the
> >>> JUnit 5 tests.
> >>>
> >>> Note the following excerpt from my build:
> >>> ---
> >>> [INFO] --- maven-surefire-plugin:3.0.0-M7:test (default-test) @
> >>> PlatformPilotMs ---
> >>> [INFO] Using auto detected provider
> >>> org.apache.maven.surefire.junit4.JUnit4Provider
> >>> --
> >>>
> >>> I'm using the very latest M version, as that resolves other issues
> we've
> >>> been having. When I look to see what tests were executed, I see that it
> >>> doesn't include any of my JUnit 5 tests.
> >>>
> >>> I ran "mvn dependency:tree" to verify what versions of JUnit are in the
> >>> classpath, and it has BOTH JUnit 4.13 and junit-platform 1.8.2 and
> >>> junit-jupiter 5.8.2.  The surefire doc page says "Surefire normally
> >>> automatically selects which test-framework provider to use based on the
> >>> version of TestNG/JUnit present in your project's classpath". Is the
> fact
> >>> that both are in the classpath causing this? Am I going to have to
> >> manually
> >>> specify both the junit 4 and junit 5 providers in the surefire
> >>> dependencies? That is additionally annoying as I also have to
> redundantly
> >>> specify the versions of those artifacts (I tried not specifying a
> >> version,
> >>> and it complained).
> >>>
> >>
> >>
> >> --
> >> Sławomir Jaranowski
> >>
> >
>
>

Re: Surefire not running JUnit 5 tests after fixing how junit-bom artifacts are specified

[David Karr]

Never mind, I think I figured this out.  I had two "parent" artifacts with
similar names, and I ran the build in the wrong one. It's still a bit
confusing where the exclusion has to go, but I now have a single exclusion
for junit-platform-runner, in the parent pom, so I don't have to do this in
each service pom.

On Fri, Jun 17, 2022 at 12:26 PM David Karr 
wrote:

> Ok, so the tree has output like this:
> --
> [INFO] +- com.att.idp:idp-seed-sdk-core:jar:2.7.0-SNAPSHOT:compile
> [INFO] |  +- org.junit.jupiter:junit-jupiter-api:jar:5.8.2:compile
> [INFO] |  |  +- org.opentest4j:opentest4j:jar:1.2.0:compile
> [INFO] |  |  \- org.apiguardian:apiguardian-api:jar:1.1.2:compile
> [INFO] |  +- org.junit.jupiter:junit-jupiter-engine:jar:5.8.2:compile
> [INFO] |  +-
> org.junit.jupiter:junit-jupiter-migrationsupport:jar:5.8.2:compile
> [INFO] |  +- org.junit.jupiter:junit-jupiter-params:jar:5.8.2:compile
> [INFO] |  +- org.junit.platform:junit-platform-commons:jar:1.8.2:compile
> [INFO] |  +- org.junit.platform:junit-platform-console:jar:1.8.2:compile
> [INFO] |  +- org.junit.platform:junit-platform-engine:jar:1.8.2:compile
> [INFO] |  +- org.junit.platform:junit-platform-jfr:jar:1.8.2:compile
> [INFO] |  +- org.junit.platform:junit-platform-launcher:jar:1.8.2:compile
> [INFO] |  +- org.junit.platform:junit-platform-reporting:jar:1.8.2:compile
> [INFO] |  +- org.junit.platform:junit-platform-runner:jar:1.8.2:compile
> [INFO] |  +- org.junit.platform:junit-platform-suite:jar:1.8.2:compile
> [INFO] |  +- org.junit.platform:junit-platform-suite-api:jar:1.8.2:compile
> [INFO] |  +-
> org.junit.platform:junit-platform-suite-commons:jar:1.8.2:compile
> [INFO] |  +-
> org.junit.platform:junit-platform-suite-engine:jar:1.8.2:compile
> [INFO] |  +- org.junit.platform:junit-platform-testkit:jar:1.8.2:compile
> [INFO] |  \- org.junit.vintage:junit-vintage-engine:jar:5.8.2:compile
> -
> It's a little hard to see with a proportional font, but the top line there
> is the artifact that references it.  In my parent pom, where this artifact
> is specified, I did the following:
> -
> 
> com.att.idp
> idp-seed-sdk-core
> 
> 
> org.junit.platform
> junit-platform-runner
> 
> 
> 
> 
>
> This made no difference.
>
> The only thing that makes this do what it needs to do is adding the
> "surefire-junit-platform" dependency to the surefire plugin, but I have to
> do that in every service that uses that parent pom. This is the only change
> that runs both the JUnit 4 and JUnit 5 tests.
>
> On Fri, Jun 17, 2022 at 12:13 PM Slawomir Jaranowski <
> s.jaranow...@gmail.com> wrote:
>
>> Import scope only sets versions of dependency - not add it to dependency.
>>
>> Please examine output of dependency:tree and look where is added
>> junit-platform-runner
>>
>> pt., 17 cze 2022 o 20:47 David Karr 
>> napisał(a):
>>
>> > Ok, what is the proper way to do that, considering I have the following
>> in
>> > a bom imported by my parent pom:
>> > 
>> > 
>> > org.junit
>> > junit-bom
>> > import
>> > pom
>> > 5.8.2
>> > 
>> > 
>> > 
>> >   org.springframework.boot
>> >   spring-boot-dependencies
>> >   ${spring-boot.version}
>> >   pom
>> >   import
>> > 
>> > 
>> > Do I add an exclusion to one or both of these?
>> >
>> > On Fri, Jun 17, 2022 at 11:37 AM Slawomir Jaranowski <
>> > s.jaranow...@gmail.com>
>> > wrote:
>> >
>> > > Do you have on your classpath - junit-platform-runner?
>> > > Please remove it.
>> > >
>> > >
>> > > pt., 17 cze 2022 o 20:23 David Karr 
>> > > napisał(a):
>> > >
>> > > > I'm posting a new note, as this might be a different issue.
>> > > >
>> > > > I recently got good advice on this list about how to properly
>> specify
>> > the
>> > > > version overrides for the junit-bom artifacts.  When I implemented
>> > that,
>> > > I
>> > > > saw that I was consistently getting the correct versions for those
>> > > > artifacts.
>> 

Re: Surefire not running JUnit 5 tests after fixing how junit-bom artifacts are specified

[David Karr]

Ok, so the tree has output like this:
--
[INFO] +- com.att.idp:idp-seed-sdk-core:jar:2.7.0-SNAPSHOT:compile
[INFO] |  +- org.junit.jupiter:junit-jupiter-api:jar:5.8.2:compile
[INFO] |  |  +- org.opentest4j:opentest4j:jar:1.2.0:compile
[INFO] |  |  \- org.apiguardian:apiguardian-api:jar:1.1.2:compile
[INFO] |  +- org.junit.jupiter:junit-jupiter-engine:jar:5.8.2:compile
[INFO] |  +-
org.junit.jupiter:junit-jupiter-migrationsupport:jar:5.8.2:compile
[INFO] |  +- org.junit.jupiter:junit-jupiter-params:jar:5.8.2:compile
[INFO] |  +- org.junit.platform:junit-platform-commons:jar:1.8.2:compile
[INFO] |  +- org.junit.platform:junit-platform-console:jar:1.8.2:compile
[INFO] |  +- org.junit.platform:junit-platform-engine:jar:1.8.2:compile
[INFO] |  +- org.junit.platform:junit-platform-jfr:jar:1.8.2:compile
[INFO] |  +- org.junit.platform:junit-platform-launcher:jar:1.8.2:compile
[INFO] |  +- org.junit.platform:junit-platform-reporting:jar:1.8.2:compile
[INFO] |  +- org.junit.platform:junit-platform-runner:jar:1.8.2:compile
[INFO] |  +- org.junit.platform:junit-platform-suite:jar:1.8.2:compile
[INFO] |  +- org.junit.platform:junit-platform-suite-api:jar:1.8.2:compile
[INFO] |  +-
org.junit.platform:junit-platform-suite-commons:jar:1.8.2:compile
[INFO] |  +-
org.junit.platform:junit-platform-suite-engine:jar:1.8.2:compile
[INFO] |  +- org.junit.platform:junit-platform-testkit:jar:1.8.2:compile
[INFO] |  \- org.junit.vintage:junit-vintage-engine:jar:5.8.2:compile
-
It's a little hard to see with a proportional font, but the top line there
is the artifact that references it.  In my parent pom, where this artifact
is specified, I did the following:
-

com.att.idp
idp-seed-sdk-core


org.junit.platform
junit-platform-runner





This made no difference.

The only thing that makes this do what it needs to do is adding the
"surefire-junit-platform" dependency to the surefire plugin, but I have to
do that in every service that uses that parent pom. This is the only change
that runs both the JUnit 4 and JUnit 5 tests.

On Fri, Jun 17, 2022 at 12:13 PM Slawomir Jaranowski 
wrote:

> Import scope only sets versions of dependency - not add it to dependency.
>
> Please examine output of dependency:tree and look where is added
> junit-platform-runner
>
> pt., 17 cze 2022 o 20:47 David Karr 
> napisał(a):
>
> > Ok, what is the proper way to do that, considering I have the following
> in
> > a bom imported by my parent pom:
> > 
> > 
> > org.junit
> > junit-bom
> > import
> > pom
> > 5.8.2
> > 
> > 
> > 
> >   org.springframework.boot
> >   spring-boot-dependencies
> >   ${spring-boot.version}
> >   pom
> >   import
> > 
> > 
> > Do I add an exclusion to one or both of these?
> >
> > On Fri, Jun 17, 2022 at 11:37 AM Slawomir Jaranowski <
> > s.jaranow...@gmail.com>
> > wrote:
> >
> > > Do you have on your classpath - junit-platform-runner?
> > > Please remove it.
> > >
> > >
> > > pt., 17 cze 2022 o 20:23 David Karr 
> > > napisał(a):
> > >
> > > > I'm posting a new note, as this might be a different issue.
> > > >
> > > > I recently got good advice on this list about how to properly specify
> > the
> > > > version overrides for the junit-bom artifacts.  When I implemented
> > that,
> > > I
> > > > saw that I was consistently getting the correct versions for those
> > > > artifacts.
> > > >
> > > > However, I'm now confused by the behavior that I'm seeing from
> > > Surefire.  I
> > > > currently have a mix of JUnit 4 and JUnit 5 tests.  I'm pretty sure
> > that
> > > I
> > > > had this working before, but now I see that it is not running any of
> > the
> > > > JUnit 5 tests.
> > > >
> > > > Note the following excerpt from my build:
> > > > ---
> > > > [INFO] --- maven-surefire-plugin:3.0.0-M7:test (default-test) @
> > > > PlatformPilotMs ---
> > > > [INFO] Using auto detected provider
> > > > org.apache.maven.surefire.junit4.JUnit4Provider
> > > > --
> > > >
> > > > I'm using the very latest M

Re: Surefire not running JUnit 5 tests after fixing how junit-bom artifacts are specified

[David Karr]

Ok, what is the proper way to do that, considering I have the following in
a bom imported by my parent pom:


org.junit
junit-bom
import
pom
5.8.2



  org.springframework.boot
  spring-boot-dependencies
  ${spring-boot.version}
  pom
  import


Do I add an exclusion to one or both of these?

On Fri, Jun 17, 2022 at 11:37 AM Slawomir Jaranowski 
wrote:

> Do you have on your classpath - junit-platform-runner?
> Please remove it.
>
>
> pt., 17 cze 2022 o 20:23 David Karr 
> napisał(a):
>
> > I'm posting a new note, as this might be a different issue.
> >
> > I recently got good advice on this list about how to properly specify the
> > version overrides for the junit-bom artifacts.  When I implemented that,
> I
> > saw that I was consistently getting the correct versions for those
> > artifacts.
> >
> > However, I'm now confused by the behavior that I'm seeing from
> Surefire.  I
> > currently have a mix of JUnit 4 and JUnit 5 tests.  I'm pretty sure that
> I
> > had this working before, but now I see that it is not running any of the
> > JUnit 5 tests.
> >
> > Note the following excerpt from my build:
> > ---
> > [INFO] --- maven-surefire-plugin:3.0.0-M7:test (default-test) @
> > PlatformPilotMs ---
> > [INFO] Using auto detected provider
> > org.apache.maven.surefire.junit4.JUnit4Provider
> > --
> >
> > I'm using the very latest M version, as that resolves other issues we've
> > been having. When I look to see what tests were executed, I see that it
> > doesn't include any of my JUnit 5 tests.
> >
> > I ran "mvn dependency:tree" to verify what versions of JUnit are in the
> > classpath, and it has BOTH JUnit 4.13 and junit-platform 1.8.2 and
> > junit-jupiter 5.8.2.  The surefire doc page says "Surefire normally
> > automatically selects which test-framework provider to use based on the
> > version of TestNG/JUnit present in your project's classpath". Is the fact
> > that both are in the classpath causing this? Am I going to have to
> manually
> > specify both the junit 4 and junit 5 providers in the surefire
> > dependencies? That is additionally annoying as I also have to redundantly
> > specify the versions of those artifacts (I tried not specifying a
> version,
> > and it complained).
> >
>
>
> --
> Sławomir Jaranowski
>

Surefire not running JUnit 5 tests after fixing how junit-bom artifacts are specified

[David Karr]

I'm posting a new note, as this might be a different issue.

I recently got good advice on this list about how to properly specify the
version overrides for the junit-bom artifacts.  When I implemented that, I
saw that I was consistently getting the correct versions for those
artifacts.

However, I'm now confused by the behavior that I'm seeing from Surefire.  I
currently have a mix of JUnit 4 and JUnit 5 tests.  I'm pretty sure that I
had this working before, but now I see that it is not running any of the
JUnit 5 tests.

Note the following excerpt from my build:
---
[INFO] --- maven-surefire-plugin:3.0.0-M7:test (default-test) @
PlatformPilotMs ---
[INFO] Using auto detected provider
org.apache.maven.surefire.junit4.JUnit4Provider
--

I'm using the very latest M version, as that resolves other issues we've
been having. When I look to see what tests were executed, I see that it
doesn't include any of my JUnit 5 tests.

I ran "mvn dependency:tree" to verify what versions of JUnit are in the
classpath, and it has BOTH JUnit 4.13 and junit-platform 1.8.2 and
junit-jupiter 5.8.2.  The surefire doc page says "Surefire normally
automatically selects which test-framework provider to use based on the
version of TestNG/JUnit present in your project's classpath". Is the fact
that both are in the classpath causing this? Am I going to have to manually
specify both the junit 4 and junit 5 providers in the surefire
dependencies? That is additionally annoying as I also have to redundantly
specify the versions of those artifacts (I tried not specifying a version,
and it complained).

Re: How to properly override junit-platform and junit-jupiter in a parent pom

[David Karr]

If it matters, I see that in our parent bom artifact, we are importing
"spring-boot-dependencies".

On Thu, Jun 16, 2022 at 5:27 PM David Karr 
wrote:

> Sorry, can you clarify exactly what you mean by that?
>
> On Thu, Jun 16, 2022 at 4:14 PM Karl Heinz Marbaise 
> wrote:
>
>> Hi,
>>
>> It's important to define the junit-bom import before the
>> spring-boot-dependencies import part in dependencyManagement which assumes
>> you don't use spring-boot-parent?
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>>
>> On 16.06.22 23:54, David Karr wrote:
>> > We have a bunch of services running Spring Boot 2.3.12, which by default
>> > uses junit-platform 1.6.3 and junit-jupiter 5.6.3.
>> >
>> > We are trying to instead use junit-platform 1.8.2 and junit-jupiter
>> 5.8.2.
>> > All the artifacts and versions we need are in junit-bom-5.8.2.
>> >
>> > We want to control this in our parent pom(s), as we have dozens of
>> similar
>> > services all using the same parent pom.
>> >
>> > I thought I had this working, but now it appears it's not, and I'm not
>> sure
>> > what I'm missing.
>> >
>> > At one time I had thought all I had to do was include junit-bom v5.8.2
>> in
>> > the "dependencies" list in the parent pom, but that never worked.  For
>> lack
>> > of any other solution, I simply pasted the contents of the
>> "dependencies"
>> > list from junit-bom-5.8.2 into the "dependencies" list of my parent pom.
>> > At one point, I thought this was working.
>> >
>> > Today, I'm looking at one service that uses that parent pom, but for
>> some
>> > reason it's not getting the newer versions of the artifacts, it's still
>> > getting 1.6.3 and 5.6.3.  I'm looking at both "mvn dependency:tree" and
>> the
>> > "Dependency Hierarchy" view in Eclipse.  I'm not completely certain how
>> to
>> > interpret what I'm seeing.
>> >
>> > The first thing I want to know is what is the best way to do this sort
>> of
>> > thing.  I find it hard to believe pasting the entire contents of the bom
>> > that I want into the parent pom was the right way to do it, but I
>> couldn't
>> > get it to work any other way, and now it's not working anyway.
>> >
>> > I can provide more details of specific poms and parent poms, but I
>> wanted
>> > to see if there was a simple solution first.
>> >
>> > I am basically aware of the difference between "dependencyManagement"
>> and
>> > "dependencies" in a parent pom.
>> >
>>
>>

Re: How to properly override junit-platform and junit-jupiter in a parent pom

[David Karr]

Sorry, can you clarify exactly what you mean by that?

On Thu, Jun 16, 2022 at 4:14 PM Karl Heinz Marbaise 
wrote:

> Hi,
>
> It's important to define the junit-bom import before the
> spring-boot-dependencies import part in dependencyManagement which assumes
> you don't use spring-boot-parent?
>
> Kind regards
> Karl Heinz Marbaise
>
>
> On 16.06.22 23:54, David Karr wrote:
> > We have a bunch of services running Spring Boot 2.3.12, which by default
> > uses junit-platform 1.6.3 and junit-jupiter 5.6.3.
> >
> > We are trying to instead use junit-platform 1.8.2 and junit-jupiter
> 5.8.2.
> > All the artifacts and versions we need are in junit-bom-5.8.2.
> >
> > We want to control this in our parent pom(s), as we have dozens of
> similar
> > services all using the same parent pom.
> >
> > I thought I had this working, but now it appears it's not, and I'm not
> sure
> > what I'm missing.
> >
> > At one time I had thought all I had to do was include junit-bom v5.8.2 in
> > the "dependencies" list in the parent pom, but that never worked.  For
> lack
> > of any other solution, I simply pasted the contents of the "dependencies"
> > list from junit-bom-5.8.2 into the "dependencies" list of my parent pom.
> > At one point, I thought this was working.
> >
> > Today, I'm looking at one service that uses that parent pom, but for some
> > reason it's not getting the newer versions of the artifacts, it's still
> > getting 1.6.3 and 5.6.3.  I'm looking at both "mvn dependency:tree" and
> the
> > "Dependency Hierarchy" view in Eclipse.  I'm not completely certain how
> to
> > interpret what I'm seeing.
> >
> > The first thing I want to know is what is the best way to do this sort of
> > thing.  I find it hard to believe pasting the entire contents of the bom
> > that I want into the parent pom was the right way to do it, but I
> couldn't
> > get it to work any other way, and now it's not working anyway.
> >
> > I can provide more details of specific poms and parent poms, but I wanted
> > to see if there was a simple solution first.
> >
> > I am basically aware of the difference between "dependencyManagement" and
> > "dependencies" in a parent pom.
> >
>
>

How to properly override junit-platform and junit-jupiter in a parent pom

[David Karr]

We have a bunch of services running Spring Boot 2.3.12, which by default
uses junit-platform 1.6.3 and junit-jupiter 5.6.3.

We are trying to instead use junit-platform 1.8.2 and junit-jupiter 5.8.2.
All the artifacts and versions we need are in junit-bom-5.8.2.

We want to control this in our parent pom(s), as we have dozens of similar
services all using the same parent pom.

I thought I had this working, but now it appears it's not, and I'm not sure
what I'm missing.

At one time I had thought all I had to do was include junit-bom v5.8.2 in
the "dependencies" list in the parent pom, but that never worked.  For lack
of any other solution, I simply pasted the contents of the "dependencies"
list from junit-bom-5.8.2 into the "dependencies" list of my parent pom.
At one point, I thought this was working.

Today, I'm looking at one service that uses that parent pom, but for some
reason it's not getting the newer versions of the artifacts, it's still
getting 1.6.3 and 5.6.3.  I'm looking at both "mvn dependency:tree" and the
"Dependency Hierarchy" view in Eclipse.  I'm not completely certain how to
interpret what I'm seeing.

The first thing I want to know is what is the best way to do this sort of
thing.  I find it hard to believe pasting the entire contents of the bom
that I want into the parent pom was the right way to do it, but I couldn't
get it to work any other way, and now it's not working anyway.

I can provide more details of specific poms and parent poms, but I wanted
to see if there was a simple solution first.

I am basically aware of the difference between "dependencyManagement" and
"dependencies" in a parent pom.

Re: Kubernetes Build Environment

[David Karr]

Along the lines of Bernd's response, I would (as we have done in our own
builds) use Maven to build the artifacts that we deploy to our intranet
repositories, but we do everything else in Jenkins pipeline script. We just
call "kubectl" for k8s configuration steps, and when it comes down to
integration tests, we do stil use Maven Failsafe, but we supply the
host:port of the service in the cluster on the maven command line.

On Sun, Jun 5, 2022 at 8:55 PM Bernd Eckenfels 
wrote:

> do you need to test K8s or just have some external containers to set up,
> maybe using Testcontainers with Docker APi is an alternative? (Advantage is
> you can simpler test it locally)
>
>  Another alternative is to use a CI pipeline script/system instead of
> orchestrating it in maven - at least if there is no plugin which does what
> you need, instead from junit/testng (IT) test cases, using the kubernetes
> or f8 client might also be an option.
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> 
> Von: Philipp Kraus 
> Gesendet: Monday, June 6, 2022 5:38:58 AM
> An: users@maven.apache.org 
> Betreff: Kubernetes Build Environment
>
> Hello,
>
> I need some idea how to solve this issue. I have got a MultiMaven project,
> which has got multiple web services. Each service will be run later in a
> container in Kubernetes.
> I have found this plugin
> https://www.eclipse.org/jkube/docs/kubernetes-maven-plugin to build
> everything, but I would like to get integration testing within the
> Kubernetes environment,
> Because all services has got a Kafka connection and I would like to run
> some complex integration test directly from the Maven build.
>
> Can you give me some ideas how to do it?
>
> Thanks a lot
>

Re: Questions about surefire issue causing "buffer overflow" and apache JIRA problem

[David Karr]

I see.

Related to this, I have still another build that is resulting in no JUnit 5
tests being selected.  I have no idea why. Are there any changes going in
M7 that might address this?  I was considering spending the time trying to
take that test case and whittling it down to something that I can post that
still demonstrates the problem, although that may take a lot of time and
not result in something that I can use.

On Tue, May 31, 2022 at 8:03 AM Slawomir Jaranowski 
wrote:

> Hi,
>
> M7 should be released soon, please follow the discussion on dev list [1]
>
> [1] https://lists.apache.org/thread/r86q92w8pfb1g3rg8tzbt810cjt6vdcq
>
> wt., 31 maj 2022 o 15:47 David Karr 
> napisał(a):
>
> > I noticed the following issue:
> > https://issues.apache.org/jira/browse/SUREFIRE-2056
> >
> > I searched for it because we are seeing this in one of our builds.
> >
> > I could use some more information about this.  This is apparently a bug
> in
> > 3.0.0-M6, which is fixed in 3.0.0-M7, which is not released yet. I
> verified
> > that backing off to 3.0.0-M5 avoids this problem, but we are already
> forced
> > to use 3.0.0-M6 because test suites don't work in the last release.
> >
> > Is there some other workaround we might be able to implement besides
> > backing off to 3.0.0-M5?  The problem seems to occur when this
> "testRunId"
> > is null, but I don't know what this is, or how it might be controlled or
> > configured in user code.
> >
> > Note that I tried to write this comment in the issue after logging in,
> but
> > each time I have attempted this (several times over the last few days),
> it
> > says:
> > -
> > Communications Breakdown
> >
> > The Jira server could not be contacted. This may be a temporary glitch or
> > the server may be down.
> >
> > Close this dialog and press refresh in your browser
> > 
> >
>
>
> --
> Sławomir Jaranowski
>

Questions about surefire issue causing "buffer overflow" and apache JIRA problem

[David Karr]

I noticed the following issue:
https://issues.apache.org/jira/browse/SUREFIRE-2056

I searched for it because we are seeing this in one of our builds.

I could use some more information about this.  This is apparently a bug in
3.0.0-M6, which is fixed in 3.0.0-M7, which is not released yet. I verified
that backing off to 3.0.0-M5 avoids this problem, but we are already forced
to use 3.0.0-M6 because test suites don't work in the last release.

Is there some other workaround we might be able to implement besides
backing off to 3.0.0-M5?  The problem seems to occur when this "testRunId"
is null, but I don't know what this is, or how it might be controlled or
configured in user code.

Note that I tried to write this comment in the issue after logging in, but
each time I have attempted this (several times over the last few days), it
says:
-
Communications Breakdown

The Jira server could not be contacted. This may be a temporary glitch or
the server may be down.

Close this dialog and press refresh in your browser

Re: exclusions are not being applied

[David Hoffer]

I thought I had tried that option and had the same issue but I just tried
that again and it worked so I must have looked at the results incorrectly.

Thanks, much for the help.

Love to see this feature in Maven.

-Dave

On Tue, Apr 26, 2022 at 5:41 PM Jacques Etienne Beaudet 
wrote:

> Exclusions are not yet supported at the dependencyManagement level. See
> https://stackoverflow.com/questions/39276024/import-dependency-management-with-exclusion
> for more informations or the corresponding unmerged PR
> https://github.com/apache/maven/pull/295
>
> Exclude it when you include the dependency in the meantime.
> On Apr 26, 2022, 7:35 PM -0400, David Hoffer , wrote:
> > I have a project where I am trying to use exclusions to exclude
> transitive
> > dependencies but they are not being excluded. Here is an example from my
> > dependencyManagement top level pom.
> >
> > 
> > 
> > com.bs.component-library.model
> > model
> > ${model.version}
> > 
> > 
> > io.swagger.core.v3
> > swagger-jaxrs2
> > 
> > 
> > 
> > 
> >
> > Then in the build this is in the dependency section.
> > 
> > com.bs.component-library.model
> > model
> > 
> >
> > However when I run mvn dependency:tree
> >
> > I still see io.swagger.core.v3:swagger-jaxrs2:jar:2.1.11:compile as a
> > first level dependency under the model
> dependency.
> >
> > Why is it not being excluded?
> >
> > -Dave
>

exclusions are not being applied

[David Hoffer]

I have a project where I am trying to use exclusions to exclude transitive
dependencies but they are not being excluded.  Here is an example from my
dependencyManagement top level pom.



com.bs.component-library.model
model
${model.version}


io.swagger.core.v3
swagger-jaxrs2





Then in the build this is in the dependency section.
  
com.bs.component-library.model
model


However when I run mvn dependency:tree

I still see  io.swagger.core.v3:swagger-jaxrs2:jar:2.1.11:compile as a
first level dependency under the model dependency.

Why is it not being excluded?

-Dave

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

[KARR, DAVID]

> -Original Message-
> From: KARR, DAVID 
> Sent: Friday, April 1, 2022 11:03 AM
> To: Maven Users List 
> Subject: How can I tell what value of "maxmem" the maven-compiler-plugin
> is using by default?
> 
> I noticed that we have one build that is trying to compile so many files
> that it is running out of memory in the maven-compiler-plugin execution.
> I see that I can set the "maxmem" property in that plugin's
> configuration.  What would be nice to know is what the default value is.
> I thought that perhaps "mvn -X" would tell me that, but that only tells
> me that the default value is "${maven.compiler.maxmem}".  That doesn't
> help me.  How can I get the default value of this property, or any
> particular property, from a given pom?

Self-answering, I guess if this is simply not providing a value if none is 
provided, that would leave it to the default maxmem for the jvm, which I guess 
is 256mb.  Is that what is happening here?


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

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

[KARR, DAVID]

I noticed that we have one build that is trying to compile so many files that 
it is running out of memory in the maven-compiler-plugin execution.  I see that 
I can set the "maxmem" property in that plugin's configuration.  What would be 
nice to know is what the default value is.  I thought that perhaps "mvn -X" 
would tell me that, but that only tells me that the default value is 
"${maven.compiler.maxmem}".  That doesn't help me.  How can I get the default 
value of this property, or any particular property, from a given pom? 

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

Re: How to produce a pom.xml that is guaranteed to fail, with specific error messages

[David Karr]

On Wed, Mar 30, 2022 at 11:52 AM Jörg Schaible 
wrote:

> Hi David,
>
> On Wednesday, 30. March 2022, 19:46:35 CEST David Karr wrote:
> > I work in a large company on a large project with hundreds of services,
> > most of which are Java Maven projects.  We have an "archetype" we use for
> > new services. It doesn't use the Maven archetype process.  There are
> > particular areas in the pom.xml that is generated that really need to be
> > modified by the developer to reflect their actual application.
> >
> > We could certainly put comments in the template that tell the developer
> > what sort of changes need to be made, but I wonder if there's any way we
> > can ensure that they notice and handle particular areas of the pom.xml.
> > Just generating a comment with directions isn't enough.  I wish there was
> > some way I could ensure that running the build would fail with a specific
> > error message if they haven't dealt with each area. I suppose I could
> > create an XML syntax error in each area that should be addressed, with
> text
> > near the error that explains what to do, but that seems like a bit of a
> > hack, although it may be the only strategy I can use.  Is there a cleaner
> > way to do this sort of thing that I'm not aware of?
>
> Add the maven-verifier-plugin and a verification file to your archetype,
> bind it
> to the validation phase and check the content of the pom.xml. If it still
> contains your placeholders, it can fail your build.
>

I've never looked at the verifier before. This could be useful. It's
unfortunate that it doesn't provide any way to communicate anything in the
log when the build fails. I at least submitted an enhancement request for
that.

Re: How to produce a pom.xml that is guaranteed to fail, with specific error messages

[David Karr]

On Wed, Mar 30, 2022 at 11:52 AM Shipp, Scott 
wrote:

> Are you saying that this is not a Maven archetype or that it is? The Maven
> archtetype feature allows the POM (and other files) to be templated. It
> sounds like exactly what you are looking for. Check out
> https://maven.apache.org/guides/mini/guide-creating-archetypes.html it
> will probably do what you want.
>

Actually, I was mistaken.  The service generation process does use a Maven
archetype.


> From: David Karr 
> Date: Wednesday, March 30, 2022 at 10:47 AM
> To: Maven Users List 
> Subject: How to produce a pom.xml that is guaranteed to fail, with
> specific error messages
> External Email
>
> I work in a large company on a large project with hundreds of services,
> most of which are Java Maven projects.  We have an "archetype" we use for
> new services. It doesn't use the Maven archetype process.  There are
> particular areas in the pom.xml that is generated that really need to be
> modified by the developer to reflect their actual application.
>
> We could certainly put comments in the template that tell the developer
> what sort of changes need to be made, but I wonder if there's any way we
> can ensure that they notice and handle particular areas of the pom.xml.
> Just generating a comment with directions isn't enough.  I wish there was
> some way I could ensure that running the build would fail with a specific
> error message if they haven't dealt with each area. I suppose I could
> create an XML syntax error in each area that should be addressed, with text
> near the error that explains what to do, but that seems like a bit of a
> hack, although it may be the only strategy I can use.  Is there a cleaner
> way to do this sort of thing that I'm not aware of?
>

How to produce a pom.xml that is guaranteed to fail, with specific error messages

[David Karr]

I work in a large company on a large project with hundreds of services,
most of which are Java Maven projects.  We have an "archetype" we use for
new services. It doesn't use the Maven archetype process.  There are
particular areas in the pom.xml that is generated that really need to be
modified by the developer to reflect their actual application.

We could certainly put comments in the template that tell the developer
what sort of changes need to be made, but I wonder if there's any way we
can ensure that they notice and handle particular areas of the pom.xml.
Just generating a comment with directions isn't enough.  I wish there was
some way I could ensure that running the build would fail with a specific
error message if they haven't dealt with each area. I suppose I could
create an XML syntax error in each area that should be addressed, with text
near the error that explains what to do, but that seems like a bit of a
hack, although it may be the only strategy I can use.  Is there a cleaner
way to do this sort of thing that I'm not aware of?

RE: Strategies for automatically fixing local maven repo corruption?

[KARR, DAVID]

> -Original Message-
> From: Jacques Etienne Beaudet 
> Sent: Wednesday, March 23, 2022 3:14 PM
> To: Maven Users List 
> Subject: Re: Strategies for automatically fixing local maven repo
> corruption?
> 
> I'll copy paste something I wrote in another thread but yea basically
> there's a neat way to help with this :
> 
> Just chiming in on my experience using the redis locks with maven 3.8.x
> and resolver 1.6. I've been running it on my Jenkins nodes for about a
> year now with great success. Before it, we had corrupted local maven
> repos (zip file empty kind of exceptions) a couple of times a week.
> Then, we configured Jenkins to properly handle multiple concurrent
> builds by not sharing the maven local repo and run each build in docker
> which is wasteful since you have to redownload all your dependencies on
> each build and build time is obviously very long.
> 
> Then I bumped into the lock feature which is available on resolver 1.6
> (instructions here svn.apache.org/repos...x.html). It is a bit
> cumbersome to setup but after that, we started sharing the same local
> repos and our build time dramatically improved (something like from 4
> minutes to ~30 seconds) and we had a corrupted maven repo once or twice
> throughout the year (and it could have been some job that a dev created
> without the proper config, I didn't investigate much).

This note posted with that url truncated.  Can you provide the full url?

> Redis is really easy to setup and is available via docker or apt so it
> should be a breeze to add it to your init script like we did. My nodes
> had docker already installed so it was just adding this to the "Init
> script" in the nodes configuration :
> #!/bin/bash -ue
> 
> docker run -d --network host --name mvn_redis redis:6.2-alpine

> 23, 2022, 6:11 PM -0400, David Karr , wrote:
> > Our enterprise has builds for a couple of hundred services running
> > many times a day, on a set of Jenkins build nodes, most of which are
> > Maven builds.The builds use a settings.xml that doesn't override the
> > "localRepository", so it will use a local repository on the build node
> > that is used by all builds.
> >
> > We often run into weird build errors like "Could not find artifact",
> > for artifacts that I can clearly show are available in our intranet
> repository.
> > In every one of those cases, when we inspect the directory in the
> > local maven repo on that build node, we see that it's "corrupted", in
> > that perhaps the pom file is there, but the jar file is missing.
> >
> > We fix these errors by simply removing the directory where the key
> > files are missing, then rerun the build, which correctly downloads the
> > artifact, and the build succeeds. We often have to do this on multiple
> > build nodes, although I don't have visibility to that (not on ops
> > team), so I don't really know if the same artifact gets corrupted on
> > multiple build nodes at the same time. I doubt that.
> >
> > I wish there was some way that we could either prevent some of these
> > incidents, or somehow automatically fix them (by removing the
> > corrupted directory). The latter seems like it's in the realm of
> > possibilities, but it would have to be constantly scanning the entire
> > repository, looking at leaf directories that haven't changed in
> > several minutes, and somehow verifying the "sanity" of the contents
> from a very limited perspective.
> >
> > Is there anything we can do to improve this situation?

Strategies for automatically fixing local maven repo corruption?

[David Karr]

Our enterprise has builds for a couple of hundred services running many
times a day, on a set of Jenkins build nodes, most of which are Maven
builds.The builds use a settings.xml that doesn't override the
"localRepository", so it will use a local repository on the build node that
is used by all builds.

We often run into weird build errors like "Could not find artifact", for
artifacts that I can clearly show are available in our intranet repository.
In every one of those cases, when we inspect the directory in the local
maven repo on that build node, we see that it's "corrupted", in that
perhaps the pom file is there, but the jar file is missing.

We fix these errors by simply removing the directory where the key files
are missing, then rerun the build, which correctly downloads the artifact,
and the build succeeds.  We often have to do this on multiple build nodes,
although I don't have visibility to that (not on ops team), so I don't
really know if the same artifact gets corrupted on multiple build nodes at
the same time. I doubt that.

I wish there was some way that we could either prevent some of these
incidents, or somehow automatically fix them (by removing the corrupted
directory). The latter seems like it's in the realm of possibilities, but
it would have to be constantly scanning the entire repository, looking at
leaf directories that haven't changed in several minutes, and somehow
verifying the "sanity" of the contents from a very limited perspective.

Is there anything we can do to improve this situation?

RE: What steps will install dependent artifacts in local maven repo

[KARR, DAVID]

> -Original Message-
> From: Thomas Broyer 
> Sent: Wednesday, March 23, 2022 6:59 AM
> To: Maven Users List 
> Subject: Re: What steps will install dependent artifacts in local maven
> repo
> 
> Releases are "immutable" in a Maven repository (or at least are expected
> to be, and the Central Repository enforces it), so if 3.7.1 is
> compatible with JDK 8, it will stay that way.

That was my assumption, but I wanted to make sure I wasn't missing something.

> On Wed, Mar 23, 2022 at 2:40 PM KARR, DAVID  wrote:
> 
> > Inline.
> >
> > > -Original Message-
> > > From: Alexander Kriegisch 
> > > Sent: Wednesday, March 23, 2022 1:11 AM
> > > To: users@maven.apache.org
> > > Subject: Re: What steps will install dependent artifacts in local
> > > maven repo
> > >
> > > Some background information, because I happen to know, being an
> > > AspectJ committer and the AspectJ compiler being a fork of ECJ, just
> > > like GrEclipse is, too:
> > >
> > > The JDT Core project has decided a while ago - I think for the
> > > Eclipse
> > > 4.22 (2021-12) release, maybe one release earlier - to drop Java 8
> > > build-time support and move on to Java 11+, because other parts of
> > > Eclipse are based on Java 11 too and it was getting more and more
> > > difficult to keep those libraries out with their Java 11 class
> > > files. So now, JDT Core and therefore also recent versions of
> > > compilers like ECJ, GrEclipse and AspectJ *had* to migrate to Java
> > > 11 as well, because they all depend on JDT Core.
> > >
> > > Attention, please do not misunderstand: ECJ and e.g. AspectJ can
> > > still compile to Java 8 target. I do not know about GrEclipse, but
> > > would expect the same. For pure POJOs (no AspectJ or Groovy), those
> > > compilers can even create class files for as low as Java 1.3! Javac
> > > cannot do that, so you are more flexible than with Javac. The
> > > limitation only applies to build time, i.e. you have to run your
> > > builds on JVM 11+, even if you compile to target 8.
> > >
> > > Your error messages therefore come from builds using more recent
> > > Eclipse
> > > (fork) compiler version, but running on JRE 8. Simply upgrade the
> > > build environment on your workstation or Jenkins server to run on
> > > JDK 11+, then you should be fine.
> >
> > We are in the process of migrating from Java 8 to Java 11, but it is
> > not going to be immediate.  We can't simply flip a switch.
> >
> > I determined that groovy-eclipse-batch v3.0.8-01 is the last version
> > that was compiled by Java 8.  I need to know it will stay this way.  I
> > also am now specifying groovy-eclipse-compiler v3.7.1.  I also hope
> > that will stay on Java 8.  Are both of those true?
> >
> > > David Karr schrieb am 22.03.2022 23:50 (GMT +07:00):
> > >
> > > > Our org's builds have been using Java 8 for quite a while.  We're
> > > starting
> > > > to move some builds to Java 11.  We're seeing some builds failing
> > > > with
> > > the
> > > > following:
> > > > -
> > > > Execution default-compile of goal
> > > > org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile
> failed:
> > > > An API incompatibility was encountered while executing
> > > > org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile:
> > > > java.lang.UnsupportedClassVersionError:
> > > > org/eclipse/jdt/core/compiler/batch/BatchCompiler has been
> > > > compiled by
> > > a
> > > > more
> > > > recent version of the Java Runtime (class file version 55.0), this
> > > version
> > > > of
> > > > the Java Runtime only recognizes class file versions up to 52.0
> > > > -
> > > >
> > > > This indicates that the artifact with the BatchCompiler class
> > > > (ecj)
> > > was
> > > > compiled with Java 11, but the current JVM is Java 8.
> > > >
> > > > I'm trying to understand the possible scenarios that could produce
> > > this, so
> > > > we can mitigate it properly.
> > > >
> > > > This artifact is specified as a direct dependency of the
> > > > "maven-compiler-plugin". It would help to understand exactly which
> > > Maven
> > > > goals wi

RE: What steps will install dependent artifacts in local maven repo

[KARR, DAVID]

Inline.

> -Original Message-
> From: Alexander Kriegisch 
> Sent: Wednesday, March 23, 2022 1:11 AM
> To: users@maven.apache.org
> Subject: Re: What steps will install dependent artifacts in local maven
> repo
> 
> Some background information, because I happen to know, being an AspectJ
> committer and the AspectJ compiler being a fork of ECJ, just like
> GrEclipse is, too:
> 
> The JDT Core project has decided a while ago - I think for the Eclipse
> 4.22 (2021-12) release, maybe one release earlier - to drop Java 8
> build-time support and move on to Java 11+, because other parts of
> Eclipse are based on Java 11 too and it was getting more and more
> difficult to keep those libraries out with their Java 11 class files. So
> now, JDT Core and therefore also recent versions of compilers like ECJ,
> GrEclipse and AspectJ *had* to migrate to Java 11 as well, because they
> all depend on JDT Core.
> 
> Attention, please do not misunderstand: ECJ and e.g. AspectJ can still
> compile to Java 8 target. I do not know about GrEclipse, but would
> expect the same. For pure POJOs (no AspectJ or Groovy), those compilers
> can even create class files for as low as Java 1.3! Javac cannot do
> that, so you are more flexible than with Javac. The limitation only
> applies to build time, i.e. you have to run your builds on JVM 11+, even
> if you compile to target 8.
> 
> Your error messages therefore come from builds using more recent Eclipse
> (fork) compiler version, but running on JRE 8. Simply upgrade the build
> environment on your workstation or Jenkins server to run on JDK 11+,
> then you should be fine.

We are in the process of migrating from Java 8 to Java 11, but it is not going 
to be immediate.  We can't simply flip a switch.

I determined that groovy-eclipse-batch v3.0.8-01 is the last version that was 
compiled by Java 8.  I need to know it will stay this way.  I also am now 
specifying groovy-eclipse-compiler v3.7.1.  I also hope that will stay on Java 
8.  Are both of those true?

> David Karr schrieb am 22.03.2022 23:50 (GMT +07:00):
> 
> > Our org's builds have been using Java 8 for quite a while.  We're
> starting
> > to move some builds to Java 11.  We're seeing some builds failing with
> the
> > following:
> > -
> > Execution default-compile of goal
> > org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile failed:
> > An API incompatibility was encountered while executing
> > org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile:
> > java.lang.UnsupportedClassVersionError:
> > org/eclipse/jdt/core/compiler/batch/BatchCompiler has been compiled by
> a
> > more
> > recent version of the Java Runtime (class file version 55.0), this
> version
> > of
> > the Java Runtime only recognizes class file versions up to 52.0
> > -
> >
> > This indicates that the artifact with the BatchCompiler class (ecj)
> was
> > compiled with Java 11, but the current JVM is Java 8.
> >
> > I'm trying to understand the possible scenarios that could produce
> this, so
> > we can mitigate it properly.
> >
> > This artifact is specified as a direct dependency of the
> > "maven-compiler-plugin". It would help to understand exactly which
> Maven
> > goals will install plugin dependencies into the local maven repo.  At
> least
> > our builds only do "mvn package" or "mvn deploy", depending on what is
> > being built.
> >
> > However, our builds are run on a pool of Jenkins build nodes, and I'm
> not
> > certain whether those build nodes are shared with other projects in
> our
> > large enterprise. I'm trying to determine that.
> >
> > We may determine that because of these issues, we will have to specify
> a
> > fresh empty local repository for every build, which will obviously
> make our
> > builds take longer.
> >
> 
> -
> 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: What steps will install dependent artifacts in local maven repo

[KARR, DAVID]

And I also determined that groovy-eclipse v4.0.1 was released on 3/6/22, so it 
just took a few days to get to our intranet repo.  I don't see any statement 
about it being built with Java 11, but it appears that's what happened. 

> -Original Message-
> From: KARR, DAVID 
> Sent: Tuesday, March 22, 2022 12:15 PM
> To: Maven Users List 
> Subject: RE: What steps will install dependent artifacts in local maven
> repo
> 
> *** Security Advisory: This Message Originated Outside of AT&T ***.
> Reference http://cso.att.com/EmailSecurity/IDSP.html for more
> information.
> 
> Here is the maven-compiler-plugin block:
> 
>   
>   maven-compiler-plugin
>   
> ${maven.compiler.plugin.version}
>   
>   
>   compile
>   
>   
>   
>   
>   
> org.codehaus.groovy
>   groovy-eclipse-
> compiler
>   3.7.0
>   
>   
>   
> org.codehaus.groovy
>   groovy-eclipse-
> batch
>   RELEASE
>   
>   
>   
>   groovy-eclipse-
> compiler
>   
>   
> --
> 
> I think in the limited circumstances I've been able to figure out, this
> is essentially caused by specifying version "RELEASE", which means it
> will use the latest released version.  If we had specified version
> 3.0.8, we wouldn't have seen this problem.  What I still don't
> understand is why the 4.x versions are compiled with Java 11.  Our
> intranet repo does have a record of who the uploader was, although I
> wouldn't be at all surprised if that person says he has no idea why his
> name would be attached to that.  I will pursue that.
> 
> > -Original Message-
> > From: Thomas Broyer 
> > Sent: Tuesday, March 22, 2022 11:56 AM
> > To: Maven Users List 
> > Subject: Re: What steps will install dependent artifacts in local
> > maven repo
> >
> > This is totally unexpected behavior to me: an external artifact whose
> > content would be different depending on which JDK downloaded it.
> >
> > Would you mind sharing the maven-compiler-plugin declaration with the
> > ecj dependency? (to try replicating the issue and understand it)
> >
> > Le mar. 22 mars 2022 à 19:20, KARR, DAVID  a écrit :
> >
> > > Self-replying from my alter ego. 😊
> > >
> > > I have verified that if I remove the "ecj" tree from my local repo,
> > > then build one service with Java 11, with just "mvn package", then
> > > run a build of a different service with Java 8, it will get the
> > > given error.  I can verify that the ecj artifact is now reinstalled
> > > into my
> > local maven repo.
> > > What's odd is that when I use "javap" to inspect the BatchCompiler
> > > class file, it says it is version 50, not 55.
> > >
> > > I think I'm heading towards having each build, or at least each
> > > build with a specific Java version, use a separate localRepository.
> > > That is set in the settings.xml, and that path would be local to the
> > > build node, not the build workspace (obviously, if we intended to
> > > use the same tree for all Java 8 builds, and similarly one for all
> > > Java 11 builds). That means coordinating with the people who
> > > maintain the
> > build nodes.  Yuck.
> > >
> > > > -Original Message-
> > > > From: David Karr 
> > > > Sent: Tuesday, March 22, 2022 9:50 AM
> > > > To: Maven Users List 
> > > > Subject: What steps will install dependent artifacts in local
> > > > maven repo
> > > >
> > > > Our org's builds have been using Java 8 for quite a while.  We're
> > > > starting to move some builds to Java 11.  We're seeing some builds
> > > > failing with the
> > > > following:
> &

RE: What steps will install dependent artifacts in local maven repo

[KARR, DAVID]

Here is the maven-compiler-plugin block:


maven-compiler-plugin

${maven.compiler.plugin.version}


compile





org.codehaus.groovy

groovy-eclipse-compiler
3.7.0



org.codehaus.groovy

groovy-eclipse-batch
RELEASE




groovy-eclipse-compiler



--

I think in the limited circumstances I've been able to figure out, this is 
essentially caused by specifying version "RELEASE", which means it will use the 
latest released version.  If we had specified version 3.0.8, we wouldn't have 
seen this problem.  What I still don't understand is why the 4.x versions are 
compiled with Java 11.  Our intranet repo does have a record of who the 
uploader was, although I wouldn't be at all surprised if that person says he 
has no idea why his name would be attached to that.  I will pursue that.

> -Original Message-
> From: Thomas Broyer 
> Sent: Tuesday, March 22, 2022 11:56 AM
> To: Maven Users List 
> Subject: Re: What steps will install dependent artifacts in local maven
> repo
> 
> This is totally unexpected behavior to me: an external artifact whose
> content would be different depending on which JDK downloaded it.
> 
> Would you mind sharing the maven-compiler-plugin declaration with the
> ecj dependency? (to try replicating the issue and understand it)
> 
> Le mar. 22 mars 2022 à 19:20, KARR, DAVID  a écrit :
> 
> > Self-replying from my alter ego. 😊
> >
> > I have verified that if I remove the "ecj" tree from my local repo,
> > then build one service with Java 11, with just "mvn package", then run
> > a build of a different service with Java 8, it will get the given
> > error.  I can verify that the ecj artifact is now reinstalled into my
> local maven repo.
> > What's odd is that when I use "javap" to inspect the BatchCompiler
> > class file, it says it is version 50, not 55.
> >
> > I think I'm heading towards having each build, or at least each build
> > with a specific Java version, use a separate localRepository.  That is
> > set in the settings.xml, and that path would be local to the build
> > node, not the build workspace (obviously, if we intended to use the
> > same tree for all Java 8 builds, and similarly one for all Java 11
> > builds). That means coordinating with the people who maintain the
> build nodes.  Yuck.
> >
> > > -Original Message-
> > > From: David Karr 
> > > Sent: Tuesday, March 22, 2022 9:50 AM
> > > To: Maven Users List 
> > > Subject: What steps will install dependent artifacts in local maven
> > > repo
> > >
> > > Our org's builds have been using Java 8 for quite a while.  We're
> > > starting to move some builds to Java 11.  We're seeing some builds
> > > failing with the
> > > following:
> > > -
> > > Execution default-compile of goal
> > > org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile failed:
> > > An API incompatibility was encountered while executing
> > > org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile:
> > > java.lang.UnsupportedClassVersionError:
> > > org/eclipse/jdt/core/compiler/batch/BatchCompiler has been compiled
> > > by a more recent version of the Java Runtime (class file version
> > > 55.0), this version of the Java Runtime only recognizes class file
> > > versions up to
> > > 52.0
> > > -
> > >
> > > This indicates that the artifact with the BatchCompiler class (ecj)
> > > was compiled with Java 11, but the current JVM is Java 8.
> > >
> > > I'm trying to understand the possible scenarios that could produce
> > 

RE: What steps will install dependent artifacts in local maven repo

[KARR, DAVID]

Correction, it wasn't the "ecj" artifact, that was compiled with Java 11, it 
was "groovy-eclipse-batch".  I still have to understand how this could happen, 
and what are reasonable mitigations we can set up to prevent this.

I found these artifacts in our intranet maven repo.  The "4.x" artifacts were 
all compiled with Java 11.  The 3.0.8 version was compiled with Java 8.

> -----Original Message-
> From: KARR, DAVID 
> Sent: Tuesday, March 22, 2022 11:20 AM
> To: Maven Users List 
> Subject: RE: What steps will install dependent artifacts in local maven
> repo
> 
> *** Security Advisory: This Message Originated Outside of AT&T ***.
> Reference http://cso.att.com/EmailSecurity/IDSP.html for more
> information.
> 
> Self-replying from my alter ego. 😊
> 
> I have verified that if I remove the "ecj" tree from my local repo, then
> build one service with Java 11, with just "mvn package", then run a
> build of a different service with Java 8, it will get the given error.
> I can verify that the ecj artifact is now reinstalled into my local
> maven repo.  What's odd is that when I use "javap" to inspect the
> BatchCompiler class file, it says it is version 50, not 55.
> 
> I think I'm heading towards having each build, or at least each build
> with a specific Java version, use a separate localRepository.  That is
> set in the settings.xml, and that path would be local to the build node,
> not the build workspace (obviously, if we intended to use the same tree
> for all Java 8 builds, and similarly one for all Java 11 builds). That
> means coordinating with the people who maintain the build nodes.  Yuck.
> 
> > -Original Message-
> > From: David Karr 
> > Sent: Tuesday, March 22, 2022 9:50 AM
> > To: Maven Users List 
> > Subject: What steps will install dependent artifacts in local maven
> > repo
> >
> > Our org's builds have been using Java 8 for quite a while.  We're
> > starting to move some builds to Java 11.  We're seeing some builds
> > failing with the
> > following:
> > -
> > Execution default-compile of goal
> > org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile failed:
> > An API incompatibility was encountered while executing
> > org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile:
> > java.lang.UnsupportedClassVersionError:
> > org/eclipse/jdt/core/compiler/batch/BatchCompiler has been compiled by
> > a more recent version of the Java Runtime (class file version 55.0),
> > this version of the Java Runtime only recognizes class file versions
> > up to
> > 52.0
> > -
> >
> > This indicates that the artifact with the BatchCompiler class (ecj)
> > was compiled with Java 11, but the current JVM is Java 8.
> >
> > I'm trying to understand the possible scenarios that could produce
> > this, so we can mitigate it properly.
> >
> > This artifact is specified as a direct dependency of the "maven-
> > compiler-plugin". It would help to understand exactly which Maven
> > goals will install plugin dependencies into the local maven repo.  At
> > least our builds only do "mvn package" or "mvn deploy", depending on
> > what is being built.
> >
> > However, our builds are run on a pool of Jenkins build nodes, and I'm
> > not certain whether those build nodes are shared with other projects
> > in our large enterprise. I'm trying to determine that.
> >
> > We may determine that because of these issues, we will have to specify
> > a fresh empty local repository for every build, which will obviously
> > make our builds take longer.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org

RE: What steps will install dependent artifacts in local maven repo

[KARR, DAVID]

Self-replying from my alter ego. 😊

I have verified that if I remove the "ecj" tree from my local repo, then build 
one service with Java 11, with just "mvn package", then run a build of a 
different service with Java 8, it will get the given error.  I can verify that 
the ecj artifact is now reinstalled into my local maven repo.  What's odd is 
that when I use "javap" to inspect the BatchCompiler class file, it says it is 
version 50, not 55.

I think I'm heading towards having each build, or at least each build with a 
specific Java version, use a separate localRepository.  That is set in the 
settings.xml, and that path would be local to the build node, not the build 
workspace (obviously, if we intended to use the same tree for all Java 8 
builds, and similarly one for all Java 11 builds). That means coordinating with 
the people who maintain the build nodes.  Yuck.

> -Original Message-
> From: David Karr 
> Sent: Tuesday, March 22, 2022 9:50 AM
> To: Maven Users List 
> Subject: What steps will install dependent artifacts in local maven repo
> 
> Our org's builds have been using Java 8 for quite a while.  We're
> starting to move some builds to Java 11.  We're seeing some builds
> failing with the
> following:
> -
> Execution default-compile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile failed:
> An API incompatibility was encountered while executing
> org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile:
> java.lang.UnsupportedClassVersionError:
> org/eclipse/jdt/core/compiler/batch/BatchCompiler has been compiled by a
> more recent version of the Java Runtime (class file version 55.0), this
> version of the Java Runtime only recognizes class file versions up to
> 52.0
> -
> 
> This indicates that the artifact with the BatchCompiler class (ecj) was
> compiled with Java 11, but the current JVM is Java 8.
> 
> I'm trying to understand the possible scenarios that could produce this,
> so we can mitigate it properly.
> 
> This artifact is specified as a direct dependency of the "maven-
> compiler-plugin". It would help to understand exactly which Maven goals
> will install plugin dependencies into the local maven repo.  At least
> our builds only do "mvn package" or "mvn deploy", depending on what is
> being built.
> 
> However, our builds are run on a pool of Jenkins build nodes, and I'm
> not certain whether those build nodes are shared with other projects in
> our large enterprise. I'm trying to determine that.
> 
> We may determine that because of these issues, we will have to specify a
> fresh empty local repository for every build, which will obviously make
> our builds take longer.

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

What steps will install dependent artifacts in local maven repo

[David Karr]

Our org's builds have been using Java 8 for quite a while.  We're starting
to move some builds to Java 11.  We're seeing some builds failing with the
following:
-
Execution default-compile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile failed:
An API incompatibility was encountered while executing
org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile:
java.lang.UnsupportedClassVersionError:
org/eclipse/jdt/core/compiler/batch/BatchCompiler has been compiled by a
more
recent version of the Java Runtime (class file version 55.0), this version
of
the Java Runtime only recognizes class file versions up to 52.0
-

This indicates that the artifact with the BatchCompiler class (ecj) was
compiled with Java 11, but the current JVM is Java 8.

I'm trying to understand the possible scenarios that could produce this, so
we can mitigate it properly.

This artifact is specified as a direct dependency of the
"maven-compiler-plugin". It would help to understand exactly which Maven
goals will install plugin dependencies into the local maven repo.  At least
our builds only do "mvn package" or "mvn deploy", depending on what is
being built.

However, our builds are run on a pool of Jenkins build nodes, and I'm not
certain whether those build nodes are shared with other projects in our
large enterprise. I'm trying to determine that.

We may determine that because of these issues, we will have to specify a
fresh empty local repository for every build, which will obviously make our
builds take longer.

RE: Can't get Surefire to run any JUnit 5 tests

[KARR, DAVID]

I think I'll have to take your word for it.  I don’t know anything about your 
build or runtime architecture to comment.  I only found one change that looked 
like an actual business logic change, relating to adding the wildcard filter to 
the TestListResolver, but I don't know what that means.  I'll be glad to test 
it when it's put into a released version.

Is there any thought as to when this will go into a full release, instead of M 
releases?

> -Original Message-
> From: Tibor Digana 
> Sent: Sunday, March 20, 2022 4:32 PM
> To: Maven Users List 
> Subject: Re: Can't get Surefire to run any JUnit 5 tests
> 
> The principles in junit providers are +/- the same, or they should be.
> So it was easy to find the difference and make the fix!
> 
> T
> 
> On Mon, Mar 21, 2022 at 12:25 AM Tibor Digana 
> wrote:
> 
> > Hey David,
> >
> > Here is the PR.
> > You can see the integration test of documentation with the principles.
> > Pls find it and let me know you like it, feel free to put +1 in your
> comment.
> > https://urldefense.com/v3/__https://github.com/apache/maven-surefire/p
> > ull/494__;!!BhdT!lFqcUUy0111TgmVTkjtCGYx0nVsQnYDTocJ9YXlK-lioUt5rbtuGB
> > _V1sLb284E5LAqrLQkEGXLu3FQAemKi$ As I said in JIRA, the combination of
> > JUnit4 and JUnit5 is not the problem. The problem is that we
> > implemented the JUnit5 Surefire Provider with a bug. We always operate
> > with TestListResolver the same way in all surefire providers but in
> > this one. It was our fault, and not the principals are the same in
> > providers and so there is no difference regarding the principles.
> > That's the reason why I showed you the example with JUnit4 because I
> > had some suspicions in the code and it was confirmed by running the
> > tests and debugging the code.
> >
> > Cheers
> > Tibor
> >
> >
> > On Sun, Mar 20, 2022 at 8:23 PM KARR, DAVID  wrote:
> >
> >> Here's my ticket:
> https://urldefense.com/v3/__https://issues.apache.org/jira/browse/SUREFI
> RE-2040__;!!BhdT!lFqcUUy0111TgmVTkjtCGYx0nVsQnYDTocJ9YXlK-
> lioUt5rbtuGB_V1sLb284E5LAqrLQkEGXLu3BaYyUTU$  .
> >>
> >> > -Original Message-
> >> > From: Tibor Digana 
> >> > Sent: Sunday, March 20, 2022 12:03 PM
> >> > To: Maven Users List 
> >> > Subject: Re: Can't get Surefire to run any JUnit 5 tests
> >> >
> >> > Hello David,
> >> >
> >> > I have an internal fix, zou won't be able to have it today. :-) But
> >> > if you have created the Jira ticket for us, we would make sure we
> >> > are on the right way.
> >> >
> >> > This is my suite class with JUnit5, just a principle (there might
> >> > be more children classes of course), and I use the command *mvn
> >> > test -
> >> > Dtest=MyTestSuite* I hope I am on the right track.
> >> >
> >> > package pkg;
> >> >
> >> > import org.junit.platform.suite.api.SelectClasses;
> >> > import org.junit.platform.suite.api.Suite;
> >> >
> >> > @Suite
> >> > @SelectClasses(BDSHelperTest.class)
> >> > public class MyTestSuite {
> >> > }
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Sun, Mar 20, 2022 at 6:25 PM KARR, DAVID  wrote:
> >> >
> >> > > > -Original Message-
> >> > > > From: Tibor Digana 
> >> > > > Sent: Sunday, March 20, 2022 6:42 AM
> >> > > > To: Maven Users List 
> >> > > > Subject: Re: Can't get Surefire to run any JUnit 5 tests
> >> > > >
> >> > > > There was the same question maybe one week ago.
> >> > > > I have created an example with JUnit4, see the next, and used
> >> > > > the configuration parameter ComponentTestSuite
> >> > > > where the command naturally works:
> >> > > >
> >> > > > mvn -Dtest=ComponentTestSuite test
> >> > > >
> >> > > > [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time
> >> > elapsed:
> >> > > > 0.14 s - in pkg.ComponentTestSuite
> >> > > >
> >> > > > After my fix this should work in JUnit5 provider. I have pushed
> >> > > > a test project with JUnit5 Suite, activate it via profile
> >> > > > "suite", see
> >> > > >
> >> https

RE: Can't get Surefire to run any JUnit 5 tests

[KARR, DAVID]

Here's my ticket: https://issues.apache.org/jira/browse/SUREFIRE-2040 .

> -Original Message-
> From: Tibor Digana 
> Sent: Sunday, March 20, 2022 12:03 PM
> To: Maven Users List 
> Subject: Re: Can't get Surefire to run any JUnit 5 tests
> 
> Hello David,
> 
> I have an internal fix, zou won't be able to have it today. :-) But if
> you have created the Jira ticket for us, we would make sure we are on
> the right way.
> 
> This is my suite class with JUnit5, just a principle (there might be
> more children classes of course), and I use the command *mvn test -
> Dtest=MyTestSuite* I hope I am on the right track.
> 
> package pkg;
> 
> import org.junit.platform.suite.api.SelectClasses;
> import org.junit.platform.suite.api.Suite;
> 
> @Suite
> @SelectClasses(BDSHelperTest.class)
> public class MyTestSuite {
> }
> 
> 
> 
> 
> 
> On Sun, Mar 20, 2022 at 6:25 PM KARR, DAVID  wrote:
> 
> > > -Original Message-
> > > From: Tibor Digana 
> > > Sent: Sunday, March 20, 2022 6:42 AM
> > > To: Maven Users List 
> > > Subject: Re: Can't get Surefire to run any JUnit 5 tests
> > >
> > > There was the same question maybe one week ago.
> > > I have created an example with JUnit4, see the next, and used the
> > > configuration parameter ComponentTestSuite where the
> > > command naturally works:
> > >
> > > mvn -Dtest=ComponentTestSuite test
> > >
> > > [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time
> elapsed:
> > > 0.14 s - in pkg.ComponentTestSuite
> > >
> > > After my fix this should work in JUnit5 provider. I have pushed a
> > > test project with JUnit5 Suite, activate it via profile "suite", see
> > > https://urldefense.com/v3/__https://github.com/Tibor17/junit5-mockit
> > > o-
> > > examples/commit/c87038b8154ae908ff50bd84e19776dfbddbe779__;!!BhdT!i5
> > > Qv7K
> > > rfNE1_FyC63UP16CRSEh0UxMbSSwKn7EBgkKBuQ2Td7B4-
> > > _p53T9zXVk_Dp0MniLHv6riNYEbn9UVw$
> > >
> > > If there is a Jira ticket pls let me know and I will open a PR on
> > > our GH.
> >
> > Thanks for the variations, I only care about the solution that moves
> > forward with Junit5.
> >
> > You refer to a fix.  Is that something you've put into version
> > 3.0.0-M6-SNAPSHOT that I would need for this to work?  I am attempting
> > to get that version, but I'm having trouble configuring my
> > settings.xml to get this to retrieve from the public repo. We engineer
> > things so that all artifacts are retrieved from our internal artifact
> > repository, which mirrors the public one.  If I need to, I will
> > continue trying to figure that out.
> >
> > I have a feeling you're saying that with Junit5, you were unable to
> > get to the point where you could specify a single test, being a test
> > suite, on the command line, which I believe is why you asked if there
> > is a JIRA ticket for this.  If you confirm that, I will create that
> ticket.
> >
> > I see what you're doing with profiles.  For what we're trying to do
> > here, I can see that this could at least be a functional 1-1
> > replacement for specifying a single test on the command line, but I'd
> > prefer not having to change how we do this, if possible.
> >
> > > On Sun, Mar 20, 2022 at 1:46 AM David Karr
> > > 
> > > wrote:
> > >
> > > > On Sat, Mar 19, 2022 at 5:06 PM Tibor Digana
> > > > 
> > > > wrote:
> > > >
> > > > > My advice is not to listen to everyone but rather understand how
> > > > > things work.
> > > > > Open this link in your browser
> > > > > https://urldefense.com/v3/__https://repo1.maven.org/maven2/org/j
> > > > > unit
> > > > > /platform/__;!!BhdT!i5Qv7KrfNE1_FyC63UP16CRSEh0UxMbSSwKn7EBgkKBu
> > > > > Q2Td 7B4-_p53T9zXVk_Dp0MniLHv6riNYCbWzIuY$
> > > > > It is groupId of some JUnit5 artifacts.
> > > > > Do you see junit-platform-suite-api?
> > > > > Scroll up and you will see junit-platform-suite. What's that?
> > > > > It's the
> > > > impl
> > > > > of the api.
> > > > > So, now you know what you miss in the dependencies.
> > > > >
> > > > > This way just discover the entire hierarchy in
> > > > > https://urldefense.com/v3/__https://repo1.maven.org/maven2/org/j
> > > > &

RE: Can't get Surefire to run any JUnit 5 tests

[KARR, DAVID]

> -Original Message-
> From: Tibor Digana 
> Sent: Sunday, March 20, 2022 6:42 AM
> To: Maven Users List 
> Subject: Re: Can't get Surefire to run any JUnit 5 tests
> 
> There was the same question maybe one week ago.
> I have created an example with JUnit4, see the next, and used the
> configuration parameter ComponentTestSuite where the
> command naturally works:
> 
> mvn -Dtest=ComponentTestSuite test
> 
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.14 s - in pkg.ComponentTestSuite
> 
> After my fix this should work in JUnit5 provider. I have pushed a test
> project with JUnit5 Suite, activate it via profile "suite", see
> https://urldefense.com/v3/__https://github.com/Tibor17/junit5-mockito-
> examples/commit/c87038b8154ae908ff50bd84e19776dfbddbe779__;!!BhdT!i5Qv7K
> rfNE1_FyC63UP16CRSEh0UxMbSSwKn7EBgkKBuQ2Td7B4-
> _p53T9zXVk_Dp0MniLHv6riNYEbn9UVw$
> 
> If there is a Jira ticket pls let me know and I will open a PR on our
> GH.

Thanks for the variations, I only care about the solution that moves forward 
with Junit5.

You refer to a fix.  Is that something you've put into version 
3.0.0-M6-SNAPSHOT that I would need for this to work?  I am attempting to get 
that version, but I'm having trouble configuring my settings.xml to get this to 
retrieve from the public repo. We engineer things so that all artifacts are 
retrieved from our internal artifact repository, which mirrors the public one.  
If I need to, I will continue trying to figure that out.

I have a feeling you're saying that with Junit5, you were unable to get to the 
point where you could specify a single test, being a test suite, on the command 
line, which I believe is why you asked if there is a JIRA ticket for this.  If 
you confirm that, I will create that ticket.

I see what you're doing with profiles.  For what we're trying to do here, I can 
see that this could at least be a functional 1-1 replacement for specifying a 
single test on the command line, but I'd prefer not having to change how we do 
this, if possible.

> On Sun, Mar 20, 2022 at 1:46 AM David Karr 
> wrote:
> 
> > On Sat, Mar 19, 2022 at 5:06 PM Tibor Digana 
> > wrote:
> >
> > > My advice is not to listen to everyone but rather understand how
> > > things work.
> > > Open this link in your browser
> > > https://urldefense.com/v3/__https://repo1.maven.org/maven2/org/junit
> > > /platform/__;!!BhdT!i5Qv7KrfNE1_FyC63UP16CRSEh0UxMbSSwKn7EBgkKBuQ2Td
> > > 7B4-_p53T9zXVk_Dp0MniLHv6riNYCbWzIuY$
> > > It is groupId of some JUnit5 artifacts.
> > > Do you see junit-platform-suite-api?
> > > Scroll up and you will see junit-platform-suite. What's that? It's
> > > the
> > impl
> > > of the api.
> > > So, now you know what you miss in the dependencies.
> > >
> > > This way just discover the entire hierarchy in
> > > https://urldefense.com/v3/__https://repo1.maven.org/maven2/org/junit
> > > /__;!!BhdT!i5Qv7KrfNE1_FyC63UP16CRSEh0UxMbSSwKn7EBgkKBuQ2Td7B4-
> _p53T9zXVk_Dp0MniLHv6riNYGRYa8RR$  and the POMs and their dependencies
> and transitive dependencies.
> > > Then you would understand most of the typical troubles.
> > > No magic, the trick is to read the content of the repo and the
> > > content of POMs.
> > >
> > > I always have to do this when I am helping the users. All the time.
> > > The job starts with this if it is a simple problem. Always the same,
> > > all the time.
> > >
> >
> > Ok, I appreciate that. However, perhaps I didn't emphasize the correct
> > thing in my last response. Fixing the compile error was simple to do.
> > The last problem I have is the problem with running a component test
> > suite from the command line. This is actually the first problem I was
> > made aware of when I first started examining this entire functional
> area.
> >
> >
> > > T
> > >
> > >
> > >
> > >
> > > On Sat, Mar 19, 2022 at 10:57 PM KARR, DAVID  wrote:
> > >
> > > > This is progress.  I at least now see both Junit 5 and Junit 4
> > > > tests running successfully.
> > > >
> > > > I have a couple of related questions, one of which is likely
> > > > entirely Junit-related, but which you might have run into, and the
> > > > other is more
> > > on
> > > > Surefire.
> > > >
> > > > We also have some test suites, which is where we base our
> "component"
> > and
> > > > "integration" tests, neithe

Re: Can't get Surefire to run any JUnit 5 tests

[David Karr]

On Sat, Mar 19, 2022 at 5:06 PM Tibor Digana  wrote:

> My advice is not to listen to everyone but rather understand how things
> work.
> Open this link in your browser
> https://repo1.maven.org/maven2/org/junit/platform/
> It is groupId of some JUnit5 artifacts.
> Do you see junit-platform-suite-api?
> Scroll up and you will see junit-platform-suite. What's that? It's the impl
> of the api.
> So, now you know what you miss in the dependencies.
>
> This way just discover the entire hierarchy in
> https://repo1.maven.org/maven2/org/junit/ and the POMs and their
> dependencies and transitive dependencies.
> Then you would understand most of the typical troubles.
> No magic, the trick is to read the content of the repo and the content of
> POMs.
>
> I always have to do this when I am helping the users. All the time.
> The job starts with this if it is a simple problem. Always the same, all
> the time.
>

Ok, I appreciate that. However, perhaps I didn't emphasize the correct
thing in my last response. Fixing the compile error was simple to do.  The
last problem I have is the problem with running a component test suite from
the command line. This is actually the first problem I was made aware of
when I first started examining this entire functional area.


> T
>
>
>
>
> On Sat, Mar 19, 2022 at 10:57 PM KARR, DAVID  wrote:
>
> > This is progress.  I at least now see both Junit 5 and Junit 4 tests
> > running successfully.
> >
> > I have a couple of related questions, one of which is likely entirely
> > Junit-related, but which you might have run into, and the other is more
> on
> > Surefire.
> >
> > We also have some test suites, which is where we base our "component" and
> > "integration" tests, neither of which run as unit tests.  I'm focusing in
> > the component tests first, but I think whatever we do to fix the
> component
> > tests will be the same for the integration tests.
> >
> > With the dependencies you specified, that results in compile errors for
> > missing classes in "org.junit.platform.suite.api.*".  That is in the
> > "junit-platform-suite-api" dependency.  It's simple enough to include
> that
> > dependency, and that resolves that compile error.  I assume that's the
> best
> > resolution for that?
> >
> > Finally, the issue that is actually one of the first trouble spots we
> > noticed, which is being able to execute test suites from the mvn command
> > line.
> >
> > With Junit4, we would execute our component tests with just this:
> >
> > mvn -Dtest=ComponentTestSuite test
> >
> > With these new frameworks, this fails with "No tests were executed". I've
> > tried numerous variations of this.
> >
> > The minimal class I have is this:
> >
> > import org.junit.platform.suite.api.SelectClasses;
> > import org.junit.platform.suite.api.Suite;
> >
> > @Suite
> > @SelectClasses(NoteResourceCT.class)
> > public class ComponentTestSuite {
> > }
> >
> > I have heard some mentions of "Tags" in Junit5 and "groups" in Surefire.
> > I have experimented with those, but I still haven't gotten anything to
> work.
> >
> > > -Original Message-
> > > From: Tibor Digana 
> > > Sent: Saturday, March 19, 2022 1:55 PM
> > > To: Maven Users List 
> > > Subject: Re: Can't get Surefire to run any JUnit 5 tests
> > >
> > > No problem, pls see the project again, there is an update.
> > > T
> > >
> > > On Sat, Mar 19, 2022 at 9:32 PM KARR, DAVID  wrote:
> > >
> > > > One thing that I see I neglected to mention in this post, but which I
> > > > did mention in the SO posting I linked to, is that I have both Junit5
> > > > and
> > > > Junit4 tests in scope.  I believe that is at least one element that
> > > > makes this more complicated.
> > > >
> > > > > -Original Message-
> > > > > From: Tibor Digana 
> > > > > Sent: Saturday, March 19, 2022 1:27 PM
> > > > > To: Maven Users List 
> > > > > Subject: Re: Can't get Surefire to run any JUnit 5 tests
> > > > >
> > > > > I have created a project which proves that it works with Surefire
> > > > > 3.0.0- M5, JUnit Jupiter 5.8.2 and Mockito Extension. Please do not
> > > > > use JUnit4 and Vintage in this case. It is not necessary to use a
> > >

RE: Can't get Surefire to run any JUnit 5 tests

[KARR, DAVID]

This is progress.  I at least now see both Junit 5 and Junit 4 tests running 
successfully.

I have a couple of related questions, one of which is likely entirely 
Junit-related, but which you might have run into, and the other is more on 
Surefire.

We also have some test suites, which is where we base our "component" and 
"integration" tests, neither of which run as unit tests.  I'm focusing in the 
component tests first, but I think whatever we do to fix the component tests 
will be the same for the integration tests.

With the dependencies you specified, that results in compile errors for missing 
classes in "org.junit.platform.suite.api.*".  That is in the 
"junit-platform-suite-api" dependency.  It's simple enough to include that 
dependency, and that resolves that compile error.  I assume that's the best 
resolution for that?

Finally, the issue that is actually one of the first trouble spots we noticed, 
which is being able to execute test suites from the mvn command line.

With Junit4, we would execute our component tests with just this:

mvn -Dtest=ComponentTestSuite test

With these new frameworks, this fails with "No tests were executed". I've tried 
numerous variations of this.

The minimal class I have is this:

import org.junit.platform.suite.api.SelectClasses;
import org.junit.platform.suite.api.Suite;

@Suite
@SelectClasses(NoteResourceCT.class)
public class ComponentTestSuite {
}

I have heard some mentions of "Tags" in Junit5 and "groups" in Surefire.  I 
have experimented with those, but I still haven't gotten anything to work.

> -Original Message-
> From: Tibor Digana 
> Sent: Saturday, March 19, 2022 1:55 PM
> To: Maven Users List 
> Subject: Re: Can't get Surefire to run any JUnit 5 tests
> 
> No problem, pls see the project again, there is an update.
> T
> 
> On Sat, Mar 19, 2022 at 9:32 PM KARR, DAVID  wrote:
> 
> > One thing that I see I neglected to mention in this post, but which I
> > did mention in the SO posting I linked to, is that I have both Junit5
> > and
> > Junit4 tests in scope.  I believe that is at least one element that
> > makes this more complicated.
> >
> > > -Original Message-
> > > From: Tibor Digana 
> > > Sent: Saturday, March 19, 2022 1:27 PM
> > > To: Maven Users List 
> > > Subject: Re: Can't get Surefire to run any JUnit 5 tests
> > >
> > > I have created a project which proves that it works with Surefire
> > > 3.0.0- M5, JUnit Jupiter 5.8.2 and Mockito Extension. Please do not
> > > use JUnit4 and Vintage in this case. It is not necessary to use a
> > > dependency inside of the plugin. Use a dependency in the project
> POM. Follow it on Github:
> > > https://urldefense.com/v3/__https://github.com/Tibor17/junit5-mockit
> > > o-
> > > examples__;!!BhdT!lvmbYgzuQOyWUX5ZylkdmfaU3sXf2apqjJSFSSrxKI8axKgcOo
> > > SucV
> > > scEb7A3q4WNmPmuxJZAl1LWz6LutPn$
> > >
> > > [INFO] --- maven-surefire-plugin:3.0.0-M5:test (default-test) @
> > > why-is- surefire-not-executing-my-junit5-tests --- [INFO] [INFO]
> > > ---
> > > 
> > > [INFO]  T E S T S
> > > [INFO] ---
> > > [INFO] Running pkg.BDSHelperTest
> > > [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time
> elapsed:
> > > 0.396 s - in pkg.BDSHelperTest
> > > [INFO]
> > > [INFO] Results:
> > > [INFO]
> > > [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 [INFO]
> > > [INFO]
> > > ----
> > > 
> > > [INFO] BUILD SUCCESS
> > > [INFO]
> > > 
> > > 
> > > [INFO] Total time:  6.417 s
> > > [INFO] Finished at: 2022-03-19T21:15:10+01:00 [INFO]
> > > 
> > > 
> > >
> > >
> > > The XML test report:
> > > 
> > >
> > >
> > > Cheers
> > > Tibor
> > >
> > >
> > > On Sat, Mar 19, 2022 at 6:53 AM David Karr
> > > 
> > > wrote:
> > >
> > > > I, along with two other people on my team, have spent days and
> > > > days now trying to figure out why we cannot get Surefire to
> > > > execute JUnit 5
> > > te

RE: Can't get Surefire to run any JUnit 5 tests

[KARR, DAVID]

One thing that I see I neglected to mention in this post, but which I did 
mention in the SO posting I linked to, is that I have both Junit5 and Junit4 
tests in scope.  I believe that is at least one element that makes this more 
complicated.

> -Original Message-
> From: Tibor Digana 
> Sent: Saturday, March 19, 2022 1:27 PM
> To: Maven Users List 
> Subject: Re: Can't get Surefire to run any JUnit 5 tests
> 
> I have created a project which proves that it works with Surefire 3.0.0-
> M5, JUnit Jupiter 5.8.2 and Mockito Extension. Please do not use JUnit4
> and Vintage in this case. It is not necessary to use a dependency inside
> of the plugin. Use a dependency in the project POM. Follow it on Github:
> https://urldefense.com/v3/__https://github.com/Tibor17/junit5-mockito-
> examples__;!!BhdT!lvmbYgzuQOyWUX5ZylkdmfaU3sXf2apqjJSFSSrxKI8axKgcOoSucV
> scEb7A3q4WNmPmuxJZAl1LWz6LutPn$
> 
> [INFO] --- maven-surefire-plugin:3.0.0-M5:test (default-test) @ why-is-
> surefire-not-executing-my-junit5-tests --- [INFO] [INFO] ---
> 
> [INFO]  T E S T S
> [INFO] ---
> [INFO] Running pkg.BDSHelperTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.396 s - in pkg.BDSHelperTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO]
> 
> [INFO] BUILD SUCCESS
> [INFO]
> 
> [INFO] Total time:  6.417 s
> [INFO] Finished at: 2022-03-19T21:15:10+01:00 [INFO]
> ----
> 
> 
> The XML test report:
> 
> 
> 
> Cheers
> Tibor
> 
> 
> On Sat, Mar 19, 2022 at 6:53 AM David Karr 
> wrote:
> 
> > I, along with two other people on my team, have spent days and days
> > now trying to figure out why we cannot get Surefire to execute JUnit 5
> tests.
> > We've all been working independently, so we don't all take the same
> > path, but it didn't really matter, as all three of us are pretty much
> > stuck at the same point.  We can execute JUnit 5 tests in Eclipse, but
> > Surefire just refuses to have anything to do with JUnit 5 tests.
> > We've all read numerous threads and posts on how to do it, and it just
> does not work.
> >
> > Most recently, I posted this question with some details of what I had
> > done so far:
> >
> > https://urldefense.com/v3/__https://stackoverflow.com/questions/715310
> > 01/why-is-surefire-not-executing-my-junit5-tests__;!!BhdT!lvmbYgzuQOyW
> > UX5ZylkdmfaU3sXf2apqjJSFSSrxKI8axKgcOoSucVscEb7A3q4WNmPmuxJZAl1LW5tYnJ
> > oJ$
> > .
> >
> > I have no idea whether the problems lie in JUnit 5, or in Surefire, or
> > some combination.  I wish I could get some debug output that told me
> SOMETHING.
> > It just does not run JUnit 5 tests.
> >

RE: Can't get Surefire to run any JUnit 5 tests

[KARR, DAVID]

> -Original Message-
> From: Dan Tran 
> Sent: Friday, March 18, 2022 11:19 PM
> To: Maven Users List 
> Subject: Re: Can't get Surefire to run any JUnit 5 tests
> 
> may relate to this
> https://urldefense.com/v3/__https://issues.apache.org/jira/browse/SUREFI
> RE-
> 2033__;!!BhdT!mLEXE8D_vVbl6u7278_BIepoVCNKZk6To_hbhGElBPGbdsDrxK28lx3JEM
> u6HtYolJcOnYNvXr8KCg$

This is the only suggestion I've tried so far that at least gives me the 
predicted result, a NPE, without any other problems.

As this was apparently merged several days ago, and M6 (or some equivalent) is 
not out yet, how do I test a snapshot version?

> On Fri, Mar 18, 2022 at 10:53 PM David Karr 
> wrote:
> 
> > I, along with two other people on my team, have spent days and days
> > now trying to figure out why we cannot get Surefire to execute JUnit 5
> tests.
> > We've all been working independently, so we don't all take the same
> > path, but it didn't really matter, as all three of us are pretty much
> > stuck at the same point.  We can execute JUnit 5 tests in Eclipse, but
> > Surefire just refuses to have anything to do with JUnit 5 tests.
> > We've all read numerous threads and posts on how to do it, and it just
> does not work.
> >
> > Most recently, I posted this question with some details of what I had
> > done so far:
> >
> > https://urldefense.com/v3/__https://stackoverflow.com/questions/715310
> > 01/why-is-surefire-not-executing-my-junit5-tests__;!!BhdT!mLEXE8D_vVbl
> > 6u7278_BIepoVCNKZk6To_hbhGElBPGbdsDrxK28lx3JEMu6HtYolJcOnYO4ycyUhg$
> > .
> >
> > I have no idea whether the problems lie in JUnit 5, or in Surefire, or
> > some combination.  I wish I could get some debug output that told me
> SOMETHING.
> > It just does not run JUnit 5 tests.
> >

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

Can't get Surefire to run any JUnit 5 tests

[David Karr]

I, along with two other people on my team, have spent days and days now
trying to figure out why we cannot get Surefire to execute JUnit 5 tests.
We've all been working independently, so we don't all take the same path,
but it didn't really matter, as all three of us are pretty much stuck at
the same point.  We can execute JUnit 5 tests in Eclipse, but Surefire just
refuses to have anything to do with JUnit 5 tests.  We've all read numerous
threads and posts on how to do it, and it just does not work.

Most recently, I posted this question with some details of what I had done
so far:
https://stackoverflow.com/questions/71531001/why-is-surefire-not-executing-my-junit5-tests
.

I have no idea whether the problems lie in JUnit 5, or in Surefire, or some
combination.  I wish I could get some debug output that told me SOMETHING.
It just does not run JUnit 5 tests.

Re: zip file is empty

[David Karr]

On Sun, Feb 27, 2022 at 4:05 PM Nils Breunese  wrote:

> After reading the various responses to this thread with people recognizing
> this issue on various operating systems, I’ve opened an issue in the Maven
> issue tracker: https://issues.apache.org/jira/browse/MNG-7425
>
> Nils.
>
> > Op 18 feb. 2022, om 13:43 heeft Nils Breunese  het
> volgende geschreven:
> >
> > Hi,
> >
> > I’ve been encountering Maven warnings like these for years from time to
> time:
> >
> > 
> > WARN: zip file is empty:
> /Users/username/.m2/repository/com/example/example-artifact/1.2.3/example-artifact-1.2.3.jar
> > java.util.zip.ZipException: zip file is empty
> > 
> >
> > I know that when I encounter this I can just delete the file and run
> Maven again and then it’ll generally download ok, but recently I’ve been
> getting questions from a lot of colleagues with this issue. I was
> wondering: would it make sense for Maven to assume that an empty JAR file
> was not downloaded correctly and try re-downloading it automatically?
> >
> > Nils.
>

Not disagreeing, just pointing out a detail about this. I imagine these
cases are likely zip files that had a "prefix" section, but with no actual
zip file entries, where the "prefix" in this case is just messages about
failed http connections, or something like that.  I only recently
discovered that some zip files can have "prefixes", and sometimes
intentionally. From the point of view of the Java api, it may appear to be
a valid zip file.

Re: Best Maven practices for releasing components/applications when the SCM requires PRs?

[David Hoffer]

What is the benefit/reason to do the release on a separate branch?  Since I
have learned we can bypass the BB PR process for approved users it seems
our problems will be solved.  We aren't currently using gitflow or any
advanced GIT process.  We just use branches for PRs (they are removed after
the merge) and for bug fix releases off from tags/master.

-Dave

On Thu, Oct 21, 2021 at 8:38 AM Jeremy Landis 
wrote:

> Try doing your release on a separate branch instead of using master or if
> you have jenkins pipeline or other automated build system, let it do the
> release with user account that does not have that requirement.  Bitbucket
> allows a user whitelist.
>
> Sent from my Verizon, Samsung Galaxy smartphone
> Get Outlook for Android<https://aka.ms/AAb9ysg>
> ____
> From: David Hoffer 
> Sent: Thursday, October 21, 2021 9:29:45 AM
> To: Maven Users List 
> Subject: Best Maven practices for releasing components/applications when
> the SCM requires PRs?
>
> Our SCM is BitBucket/GIT and normally it does not allow Pushes to Master,
> have to Push to a branch and then do a PR to merge to Master.  However this
> doesn't work with the maven release plugin so we have to turn off the PR
> requirement when performing releases.
>
> What are the best practices for managing this?  We would like to avoid
> having to manually turn something off and then back on again.
>
> Is there a way the plugin can manage this?  Is there a different release
> plugin that can handle the PR process?
>
> Does anyone know if the BitBucket PR process can be bypassed for certain
> users using the maven release plugin?  That might be the simplest solution
> if that is possible.
>
> -Dave
>

Maven best practices for handling component releases?

[David Hoffer]

We have about a dozen applications that use various in-house developed
components which are in a separate component repo.  The component repo has
all of the components (currently about a dozen) and is configured so we can
release each one independently from the others.  (Some components change
often, some rarely.)

If we make changes to a component it stays in SNAPSHOT until the next
application release cycle.  We release all components that changed when we
release the dozen applications.

Some of the components have dependencies on other components and the dozen
apps have various dependencies on the components.

So naturally our release process is a rollup of releases starting at the
bottom component and then updating all components/applications that have a
dependency to the just released version, this keeps going until the top
level apps are released.

So my question is are there tools/practices that can help automate this
release/roll-up process?

-Dave

Re: Best Maven practices for releasing components/applications when the SCM requires PRs?

[David Hoffer]

That is great news.  We don't have a specific CI user yet but your approach
sounds great and we will investigate this, it seems the best and simplest
solution.

Just curious do you do releases manually via command prompt or do you
automate the process with your CI tool?  We use Jenkins but releases are
manual so far for us.

-Dave

On Thu, Oct 21, 2021 at 7:44 AM  wrote:

> Hi Dave,
>
> Does this maven-release part of your workflow runs on CI? If yes, you can
> manually allow specific users to push directly to master, that's what we do
> on our end. We have a specific restricted CI user that we manually allow on
> the branch permissions in bitbucket with write access and keep the PR
> restriction for the rest of the users.
>
> On Thu, Oct 21, 2021 at 9:30 AM David Hoffer  wrote:
>
> > Our SCM is BitBucket/GIT and normally it does not allow Pushes to Master,
> > have to Push to a branch and then do a PR to merge to Master.  However
> this
> > doesn't work with the maven release plugin so we have to turn off the PR
> > requirement when performing releases.
> >
> > What are the best practices for managing this?  We would like to avoid
> > having to manually turn something off and then back on again.
> >
> > Is there a way the plugin can manage this?  Is there a different release
> > plugin that can handle the PR process?
> >
> > Does anyone know if the BitBucket PR process can be bypassed for certain
> > users using the maven release plugin?  That might be the simplest
> solution
> > if that is possible.
> >
> > -Dave
> >
>

Best Maven practices for releasing components/applications when the SCM requires PRs?

[David Hoffer]

Our SCM is BitBucket/GIT and normally it does not allow Pushes to Master,
have to Push to a branch and then do a PR to merge to Master.  However this
doesn't work with the maven release plugin so we have to turn off the PR
requirement when performing releases.

What are the best practices for managing this?  We would like to avoid
having to manually turn something off and then back on again.

Is there a way the plugin can manage this?  Is there a different release
plugin that can handle the PR process?

Does anyone know if the BitBucket PR process can be bypassed for certain
users using the maven release plugin?  That might be the simplest solution
if that is possible.

-Dave

Maven ignores my repo override and tries to keep using Maven Central

[David Koenig]

I have a project that is importing a POM just for its pinned dependency 
versions (my-custom-bom).

my-custom-bom does that for another POM, called another-bom. (I've redacted the 
specific names of things.)

The first set of dependencies are successfully pulled from the internal server, 
the.internal.repo/libs-release. However, once it gets to 'another-bom', it 
starts ignoring this custom repo and going straight to the public Maven Central 
(which obviously doesn't have it). What might be causing that?

Last successful, and first failing, logs:

[DEBUG] Resolving artifact the.package.name:my-custom-bom:pom:0.1.8 from 
[central (https://the.internal.repo/libs-release, default, releases)]
[DEBUG] Using transporter WagonTransporter with priority -1.0 for 
https://the.internal.repo/libs-release
[DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for 
https://the.internal.repo/libs-release
Downloading from central: 
https://the.internal.repo/libs-release/the/package/name/my-custom-bom/0.1.8/my-custom-bom-0.1.8.pom
Downloaded from central: 
https://the.internal.repo/libs-release/the/package/name/my-custom-bom/0.1.8/my-custom-bom-0.1.8.pom
 (2.1 kB at 1.6 kB/s)
[DEBUG] Writing tracking file 
/Users/dmkoenig/.m2/repository/the/package/name/my-custom-bom/0.1.8/_remote.repositories
[DEBUG] Writing tracking file 
/Users/dmkoenig/.m2/repository/the/package/name/my-custom-bom/0.1.8/my-custom-bom-0.1.8.pom.lastUpdated
[DEBUG] Resolving artifact another.package.name:another-bom:pom:1.1.53 from 
[central (https://repo.maven.apache.org/maven2, default, releases)]
[ERROR] Non-resolvable import POM: Could not find artifact 
another.package.name:another-bom:pom:1.1.53 in central 
(https://repo.maven.apache.org/maven2) @ the.package.name:my-custom-bom:0.1.8, 
/Users/dmkoenig/.m2/repository/the/package/name/another-bom/0.1.8/another-bom-0.1.8.pom,
 line 22, column 25

Settings.xml:

http://maven.apache.org/SETTINGS/1.1.0";
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 
http://maven.apache.org/xsd/settings-1.1.0.xsd";
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
  

Re: Maven enforcer plugin regarding child module's groupId

[David Hoffer]

They can delete/change/not do that.   I'd like to put the rule in a parent
POM that enforces in a way that can't easily be removed.

-Dave

On Tue, Aug 31, 2021 at 8:41 AM Delany  wrote:

> Instead of policing deviations with a rule, why not make this possible at
> the outset?
>
> ${project.parent.groupId}.${project.parent.artifactId}
>
> Delany
>
>
> On Tue, 31 Aug 2021 at 16:29, David Hoffer  wrote:
>
> > I'd love to see that added to the included rules in the enforcer plugin.
> >
> > -Dave
> >
> > On Tue, Aug 31, 2021 at 6:53 AM Matt Benson  wrote:
> >
> > > On Tue, Aug 31, 2021, 3:28 AM Delany 
> wrote:
> > >
> > > > Good question. There seems no way to do this dynamically in Maven 3.x
> > > > Delany
> > > >
> > > > On Mon, 30 Aug 2021 at 20:45, David Hoffer 
> wrote:
> > > >
> > > > > How to enforce that child modules append to the parent groupId per
> > the
> > > > > Maven
> > > > > Guide to Naming Conventions
> > > > > <http://maven.apache.org/guides/mini/guide-naming-conventions.html
> >
> > ?
> > > > >
> > > >
> > >
> > > It would seem that writing a custom enforcer rule to do this would be
> > > trivial.
> > >
> > > Matt
> > >
> > >
> > > > -Dave
> > > > >
> > > >
> > >
> >
>

Re: Maven enforcer plugin regarding child module's groupId

[David Hoffer]

I'd love to see that added to the included rules in the enforcer plugin.

-Dave

On Tue, Aug 31, 2021 at 6:53 AM Matt Benson  wrote:

> On Tue, Aug 31, 2021, 3:28 AM Delany  wrote:
>
> > Good question. There seems no way to do this dynamically in Maven 3.x
> > Delany
> >
> > On Mon, 30 Aug 2021 at 20:45, David Hoffer  wrote:
> >
> > > How to enforce that child modules append to the parent groupId per the
> > > Maven
> > > Guide to Naming Conventions
> > > <http://maven.apache.org/guides/mini/guide-naming-conventions.html>  ?
> > >
> >
>
> It would seem that writing a custom enforcer rule to do this would be
> trivial.
>
> Matt
>
>
> > -Dave
> > >
> >
>

Maven enforcer plugin regarding child module's groupId

[David Hoffer]

How to enforce that child modules append to the parent groupId per the Maven
Guide to Naming Conventions
  ?

-Dave

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

[KARR, DAVID]

> -Original Message-
> From: KARR, DAVID 
> Sent: Tuesday, June 15, 2021 8:02 AM
> To: Maven Users List 
> Subject: Where is an exact syntax reference for the "nonProxyHosts"
> property?
> 
> I have been trying to find a fully complete specification for the syntax
> of the "nonProxyHosts" property in the settings.xml file.  Every
> statement I've found, even in Maven documentation, is vague and
> incomplete.  Is this fully documented somewhere?

I suppose I found this.  The statement in the Maven doc does mention "This 
matches the JDK configuration equivalent.", so I was able to find 
https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html
 which has a statement that is specific enough for me.  It would be better if 
this was clear in the Maven documentation.


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

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

[KARR, DAVID]

I have been trying to find a fully complete specification for the syntax of the 
"nonProxyHosts" property in the settings.xml file.  Every statement I've found, 
even in Maven documentation, is vague and incomplete.  Is this fully documented 
somewhere?

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

Re: Maven 3.8.1 + maven-deploy-plugin 3.0.0-M1 and still no SHA256/SHA512

[David Milet]

I figured it out...

With Maven 3.8.1 and maven-deploy-plugin 3.0.0-M1, need to pass
-Daether.checksums.algorithms="SHA256,SHA512"
to the maven options



On Thu, Apr 29, 2021 at 8:35 PM David Milet  wrote:

> Hello,
>
> Maven 3.8.1 picked up new maven-resolver which supports the generation
> (and I suppose, verification) of SHA256 and SHA512 digests. (
> https://issues.apache.org/jira/browse/MRESOLVER-115)
>
> However it seems that maven-deploy-plugin 3.0.0-M1 still uses
> maven-artifact-transfer 0.10.0, which generates MD5 and SHA1 digests
> (removed in 0.13.1 it seems
> https://issues.apache.org/jira/browse/MSHARED-922).
>
> When will maven-deploy-plugin be updated to generate the new digests ?
>
>

Maven 3.8.1 + maven-deploy-plugin 3.0.0-M1 and still no SHA256/SHA512

[David Milet]

Hello,

Maven 3.8.1 picked up new maven-resolver which supports the generation (and
I suppose, verification) of SHA256 and SHA512 digests. (
https://issues.apache.org/jira/browse/MRESOLVER-115)

However it seems that maven-deploy-plugin 3.0.0-M1 still uses
maven-artifact-transfer 0.10.0, which generates MD5 and SHA1 digests
(removed in 0.13.1 it seems
https://issues.apache.org/jira/browse/MSHARED-922).

When will maven-deploy-plugin be updated to generate the new digests ?

Re: Maven internal company component sharing best practices

[David Hoffer]

Following up on this.

First, thanks for the quick and detailed responses.

I have another colleague that suggested we create a single new GIT repo for
the 'library' code that would be a multi-module Maven build, each module
being a component.  My first thought is that it does solve the
'releasability' of components and applications issue but does it allow
granular versioning/releasing of the modules?

In all my experience with multi-module builds they all shared the same
version from the parent and all were released at the same time with the
same version.  However is that a Maven requirement?

I see in the link below in the multi-module projects section that there is
an autoVersionSubmodules flag.  So if that is false how does this work on
the sub-modules?  E.g. it says it will prompt for the new version for each
module but does it allow you to skip modules that didn't have any changes
so no need to release?  E.g. is the release granularity at the module layer?

E.g. if I have 10 components in the multi-module Maven build, can I release
just one and with a version completely independent of the others?

Also just so I know...can the release plugin be run on just one module and
not on the parent?

https://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html

Again just looking for best practices here regarding sharing components and
how they can be versioned independently.

Thanks,
-Dave

On Mon, Apr 12, 2021 at 12:36 PM Mantas Gridinas 
wrote:

> Being in similar situation myself I strongly suggest against storing
> the "library" component in the same place as your application is
> stored, because you will be producing n+1 artifacts every time, where
> n is the modules actually required to build for your application. Your
> application will be moving faster than that library component and you
> will be producing duplicate builds of it, which ultimately just
> consumes space in your artifact repository. The upside of this
> approach is you don't have to worry about transitive dependency
> conflicts.
>
> In our case we host sonatype, put everything there and reference them
> as needed. There are two downsides to this approach, though:
> dependency conflicts and bumping the dependency in dependent
> applications.
>
> Dependency conflicts happen because of several reasons:
> * developer decided to change its artifact/group id starting with some
> version
> * you're importing some dependency pom (like spring, camel, or what
> ever overarching framework provides it)
> * you require several frameworks at the same time
>
> Maven is perfectly capable of resolving those conflicts if artifacts
> actually collide (spring-boot-camel-starter:3.0.0 provides spring boot
> 2.2.1 while you're actually using 2.4.4, and since you have shorter
> path to spring 2.4.4 maven will use that). Problems arise when
> collisions happen between artifacts that contribute to same package
> (ex. ehcache changing its group id between ehcache 2 and ehcache 3) or
> depend on each other indirectly (ex. cxf switching between blocking
> and async calls depending if you have cxf-rt-transports-http-hc on
> your classpath). This is solved by using enforcer plugin with
> dependency convergence rule.
>
> Dependency bumping is a pretty tiring process. Whenever you would
> release a new library version, you would have to go and bump its
> version across all applications and/or libraries that depend on it.
> Since we're in the process of splitting our monorepository, we were
> looking into solutions to automate that. If you're on github, and use
> github as nexus, you can look into dependabot. It's free to use and
> has a lot of configuration options. Since we're not so lucky, we might
> end up using renovate or something similar. The idea is to create a
> pullrequest to dependents whenever a new version of that library is
> released with the bumped version. Upside is you won't have to do
> manual labor of bumping the version, while downside is having a ton of
> noise if you have complicated dependency trees.
>
> These are issues i've encountered so far. You can start by hosting
> your own nexus, uploading artifacts to it and referencing the
> artifacts in the pom. Sonatype offers free solution
> https://www.sonatype.com/products/repository-oss-download. Take care
> of your dependency tree.
>
> On Mon, Apr 12, 2021 at 6:03 PM David Hoffer  wrote:
> >
> > Hey just looking for Maven best practices here, want to be sure I'm not
> > missing something.
> >
> > Here is our use case.
> >
> > We have 10 applications that have duplicate code in each, we want to
> create
> > component(s) for the duplicate code and not duplicate in the 10 apps/G

Maven internal company component sharing best practices

[David Hoffer]

Hey just looking for Maven best practices here, want to be sure I'm not
missing something.

Here is our use case.

We have 10 applications that have duplicate code in each, we want to create
component(s) for the duplicate code and not duplicate in the 10 apps/GIT
any longer.

Each app is in a separate GIT repository & each has a Maven build.  Simple
single module build in each.

To solve this I am assuming we need a new GIT repo for the duplicate code
and a Maven build for it.  That repo and it's component would be released
and then the 10 apps would then depend on that released artifact (SNAPSHOT
until release).

However I have someone here that is saying he wants to not create any other
GIT repo and just make child modules in one of the 10 apps for the shared
code then have the other 9 apps depend on the child module GAV.

However with this approach we would have to 'release' App 1 to get a
release version and then update the other 9 apps to use that app's version
for the component, right?  It seems it causes releasably issues for the
component as no other app can be released until App1 is released first,
correct?

What is the normal pattern in the Maven world when a company wants to share
components between apps when the applications are in separate GIT repos and
therefore have separate Maven builds?

-Dave

How to relocate dependency classes using maven-shade-plugin?

[David Hoffer]

I have a single module Maven build where one of the dependences has well
over 200 transitive dependencies.  These transitive dependencies are
incompatible with the rest of my application.

I would like to use the maven-shade-plugin to create a shaded jar uber jar
that contains all of these dependencies that all have been relocated to a
custom package name.  Then I need the Maven build to include this new
shaded dependency instead of the prior/regular one.

How can I configure the maven-shade-plugin to do this?  So far I have not
gotten it to process dependencies at all only other project code.  I want
it to start relocating at the top level dependency that I specify and have
it include all transitive ones from there.

Any pointers, examples are greatly appreciated.

-Dave

Please release surefire 2.22.3

[David Syer]

This bug fix is kind of important: 
https://issues.apache.org/jira/browse/SUREFIRE-1679

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

Re: Maven plugin to replace text in file

[David Hoffer]

Yeah I was trying to use com.google.code.maven-replacer-plugin but I don't
think that can replace with the variable content found in what is to be
removed.

I'm not familiar with Ant ReplaceRegExp can anyone suggest how to do the
replacement?

-Dave

On Sun, Nov 8, 2020 at 10:19 AM Bernd Eckenfels 
wrote:

> You can use the antrun plugin to run a ant search and replace, or you an
> call a jruby or groovy script. Or is the exec plugin to run a java class.
> The resources plugin can replace placeholders, but that does not sound like
> the right tool for your case.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ____
> Von: David Hoffer 
> Gesendet: Sunday, November 8, 2020 6:00:41 PM
> An: Maven Users List 
> Betreff: Maven plugin to replace text in file
>
> Hi,
>
> I need to process a file during the build to replace constructs like this:
>
> "allOf": [
>   {
> "$ref": "#/definitions/Eligibility"
>   }
> ],
>
> to be:
>
> "$ref": "#/definitions/Eligibility",
>
> Where the $ref can point to anything.  How can I do this sort of writing
> custom code?
>
> -Dave
>

Maven plugin to replace text in file

[David Hoffer]

Hi,

I need to process a file during the build to replace constructs like this:

"allOf": [
  {
"$ref": "#/definitions/Eligibility"
  }
],

to be:

"$ref": "#/definitions/Eligibility",

Where the $ref can point to anything.  How can I do this sort of writing
custom code?

-Dave

maven-assembly-plugin Windows vs Linux

[David Grigglestone]

https://stackoverflow.com/questions/64364051/maven-assembly-plugin-windows-vs-linux 
.. sorry to post in two places, but hoping to get someones attention :-[ ...


I have a project that uses the maven-assembly-plugin and I see a 
difference in behavior when building on Linux vs Windows. Exactly the 
same pom.xml and assembly.xml are used on each platform.


Windows:

mvn logging looks like this:

|[INFO] --- maven-jar-plugin:3.1.0:jar (default-jar) @ foo --- [INFO] 
Building jar: C:\foo\target\foo.jar [INFO] [INFO] --- 
maven-assembly-plugin:3.1.0:single (default) @ foo --- [INFO] Reading 
assembly descriptor: assembly.xml [INFO] Copying files to 
C:\foo\target\foo [WARNING] Assembly file: C:\foo\target\foo is not a 
regular file (it may be a directory). It cannot be attached to the 
project build for installation or deployment. |


And in the target directory I observe a directory C:\foo\target\foo 
which contains all the project's dependent jars.


Linux:

mvn logging looks like this:

|[INFO] --- maven-jar-plugin:3.1.0:jar (default-jar) @ foo --- [INFO] 
Building jar: /home//foo/target/foo.jar [INFO] [INFO] --- 
maven-assembly-plugin:3.1.0:single (default) @ foo --- [INFO] Reading 
assembly descriptor: assembly.xml [INFO] Copying files to 
/home//foo/target/foo-1.0.0001 [WARNING] Assembly file: 
/home//foo/target/foo-1.0.0001 is not a regular file (it may be a 
directory). It cannot be attached to the project build for installation 
or deployment. |


But in the target directory there is no directory target/foo (nor 
target/foo-1.0.001)


I should note that a downstream project is expecting the target/foo 
directory to exist which is why I'm investigating the difference in 
behavior between Windows and Linux.


This is plugin definition in my pom:

| maven-assembly-plugin  
 package  single  
 false  
assembly.xml   
   |


and this is the assembly descriptor:

|xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/3.1.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/3.1.0 
http://maven.apache.org/xsd/assembly-3.1.0.xsd";> tar  
dir  
false   
${project.build.directory}/${project.artifactId}.jar 
./
 false  
${artifact}   
  |


I have tried tinkering with finalName in both the  and 
 sections to no avail and have also tried more recent versions of 
the plugin.


*The urgent question is why does a build on Windows give me the 
target\foo directory with the dependencies in, whilst after a build on 
Linux I don't see the equivalent ?*


Thanks very much for getting this far :-)

Suddenly getting "NoSuchMethodError" from Maven internals without any obvious change

[David Karr]

I've already asked this on StackOverflow (
https://stackoverflow.com/questions/54385789/suddenly-getting-nosuchmethoderror-org-codehaus-plexus-compiler-compilerconfig),
but I'm getting nowhere, and all of our builds are blocked by this.

This is what we're seeing on the CI server:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile
(default-compile) on project CheckoutMs: Execution default-compile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile failed: An API
incompatibility was encountered while executing
org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile:
java.lang.NoSuchMethodError:
org.codehaus.plexus.compiler.CompilerConfiguration.isParameters()Z
[ERROR] -
[ERROR] realm =
plugin>org.apache.maven.plugins:maven-compiler-plugin:3.6.1
[ERROR] strategy =
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] =
file:/home/userid/.m2/repository/org/apache/maven/plugins/maven-compiler-plugin/3.6.1/maven-compiler-plugin-3.6.1.jar
[ERROR] urls[1] =
file:/home/userid/.m2/repository/org/codehaus/groovy/groovy-eclipse-compiler/3.3.0-01/groovy-eclipse-compiler-3.3.0-01.jar
[ERROR] urls[2] =
file:/home/userid/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.6/plexus-component-annotations-1.6.jar
[ERROR] urls[3] =
file:/home/userid/.m2/repository/org/apache/xbean/xbean-reflect/3.7/xbean-reflect-3.7.jar
[ERROR] urls[4] =
file:/home/userid/.m2/repository/com/google/collections/google-collections/1.0/google-collections-1.0.jar
[ERROR] urls[5] =
file:/home/userid/.m2/repository/org/codehaus/groovy/groovy-eclipse-batch/2.5.5-01/groovy-eclipse-batch-2.5.5-01.jar
[ERROR] urls[6] =
file:/home/userid/.m2/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
[ERROR] urls[7] =
file:/home/userid/.m2/repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
[ERROR] urls[8] =
file:/home/userid/.m2/repository/org/codehaus/plexus/plexus-utils/2.0.4/plexus-utils-2.0.4.jar
[ERROR] urls[9] =
file:/home/userid/.m2/repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
[ERROR] urls[10] =
file:/home/userid/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
[ERROR] urls[11] =
file:/home/userid/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
[ERROR] urls[12] =
file:/home/userid/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
[ERROR] urls[13] =
file:/home/userid/.m2/repository/org/apache/maven/shared/maven-shared-utils/3.1.0/maven-shared-utils-3.1.0.jar
[ERROR] urls[14] =
file:/home/userid/.m2/repository/commons-io/commons-io/2.5/commons-io-2.5.jar
[ERROR] urls[15] =
file:/home/userid/.m2/repository/org/apache/maven/shared/maven-shared-incremental/1.1/maven-shared-incremental-1.1.jar
[ERROR] urls[16] =
file:/home/userid/.m2/repository/org/ow2/asm/asm/6.0_ALPHA/asm-6.0_ALPHA.jar
[ERROR] urls[17] =
file:/home/userid/.m2/repository/com/thoughtworks/qdox/qdox/2.0-M5/qdox-2.0-M5.jar
[ERROR] urls[18] =
file:/home/userid/.m2/repository/org/codehaus/plexus/plexus-compiler-api/2.8.1/plexus-compiler-api-2.8.1.jar
[ERROR] urls[19] =
file:/home/userid/.m2/repository/org/codehaus/plexus/plexus-compiler-manager/2.8.1/plexus-compiler-manager-2.8.1.jar
[ERROR] urls[20] =
file:/home/userid/.m2/repository/org/codehaus/plexus/plexus-compiler-javac/2.8.1/plexus-compiler-javac-2.8.1.jar
[ERROR] Number of foreign imports: 1
[ERROR] import: Entry[import  from realm ClassRealm[maven.api, parent:
null]]
---

This started happening in one project, among several, on the first build
after midnight on 1/26.  The previous build, just before midnight, didn't
fail with this.  Jenkins displays all the git commit ids that it checked
out for the builds, and they are identical for both builds. That seems to
indicate that there were no code changes between the successful build and
the failed build.

This is only failing on the CI server, but it's only failing for one
particular project out of several. As far as I can see, it's using Maven
3.3.9, and has been for quite a while.

The application pom doesn't have any of the dependencies listed above,
either direct or indirect.

I did examine the particular class and method mentioned in the error.  That
method is not present in version 2.8.1 of the plexus-api. It was added in
version 2.8.3.  Besides that, I can see no other useful information from
this, or understand how to resolve this.

Re: Generate SonarQube analysis files

[David Karr]

On Wed, Jan 16, 2019 at 11:31 PM Vega Castañeda, Javier <
javier.vega-castan...@capgemini.com> wrote:

> Hello,
>
> I have set up a CI project with Eclipse, Jenkis, Git, Maven, Sonar and
> Nexus.The idea is that files are generated from the sonar analysis as part
> of the build to be able to process those files and send them to
> Elasticsearch. The problem is that I do not know how I can dump that data
> that I see through SonarQube to local files and send those logs to kibana.
> I think that before sending the data to SonarQube it generates a file. I
> would like to know if it is possible to do what I want. The reason for the
> consultation is to create my own dashboards in ELK.
>
> Thanks for your time.
>

Most of the data that SonarQube produces can be obtained through a REST
api.  If you go to any SonarQube view page, and go to the bottom, you
should see a "Web API" link. You'll be able to extract a lot of data from
that, but you'll have to design a data model based on what's available and
what you want to retrieve.


> This message contains information that may be privileged or confidential
> and is the property of the Capgemini Group. It is intended only for the
> person to whom it is addressed. If you are not the intended recipient, you
> are not authorized to read, print, retain, copy, disseminate, distribute,
> or use this message or any part thereof. If you receive this message in
> error, please notify the sender immediately and delete all copies of this
> message.
>

repository problems (ibiblio.org) - redirections , HTTP response codes

[David Balažic]

 notified ibiblio, here:
https://answers.ibiblio.org/questions/2344/missing-maven-artefacts-spring-roo.html
)

Regards,
David

Re: json-schema-generator-maven-plugin has NPE fault

[David Hoffer]

Here is my configuration.  Note I had to add the one excludes because that
is the file that causes the NPE.



com/issinc/odin/display/*.class



com/issinc/odin/messaging/event/msg/EventActionMsgs_Action.class

${project.build.outputDirectory}

${project.build.directory}/generated-resources



Here is EventActionMsgs_Action that causes the NPE.

public enum EventActionMsgs_Action
{
/**
 * Cancel event action msgs action.
 */
CANCEL,
/**
 * Expire event action msgs action.
 */
EXPIRE,
/**
 * Complete event action msgs action.
 */
COMPLETE,
/**
 * Delete event action msgs action.
 */
DELETE;
}

-Dave





On Sat, Mar 24, 2018 at 1:04 PM, Martin Gainty  wrote:

> the failure occurs in io.gravitee.maven.plugins.
> json.schema.generator.mojo.JsonSchemaGeneratorMojo :
>
>
>   Config config = new Config(
> new Globs(getIncludes(), getExcludes()),
> getBuildDirectory(),
> getOutputDirectory(),
> getLog()
> );
> // Then run mapper
> Mapper mapper = new Mapper(config);
> List schemas = mapper.generateJsonSchemas();
> // Finally write JSON Schemas to the configured output directory
> Output output = new Output(config);
> output.write(schemas); //schemas must be a valid schema based on
>  parameters
> ..
> }
>
> in   what is
> includes
> excludes
> buildDirectory
> outputDirectory
>
> ?
> Martin
> ______
>
>
>
>
> --
> *From:* David Hoffer 
> *Sent:* Friday, March 23, 2018 2:10 PM
> *To:* Maven Users List
> *Subject:* Fwd: json-schema-generator-maven-plugin has NPE fault
>
> json-schema-generator-maven-plugin v1.3.0 generates and NPE.  Just trying
> to get feedback to developers.
>
> [ERROR] Failed to execute goal io.gravitee.maven.plugins:
> json-schema-generator-maven-plugin:1.3.0:generate-json-schemas
> (json-schema-generator) on project odin-messaging: Execution
> json-schema-generator of goal io.gravitee.maven.plugins:jso
> n-schema-generator-maven-plugin:1.3.0:generate-json-schemas failed.:
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal io.gravitee.maven.plugins:json-schema-gen
> erator-maven-plugin:1.3.0:generate-json-schemas (json-schema-generator) on
> project odin-messaging: Execution json-schema
> -generator of goal io.gravitee.maven.plugins:json-schema-generator-maven-
> plugin:1.3.0:generate-json-schemas failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.
> buildProject
> (LifecycleModuleBuilder.java:117)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.
> buildProject
> (LifecycleModuleBuilder.java:81)
> at org.apache.maven.lifecycle.internal.builder.singlethreaded.
> SingleThreadedBuilder.build
> (SingleThreadedBuilder.jav
> a:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> json-schema-generator of goal io.gravitee.maven.p
> lugins:json-schema-generator-maven-plugin:1.3.0:generate-json-schemas
> failed.
> at

Fwd: json-schema-generator-maven-plugin has NPE fault

[David Hoffer]

json-schema-generator-maven-plugin v1.3.0 generates and NPE.  Just trying
to get feedback to developers.

[ERROR] Failed to execute goal io.gravitee.maven.plugins:
json-schema-generator-maven-plugin:1.3.0:generate-json-schemas
(json-schema-generator) on project odin-messaging: Execution
json-schema-generator of goal io.gravitee.maven.plugins:jso
n-schema-generator-maven-plugin:1.3.0:generate-json-schemas failed.:
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal io.gravitee.maven.plugins:json-schema-gen
erator-maven-plugin:1.3.0:generate-json-schemas (json-schema-generator) on
project odin-messaging: Execution json-schema
-generator of goal io.gravitee.maven.plugins:json-schema-generator-maven-
plugin:1.3.0:generate-json-schemas failed.
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:213)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.jav
a:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
json-schema-generator of goal io.gravitee.maven.p
lugins:json-schema-generator-maven-plugin:1.3.0:generate-json-schemas
failed.
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:145)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.jav
a:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
Caused by: java.lang.NullPointerException
at 
io.gravitee.maven.plugins.json.schema.generator.mojo.Output.createJsonFile
(Output.java:93)
at 
io.gravitee.maven.plugins.json.schema.generator.mojo.Output.createJsonFiles
(Output.java:78)
at io.gravitee.maven.plugins.json.schema.generator.mojo.Output.write
(Output.java:65)
at i

jacoco-maven-plugin site generation question

[David Hoffer]

I am using jacoco-maven-plugin v0.8.0 to generate test code coverage
reports (and checks) to the build. This is working fine for normal dev
builds, e.g. mvn clean install.

However we also need to include these reports in the Maven site that is
generated and published that part is not working.

The build is a multi-module build and I see you have a link to some ways of
creating an aggregated report, https://github.com/jacoco/
jacoco/wiki/MavenMultiModule, however I am not to the part yet. Right now
I'm just trying to get it to publish the individual reports in the site
build.

The problem is that the site build is including JaCoCo but its labeled
as JaCoCo
Aggregate on each of the modules (and parent) and each of these point to
'target/site/jacoco-aggregate/index.html' however that folder does not
exist. The actual generated report is at target/site/jacoco-ut/index.html.

How can I configure JaCoCo so that it reports the correct name and location
for each report? I have tried various configuration options in the
reporting section but to no avail. It seems hard coded to use
ReportAggregateMojo when it should use ReportMojo (and optionally
ReportITMojo) and I need to provide the outputDirectory when used
indirectly via the site plugin. I will include my config below.

build...


org.jacoco
jacoco-maven-plugin



jacoco-pre-unit-test

prepare-agent




${project.build.directory}/coverage-reports/jacoco-ut.exec

surefireArgLine





jacoco-post-unit-test
test

report





${project.build.directory}/coverage-reports/jacoco-ut.exec


${project.reporting.outputDirectory}/jacoco-ut





jacoco-check
test

check



${project.build.directory}/coverage-reports/jacoco-ut.exec
true



BUNDLE



INSTRUCTION

COVEREDRATIO

${jacoco.percentage.instruction}



BRANCH

COVEREDRATIO

${jacoco.percentage.branch}










jacoco-pre-integration-test
pre-integration-test

prepare-agent



${jacoco.it.execution.data.file}

failsafeArgLine




jacoco-post-integration-test
post-integration-test

report




${jacoco.ut.execution.data.file}


${project.reporting.outputDirectory}/jacoco-it







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


${surefireArgLine}

${skip.unit.tests}


**/IT*.java





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



integration-tests

integration-test
verify



${failsafeArgLine}

${skip.integration.tests}






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



reporting...


org.jacoco
jacoco-maven-plugin
0.8.0



Note I'm not running IT tests yet. But ideally when we do I'd like to be
able to publish both sets of reports in the site.


My command line to generate the site is mvn clean package site

-Dave

RE: IT test in src/test/java is not executed by failsafe:integration-test, or fails oddly with verify

[KARR, DAVID]

> -Original Message-
> From: KARR, DAVID
> Sent: Wednesday, October 25, 2017 10:56 AM
> To: users@maven.apache.org
> Subject: IT test in src/test/java is not executed by
> failsafe:integration-test, or fails oddly with verify
> 
> I work on a large multiproject build that mostly produces OSGi bundle
> artifacts.  The codebase has a lot of unit tests that work fine from the
> build.
> 
> We also have quite a few IT tests, but we only execute those from
> Eclipse, as the nature of the framework makes those tests unreliable.
> 
> I now want to write a small test of IT tests that WILL be run from
> maven, in a CI build.  I verified that the test behaves properly when
> run from Eclipse.
> 
> I put the test in "src/test/java", named it with the "*IT.java" pattern,
> and then tried to run "failsafe:integration-test".  It ran failsafe, but
> it didn't find any tests.
> 
> So, on advice from someone on StackOverflow, I added an "executions"
> block to the plugin declaration.  Adding "integration-test" to the goals
> list didn't make any difference, but when I added "verify" and then ran
> that goal from the command line, I got very odd results.
> 
> The following is an elided version of the pom:
> 
> 
>   http://maven.apache.org/POM/4.0.0http:/
> /maven.apache.org/xsd/maven-
> 4.0.0.xsd"xmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www
> .w3.org/2001/XMLSchema-instance">
>   4.0.0
>   
>   ...
>   
>   usl-features-install
>   usl-features-install
>   https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__maven.apache.org&d=DwIFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> xy2uk0vYF_EA&m=W15vi5llM1SmJsj7-
> g2VFzZ5ukS3vXQL3Rsy29lSpys&s=vk_ZTOxGLHdUOjOv4Env7MsI-5-
> FKM1Di5FmCyO24sA&e= 
>   bundle
>   
>   UTF-
> 8
>   
>   
>   
>   
>   
> org.apache.maven.plugins
>   maven-failsafe-
> plugin
>   2.20.1
>   
>   
>   
>   
> verify
>   
> integration-test
>   
>   
>   
>   
>   
>   org.apache.felix
>   
> maven-bundle-plugin
>   
>   
>   org.codehaus.mojo
>   build-helper-maven-
> plugin
>   
>   
>   
> attach-artifacts
>   package
>   
>   
> attach-artifact
>   
>   
>   
>   ...
>   
>   
>   
>   
>   
>   
>   
>   
> 
> When I run "mvn failsafe:integration-test", I see the following:
> 
> [INFO] -
> ---
>   [INFO] Building usl-features-install 3.1.0-SNAPSHOT
>   [INFO] 
> 
>   [INFO]
>   [INFO] --- maven-failsafe-plugin:2.20.1:integration-test (default-
> cli) @ usl-features-install ---
>   [INFO]
>   [INFO] ---
>   [INFO]  T E S T S
>   [INFO] 

RE: IT test in src/test/java is not executed by failsafe:integration-test, or fails oddly with verify

[KARR, DAVID]

> -Original Message-
> From: Robert Patrick [mailto:robert.patr...@oracle.com]
> Sent: Wednesday, October 25, 2017 11:32 AM
> To: Maven Users List 
> Subject: RE: IT test in src/test/java is not executed by
> failsafe:integration-test, or fails oddly with verify
> 
> In our integration tests' parent POM, we configured the compiler plugin
> to run the test-compile goal:

Thanks for showing how you've configured these plugins, but what in this is 
intended to address the issues that I described?

> 
> org.apache.maven.plugins
> maven-compiler-plugin
> 
> 
> test-compile
> test-compile
> 
> testCompile
> 
> 
> 
> 
> 
> 
> 
> And the failsafe-plugin like this:
> 
> 
> org.apache.maven.plugins
> maven-failsafe-plugin
> 
> 
> system-integration-test
> integration-test
> 
> integration-test
> 
> 
> -Xmx2048m -XX:PermSize=128m -
> XX:MaxPermSize=256m
> 
> 
> ${project.build.directory}
> ${a2c-home}
> 
> 
> 
> java.io.tmpdir
> 
> ${project.build.directory}
> 
> 
> 
> 
> 
> system-test-verify
> verify
> 
> verify
> 
> 
> 
> 
> 
> In each test submodule POM, we simply add the following:
> 
> 
> org.apache.maven.plugins
> maven-compiler-plugin
> 
> 
> org.apache.maven.plugins
> maven-failsafe-plugin
> 
> 
> 
> -Original Message-
> From: KARR, DAVID [mailto:dk0...@att.com]
> Sent: Wednesday, October 25, 2017 12:56 PM
> To: users@maven.apache.org
> Subject: IT test in src/test/java is not executed by
> failsafe:integration-test, or fails oddly with verify
> 
> I work on a large multiproject build that mostly produces OSGi bundle
> artifacts.  The codebase has a lot of unit tests that work fine from the
> build.
> 
> We also have quite a few IT tests, but we only execute those from
> Eclipse, as the nature of the framework makes those tests unreliable.
> 
> I now want to write a small test of IT tests that WILL be run from
> maven, in a CI build.  I verified that the test behaves properly when
> run from Eclipse.
> 
> I put the test in "src/test/java", named it with the "*IT.java" pattern,
> and then tried to run "failsafe:integration-test".  It ran failsafe, but
> it didn't find any tests.
> 
> So, on advice from someone on StackOverflow, I added an "executions"
> block to the plugin declaration.  Adding "integration-test" to the goals
> list didn't make any difference, but when I added "verify" and then ran
> that goal from the command line, I got very odd results.
> 
> The following is an elided version of the pom:
> 
> 
>   http://maven.apache.org/POM/4.0.0http:/
> /maven.apache.org/xsd/maven-
> 4.0.0.xsd"xmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www
> .w3.org/2001/XMLSchema-instance">
>   4.0.0
>   
>   ...
>   
>   usl-features-install
>   usl-features-install
>   https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__maven.apache.org&d=DwIFAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057Sb
> K10&r=Ql5uwmbofQMW0

IT test in src/test/java is not executed by failsafe:integration-test, or fails oddly with verify

[KARR, DAVID]

I work on a large multiproject build that mostly produces OSGi bundle 
artifacts.  The codebase has a lot of unit tests that work fine from the build.

We also have quite a few IT tests, but we only execute those from Eclipse, as 
the nature of the framework makes those tests unreliable.

I now want to write a small test of IT tests that WILL be run from maven, in a 
CI build.  I verified that the test behaves properly when run from Eclipse.

I put the test in "src/test/java", named it with the "*IT.java" pattern, and 
then tried to run "failsafe:integration-test".  It ran failsafe, but it didn't 
find any tests.

So, on advice from someone on StackOverflow, I added an "executions" block to 
the plugin declaration.  Adding "integration-test" to the goals list didn't 
make any difference, but when I added "verify" and then ran that goal from the 
command line, I got very odd results.

The following is an elided version of the pom:


http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd";
xmlns="http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
4.0.0

...

usl-features-install
usl-features-install
http://maven.apache.org
bundle


UTF-8





org.apache.maven.plugins

maven-failsafe-plugin
2.20.1




verify

integration-test





org.apache.felix

maven-bundle-plugin


org.codehaus.mojo

build-helper-maven-plugin



attach-artifacts
package


attach-artifact



...









When I run "mvn failsafe:integration-test", I see the following:

[INFO] 

[INFO] Building usl-features-install 3.1.0-SNAPSHOT
[INFO] 

[INFO] 
[INFO] --- maven-failsafe-plugin:2.20.1:integration-test (default-cli) 
@ usl-features-install ---
[INFO] 
[INFO] ---
[INFO]  T E S T S
[INFO] ---
[INFO] 
[INFO] Results:
[INFO] 
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO] 
[INFO] 

[INFO] BUILD SUCCESS
[INFO] 


Running "mvn verify" did the following:

[INFO] --- maven-failsafe-plugin:2.20.1:integration-test (default) @ 
usl-features-install ---
[INFO] 
[INFO] ---
[INFO]  T E S T S
[INFO] ---
[INFO] 
[INFO] Results:
[INFO] 
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO] 
[INFO] 
[INFO] --- maven-failsafe-plugin:2.20.1:verify (default) @ 
usl-features-install ---
[INFO] 
--

Provided scope not being applied correctly

[David Hoffer]

I have a module that has a provided scope dependency on a zip file (just
resources so no need for any dependencies).  The zip was produced via the
maven-assembly-plugin in another module.

The problem is that transitive dependencies of this zip are being included
in the war being generated.


com.issinc.odin.webservice.client
odin-webservice-client-rd
zip
wsdl
provided


Note its marked as provided so none of its dependencies should be included.

+-
com.issinc.odin.webservice.client:odin-webservice-client-rd:zip:wsdl:2.0-ODIN-SNAPSHOT:provided
[INFO] |  +-
com.issinc.odin.webservice.client:odin-webservice-client-common:jar:2.0-ODIN-SNAPSHOT:provided
[INFO] |  +-
com.issinc.jms.satcat.client.cxf:satcat-client-cxf-common:jar:11.25.0-ODIN-SNAPSHOT:provided
[INFO] |  |  \- org.apache.cxf:cxf-rt-ws-policy:jar:2.7.11:compile
[INFO] |  | +- org.apache.cxf:cxf-api:jar:2.7.11:compile
[INFO] |  | \- org.apache.cxf:cxf-rt-core:jar:2.7.11:compile
[INFO] |  \- org.apache.cxf.xjc-utils:cxf-xjc-runtime:jar:2.7.0:provided
[INFO] | \- javax.xml.bind:jaxb-api:jar:2.1:provided
[INFO] |+- javax.xml.stream:stax-api:jar:1.0-2:provided
[INFO] |\- javax.activation:activation:jar:1.1:provided

Note the 3 compile time dependencies above, these are being included in the
war but should not be because they should be provided.

Ideally when I created the zip I'd like it to have have any dependencies at
all but when using it marking as provided should work too.

I'm using Maven 3.5.0.  What is going on here?

-Dave

Re: How to add class file to build & classpath?

[David Hoffer]

I'll try to reply to the last 3 posts...

Unfortunately the code uses compiled classes from other modules.  So I
can't change the phase to prior to compile, if I do that then it doesn't
generate the sources.

I did find a way to generate sources instead of class files as I agree that
is a lot nicer...its not quite as easy as javassist but close enough.

However I could not find any combination of moving phases around/etc to
make this work...as I mentioned above if I changed the exec plugin phase to
be prior to compile then it didn't do anything so there was no generated
sources to compile.  It seems Maven just just does not like subprocesses
that generate more sources using the compiled code.

I will look at the above sample projects to see what I missed.

For now I have changed things so that I put my generated code right in the
src/main/java folder then wrap the exec plugin in a profile so I can
manually run that when needed.  Not ideal but its working.  Will
investigate the other projects.

-Dave

On Thu, Apr 6, 2017 at 1:27 PM, Robert Patrick 
wrote:

> I also built a little sample project where I simulated a generated class
> using the maven-resources-plugin to copy a class into the target/classes
> directory during the process-resources phase.  My unit test in that module
> works fine and the other module that consumes that class (via a normal
> dependency) works fine in a multi-module build.  Maybe the issue you are
> having can be solved by simply moving the exec-maven-plugin execution to
> the process-resources phase?
>
>
>
> -Original Message-
> From: David Hoffer [mailto:dhoff...@gmail.com]
> Sent: Thursday, April 06, 2017 12:45 PM
> To: Maven Users List
> Subject: Re: How to add class file to build & classpath?
>
> Yes that is the location the class file(s) are being created in.  And yes
> I am binding the exec-maven-plugin to the compile phase in my pom (see
> prior email).  Also the class(s) file is being included in the resulting
> jar.
> However all this is not sufficient for Maven to notice the class(s) file
> was generated and add to the build and classpath.
>
> I think part of the reason is that in multi-module maven builds it does
> not use the jars for the classpath but rather the pre-jar content (not 100%
> certain of that).  However I don't know why Maven doesn't add/use all files
> in the ./target/classes folder but only uses files that it put there itself.
>
> What am I missing here?  It seems this should just work because the files
> are in the ./target/classes folder.
>
> -Dave
>
> On Thu, Apr 6, 2017 at 10:55 AM, Robert Patrick  >
> wrote:
>
> > Can't you generated class files in the expected location (in
> > ${project.build.directory}/classes directory) during the compile phase?
> > I would expect these classes to be included in classpath for later
> > pahses and in the JAR created during the packaging phase of the module
> > build (assuming packaging type is "jar").  Have you tried that?
> >
> >
> >
> > -Original Message-
> > From: Curtis Rueden [mailto:ctrue...@wisc.edu]
> > Sent: Thursday, April 06, 2017 11:34 AM
> > To: Maven Users List
> > Subject: Re: How to add class file to build & classpath?
> >
> > Hi Dave,
> >
> > > I'm using exec-maven-plugin to call a main in my code that uses
> > > javassist to generate a class file at build time.
> >
> > The more common pattern is to generate .java source files, and then
> > include them in the build.
> >
> > Since you are generating .class file(s), could you do it in a separate
> > module of a multi-module build, then add that module as a dependency
> > to your main project module?
> >
> > Could you post an MCVE, particularly your POM, which shows your
> > current approach?
> >
> > Regards,
> > Curtis
> >
> > --
> > Curtis Rueden
> > LOCI software architect - https://urldefense.proofpoint.
> com/v2/url?u=https-3A__urldefense.proofpoint&d=DwIBaQ&c=
> RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
> Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=hpzCbX-p3CruRsEhA_
> MZO805q6XsrzWSSqkZCm7IfAs&s=K-Fe2PmitKUNWXWy2vB1JvN-Ih5TBC0VwxThPwDenU8&e=
> .
> > com/v2/url?u=https-3A__loci.wisc.edu_software&d=DwIBaQ&c=
> > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
> > Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=
> > sAgPJflD39NrfRATxD1qVSvbRHcZlzbPxQqHpteGc0M&s=
> > yDl8PjVnueV1WAKs6W36AGN5yriHr-5eTXTPZi_k0kk&e=
> > ImageJ2 lead, Fiji maintainer - https://urldefense.proofpoint.
> com/v2/url?u=https-3A__urldefense.proofpoint&d=DwIBaQ&c=
&

Re: How to add class file to build & classpath?

[David Hoffer]

Yes that is the location the class file(s) are being created in.  And yes I
am binding the exec-maven-plugin to the compile phase in my pom (see prior
email).  Also the class(s) file is being included in the resulting jar.
However all this is not sufficient for Maven to notice the class(s) file
was generated and add to the build and classpath.

I think part of the reason is that in multi-module maven builds it does not
use the jars for the classpath but rather the pre-jar content (not 100%
certain of that).  However I don't know why Maven doesn't add/use all files
in the ./target/classes folder but only uses files that it put there itself.

What am I missing here?  It seems this should just work because the files
are in the ./target/classes folder.

-Dave

On Thu, Apr 6, 2017 at 10:55 AM, Robert Patrick 
wrote:

> Can't you generated class files in the expected location (in
> ${project.build.directory}/classes directory) during the compile phase?
> I would expect these classes to be included in classpath for later pahses
> and in the JAR created during the packaging phase of the module build
> (assuming packaging type is "jar").  Have you tried that?
>
>
>
> -Original Message-
> From: Curtis Rueden [mailto:ctrue...@wisc.edu]
> Sent: Thursday, April 06, 2017 11:34 AM
> To: Maven Users List
> Subject: Re: How to add class file to build & classpath?
>
> Hi Dave,
>
> > I'm using exec-maven-plugin to call a main in my code that uses
> > javassist to generate a class file at build time.
>
> The more common pattern is to generate .java source files, and then
> include them in the build.
>
> Since you are generating .class file(s), could you do it in a separate
> module of a multi-module build, then add that module as a dependency to
> your main project module?
>
> Could you post an MCVE, particularly your POM, which shows your current
> approach?
>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - https://urldefense.proofpoint.
> com/v2/url?u=https-3A__loci.wisc.edu_software&d=DwIBaQ&c=
> RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
> Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=
> sAgPJflD39NrfRATxD1qVSvbRHcZlzbPxQqHpteGc0M&s=
> yDl8PjVnueV1WAKs6W36AGN5yriHr-5eTXTPZi_k0kk&e=
> ImageJ2 lead, Fiji maintainer - https://urldefense.proofpoint.
> com/v2/url?u=https-3A__imagej.net_User-3ARueden&d=DwIBaQ&c=
> RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
> Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=
> sAgPJflD39NrfRATxD1qVSvbRHcZlzbPxQqHpteGc0M&s=
> biFYk60WuoVvD5FQonUNvMwQmBxfAOcXn6XyvvRRVDw&e=
>
>
> On Thu, Apr 6, 2017 at 10:48 AM, David Hoffer  wrote:
>
> > I'm using exec-maven-plugin to call a main in my code that uses javassist
> > to generate a class file at build time.  My code places the class file in
> > the ./target/classes folder so it gets included in the modules normal
> > binary jar.
> >
> > However the rest of the build and other code needs to know that the class
> > exists.  I've added that module/artifact as a dependency but the build
> and
> > the runtime classpath has no idea that class exists.
> >
> > How do I add it to the build and runtime classpath?
> >
> > -Dave
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: How to add class file to build & classpath?

[David Hoffer]

Yes I know its more common to start with java source files but in this case
that is not possible unless someone knows how to generate sources from a
javassist generated CtClass.  If I could do that then yes I could just add
the sources instead of the class.

Here is the best I have so far and sort of works.  Since my class generator
writes to the target/classes folder I told the exec-maven-plugin that and
now it is part of the build as other modules can use the generated class
but its not a great solution as my IDE does not know about the class so it
shows errors.  So apparently IntelliJ's Maven support does not extend this
sort of exec-maven-plugin configuration.  I need to find a better way to do
this so IDE is happy as well.

Here is the relevant part of my pom.



org.codehaus.mojo
exec-maven-plugin
1.6.0


code-generator
compile

java



com.issinc.odin.display.metadata.generator.UiDisplayMetadataGenerator

true
true

${project.build.directory}/classes






-Dave



On Thu, Apr 6, 2017 at 10:34 AM, Curtis Rueden  wrote:

> Hi Dave,
>
> > I'm using exec-maven-plugin to call a main in my code that uses
> > javassist to generate a class file at build time.
>
> The more common pattern is to generate .java source files, and then include
> them in the build.
>
> Since you are generating .class file(s), could you do it in a separate
> module of a multi-module build, then add that module as a dependency to
> your main project module?
>
> Could you post an MCVE, particularly your POM, which shows your current
> approach?
>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - https://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>
>
> On Thu, Apr 6, 2017 at 10:48 AM, David Hoffer  wrote:
>
> > I'm using exec-maven-plugin to call a main in my code that uses javassist
> > to generate a class file at build time.  My code places the class file in
> > the ./target/classes folder so it gets included in the modules normal
> > binary jar.
> >
> > However the rest of the build and other code needs to know that the class
> > exists.  I've added that module/artifact as a dependency but the build
> and
> > the runtime classpath has no idea that class exists.
> >
> > How do I add it to the build and runtime classpath?
> >
> > -Dave
> >
>

How to add class file to build & classpath?

[David Hoffer]

I'm using exec-maven-plugin to call a main in my code that uses javassist
to generate a class file at build time.  My code places the class file in
the ./target/classes folder so it gets included in the modules normal
binary jar.

However the rest of the build and other code needs to know that the class
exists.  I've added that module/artifact as a dependency but the build and
the runtime classpath has no idea that class exists.

How do I add it to the build and runtime classpath?

-Dave

RE: Strategies for overriding parent plugin configuration in some modules without duplicating config code?

[KARR, DAVID]

> -Original Message-
> From: KARR, DAVID
> Sent: Wednesday, February 22, 2017 11:04 AM
> To: Maven Users List 
> Subject: RE: Strategies for overriding parent plugin configuration in
> some modules without duplicating config code?
> 
> > -Original Message-
> > From: Justin Georgeson [mailto:jgeorge...@lgc.com]
> > Sent: Monday, February 20, 2017 8:40 AM
> > To: Maven Users List 
> > Subject: RE: Strategies for overriding parent plugin configuration in
> > some modules without duplicating config code?
> >
> > Have you looked at combine.children="append" or
> combine.self="override"
> > attributes to the  element?
> >
> > https://urldefense.proofpoint.com/v2/url?u=http-
> > 3A__blog.sonatype.com_2011_01_maven-2Dhow-2Dto-2Dmerging-2Dplugin-
> > 2Dconfiguration-2Din-2Dcomplex-2Dprojects_&d=DQIFAg&c=LFYZ-
> > o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> > xy2uk0vYF_EA&m=FHuWQ_q8B5maEN_es6oJCbGAxMD8fxn8FxP0AQ9VZ3w&s=hQ-
> > pliBIxKnBjdS66GjKAlZqdGHagiZTuPSvxK1SoFU&e=
> > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__maven.apache.org_pom.html&d=DQIFAg&c=LFYZ-
> > o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> > xy2uk0vYF_EA&m=FHuWQ_q8B5maEN_es6oJCbGAxMD8fxn8FxP0AQ9VZ3w&s=GptXYbOIz
> > Ww
> > xSTYZmwZufxSKr6WYerQ_ll_D1fVE-D4&e=
> 
> How do I override the "executions" list?  These properties aren't valid
> there.

If anyone searches for this in the future, I've figured out how to do this.  If 
I need to make an execution defined in the parent do nothing in the child, I 
set it in the child to phase "none".

Yes, this is clearly a hack, but as I intend to make the config in the child 
the default in the very near future, this will hopefully be removed before I 
get hit by a truck. :)

> > -Original Message-
> > From: KARR, DAVID [mailto:dk0...@att.com]
> > Sent: Monday, February 20, 2017 10:33 AM
> > To: Maven Users List 
> > Subject: [EXTERNAL] Strategies for overriding parent plugin
> > configuration in some modules without duplicating config code?
> >
> > External Sender: Use caution with links/attachments.
> >
> >
> >
> > Although my issue is about configuring the "jacoco-maven-plugin", I
> > think it's really more of a pure Maven configuration issue, as I don't
> > think this situation is unique to JaCoCo.
> >
> > I have a somewhat large multi-module project.  Each of the child
> > modules has a parent pom that configures the "jacoco-maven-plugin" to
> > do offline instrumentation (at present, all the modules having unit
> > tests using PowerMock, which doesn't work with online
> instrumentation).
> >
> > I've designed a change that I'll have to make in a few classes in each
> > module that will allow the unit tests to use Mockito, and for JaCoCo
> > to use online instrumentation.  I'll eventually fix all of them to
> > work this way, but it will take a little while.  In the meantime, I
> > just want to override the configuration in the "fixed" modules with
> > online instrumentation and let the other modules use the default of
> > offline instrumentation.
> >
> > The simple-minded way to do this is just to define the same
> > configuration using online instrumentation in each "fixed" module, so
> > it will override the parent pom.  Copying that block to every "fixed"
> > module is not a great idea.  I'd like a solution that requires less
> > code duplication.
> >
> > I suppose I could define ANOTHER parent pom, that specifies the
> > existing parent as its parent, and have that second parent use online
> > instrumentation, and have the fixed modules use that second parent
> > instead.  I will eventually delete this second parent pom once all of
> > the modules are "fixed".
> >
> > Note that I have a separate aggregator pom that is not a parent pom.
> >
> > Are there other reasonable strategies for this "use original parent
> > for some, override in same way for others" situation?
> >
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> > --
> > This e-mail, including any attached files, may contain confidential
> > and privileged information for the sole use of the intended recip

RE: Strategies for overriding parent plugin configuration in some modules without duplicating config code?

[KARR, DAVID]

> -Original Message-
> From: Justin Georgeson [mailto:jgeorge...@lgc.com]
> Sent: Monday, February 20, 2017 8:40 AM
> To: Maven Users List 
> Subject: RE: Strategies for overriding parent plugin configuration in
> some modules without duplicating config code?
> 
> Have you looked at combine.children="append" or combine.self="override"
> attributes to the  element?
> 
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__blog.sonatype.com_2011_01_maven-2Dhow-2Dto-2Dmerging-2Dplugin-
> 2Dconfiguration-2Din-2Dcomplex-2Dprojects_&d=DQIFAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> xy2uk0vYF_EA&m=FHuWQ_q8B5maEN_es6oJCbGAxMD8fxn8FxP0AQ9VZ3w&s=hQ-
> pliBIxKnBjdS66GjKAlZqdGHagiZTuPSvxK1SoFU&e=
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__maven.apache.org_pom.html&d=DQIFAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> xy2uk0vYF_EA&m=FHuWQ_q8B5maEN_es6oJCbGAxMD8fxn8FxP0AQ9VZ3w&s=GptXYbOIzWw
> xSTYZmwZufxSKr6WYerQ_ll_D1fVE-D4&e=

How do I override the "executions" list?  These properties aren't valid there.

> -Original Message-
> From: KARR, DAVID [mailto:dk0...@att.com]
> Sent: Monday, February 20, 2017 10:33 AM
> To: Maven Users List 
> Subject: [EXTERNAL] Strategies for overriding parent plugin
> configuration in some modules without duplicating config code?
> 
> External Sender: Use caution with links/attachments.
> 
> 
> 
> Although my issue is about configuring the "jacoco-maven-plugin", I
> think it's really more of a pure Maven configuration issue, as I don't
> think this situation is unique to JaCoCo.
> 
> I have a somewhat large multi-module project.  Each of the child modules
> has a parent pom that configures the "jacoco-maven-plugin" to do offline
> instrumentation (at present, all the modules having unit tests using
> PowerMock, which doesn't work with online instrumentation).
> 
> I've designed a change that I'll have to make in a few classes in each
> module that will allow the unit tests to use Mockito, and for JaCoCo to
> use online instrumentation.  I'll eventually fix all of them to work
> this way, but it will take a little while.  In the meantime, I just want
> to override the configuration in the "fixed" modules with online
> instrumentation and let the other modules use the default of offline
> instrumentation.
> 
> The simple-minded way to do this is just to define the same
> configuration using online instrumentation in each "fixed" module, so it
> will override the parent pom.  Copying that block to every "fixed"
> module is not a great idea.  I'd like a solution that requires less code
> duplication.
> 
> I suppose I could define ANOTHER parent pom, that specifies the existing
> parent as its parent, and have that second parent use online
> instrumentation, and have the fixed modules use that second parent
> instead.  I will eventually delete this second parent pom once all of
> the modules are "fixed".
> 
> Note that I have a separate aggregator pom that is not a parent pom.
> 
> Are there other reasonable strategies for this "use original parent for
> some, override in same way for others" situation?
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> --
> This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient.  Any
> review, use, distribution, or disclosure by others is strictly
> prohibited.  If you are not the intended recipient (or authorized to
> receive information for the intended recipient), please contact the
> sender by reply e-mail and delete all copies of this message.
> 
> -
> 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: Strategies for overriding parent plugin configuration in some modules without duplicating config code?

[KARR, DAVID]

> -Original Message-
> From: Martin Hoeller [mailto:mar...@xss.co.at]
> Sent: Monday, February 20, 2017 11:44 PM
> To: Maven Users List 
> Subject: Re: Strategies for overriding parent plugin configuration in
> some modules without duplicating config code?
> 
> Hi!
> 
> On Mon, 20 Feb 2017 16:32 "KARR, DAVID"  wrote:
> 
> > Although my issue is about configuring the "jacoco-maven-plugin", I
> > think it's really more of a pure Maven configuration issue, as I don't
> > think this situation is unique to JaCoCo.
> >
> > I have a somewhat large multi-module project.  Each of the child
> > modules has a parent pom that configures the "jacoco-maven-plugin" to
> > do offline instrumentation (at present, all the modules having unit
> > tests using PowerMock, which doesn't work with online
> > instrumentation).
> >
> > I've designed a change that I'll have to make in a few classes in each
> > module that will allow the unit tests to use Mockito, and for JaCoCo
> > to use online instrumentation.  I'll eventually fix all of them to
> > work this way, but it will take a little while.  In the meantime, I
> > just want to override the configuration in the "fixed"
> > modules with online instrumentation and let the other modules use the
> > default of offline instrumentation.
> >
> > The simple-minded way to do this is just to define the same
> > configuration using online instrumentation in each "fixed" module, so
> > it will override the parent pom.  Copying that block to every "fixed"
> > module is not a great idea.  I'd like a solution that requires less
> > code duplication.
> 
> 
> Just two weeks ago Tamás Cservenák pointed out on this list the
> configuration-maven-plugin [1]. I haven't used it myself, but it sounds
> like this plugin could help you saving some code duplication.
> 
> hth,
> - martin
> 
> [1] https://github.com/cstamas/configuration-maven-plugin

It does look promising, but as the README says, this is just a "proof of 
concept" and doesn't appear to be available in mavencentral.

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

RE: Strategies for overriding parent plugin configuration in some modules without duplicating config code?

[KARR, DAVID]

> -Original Message-
> From: Justin Georgeson [mailto:jgeorge...@lgc.com]
> Sent: Monday, February 20, 2017 8:40 AM
> To: Maven Users List 
> Subject: RE: Strategies for overriding parent plugin configuration in
> some modules without duplicating config code?
> 
> Have you looked at combine.children="append" or combine.self="override"
> attributes to the  element?
> 
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__blog.sonatype.com_2011_01_maven-2Dhow-2Dto-2Dmerging-2Dplugin-
> 2Dconfiguration-2Din-2Dcomplex-2Dprojects_&d=DQIFAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> xy2uk0vYF_EA&m=FHuWQ_q8B5maEN_es6oJCbGAxMD8fxn8FxP0AQ9VZ3w&s=hQ-
> pliBIxKnBjdS66GjKAlZqdGHagiZTuPSvxK1SoFU&e=
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__maven.apache.org_pom.html&d=DQIFAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OsTemSXEn-
> xy2uk0vYF_EA&m=FHuWQ_q8B5maEN_es6oJCbGAxMD8fxn8FxP0AQ9VZ3w&s=GptXYbOIzWw
> xSTYZmwZufxSKr6WYerQ_ll_D1fVE-D4&e=

Good to know that mechanism exists, but I don't think it applies to my 
situation.

Still looks like the alternate parent pom has the best balance of tradeoffs, 
for now.

> -Original Message-
> From: KARR, DAVID [mailto:dk0...@att.com]
> Sent: Monday, February 20, 2017 10:33 AM
> To: Maven Users List 
> Subject: [EXTERNAL] Strategies for overriding parent plugin
> configuration in some modules without duplicating config code?
> 
> External Sender: Use caution with links/attachments.
> 
> 
> 
> Although my issue is about configuring the "jacoco-maven-plugin", I
> think it's really more of a pure Maven configuration issue, as I don't
> think this situation is unique to JaCoCo.
> 
> I have a somewhat large multi-module project.  Each of the child modules
> has a parent pom that configures the "jacoco-maven-plugin" to do offline
> instrumentation (at present, all the modules having unit tests using
> PowerMock, which doesn't work with online instrumentation).
> 
> I've designed a change that I'll have to make in a few classes in each
> module that will allow the unit tests to use Mockito, and for JaCoCo to
> use online instrumentation.  I'll eventually fix all of them to work
> this way, but it will take a little while.  In the meantime, I just want
> to override the configuration in the "fixed" modules with online
> instrumentation and let the other modules use the default of offline
> instrumentation.
> 
> The simple-minded way to do this is just to define the same
> configuration using online instrumentation in each "fixed" module, so it
> will override the parent pom.  Copying that block to every "fixed"
> module is not a great idea.  I'd like a solution that requires less code
> duplication.
> 
> I suppose I could define ANOTHER parent pom, that specifies the existing
> parent as its parent, and have that second parent use online
> instrumentation, and have the fixed modules use that second parent
> instead.  I will eventually delete this second parent pom once all of
> the modules are "fixed".
> 
> Note that I have a separate aggregator pom that is not a parent pom.
> 
> Are there other reasonable strategies for this "use original parent for
> some, override in same way for others" situation?
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> --
> This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient.  Any
> review, use, distribution, or disclosure by others is strictly
> prohibited.  If you are not the intended recipient (or authorized to
> receive information for the intended recipient), please contact the
> sender by reply e-mail and delete all copies of this message.
> 
> -
> 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