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)
> at org.apache.

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

[David Karr]

nWithExitCode
(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
> > >
> > > please look at the 

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 the -X switch to enable full debug loggi

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

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

[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 version, as that resolves oth

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: 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?

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?

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

[David Karr]

 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
> > > > > 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/71
> > > > > > 5310
> > > > > >
> 01/why-is-surefire-not-executing-my-junit5-tests__;!!BhdT!lvmbYgzu
> > > > > > QOyW
> > > > > >
> UX5ZylkdmfaU3sXf2apqjJSFSSrxKI8axKgcOoSucVscEb7A3q4WNmPmuxJZAl1LW5
> > > > > > tYnJ
> > > > > > 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.
> > > > > >
> > > >
> >
> > -
> > 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.

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

Re: Need to fully understand bad implications of combined aggregator and parent pom

[David Karr]

Why would there be plugin duplications?  Are you thinking there would
be plugin definitions in the aggregator pom?  The point of the
aggregator pom is that it defines the GAV of the artifact and has the
modules list and NOTHING else.

On Mon, Dec 5, 2016 at 11:27 AM, Mirko Friedenhagen
 wrote:
> Hello,
>
> I use the combined aggregator/parent pom as well. While multiple poms may
> be cleaner because of separation of concerns, you might easily end in
> duplications for e.g. plugin definitions, which is a shame as well.
>
> Regards
> Mirko
> --
> Sent from my mobile
>
> Am 05.12.2016 10:56 schrieb "Sander Verhagen" :
>
>> Simple and easy may be in the eye of the beholder. I get a lot of your
>> points (except for the cycles breaking your build, I'm not recognizing
>> that), but my environment is just dramatically different, and the things
>> that you are describing as necessary for your environment, would be
>> unneeded complexity for mine. We have a lot more entirely separate
>> projects, each of which with their own (smaller) constellation (ancestry)
>> of Maven projects. There's a company POM. Each project has a parent POM,
>> that inherits the company POM, and yes, it's an aggregator too. That's
>> never a problem, because the child projects are all unique and different,
>> and aside from a few shared plugin configurations, that we are perfectly
>> happy to have in the company POM, and a few enforcer rules that we are
>> happy to share across the entire project, all the real meat is in the leaf
>> node POM files. I don’t know what JSP compilation you speak of, nor do we
>> have any significant WAR configuration to be shared across modules. I
>> currently have 716 POM files checked out locally (just a quick "find"),
>> just to give you some feeling that my application of Maven isn't just
>> trivial. But it is DIFFERENT than yours. And I like my shared
>> aggregator/parent POMs. Maybe if it hadn't been designed like this, by
>> Maven, for many years now as it is, whatever the world would look like
>> would've been fine too, but now I'm fond of this approach, to be honest :)
>>
>> One more note, I have learned to be sparse on what to put into the
>> inheritance hierarchy (composition over inheritance, that good stuff), so
>> our parent POMs are also a lot leaner than what I've seen (myself and
>> others do) in the past. Something like this may play into your observations
>> also.
>>
>> Thanks for everyone's perspective on this, it's interesting!
>>
>>
>> Sander Verhagen
>> [  san...@sanderverhagen.net  ]
>>
>> NOTICE: my e-mail address has changed. Please remove verha...@sander.com
>> now and start using san...@sanderverhagen.net from now on. Please update
>> your address book. Thank you!
>>
>> -Original Message-
>> From: Hilco Wijbenga [mailto:hilco.wijbe...@gmail.com]
>> Sent: Sunday, December 4, 2016 17:16
>> To: Maven Users List 
>> Subject: Re: Need to fully understand bad implications of combined
>> aggregator and parent pom
>>
>> Indeed, combining the parent and aggregator concerns in one POM is not a
>> good idea. I would go so far as to call it an anti-pattern. A very common
>> one, unfortunately.
>>
>> First, you get a cycle per module. Cycles are never a good thing, though
>> sometimes they are unavoidable. Maven seems to be fine with this particular
>> type of cycle but you still get strange behaviour on occasion. A build may
>> break (especially when starting with an empty
>> repository) with a strange error message but a second attempt may succeed.
>> That's also (probably) why it is usually not recognised as a problem. If
>> the second build succeeds you tend to shrug your shoulders and move on.
>>
>> Let's say you have an enormous Java file of 10,000 lines of code. I don't
>> think anyone would consider that good design. Similarly, if you have a
>> single project with some 4,000 Java files. Again, I don't think anyone
>> would consider that an example of good design. In both cases, we would
>> argue that it needs to be broken up because, clearly, separate/independent
>> concerns have been conflated. And it is all just too hard to understand,
>> too hard to test, and too hard to maintain.
>>
>> So why would it be a good idea to put all POM related concerns in one
>> place? Especially when it comes to modules, they are *only* relevant at
>> compile time. There is absolutely no reason to know about this at any other
>> time. In fact, my aggregator POMs have a version "modules"
>> (that looks nice in the build output) that never changes and they all set
>> .
>>
>> But it goes beyond that. If you have a JAR project and a WAR project then
>> it makes sense to have a separate parent-jar-pom and parent-war-pom. The
>> parent-jar-pom would only need to know about compiling Java code and
>> putting it in a JAR. Very simple. The parent-war-pom, however, would need
>> to know about JSP compilation
>> (e.g.) and how to 

Re: Why isn't maven-dependency-plugin copying my artifacts anymore?

[David Karr]

Ok. Could you remove the jars and then run it again?

On Thu, Mar 10, 2016, 20:58 Uwe Barthel  wrote:

> Hi David,
>
> I use your pom.xml (but removed parent and org.opendaylight dependencies)
> and it works well with:
>
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T17:41:47+01:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 1.8.0_31, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.3", arch: "x86_64", family: “mac"
>
> $ ls -1 libs/
> antlr4-runtime-4.0.jar
> mapdb-1.0.4.jar
>
> --
> bart...@x-reizend.de
>
>
> > On 11 Mar 2016, at 01:03, David M. Karr 
> wrote:
> >
> > On 03/10/2016 03:54 PM, Mark Eggers wrote:
> >> David,
> >>
> >> I just upgraded to 3.3.9, and ran the following on one of my projects
> >> (twice):
> >>
> >> mvn clean package
> >>
> >> In both cases the JAR files were copied to my output directory and
> >> included in both the zip and tar.gz files.
> >>
> >> I guess a little more information is needed??
> >
> > Ok.  Following this is the entire pom.xml file in question.  Two of the
> artifacts aren't on MavenCentral, but the example could easily be
> simplified to not specify those.
> >
> > --
> > http://maven.apache.org/POM/4.0.0; xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> >  4.0.0
> >
> >  
> >com.cisco.yangide
> >com.cisco.yangide.parent
> >1.1.1-SNAPSHOT
> >../..
> >  
> >
> >  com.cisco.yangide.core
> >  eclipse-plugin
> >  1.1.1-SNAPSHOT
> >  
> >src
> >
> >
> >org.apache.maven.plugins
> >maven-clean-plugin
> >
> >
> >
> >libs
> >
> >
> >
> >
> >
> >org.apache.maven.plugins
> > maven-dependency-plugin
> >2.10
> >
> >
> >copy
> >prepare-package
> >
> >copy
> >
> >
> > libs
> >
> >
> > org.antlr
> > antlr4-runtime
> >4.0
> >jar
> > true
> > antlr4-runtime-4.0.jar
> >
> >
> > org.mapdb
> > mapdb
> >1.0.4
> >jar
> > true
> > mapdb-1.0.4.jar
> >
> >
> > org.opendaylight.yangtools
> > yang-model-api
> >0.6.1
> >jar
> > true
> > yang-model-api-0.6.1.jar
> >
> >
> > org.opendaylight.yangtools
> > yang-parser-impl
> >0.6.1
> >jar
> > true
> > yang-parser-impl-0.6.1.jar
> >
> >
> >
> >
> >
> >
> >
> >  
> > 
> > --
> >>
> >> . . . just my two cents
> >> /mde/
> >>
> >> On 3/10/2016 3:44 PM, David M. Karr wrote:
> >>> On 03/10/2016 03:36 PM, Mark Eggers wrote:
>  David,
> 
>  If you're providing a list of dependencies, then yes you'll use the
> copy
>  instead of copy-dependencies.
> 
>  See the following for that information:
> 
>  https://maven.apache.org/plugins/maven-dependency-plugin/index.html
> 
>  Also, I notice that you don't have outputDirectory specified. If you
>  don't, the dependencies will be copied to
>  ${project.build.directory}/dependency.
> >>> Actually, I was specifying that individually on each artifactItem, but
> >>> it's definitely an improvement to only specify that once.  In any case,
> >>> it still makes no difference.  It's not writing the artifacts, whether
> I
> >>> use "copy" or "copy-dependencies", or whether I say to write them to
> >>> "libs" or "${project.build.directory}/libs". It ("copy", to be
> specific)
> >>> did it the first time I ran this, but never since then.
> >>>
> >>> I'm using Maven 3.3.9, with JDK 1.8.0_60.
> >>>
>  See the following for that information:
> 
> 
> https://maven.apache.org/plugins/maven-dependency-plugin/copy-mojo.html
> 
>  . . . just my two cents
>  /mde/
> 
>  On 3/10/2016 3:22 PM, David M. Karr wrote:
> > Thanks, but replacing my "manual" copy goal with "copy-dependencies"
> and
> > implicit dependency declarations made no difference.  No error at
> this
> > phase, it just doesn't 

Re: build error on strutsel

[David Karr]

One thing I should mention about your use of the Struts-EL library (which
I wrote, like, 15 years ago). It was a stopgap solution to somewhat
integrate Struts with JSP expressions, but only in JSP 1.2 containers.  If
you use it in a JSP 2.0 or newer container, you'll likely get confusing
results.  It should only be used in a JSP1.2 container.

On Fri, Jul 24, 2015 at 2:14 PM Curtis Rueden ctrue...@wisc.edu wrote:

 Hi Hector,

 Maybe you are depending on the wrong version of those libraries? API change
 and evolve; you have to depend on a version compatible with what was
 originally coded against.

 -Curtis

 On Fri, Jul 24, 2015 at 3:04 PM, Magnanao, Hector hector.magna...@sap.com
 
 wrote:

  Hi Curtis,
 
  I have these remaining errors on my compilation.  I can't figure out if
  this is code or package errors.  Can you help me out ?
 
  [ERROR] COMPILATION ERROR :
  [INFO] -
  [ERROR]
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[351,53]
  cannot find symbol
symbol:   method getName()
location: class foundation.web.taglib.struts.html.FormTagEl
  [ERROR]
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[352,18]
  cannot find symbol
symbol: method setName(java.lang.String)
  [ERROR]
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[360,54]
  cannot find symbol
symbol:   method getScope()
location: class foundation.web.taglib.struts.html.FormTagEl
  [ERROR]
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[361,18]
  cannot find symbol
symbol: method setScope(java.lang.String)
  [ERROR]
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[375,53]
  cannot find symbol
symbol:   method getType()
location: class foundation.web.taglib.struts.html.FormTagEl
  [ERROR]
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[376,18]
  cannot find symbol
symbol: method setType(java.lang.String)
  [ERROR]
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/cache/LicenseService.java:[35,23]
  cannot find symbol
symbol:   class License
location: package aspose.pdf
  [ERROR]
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/cache/LicenseService.java:[35,59]
  cannot find symbol
symbol:   class License
location: package aspose.pdf
  [INFO] 8 errors
 
  -Original Message-
  From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On Behalf
  Of Curtis Rueden
  Sent: Friday, July 24, 2015 1:13 PM
  To: Maven Users List
  Subject: Re: build error on strutsel
 
  Hi Hector,
 
   package com.aspose.cells does not exist
 
  Looks like Aspose.Cells is in its own Maven repo from that company:
 
 
 
 http://www.aspose.com/blogs/aspose-products/aspose-total-product-family/archive/2014/08/12/aspose-for-maven-aspose-cloud-maven-repository.html
 
  Found by searching Google for com.aspose.cells maven
 
  Repeat these tricks for all packages you need to find.
 
  -Curtis
 
  On Fri, Jul 24, 2015 at 12:39 PM, Magnanao, Hector 
  hector.magna...@sap.com
  wrote:
 
   Hi Curtis,  that’s ok, I got past that error.  Now I get this one.
  
   [ERROR] Failed to execute goal
   org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
   (default-compile) on project foundation: Compilation failure:
 Compilation
   failure:
   [ERROR]
  
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/cache/LicenseService.java:[3,24]
   package com.aspose.cells does not exist
  
   From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On
 Behalf
   Of Curtis Rueden
   Sent: Friday, July 24, 2015 12:35 PM
   To: Maven Users List
   Subject: Re: build error on strutsel
  
   Hi Hector,
  
I clicked on the link and it returns nothing.
How do I search for it in the repository ?
  
   That's baffling. I see this:
  
   [Inline image 1]
  
   I have no clue why it would be different for you...
  
   Regards,
   Curtis
  
   On Fri, Jul 24, 2015 at 12:31 PM, Magnanao, Hector 
   hector.magna...@sap.commailto:hector.magna...@sap.com wrote:
   Hi Curtis,
  
   I clicked on the link and it returns nothing.  How do I search for it
 in
   the repository ?
  
   -Original Message-
   From: ctrueden.w...@gmail.commailto:ctrueden.w...@gmail.com [mailto:
   ctrueden.w...@gmail.commailto:ctrueden.w...@gmail.com] On Behalf Of
   Curtis Rueden
   Sent: Friday, July 24, 2015 12:17 PM
   To: Maven Users List
   Subject: Re: build error on strutsel
  
   Hi Hector,
  
I can't find it in the maven repository.
  
  
  
 
 http://search.maven.org/#search%7Cga%7C1%7Cfc%3A%22org.apache.strutsel.taglib.utils%22
  
   -Curtis
  
   On Fri, Jul 24, 2015 at 12:11 PM, Magnanao, Hector 
   

Re: Best way to use closed-source jars with maven repository

[David Karr]

It's conceivable you don't have to mess with any sort of repackaging.

The problem is that the MQ classes that your container loads have to be in
a specific location, with a specific name.  Simply deploy your unmodified
application into a container with an altered classpath, where those
special jars are in front of everything else on the classpath.


On Fri, Jul 25, 2014 at 9:07 AM, Steve Cohen sco...@javactivity.org wrote:

 I have a client application that was developed with Websphere MQ.  Our
 company has a Maven nexus repository.  In this repository, we have a place
 to store third party jars.  In here I stored the MQ jars.  Since the
 repository demanded a version number I provided one (7.0.1.8, 7.0.1.9, etc)
 and in each case these version numbers were appended to the jar name.  This
 led to a clean build and deploy process and everyone was happy.

 Now we have need of turning on MQ traces.  It turns out that IBM offers no
 way of doing this unless the jar files are in a single directory named
 exactly as IBM named them in their release.  So we have to repackage the
 application so as to accomplish this.

 Before I jump into hacking this mess into place, is there a recommended
 way of handling this so that the maven repository, maven, and ibm are all
 happy?

 Thanks,
 Steve Cohen

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

Re: Sonar with Maven: Fail to connect to database: Cannot loa d JDBC driver class 'oracle.jdbc.OracleDriver'

[David Karr]

I assume that your Sonar server is not the box you're running Maven on?

What Sonar properties are you setting in your settings.xml?  Feel free to
omit the value for each if you need to.

In the Sonar installation instructions there is a section titled Adding
the JDBC Driver which talks about adding the Oracle JDBC driver to the
SONAR installation.  Have you done this?




On Sat, Dec 7, 2013 at 4:33 AM, Omar@Gmail omarnet...@googlemail.comwrote:

 Objective: Get Maven to publish sonar results to running Sonar server

 Steps:

- Installed and ran Sonar, accessible from browser
   - The back-end database is Oracle
-

Installed and configured Maven in settings.xml file to connect to the
Oracle db
-

Invoked: mvn clean install -DSkipTests=true
- Invoke: mvn sonar:sonar

 But getting following mvn sonar:sonar Fail to connect to database: Cannot
 load JDBC driver class 'oracle.jdbc.OracleDriver'

 So I need somehow to put the ojdbc6.jar on Maven classpath. Tried placing
 the ojdbc6.jar in /lib and lib/ext but did not help.

 Am I missing something here? please help.

 To fix this I modified *maven113home/bin/mvn*.bat at line 161 and added

 %MAVEN_JAVA_EXE% %MAVEN_OPTS% -classpath path/to/ojdbc6.jar;...

 *Which is nasty!*

 Please suggest a better approach.

Re: Sonar with Maven: Fail to connect to database: Cannot loa d JDBC driver class 'oracle.jdbc.OracleDriver'

[David Karr]

I suggest you pursue this on the Sonar user list, then.

On Sun, Dec 8, 2013 at 11:55 AM, Omar@Gmail omarnet...@googlemail.comwrote:

 Thanks David,

 Yes Sonar on separate server.

 Also please see
 http://www.mail-archive.com/users@maven.apache.org/msg132123.html


 On 8 December 2013 18:31, David Karr davidmichaelk...@gmail.com wrote:

  I assume that your Sonar server is not the box you're running Maven on?
 
  What Sonar properties are you setting in your settings.xml?  Feel free to
  omit the value for each if you need to.
 
  In the Sonar installation instructions there is a section titled Adding
  the JDBC Driver which talks about adding the Oracle JDBC driver to the
  SONAR installation.  Have you done this?
 
 
 
 
  On Sat, Dec 7, 2013 at 4:33 AM, Omar@Gmail omarnet...@googlemail.com
  wrote:
 
   Objective: Get Maven to publish sonar results to running Sonar server
  
   Steps:
  
  - Installed and ran Sonar, accessible from browser
 - The back-end database is Oracle
  -
  
  Installed and configured Maven in settings.xml file to connect to
 the
  Oracle db
  -
  
  Invoked: mvn clean install -DSkipTests=true
  - Invoke: mvn sonar:sonar
  
   But getting following mvn sonar:sonar Fail to connect to database:
 Cannot
   load JDBC driver class 'oracle.jdbc.OracleDriver'
  
   So I need somehow to put the ojdbc6.jar on Maven classpath. Tried
 placing
   the ojdbc6.jar in /lib and lib/ext but did not help.
  
   Am I missing something here? please help.
  
   To fix this I modified *maven113home/bin/mvn*.bat at line 161 and added
  
   %MAVEN_JAVA_EXE% %MAVEN_OPTS% -classpath path/to/ojdbc6.jar;...
  
   *Which is nasty!*
  
   Please suggest a better approach.
  
 

Re: maven profiles - load config.properties based on environment

[David Karr]

As Stephen states, and you've realized intuitively, this is not what Maven
is for.

A simple way to do what you're trying to do is simply to package all of the
config files for each environment in your artifact, although perhaps
without the production one (which typically has production credentials).
Design your application to expect a system property that defines what
environment it is running in, like env, with possible values of dev,
test, and prod (many other variations are possible). Make your
application load config-${env}.properties.  For production, configure
Tomcat so your application will have an additional pre-classpath entry that
is controllable by your production deployment team, and place the modified
version of config-prod.properties in that directory.


On Thu, Mar 28, 2013 at 8:08 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 Most likely you are trying to do something that most Maven users would
 consider to be an anti-pattern.

 Please have a read of the following:


 http://stackoverflow.com/questions/14725197/reading-properties-file-from-pom-file-in-maven/14727072#14727072


 http://stackoverflow.com/questions/14650468/whats-a-practicable-way-for-automated-configuration-versioning-and-deployment/14661186#14661186

 The first may steer you away from some property related things that people
 think they should be able to do, though it may not be exactly your context.
 The second is more general, but is actually very relevant to what you are
 trying to do.

 If nether of those seem to address your problem, then you might have to
 seek assistance from other than me as I tend towards grumpy this late in my
 afternoon ;-)

 -Stephen



 On 28 March 2013 14:54, adeelmahmood adeelmahm...@gmail.com wrote:

  I am trying to setup maven profiles in a way that allows me to read a
  properties file based on an environment property e.g. either
  config-dev.properties or config-prod.properties and then have those
  propreties within the config-*.properties files available for the
  application to use. I am kind of new to the maven profiles concept so I
 am
  not sure what the best way is to set something up like this. This is how
 I
  have things setup so far (following
 
 http://www.petrikainulainen.net/programming/maven/running-solr-with-maven/
  )
 
  -- Pom.xml
  profiles
profile
   iddev/id
   activation
 activeByDefaulttrue/activeByDefault
   /activation
   properties
 build.profile.iddev/build.profile.id
   /properties
/profile
profile
   idprod/id
   activation
 property
nameWASENV/name
valuePROD/value
 /property
   /activation
   properties
 build.profile.idprod/build.profile.id
   /properties
/profile
 /profiles
 
  build
finalNamesolr/finalName
 
filters
 
  filter${project.basedir}/src/main/resources/config-${build.profile.id
  }.properties/filter
/filters
resources
   resource
 filteringtrue/filtering
 directorysrc/main/resources/directory
   /resource
/resources
 
  ……
 
  plugin
 groupIdorg.mortbay.jetty/groupId
 artifactIdjetty-maven-plugin/artifactId
 version8.1.8.v20121106/version
 configuration
 
 
  systemPropertiesFile${project.basedir}/src/main/resources/config-${
  build.profile.id}.properties/systemPropertiesFile
stopPort9966/stopPort
stopKeystop/stopKey
connectors
 
   connector
  implementation=org.eclipse.jetty.server.nio.SelectChannelConnector
  port8983/port
 
  maxIdleTime6/maxIdleTime
   /connector
/connectors
webApp
   contextPath/solr/contextPath
/webApp
 /configuration
   /plugin
/plugins
 /build
 
  So first thing I have defined two profiles (dev and prod). Dev is active
 by
  default and prod is activated based on WASENV environment variable/system
  

Re: Create Windows executable JAR

[David Karr]

If you're just trying to build a windows executable, I've been able to use
launch4j to make this happen. It works perfectly fine for what I've used
it for.


On Thu, Feb 7, 2013 at 9:34 AM, Jeff MAURY jeffma...@jeffmaury.com wrote:

 Hello,

 I have the following request:
 I want to build with Maven a Windows executable given the fact that I am
 able to produce an executable JAR.
 I have seen the Codehaus appasembler Maven plugin but it seems it produces
 several files where I want to produce a single .exe file.
 Do you know if such a plugin exists somewhere ?

 Thanks

 --
 Jeff MAURY


 Legacy code often differs from its suggested alternative by actually
 working and scaling.
  - Bjarne Stroustrup

 http://www.jeffmaury.com
 http://riadiscuss.jeffmaury.com
 http://www.twitter.com/jeffmaury

Re: Referencing a parent POM without relativePath

[David Karr]

I had also discovered the difference between the missing vs. empty
relativePath element.  Although it was initially disconcerting that I had
to specify an empty relativePath element to get what I assumed was the
most reasonable behavior, I can also see the logic of the alternative with
the default value. I prefer to separate the notion of parent pom from
aggregator pom (a pom with a list of modules), but if you use a strategy
that combines them, then the default value is more likely.


On Fri, Nov 23, 2012 at 12:34 PM, Eric Kolotyluk
eric.koloty...@gmail.comwrote:

 DOH! I retract that previous message. I forgot to open my VPN connection
 first.

 Putting relativePath/ in the POM does work!

 So, would it be unreasonable if Maven treated the absence of the
 relativePath element the same as relativePath/. That would make it more
 user friendly as far as I am concerned.

 Also, it was m2e that built the original project POM, and it did not put
 relativePath/  in the POM.

 Cheers, Eric



 On 2012-11-23 12:22 PM, Eric Kolotyluk wrote:

 I tried putting relativePath/ in my POM, but it does not fix things.

   parent
 groupIdcom/groupId
 artifactIdkodak/artifactId
 version0.0.11-SNAPSHOT/**version
 relativePath/
   /parent

 I still get

 C:\Users\Eric\workspace\tree-**combo-boxmvn clean
 [INFO] Scanning for projects...
 Downloading: http://repository.ca.kodak.**com:8082/nexus/content/groups/*
 *public/com/kodak/0.0.11-**SNAPSHOT/maven-metadata.xmlhttp://repository.ca.kodak.com:8082/nexus/content/groups/public/com/kodak/0.0.11-SNAPSHOT/maven-metadata.xml
 [WARNING] Could not transfer metadata 
 com:kodak:0.0.11-SNAPSHOT/**maven-metadata.xml
 from/to nexus (http://repository.ca.kodak.**
 com:8082/nexus/content/groups/**publichttp://repository.ca.kodak.com:8082/nexus/content/groups/public):
 repository.ca.kodak.com
 Downloading: http://repository.ca.kodak.**com:8082/nexus/content/groups/*
 *public/com/kodak/0.0.11-**SNAPSHOT/kodak-0.0.11-**SNAPSHOT.pomhttp://repository.ca.kodak.com:8082/nexus/content/groups/public/com/kodak/0.0.11-SNAPSHOT/kodak-0.0.11-SNAPSHOT.pom
 [ERROR] The build could not read 1 project - [Help 1]
 [ERROR]
 [ERROR]   The project 
 net.kolotyluk.experiment:tree-**combo-box:0.0.1-SNAPSHOT
 (C:\Users\Eric\workspace\tree-**combo-box\pom.xml) has 1 error
 [ERROR] Non-resolvable parent POM: Could not transfer artifact
 com:kodak:pom:0.0.11-SNAPSHOT from/to nexus (http://repository.ca.kodak.*
 *com:8082/nexus/content/groups/**publichttp://repository.ca.kodak.com:8082/nexus/content/groups/public):
 repository.ca.kodak.com and 'parent.relativePath' points at no local POM
 @ line 9, column 11: Unknown host repository.ca.kodak.com - [Help 2]
 [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/**
 ProjectBuildingExceptionhttp://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
 [ERROR] [Help 2] http://cwiki.apache.org/**confluence/display/MAVEN/**
 UnresolvableModelExceptionhttp://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException

 It looks like Maven wants to download the Corporate POM because it sees
 it in Nexus, but craps out because it does not like the Project POM. Maven
 seems pretty certain that it wants parent.relativePath to point to a local
 POM.

 Is there a userFriendlytrue/**userFriendly switch I can turn on
 somewhere in Maven ;-)

 Cheers, Eric

 On 2012-11-23 9:05 AM, Laird Nelson wrote:

 On Fri, Nov 23, 2012 at 11:22 AM, Benson Margulies 
 bimargul...@gmail.comwrote:

  You just name the G/A/V and no relativePath, and Maven will download
 just as it would a dependency.

  Well, not exactly; if there is no relativePath element present, then
 Maven behaves as though relativePath../pom.xml/**relativePath were
 specified.  If that file is a working copy that has not been refreshed
 from
 the SCM, then problems can ensue.

 I recall that someone mentioned specifying a relative path like this:

 relativePath/


 ...and that that was the only way to force Maven to truly resolve the pom
 from the repository, but I don't know if this is in fact true.

 Best,
 Laird




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

Re: Maven site can not find parent

[David Karr]

Concerning the empty relativePath element, this will typically be empty
when you can't guarantee that the parent is in the parent directory.  it's
a common practice to separate the responsibilities of the aggregator pom
from the parent pom.  When that is the case, if you don't have the empty
relativePath element, it will fail.


On Sat, Nov 10, 2012 at 3:06 PM, Dennis Lundberg denn...@apache.org wrote:

 Hi

 Why do you use an empty relativePath element?

 If the parent is in the directory above the current project, then just
 omit the relativePath element. Otherwise it must contain the relative
 path to the directory where the parent pom is.

 On 2012-11-01 23:10, Andre Gomes wrote:
 
  I am using the maven-site-plugin version 3.2 in a multi-module project
 that has a parent project. This parent project is a release and it is in a
 release repository and it is in this project that is defined the
 repositories (that is also defined in the settings.xml file). The
 multi-module project is a snapshot and when I run mvn site on the
 multi-module project I am getting the error below saying that can not find
 the parent project, however the parent project is download. When I change
 the parent project version to a snapshot version the error disappear, also
 when I run mvn install in the parent project the error disappear. What I
 want to know is why I am getting this error and how can I solved without
 changing the parent version and running mvn install in the parent.
  Note: In the pom files the relative path is set as empty. And all
 project have the same groupId
 
  Thanks, André Gomes
 
  [INFO] Parent project loaded from
 repository:groupId:parent:pom:1.0.3[DEBUG] Parent project loaded ...[DEBUG]
 Skipped site descriptor for locale en[DEBUG] Skipped remote site descriptor
 check[WARNING] Unable to find a URL to the parent project. The parent
 menuwill NOT be added.[DEBUG] Attempting to load module information from
 local filesystem[DEBUG] Verifying availabilityof
 /home/agomes/.m2/repository/groupId/parent/1.0.3/parent-1.0.3.pom from
 [central (http://repo1.maven.org/maven2, releases)][DEBUG] Skipped remote
 update check forgroupId:parent:pom:1.0.3, locally cached
 artifactup-to-date.[DEBUG] Using connector WagonRepositoryConnector with
 priority 0 forhttp://
 repo1.maven.org/maven2Downloading:http://repo1.maven.org/maven2/groupId/parent/1.0.3/parent-1.0.3.pom[DEBUG]Reading
  resolution trackingfile
 /home/agomes/.m2/repository/groupId/parent/1.0.3/parent-1.0.3.pom.lastUpdated[DEBUG]
 Writing resolution trackingfile
 /home/agomes/.m2/repository/groupId/parent/1.0.3/parent-
  1.0.3.p
 om.lastUpdated[INFO][INFO]
 Reactor Summary:[INFO] [INFO] projectName
 .. FAILURE[12.552s][INFO]
 moduleA  SKIPPED[INFO] moduleB
  ... SKIPPED[INFO] moduleC
  SKIPPED[INFO] moduleD
 ... SKIPPED[INFO] moduleE
 .. SKIPPED[INFO] moduleF
 ...
 SKIPPED[INFO][INFO]
 BUILD
 FAILURE[INFO][INFO]
 Total time: 13.045s[INFO] Finished at: Tue Oct 30 18:39:43 WET 2012[INFO]
 Final Memory:
 26M/247M[INFO][ERROR]
 Failed to execute goalorg.apache.maven.plugins:maven-site-plugin:3.
  1:site (
 default-site) onproject projectName: SiteToolException: Unable to read
 local module-POM: 1problem was encountered while building the effective
 model forgroupId:moduleA:1.1.5-SNAPSHOT[ERROR] [FATAL] Non-resolvable
 parent POM forgroupId:projectName:1.1.5-SNAPSHOT: Could not find
 artifactgroupId:parent:pom:1.0.3 in central(http://repo1.maven.org/maven2)
 @groupId:projectName:1.1.5-SNAPSHOT,
 /home/agomes/workspace/projectName/pom.xml,line 9, column 10[ERROR] for
 project groupId:moduleA:1.1.5-SNAPSHOTat
 /home/agomes/workspace/projectName/moduleA/pom.xml for
 projectgroupId:moduleA:1.1.5-SNAPSHOTat
 /home/agomes/workspace/projectName/moduleA/pom.xml[ERROR] - [Help
 1]org.apache.maven.lifecycle.LifecycleExecutionException: Failed toexecute
 goal org.apache.maven.plugins:maven-site-plugin:3.1:site(default-site) on
 project projectName: SiteToolException: Unable to read
 localmodule-POMatorg.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)atorg.apache.maven.lifecy
  cle.inte
 

Re: Separate unit test / functional test directories?

[David Karr]

On Wed, Apr 4, 2012 at 2:06 PM, Russell Gold russell.g...@oracle.comwrote:

 I see that the maven lifecycle includes separate phases for unit tests and
 functional tests, but I don't see how to take advantage of that. The
 failsafe plugin, as far as I can tell, uses the exact same directories as
 the surefire one. Is there a standard maven way to define a set of unit
 tests and also a separate set of functional tests? If not, what good does
 having separate phases do?


It seems to me that this is one place where you have to add some
configuration. Using the convention by itself won't work. One strategy I
use is to name all of my unit test classes *Test and all my integration
test classes *IntTest.  I then exclude *IntTest from surefire and
include *IntTest in failsafe.  I suppose another approach would be to
name your integration tests *TestInt, and that would allow you to only
specify configuration in failsafe, as surefire would be fine.

Re: Mvn command line options

[David Karr]

On Sat, Mar 24, 2012 at 8:45 AM, sarmahdi sarma...@hotmail.com wrote:

 Hello,

 I did the mvn.bat --help and it gave me  a list of options.

 I need to know that IF i want to write a batch or shell script for three
 different projects. how can i do that.

 /echo Starting Maven build process

 cd c:\demo1\workspace\finApp\
 mvn.bat install

 echo Finish finApp

 cd c:\demo1\workspace\Communications\
 mvn.bat install

 echo Finish Communications/

 It never reaches the the echo Finish finApp even. it stops after
 completing the install on finApp.

 What can I do to actually acheive a script that can build my projects one
 by
 one.


As we're on the Maven list, a better way to do this is to simply define a
new POM project that aggregates the modules you need built.  You would
simply have a modules list with entries like ../finApp and
../Communications. You would place this new module as a peer of finApp
and Communications.  Then, you just do mvn install in your new module.

Re: Error during compiling xsd's using maven xjc

[David Karr]

On Wed, Mar 16, 2011 at 5:40 AM, arvindv6 
arvind.venugo...@verizonbusiness.com wrote:

 Hi

 When i try to compile and generate java files using jaxb through xjc maven
 plugin i am getting the error.

 Please suggest how to use the jaxb:extensionBindingPrefixes by disabling
 the
 strict mode or by using the extension

 The issue is because in the xsd schema in using
 jaxb:extensionBindingPrefixes=xjc as follows:


 [ERROR] file:/C:/mvnExample/SampleConfig.xsd[16,32]
 org.xml.sax.SAXParseException: vendor extension bindings
 (jaxb:extensionBindingPrefixes) are not allowed in the strict mode. Use
 -extension.


If you had googled this error message, you would have found several people
who have had the same problem.  I didn't notice one that was maven-specific,
however.

It would help if you had shown the excerpt of your POM that specifies this
plugin. It sounds like you need to add the extension element (with a value
of true) to the xsdOption element.


at

 com.sun.tools.xjc.reader.AbstractExtensionBindingChecker.error(AbstractExtensionBindingChecker.java:202)
at

 com.sun.tools.xjc.reader.ExtensionBindingChecker.startElement(ExtensionBindingChecker.java:116)
at
 org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:527)
at

 com.sun.tools.xjc.reader.xmlschema.parser.IncorrectNamespaceURIChecker.startElement(IncorrectNamespaceURIChecker.java:113)
at
 org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:527)
at

 com.sun.tools.xjc.reader.xmlschema.parser.CustomizationContextChecker.startElement(CustomizationContextChecker.java:188)
at
 org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:527)
at

 com.sun.tools.xjc.ModelLoader$SpeculationChecker.startElement(ModelLoader.java:455)
at
 org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:527)
at

 com.sun.tools.xjc.reader.internalizer.VersionChecker.startElement(VersionChecker.java:98)
at
 org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:527)
at

 com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:501)
at

 com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:400)
at

 com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDriver.scanRootElementHook(XMLNSDocumentScannerImpl.java:626)
at

 com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:3103)
at

 com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:922)
at

 com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
at

 com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
at

 com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
at

 com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
at

 com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at

 com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
at

 com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
at

 com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:333)
at com.sun.xml.xsom.parser.JAXPParser.parse(JAXPParser.java:115)
at com.sun.tools.xjc.ModelLoader$2.parse(ModelLoader.java:479)
at
 com.sun.tools.xjc.ModelLoader$XMLSchemaParser.parse(ModelLoader.java:262)
at

 com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.parseEntity(NGCCRuntimeEx.java:337)
at
 com.sun.xml.xsom.impl.parser.ParserContext.parse(ParserContext.java:124)
at com.sun.xml.xsom.parser.XSOMParser.parse(XSOMParser.java:183)
at
 com.sun.tools.xjc.ModelLoader.createXSOMSpeculative(ModelLoader.java:496)
at com.sun.tools.xjc.ModelLoader.loadXMLSchema(ModelLoader.java:366)
at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:167)
at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:113)
at com.sun.tools.xjc.Driver.run(Driver.java:313)
at
 org.codehaus.mojo.jaxb2.AbstractXjcMojo.execute(AbstractXjcMojo.java:297)
at

 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)

Strategies for converting from Ant

[David Karr]

I work on a pretty large project that uses Ant for builds. We're doing some
research on converting to Maven.  I'd like to describe some of the elements
of our situation, hopefully to find some conceptual cookbook strategies
for those aspects.

The application consists of the aggregation of several (10-20) separate
SVN/Eclipse projects on a particular branch.  Sometimes a project is used on
the branch, sometimes on the trunk.  The build, when spawned from one of
those projects expects the other projects to exist with expected names in
peer directories (like ../module). In order to complete a build of the
entire application, a developer has to check out all of the projects
required for the build, even if they only do work in one of them.  The plans
for a particular release define which projects will be on the branch, and
which on the trunk.

Although the deployment unit of the application is an EAR, the present build
process uses a vendor-specific assembly mechanism to produce the EAR
modules.  We're examining how/whether we can simplify that part to be more
conventional, but we may have to just figure out how to integrate more
closely with that mechanism so we can control it, instead of replacing it.

Developers use Eclipse on Windows, although the official build and
deployment is on Unix/Solaris.  Developers would likely use the m2eclipse
plugin in Eclipse.

One thing that I'm particularly looking forward to is the ability to just
have to check out a single project from SVN in order to build the entire
application, as I'm hoping it can somehow know to pull subproject builds
from the repo instead of expecting to build the source locally.  I'm not
certain exactly how that will work, but I believe that should be an expected
benefit of this conversion.

I know I've left out a lot of specific details of our environment, but can
you enumerate specific strategies and steps we should be examining?