Re: Retrieving maven.build.timestamp at plugin

[Dan Tran]

It works.

Thank you so much for the quick response. Very much appreciated

-D

On Wed, Nov 22, 2023 at 12:05 PM Slawomir Jaranowski 
wrote:

> Hi,
>
> Please use:
>
> org.apache.maven.execution.MavenSession#getStartTime
>
> There is no property maven.build.timestamp, this value is used only during
> model interpolation.
>
>
> śr., 22 lis 2023 o 20:47 Dan Tran  napisał(a):
>
> > Hi
> >
> > My plugin invokes
> >
> >   this.project.getProperties().getProperty("maven.build.timestamp")
> >
> > It returns NULL.   This means this property is not available
> >
> > is there a way to get it?
> >
> > Thanks
> >
>
>
> --
> Sławomir Jaranowski
>

Retrieving maven.build.timestamp at plugin

[Dan Tran]

Hi

My plugin invokes

  this.project.getProperties().getProperty("maven.build.timestamp")

It returns NULL.   This means this property is not available

is there a way to get it?

Thanks

Re: Maven 3.9.2 - Could not acquire read lock

[Dan Tran]

tModelResolver.resolveModel
> (ProjectModelResolver.java:172)
> 15:33:02  at org.apache.maven.project.ProjectModelResolver.resolveModel
> (ProjectModelResolver.java:218)
> 15:33:02  at
> org.apache.maven.model.building.DefaultModelBuilder.readParentExternally
> (DefaultModelBuilder.java:1009)
> 15:33:02  at
> org.apache.maven.model.building.DefaultModelBuilder.readParent
> (DefaultModelBuilder.java:801)
> 15:33:02  at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:327)
> 15:33:02  at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:243)
> 15:33:02  at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:447)
> 15:33:02  at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:410)
> 15:33:02  at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:367)
> 15:33:02  at org.apache.maven.graph.DefaultGraphBuilder.collectProjects
> (DefaultGraphBuilder.java:349)
> 15:33:02  at
> org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor
> (DefaultGraphBuilder.java:340)
> 15:33:02  at org.apache.maven.graph.DefaultGraphBuilder.build
> (DefaultGraphBuilder.java:76)
> 15:33:02  at org.apache.maven.DefaultMaven.buildGraph
> (DefaultMaven.java:448)
> 15:33:02  at org.apache.maven.DefaultMaven.doExecute
> (DefaultMaven.java:197)
> 15:33:02  at org.apache.maven.DefaultMaven.doExecute
> (DefaultMaven.java:173)
> 15:33:02  at org.apache.maven.DefaultMaven.execute
> (DefaultMaven.java:101)
> 15:33:02  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:910)
> 15:33:02  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> 15:33:02  at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> 15:33:02  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0
> (Native Method)
> 15:33:02  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> 15:33:02  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> 15:33:02  at java.lang.reflect.Method.invoke (Method.java:566)
> 15:33:02  at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> 15:33:02  at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> 15:33:02  at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> 15:33:02  at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348)
> 15:33:02  Suppressed: java.lang.IllegalStateException: Attempt 1: Could
> not acquire write lock for
>
> 'C:\ws\targ-2.2.16\.m2\repository\.locks\com.segway~segway-build~1-SNAPSHOT.lock'
> in 120 SECONDS
>
> Delany
>
>
> On Sat, 27 May 2023 at 08:28, Dan Tran  wrote:
>
> > Hi
> >
> > My multi-threaded build encounters the below failure at the very end of
> the
> > build
> >
> > *05:26:33*  Suppressed: java.lang.IllegalStateException: Attempt
> > 1: Could not acquire read lock for
> > 'artifact:ch.qos.logback:logback-classic:1.2.12' in 150
> > SECONDS*05:26:33*  at
> >
> >
> org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
> > (NamedLockFactoryAdapter.java:202)*05:26:33*  at
> > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> > (DefaultArtifactResolver.java:275)*05:26:33*  at
> > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> > (DefaultArtifactResolver.java:260)*05:26:33*  at
> >
> >
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
> > (DefaultRepositorySystem.java:352)*05:26:33*  at
> > org.apache.maven.project.DefaultProjectDependenciesResolver.resolve
> > (DefaultProjectDependenciesResolver.java:182)*05:26:33*  at
> >
> >
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> > (LifecycleDependencyResolver.java:224)*05:26:33*  at
> >
> >
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> > (LifecycleDependencyResolver.java:136)
> >
> >
> > Some observation
> >
> >
> > 1. Seems to happen only on slow build host/agent
> >
> > 2. The failure is 2/3 into the build where logback-classic is the most
> > common dependency of all modules should be at local already
> >
> > 3. Increase lock time not helping
> >
> > 4. why readlock? instead of writelock
> >
> >
> > Thought?
> >
> >
> > Thanks
> >
> >
> > -D
> >
>

Maven 3.9.2 - Could not acquire read lock

[Dan Tran]

Hi

My multi-threaded build encounters the below failure at the very end of the
build

*05:26:33*  Suppressed: java.lang.IllegalStateException: Attempt
1: Could not acquire read lock for
'artifact:ch.qos.logback:logback-classic:1.2.12' in 150
SECONDS*05:26:33*  at
org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
(NamedLockFactoryAdapter.java:202)*05:26:33*  at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
(DefaultArtifactResolver.java:275)*05:26:33*  at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
(DefaultArtifactResolver.java:260)*05:26:33*  at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
(DefaultRepositorySystem.java:352)*05:26:33*  at
org.apache.maven.project.DefaultProjectDependenciesResolver.resolve
(DefaultProjectDependenciesResolver.java:182)*05:26:33*  at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
(LifecycleDependencyResolver.java:224)*05:26:33*  at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
(LifecycleDependencyResolver.java:136)


Some observation


1. Seems to happen only on slow build host/agent

2. The failure is 2/3 into the build where logback-classic is the most
common dependency of all modules should be at local already

3. Increase lock time not helping

4. why readlock? instead of writelock


Thought?


Thanks


-D

Re: maven-3.9.1 sees Could not acquire write lock for 'artifact:g:a:v

[Dan Tran]

It works on one of my smaller projects that facing the same issue.

However, in order to test with a bigger project, I need an official
3.9.2-SNAPSHOT deployed at apache (long story)

Thank you for the quick fix

-D

On Thu, Mar 23, 2023 at 4:27 AM Tamás Cservenák  wrote:

> You could try out this one, if you can:
> Resolver PR:
> https://github.com/apache/maven-resolver/pull/272
> Then build Maven 3.9.x using built resolver (just modify the POM to use
> resolver 1.9.8-SNAPSHOT)
> https://github.com/apache/maven/tree/maven-3.9.x
>
> https://issues.apache.org/jira/browse/MRESOLVER-346
>
> If you want "baked" ZIP, just ping.
>
> Thanks
> T
>
> On Thu, Mar 23, 2023 at 11:34 AM Tamás Cservenák 
> wrote:
>
> > Dan,
> >
> > iI I provide you with a patched Maven ZIP, or,
> > if I point you to two PRs (one in resolver and one in maven-3.9.x) to
> > build patched Maven locally,
> > could you stick that patched Maven into your env just to try it out?
> >
> > Thanks
> > T
> >
> > On Thu, Mar 23, 2023 at 9:37 AM Tamás Cservenák 
> > wrote:
> >
> >> Ok,
> >>
> >> this is def a timeout on lock:
> >>
> >>
> https://github.com/apache/maven-resolver/blob/e439b343d8d94bdcc82965a3d4f2584c31c319c0/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/named/NamedLockFactoryAdapter.java#L157-L158
> >>
> >> Pls increase the timeout.
> >>
> >> T
> >>
> >> On Thu, Mar 23, 2023 at 9:32 AM Dan Tran  wrote:
> >>
> >>> this is not a single threaded buld
> >>>
> >>> stack trace:
> >>>
> >>> *9:35:34*  [ERROR] Could not acquire write lock for
> >>> 'artifact:ch.qos.logback:logback-classic:1.2.10'*09:35:34*
> >>> java.lang.IllegalStateException: Could not acquire write lock for
> >>> 'artifact:ch.qos.logback:logback-classic:1.2.10'*09:35:34*  at
> >>>
> >>>
> org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
> >>> (NamedLockFactoryAdapter.java:158)*09:35:34*  at
> >>>
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> >>> (DefaultArtifactResolver.java:259)*09:35:34*  at
> >>>
> >>>
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
> >>> (DefaultRepositorySystem.java:352)*09:35:34*  at
> >>>
> >>>
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal
> >>> (DefaultPluginDependenciesResolver.java:212)*09:35:34*  at
> >>>
> >>>
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve
> >>> (DefaultPluginDependenciesResolver.java:158)*09:35:34*  at
> >>>
> >>>
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.createPluginRealm
> >>> (DefaultMavenPluginManager.java:372)*09:35:34*  at
> >>>
> >>>
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.lambda$setupPluginRealm$1
> >>> (DefaultMavenPluginManager.java:335)*09:35:34*  at
> >>> org.apache.maven.plugin.DefaultPluginRealmCache.lambda$get$0
> >>> (DefaultPluginRealmCache.java:156)*09:35:34*  at
> >>> java.util.concurrent.ConcurrentHashMap.computeIfAbsent
> >>> (ConcurrentHashMap.java:1737)*09:35:34*  at
> >>> org.apache.maven.plugin.DefaultPluginRealmCache.get
> >>> (DefaultPluginRealmCache.java:154)*09:35:34*  at
> >>>
> >>>
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.setupPluginRealm
> >>> (DefaultMavenPluginManager.java:334)*09:35:34*  at
> >>> org.apache.maven.plugin.DefaultBuildPluginManager.getPluginRealm
> >>> (DefaultBuildPluginManager.java:205)*09:35:34*  at
> >>> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> >>> (DefaultBuildPluginManager.java:98)*09:35:34*  at
> >>> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> >>> (MojoExecutor.java:342)*09:35:34*  at
> >>> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> >>> (MojoExecutor.java:330)*09:35:34*  at
> >>> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> >>> (MojoExecutor.java:213)*09:35:34*  at
> >>> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> >>> (MojoExecutor.java:175)*09:35:34*  at
> >>> org.apache.maven.lif

Re: maven-3.9.1 sees Could not acquire write lock for 'artifact:g:a:v

[Dan Tran]

*
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native
Method)*09:35:34*  at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)*09:35:34*  at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)*09:35:34*  at
java.lang.reflect.Method.invoke (Method.java:566)*09:35:34*  at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)*09:35:34*  at
org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)*09:35:34*  at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)*09:35:34*  at
org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)*09:35:34*  at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native
Method)*09:35:34*  at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)*09:35:34*  at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)*09:35:34*  at
java.lang.reflect.Method.invoke (Method.java:566)*09:35:34*  at
org.apache.maven.wrapper.BootstrapMainStarter.start
(BootstrapMainStarter.java:52)*09:35:34*  at
org.apache.maven.wrapper.WrapperExecutor.execute
(WrapperExecutor.java:161)*09:35:34*  at
org.apache.maven.wrapper.MavenWrapperMain.main
(MavenWrapperMain.java:73)


thanks


-D


On Wed, Mar 22, 2023 at 3:23 PM Tamás Cservenák  wrote:

> Interesting.
>
> You did not provide any stack, so I just guessed "timeout". For
> increasing/decreasing "wait time" (def is 30 sec), see here:
> https://maven.apache.org/resolver/configuration.html
> Look for "aether.syncContext.named.time" and
> "aether.syncContext.named.time.unit".
> Also good to look at:
> https://maven.apache.org/resolver/maven-resolver-named-locks/index.html
>
> And finally, there are redisson and hazelcast provided locks:
>
> https://maven.apache.org/resolver/maven-resolver-named-locks-redisson/index.html
>
> Also, "So I guess it is using the default file-lock?" -- Maven 3.9.1 does
> NOT use file locking by default, so unless the docker image you use, or
> whatever sets it up
> It would be good to see some stack and what locking is in use.
>
> Note: if it turns out you don't use file locking, but the default (Maven
> 3.9.1 by default uses in-jvm "rwlock-local" (backed by ReadWriteLock), then
> really just increase time
>
> How about concurrency, I guess this is not a single threaded build?
>
> T
>
> PS: Is late here, my response to your response will probably come in my
> morning
>
> On Wed, Mar 22, 2023 at 11:08 PM Dan Tran  wrote:
>
> > Thanks for the quick response
> >
> > This is a simple switch from 3.8.7 to 3.9.1 ( did not see this issue when
> > tested with  3.9.0). So I guess it is using the default file-lock?
> >
> > The build runs inside a docker container on Jenkins agent with no
> antivirus
> > checker. The build always starts from scratch
> >
> > artifact:ch.qos.logback:logback-classic:1.2.10  is common artifact
> > used by all components
> >
> >
> > How do I increase timeout?
> >
> >
> > Thanks
> >
> >
> > -D
> >
> >
> > On Wed, Mar 22, 2023 at 11:44 AM Tamás Cservenák 
> > wrote:
> >
> > > Howdy Dan,
> > >
> > > You did not mention what locking implementation you use, what params
> etc?
> > > file-lock? redisson? something else?
> > >
> > > At the same time, it is rather strange that you mention "at the same
> > > artifact" thing... from here and below I will assume you use file
> locks:
> > > - can you do something like lsof on Linux? Meaning, can you ensure
> > nothing
> > > (some app, IDE or antivirus) is keeping the file open?
> > > - can you tell a bit more about that artifact? Is it installed one?
> Maybe
> > > from the current build? A dependency? In case of HUGE build and COMMON
> > > artifact (ie. slf4j-api) that is used in almost all modules may be
> "hot",
> > > maybe try to increase lock timeout? Or even radically lessen (that
> should
> > > make problem occur more often perhaps)
> > >
> > > HTH
> > > Tamas
> > >
> > > On Wed, Mar 22, 2023 at 7:32 PM Dan Tran  wrote:
> > >
> > > > Hi
> > > >
> > > > My large 400+ modules build facing the mentioned locking issue
> > > consistently
> > > > at the same artifact
> > > >
> > > > artifact:ch.qos.logback:logback-classic:1.2.10
> > > >
> > > >
> > > > any one see this issue at your build?
> > > >
> > > >
> > > > Thanks
> > > >
> > > >
> > > > -D
> > > >
> > > >
> > > > dont see same issue at smaller build
> > > >
> > >
> >
>

Re: maven-3.9.1 sees Could not acquire write lock for 'artifact:g:a:v

[Dan Tran]

Thanks for the quick response

This is a simple switch from 3.8.7 to 3.9.1 ( did not see this issue when
tested with  3.9.0). So I guess it is using the default file-lock?

The build runs inside a docker container on Jenkins agent with no antivirus
checker. The build always starts from scratch

artifact:ch.qos.logback:logback-classic:1.2.10  is common artifact
used by all components


How do I increase timeout?


Thanks


-D


On Wed, Mar 22, 2023 at 11:44 AM Tamás Cservenák 
wrote:

> Howdy Dan,
>
> You did not mention what locking implementation you use, what params etc?
> file-lock? redisson? something else?
>
> At the same time, it is rather strange that you mention "at the same
> artifact" thing... from here and below I will assume you use file locks:
> - can you do something like lsof on Linux? Meaning, can you ensure nothing
> (some app, IDE or antivirus) is keeping the file open?
> - can you tell a bit more about that artifact? Is it installed one? Maybe
> from the current build? A dependency? In case of HUGE build and COMMON
> artifact (ie. slf4j-api) that is used in almost all modules may be "hot",
> maybe try to increase lock timeout? Or even radically lessen (that should
> make problem occur more often perhaps)
>
> HTH
> Tamas
>
> On Wed, Mar 22, 2023 at 7:32 PM Dan Tran  wrote:
>
> > Hi
> >
> > My large 400+ modules build facing the mentioned locking issue
> consistently
> > at the same artifact
> >
> > artifact:ch.qos.logback:logback-classic:1.2.10
> >
> >
> > any one see this issue at your build?
> >
> >
> > Thanks
> >
> >
> > -D
> >
> >
> > dont see same issue at smaller build
> >
>

maven-3.9.1 sees Could not acquire write lock for 'artifact:g:a:v

[Dan Tran]

Hi

My large 400+ modules build facing the mentioned locking issue consistently
at the same artifact

artifact:ch.qos.logback:logback-classic:1.2.10


any one see this issue at your build?


Thanks


-D


dont see same issue at smaller build

Re: maven-wrapper-3.1.1 breaks MVNW_REPOURL?

[Dan Tran]

found this jira - :-)
https://issues.apache.org/jira/projects/MWRAPPER/issues/MWRAPPER-68

-D

On Mon, Jun 13, 2022 at 2:29 AM Dan Tran  wrote:

>
> Hi
>
> After upgrading from 3.1.0 to 3.1.1, we are seeing the following download
> error
>
>
> *23:18:36*  Exception in thread "main" java.io.FileNotFoundException: 
> https://my.comp.com/org/apache/maven/apache-maven/3.8.6/apache-maven-3.8.6-bin.zip
>
>
> where it should be
>
>
> https://my.comp.com/artifactory/public/org/apache/maven/apache-maven/3.8.6/apache-maven-3.8.6-bin.zip
>
>
> anyone facing this issue?
>
>
> Thanks
>
>
> -D
>
>
> very likely due to this change  
> https://github.com/apache/maven-wrapper/commit/22a3268def96e5e648aa97a49d9e146e529b7c87
>
>
>

maven-wrapper-3.1.1 breaks MVNW_REPOURL?

[Dan Tran]

Hi

After upgrading from 3.1.0 to 3.1.1, we are seeing the following download
error


*23:18:36*  Exception in thread "main" java.io.FileNotFoundException:
https://my.comp.com/org/apache/maven/apache-maven/3.8.6/apache-maven-3.8.6-bin.zip


where it should be


https://my.comp.com/artifactory/public/org/apache/maven/apache-maven/3.8.6/apache-maven-3.8.6-bin.zip


anyone facing this issue?


Thanks


-D


very likely due to this change
https://github.com/apache/maven-wrapper/commit/22a3268def96e5e648aa97a49d9e146e529b7c87

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

[Dan Tran]

the latest snapshot is at repository.apache.org/content/groups/snapshots

or use 3.0.0-M4 instead

-D

On Sat, Mar 19, 2022 at 1:32 PM KARR, DAVID  wrote:

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

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

[Dan Tran]

may relate to this  https://issues.apache.org/jira/browse/SUREFIRE-2033

-D

On Fri, Mar 18, 2022 at 10:53 PM David Karr 
wrote:

> I, along with two other people on my team, have spent days and days now
> trying to figure out why we cannot get Surefire to execute JUnit 5 tests.
> We've all been working independently, so we don't all take the same path,
> but it didn't really matter, as all three of us are pretty much stuck at
> the same point.  We can execute JUnit 5 tests in Eclipse, but Surefire just
> refuses to have anything to do with JUnit 5 tests.  We've all read numerous
> threads and posts on how to do it, and it just does not work.
>
> Most recently, I posted this question with some details of what I had done
> so far:
>
> https://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: maven-3.8.5 - multiple instances of mvn locking in each others ??

[Dan Tran]

Filed this issue -  https://issues.apache.org/jira/browse/MNG-7433

thanks

-D

On Tue, Mar 15, 2022 at 7:05 PM Dan Tran  wrote:

>
> Can confirm that   https://github.com/apache/maven/pull/628 is where my
> issue starts to show up. I manage to test my build before and after that PR
>
> The question - is it a bug/regression?
>
> Thanks
>
> -D
>
> On Tue, Mar 15, 2022 at 5:12 PM Dan Tran  wrote:
>
>> Hi
>>
>> I have a large multi modules java maven build where:
>>
>>   * basic build + unit tests  - 40 min
>>   * sonar:sonar 20 min
>>   * final packaging and basic smoke-test - 20 min
>>
>> To take advantage of Maven multi-threaded build , we spin another maven
>> instance to run sonar:sonar right after the basic build is done.
>>
>> This means  sonar:sonar and final packaging + basic test running in
>> parallel sharing same source tree, same local maven repo ( where
>> sonar:sonar should have all needed dependencies to run its task)
>>
>> With maven-3.8.5,  the main maven instance which runs basic build and
>> continues with the final packaging phase hangs waiting for my sonar:sonar
>> mvn instant to complete
>>
>> is it possible that this https://github.com/apache/maven/pull/628 may
>> cause the locking I am seeing?
>>
>> Thanks
>>
>> -D
>>
>>

Re: maven-3.8.5 - multiple instances of mvn locking in each others ??

[Dan Tran]

Can confirm that   https://github.com/apache/maven/pull/628 is where my
issue starts to show up. I manage to test my build before and after that PR

The question - is it a bug/regression?

Thanks

-D

On Tue, Mar 15, 2022 at 5:12 PM Dan Tran  wrote:

> Hi
>
> I have a large multi modules java maven build where:
>
>   * basic build + unit tests  - 40 min
>   * sonar:sonar 20 min
>   * final packaging and basic smoke-test - 20 min
>
> To take advantage of Maven multi-threaded build , we spin another maven
> instance to run sonar:sonar right after the basic build is done.
>
> This means  sonar:sonar and final packaging + basic test running in
> parallel sharing same source tree, same local maven repo ( where
> sonar:sonar should have all needed dependencies to run its task)
>
> With maven-3.8.5,  the main maven instance which runs basic build and
> continues with the final packaging phase hangs waiting for my sonar:sonar
> mvn instant to complete
>
> is it possible that this https://github.com/apache/maven/pull/628 may
> cause the locking I am seeing?
>
> Thanks
>
> -D
>
>

maven-3.8.5 - multiple instances of mvn locking in each others ??

[Dan Tran]

Hi

I have a large multi modules java maven build where:

  * basic build + unit tests  - 40 min
  * sonar:sonar 20 min
  * final packaging and basic smoke-test - 20 min

To take advantage of Maven multi-threaded build , we spin another maven
instance to run sonar:sonar right after the basic build is done.

This means  sonar:sonar and final packaging + basic test running in
parallel sharing same source tree, same local maven repo ( where
sonar:sonar should have all needed dependencies to run its task)

With maven-3.8.5,  the main maven instance which runs basic build and
continues with the final packaging phase hangs waiting for my sonar:sonar
mvn instant to complete

is it possible that this https://github.com/apache/maven/pull/628 may cause
the locking I am seeing?

Thanks

-D

Re: My maven module dependencies got wipe out randomly

[Dan Tran]

Hi Tomo

Thanks for a very good hint.

As I recalled we used to have multithreaded issue with this plugin's where
I had to ensure all modules using this plugin to run in sequence to prevent
the multithreaded issues.  The latest version indicates it is now
threadsafe, and using my trick to sequence the build not working either

Now I need to looking into local repo to see any sign of download
corruption.  it would be a challenge due to its randomness

Love to hear more similar stories from this list

Thanks

-D


On Tue, Oct 13, 2020 at 10:24 AM Tomo Suzuki 
wrote:

> Hi Dan,
>
> (I don't use openapi-generator-maven-plugin)
> I had a similar situation where my Maven plugin (Linkage Checker enforcer
> rule
> <
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/wiki/Linkage-Checker-Enforcer-Rule
> >,
> which reads dependencies of a project) stopped working when I started to
> use Maven's "-T" option. The root cause was that, with multi-threading, JAR
> files in ~/.m2/repository were deleted and recreated while the plugin was
> reading JAR files as another thread was resolving dependencies of another
> project. I figured out that when I checked the timestamp of the error and
> the JAR files. I ended up not running the plugin with multi-thread.
>
> So if your error is about missing files and the files' timestamps were
> close to the time of the error, that might be caused by another project
> being built simultaneously.
>
> Regards,
> Tomo
>
>
>
> On Tue, Oct 13, 2020 at 2:30 AM Dan Tran  wrote:
>
> > Hello to all,
> >
> > I have a 300+ java modules [0] which takes about 2 min to build without
> > tests.  The build randomly failing once a while(%5) where I am able to
> > chase it to the root cause mentioned in the title
> >
> > Further guessing[2] takes me to the removal of one module which
> > uses openapi-generator-maven-plugin-4.3.1[1] and the issue completely
> > disappears.
> >
> > Looking at the plugin source, iI could not figure out anything standing
> > out.
> >
> > Looking for more set of eyes to see if that plugin is thread-safe
> >
> > Appreciate all advice and helps
> >
> > -D
> >
> > [0] error is reproducible with maven 3.6.3 and latest 3.7.0-SNAPSHOT
> >
> > [1]
> >
> >
> https://github.com/OpenAPITools/openapi-generator/blob/v4.3.1/modules/openapi-generator-maven-plugin/src/main/java/org/openapitools/codegen/plugin/CodeGenMojo.java
> >
> > [2] I used to face this type of issue before where a none threadsafe
> plugin
> > can corrupted classpath in reactor mode ( for example:
> > build-number-maven-plugin)
> >
>
>
> --
> Regards,
> Tomo
>

My maven module dependencies got wipe out randomly

[Dan Tran]

Hello to all,

I have a 300+ java modules [0] which takes about 2 min to build without
tests.  The build randomly failing once a while(%5) where I am able to
chase it to the root cause mentioned in the title

Further guessing[2] takes me to the removal of one module which
uses openapi-generator-maven-plugin-4.3.1[1] and the issue completely
disappears.

Looking at the plugin source, iI could not figure out anything standing out.

Looking for more set of eyes to see if that plugin is thread-safe

Appreciate all advice and helps

-D

[0] error is reproducible with maven 3.6.3 and latest 3.7.0-SNAPSHOT

[1]
https://github.com/OpenAPITools/openapi-generator/blob/v4.3.1/modules/openapi-generator-maven-plugin/src/main/java/org/openapitools/codegen/plugin/CodeGenMojo.java

[2] I used to face this type of issue before where a none threadsafe plugin
can corrupted classpath in reactor mode ( for example:
build-number-maven-plugin)

Re: about the new Maven Plugin Testing at https://github.com/khmarbaise/maven-it-extension

[Dan Tran]

the user guide does discuss IDE integration :-)

-D

On Sun, Aug 30, 2020 at 5:19 PM Dan Tran  wrote:

>
> I have been using takari-team for maven-plugin testing for Eclipse,
> however, the eclipse feature is currently stalled or not maintained.
>
> I wonder if the new framework will work with m2e out of the box where I
> can debug my plugin testing?
>
> -D
>
>
>
>

about the new Maven Plugin Testing at https://github.com/khmarbaise/maven-it-extension

[Dan Tran]

I have been using takari-team for maven-plugin testing for Eclipse,
however, the eclipse feature is currently stalled or not maintained.

I wonder if the new framework will work with m2e out of the box where I can
debug my plugin testing?

-D

Re: Strange maven sonar download warning?

[Dan Tran]

@ Enrico  I have clean builds

@Bernd thanks for the hint, the '?' must be a hidden char sitting in my
pom.  When overriding from outside ( -Dkey=value) dont see this issue

I have a good clue now

Thanks

-D




On Sat, Aug 29, 2020 at 11:34 PM Bernd Eckenfels 
wrote:

> Wonder where the questionmark is coming from... is there somewhere in the
> Pom?
>
>
> --
> http://bernd.eckenfels.net
> 
> Von: Enrico Olivelli 
> Gesendet: Sunday, August 30, 2020 8:24:49 AM
> An: Maven Users List 
> Betreff: Re: Strange maven sonar download warning?
>
> Il Dom 30 Ago 2020, 05:52 Dan Tran  ha scritto:
>
> > don't see similar warnings when using with sonar-maven-plugin-3.6.x
> >
> > -D
> >
> > On Sat, Aug 29, 2020 at 8:13 PM Dan Tran  wrote:
> >
> > >
> > > Hello to all
> > >
> > > I am seeing the bellow warning at my build with no build failure.
> Wonder
> > > if anyone else sees the same thing?
> > >
> > > *19:22:30*  [WARNING] The POM for
> > org.sonarsource.scanner.maven:sonar-maven-plugin:jar:?3.7.0.1746 is
> > missing, no dependency information available*19:22:30*  [WARNING] Failed
> to
> > retrieve plugin descriptor for
> > org.sonarsource.scanner.maven:sonar-maven-plugin:?3.7.0.1746: Plugin
> > org.sonarsource.scanner.maven:sonar-maven-plugin:?3.7.0.1746 or one of
> its
> > dependencies could not be resolved: Failure to find
> > org.sonarsource.scanner.maven:sonar-maven-plugin:jar:?3.7.0.1746 in
> > https://my.inernal.maven <https://ap-sc.lss.emc.com/artifactory/public
> >.repo
> > was cached in the local repository, resolution will not be reattempted
> > until the update interval of brs has elapsed or updates are forced
> >
>
> Probably you had problems during the download of some file.
>
> You can try to run your build with -U flag or clean up your .m2/repository
> directory, this way you will start with a clean local repository (that's
> basically a cache)
>
> Enrico
>
>
> >
> > >
> > > Thanks
> > >
> > >
> > > -D
> > >
> > >
> >
>

Re: Strange maven sonar download warning?

[Dan Tran]

don't see similar warnings when using with sonar-maven-plugin-3.6.x

-D

On Sat, Aug 29, 2020 at 8:13 PM Dan Tran  wrote:

>
> Hello to all
>
> I am seeing the bellow warning at my build with no build failure.  Wonder
> if anyone else sees the same thing?
>
> *19:22:30*  [WARNING] The POM for 
> org.sonarsource.scanner.maven:sonar-maven-plugin:jar:?3.7.0.1746 is missing, 
> no dependency information available*19:22:30*  [WARNING] Failed to retrieve 
> plugin descriptor for 
> org.sonarsource.scanner.maven:sonar-maven-plugin:?3.7.0.1746: Plugin 
> org.sonarsource.scanner.maven:sonar-maven-plugin:?3.7.0.1746 or one of its 
> dependencies could not be resolved: Failure to find 
> org.sonarsource.scanner.maven:sonar-maven-plugin:jar:?3.7.0.1746 in 
> https://my.inernal.maven <https://ap-sc.lss.emc.com/artifactory/public>.repo 
> was cached in the local repository, resolution will not be reattempted until 
> the update interval of brs has elapsed or updates are forced
>
>
> Thanks
>
>
> -D
>
>

Strange maven sonar download warning?

[Dan Tran]

Hello to all

I am seeing the bellow warning at my build with no build failure.  Wonder
if anyone else sees the same thing?

*19:22:30*  [WARNING] The POM for
org.sonarsource.scanner.maven:sonar-maven-plugin:jar:?3.7.0.1746 is
missing, no dependency information available*19:22:30*  [WARNING]
Failed to retrieve plugin descriptor for
org.sonarsource.scanner.maven:sonar-maven-plugin:?3.7.0.1746: Plugin
org.sonarsource.scanner.maven:sonar-maven-plugin:?3.7.0.1746 or one of
its dependencies could not be resolved: Failure to find
org.sonarsource.scanner.maven:sonar-maven-plugin:jar:?3.7.0.1746 in
https://my.inernal.maven
.repo was cached in the
local repository, resolution will not be reattempted until the update
interval of brs has elapsed or updates are forced


Thanks


-D

Re: Overriding dependencyManagement import version?

[Dan Tran]

@khmarbaise <https://github.com/khmarbaise>  from  junit issue,  you
mentioned about placing your 'import' above spring boot import, what about
the individual artifact?

-D

On Wed, Apr 1, 2020 at 1:50 PM Dan Tran  wrote:

> found this  ref
> https://github.com/sormuras/junit-platform-maven-plugin/issues/29#issuecomment-456958188
>
>
> Need maven core devs to confirm this
>
> Thanks
>
> -D
>
> On Wed, Apr 1, 2020 at 1:08 PM Dan Tran  wrote:
>
>> Hi
>>
>> I believe in order to do so, I need to place my override above the
>> import, do we have this maven behavior documented somewhere?
>>
>> 
>>
>>   
>>  [mine]
>>   
>>   
>>  [the import BOM]
>>   
>>
>>
>> Thanks
>>
>> -D
>>
>

Re: Overriding dependencyManagement import version?

[Dan Tran]

found this  ref
https://github.com/sormuras/junit-platform-maven-plugin/issues/29#issuecomment-456958188


Need maven core devs to confirm this

Thanks

-D

On Wed, Apr 1, 2020 at 1:08 PM Dan Tran  wrote:

> Hi
>
> I believe in order to do so, I need to place my override above the import,
> do we have this maven behavior documented somewhere?
>
> 
>
>   
>  [mine]
>   
>   
>  [the import BOM]
>   
>
>
> Thanks
>
> -D
>

Overriding dependencyManagement import version?

[Dan Tran]

Hi

I believe in order to do so, I need to place my override above the import,
do we have this maven behavior documented somewhere?


   
  
 [mine]
  
  
 [the import BOM]
  
   

Thanks

-D

Re: Same snapshot deploy number for entire build - possible

[Dan Tran]

as stated before we are not cutting RC build at CI level.  We must stay
with snapshot until it is closed to release date, this is where we will use
CI friendly RC ( ie no more snaphots)

Clarification of to your problem statements:

1. QA needs projects built from the same revision and each snapshot
uploaded to maven repo must end with same snapshot buildNum
2. When the projects are built from the same revision, no one can verify
that easily when the build numbers are different.

-D

On Mon, Sep 16, 2019 at 11:46 AM Jason Young 
wrote:

> Dan,
>
> Thank you for clarifying the problem more. I think I understand better now.
>
> It sounds like there are really 2 problems:
> 1. QA needs projects built from the same revision.
> 2. When the projects are built from the same revision, no one can verify
> that easily because the build numbers are different.
>
> Is that correct?
>
> For the first problem, I think Tibor's example of using a CI pipeline to
> use the artifacts only if the whole reactor succeeds is what will work for
> most people (it's what my team does, in effect, just with a different CI
> tool).
>
> On Sun, Sep 15, 2019 at 5:35 PM Dan Tran  wrote:
>
> > Please keep in mind QA is not a maven user.  All download/deployment and
> > testing are mostly automated, however, when come to reporting they have
> to
> > use something concrete which is the exact snapshot downloaded for them
> >
> > They also come to accept that each artifact has its own
> buildNo/snapshotNo,
> > but the same conversation keeps repeating about version inconsistency.  (
> > if you add Jenkins build number it does get worse).  My take here is to
> > find a way to unify the snapshotNum for the entire build, then the
> ongoing
> > problem will be fixed
> >
> > Speaking of implementation, I dig a litter deeper by debugging thru maven
> > deploy, but my IDE (eclipse) step debugger is out of syn ( maven deploy
> > 2.8.2 --> artifact-transfier-->maven-resolver)
> > so I dont have much luck getting more understanding of the code.
> Basically
> > I am looking for the exact place where Maven calculate the next snapshot
> > number
> >
> > Thanks
> >
> > -D
> >
> >
> >
> > On Sun, Sep 15, 2019 at 1:57 PM Tibor Digana 
> > wrote:
> >
> > > Hi Francois and Dan,
> > >
> > > I understood it the same way as Francois mentioned. Not sure if NN in
> the
> > > format "artifactId-version-timestamp-NN" is a bug. Who cares is
> probably
> > > someone who downloads the artifact manually, maybe the QA.
> > > Also downloading the artifacts from Nexus never was so trivial for QA
> and
> > > development team.
> > > There's Nexus Proffessional and the Staging Repos but I found it useful
> > > only in OSS developers.
> > >
> > > What was found acceptable was the solution where the QA does not
> traverse
> > > the path of groupId/artifactId in the repo, and it was a simple button
> in
> > > GUI and automatic deployment. Something where nobody downloads the
> > artifact
> > > directly.
> > > My colleagues like integrating release candidates and not the
> Snapsthots
> > > because Snapshots are very volatile and the RCs are positively deployed
> > > ones or two times a month - rarely.
> > >
> > > If the Snapshots must be downloaded every day then the question is why
> > such
> > > processes exist in the company or what's wrong with the project
> > structures,
> > > and what is missing in the automatic deployment.
> > >
> > > Cheers
> > > Tibor17
> > >
> > >
> > >
> > > On Sun, Sep 15, 2019 at 10:15 PM Francois Marot <
> > francois.ma...@gmail.com>
> > > wrote:
> > >
> > > > I'm sorry to insist but nevertheless I insist ;). I may have
> > > misunderstood
> > > > the problem but as I understand it, the whole problem can be sumed up
> > by:
> > > > " the fact that the repository adds a number at the end of the
> deployed
> > > > files is a problem because not all artifacts deployed from the same
> > > reactor
> > > > may not get the same suffix/number if some previous build failed half
> > > way".
> > > > I still do not see how it is a problem as it is only a problem if one
> > > wants
> > > > to get each files manually from the filesystem. In this case he does
> > not
> > > > know the *right* number for each artifact.
> > &

Re: Same snapshot deploy number for entire build - possible

[Dan Tran]

Please keep in mind QA is not a maven user.  All download/deployment and
testing are mostly automated, however, when come to reporting they have to
use something concrete which is the exact snapshot downloaded for them

They also come to accept that each artifact has its own buildNo/snapshotNo,
but the same conversation keeps repeating about version inconsistency.  (
if you add Jenkins build number it does get worse).  My take here is to
find a way to unify the snapshotNum for the entire build, then the ongoing
problem will be fixed

Speaking of implementation, I dig a litter deeper by debugging thru maven
deploy, but my IDE (eclipse) step debugger is out of syn ( maven deploy
2.8.2 --> artifact-transfier-->maven-resolver)
so I dont have much luck getting more understanding of the code.  Basically
I am looking for the exact place where Maven calculate the next snapshot
number

Thanks

-D



On Sun, Sep 15, 2019 at 1:57 PM Tibor Digana  wrote:

> Hi Francois and Dan,
>
> I understood it the same way as Francois mentioned. Not sure if NN in the
> format "artifactId-version-timestamp-NN" is a bug. Who cares is probably
> someone who downloads the artifact manually, maybe the QA.
> Also downloading the artifacts from Nexus never was so trivial for QA and
> development team.
> There's Nexus Proffessional and the Staging Repos but I found it useful
> only in OSS developers.
>
> What was found acceptable was the solution where the QA does not traverse
> the path of groupId/artifactId in the repo, and it was a simple button in
> GUI and automatic deployment. Something where nobody downloads the artifact
> directly.
> My colleagues like integrating release candidates and not the Snapsthots
> because Snapshots are very volatile and the RCs are positively deployed
> ones or two times a month - rarely.
>
> If the Snapshots must be downloaded every day then the question is why such
> processes exist in the company or what's wrong with the project structures,
> and what is missing in the automatic deployment.
>
> Cheers
> Tibor17
>
>
>
> On Sun, Sep 15, 2019 at 10:15 PM Francois Marot 
> wrote:
>
> > I'm sorry to insist but nevertheless I insist ;). I may have
> misunderstood
> > the problem but as I understand it, the whole problem can be sumed up by:
> > " the fact that the repository adds a number at the end of the deployed
> > files is a problem because not all artifacts deployed from the same
> reactor
> > may not get the same suffix/number if some previous build failed half
> way".
> > I still do not see how it is a problem as it is only a problem if one
> wants
> > to get each files manually from the filesystem. In this case he does not
> > know the *right* number for each artifact.
> > But if the QA want to download all the artifacts belonging to the latest
> > build, all he has to do is create a pom.xml referencing all those
> artifact,
> > use a variable as the version number and use the dependency plugin (
> >
> >
> https://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html
> > ) to retrieve the artifacts locally.
> >
> > This way, what you see as a problem is hust an internal implementation
> > detail of Maven/repository that you can circumvent easily.
> >
> > Again, I may have misunderstood so please excuse me if I'm talking
> nonsense
> > but I thought it could help.
> >
> > Regards
> >
> >
> >
> >
> >
> >
> >
> > *- - - - -François Marot06 50 91 96 38*
> >
> >
> >
> > On Thu, 12 Sep 2019 at 04:07, Dan Tran  wrote:
> >
> > > Hello Maven Users and Development Team
> > >
> > > Currently, artifact deployed as snapshot at Maven repository has the
> > > following format
> > >
> > >  artifactId-version-timestamp-NN
> > >
> > > where NN auto-incremented at each maven module and the number varies
> > >
> > > Is there a way to use same snapshot NN for the entire multi-module
> maven
> > > build?
> > >
> > > If I have to implement a solution, would it be as an extension or I
> have
> > to
> > > tinker with maven-deploy-plugin?
> > >
> > > Very appreciated any advice
> > >
> > > -D
> > >
> >
>

Re: Same snapshot deploy number for entire build - possible

[Dan Tran]

Found  this JIRA at MDEPLOY

   * https://issues.apache.org/jira/projects/MDEPLOY/issues/MDEPLOY-217
   * https://issues.apache.org/jira/projects/MDEPLOY/issues/MDEPLOY-199

Looks the place to look for is at maven-resolver? which responsible to
download maven-metadata and calculate next build number

Thanks

-D


On Sat, Sep 14, 2019 at 2:52 AM Robert Scholte  wrote:

> On Sat, 14 Sep 2019 07:17:16 +0200, Dan Tran  wrote:
>
> > Still waiting for the maven dev team to chime in if there is possible
> > solution
>
> Tamás is dev team member :)
>
> I don't know which code is responsible for adding the buildnumer.
> Personally I'd like to invest in MNG-5666[1], which should already be
> huge
> help for a lot of people.
> It might even reduce your problem. And afterwards, depending on where the
> buildnumber calculation is done, it should be easier to implement it per
> "deploymentgroup".
>
> thanks,
> Robert
>
> [1] https://issues.apache.org/jira/browse/MNG-5666
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Same snapshot deploy number for entire build - possible

[Dan Tran]

Hi Jason,

There is no problem having maven to maven snapshot dependencies between
teams.

The problem arises when you have 3 to 4 installer type artifacts landing on
QA  teams who have to install/deploy and coordinate

 Having the same snapshot number at the end of each installer artifact
helps.  Knowing all coming from same build

Still waiting for the maven dev team to chime in if there is possible
solution :-)

Thanks for all feedbacks

-D




On Fri, Sep 13, 2019 at 5:33 PM Jason Young 
wrote:

> Dan,
>
> Why are people asking about anything after `SNAPSHOT` in the version
> number, i.e. why do they care? Are discrepancies causing build failures
> somehow?
>
> My team's projects depend on each other with `SNAPSHOT` versions but
> without specifying a build number or timestamp, e.g.
> `1.2.3-SNAPSHOT`. This, combined with a policy to always
> get the latest SNAPSHOT (just like the `-U` argument only applied
> implicitly), makes every build use the latest SNAPSHOT of any dependencies
> it does not build from source. Nobody ever asks me about timestamps or
> build numbers that e.g. Nexus keeps up with.
>
> Regarding the policy or the -U argument, IMO these are necessary for
> correct builds because the default policy, last I checked, is to download
> the latest SNAPSHOT only if Maven hasn't checked in the last 24 hours,
> which I find bewildering.
>
> Again, you can define the version _once for all projects_ in a parent
> pom.xml. Let us know if that makes sense or if it is not an option for some
> reason.
>
> HTH. Sorry if I still don't understand the problem.
>
> On Fri, Sep 13, 2019 at 6:22 PM Dan Tran  wrote:
>
> > @ Tamás Cservenák you read my mind thanks
> >
> > The problem I am facing is, out of a few hundred artifacts deployed every
> > build.
> > There is a handful of artifacts that landed on QA side. By having the
> same
> > 'buildNo/snapshotNo'
> >  ( ie artifactId-version-timestamp-buildNo.xx)  it is much easier to
> > communicate,
> > otherwise, it is a constant problem explaining why they are not the same
> >
> > This is an ongoing problem at my workplace.
> >
> > deployAtEnd never work for us
> > https://issues.apache.org/jira/projects/MDEPLOY especially this one
> > https://issues.apache.org/jira/projects/MDEPLOY/issues/MDEPLOY-226
> >
> > We can switch to release build but that is not an option since we would
> run
> > out  of storage quickly and have to purge ourselves
> >
> > The question here what is the best way to implement an option asking
> > maven-deploy-plugin to use the same provided 'buildNo' ? possible?
> >
> > Thanks
> >
> > -D
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Sep 13, 2019 at 1:53 PM Francois Marot  >
> > wrote:
> >
> > > OK, I get the "problem" but in fact I do not think this is a problem.
> > > How those files (with the number suffix) are named, whether you deploy
> > (to
> > > a remote repo) or install (to a local folder), is just an
> implementation
> > > detail. You should never end up accessing those files by their name.
> > > Let me explain: if you want to get all the 3 latest artifacts, whatever
> > the
> > > file name and the timestamp version, you can just create a pom having
> > those
> > > 3 artifacts declared as dependencies and use maven dependency plugin (
> > >
> >
> https://maven.apache.org/plugins/maven-dependency-plugin/plugin-info.html
> > > )
> > > to copy those artifacts in a directory. Use the "-U" flag to make sure
> to
> > > get the latest version. This way, maven will care about the file names,
> > but
> > > you will not.
> > >
> > > I hope I can help
> > >
> > >
> > >
> > >
> > >
> > > On Fri, 13 Sep 2019 at 22:42, Tamás Cservenák 
> > wrote:
> > >
> > > > Howdy,
> > > >
> > > > so what Dan is asking for is I think the following thing:
> > > > On multi module snapshot deploy, the last bit of snapshot timestamped
> > > > version is "buildNo".
> > > >
> > > > Consider following scenario: you have a 3 module reactor build:
> > > > i) you deploy first time: the buildNo is -1
> > > > ii) you deploy second time, and 2nd module UT fails: result in repo
> is
> > > 1st
> > > > module has -2, while the rest, as module2 failed, is not deployed
> > > > iii) you deploy third time: the build No is -3 for 1st module, while
> it
> 

Re: Same snapshot deploy number for entire build - possible

[Dan Tran]

@ Tamás Cservenák you read my mind thanks

The problem I am facing is, out of a few hundred artifacts deployed every
build.
There is a handful of artifacts that landed on QA side. By having the same
'buildNo/snapshotNo'
 ( ie artifactId-version-timestamp-buildNo.xx)  it is much easier to
communicate,
otherwise, it is a constant problem explaining why they are not the same

This is an ongoing problem at my workplace.

deployAtEnd never work for us
https://issues.apache.org/jira/projects/MDEPLOY especially this one
https://issues.apache.org/jira/projects/MDEPLOY/issues/MDEPLOY-226

We can switch to release build but that is not an option since we would run
out  of storage quickly and have to purge ourselves

The question here what is the best way to implement an option asking
maven-deploy-plugin to use the same provided 'buildNo' ? possible?

Thanks

-D









On Fri, Sep 13, 2019 at 1:53 PM Francois Marot 
wrote:

> OK, I get the "problem" but in fact I do not think this is a problem.
> How those files (with the number suffix) are named, whether you deploy (to
> a remote repo) or install (to a local folder), is just an implementation
> detail. You should never end up accessing those files by their name.
> Let me explain: if you want to get all the 3 latest artifacts, whatever the
> file name and the timestamp version, you can just create a pom having those
> 3 artifacts declared as dependencies and use maven dependency plugin (
> https://maven.apache.org/plugins/maven-dependency-plugin/plugin-info.html
> )
> to copy those artifacts in a directory. Use the "-U" flag to make sure to
> get the latest version. This way, maven will care about the file names, but
> you will not.
>
> I hope I can help
>
>
>
>
>
> On Fri, 13 Sep 2019 at 22:42, Tamás Cservenák  wrote:
>
> > Howdy,
> >
> > so what Dan is asking for is I think the following thing:
> > On multi module snapshot deploy, the last bit of snapshot timestamped
> > version is "buildNo".
> >
> > Consider following scenario: you have a 3 module reactor build:
> > i) you deploy first time: the buildNo is -1
> > ii) you deploy second time, and 2nd module UT fails: result in repo is
> 1st
> > module has -2, while the rest, as module2 failed, is not deployed
> > iii) you deploy third time: the build No is -3 for 1st module, while it
> is
> > -2 for the rest.
> >
> > All sounds great ("as it should be"), but buildNo has "fall apart". 3rd
> > deployment will have snapshots that will have their version like
> > 1.0-mmdd.hhmmss-3 while the rest version is 1.0-mmdd.hhmmss-2.
> >
> > Determining buildNo is possible only from maven metadata.xml, that may be
> > overkill. Nothing logically "groups" the two version above, even if they
> > were deployed at same time, by the same build.
> >
> > Deploy at end may help here, yes, but personally, I dislike the fact how
> > buildNo is calculated (md get, buildNo++ jar put,, modified md put).
> >
> > Also, this topic seems to me, like somewhat related to the overall issue
> of
> > https://issues.apache.org/jira/browse/MNG-6581
> >
> > Thanks,
> > T
> >
> >
> >
> > On Fri, Sep 13, 2019 at 8:32 PM Francois Marot  >
> > wrote:
> >
> > >  can you tell us a little bit more about your problem please ?
> > > You say "Currently, artifact deployed as snapshot at Maven repository
> has
> > > the following format: artifactId-version-timestamp-NN ". Do youmean the
> > > filename in the repo ? If so, why is it a problem for you ?
> > > Share more with us and I think we'll suggest solution more adapted for
> > your
> > > use case  ;)
> > >
> > > Regards,
> > > Francois
> > >
> > >
> > >
> > > On Thu, 12 Sep 2019 at 04:07, Dan Tran  wrote:
> > >
> > > > Hello Maven Users and Development Team
> > > >
> > > > Currently, artifact deployed as snapshot at Maven repository has the
> > > > following format
> > > >
> > > >  artifactId-version-timestamp-NN
> > > >
> > > > where NN auto-incremented at each maven module and the number varies
> > > >
> > > > Is there a way to use same snapshot NN for the entire multi-module
> > maven
> > > > build?
> > > >
> > > > If I have to implement a solution, would it be as an extension or I
> > have
> > > to
> > > > tinker with maven-deploy-plugin?
> > > >
> > > > Very appreciated any advice
> > > >
> > > > -D
> > > >
> > >
> >
>

Re: Same snapshot deploy number for entire build - possible

[Dan Tran]

Looks like I need to clear thing a little bit

Assume I have a reactor of few hundreds of maven modules and my CI
build deploys snapshots, first few good builds, each module deployed to
maven repository have same snapshot number

Once we encounter a build failure at a module,  the snapshot number begins
to vary and over time, all modules no longer have the same snapshot number
anymore

To be able to determine a consistent snapshot number at each build,  I
would like to have an ability the tell deploy maven plugin to use an
assigned number for all modules.

Possible?

Thanks

-D






On Thu, Sep 12, 2019 at 11:31 PM Enrico Olivelli 
wrote:

> Dan,
> Are you running a single 'mvn deploy' or do you have multiple runs?
> I have never seen weird behaviours in multi module projects
>
> Cheers
> Enrico
>
> Il ven 13 set 2019, 08:19 Dan Tran  ha scritto:
>
> > Hello, Maven dev
> >
> > any suggestion/thoughts on this issue are very much appreciated
> >
> > Regards
> >
> > -D
> >
> > On Wed, Sep 11, 2019 at 7:06 PM Dan Tran  wrote:
> >
> > > Hello Maven Users and Development Team
> > >
> > > Currently, artifact deployed as snapshot at Maven repository has the
> > > following format
> > >
> > >  artifactId-version-timestamp-NN
> > >
> > > where NN auto-incremented at each maven module and the number varies
> > >
> > > Is there a way to use same snapshot NN for the entire multi-module
> maven
> > > build?
> > >
> > > If I have to implement a solution, would it be as an extension or I
> have
> > > to tinker with maven-deploy-plugin?
> > >
> > > Very appreciated any advice
> > >
> > > -D
> > >
> > >
> > >
> > >
> > >
> >
>

Re: Same snapshot deploy number for entire build - possible

[Dan Tran]

Hello, Maven dev

any suggestion/thoughts on this issue are very much appreciated

Regards

-D

On Wed, Sep 11, 2019 at 7:06 PM Dan Tran  wrote:

> Hello Maven Users and Development Team
>
> Currently, artifact deployed as snapshot at Maven repository has the
> following format
>
>  artifactId-version-timestamp-NN
>
> where NN auto-incremented at each maven module and the number varies
>
> Is there a way to use same snapshot NN for the entire multi-module maven
> build?
>
> If I have to implement a solution, would it be as an extension or I have
> to tinker with maven-deploy-plugin?
>
> Very appreciated any advice
>
> -D
>
>
>
>
>

Same snapshot deploy number for entire build - possible

[Dan Tran]

Hello Maven Users and Development Team

Currently, artifact deployed as snapshot at Maven repository has the
following format

 artifactId-version-timestamp-NN

where NN auto-incremented at each maven module and the number varies

Is there a way to use same snapshot NN for the entire multi-module maven
build?

If I have to implement a solution, would it be as an extension or I have to
tinker with maven-deploy-plugin?

Very appreciated any advice

-D

Re: Same snapshot number for entired build? possible

[Dan Tran]

I am just looking for the technical possibility to allow this scenario

artifact1-timestamp-buildNum.xxx
artifact2-timestamp-buidNum.xxx

for Maven snapshot build where maven deploy-plugin generates the
timestamp-buildNum parts and they are no guarantee to be the same

I just need the buildNum part to be the same and the ability to specify at
maven-deploy-plugin

Thanks

-D

On Fri, May 3, 2019 at 3:48 AM Tibor Digana  wrote:

> I don't like deploying snapshots, but if you want to do it, you can
> deplyAtEnd=true and eliminate race conditioning on repo. You won't prevent
> from if on 100% with this config.
> Why adding a number manually to SNAPSHOT version, and why not to make an
> ordinal release (using maven-release-plugin) with release candidate
> versions by one person in dev or QA?
> I would personally prefer using Staging server instead of Snapshot repo,
> because staging repo is temporary and release version with release
> candidates on the Staging (marked by Git Tags) can tested in QA. Final
> release candidate would be promoted to public repo and the temporary
> staging repo is deleted. So if you have big deployment files cancalled by
> your QA, don't be afraid that they persist in the repo.
>
> On Thu, May 2, 2019 at 7:49 AM Dan Tran  wrote:
>
> > Hi
> >
> > We have a large build with a few artifacts are consumed by QA (2 vmware
> > OVAs).  However, each artifact  has its own maven module and therefore
> has
> > its own snapshot number
> >
> > is it possible to fix up deploy-maven-plugin to allow the user
> configuring
> > the snapshot number (yes timestamp should be different) so our QA can
> > correlate/relate the snapshots under test?
> >
> > Basically, we can auto-detect the current top-level parent snapshot
> number
> > at maven repo, and then increment by one and use the same number for the
> > entire build
> >
> > Advice is greatly appreciated
> >
> > -D
> >
>

Same snapshot number for entired build? possible

[Dan Tran]

Hi

We have a large build with a few artifacts are consumed by QA (2 vmware
OVAs).  However, each artifact  has its own maven module and therefore has
its own snapshot number

is it possible to fix up deploy-maven-plugin to allow the user configuring
the snapshot number (yes timestamp should be different) so our QA can
correlate/relate the snapshots under test?

Basically, we can auto-detect the current top-level parent snapshot number
at maven repo, and then increment by one and use the same number for the
entire build

Advice is greatly appreciated

-D

Re: PSA: You can't push POMs with child.inherit.append.path attributes to Maven Central yet

[Dan Tran]

looking forward to maven 3.6.1 with IDE fix which is blocking us from
moving forward

Thanks

-D

On Sun, Nov 4, 2018 at 3:33 AM Hervé BOUTEMY  wrote:

> good idea, that's a good opportunity: let's try
>
> Regards,
>
> Hervé
>
> Le samedi 3 novembre 2018, 13:01:34 CET Robert Scholte a écrit :
> > I could start experimenting with this specific issue.
> >
> > Maven 3.6.0 has access to a FileTransformer, which can be used to make
> > remove this attribute and make its value explicit in the pom file.
> >
> > Robert
> >
> > On Sat, 03 Nov 2018 12:36:30 +0100, Karl Heinz Marbaise
> >
> >  wrote:
> > > Hi Hervé,
> > >
> > > On 03/11/18 12:29, Hervé BOUTEMY wrote:
> > >> yes, sorry...
> > >
> > > No problem..
> > >
> > >>  I already marked MNG-6059 as "fix for: 3.6.1"
> > >>  I suppose we should fix also the compatibility issue with IntelliJ,
> > >>
> > >> since it
> > >> should not be complex on our side
> > >
> > > If its that simple we should do that...
> > >
> > > But on the other hand if we change back to the previous state the IDE's
> > > have to change another time?  But I'm not sure about that..
> > >
> > > Kind regards
> > > Karl Heinz Marbaise
> > >
> > >>  Regards,
> > >>  Hervé
> > >>
> > >>  Le vendredi 2 novembre 2018, 06:17:06 CET Karl Heinz Marbaise a
> écrit :
> > >>> Hi,
> > >>>
> > >>> On 01/11/18 23:55, Hervé BOUTEMY wrote:
> >  Hi,
> > 
> >  Ah, I forgot about Nexus staging checks...
> > 
> >  I also forgot to merge MNG-6059 [1], which changes the attributes
> >  names
> >  for
> >  more flexibility on scm urls.
> > 
> >  Looks like Maven 3.6.0 is not fully ready for this feature, will
> >  require
> >  3.6.1 to have a definitive solution: sorry for the mistakes, and
> >  eager to
> >  see more user tests to detect such issues earlier in the future
> > >>>
> > >>> Sounds like I should make another Core release within the next 4
> Weeks
> > >>> to fix this..
> > >>>
> > >>> let us summarize that...
> > >>>
> > >>> Kind regards
> > >>> Karl Heinz Marbaise
> > >>>
> >  Regards,
> > 
> >  Hervé
> > 
> >  [1] https://issues.apache.org/jira/browse/MNG-6059
> > 
> >  Le jeudi 1 novembre 2018, 15:52:58 CET Mark Raynsford a écrit :
> > > Hello!
> > >
> > > Ran into a problem today whilst trying to push artifacts to Central
> > > that happened to use the new MNG-5951 attributes.
> > >
> > > See:
> http://blog.io7m.com/2018/11/01/you-cannot-put-that-there.xhtml
> > > See: https://issues.apache.org/jira/browse/MNG-5951
> > > See: https://issues.sonatype.org/browse/MVNCENTRAL-4085
> > >
> > > Just letting everyone know that they'll run into this until
> Sonatype
> > > do
> > > whatever updates are required.
> > >
> > > --
> > > Mark Raynsford | http://www.io7m.com
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

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

[Dan Tran]

I added a sample maven project to reproduce the issue. Compare to 2.21,
2.22 is awesomely better. This issue is just a corner case with work around

-D

On Fri, Jun 22, 2018 at 11:49 PM, Enrico Olivelli 
wrote:

> In Surefire 2.22 we integrated junit5 into the core of the plugin so this
> was a big refactor.
>
> I hope Tibor and Chris could help better in this case.
>
> Do you need some feature in 2.22 ? Or can you stay with 2.21 until we find
> the cause?
>
> Your contribution will be really welcome, with a simple reproducer or a
> patch.
>
> Enrico
>
> Il sab 23 giu 2018, 01:51 Dan Tran  ha scritto:
>
> > with older surefire 2.21, I had to add  junit-platform-surefire-provider
> as
> > sufirefire dependency, so this issue only shows up at 2.22
> >
> > Thanks
> >
> > -D
> >
> > On Fri, Jun 22, 2018 at 1:49 PM, Enrico Olivelli 
> > wrote:
> >
> > > Hi Dan,
> > > Did you have the same problem with an older version of surefire?
> > > Enrico
> > >
> > > Il ven 22 giu 2018, 22:21 Dan Tran  ha scritto:
> > >
> > > > I went ahead to file a jira issue at
> > > > https://issues.apache.org/jira/browse/SUREFIRE-1527
> > > >
> > > > On Wed, Jun 20, 2018 at 8:39 PM, Dan Tran  wrote:
> > > >
> > > > > and I am using latest surefire 2.22.0
> > > > >
> > > > > -D
> > > > >
> > > > > On Wed, Jun 20, 2018 at 8:39 PM, Dan Tran 
> wrote:
> > > > >
> > > > >>
> > > > >> Hi
> > > > >>
> > > > >> I have junit4/5 and testng in the classpath and none of my junit
> > tests
> > > > >> got invoked
> > > > >>
> > > > >> I this a correct behavior?
> > > > >>
> > > > >> I ended up to directly add junit-platform-surefire-provider  to
> > > > >> surefire's dependency
> > > > >>
> > > > >> and I cant remove testng since we have legacy none test code  uses
> > > > testng
> > > > >> assert
> > > > >>
> > > > >> Thanks
> > > > >>
> > > > >> -Dan
> > > > >>
> > > > >
> > > > >
> > > >
> > > --
> > >
> > >
> > > -- Enrico Olivelli
> > >
> >
> --
>
>
> -- Enrico Olivelli
>

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

[Dan Tran]

with older surefire 2.21, I had to add  junit-platform-surefire-provider as
sufirefire dependency, so this issue only shows up at 2.22

Thanks

-D

On Fri, Jun 22, 2018 at 1:49 PM, Enrico Olivelli 
wrote:

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

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

[Dan Tran]

I went ahead to file a jira issue at
https://issues.apache.org/jira/browse/SUREFIRE-1527

On Wed, Jun 20, 2018 at 8:39 PM, Dan Tran  wrote:

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

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

[Dan Tran]

and I am using latest surefire 2.22.0

-D

On Wed, Jun 20, 2018 at 8:39 PM, Dan Tran  wrote:

>
> Hi
>
> I have junit4/5 and testng in the classpath and none of my junit tests got
> invoked
>
> I this a correct behavior?
>
> I ended up to directly add junit-platform-surefire-provider  to
> surefire's dependency
>
> and I cant remove testng since we have legacy none test code  uses testng
> assert
>
> Thanks
>
> -Dan
>

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

[Dan Tran]

Hi

I have junit4/5 and testng in the classpath and none of my junit tests got
invoked

I this a correct behavior?

I ended up to directly add junit-platform-surefire-provider  to surefire's
dependency

and I cant remove testng since we have legacy none test code  uses testng
assert

Thanks

-Dan

Re: Maven extension's repository

[Dan Tran]

what is exact URL of  'maven website'?


-D

On Wed, May 23, 2018 at 5:26 PM, Vivi An  wrote:

> Hi All,
>
> I’m using takari extension through extensions.xml file under ./mvn,  it
> downloads extensions from maven website. Wondering if we can change
> configuration in some way so it could download all extensions from some
> internal repository?
>
> Thank you all!
> Regards,
> ~ Vivi
>

Re: maven parallel build has intermittent compile error, dependency not added to classpath

[Dan Tran]

this may help
http://maven.40175.n5.nabble.com/Hickup-in-multi-thread-build-td5865974.html#a5866778

-D

On Wed, May 16, 2018 at 1:49 PM, Vivi An  wrote:

> Hi all,
>
> Hit intermittent compile error after enabling maven parallel build,
> complains about symbol not found.  Checked the log, it’s not caused by
> racing issue of multithread downloading, though that’s another problem even
> with Takari extension. Problem is in case of failure, the dependency in the
> pom was not added to the compile path of the project,  the dependency tree
> looks correct, did not find a way to enforce injecting pom dependency paths
> to class path for the project. I tried with both maven compiler plugin 3.1
> and 3.7.0. Wondering if anybody in the list hits similar issue or have any
> idea about this.
>
> Thanks for help
> Regards,
> ~ Vivi
>

Re: ConcurrentContinuous Delivery Maven Builds

[Dan Tran]

@Paul yes the final build artifacts go to QA. I guess I can instrument
Maven only deploy the necessary files.  But I still need to deploy full
snapshot build once a day

@Francois, for my case, it very very possible that 2 parallel pipelines
pushing same artifact ( different versions) to maven repo and step on each
other maven-metadata.xml files

Thanks

-D

On Wed, Mar 14, 2018 at 2:14 PM, Francois MAROT 
wrote:

> What do you mean by "pushing maven-metadata.xml which can be corrupted" ?
> Are you talking about https://issues.apache.org/jira/browse/MDEPLOY-221
> which is solved in Maven 3.5.2 (even 3.5.1 I think) ?
>
>
>
> --
> Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

ConcurrentContinuous Delivery Maven Builds

[Dan Tran]

Hi

I have a requirement to run concurrent maven continuous deliver style.
Each new commit/PR triggers new pipeline with unique version.

Since maven deployment also pushing maven-metadata.xml which can be
corrupted for concurrent pipeplines

I wonder if Artifactory or Nexus have some type of protection for this
scenario?

Thanks

-Dan

Re: Is there any possibility to reduce the size of maven distribution

[Dan Tran]

I believe you can shave off 1 to 2M by removing those already shaded by
wagon-http.

-D

On Fri, Nov 10, 2017 at 1:18 AM, Kasun Siyambalapitiya 
wrote:

> Hi Anders,
>
> Thank you for the quick response, I'll keep it as it is then :)
>
> On Fri, Nov 10, 2017 at 2:03 PM, Anders Hammar  wrote:
>
> > I doubt there is very much you can remove. The Maven installation just
> > includes the basic features to perform the core features of a build, then
> > additional plugins are downloaded as needed to do specific tasks during
> the
> > build steps. I think that you could reduce the size by removing the color
> > logging support (jansi).
> >
> > Please keep in mind that Maven will (typically) download A LOT of
> artifacts
> > during the build. So the 9MB of Maven core is not your main concern if
> you
> > want to keep the total size down.
> >
> > /Anders
> >
> > On Fri, Nov 10, 2017 at 6:30 AM, Kasun Siyambalapitiya  >
> > wrote:
> >
> > > Hi all,
> > >
> > > I am currently working on a project which packs `maven` distribution in
> > > itself, so that the programme is capable of performing a `maven` build
> if
> > > the running system is having `Java` pre installed. Since the `maven`
> > > distribution (apache-maven-3.5.2-bin.zip) size is around 9MB the total
> > > resultant output of the program becomes bulky. Is there any way to
> reduce
> > > the size of the `maven` distribution by keeping only the libs which
> > > required for performing the maven build.
> > >
> > > Thanks
> > >
> > > --
> > > *Regards,*
> > >
> > > *Kasun Siyambalapitiya*
> > > *Software Engineer*
> > > WSO2 Inc. - http://wso2.com/
> > > lean . enterprise . middleware
> > > Tel : 0715523466
> > > E mail : kasu...@wso2.com
> > > Blog: https://medium.com/@kasunsiyambalapitiya
> > > 
> > >
> >
>
>
>
> --
> *Regards,*
>
> *Kasun Siyambalapitiya*
> *Software Engineer*
> WSO2 Inc. - http://wso2.com/
> lean . enterprise . middleware
> Tel : 0715523466
> E mail : kasu...@wso2.com
> Blog: https://medium.com/@kasunsiyambalapitiya
> 
>

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Dan Tran]

I don't think I can help much since I don't use sha1 for revision prop.
For my case,  I  run  buildnumber:create-metadata top level only
(true) to track SCM info per build and user
Jenkins env.BUILD_NUMBER for CD version

-Dan

On Wed, Nov 8, 2017 at 2:30 PM, Eric Benzacar <e...@benzacar.ca> wrote:

> Hi Guys,
>
> Sorry to reopen a 6 month old thread, but I'm trying to add some more
> smarts to my stuff, and am failing trying to figure out how to do this.
>
> I want to use the buildnumber-maven-plugin:create-metadata goal  to
> generate the metadata build.properties file, which is a great addition to
> my artifacts.  At the same time, I noticed that it contains some useful
> information that I would want to use in my version number - such as the
> sha1.
>
> But the problem is that I can't figure out how to consume the metadata for
> my version.  Basically, I need to get maven to know the sha1 from my
> commit.  But the metadata file won't be interpolated by maven.  And if I
> use the buildnumber:create goal to get the sha1, I can configure it to be
> exported as a ${sha1} property.  And from everything I've understood, the
> ONLY properties understood by maven for the  tag are ${revision}
> ${changelist} and ${sha1}.
>
> But when I actually run the build all the interpolated version numbers
> ignore the ${sha1} property as generated by the buildnumber-m-p, even
> though I bound the create to the validate phase.
>
> Although I am not extremely surprised by this, I was sincerely hoping there
> was some way to make this work.  Is there any way at all to be able to
> leverage what the buildnumber-m-p generates as part of my ?  Is
> the only option to pass the ${sha1} value on command line?
>
>
> A snippet of my pom:
>
> 
> test
> org.project
> ${revision}${sha1}${changelist}
> 
> 
> 5.0.0
> 
> 
>
> 
> 
> 
> 
> org.codehaus.mojo
> buildnumber-maven-plugin
> 1.4
> 
> 
> generate-sha1
> validate
> 
> create
> 
> 
> 
> sha1
> 
> -{0}
> 
> scmVersion
> 
> 8
> 
> 
> 
> generate-metadata
> generate-resources
> 
> create-metadata
> 
> 
> ${revision}${sha1}${changelist}
> true
> true
> META-INF/build.properties
> 
> 
> 
> 
> no.scm.config.in.pom
> 
> 
> 
> 
> 
> 
> 
>
>
> Thanks!
>
> Eric
>
>
> On Thu, Jul 27, 2017 at 1:46 AM, Dan Tran <dant...@gmail.com> wrote:
>
> > Hi Eric
> >
> >
> > i am using the follow at top level parent
> >
> >   ${revision}
> >
> >   
> > x.y.x-SNAPSHOT
> >   
> >
> > In child pom
> >
> >   
> >   ...
> >   ${revision}
> >   
> >
> >
> > At jenskins file
> >
> >   I have a param  releaseVersion by default it is empty
> >
> > if the releaseVersion is not empty, then pass
> > -Drevision-${params.releaseVersion} into maven build
> >
> >
> > This mean i have 3 modes
> >
> >- Default SNAPSHOT build
> >- User can pass in the release version
> >- Auto incremental release build where I update and commit jenkins
> file
> > to default release version to 'x.y.z-${BUILD_NUMBER}'.
> >
> >
> > I have team that will never use auto incremental release build, and they
> > will manually run the build with a release version of their choice ( mode
> > #2)
> >
> >
> > -Dan
> >
> >
> > On Wed, Jul 26, 2017 at 8:37 PM, Eric Benzacar <e...@benzacar.ca> wrote:
> >
> > > Dan,
> > >
> > > Thanks for the update.  I'm at the state where I am trying to
> integrated
> > CD
> > > with a large multi-module maven project and trying to get this process
> > > running smoothly with Jenkins.  For the moment, I'm ok to use a
> > > split-Continuous Deployment concept - similar to yours.  ie: using
> > > SNAPSHOTs for development phase, and anything in a release branch
> becomes
> > > an release candidate.  Meaning that any commits into the release/
> branch
> > > produce a potentially shippable version.
> > >
> > > But that means that I need poms with version numbers as moving targets
> > (ie:
> > > sometimes with SNAPSHOTs, sometimes without).  Based on Karl Heinz
> > > Marbaise's suggestions, I am planning on building my poms as follows:
> > >
> > > parent pom:
> > >
> > > com.benze
> > >   parent
> > >   ${revision}${sha1}${changelist}
> > >   pom
> > >
> > >   
> > > 1.3.1
> > > -SNAPSHOT

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Dan Tran]

Hi Eric


i am using the follow at top level parent

  ${revision}

  
x.y.x-SNAPSHOT
  

In child pom

  
  ...
  ${revision}
  


At jenskins file

  I have a param  releaseVersion by default it is empty

if the releaseVersion is not empty, then pass
-Drevision-${params.releaseVersion} into maven build


This mean i have 3 modes

   - Default SNAPSHOT build
   - User can pass in the release version
   - Auto incremental release build where I update and commit jenkins file
to default release version to 'x.y.z-${BUILD_NUMBER}'.


I have team that will never use auto incremental release build, and they
will manually run the build with a release version of their choice ( mode
#2)


-Dan


On Wed, Jul 26, 2017 at 8:37 PM, Eric Benzacar <e...@benzacar.ca> wrote:

> Dan,
>
> Thanks for the update.  I'm at the state where I am trying to integrated CD
> with a large multi-module maven project and trying to get this process
> running smoothly with Jenkins.  For the moment, I'm ok to use a
> split-Continuous Deployment concept - similar to yours.  ie: using
> SNAPSHOTs for development phase, and anything in a release branch becomes
> an release candidate.  Meaning that any commits into the release/ branch
> produce a potentially shippable version.
>
> But that means that I need poms with version numbers as moving targets (ie:
> sometimes with SNAPSHOTs, sometimes without).  Based on Karl Heinz
> Marbaise's suggestions, I am planning on building my poms as follows:
>
> parent pom:
>
> com.benze
>   parent
>   ${revision}${sha1}${changelist}
>   pom
>
>   
> 1.3.1
> -SNAPSHOT
> 
>   
>
>
> but in my child poms, I'm not sure how to refer to the parent:
>
> webapp
> war
> 
>com.benze
>parent
> ??? 
>../superpom
> 
>
>
>
> How do you refer to the parent pom with a constantly (non-defined) moving
> version?  In the past, without using properties like this, I could use the
> maven-versions-plugin to update the version numbers, but now I don't even
> see how I can do that.  If the revision is defined at the command line in
> Jenkins (ie: -Drevision=4.5.0), how do I deal with the child poms?  If
> memory serves, the child cannot use properties for the parent version
> number.
>
> How/where to do you specify your semantic version number?  I remember you
> said you use the buildnumber-m-p for the build number, but that
> how/where/when do you specify the sematic version number?  Do you have to
> manually change it in the poms at RC time?  Is it only defined during the
> build process?
>
> Do you have an example of your pom structure and Jenkinsfile pipeline that
> you can share to help me better grasp how to handle this integration?
>
> Thanks,
>
> Eric
>
>
>
> On Fri, Jun 2, 2017 at 5:34 AM, Dan Tran <dant...@gmail.com> wrote:
>
> > Just want to share our final outcomes
> >
> > 1. Use snapshot build during development phase
> >
> > 2. At release candidate phase, switch jenkinsfile to release mode
> >
> > * For small projects, use version less Maven continuous deliver
> > friendly,
> >
> > * For large projects, use  versions-maven-plugin to change version in
> > all poms at pre-build
> >
> > * Automate the process to tag the final RC (we deploy a
> > build.properties to maven repo at each build, use its info to tag the
> SCM)
> >
> > Whenever, the startup performance issue for large project is fixed, we
> will
> > switch to full version less build
> >
> > -Dan
> >
> > On Sun, May 14, 2017 at 7:23 PM, Dan Tran <dant...@gmail.com> wrote:
> >
> > > I also noticed it takes about a minute for the build to roll after this
> > >
> > > [INFO] Error stacktraces are turned on.
> > > [INFO] Scanning for projects...
> > >
> > > This is not a good news for local dev build
> > >
> > > here are 2 time summaries running 250+ modules with skipTests and 4
> > thread
> > > smart builder. The first one does not use
> ${revision}
> > >
> > > [INFO] --
> --
> > > 
> > > [INFO] Total time: 04:05 min (Wall Clock)
> > > [INFO] Finished at: 2017-05-14T19:16:32-07:00
> > > [INFO] Final Memory: 680M/2078M
> > >
> > > [INFO] --
> --
> > > 
> > > [INFO] Total time: 05:56 min (Wall Clock)
> > > [INFO] Finished at: 2017-05-14T19:11:00-07:00
> > > [INFO] Final Memory: 1726M/3561M
> > >
> > >
> > > -D
> > >
> >
>

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Dan Tran]

Just want to share our final outcomes

1. Use snapshot build during development phase

2. At release candidate phase, switch jenkinsfile to release mode

* For small projects, use version less Maven continuous deliver
friendly,

* For large projects, use  versions-maven-plugin to change version in
all poms at pre-build

* Automate the process to tag the final RC (we deploy a
build.properties to maven repo at each build, use its info to tag the SCM)

Whenever, the startup performance issue for large project is fixed, we will
switch to full version less build

-Dan

On Sun, May 14, 2017 at 7:23 PM, Dan Tran <dant...@gmail.com> wrote:

> I also noticed it takes about a minute for the build to roll after this
>
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
>
> This is not a good news for local dev build
>
> here are 2 time summaries running 250+ modules with skipTests and 4 thread
> smart builder. The first one does not use ${revision}
>
> [INFO] 
> 
> [INFO] Total time: 04:05 min (Wall Clock)
> [INFO] Finished at: 2017-05-14T19:16:32-07:00
> [INFO] Final Memory: 680M/2078M
>
> [INFO] 
> 
> [INFO] Total time: 05:56 min (Wall Clock)
> [INFO] Finished at: 2017-05-14T19:11:00-07:00
> [INFO] Final Memory: 1726M/3561M
>
>
> -D
>

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Dan Tran]

I also noticed it takes about a minute for the build to roll after this

[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...

This is not a good news for local dev build

here are 2 time summaries running 250+ modules with skipTests and 4 thread
smart builder. The first one does not use ${revision}

[INFO]

[INFO] Total time: 04:05 min (Wall Clock)
[INFO] Finished at: 2017-05-14T19:16:32-07:00
[INFO] Final Memory: 680M/2078M

[INFO]

[INFO] Total time: 05:56 min (Wall Clock)
[INFO] Finished at: 2017-05-14T19:11:00-07:00
[INFO] Final Memory: 1726M/3561M


-D

Re: Excessive download/upload of maven-metadata.xml during maven deploy

[Dan Tran]

Yes, I have global maven settings to route all repositories to my internal
maven repository

  *

 I still can't connect the thought of transitive dependencies's
repositories can influence how maven-deploy-plugin handles module
maven-metadata.xml

I am very sure most corporate user would have internal maven repository, do
you see the same behavior?

since my project has about 250+ modules,  fixing this can improve build
time.

Thanks

-Dan




On Sat, May 13, 2017 at 2:11 PM, Arnaud Héritier <aherit...@gmail.com>
wrote:

> Are you defining a mirror in your maven settings ?
> How many different snapshots repositories are defined in your project and
> it's transitive dependencies (hard to define but from central it should
> never be the case)
> My guess is that in your project and transitive dependencies you are
> defining ~20 snapshots repositories (with different identifiers).
> When you upload upload an artifact, maven doesn't know where each artifact
> comes from and thus it is asking to each repository if there are some
> metadata for it.
> It you have a catch-all mirror defined in your settings it could end to
> have maven asking 20 times the same metadata to your mirror (Maven doesn't
> compare at all the repositories URLs to see if some repositories with
> different identifiers are targeting the same url)
>
>
> On Fri, May 12, 2017 at 9:31 PM, Dan Tran <dant...@gmail.com> wrote:
>
> > and it happens at deploy phase only
> >
> > -D
> >
> > On Fri, May 12, 2017 at 12:01 PM, Dan Tran <dant...@gmail.com> wrote:
> >
> > >
> > > my particular module has one optional RPM dependency. this means it
> only
> > > downloads one dependency and no transitive
> > >
> > > not sure why this cause the strange metadata download behavior
> > >
> > > -D
> > >
> > >
> > > On Fri, May 12, 2017 at 3:49 AM, Robert Scholte <rfscho...@apache.org>
> > > wrote:
> > >
> > >> My guess: references to snapshots or version ranges in one of your
> > >> (transitive) dependencies.
> > >>
> > >> Robert
> > >>
> > >
> >
>
>
>
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>

Re: Excessive download/upload of maven-metadata.xml during maven deploy

[Dan Tran]

and it happens at deploy phase only

-D

On Fri, May 12, 2017 at 12:01 PM, Dan Tran <dant...@gmail.com> wrote:

>
> my particular module has one optional RPM dependency. this means it only
> downloads one dependency and no transitive
>
> not sure why this cause the strange metadata download behavior
>
> -D
>
>
> On Fri, May 12, 2017 at 3:49 AM, Robert Scholte <rfscho...@apache.org>
> wrote:
>
>> My guess: references to snapshots or version ranges in one of your
>> (transitive) dependencies.
>>
>> Robert
>>
>

Re: Excessive download/upload of maven-metadata.xml during maven deploy

[Dan Tran]

my particular module has one optional RPM dependency. this means it only
downloads one dependency and no transitive

not sure why this cause the strange metadata download behavior

-D


On Fri, May 12, 2017 at 3:49 AM, Robert Scholte 
wrote:

> My guess: references to snapshots or version ranges in one of your
> (transitive) dependencies.
>
> Robert
>

Excessive download/upload of maven-metadata.xml during maven deploy

[Dan Tran]

Hi

About 20 pairs of the below lines

[INFO] Downloading:
http://myComp:8081/artifactory/snapshots//maven-metadata.xml

[INFO] Downloaded:
http://myComp:8081/artifactory/snapshots//maven-metadata.xml

(349 B at 39 kB/s)


showing up in my build log

any idea what causes this behavior?

Thanks

-Dan

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Dan Tran]

On Wed, May 10, 2017 at 11:50 AM, Karl Heinz Marbaise <khmarba...@gmx.de>
wrote:

> Hi Dan,
>
> On 10/05/17 00:59, Dan Tran wrote:
>
>> Hi
>>
>> I am in the process of switching our 250+ modules to version-less poms.
>> There are 2 phases
>>
>> 1. Activated flatten poms.  Every thing seems ok,
>>
>
> Good to hear that...
>
> > except those external
>
>> modules which depends on a full pom.xml at maven repo. This is fixable
>>
>
> Can you give more details about that? What that means?


any project depends on any flatten pom is screwed!!! but that is there
problem, they should not do that




>
>
> 2. Switched   versionless using ${revision} at a dev branch.  Looking good,
>> except final maven memory report increases significantly by 2G for both
>> min
>> and max
>>
>
> you mean the output of Maven at BUILD SUCCESS ?
>

Yes


>
> Do you have the option to test with JConsole during the run of the build
> and see how the evolution of the memory usage is going over the time? Can
> you give the exact values for -Xmx, -Xms etc. and which JDK you are using ?
>
> currently, I don't set any memory settings. My build is under SLES12SP2
docker container with latest  openjdk  1.8.x


>
> Hm...Maven 3.5.0 contains a fix for larger reactors which caused a bigger
> issues with large reactors (See https://github.com/khmarbaise/
> maven-test-project-generator).
>
> I'm really astonished cause Maven 3.3.9 used more memory than 3.5.0 did
> (based on my tests)...Maybe the changes for the properties (revision,
> changelist, sha1) might be the culprit...
>
>
> No major hickup at IDEs eclipse, Intellij, and netbeans
>>
>
> No major means there are some? Do you have some more details...
>
>
One one my NetBean user notices  'Build with dependencies' is much slower.
But he only does it once a day



>
> Kind regards
> Karl Heinz Marbaise
>
>>
>> If you have any idea on the root cause of memory issue please advice
>>
>> Thanks
>>
>> -Dan
>>
>> On Mon, May 8, 2017 at 10:27 AM, Karl Heinz Marbaise <khmarba...@gmx.de>
>> wrote:
>>
>> Hi to all,
>>>
>>> I think it is needed to explain that in more detail (means also to
>>> improve
>>> the ci documentation).
>>>
>>>
>>> Let me start with the following:
>>>
>>> You can only use those three names "revision", "changelist" and "sha1" in
>>> a version tag of the pom file cause they are handled special (the
>>> foundation of its handling is given by the explanation of Bernd Eckenfeld
>>> Thanks to Bernd).
>>>
>>> This means in consequence the given part will not work as expected (at
>>> the
>>> moment):
>>>
>>> com.soebes.examples.j2ee
>>> parent>>
>>>>
>>>> ${revision}
>>> pom
>>> 
>>>   1.2.1-${buildNumber}
>>>   SNAPSHOT
>>> 
>>>
>>>
>>> If you like to make combinations you can do it like this for example:
>>> (https://github.com/khmarbaise/javaee/tree/maven350-properties):
>>>
>>>   com.soebes.examples.j2ee
>>>   parent
>>>   ${revision}${sha1}${changelist}
>>>   pom
>>>
>>>   
>>> 1.6
>>> 1.6
>>> 1.3.1
>>> -SNAPSHOT
>>> 
>>>   
>>>
>>> or to pickup the previous example which should look like this:
>>>
>>> com.soebes.examples.j2ee
>>> parent>>
>>>>
>>>> ${revision}${changelist}
>>> pom
>>> 
>>>   1.2.1
>>>   -SNAPSHOT
>>> 
>>>
>>> So now your build will work as expected.
>>>
>>> If you like to switch to release you simply do that by using the
>>> following:
>>>
>>> mvn -Dchangelist= clean package (This will define changelist as empty).
>>>
>>> Or if you like to give a buildNumber from commandline:
>>>
>>> mvn -Dchangelist=-23-SNAPSHOT clean package
>>>
>>> So to make it more convenient you can define the versions like this:
>>>
>>>   com.soebes.examples.j2ee
>>>   parent
>>>   ${revision}${sha1}${changelist}
>>>   pom
>>>
>>>   
>>> 1.6
>>> 1.6
>>> 1.3.1
>>> -SNAPSHOT
>>> 
>>>   
>>>
>>> So now I can build via (be carefull with the separator between version
>>> and

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Dan Tran]

>>
> >>>> 1 5_A4OMXDtdtFyA=  was cached in the local reposito ry, resolution
> >>>>>>> will not be reattempted until the update interval of repo1 has el
> >>>>>>>
> >>>>>> apsed
> >>>>
> >>>>> or updates are forced and 'parent.relativePath' points at wrong local
> >>>>>
> >>>> POM @
> >>>>
> >>>>> line 7, column 13  @ [ERROR] The build could not read 1 project ->
> >>>>>
> >>>> [Help
> >>>
> >>>> 1]
> >>>>
> >>>>> [ERROR]
> >>>>>
> >>>>>> [ERROR]   The project oracle.jcs.lifecycle:util:[unknown-version]
> >>>>>>>
> >>>>>> (C:\rpatrick\w
> >>>>>
> >>>>>> ork\projects\jcs-las\util\pom.xml) has 1 error
> >>>>>>> [ERROR] Non-resolvable parent POM for
> >>>>>>>
> >>>>>> oracle.jcs.lifecycle:util:[
> >>>
> >>>> unknown-ver
> >>>>>
> >>>>>> sion]: Failure to find
> >>>>>>> oracle.jcs.lifecycle:app-to-cloud:pom:${revision} in http
> >>>>>>> ://artifactory-slc.oraclecorp.com/artifactory/repo1 was cached in
> >>>>>>>
> >>>>>> the
> >>>
> >>>> local repo sitory, resolution will not be reattempted until the
> >>>>>>> update interval of repo1 ha s elapsed or updates are forced and
> >>>>>>> 'parent.relativePath' points at wrong local POM @ line 7, column 13
> >>>>>>> -> [Help 2] [ERROR] [ERROR] To see the full stack trace of the
> >>>>>>> errors, re-run Maven with the -e swit ch.
> >>>>>>> [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 rea d the following articles:
> >>>>>>> [ERROR] [Help 1]
> >>>>>>>
> >>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.ap
> >>> ache.org_
> >>>
> >>>> c
> >>>>>>>
> >>>>>>> onfluence_display_MAVEN_ProjectBuildin=DwIDaQ=RoP1YumCXC
> >>> gaWHvlZYR
> >>>
> >>>> 8
> >>>>>>>
> >>>>>>> PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_
> >>> OzwdxJosG0
> >>>
> >>>> &
> >>>>>>>
> >>>>>>> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=Gpqh8tXn87EJ
> >>> PGvORYVRo
> >>>
> >>>> H
> >>>>>>> s2ncTiyaZSJWc3AEyEsUQ=
> >>>>>>> gException
> >>>>>>> [ERROR] [Help 2]
> >>>>>>>
> >>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.ap
> >>> ache.org_
> >>>
> >>>> c
> >>>>>>>
> >>>>>>> onfluence_display_MAVEN_UnresolvableMo=DwIDaQ=RoP1YumCXC
> >>> gaWHvlZYR
> >>>
> >>>> 8
> >>>>>>>
> >>>>>>> PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_
> >>> OzwdxJosG0
> >>>
> >>>> &
> >>>>>>>
> >>>>>>> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=kjqcy_wD0H5q
> >>> wfISMGTZr
> >>>
> >>>> q
> >>>>>>> XoHWM-jV5GAbTtEvug-bc=
> >>>>>>> delException
> >>>>>>>
> >>>>>>>
> >>>>>>> Did I miss something?
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Robert
> >>>>>>>
> >>>>>>> -Original Message-
> >>>>>>> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> >>>>>>> Sent: Thursday, May 04, 2017 3:02 PM
> >>>>>>> To: Maven Users List
> >>>>>>> Subject: Re: Continuous Delivery with Maven now possible?
> >>>>>>>
> >>>>>>> Hi Robert,
> >>>>>>>
> >>>>>>>
> >>>>>>> On 04/05/17 21:55, Robert Patrick wrote:
> >>>>>>>
> >>>>>>> With 3.5, you can now use a variable *but* that variable
> >>>>>>>>
> >>>>>>>  > has to be accessible to the POM prior to finding its  > parent
> so
> >>>>>>> the only solution is to move the  >  version number outside the POM
> >>>>>>> hierarchy and into a -D defined
> >>>>>>>
> >>>>>>>> variable.
> >>>>>>>>
> >>>>>>>
> >>>>>>> Which is not true. You can define the property inside the pom file
> >>>>>>>
> >>>>>> if
> >>>
> >>>> you like and can overwrite the version via command line
> >>>>>
> >>>> (-Drevision=...).
> >>>
> >>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>  > While this works, it seems to have some undesirable  > aspects
> to
> >>>>>>> it.  In my opinion, it would be better if  > Maven could find a way
> >>>>>>> to resolve this issue  > without resorting to -Ds to specify the  >
> >>>>>>> value of the variable.
> >>>>>>>  > I am not sure it is possible but I also worry  > about moving
> the
> >>>>>>> version number outside the POM...
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Maybe Maven should consider a mechanism by which the project
> >>>>>>>>
> >>>>>>> version
> >>>
> >>>> number can be defined in a separate location that is:
> >>>>>
> >>>>>>
> >>>>>>>> 1.) Well-known so that all resolution can happen directly by
> >>>>>>>> interacting with this location directly, without the need to
> >>>>>>>> traverse the parent hierarchy
> >>>>>>>> 2.) It is part of the project structure so that it can be managed
> >>>>>>>>
> >>>>>>> in
> >>>
> >>>> the project's source control system
> >>>>>>>> 3.) It cannot be overridden at build time with command-line
> >>>>>>>>
> >>>>>>> arguments.
> >>>>
> >>>>> 4.) Has a mechanism by which to reference it from all the necessary
> >>>>>>>> locations within the POMs
> >>>>>>>>
> >>>>>>>> Maybe something like an optional .mvn/project.version file and a
> >>>>>>>>
> >>>>>>> variable that cannot be overridden to refer to it?
> >>>>>
> >>>>>>
> >>>>>>>> -Original Message-
> >>>>>>>> From: Eric Benzacar [mailto:e...@benzacar.ca]
> >>>>>>>> Sent: Thursday, May 04, 2017 12:53 PM
> >>>>>>>> To: Maven Users List
> >>>>>>>> Subject: Re: Continuous Delivery with Maven now possible?
> >>>>>>>>
> >>>>>>>> I've read through Karl's blog
> >>>>>>>> (
> >>>>>>>>
> >>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.
> soebes.de_
> >>>
> >>>> b
> >>>>>>>>
> >>>>>>>> log_=DwIFaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&
> >>> r=Ql5uwm
> >>>
> >>>> b
> >>>>>>>>
> >>>>>>>> ofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0=0Ys4DN-HQMZpvVqWFa1z9
> >>> 1pnAzKb4
> >>>
> >>>> A YSpzB_W99oBqY=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk=
> >>>>>>>> 2017/04/02/maven-pom-files-without-a-version-in-it/), and while I
> >>>>>>>>
> >>>>>>> understand the approach, there is still one critical issue that
> >>>>> bothers
> >>>>> me.  I think this actually reopens an old thread that circulated on
> >>>>>
> >>>> this
> >>>
> >>>> list a few months ago, but it related to the Idempotence of a pom
> file.
> >>>>>
> >>>>>>
> >>>>>>>> >From my perspective/view a pom file should be idempotent.  That
> is
> >>>>>>>>
> >>>>>>> every single build of a given NON-SNAPSHOT pom file should finish
> >>>>> with
> >>>>>
> >>>> the
> >>>>
> >>>>> same build.  But by moving a release number or version number outside
> >>>>>
> >>>> of
> >>>
> >>>> the pom, it eliminates this need.  Furthermore, from a traceability
> >>>>> perspective, my source control can no longer show me precisely
> version
> >>>>>
> >>>> was
> >>>>
> >>>>> being built/developed at any given time.
> >>>>>
> >>>>>>
> >>>>>>>> By leveraging the mvn.config file, I'm a little further down the
> >>>>>>>>
> >>>>>>> path,
> >>>>
> >>>>> but none the less, the value can be overridden at build time with a
> >>>>> completely different value.  Consequently, I can still not be 100%
> >>>>> confident that a pom delivered a particular version.
> >>>>>
> >>>>>>
> >>>>>>>> I'm still not 100% sure of the best approach going forward, but
> I'm
> >>>>>>>>
> >>>>>>> thinking that something like the version-plugin being able to
> >>>>>
> >>>> manipulate
> >>>
> >>>> a
> >>>>
> >>>>> revision property that can then be committed as part of the pom would
> >>>>>
> >>>> be
> >>>
> >>>> the best of both approaches.  In that way, my developers can fix the
> >>>>> version number, but my build system can manipulate the revision
> >>>>>
> >>>> property.
> >>>
> >>>>
> >>>>>>>> Does anyone know if there is a plugin that will allow for that?
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> Eric
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <
> https://urldefense
> >>>>>>>>
> >>>>>>> .
> >>>
> >>>> proofpoint.com/v2/url?u=http-3A__t.broyer-40gmail.com=
> >>>>> DwIFaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=
> >>>>> dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=
> >>>>> mQrJOCEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY=
> >>>>> 0PY7XDt7qFb0WfiWMn1CIgxZ2Q6apBhIlOqIgfU0A3A= > wrote:
> >>>>>
> >>>>>>
> >>>>>>>> How about everybody read their mail?
> >>>>>>>>> (see below)
> >>>>>>>>>
> >>>>>>>>> On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <ctrue...@wisc.edu>
> >>>>>>>>>
> >>>>>>>> wrote:
> >>>>>
> >>>>>>
> >>>>>>>>> Hi Dan, Karl & everyone,
> >>>>>>>>>>
> >>>>>>>>>> See Karl's Blog
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Link, please?
> >>>>>>>>>>
> >>>>>>>>>> [...]
> >>>>>>>>>
> >>>>>>>>> On 03/05/17 20:39, Dan Tran wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hi
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I have been experimenting with suggestion from Karl [1] with
> >>>>>>>>>>>>>> small
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> multi
> >>>>>>>>>>>
> >>>>>>>>>>>> module maven project.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>> [...]
> >>>>>>>>>
> >>>>>>>>> [1]
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.
> soeb
> >>>
> >>>> es.de_blog_2017_04_02_maven-2Dpom-2Dfiles-2Dwithou=DwIFaQ
> >>>>>>>>>>>>>> =RoP1YumCXCgaWHvlZYR8PQcxBKCX5Y
> TpkKY057SbK10=Ql5uwmbofQMW0i
> >>>>>>>>>>>>>> ErugdCnFgO-CBGr_pt_OzwdxJosG0=0Ys4DN-
> HQMZpvVqWFa1z91pnAzKb4
> >>>>>>>>>>>>>> AYSpzB_W99oBqY=RYXyGU3piqrAe7XDXXTuPvbcQH935s
> duSNhMeYstT8Y&
> >>>>>>>>>>>>>> e=
> >>>>>>>>>>>>>> t-a-version-in-it/
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>> 
> --
> >>>>> This e-mail, including any attached files, may contain confidential
> and
> >>>>> privileged information for the sole use of the intended recipient.
> Any
> >>>>> review, use, distribution, or disclosure by others is strictly
> >>>>>
> >>>> prohibited.
> >>>>
> >>>>> If you are not the intended recipient (or authorized to receive
> >>>>>
> >>>> information
> >>>>
> >>>>> for the intended recipient), please contact the sender by reply
> e-mail
> >>>>>
> >>>> and
> >>>>
> >>>>> delete all copies of this message.
> >>>>>
> >>>>>
> >>>>
> >>>
> >
> > Mit freundlichem Gru?
> > Karl-Heinz Marbaise
> > --
> > SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
> > Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579
> > Hauptstrasse 177
> > 52146 W?rselen   http://www.soebes.de
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Dan Tran]

gt;>> umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugd
>>> CnFgO-CBG
>>>
>>>> r
>>>>>>>
>>>>>>> _pt_OzwdxJosG0=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY
>>> =by9uci
>>>
>>>> i pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE=
>>>>>>>
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc
>>> .
>>>
>>>> o
>>>>>>>
>>>>>>> raclecorp.com_artifactory_repo1=DwIFaQ=PskvixtEUDK7wuWU-
>>> tIg6oKuGY
>>>
>>>> B
>>>>>>>
>>>>>>> RbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEi
>>> Tk=mQrJ
>>>
>>>> O
>>>>>>>
>>>>>>> CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY=oPO-3-7EEwzSMAr8-re
>>> 0YxZdReMu
>>>
>>>> 1 5_A4OMXDtdtFyA=  was cached in the local reposito ry, resolution
>>>>>>> will not be reattempted until the update interval of repo1 has el
>>>>>>>
>>>>>> apsed
>>>>
>>>>> or updates are forced and 'parent.relativePath' points at wrong local
>>>>>
>>>> POM @
>>>>
>>>>> line 7, column 13  @ [ERROR] The build could not read 1 project ->
>>>>>
>>>> [Help
>>>
>>>> 1]
>>>>
>>>>> [ERROR]
>>>>>
>>>>>> [ERROR]   The project oracle.jcs.lifecycle:util:[unknown-version]
>>>>>>>
>>>>>> (C:\rpatrick\w
>>>>>
>>>>>> ork\projects\jcs-las\util\pom.xml) has 1 error
>>>>>>> [ERROR] Non-resolvable parent POM for
>>>>>>>
>>>>>> oracle.jcs.lifecycle:util:[
>>>
>>>> unknown-ver
>>>>>
>>>>>> sion]: Failure to find
>>>>>>> oracle.jcs.lifecycle:app-to-cloud:pom:${revision} in http
>>>>>>> ://artifactory-slc.oraclecorp.com/artifactory/repo1 was cached in
>>>>>>>
>>>>>> the
>>>
>>>> local repo sitory, resolution will not be reattempted until the
>>>>>>> update interval of repo1 ha s elapsed or updates are forced and
>>>>>>> 'parent.relativePath' points at wrong local POM @ line 7, column 13
>>>>>>> -> [Help 2] [ERROR] [ERROR] To see the full stack trace of the
>>>>>>> errors, re-run Maven with the -e swit ch.
>>>>>>> [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 rea d the following articles:
>>>>>>> [ERROR] [Help 1]
>>>>>>>
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.ap
>>> ache.org_
>>>
>>>> c
>>>>>>>
>>>>>>> onfluence_display_MAVEN_ProjectBuildin=DwIDaQ=RoP1YumCXC
>>> gaWHvlZYR
>>>
>>>> 8
>>>>>>>
>>>>>>> PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_
>>> OzwdxJosG0
>>>
>>>> &
>>>>>>>
>>>>>>> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=Gpqh8tXn87EJ
>>> PGvORYVRo
>>>
>>>> H
>>>>>>> s2ncTiyaZSJWc3AEyEsUQ=
>>>>>>> gException
>>>>>>> [ERROR] [Help 2]
>>>>>>>
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.ap
>>> ache.org_
>>>
>>>> c
>>>>>>>
>>>>>>> onfluence_display_MAVEN_UnresolvableMo=DwIDaQ=RoP1YumCXC
>>> gaWHvlZYR
>>>
>>>> 8
>>>>>>>
>>>>>>> PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_
>>> OzwdxJosG0
>>>
>>>> &
>>>>>>>
>>>>>>> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=kjqcy_wD0H5q
>>> wfISMGTZr
>>>
>>>> q
>>>>>>> XoHWM-jV5GAbTtEvug-bc=
>>>>>>> delException
>>>>>>>
>>>>>>>
>>>>&

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Dan Tran]

Hi Karl

I think you already made changes to the the plugin,  but will file ticket
to make it official

-D

On Thu, May 4, 2017 at 10:09 PM, Karl Heinz Marbaise <khmarba...@gmx.de>
wrote:

> Hi Dan,
>
> On 05/05/17 02:30, Dan Tran wrote:
>
>> is flatten-maven-plugin threadsafe?   if not, we have a problem with large
>> project where multhreaded build is a must have
>>
>> maven 3.5 displays a warning on flatten-maven-plugin not thread safe
>>
>
> I need to take a look...can you file in a ticket on flatten-maven-plugin..
>
> Thanks.
>
> Kind regards
> Karl Heinz Marbaise
>
>
>> Thanks
>>
>> -D
>>
>> On Thu, May 4, 2017 at 2:52 PM, Karl Heinz Marbaise <khmarba...@gmx.de>
>> wrote:
>>
>> Hi,
>>>
>>> On 04/05/17 22:52, Justin Georgeson wrote:
>>>
>>> Also I believe the partial reactor switches don't work for Tycho builds.
>>>>
>>>>
>>> You mean -pl ..option I suppose?
>>>
>>> As far as I know Tycho is handling that at the wrong time of the maven
>>> build and furthermore handles in this relationship some other things
>>> wrong
>>> which results in not working things like this..
>>>
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>>
>>> -Original Message-
>>>> From: Robert Patrick [mailto:robert.patr...@oracle.com]
>>>> Sent: Thursday, May 4, 2017 3:18 PM
>>>> To: Maven Users List <users@maven.apache.org>; i...@soebes.de
>>>> Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
>>>>
>>>> External Sender: Use caution with links/attachments.
>>>>
>>>>
>>>>
>>>> Hard to train developers to break old habits but thanks... :-)
>>>>
>>>>
>>>>
>>>> -Original Message-
>>>> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
>>>> Sent: Thursday, May 04, 2017 3:16 PM
>>>> To: Robert Patrick; Maven Users List; i...@soebes.de
>>>> Subject: Re: Continuous Delivery with Maven now possible?
>>>>
>>>> Hi Robert,
>>>>
>>>> Ah now I see the issue.
>>>>
>>>> If you have a multi module build you should use
>>>>
>>>> mvn -pl moduleToBuild clean install
>>>>
>>>> but from root location and don't change into the module directory cause
>>>> this can't work like this.
>>>>
>>>> Kind regards
>>>> Karl Heinz Marbaise
>>>>
>>>> On 04/05/17 22:08, Robert Patrick wrote:
>>>>
>>>> Hi Karl,
>>>>>
>>>>> If I define the revision property in the top-level POM, I cannot refer
>>>>> to it in the module POMs'  elements *and* still retain the
>>>>> ability
>>>>> to build from the module directory, right?  I tried this and it failed
>>>>> because it was unable to resolve the revision property variable.
>>>>>
>>>>> C:\rpatrick\work\projects\jcs-las\util>mvn clean install [INFO]
>>>>> Scanning for projects...
>>>>> [ERROR] [ERROR] Some problems were encountered while processing the
>>>>> POMs:
>>>>> [FATAL] Non-resolvable parent POM for
>>>>> oracle.jcs.lifecycle:util:[unknown-version
>>>>> ]: Failure to find oracle.jcs.lifecycle:app-to-cloud:pom:${revision}
>>>>> in
>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__a=DwIDaQ=RoP1Y
>>>>> umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr
>>>>> _pt_OzwdxJosG0=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=by9ucii
>>>>> pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE=
>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc.o
>>>>> raclecorp.com_artifactory_repo1=DwIFaQ=PskvixtEUDK7wuWU-tIg6oKuGYB
>>>>> RbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=mQrJO
>>>>> CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY=oPO-3-7EEwzSMAr8-re0YxZdReMu1
>>>>> 5_A4OMXDtdtFyA=  was cached in the local reposito ry, resolution will
>>>>> not be reattempted until the update interval of repo1 has el apsed or
>>>>> updates are forced and 'parent.relativePath' points at wrong local POM
>>>>> @
>>>>> line 7, column 13  @ [ERROR] The build could not read 1 project ->
>>>>> [Help 1]
>>>

Re: Intermittent java.lang.NoClassDefFoundError: org/junit/runner/notification/RunNotifier

[Dan Tran]

@Fabian, one more time you have come to my rescue.   Indeed, we introduce a
new MOJO  and it has aggregate flag set to true

Thanks again

-Dan

On Fri, May 5, 2017 at 8:56 AM, Dan Tran <dant...@gmail.com> wrote:

> @Fabian, yes i do recall vaguely with your and I have a good run for a
> year :-). Thanks for the reminder, i can search thru new mojos lately
> introduced to the build and find out. Thanks
>
> @Martin,  i do use hamcrest
>
> -D
>
> On Fri, May 5, 2017 at 4:42 AM, Martin Gainty <mgai...@hotmail.com> wrote:
>
>>
>>
>> 
>> From: Dan Tran <dant...@gmail.com>
>> Sent: Friday, May 5, 2017 3:51 AM
>> To: Maven Users List
>> Subject: Intermittent java.lang.NoClassDefFoundError:
>> org/junit/runner/notification/RunNotifier
>>
>> Hi
>>
>> Lately, my build randomly fails with
>>
>>   java.lang.NoClassDefFoundError: org/junit/runner/notification/
>> RunNotifier
>>  at surefire
>>
>>
>> My environment consists of
>>
>>   * 200+ modules  running with --builder smart  -T 4
>>   * surefire 2.19.1 and 2.20, maven 3.3.9 and 3.5
>>   * Build runs on Sles12SP2 with OpenJDK8
>>
>> Stack Overflow has a similar issue back in 2014
>>
>> MG>assuming you are not using Hamcrest following surefire doc i assume
>> declaring junit-dep as dependency to maven-surefire-plugin will solve
>>
>>   
>>   
>> junit
>> junit-dep
>>
>>  test
>>   
>>
>> MG>http://maven.apache.org/surefire/maven-surefire-plugin/
>> examples/junit.html
>> <http://maven.apache.org/surefire/maven-surefire-plugin/
>> examples/junit.html>
>> Maven Surefire Plugin – Using JUnit<http://maven.apache.org/
>> surefire/maven-surefire-plugin/examples/junit.html>
>> maven.apache.org
>> This is the only step that is required to get started - you can now
>> create tests in your test source directory (e.g., src/test/java). Surefire
>> supports three ...
>>
>> MG>once junit added as dependency supposedly surefire test classloader
>> will now see junit classes (including org/junit/runner/notification/
>> RunNotifier)
>> MG>does this help?
>>
>>
>> Any suggestion helping to trouble shoot this issue is greatly appreciated
>>
>> Thanks
>>
>> -Dan
>>
>
>

Re: Intermittent java.lang.NoClassDefFoundError: org/junit/runner/notification/RunNotifier

[Dan Tran]

@Fabian, yes i do recall vaguely with your and I have a good run for a year
:-). Thanks for the reminder, i can search thru new mojos lately introduced
to the build and find out. Thanks

@Martin,  i do use hamcrest

-D

On Fri, May 5, 2017 at 4:42 AM, Martin Gainty <mgai...@hotmail.com> wrote:

>
>
> ________
> From: Dan Tran <dant...@gmail.com>
> Sent: Friday, May 5, 2017 3:51 AM
> To: Maven Users List
> Subject: Intermittent java.lang.NoClassDefFoundError:
> org/junit/runner/notification/RunNotifier
>
> Hi
>
> Lately, my build randomly fails with
>
>   java.lang.NoClassDefFoundError: org/junit/runner/notification/
> RunNotifier
>  at surefire
>
>
> My environment consists of
>
>   * 200+ modules  running with --builder smart  -T 4
>   * surefire 2.19.1 and 2.20, maven 3.3.9 and 3.5
>   * Build runs on Sles12SP2 with OpenJDK8
>
> Stack Overflow has a similar issue back in 2014
>
> MG>assuming you are not using Hamcrest following surefire doc i assume
> declaring junit-dep as dependency to maven-surefire-plugin will solve
>
>   
>   
> junit
> junit-dep
>
>  test
>   
>
> MG>http://maven.apache.org/surefire/maven-surefire-
> plugin/examples/junit.html
> <http://maven.apache.org/surefire/maven-surefire-
> plugin/examples/junit.html>
> Maven Surefire Plugin – Using JUnit<http://maven.apache.org/
> surefire/maven-surefire-plugin/examples/junit.html>
> maven.apache.org
> This is the only step that is required to get started - you can now create
> tests in your test source directory (e.g., src/test/java). Surefire
> supports three ...
>
> MG>once junit added as dependency supposedly surefire test classloader
> will now see junit classes (including org/junit/runner/notification/
> RunNotifier)
> MG>does this help?
>
>
> Any suggestion helping to trouble shoot this issue is greatly appreciated
>
> Thanks
>
> -Dan
>

Intermittent java.lang.NoClassDefFoundError: org/junit/runner/notification/RunNotifier

[Dan Tran]

Hi

Lately, my build randomly fails with

  java.lang.NoClassDefFoundError: org/junit/runner/notification/RunNotifier
 at surefire


My environment consists of

  * 200+ modules  running with --builder smart  -T 4
  * surefire 2.19.1 and 2.20, maven 3.3.9 and 3.5
  * Build runs on Sles12SP2 with OpenJDK8

Stack Overflow has a similar issue back in 2014

Any suggestion helping to trouble shoot this issue is greatly appreciated

Thanks

-Dan

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Dan Tran]

aQ=RoP1YumCXCgaWHvlZYR8
>>> PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
>>> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=Gpqh8tXn87EJPGvORYVRoH
>>> s2ncTiyaZSJWc3AEyEsUQ=
>>> gException
>>> [ERROR] [Help 2]
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_c
>>> onfluence_display_MAVEN_UnresolvableMo=DwIDaQ=RoP1YumCXCgaWHvlZYR8
>>> PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
>>> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=kjqcy_wD0H5qwfISMGTZrq
>>> XoHWM-jV5GAbTtEvug-bc=
>>> delException
>>>
>>>
>>> Did I miss something?
>>>
>>> Thanks,
>>> Robert
>>>
>>> -Original Message-
>>> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
>>> Sent: Thursday, May 04, 2017 3:02 PM
>>> To: Maven Users List
>>> Subject: Re: Continuous Delivery with Maven now possible?
>>>
>>> Hi Robert,
>>>
>>>
>>> On 04/05/17 21:55, Robert Patrick wrote:
>>>
>>> With 3.5, you can now use a variable *but* that variable
>>>>
>>>  > has to be accessible to the POM prior to finding its  > parent so
>>> the only solution is to move the  >  version number outside the POM
>>> hierarchy and into a -D defined
>>>
>>>> variable.
>>>>
>>>
>>> Which is not true. You can define the property inside the pom file if
>>> you like and can overwrite the version via command line (-Drevision=...).
>>>
>>>
>>>
>>>  > While this works, it seems to have some undesirable  > aspects to
>>> it.  In my opinion, it would be better if  > Maven could find a way to
>>> resolve this issue  > without resorting to -Ds to specify the  > value
>>> of the variable.
>>>  > I am not sure it is possible but I also worry  > about moving the
>>> version number outside the POM...
>>>
>>>>
>>>> Maybe Maven should consider a mechanism by which the project version
>>>> number can be defined in a separate location that is:
>>>>
>>>> 1.) Well-known so that all resolution can happen directly by
>>>> interacting with this location directly, without the need to traverse
>>>> the parent hierarchy
>>>> 2.) It is part of the project structure so that it can be managed in
>>>> the project's source control system
>>>> 3.) It cannot be overridden at build time with command-line arguments.
>>>> 4.) Has a mechanism by which to reference it from all the necessary
>>>> locations within the POMs
>>>>
>>>> Maybe something like an optional .mvn/project.version file and a
>>>> variable that cannot be overridden to refer to it?
>>>>
>>>> -Original Message-
>>>> From: Eric Benzacar [mailto:e...@benzacar.ca]
>>>> Sent: Thursday, May 04, 2017 12:53 PM
>>>> To: Maven Users List
>>>> Subject: Re: Continuous Delivery with Maven now possible?
>>>>
>>>> I've read through Karl's blog
>>>> (https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soebes.de_b
>>>> log_=DwIFaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmb
>>>> ofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4A
>>>> YSpzB_W99oBqY=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk=
>>>> 2017/04/02/maven-pom-files-without-a-version-in-it/), and while I
>>>> understand the approach, there is still one critical issue that bothers
>>>> me.  I think this actually reopens an old thread that circulated on this
>>>> list a few months ago, but it related to the Idempotence of a pom file.
>>>>
>>>> >From my perspective/view a pom file should be idempotent.  That is
>>>> every single build of a given NON-SNAPSHOT pom file should finish with the
>>>> same build.  But by moving a release number or version number outside of
>>>> the pom, it eliminates this need.  Furthermore, from a traceability
>>>> perspective, my source control can no longer show me precisely version was
>>>> being built/developed at any given time.
>>>>
>>>> By leveraging the mvn.config file, I'm a little further down the path,
>>>> but none the less, the value can be overridden at build time with a
>>>> completely different value.  Consequently, I can still not be 100%
>>>> confident that a

Re: Continuous Delivery with Maven now possible?

[Dan Tran]

for trace-ability,  i add this to top level pom

 
org.codehaus.mojo
buildnumber-maven-plugin

  
this-has-scm-info-for-tagging-and-tracability-purpose
prepare-package

  create-metadata

false 

  date
  .MM.dd
  true
  
${project.scm.developerConnection}
  

  

  

On Thu, May 4, 2017 at 10:53 AM, Eric Benzacar <e...@benzacar.ca> wrote:

> I've read through Karl's blog (http://blog.soebes.de/blog/
> 2017/04/02/maven-pom-files-without-a-version-in-it/), and while I
> understand the approach, there is still one critical issue that bothers
> me.  I think this actually reopens an old thread that circulated on this
> list a few months ago, but it related to the Idempotence of a pom file.
>
> From my perspective/view a pom file should be idempotent.  That is every
> single build of a given NON-SNAPSHOT pom file should finish with the same
> build.  But by moving a release number or version number outside of the
> pom, it eliminates this need.  Furthermore, from a traceability
> perspective, my source control can no longer show me precisely version was
> being built/developed at any given time.
>
> By leveraging the mvn.config file, I'm a little further down the path, but
> none the less, the value can be overridden at build time with a completely
> different value.  Consequently, I can still not be 100% confident that a
> pom delivered a particular version.
>
> I'm still not 100% sure of the best approach going forward, but I'm
> thinking that something like the version-plugin being able to manipulate a
> revision property that can then be committed as part of the pom would be
> the best of both approaches.  In that way, my developers can fix the
> version number, but my build system can manipulate the revision property.
>
> Does anyone know if there is a plugin that will allow for that?
>
> Thanks,
>
> Eric
>
>
> On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <t.bro...@gmail.com> wrote:
>
> > How about everybody read their mail?
> > (see below)
> >
> > On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <ctrue...@wisc.edu> wrote:
> >
> > > Hi Dan, Karl & everyone,
> > >
> > > > See Karl's Blog
> > >
> > > Link, please?
> > >
> > […]
> >
> > > > > > On 03/05/17 20:39, Dan Tran wrote:
> > > > > >
> > > > > >> Hi
> > > > > >>
> > > > > >> I have been experimenting with suggestion from Karl [1] with
> small
> > > > multi
> > > > > >> module maven project.
> >
> > […]
> >
> > > > > >> [1]
> > > > > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> > > > > >> t-a-version-in-it/
> > >
> >
>

Re: Continuous Delivery with Maven now possible?

[Dan Tran]

a couple corrections:

  * for Jenkins freeslyle, one can create a job parameter  similiar to this
format   revision=x.y.x-${BUILD_NUMBER} to override the default maven
version

  * for Jenkins Pipeline, the revision handling is part of  projec's t
Jenkinsfile

The original blog is here http://blog.soebes.de/blog/
2017/04/02/maven-pom-files-without-a-version-in-it/

-D

On Wed, May 3, 2017 at 5:54 PM, Dan Tran <dant...@gmail.com> wrote:

> I am able to bring it to production with very small project with few
> modules. Where I hook up jenkins build number with the version
>
>   1.0.0-${env.BUILD_NUMBER}  See Karl's Blog
>
> At the same time,  use buildnumber-m-p to deploy text file with SCM info,
> and finally push to staging repo using Artifactory
>
> Once a build is promoted (GAed), I then remove the rest from staging,  and
> manually tag the build using the recorded SCM info
>
> My next task is a much bigger project with 300+ modules and lots of
> dev/qa.  So it is crucial i dont break their development environments
>
> Thanks
>
> -Dan
>
>
> On Wed, May 3, 2017 at 5:34 PM, Eric B <ebenza...@gmail.com> wrote:
>
>> Hi Karl,
>>
>> Can you provide a little more information how you are doing this? Or do
>> you
>> have a blog about it somewhere? It's something I desperately need to
>> insert
>> into my build pipeline but haven't had the time to work on yet.  So far,
>> the best I've been able to think of is to use a parameter for a build
>> number, have Jenkins assign a build number, pass it to maven, and have the
>> version reflect the build number using the external parameter.  But I
>> really don't like that idea as the version is now dependent on a variable,
>> which I find is contrary to the whole concept.
>>
>> The other option is to have Jenkins took the build number in the pom using
>> the release plugin or the version plugin, commit the new pom, and then
>> build from a newly checked out code.  My issue there is that I'm having
>> Jenkins do a lot of scm manipulations which are more subject to failing
>> (ie: version updates, commit, tag, push, etc).
>>
>> Finally, I'm trying to think of a good way of rolling all this into Nexus
>> staging repos and only promoting a build out of a staging repo once it
>> passes the pre prod environment and is certified for prod.
>>
>> Any ideas, thoughts, feedback and/or tips would be greatly appreciated.
>>
>> Thanks,
>>
>> Eric
>>
>> On May 3, 2017 2:50 PM, "Karl Heinz Marbaise" <khmarba...@gmx.de> wrote:
>>
>> > Hi Dan,
>> >
>> > I'm trying to do something in this direction starting next week...
>> >
>> > Apart from that already tested it with Eclipse Neon without any
>> > issue...(at the moment only test projects with 10-15 modules)...
>> >
>> > But it works at the moment..
>> >
>> > In the meantime I have found one issue which is related to
>> > maven-enforcer-plugin where I already opened an issue for it [1]..
>> >
>> > Kind regards
>> > Karl Heinz
>> >
>> > [1]: https://issues.apache.org/jira/browse/MENFORCER-268
>> >
>> > On 03/05/17 20:39, Dan Tran wrote:
>> >
>> >> Hi
>> >>
>> >> I have been experimenting with suggestion from Karl [1] with small
>> multi
>> >> module maven project.
>> >>
>> >>
>> >> Is there any one actually bring this to production for large scale
>> project
>> >> yet? Love to learn from your experience integration specially with
>> >> Jenkins,
>> >> IDE ( eclipse,  intellij, Netbean)
>> >>
>> >> this allows us to stop using maven-release-plugin
>> >>
>> >> Thanks
>> >>
>> >> -Dan
>> >>
>> >> [1]
>> >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
>> >> t-a-version-in-it/
>> >>
>> >>
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: users-h...@maven.apache.org
>> >
>> >
>>
>
>

Re: Continuous Delivery with Maven now possible?

[Dan Tran]

I am able to bring it to production with very small project with few
modules. Where I hook up jenkins build number with the version

  1.0.0-${env.BUILD_NUMBER}  See Karl's Blog

At the same time,  use buildnumber-m-p to deploy text file with SCM info,
and finally push to staging repo using Artifactory

Once a build is promoted (GAed), I then remove the rest from staging,  and
manually tag the build using the recorded SCM info

My next task is a much bigger project with 300+ modules and lots of
dev/qa.  So it is crucial i dont break their development environments

Thanks

-Dan


On Wed, May 3, 2017 at 5:34 PM, Eric B <ebenza...@gmail.com> wrote:

> Hi Karl,
>
> Can you provide a little more information how you are doing this? Or do you
> have a blog about it somewhere? It's something I desperately need to insert
> into my build pipeline but haven't had the time to work on yet.  So far,
> the best I've been able to think of is to use a parameter for a build
> number, have Jenkins assign a build number, pass it to maven, and have the
> version reflect the build number using the external parameter.  But I
> really don't like that idea as the version is now dependent on a variable,
> which I find is contrary to the whole concept.
>
> The other option is to have Jenkins took the build number in the pom using
> the release plugin or the version plugin, commit the new pom, and then
> build from a newly checked out code.  My issue there is that I'm having
> Jenkins do a lot of scm manipulations which are more subject to failing
> (ie: version updates, commit, tag, push, etc).
>
> Finally, I'm trying to think of a good way of rolling all this into Nexus
> staging repos and only promoting a build out of a staging repo once it
> passes the pre prod environment and is certified for prod.
>
> Any ideas, thoughts, feedback and/or tips would be greatly appreciated.
>
> Thanks,
>
> Eric
>
> On May 3, 2017 2:50 PM, "Karl Heinz Marbaise" <khmarba...@gmx.de> wrote:
>
> > Hi Dan,
> >
> > I'm trying to do something in this direction starting next week...
> >
> > Apart from that already tested it with Eclipse Neon without any
> > issue...(at the moment only test projects with 10-15 modules)...
> >
> > But it works at the moment..
> >
> > In the meantime I have found one issue which is related to
> > maven-enforcer-plugin where I already opened an issue for it [1]..
> >
> > Kind regards
> > Karl Heinz
> >
> > [1]: https://issues.apache.org/jira/browse/MENFORCER-268
> >
> > On 03/05/17 20:39, Dan Tran wrote:
> >
> >> Hi
> >>
> >> I have been experimenting with suggestion from Karl [1] with small multi
> >> module maven project.
> >>
> >>
> >> Is there any one actually bring this to production for large scale
> project
> >> yet? Love to learn from your experience integration specially with
> >> Jenkins,
> >> IDE ( eclipse,  intellij, Netbean)
> >>
> >> this allows us to stop using maven-release-plugin
> >>
> >> Thanks
> >>
> >> -Dan
> >>
> >> [1]
> >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> >> t-a-version-in-it/
> >>
> >>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Continuous Delivery with Maven now possible?

[Dan Tran]

Hi

I have been experimenting with suggestion from Karl [1] with small multi
module maven project.


Is there any one actually bring this to production for large scale project
yet? Love to learn from your experience integration specially with Jenkins,
IDE ( eclipse,  intellij, Netbean)

this allows us to stop using maven-release-plugin

Thanks

-Dan

[1]
http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/

Re: Surefire 2.20 slowing down?

[Dan Tran]

sorry about the noise, it is from one of our internal components

-D

On Sat, Apr 15, 2017 at 12:34 PM, Dan Tran <dant...@gmail.com> wrote:

>
> Hi
>
> I just notice my 200+ module running with --build smart -T 4 + surefire
> 2.20 build time is double
> from 7 to 15min
>
> Do you encounter the same problem?
>
> Thanks
>
> -Dan
>

Surefire 2.20 slowing down?

[Dan Tran]

Hi

I just notice my 200+ module running with --build smart -T 4 + surefire
2.20 build time is double
from 7 to 15min

Do you encounter the same problem?

Thanks

-Dan

Re: maven-artifact-transfer not able to resolve SNAPSHOT artifact

[Dan Tran]

Here you go.   https://issues.apache.org/jira/browse/MNG-6214

Thanks



On Wed, Apr 5, 2017 at 3:50 PM, Dan Tran <dant...@gmail.com> wrote:

> Eric,
>
> looks like we are on the boat.  I will file a Jira ticket
>
> Thanks
>
> -Dan
>
> On Wed, Apr 5, 2017 at 3:40 PM, Eric B <ebenza...@gmail.com> wrote:
>
>> Dan,
>>
>> It's this the same type of problem that I am encountering here:
>> http://stackoverflow.com/q/43220923/827480 ?
>>
>> For me I'm not sure of the genesis of the problem, but I suspect it is
>> something to do with maven not having a default snapshot repo to retrieve
>> artifacts.  But I don't know if you are seeing the same behaviour or if my
>> issue is at all related to your question.
>>
>> Thanks
>>
>> Eric
>>
>>
>> On Apr 3, 2017 1:55 AM, "Dan Tran" <dant...@gmail.com> wrote:
>>
>> Hi,
>>
>> I am very sure maven-artifact-transfer is not the issue.
>>
>> The real issue is MavenSession.ProjectBuildingRequest.RemoteRepositories,
>> needed by maven-artifact-transfer, has snapshot resolution disable
>>
>>
>> For my case, I am using maven setting's mirror to route all pom's
>> repositories to my internal maven repository.
>>
>> This also means I have only one remoteRepository with this content from my
>> debugger
>>
>>   id: xxx
>>   url: http://my.internal.repo/public
>>layout: default
>> snapshots: [enabled => false, update => daily]
>>  releases: [enabled => true, update => daily]
>>
>> What could have caused this?
>>
>> I  am seeing this issue on all maven 3.1+
>>
>> Thanks
>>
>> -Dan
>>
>
>

Re: maven-artifact-transfer not able to resolve SNAPSHOT artifact

[Dan Tran]

Eric,

looks like we are on the boat.  I will file a Jira ticket

Thanks

-Dan

On Wed, Apr 5, 2017 at 3:40 PM, Eric B <ebenza...@gmail.com> wrote:

> Dan,
>
> It's this the same type of problem that I am encountering here:
> http://stackoverflow.com/q/43220923/827480 ?
>
> For me I'm not sure of the genesis of the problem, but I suspect it is
> something to do with maven not having a default snapshot repo to retrieve
> artifacts.  But I don't know if you are seeing the same behaviour or if my
> issue is at all related to your question.
>
> Thanks
>
> Eric
>
>
> On Apr 3, 2017 1:55 AM, "Dan Tran" <dant...@gmail.com> wrote:
>
> Hi,
>
> I am very sure maven-artifact-transfer is not the issue.
>
> The real issue is MavenSession.ProjectBuildingRequest.RemoteRepositories,
> needed by maven-artifact-transfer, has snapshot resolution disable
>
>
> For my case, I am using maven setting's mirror to route all pom's
> repositories to my internal maven repository.
>
> This also means I have only one remoteRepository with this content from my
> debugger
>
>   id: xxx
>   url: http://my.internal.repo/public
>layout: default
> snapshots: [enabled => false, update => daily]
>  releases: [enabled => true, update => daily]
>
> What could have caused this?
>
> I  am seeing this issue on all maven 3.1+
>
> Thanks
>
> -Dan
>

Re: maven-artifact-transfer not able to resolve SNAPSHOT artifact

[Dan Tran]

yes  snapshots: [enabled => false, update => daily]   is the problem.

I ended up to hack by enable it before pass over to maven-artifact-transfer

The question here why it  is disabled at the first place

Thanks

-Dan

On Sun, Apr 2, 2017 at 11:38 PM, Karl Heinz Marbaise <khmarba...@gmx.de>
wrote:

> Hi Dan,
>
> On 03/04/17 07:54, Dan Tran wrote:
>
>> Hi,
>>
>> I am very sure maven-artifact-transfer is not the issue.
>>
>> The real issue is MavenSession.ProjectBuildingRequest.RemoteRepositories,
>> needed by maven-artifact-transfer, has snapshot resolution disable
>>
>>
>> For my case, I am using maven setting's mirror to route all pom's
>> repositories to my internal maven repository.
>>
>> This also means I have only one remoteRepository with this content from my
>> debugger
>>
>>   id: xxx
>>   url: http://my.internal.repo/public
>>layout: default
>> snapshots: [enabled => false, update => daily]
>>
>
> I'm not sure but maybe this is the problem ?
>
> not enabled to allow having snapshots ?
>
> Kind regards
> Karl Heinz
>
>
>  releases: [enabled => true, update => daily]
>>
>> What could have caused this?
>>
>> I  am seeing this issue on all maven 3.1+
>>
>> Thanks
>>
>> -Dan
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

maven-artifact-transfer not able to resolve SNAPSHOT artifact

[Dan Tran]

Hi,

I am very sure maven-artifact-transfer is not the issue.

The real issue is MavenSession.ProjectBuildingRequest.RemoteRepositories,
needed by maven-artifact-transfer, has snapshot resolution disable


For my case, I am using maven setting's mirror to route all pom's
repositories to my internal maven repository.

This also means I have only one remoteRepository with this content from my
debugger

  id: xxx
  url: http://my.internal.repo/public
   layout: default
snapshots: [enabled => false, update => daily]
 releases: [enabled => true, update => daily]

What could have caused this?

I  am seeing this issue on all maven 3.1+

Thanks

-Dan

Re: Is there a guide on how to use Sisu within Maven plugins?

[Dan Tran]

JSR330 is supported [1]

JSR250 not yet [2]

-D

http://maven.apache.org/maven-jsr330.html

https://issues.apache.org/jira/browse/MNG-6084  cast your note

On Wed, Feb 1, 2017 at 10:21 AM, Laird Nelson  wrote:

> I apologize in advance for the inarticulate nature of this question.
>
> I have this faint sense that Sisu and Guice are at the core of Maven these
> days, with a Plexus layer on top.
>
> This makes me think that perhaps I should be using different annotations in
> my maven plugins than @Component etc.
>
> Is this (
> https://maven.apache.org/guides/plugin/guide-java-plugin-development.html)
> still the official guide for writing Maven plugins?  If I wanted to inject
> some named Plexus component, is there some guide showing how to do that?
>
> Thanks,
> Best,
> Laird
>

Re: Excluding -beta-N from a range

[Dan Tran]

Thanks karl, the version range semantic is much clear now for me.

-D

On Sun, Jan 15, 2017 at 3:03 AM, Karl Heinz Marbaise 
wrote:

> Hi,
>
> On 15/01/17 12:01, Karl Heinz Marbaise wrote:
>
>> Hi,
>>
>> On 13/01/17 16:37, Benson Margulies wrote:
>>
>>> On Thu, Jan 12, 2017 at 11:42 PM, Florian Schätz 
>>> wrote:
>>>
 Am Donnerstag, den 12.01.2017, 14:22 -0800 schrieb Benson Margulies:

 I agree with them that this is counter-intuitive. The whole point of
> -beta-1 is to introduce new, incompatible, stuff. The whole point of
> that range is to exclude it.
>

>> If you introduce incompatible stuff you should call it 3.X cause based
>> on SemVer[1] this would be the way to go...
>>
>>
>> [1]: http://semver.org/
>>
>
> Missed a LinK.
>
> [2]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
>
>
> Kind regards
> Karl Heinz Marbaise
>
>>
>>
 Doesn't 2.0.0-beta1 imply that it's a beta for the 2.0.0 release, so
 that the final 2.0.0 release will include everything that's in this
 beta, thus the range quite correctly contains it...?

>>>
>>>
>>> The range [1,2) excludes 2.0.0.
>>> So, by your logic, which is my logic,
>>> it should also exclude the beta.
>>>
>>
>> The range [1,2) excludes 2.0.0 cause 2 is equal to 2.0 and equal to
>> 2.0.0 BUT 2.0.0-beta is less than 2.0 which means it is included the
>> range ...cause based on the timeline 2.0-beta is before 2.0
>>
>> So in the end it does not exclude the beta...
>>
>>
 If the stuff from the 2.0.0-beta1 will not be part of the final 2.0.0
 release, wouldn't it be better called 2.0.1-beta1?

 Just curious because we had some discussions about versioning strategies
 here, too, a while ago.

>>>
>> Yes I agree...
>>
>> If you having changes which will not being part of 2.0.0 you should call
>> that 2.1.0-beta BUT NOT 2.0.0-beta1 be aware of the timeline
>>
>> 1.0 ... 2.0.0-beta1  2.0.0 ... 2.0.1 ... 2.1.0 ..
>>
>> If you like having something which should be introduces after releasing
>> 2.0.0 you have to call it 2.0.1-WhatEver or 2.1.0-WhatEver...
>>
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>>
 Regards,

 Flo

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

Re: Excluding -beta-N from a range

[Dan Tran]

+1 to fix it at maven-core

-D

On Fri, Jan 13, 2017 at 7:37 AM, Benson Margulies 
wrote:

> On Thu, Jan 12, 2017 at 11:42 PM, Florian Schätz 
> wrote:
> > Am Donnerstag, den 12.01.2017, 14:22 -0800 schrieb Benson Margulies:
> >
> >> I agree with them that this is counter-intuitive. The whole point of
> >> -beta-1 is to introduce new, incompatible, stuff. The whole point of
> >> that range is to exclude it.
> >
> > Doesn't 2.0.0-beta1 imply that it's a beta for the 2.0.0 release, so
> > that the final 2.0.0 release will include everything that's in this
> > beta, thus the range quite correctly contains it...?
>
>
> The range [1,2) excludes 2.0.0. So, by your logic, which is my logic,
> it should also exclude the beta.
> >
> > If the stuff from the 2.0.0-beta1 will not be part of the final 2.0.0
> > release, wouldn't it be better called 2.0.1-beta1?
> >
> > Just curious because we had some discussions about versioning strategies
> > here, too, a while ago.
> >
> > Regards,
> >
> > Flo
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: API to resolve a version range artifact

[Dan Tran]

I am able to construct Dependency from my Artifact's GAV,
maven-artifact-transfer's DependencyResolver handles the rest.

Thanks to Robert's excellent works under maven-artifact-transfer

-Dan

On Wed, Dec 28, 2016 at 2:17 AM, Robert Scholte <rfscho...@apache.org>
wrote:

> Well, you can go from dependency to artifact to file, but not the other
> way around. If you want to go from artifact to dependency, then the
> artifact should have been a dependency from the beginning. I've tried to
> make the difference more clear on the comparison page[1].
> While integrating maven-artifact-transfer in several plugins I noticed
> that quite a lot were using artifacts where actually dependencies should
> have been used. I've managed to refactor all these cases by using
> dependencies instead.
>
> Be aware that the o.a.m.a.Artifact[2] is a confusing interface, it has way
> too much methods which actually belong to the dependency.
>
> Robert
>
> [1] http://maven.apache.org/shared/maven-artifact-transfer/comparison.html
> [2] http://maven.apache.org/ref/3.3.9/maven-artifact/apidocs/org
> /apache/maven/artifact/Artifact.html
>
> On Wed, 28 Dec 2016 10:01:17 +0100, Dan Tran <dant...@gmail.com> wrote:
>
> is there a component to convert and Artifact to Dependency?
>>
>> Thanks
>>
>> -D
>>
>> On Tue, Dec 27, 2016 at 3:31 PM, Dan Tran <dant...@gmail.com> wrote:
>>
>> Bingo, it works. I will close to Jira
>>>
>>> Thanks Robert
>>>
>>> -Dan
>>>
>>> On Tue, Dec 27, 2016 at 1:01 PM, Robert Scholte <rfscho...@apache.org>
>>> wrote:
>>>
>>> Just to be sure:
>>>>
>>>> buildingRequest = repositoryManager.setLocalRepositoryBasedir(
>>>> buildingRequest, localRepositoryPath );
>>>>
>>>> do you pick up the new buildingRequest? This is required due to
>>>> immutable
>>>> instances inside buildingRequest.
>>>> IIRC I've already applied this to the maven-invoker-plugin, which also
>>>> needs its own localRepository.
>>>>
>>>> Robert
>>>>
>>>>
>>>> On Tue, 27 Dec 2016 05:30:43 +0100, Dan Tran <dant...@gmail.com> wrote:
>>>>
>>>> Thanks, Robert,
>>>>
>>>>>
>>>>> I am going to switch to  DependencyResolver for my use case
>>>>>
>>>>> I also filed https://issues.apache.org/jira/browse/MSHARED-604. Let me
>>>>> know
>>>>> if it is valid, so I can work on the fix
>>>>>
>>>>> Thanks
>>>>>
>>>>> -Dan
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Dec 26, 2016 at 2:53 AM, Robert Scholte <rfscho...@apache.org>
>>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>>
>>>>>> we must be clear about the naming: an artifact can never have a
>>>>>> version
>>>>>> range; it is a maven coordinate which results in one file.
>>>>>> However, a dependency can have a version range, that's the proper way
>>>>>> to
>>>>>> get the range resolved and get the matching artifact.
>>>>>>
>>>>>> Robert
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, 26 Dec 2016 08:33:59 +0100, Dan Tran <dant...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> to elaborate my use case: where i started with maven GAV as string,
>>>>>>
>>>>>>  convert to maven artifact, and finally resolve with option to change
>>>>>>> local
>>>>>>> repo path
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> -Dan
>>>>>>>
>>>>>>> On Sun, Dec 25, 2016 at 11:31 PM, Dan Tran <dant...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Thanks, I am able to obtain ProjectBuildingRequest  either with
>>>>>>>
>>>>>>> MavenSession or MavenProject, however, there are 2 issues
>>>>>>>>
>>>>>>>>   1. version range does not work, stepping the debugger show no sign
>>>>>>>> of
>>>>>>>> processing resolveVersionRanges flag. and aether throws exception
>>>>>>>>
>&g

Re: API to resolve a version range artifact

[Dan Tran]

is there a component to convert and Artifact to Dependency?

Thanks

-D

On Tue, Dec 27, 2016 at 3:31 PM, Dan Tran <dant...@gmail.com> wrote:

> Bingo, it works. I will close to Jira
>
> Thanks Robert
>
> -Dan
>
> On Tue, Dec 27, 2016 at 1:01 PM, Robert Scholte <rfscho...@apache.org>
> wrote:
>
>> Just to be sure:
>>
>> buildingRequest = repositoryManager.setLocalRepositoryBasedir(
>> buildingRequest, localRepositoryPath );
>>
>> do you pick up the new buildingRequest? This is required due to immutable
>> instances inside buildingRequest.
>> IIRC I've already applied this to the maven-invoker-plugin, which also
>> needs its own localRepository.
>>
>> Robert
>>
>>
>> On Tue, 27 Dec 2016 05:30:43 +0100, Dan Tran <dant...@gmail.com> wrote:
>>
>> Thanks, Robert,
>>>
>>> I am going to switch to  DependencyResolver for my use case
>>>
>>> I also filed https://issues.apache.org/jira/browse/MSHARED-604. Let me
>>> know
>>> if it is valid, so I can work on the fix
>>>
>>> Thanks
>>>
>>> -Dan
>>>
>>>
>>>
>>> On Mon, Dec 26, 2016 at 2:53 AM, Robert Scholte <rfscho...@apache.org>
>>> wrote:
>>>
>>> Hi,
>>>>
>>>> we must be clear about the naming: an artifact can never have a version
>>>> range; it is a maven coordinate which results in one file.
>>>> However, a dependency can have a version range, that's the proper way to
>>>> get the range resolved and get the matching artifact.
>>>>
>>>> Robert
>>>>
>>>>
>>>>
>>>> On Mon, 26 Dec 2016 08:33:59 +0100, Dan Tran <dant...@gmail.com> wrote:
>>>>
>>>> to elaborate my use case: where i started with maven GAV as string,
>>>>
>>>>>  convert to maven artifact, and finally resolve with option to change
>>>>> local
>>>>> repo path
>>>>>
>>>>> Thanks
>>>>>
>>>>> -Dan
>>>>>
>>>>> On Sun, Dec 25, 2016 at 11:31 PM, Dan Tran <dant...@gmail.com> wrote:
>>>>>
>>>>> Thanks, I am able to obtain ProjectBuildingRequest  either with
>>>>>
>>>>>> MavenSession or MavenProject, however, there are 2 issues
>>>>>>
>>>>>>   1. version range does not work, stepping the debugger show no sign
>>>>>> of
>>>>>> processing resolveVersionRanges flag. and aether throws exception
>>>>>>
>>>>>>   2. Looks like ProjectBuildingRequest is immutable, i cant override
>>>>>> localRepository as resolve time. I can do so with ArtifactResolver
>>>>>> from
>>>>>> maven-compat
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> -Dan
>>>>>>
>>>>>> On Sun, Dec 25, 2016 at 10:50 PM, Guillaume Boué <gb...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>> If you're inside a Maven plugin, you can get a ProjectBuildingRequest
>>>>>>
>>>>>>> with the session.
>>>>>>>
>>>>>>> https://maven.apache.org/ref/3.3.9/maven-core/apidocs/org/ap
>>>>>>> ache/maven/execution/MavenSession.html#getProjectBuildingRequest()
>>>>>>>
>>>>>>> The shared ArtifactResolver from maven-artifact-transfer should
>>>>>>> resolve
>>>>>>> version ranges, yes.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le 26/12/2016 à 03:59, Dan Tran a écrit :
>>>>>>>
>>>>>>> I found  org.apache.maven.shared.artifact.resolve.ArtifactResolver
>>>>>>>
>>>>>>>>  with
>>>>>>>> input of ProjectBuildingRequest
>>>>>>>>
>>>>>>>> here is how I construct the request
>>>>>>>>
>>>>>>>>  ProjectBuildingRequest req = new
>>>>>>>> DefaultProjectBuildingRequest();
>>>>>>>>  req.setLocalRepository(localRepository);
>>>>>>>>  req.setRemoteRepositories(remoteRepositories);
>>>>>

Re: API to resolve a version range artifact

[Dan Tran]

Bingo, it works. I will close to Jira

Thanks Robert

-Dan

On Tue, Dec 27, 2016 at 1:01 PM, Robert Scholte <rfscho...@apache.org>
wrote:

> Just to be sure:
>
> buildingRequest = repositoryManager.setLocalRepositoryBasedir(
> buildingRequest, localRepositoryPath );
>
> do you pick up the new buildingRequest? This is required due to immutable
> instances inside buildingRequest.
> IIRC I've already applied this to the maven-invoker-plugin, which also
> needs its own localRepository.
>
> Robert
>
>
> On Tue, 27 Dec 2016 05:30:43 +0100, Dan Tran <dant...@gmail.com> wrote:
>
> Thanks, Robert,
>>
>> I am going to switch to  DependencyResolver for my use case
>>
>> I also filed https://issues.apache.org/jira/browse/MSHARED-604. Let me
>> know
>> if it is valid, so I can work on the fix
>>
>> Thanks
>>
>> -Dan
>>
>>
>>
>> On Mon, Dec 26, 2016 at 2:53 AM, Robert Scholte <rfscho...@apache.org>
>> wrote:
>>
>> Hi,
>>>
>>> we must be clear about the naming: an artifact can never have a version
>>> range; it is a maven coordinate which results in one file.
>>> However, a dependency can have a version range, that's the proper way to
>>> get the range resolved and get the matching artifact.
>>>
>>> Robert
>>>
>>>
>>>
>>> On Mon, 26 Dec 2016 08:33:59 +0100, Dan Tran <dant...@gmail.com> wrote:
>>>
>>> to elaborate my use case: where i started with maven GAV as string,
>>>
>>>>  convert to maven artifact, and finally resolve with option to change
>>>> local
>>>> repo path
>>>>
>>>> Thanks
>>>>
>>>> -Dan
>>>>
>>>> On Sun, Dec 25, 2016 at 11:31 PM, Dan Tran <dant...@gmail.com> wrote:
>>>>
>>>> Thanks, I am able to obtain ProjectBuildingRequest  either with
>>>>
>>>>> MavenSession or MavenProject, however, there are 2 issues
>>>>>
>>>>>   1. version range does not work, stepping the debugger show no sign of
>>>>> processing resolveVersionRanges flag. and aether throws exception
>>>>>
>>>>>   2. Looks like ProjectBuildingRequest is immutable, i cant override
>>>>> localRepository as resolve time. I can do so with ArtifactResolver from
>>>>> maven-compat
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>> -Dan
>>>>>
>>>>> On Sun, Dec 25, 2016 at 10:50 PM, Guillaume Boué <gb...@apache.org>
>>>>> wrote:
>>>>>
>>>>> If you're inside a Maven plugin, you can get a ProjectBuildingRequest
>>>>>
>>>>>> with the session.
>>>>>>
>>>>>> https://maven.apache.org/ref/3.3.9/maven-core/apidocs/org/ap
>>>>>> ache/maven/execution/MavenSession.html#getProjectBuildingRequest()
>>>>>>
>>>>>> The shared ArtifactResolver from maven-artifact-transfer should
>>>>>> resolve
>>>>>> version ranges, yes.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le 26/12/2016 à 03:59, Dan Tran a écrit :
>>>>>>
>>>>>> I found  org.apache.maven.shared.artifact.resolve.ArtifactResolver
>>>>>>
>>>>>>>  with
>>>>>>> input of ProjectBuildingRequest
>>>>>>>
>>>>>>> here is how I construct the request
>>>>>>>
>>>>>>>  ProjectBuildingRequest req = new
>>>>>>> DefaultProjectBuildingRequest();
>>>>>>>  req.setLocalRepository(localRepository);
>>>>>>>  req.setRemoteRepositories(remoteRepositories);
>>>>>>>  req.setResolveVersionRanges(true);
>>>>>>>  req.setRepositorySession(???);//fixme
>>>>>>>
>>>>>>> I have access to both local and remote repos instances,
>>>>>>>
>>>>>>> How do I obtain a repositorySession?
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> -Dan
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Dec 25, 2016 at 10:45 AM, Dan Tran <dant...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>>
>>>>>>>> Does maven-artifact-transfer have this feature? if so which api?
>>>>>>>>
>>>>>>>> basically, I have an org.apache.maven.artifact.Artifact with
>>>>>>>> version
>>>>>>>> range set.  I need to resolve it to pickup the matching version
>>>>>>>> available
>>>>>>>> at maven repo
>>>>>>>>
>>>>>>>> the org.apache.maven.artifact.resolver.ArtifactResolver from
>>>>>>>> maven-compat cant resolve it
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> -Dan
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---
>>>>>> L'absence de virus dans ce courrier électronique a été vérifiée par le
>>>>>> logiciel antivirus Avast.
>>>>>> https://www.avast.com/antivirus
>>>>>>
>>>>>>
>>>>>> -
>>>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: API to resolve a version range artifact

[Dan Tran]

Thanks, Robert,

I am going to switch to  DependencyResolver for my use case

I also filed https://issues.apache.org/jira/browse/MSHARED-604. Let me know
if it is valid, so I can work on the fix

Thanks

-Dan



On Mon, Dec 26, 2016 at 2:53 AM, Robert Scholte <rfscho...@apache.org>
wrote:

> Hi,
>
> we must be clear about the naming: an artifact can never have a version
> range; it is a maven coordinate which results in one file.
> However, a dependency can have a version range, that's the proper way to
> get the range resolved and get the matching artifact.
>
> Robert
>
>
>
> On Mon, 26 Dec 2016 08:33:59 +0100, Dan Tran <dant...@gmail.com> wrote:
>
> to elaborate my use case: where i started with maven GAV as string,
>>  convert to maven artifact, and finally resolve with option to change
>> local
>> repo path
>>
>> Thanks
>>
>> -Dan
>>
>> On Sun, Dec 25, 2016 at 11:31 PM, Dan Tran <dant...@gmail.com> wrote:
>>
>> Thanks, I am able to obtain ProjectBuildingRequest  either with
>>> MavenSession or MavenProject, however, there are 2 issues
>>>
>>>   1. version range does not work, stepping the debugger show no sign of
>>> processing resolveVersionRanges flag. and aether throws exception
>>>
>>>   2. Looks like ProjectBuildingRequest is immutable, i cant override
>>> localRepository as resolve time. I can do so with ArtifactResolver from
>>> maven-compat
>>>
>>>
>>> Thanks
>>>
>>> -Dan
>>>
>>> On Sun, Dec 25, 2016 at 10:50 PM, Guillaume Boué <gb...@apache.org>
>>> wrote:
>>>
>>> If you're inside a Maven plugin, you can get a ProjectBuildingRequest
>>>> with the session.
>>>>
>>>> https://maven.apache.org/ref/3.3.9/maven-core/apidocs/org/ap
>>>> ache/maven/execution/MavenSession.html#getProjectBuildingRequest()
>>>>
>>>> The shared ArtifactResolver from maven-artifact-transfer should resolve
>>>> version ranges, yes.
>>>>
>>>>
>>>>
>>>> Le 26/12/2016 à 03:59, Dan Tran a écrit :
>>>>
>>>> I found  org.apache.maven.shared.artifact.resolve.ArtifactResolver
>>>>>  with
>>>>> input of ProjectBuildingRequest
>>>>>
>>>>> here is how I construct the request
>>>>>
>>>>>  ProjectBuildingRequest req = new
>>>>> DefaultProjectBuildingRequest();
>>>>>  req.setLocalRepository(localRepository);
>>>>>  req.setRemoteRepositories(remoteRepositories);
>>>>>  req.setResolveVersionRanges(true);
>>>>>  req.setRepositorySession(???);//fixme
>>>>>
>>>>> I have access to both local and remote repos instances,
>>>>>
>>>>> How do I obtain a repositorySession?
>>>>>
>>>>> Thanks
>>>>>
>>>>> -Dan
>>>>>
>>>>>
>>>>> On Sun, Dec 25, 2016 at 10:45 AM, Dan Tran <dant...@gmail.com> wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>>>
>>>>>> Does maven-artifact-transfer have this feature? if so which api?
>>>>>>
>>>>>> basically, I have an org.apache.maven.artifact.Artifact with version
>>>>>> range set.  I need to resolve it to pickup the matching version
>>>>>> available
>>>>>> at maven repo
>>>>>>
>>>>>> the org.apache.maven.artifact.resolver.ArtifactResolver from
>>>>>> maven-compat cant resolve it
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> -Dan
>>>>>>
>>>>>>
>>>>>>
>>>> ---
>>>> L'absence de virus dans ce courrier électronique a été vérifiée par le
>>>> logiciel antivirus Avast.
>>>> https://www.avast.com/antivirus
>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>>
>>>>
>>>>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: API to resolve a version range artifact

[Dan Tran]

to elaborate my use case: where i started with maven GAV as string,
 convert to maven artifact, and finally resolve with option to change local
repo path

Thanks

-Dan

On Sun, Dec 25, 2016 at 11:31 PM, Dan Tran <dant...@gmail.com> wrote:

> Thanks, I am able to obtain ProjectBuildingRequest  either with
> MavenSession or MavenProject, however, there are 2 issues
>
>   1. version range does not work, stepping the debugger show no sign of
> processing resolveVersionRanges flag. and aether throws exception
>
>   2. Looks like ProjectBuildingRequest is immutable, i cant override
> localRepository as resolve time. I can do so with ArtifactResolver from
> maven-compat
>
>
> Thanks
>
> -Dan
>
> On Sun, Dec 25, 2016 at 10:50 PM, Guillaume Boué <gb...@apache.org> wrote:
>
>> If you're inside a Maven plugin, you can get a ProjectBuildingRequest
>> with the session.
>>
>> https://maven.apache.org/ref/3.3.9/maven-core/apidocs/org/ap
>> ache/maven/execution/MavenSession.html#getProjectBuildingRequest()
>>
>> The shared ArtifactResolver from maven-artifact-transfer should resolve
>> version ranges, yes.
>>
>>
>>
>> Le 26/12/2016 à 03:59, Dan Tran a écrit :
>>
>>> I found  org.apache.maven.shared.artifact.resolve.ArtifactResolver
>>>  with
>>> input of ProjectBuildingRequest
>>>
>>> here is how I construct the request
>>>
>>>  ProjectBuildingRequest req = new
>>> DefaultProjectBuildingRequest();
>>>  req.setLocalRepository(localRepository);
>>>  req.setRemoteRepositories(remoteRepositories);
>>>  req.setResolveVersionRanges(true);
>>>  req.setRepositorySession(???);//fixme
>>>
>>> I have access to both local and remote repos instances,
>>>
>>> How do I obtain a repositorySession?
>>>
>>> Thanks
>>>
>>> -Dan
>>>
>>>
>>> On Sun, Dec 25, 2016 at 10:45 AM, Dan Tran <dant...@gmail.com> wrote:
>>>
>>> Hi
>>>>
>>>> Does maven-artifact-transfer have this feature? if so which api?
>>>>
>>>> basically, I have an org.apache.maven.artifact.Artifact with version
>>>> range set.  I need to resolve it to pickup the matching version
>>>> available
>>>> at maven repo
>>>>
>>>> the org.apache.maven.artifact.resolver.ArtifactResolver from
>>>> maven-compat cant resolve it
>>>>
>>>>
>>>> Thanks
>>>>
>>>> -Dan
>>>>
>>>>
>>
>> ---
>> L'absence de virus dans ce courrier électronique a été vérifiée par le
>> logiciel antivirus Avast.
>> https://www.avast.com/antivirus
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>

Re: API to resolve a version range artifact

[Dan Tran]

Thanks, I am able to obtain ProjectBuildingRequest  either with
MavenSession or MavenProject, however, there are 2 issues

  1. version range does not work, stepping the debugger show no sign of
processing resolveVersionRanges flag. and aether throws exception

  2. Looks like ProjectBuildingRequest is immutable, i cant override
localRepository as resolve time. I can do so with ArtifactResolver from
maven-compat


Thanks

-Dan

On Sun, Dec 25, 2016 at 10:50 PM, Guillaume Boué <gb...@apache.org> wrote:

> If you're inside a Maven plugin, you can get a ProjectBuildingRequest with
> the session.
>
> https://maven.apache.org/ref/3.3.9/maven-core/apidocs/org/ap
> ache/maven/execution/MavenSession.html#getProjectBuildingRequest()
>
> The shared ArtifactResolver from maven-artifact-transfer should resolve
> version ranges, yes.
>
>
>
> Le 26/12/2016 à 03:59, Dan Tran a écrit :
>
>> I found  org.apache.maven.shared.artifact.resolve.ArtifactResolver   with
>> input of ProjectBuildingRequest
>>
>> here is how I construct the request
>>
>>  ProjectBuildingRequest req = new
>> DefaultProjectBuildingRequest();
>>  req.setLocalRepository(localRepository);
>>  req.setRemoteRepositories(remoteRepositories);
>>  req.setResolveVersionRanges(true);
>>  req.setRepositorySession(???);//fixme
>>
>> I have access to both local and remote repos instances,
>>
>> How do I obtain a repositorySession?
>>
>> Thanks
>>
>> -Dan
>>
>>
>> On Sun, Dec 25, 2016 at 10:45 AM, Dan Tran <dant...@gmail.com> wrote:
>>
>> Hi
>>>
>>> Does maven-artifact-transfer have this feature? if so which api?
>>>
>>> basically, I have an org.apache.maven.artifact.Artifact with version
>>> range set.  I need to resolve it to pickup the matching version available
>>> at maven repo
>>>
>>> the org.apache.maven.artifact.resolver.ArtifactResolver from
>>> maven-compat cant resolve it
>>>
>>>
>>> Thanks
>>>
>>> -Dan
>>>
>>>
>
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le
> logiciel antivirus Avast.
> https://www.avast.com/antivirus
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: API to resolve a version range artifact

[Dan Tran]

I found  org.apache.maven.shared.artifact.resolve.ArtifactResolver   with
input of ProjectBuildingRequest

here is how I construct the request

ProjectBuildingRequest req = new
DefaultProjectBuildingRequest();
req.setLocalRepository(localRepository);
req.setRemoteRepositories(remoteRepositories);
req.setResolveVersionRanges(true);
req.setRepositorySession(???);//fixme

I have access to both local and remote repos instances,

How do I obtain a repositorySession?

Thanks

-Dan


On Sun, Dec 25, 2016 at 10:45 AM, Dan Tran <dant...@gmail.com> wrote:

>
> Hi
>
> Does maven-artifact-transfer have this feature? if so which api?
>
> basically, I have an org.apache.maven.artifact.Artifact with version
> range set.  I need to resolve it to pickup the matching version available
> at maven repo
>
> the org.apache.maven.artifact.resolver.ArtifactResolver from
> maven-compat cant resolve it
>
>
> Thanks
>
> -Dan
>

API to resolve a version range artifact

[Dan Tran]

Hi

Does maven-artifact-transfer have this feature? if so which api?

basically, I have an org.apache.maven.artifact.Artifact with version range
set.  I need to resolve it to pickup the matching version available at
maven repo

the org.apache.maven.artifact.resolver.ArtifactResolver from
maven-compat cant resolve it


Thanks

-Dan

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

[Dan Tran]

Correct we dont ever enter relativePath. The implicit one should work and
should never see warning that a module can't find its parent

On Wed, Nov 30, 2016 at 4:54 PM, KARR, DAVID <dk0...@att.com> wrote:

> > -Original Message-
> > From: Dan Tran [mailto:dant...@gmail.com]
> > Sent: Wednesday, November 30, 2016 3:17 PM
> > To: Maven Users List <users@maven.apache.org>
> > Subject: Re: Need to fully understand bad implications of combined
> > aggregator and parent pom
> >
> > I concur with Ben,  aggregator module is banned at my work. Top level
> > parent hosts all modules
>
> So does this mean that you utilize "relativePath" in the child module's
> parent definitions?  Otherwise, the child modules are being built before
> the POM for the top-level POM is installed (which happens at the end of the
> build).
>
> > On Wed, Nov 30, 2016 at 1:47 PM, KARR, DAVID <dk0...@att.com> wrote:
> >
> > > > -Original Message-
> > > > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> > > > Sent: Wednesday, November 30, 2016 1:01 PM
> > > > To: Maven Users List <users@maven.apache.org>
> > > > Subject: Re: Need to fully understand bad implications of combined
> > > > aggregator and parent pom
> > > >
> > > > You do have relativePath set correctly for the separate parent from
> > > > aggregator?
> > >
> > > Not sure whether you're addressing Benson or me, but setting
> > > relativePath is definitely a requirement, and I think the error
> > > message you get is pretty clear when you don’t have it, so I imagine
> > that's not Benson's issue.
> > >
> > > In my case, I did some cut/pasting and some global replaces to
> > > separate the POM into parent and aggregator, and now my build works
> > > from the top with empty repositories.
> > >
> > > I don't use the site plugin.
> > >
> > > > On Wed 30 Nov 2016 at 03:28, Benson Margulies
> > > > <bimargul...@gmail.com>
> > > > wrote:
> > > >
> > > > > My experience is precisely the opposite of yours. The most common
> > > > > practice is for the parent to be the aggregator; it's hard to get
> > > > > the site plugin, for example, to work right with your preferred
> > > > > structure where they are different.
> > > > >
> > > > > I have built many projects with the the one-parent structure, and
> > > > > they typically have interdependencies between the modules, and
> > > > > they work fine.  Can you boil this down to a failing case on
> > > > > github? Can you share some poms?
> > > > >
> > > > >
> > > > > On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID <dk0...@att.com>
> > wrote:
> > > > > > A while ago, I started working on an existing project with many
> > > > > developers.  The codebase has a large multi-project Maven build.
> > > > > The top directory is both an "aggregator" and "parent" POM, as it
> > > > > has a
> > > > "modules"
> > > > > list, and all of the child modules have it as their parent POM,
> > > > > for dependencies and plugins.
> > > > > >
> > > > > > I've always believed this is a defective architecture.  I
> > > > > > believe that
> > > > > the top-level directory should have an "aggregator" POM that just
> > > > > lists the modules to build, and a subdirectory of the top-level
> > > > > directory should have a project that just defines the parent POM,
> > > > > which defines dependencies and plugins for subprojects to use.
> > > > > >
> > > > > > Although I feel this is a "cleaner" architecture, I've never
> > > > > > been able
> > > > > to cite specific problems with the other approach, besides the
> > > > > fact that module changes and dependency/plugin changes go in the
> > > > > same file, which is still a "cleanliness" argument.
> > > > > >
> > > > > > Today I think I saw a real reason why the present architecture
> > > > > > is a
> > > > > problem, but I need to be certain the problem I'm seeing is caused
&

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

[Dan Tran]

I concur with Ben,  aggregator module is banned at my work. Top level
parent hosts all modules

On Wed, Nov 30, 2016 at 1:47 PM, KARR, DAVID  wrote:

> > -Original Message-
> > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> > Sent: Wednesday, November 30, 2016 1:01 PM
> > To: Maven Users List 
> > Subject: Re: Need to fully understand bad implications of combined
> > aggregator and parent pom
> >
> > You do have relativePath set correctly for the separate parent from
> > aggregator?
>
> Not sure whether you're addressing Benson or me, but setting relativePath
> is definitely a requirement, and I think the error message you get is
> pretty clear when you don’t have it, so I imagine that's not Benson's issue.
>
> In my case, I did some cut/pasting and some global replaces to separate
> the POM into parent and aggregator, and now my build works from the top
> with empty repositories.
>
> I don't use the site plugin.
>
> > On Wed 30 Nov 2016 at 03:28, Benson Margulies 
> > wrote:
> >
> > > My experience is precisely the opposite of yours. The most common
> > > practice is for the parent to be the aggregator; it's hard to get the
> > > site plugin, for example, to work right with your preferred structure
> > > where they are different.
> > >
> > > I have built many projects with the the one-parent structure, and they
> > > typically have interdependencies between the modules, and they work
> > > fine.  Can you boil this down to a failing case on github? Can you
> > > share some poms?
> > >
> > >
> > > On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID  wrote:
> > > > A while ago, I started working on an existing project with many
> > > developers.  The codebase has a large multi-project Maven build.  The
> > > top directory is both an "aggregator" and "parent" POM, as it has a
> > "modules"
> > > list, and all of the child modules have it as their parent POM, for
> > > dependencies and plugins.
> > > >
> > > > I've always believed this is a defective architecture.  I believe
> > > > that
> > > the top-level directory should have an "aggregator" POM that just
> > > lists the modules to build, and a subdirectory of the top-level
> > > directory should have a project that just defines the parent POM,
> > > which defines dependencies and plugins for subprojects to use.
> > > >
> > > > Although I feel this is a "cleaner" architecture, I've never been
> > > > able
> > > to cite specific problems with the other approach, besides the fact
> > > that module changes and dependency/plugin changes go in the same file,
> > > which is still a "cleanliness" argument.
> > > >
> > > > Today I think I saw a real reason why the present architecture is a
> > > problem, but I need to be certain the problem I'm seeing is caused by
> > > this, and that the better architecture fixes this problem, and whether
> > > there is a simple workaround in the meantime.
> > > >
> > > > I've been modifying the build to use a completely new intranet maven
> > > repo and completely different groupids for the build artifacts.
> > > >
> > > > I saw errors like this (with elisions):
> > > > ---
> > > > [INFO] Reactor Summary:
> > > > [INFO]
> > > > [INFO] big-parent . FAILURE
> > > > [
> > > 5.230 s]
> > > > [INFO] some-other-module... SKIPPED
> > > > [INFO] another-module.. SKIPPED
> > > > [INFO] .SKIPPED
> > > > [INFO]
> > > --
> > > --
> > > > [INFO] BUILD FAILURE
> > > > [INFO]
> > > --
> > > --
> > > > [INFO] Total time: 8.063 s
> > > > [INFO] Finished at: 2016-11-29T16:23:36-08:00 [INFO] Final Memory:
> > > > 41M/1093M [INFO]
> > > --
> > > --
> > > > [ERROR] Failed to execute goal on project some-other-module: Could
> > > > not
> > > resolve dependencies for project
> > > com.mycomp.detsusl:some-other-module:bundle:2.0.0-SNAPSHOT: Could not
> > > find artifact com.mycomp.detsusl:another-module:jar:2.0.0-SNAPSHOT in
> > > mycomp-public-group (
> > > http://mavencentral.it.mycomp.com:8084/nexus/content/repositories/myco
> > > mp-public-group/)
> > > -> [Help 1]
> > > > [ERROR]
> > > > ---
> > > >
> > > > The "big-parent" module is the top-level directory that is both the
> > > aggregator and parent pom.
> > > >
> > > > Conceptually, I think this is happening because Maven is trying to
> > > evaluate dependencies before those dependencies are built.  Again, I
> > > think the "separated" architecture will resolve this, but before I
> > > implement that, I need to understand exactly what is going on here.
> > > >
> > > > In my local workspace, I got around this 

Re: Maven Plugin and JSR330

[Dan Tran]

I filed a PR at https://github.com/apache/maven/pull/98.

On Thu, Nov 17, 2016 at 8:48 PM, Dan Tran <dant...@gmail.com> wrote:

> It works!!! Thanks Stuard
>
> So my change should be good for commit for 3.4?
>
> -Dan
>
> On Sun, Nov 13, 2016 at 3:01 PM, Stuart McCulloch <mccu...@gmail.com>
> wrote:
>
>> Hi Dan,
>>
>> There are two places in MavenCli which create a container.
>>
>> You’ve enabled JSR250 for the temporary container that resolves the core
>> extensions, but not the main container that runs the Mojos:
>>
>> https://github.com/dantran/maven/blob/master/maven-embedder/
>> src/main/java/org/apache/maven/cli/MavenCli.java#L585
>>
>> If I enable JSR250 in the above line then your test passes.
>>
>> --
>> Cheers, Stuart
>>
>>
>> On Sunday, 13 November 2016 at 22:10, Dan Tran wrote:
>>
>> > @Stuard
>> >
>> > Could you review my changes at
>> > https://github.com/dantran/maven/commits/master? I still not able to
>> get
>> > @PostContruct working yet
>> >
>> > Thanks
>> >
>> > -Dan
>> >
>> > On Sun, Sep 11, 2016 at 7:27 PM, Dan Tran <dant...@gmail.com (mailto:
>> dant...@gmail.com)> wrote:
>> >
>> > > Thanks Stuart, very much appreciated
>> > >
>> > > -D
>> > >
>> > > On Sun, Sep 11, 2016 at 7:22 PM, Stuart McCulloch <mccu...@gmail.com
>> (mailto:mccu...@gmail.com)>
>> > > wrote:
>> > >
>> > > > Sorry, last week was very busy with work and family
>> > > >
>> > > > I’ve listed the necessary config changes in
>> > > > https://issues.apache.org/jira/browse/MNG-6084
>> > > >
>> > > > --
>> > > > Cheers, Stuart
>> > > >
>> > > >
>> > > > On Sunday, 11 September 2016 at 04:28, Dan Tran wrote:
>> > > >
>> > > > > @Stuart, ping :-)
>> > > > >
>> > > > > On Tue, Sep 6, 2016 at 7:06 PM, Dan Tran <dant...@gmail.com
>> (mailto:dant...@gmail.com) (mailto:
>> > > > dant...@gmail.com (mailto:dant...@gmail.com))> wrote:
>> > > > >
>> > > > > > @Stuart, could you provide instructions on how to enable JSR 250
>> > > > support?
>> > > > > >
>> > > > > > Thanks
>> > > > > >
>> > > > > >
>> > > > > > -Dan
>> > > > > >
>> > > > > > On Fri, Sep 2, 2016 at 9:22 AM, Dan Tran <dant...@gmail.com
>> (mailto:dant...@gmail.com) (mailto:
>> > > > dant...@gmail.com (mailto:dant...@gmail.com))> wrote:
>> > > > > >
>> > > > > > > here you go https://issues.apache.org/jira/browse/MNG-6084
>> > > > > > >
>> > > > > > > Very much appreciated
>> > > > > > >
>> > > > > > > -Dan
>> > > > > > >
>> > > > > > > On Fri, Sep 2, 2016 at 8:42 AM, Stuart McCulloch <
>> mccu...@gmail.com (mailto:mccu...@gmail.com)
>> > > > (mailto:mccu...@gmail.com)>
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > > > On Wednesday, 31 August 2016 at 19:05, Dan Tran wrote:
>> > > > > > > > > Hi Stuart
>> > > > > > > > >
>> > > > > > > > > Thanks for helping out.
>> > > > > > > > >
>> > > > > > > > > I have 3 mojos, sharing one singleton component which
>> depends on
>> > > > > > > > another
>> > > > > > > > > singleton component thru injection. All working now via
>> both
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > > > injection
>> > > > > > > >
>> > > > > > > > type
>> > > > > > > > > ( after some cleanup)
>> > > > > > > > >
>> > > > > > > > > should I file a JIRA to enable JSR-250 support fo rmaven
>> 3.4?
>> > > > > > > > Sure -

Re: Maven Plugin and JSR330

[Dan Tran]

It works!!! Thanks Stuard

So my change should be good for commit for 3.4?

-Dan

On Sun, Nov 13, 2016 at 3:01 PM, Stuart McCulloch <mccu...@gmail.com> wrote:

> Hi Dan,
>
> There are two places in MavenCli which create a container.
>
> You’ve enabled JSR250 for the temporary container that resolves the core
> extensions, but not the main container that runs the Mojos:
>
> https://github.com/dantran/maven/blob/master/maven-
> embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L585
>
> If I enable JSR250 in the above line then your test passes.
>
> --
> Cheers, Stuart
>
>
> On Sunday, 13 November 2016 at 22:10, Dan Tran wrote:
>
> > @Stuard
> >
> > Could you review my changes at
> > https://github.com/dantran/maven/commits/master? I still not able to get
> > @PostContruct working yet
> >
> > Thanks
> >
> > -Dan
> >
> > On Sun, Sep 11, 2016 at 7:27 PM, Dan Tran <dant...@gmail.com (mailto:
> dant...@gmail.com)> wrote:
> >
> > > Thanks Stuart, very much appreciated
> > >
> > > -D
> > >
> > > On Sun, Sep 11, 2016 at 7:22 PM, Stuart McCulloch <mccu...@gmail.com
> (mailto:mccu...@gmail.com)>
> > > wrote:
> > >
> > > > Sorry, last week was very busy with work and family
> > > >
> > > > I’ve listed the necessary config changes in
> > > > https://issues.apache.org/jira/browse/MNG-6084
> > > >
> > > > --
> > > > Cheers, Stuart
> > > >
> > > >
> > > > On Sunday, 11 September 2016 at 04:28, Dan Tran wrote:
> > > >
> > > > > @Stuart, ping :-)
> > > > >
> > > > > On Tue, Sep 6, 2016 at 7:06 PM, Dan Tran <dant...@gmail.com
> (mailto:dant...@gmail.com) (mailto:
> > > > dant...@gmail.com (mailto:dant...@gmail.com))> wrote:
> > > > >
> > > > > > @Stuart, could you provide instructions on how to enable JSR 250
> > > > support?
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > >
> > > > > > -Dan
> > > > > >
> > > > > > On Fri, Sep 2, 2016 at 9:22 AM, Dan Tran <dant...@gmail.com
> (mailto:dant...@gmail.com) (mailto:
> > > > dant...@gmail.com (mailto:dant...@gmail.com))> wrote:
> > > > > >
> > > > > > > here you go https://issues.apache.org/jira/browse/MNG-6084
> > > > > > >
> > > > > > > Very much appreciated
> > > > > > >
> > > > > > > -Dan
> > > > > > >
> > > > > > > On Fri, Sep 2, 2016 at 8:42 AM, Stuart McCulloch <
> mccu...@gmail.com (mailto:mccu...@gmail.com)
> > > > (mailto:mccu...@gmail.com)>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Wednesday, 31 August 2016 at 19:05, Dan Tran wrote:
> > > > > > > > > Hi Stuart
> > > > > > > > >
> > > > > > > > > Thanks for helping out.
> > > > > > > > >
> > > > > > > > > I have 3 mojos, sharing one singleton component which
> depends on
> > > > > > > > another
> > > > > > > > > singleton component thru injection. All working now via
> both
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > > injection
> > > > > > > >
> > > > > > > > type
> > > > > > > > > ( after some cleanup)
> > > > > > > > >
> > > > > > > > > should I file a JIRA to enable JSR-250 support fo rmaven
> 3.4?
> > > > > > > > Sure - send me the ticket number and I’ll add some
> commentary this
> > > > > > > > weekend
> > > > > > > > > looking forward to use it
> > > > > > > > >
> > > > > > > > > Thanks
> > > > > > > > >
> > > > > > > > > -Dan
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Aug 31, 2016 at 9:22 AM, Stuart McCulloch &l

Re: Maven Plugin and JSR330

[Dan Tran]

@Stuard

Could you review my changes at
https://github.com/dantran/maven/commits/master?  I still not able to get
@PostContruct working yet

Thanks

-Dan

On Sun, Sep 11, 2016 at 7:27 PM, Dan Tran <dant...@gmail.com> wrote:

> Thanks Stuart, very much appreciated
>
> -D
>
> On Sun, Sep 11, 2016 at 7:22 PM, Stuart McCulloch <mccu...@gmail.com>
> wrote:
>
>> Sorry, last week was very busy with work and family
>>
>> I’ve listed the necessary config changes in
>> https://issues.apache.org/jira/browse/MNG-6084
>>
>> --
>> Cheers, Stuart
>>
>>
>> On Sunday, 11 September 2016 at 04:28, Dan Tran wrote:
>>
>> > @Stuart, ping :-)
>> >
>> > On Tue, Sep 6, 2016 at 7:06 PM, Dan Tran <dant...@gmail.com (mailto:
>> dant...@gmail.com)> wrote:
>> >
>> > > @Stuart, could you provide instructions on how to enable JSR 250
>> support?
>> > >
>> > > Thanks
>> > >
>> > >
>> > > -Dan
>> > >
>> > > On Fri, Sep 2, 2016 at 9:22 AM, Dan Tran <dant...@gmail.com (mailto:
>> dant...@gmail.com)> wrote:
>> > >
>> > > > here you go https://issues.apache.org/jira/browse/MNG-6084
>> > > >
>> > > > Very much appreciated
>> > > >
>> > > > -Dan
>> > > >
>> > > > On Fri, Sep 2, 2016 at 8:42 AM, Stuart McCulloch <mccu...@gmail.com
>> (mailto:mccu...@gmail.com)>
>> > > > wrote:
>> > > >
>> > > > > On Wednesday, 31 August 2016 at 19:05, Dan Tran wrote:
>> > > > > > Hi Stuart
>> > > > > >
>> > > > > > Thanks for helping out.
>> > > > > >
>> > > > > > I have 3 mojos, sharing one singleton component which depends on
>> > > > > another
>> > > > > > singleton component thru injection. All working now via both
>> injection
>> > > > >
>> > > > > type
>> > > > > > ( after some cleanup)
>> > > > > >
>> > > > > > should I file a JIRA to enable JSR-250 support fo rmaven 3.4?
>> > > > > Sure - send me the ticket number and I’ll add some commentary this
>> > > > > weekend
>> > > > > > looking forward to use it
>> > > > > >
>> > > > > > Thanks
>> > > > > >
>> > > > > > -Dan
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > On Wed, Aug 31, 2016 at 9:22 AM, Stuart McCulloch <
>> mccu...@gmail.com (mailto:mccu...@gmail.com)
>> > > > > (mailto:mccu...@gmail.com)> wrote:
>> > > > > >
>> > > > > > > Hi Dan,
>> > > > > > >
>> > > > > > > Constructor injection (and component injection) is working
>> for me
>> > > > > with
>> > > > > > > Maven 3.3.9 if I follow the example in
>> > > > > >
>> > > > >
>> > > > > http://maven.apache.org/maven-
>> > > > > > > jsr330.html
>> > > > > > >
>> > > > > > > Is your plugin code available somewhere?
>> > > > > > >
>> > > > > > > PS. at the moment Maven doesn’t enable container support for
>> JSR-250
>> > > > > > > lifecycle, but it is implemented by Sisu under a feature flag:
>> > > > > > >
>> > > > > > > https://github.com/eclipse/sisu.plexus/blob/releases/0.3.
>> > > > > > > 3/org.eclipse.sisu.plexus/src/org/codehaus/plexus/
>> > > > > > > ContainerConfiguration.java#L62
>> > > > > > >
>> > > > > > > --
>> > > > > > > Cheers, Stuart
>> > > > > > >
>> > > > > > >
>> > > > > > > On Wednesday, 31 August 2016 at 16:59, Dan Tran wrote:
>> > > > > > >
>> > > > > > > > Hi Thomas,
>> > > > > > > >
>> > > > > > > > You are right!!! looking for how to fix this...
>> > > > > > > >
>> > > > > > > > The only thing working for me is field injection at MOJO.
>> event The
>> > > > > > > > constructor injection ( as documented) at MOJO is not.
>> > > > > > > >
>> > > > > > > > Thanks
>> > > > > > > >
>> > > > > > > > -Dan
>> > > > > > > >
>> > > > > > > > On Wed, Aug 31, 2016 at 1:20 AM, Thomas Broyer <
>> t.bro...@gmail.com (mailto:t.bro...@gmail.com)
>> > > > > (mailto:t.bro...@gmail.com)
>> > > > > > > (mailto:t.bro...@gmail.com)> wrote:
>> > > > > > > >
>> > > > > > > > > On Wed, Aug 31, 2016 at 8:43 AM Dan Tran <
>> dant...@gmail.com (mailto:dant...@gmail.com)
>> > > > > (mailto:dant...@gmail.com) (mailto:
>> > > > > > > dant...@gmail.com (mailto:dant...@gmail.com))> wrote:
>> > > > > > > > >
>> > > > > > > > > > Hi
>> > > > > > > > > >
>> > > > > > > > > > I have a need to inject my jsr330 component into my
>> plugins[1]
>> > > > > and I
>> > > > > > > > > > found 2 issues
>> > > > > > > > > >
>> > > > > > > > > > 1. @Inject under MOJO works, but my singleton component
>> > > > > @PreDestroy
>> > > > > > > never
>> > > > > > > > > > got called
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > @PreDestroy is not part of JSR 330, it's a CDI thing, so
>> no
>> > > > > wonder
>> > > > > > > it's not
>> > > > > > > > > called.
>> > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> >
>>
>>
>>
>

Re: Skipping install phase for a particular artifact in a project

[Dan Tran]

setup 2 assembly executions, with the first one not 'attach' to maven
session(see assembly-m-p doc for detail).  Then at install phase, maven
only install the second assembly

-D

On Thu, Nov 3, 2016 at 10:57 PM, Gupta, Nishant. 
wrote:

> Hi,
>
> I was wondering if there is a way by which we can skip the install phase
> for a particular artifact. My use case is that I am using
> maven-assembly-plugin with two assembly descriptors in it. The output of
> first assembly descriptor is being used as input of the second assembly
> descriptor. After package phase, I deleted the first assembly descriptor
> artifact (in the target folder) using maven-clean-plugin but in the install
> phase, it throws and error saying that it couldn't find the first assembly
> descriptor artifact.
>
> Any help will be appreciated.
>
> Regards,
> Nishant Gupta
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

[ANN] Mojohaus' Assembler Maven Plugin 2.0.0 Released

[Dan Tran]

Hi,

The Mojo team is pleased to announce the release of the Appassembler Maven
Plugin version 2.0.0.

The Application Assembler Plugin is a Maven plugin for generating scripts
for starting java applications. All dependencies and the artifact of the
project itself are placed in a generated Maven repository in a defined
assemble directory. All artifacts (dependencies + the artifact from the
project) are added to the classpath in the generated bin scripts.

http://www.mojohaus.org/appassembler/appassembler-maven-plugin


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


  org.codehaus.mojo
  appassembler-maven-plugin
  2.0.0

Hi,


This release consists of:

  * The usual dependency upgrades
  * Drop Java 5 support ( reason for pumping the version to 2.0)
  * Add option to clean staging directory without the need to run maven
clean for build optimization purpose


The list of fixed issues can be viewed here:
https://github.com/mojohaus/appassembler/issues?q=is%3Aclosed+milestone%3A%
22Release+2.0.0%22

Enjoy

The Mojo Team

Re: Maven Plugin and JSR330

[Dan Tran]

Thanks Stuart, very much appreciated

-D

On Sun, Sep 11, 2016 at 7:22 PM, Stuart McCulloch <mccu...@gmail.com> wrote:

> Sorry, last week was very busy with work and family
>
> I’ve listed the necessary config changes in https://issues.apache.org/
> jira/browse/MNG-6084
>
> --
> Cheers, Stuart
>
>
> On Sunday, 11 September 2016 at 04:28, Dan Tran wrote:
>
> > @Stuart, ping :-)
> >
> > On Tue, Sep 6, 2016 at 7:06 PM, Dan Tran <dant...@gmail.com (mailto:
> dant...@gmail.com)> wrote:
> >
> > > @Stuart, could you provide instructions on how to enable JSR 250
> support?
> > >
> > > Thanks
> > >
> > >
> > > -Dan
> > >
> > > On Fri, Sep 2, 2016 at 9:22 AM, Dan Tran <dant...@gmail.com (mailto:
> dant...@gmail.com)> wrote:
> > >
> > > > here you go https://issues.apache.org/jira/browse/MNG-6084
> > > >
> > > > Very much appreciated
> > > >
> > > > -Dan
> > > >
> > > > On Fri, Sep 2, 2016 at 8:42 AM, Stuart McCulloch <mccu...@gmail.com
> (mailto:mccu...@gmail.com)>
> > > > wrote:
> > > >
> > > > > On Wednesday, 31 August 2016 at 19:05, Dan Tran wrote:
> > > > > > Hi Stuart
> > > > > >
> > > > > > Thanks for helping out.
> > > > > >
> > > > > > I have 3 mojos, sharing one singleton component which depends on
> > > > > another
> > > > > > singleton component thru injection. All working now via both
> injection
> > > > >
> > > > > type
> > > > > > ( after some cleanup)
> > > > > >
> > > > > > should I file a JIRA to enable JSR-250 support fo rmaven 3.4?
> > > > > Sure - send me the ticket number and I’ll add some commentary this
> > > > > weekend
> > > > > > looking forward to use it
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > -Dan
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Aug 31, 2016 at 9:22 AM, Stuart McCulloch <
> mccu...@gmail.com (mailto:mccu...@gmail.com)
> > > > > (mailto:mccu...@gmail.com)> wrote:
> > > > > >
> > > > > > > Hi Dan,
> > > > > > >
> > > > > > > Constructor injection (and component injection) is working for
> me
> > > > > with
> > > > > > > Maven 3.3.9 if I follow the example in
> > > > > >
> > > > >
> > > > > http://maven.apache.org/maven-
> > > > > > > jsr330.html
> > > > > > >
> > > > > > > Is your plugin code available somewhere?
> > > > > > >
> > > > > > > PS. at the moment Maven doesn’t enable container support for
> JSR-250
> > > > > > > lifecycle, but it is implemented by Sisu under a feature flag:
> > > > > > >
> > > > > > > https://github.com/eclipse/sisu.plexus/blob/releases/0.3.
> > > > > > > 3/org.eclipse.sisu.plexus/src/org/codehaus/plexus/
> > > > > > > ContainerConfiguration.java#L62
> > > > > > >
> > > > > > > --
> > > > > > > Cheers, Stuart
> > > > > > >
> > > > > > >
> > > > > > > On Wednesday, 31 August 2016 at 16:59, Dan Tran wrote:
> > > > > > >
> > > > > > > > Hi Thomas,
> > > > > > > >
> > > > > > > > You are right!!! looking for how to fix this...
> > > > > > > >
> > > > > > > > The only thing working for me is field injection at MOJO.
> event The
> > > > > > > > constructor injection ( as documented) at MOJO is not.
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > >
> > > > > > > > -Dan
> > > > > > > >
> > > > > > > > On Wed, Aug 31, 2016 at 1:20 AM, Thomas Broyer <
> t.bro...@gmail.com (mailto:t.bro...@gmail.com)
> > > > > (mailto:t.bro...@gmail.com)
> > > > > > > (mailto:t.bro...@gmail.com)> wrote:
> > > > > > > >
> > > > > > > > > On Wed, Aug 31, 2016 at 8:43 AM Dan Tran <
> dant...@gmail.com (mailto:dant...@gmail.com)
> > > > > (mailto:dant...@gmail.com) (mailto:
> > > > > > > dant...@gmail.com (mailto:dant...@gmail.com))> wrote:
> > > > > > > > >
> > > > > > > > > > Hi
> > > > > > > > > >
> > > > > > > > > > I have a need to inject my jsr330 component into my
> plugins[1]
> > > > > and I
> > > > > > > > > > found 2 issues
> > > > > > > > > >
> > > > > > > > > > 1. @Inject under MOJO works, but my singleton component
> > > > > @PreDestroy
> > > > > > > never
> > > > > > > > > > got called
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > @PreDestroy is not part of JSR 330, it's a CDI thing, so no
> > > > > wonder
> > > > > > > it's not
> > > > > > > > > called.
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>
>

Re: Maven Plugin and JSR330

[Dan Tran]

@Stuart, ping :-)

On Tue, Sep 6, 2016 at 7:06 PM, Dan Tran <dant...@gmail.com> wrote:

> @Stuart, could you provide instructions on how to enable JSR 250 support?
>
> Thanks
>
>
> -Dan
>
> On Fri, Sep 2, 2016 at 9:22 AM, Dan Tran <dant...@gmail.com> wrote:
>
>> here you go https://issues.apache.org/jira/browse/MNG-6084
>>
>> Very much appreciated
>>
>> -Dan
>>
>> On Fri, Sep 2, 2016 at 8:42 AM, Stuart McCulloch <mccu...@gmail.com>
>> wrote:
>>
>>> On Wednesday, 31 August 2016 at 19:05, Dan Tran wrote:
>>> > Hi Stuart
>>> >
>>> > Thanks for helping out.
>>> >
>>> > I have 3 mojos, sharing one singleton component which depends on
>>> another
>>> > singleton component thru injection. All working now via both injection
>>> type
>>> > ( after some cleanup)
>>> >
>>> > should I file a JIRA to enable JSR-250 support fo rmaven 3.4?
>>> Sure - send me the ticket number and I’ll add some commentary this
>>> weekend
>>> > looking forward to use it
>>> >
>>> > Thanks
>>> >
>>> > -Dan
>>> >
>>> >
>>> >
>>> > On Wed, Aug 31, 2016 at 9:22 AM, Stuart McCulloch <mccu...@gmail.com
>>> (mailto:mccu...@gmail.com)> wrote:
>>> >
>>> > > Hi Dan,
>>> > >
>>> > > Constructor injection (and component injection) is working for me
>>> with
>>> > > Maven 3.3.9 if I follow the example in
>>> http://maven.apache.org/maven-
>>> > > jsr330.html
>>> > >
>>> > > Is your plugin code available somewhere?
>>> > >
>>> > > PS. at the moment Maven doesn’t enable container support for JSR-250
>>> > > lifecycle, but it is implemented by Sisu under a feature flag:
>>> > >
>>> > > https://github.com/eclipse/sisu.plexus/blob/releases/0.3.
>>> > > 3/org.eclipse.sisu.plexus/src/org/codehaus/plexus/
>>> > > ContainerConfiguration.java#L62
>>> > >
>>> > > --
>>> > > Cheers, Stuart
>>> > >
>>> > >
>>> > > On Wednesday, 31 August 2016 at 16:59, Dan Tran wrote:
>>> > >
>>> > > > Hi Thomas,
>>> > > >
>>> > > > You are right!!! looking for how to fix this...
>>> > > >
>>> > > > The only thing working for me is field injection at MOJO. event The
>>> > > > constructor injection ( as documented) at MOJO is not.
>>> > > >
>>> > > > Thanks
>>> > > >
>>> > > > -Dan
>>> > > >
>>> > > > On Wed, Aug 31, 2016 at 1:20 AM, Thomas Broyer <t.bro...@gmail.com
>>> (mailto:t.bro...@gmail.com)
>>> > > (mailto:t.bro...@gmail.com)> wrote:
>>> > > >
>>> > > > > On Wed, Aug 31, 2016 at 8:43 AM Dan Tran <dant...@gmail.com
>>> (mailto:dant...@gmail.com) (mailto:
>>> > > dant...@gmail.com (mailto:dant...@gmail.com))> wrote:
>>> > > > >
>>> > > > > > Hi
>>> > > > > >
>>> > > > > > I have a need to inject my jsr330 component into my plugins[1]
>>> and I
>>> > > > > > found 2 issues
>>> > > > > >
>>> > > > > > 1. @Inject under MOJO works, but my singleton component
>>> @PreDestroy
>>> > > never
>>> > > > > > got called
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > @PreDestroy is not part of JSR 330, it's a CDI thing, so no
>>> wonder
>>> > > it's not
>>> > > > > called.
>>> > > >
>>> > >
>>> > >
>>> >
>>>
>>>
>>>
>>
>

Re: Maven Plugin and JSR330

[Dan Tran]

@Stuart, could you provide instructions on how to enable JSR 250 support?

Thanks


-Dan

On Fri, Sep 2, 2016 at 9:22 AM, Dan Tran <dant...@gmail.com> wrote:

> here you go https://issues.apache.org/jira/browse/MNG-6084
>
> Very much appreciated
>
> -Dan
>
> On Fri, Sep 2, 2016 at 8:42 AM, Stuart McCulloch <mccu...@gmail.com>
> wrote:
>
>> On Wednesday, 31 August 2016 at 19:05, Dan Tran wrote:
>> > Hi Stuart
>> >
>> > Thanks for helping out.
>> >
>> > I have 3 mojos, sharing one singleton component which depends on another
>> > singleton component thru injection. All working now via both injection
>> type
>> > ( after some cleanup)
>> >
>> > should I file a JIRA to enable JSR-250 support fo rmaven 3.4?
>> Sure - send me the ticket number and I’ll add some commentary this weekend
>> > looking forward to use it
>> >
>> > Thanks
>> >
>> > -Dan
>> >
>> >
>> >
>> > On Wed, Aug 31, 2016 at 9:22 AM, Stuart McCulloch <mccu...@gmail.com
>> (mailto:mccu...@gmail.com)> wrote:
>> >
>> > > Hi Dan,
>> > >
>> > > Constructor injection (and component injection) is working for me with
>> > > Maven 3.3.9 if I follow the example in http://maven.apache.org/maven-
>> > > jsr330.html
>> > >
>> > > Is your plugin code available somewhere?
>> > >
>> > > PS. at the moment Maven doesn’t enable container support for JSR-250
>> > > lifecycle, but it is implemented by Sisu under a feature flag:
>> > >
>> > > https://github.com/eclipse/sisu.plexus/blob/releases/0.3.
>> > > 3/org.eclipse.sisu.plexus/src/org/codehaus/plexus/
>> > > ContainerConfiguration.java#L62
>> > >
>> > > --
>> > > Cheers, Stuart
>> > >
>> > >
>> > > On Wednesday, 31 August 2016 at 16:59, Dan Tran wrote:
>> > >
>> > > > Hi Thomas,
>> > > >
>> > > > You are right!!! looking for how to fix this...
>> > > >
>> > > > The only thing working for me is field injection at MOJO. event The
>> > > > constructor injection ( as documented) at MOJO is not.
>> > > >
>> > > > Thanks
>> > > >
>> > > > -Dan
>> > > >
>> > > > On Wed, Aug 31, 2016 at 1:20 AM, Thomas Broyer <t.bro...@gmail.com
>> (mailto:t.bro...@gmail.com)
>> > > (mailto:t.bro...@gmail.com)> wrote:
>> > > >
>> > > > > On Wed, Aug 31, 2016 at 8:43 AM Dan Tran <dant...@gmail.com
>> (mailto:dant...@gmail.com) (mailto:
>> > > dant...@gmail.com (mailto:dant...@gmail.com))> wrote:
>> > > > >
>> > > > > > Hi
>> > > > > >
>> > > > > > I have a need to inject my jsr330 component into my plugins[1]
>> and I
>> > > > > > found 2 issues
>> > > > > >
>> > > > > > 1. @Inject under MOJO works, but my singleton component
>> @PreDestroy
>> > > never
>> > > > > > got called
>> > > > >
>> > > > >
>> > > > >
>> > > > > @PreDestroy is not part of JSR 330, it's a CDI thing, so no wonder
>> > > it's not
>> > > > > called.
>> > > >
>> > >
>> > >
>> >
>>
>>
>>
>

Re: Maven Plugin and JSR330

[Dan Tran]

here you go https://issues.apache.org/jira/browse/MNG-6084

Very much appreciated

-Dan

On Fri, Sep 2, 2016 at 8:42 AM, Stuart McCulloch <mccu...@gmail.com> wrote:

> On Wednesday, 31 August 2016 at 19:05, Dan Tran wrote:
> > Hi Stuart
> >
> > Thanks for helping out.
> >
> > I have 3 mojos, sharing one singleton component which depends on another
> > singleton component thru injection. All working now via both injection
> type
> > ( after some cleanup)
> >
> > should I file a JIRA to enable JSR-250 support fo rmaven 3.4?
> Sure - send me the ticket number and I’ll add some commentary this weekend
> > looking forward to use it
> >
> > Thanks
> >
> > -Dan
> >
> >
> >
> > On Wed, Aug 31, 2016 at 9:22 AM, Stuart McCulloch <mccu...@gmail.com
> (mailto:mccu...@gmail.com)> wrote:
> >
> > > Hi Dan,
> > >
> > > Constructor injection (and component injection) is working for me with
> > > Maven 3.3.9 if I follow the example in http://maven.apache.org/maven-
> > > jsr330.html
> > >
> > > Is your plugin code available somewhere?
> > >
> > > PS. at the moment Maven doesn’t enable container support for JSR-250
> > > lifecycle, but it is implemented by Sisu under a feature flag:
> > >
> > > https://github.com/eclipse/sisu.plexus/blob/releases/0.3.
> > > 3/org.eclipse.sisu.plexus/src/org/codehaus/plexus/
> > > ContainerConfiguration.java#L62
> > >
> > > --
> > > Cheers, Stuart
> > >
> > >
> > > On Wednesday, 31 August 2016 at 16:59, Dan Tran wrote:
> > >
> > > > Hi Thomas,
> > > >
> > > > You are right!!! looking for how to fix this...
> > > >
> > > > The only thing working for me is field injection at MOJO. event The
> > > > constructor injection ( as documented) at MOJO is not.
> > > >
> > > > Thanks
> > > >
> > > > -Dan
> > > >
> > > > On Wed, Aug 31, 2016 at 1:20 AM, Thomas Broyer <t.bro...@gmail.com
> (mailto:t.bro...@gmail.com)
> > > (mailto:t.bro...@gmail.com)> wrote:
> > > >
> > > > > On Wed, Aug 31, 2016 at 8:43 AM Dan Tran <dant...@gmail.com
> (mailto:dant...@gmail.com) (mailto:
> > > dant...@gmail.com (mailto:dant...@gmail.com))> wrote:
> > > > >
> > > > > > Hi
> > > > > >
> > > > > > I have a need to inject my jsr330 component into my plugins[1]
> and I
> > > > > > found 2 issues
> > > > > >
> > > > > > 1. @Inject under MOJO works, but my singleton component
> @PreDestroy
> > > never
> > > > > > got called
> > > > >
> > > > >
> > > > >
> > > > > @PreDestroy is not part of JSR 330, it's a CDI thing, so no wonder
> > > it's not
> > > > > called.
> > > >
> > >
> > >
> >
>
>
>

Re: If an extension improves the version, it's not deployed

[Dan Tran]

I wonder if Karl's solution facing the same issue
http://blog.soebes.de/blog/2016/08/08/maven-how-to-create-a-release/

On Thu, Sep 1, 2016 at 9:20 AM, Benson Margulies 
wrote:

> Using Maven 3.3.9,
> https://github.com/basis-technology-corp/auto-version-maven-extension
> is not as useful as I had hoped. The extension sets a property for use
> in a  element, but 'mvn deploy' deploys the POM as-is, not
> after the version is calculated.
>
> Has anyone a suggestion for how to add to this extension to get the
> desired behavior?
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Maven Plugin and JSR330

[Dan Tran]

Hi Stuart

Thanks for helping out.

I have 3 mojos, sharing one singleton component which depends on another
singleton component thru injection. All working now via both injection type
( after some cleanup)

should I file a JIRA to enable JSR-250 support fo rmaven 3.4?

looking forward to use it

Thanks

-Dan



On Wed, Aug 31, 2016 at 9:22 AM, Stuart McCulloch <mccu...@gmail.com> wrote:

> Hi Dan,
>
> Constructor injection (and component injection) is working for me with
> Maven 3.3.9 if I follow the example in http://maven.apache.org/maven-
> jsr330.html
>
> Is your plugin code available somewhere?
>
> PS. at the moment Maven doesn’t enable container support for JSR-250
> lifecycle, but it is implemented by Sisu under a feature flag:
>
> https://github.com/eclipse/sisu.plexus/blob/releases/0.3.
> 3/org.eclipse.sisu.plexus/src/org/codehaus/plexus/
> ContainerConfiguration.java#L62
>
> --
> Cheers, Stuart
>
>
> On Wednesday, 31 August 2016 at 16:59, Dan Tran wrote:
>
> > Hi Thomas,
> >
> > You are right!!! looking for how to fix this...
> >
> > The only thing working for me is field injection at MOJO. event The
> > constructor injection ( as documented) at MOJO is not.
> >
> > Thanks
> >
> > -Dan
> >
> > On Wed, Aug 31, 2016 at 1:20 AM, Thomas Broyer <t.bro...@gmail.com
> (mailto:t.bro...@gmail.com)> wrote:
> >
> > > On Wed, Aug 31, 2016 at 8:43 AM Dan Tran <dant...@gmail.com (mailto:
> dant...@gmail.com)> wrote:
> > >
> > > > Hi
> > > >
> > > > I have a need to inject my jsr330 component into my plugins[1] and I
> > > > found 2 issues
> > > >
> > > > 1. @Inject under MOJO works, but my singleton component @PreDestroy
> never
> > > > got called
> > > >
> > >
> > >
> > > @PreDestroy is not part of JSR 330, it's a CDI thing, so no wonder
> it's not
> > > called.
> > >
> >
> >
> >
>
>
>

Re: Maven Plugin and JSR330

[Dan Tran]

Hi Thomas,

You are right!!! looking for how to fix this...

The only thing working for me is field injection at MOJO. event The
constructor injection ( as documented) at MOJO is not.

Thanks

-Dan

On Wed, Aug 31, 2016 at 1:20 AM, Thomas Broyer <t.bro...@gmail.com> wrote:

> On Wed, Aug 31, 2016 at 8:43 AM Dan Tran <dant...@gmail.com> wrote:
>
> > Hi
> >
> > I have a need  to  inject my jsr330 component into my plugins[1] and I
> > found 2 issues
> >
> > 1. @Inject under MOJO works, but my singleton component @PreDestroy never
> > got called
> >
>
> @PreDestroy is not part of JSR 330, it's a CDI thing, so no wonder it's not
> called.
>

Maven Plugin and JSR330

[Dan Tran]

Hi

I have a need  to  inject my jsr330 component into my plugins[1] and I
found 2 issues

1. @Inject under MOJO works, but my singleton component @PreDestroy never
got called

2.  @Inject at my component does not work.


I wonder if anyone able to get JSR330 fully working for your maven plugin
development?

my env is maven 3.3.9 and java 8


Thanks

-Dan



[1] http://maven.apache.org/maven-jsr330.html

Re: Strategies for building Docker image for Tomcat with Maven-built webapps with docker-maven-plugin

[Dan Tran]

that works too

-D

On Mon, Aug 15, 2016 at 10:52 AM, KARR, DAVID <dk0...@att.com> wrote:

> > -Original Message-
> > From: Dan Tran [mailto:dant...@gmail.com]
> > Sent: Monday, August 15, 2016 10:28 AM
> > To: Maven Users List <users@maven.apache.org>
> > Subject: Re: Strategies for building Docker image for Tomcat with Maven-
> > built webapps with docker-maven-plugin
> >
> > use destFileName
> > http://maven.apache.org/plugins/maven-dependency-plugin/copy-
> > mojo.html#artifactItems
>
> Ok.  After some research, I think that perhaps just setting "stripVersion"
> to true might be all that I need.
>
> > On Mon, Aug 15, 2016 at 10:22 AM, KARR, DAVID <dk0...@att.com> wrote:
> >
> > > > -Original Message-
> > > > From: Dan Tran [mailto:dant...@gmail.com]
> > > > Sent: Wednesday, August 10, 2016 9:15 AM
> > > > To: Maven Users List <users@maven.apache.org>
> > > > Subject: Re: Strategies for building Docker image for Tomcat with
> > > > Maven- built webapps with docker-maven-plugin
> > > >
> > > >  with optoinal set to true is your friend at docker
> > > > module.
> > > > Then use maven-dependency-plugin to copy the war files into staging
> > > > directory where docker file can consume it
> > >
> > > Getting back to this, one aim that I have is for the Docker build to
> > > not care about the artifact versions, so somehow the dependency copy
> > > has to remove the version number from the artifact file.  What is the
> > > best way to do this?
> > >
> > > > On Wed, Aug 10, 2016 at 8:44 AM, KARR, DAVID <dk0...@att.com> wrote:
> > > >
> > > > > I have a simple multi-project build (just two projects), and the
> > > > > webapps produced from the two projects will be deployed to Tomcat
> > > > > (TomEE, actually).  The TomEE instance requires some non-standard
> > > > > configuration for these apps to work.
> > > > >
> > > > > I'm considering having a third subproject using the
> > > > > docker-maven-plugin to produce an image with Tomcat and the two
> > > > webapps deployed to it.
> > > > >
> > > > > The idea seems straightforward, but there are some details I want
> > > > > to clean up.
> > > > >
> > > > > For instance, the Dockerfile is going to have to copy the two
> > > > > webapps into the Tomcat distro.  At a minimum, I have to figure
> > > > > out how to get the two war files built from the peer projects into
> > > > > the Docker context so I can build the image.  I'd also like to
> > > > > ensure that when/if I change the artifact versions of the
> > > > > subprojects, I only need minimal changes to get the new version
> > into the image.
> > > > >
> > > > > What do I need to make this happen?
> > > > >
> > > > > --
> > > > > --- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > > >
> > > > >
> > >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

Re: Strategies for building Docker image for Tomcat with Maven-built webapps with docker-maven-plugin

[Dan Tran]

use destFileName
http://maven.apache.org/plugins/maven-dependency-plugin/copy-mojo.html#artifactItems

-D

On Mon, Aug 15, 2016 at 10:22 AM, KARR, DAVID <dk0...@att.com> wrote:

> > -Original Message-
> > From: Dan Tran [mailto:dant...@gmail.com]
> > Sent: Wednesday, August 10, 2016 9:15 AM
> > To: Maven Users List <users@maven.apache.org>
> > Subject: Re: Strategies for building Docker image for Tomcat with Maven-
> > built webapps with docker-maven-plugin
> >
> >  with optoinal set to true is your friend at docker
> > module.
> > Then use maven-dependency-plugin to copy the war files into staging
> > directory where docker file can consume it
>
> Getting back to this, one aim that I have is for the Docker build to not
> care about the artifact versions, so somehow the dependency copy has to
> remove the version number from the artifact file.  What is the best way to
> do this?
>
> > On Wed, Aug 10, 2016 at 8:44 AM, KARR, DAVID <dk0...@att.com> wrote:
> >
> > > I have a simple multi-project build (just two projects), and the
> > > webapps produced from the two projects will be deployed to Tomcat
> > > (TomEE, actually).  The TomEE instance requires some non-standard
> > > configuration for these apps to work.
> > >
> > > I'm considering having a third subproject using the
> > > docker-maven-plugin to produce an image with Tomcat and the two
> > webapps deployed to it.
> > >
> > > The idea seems straightforward, but there are some details I want to
> > > clean up.
> > >
> > > For instance, the Dockerfile is going to have to copy the two webapps
> > > into the Tomcat distro.  At a minimum, I have to figure out how to get
> > > the two war files built from the peer projects into the Docker context
> > > so I can build the image.  I'd also like to ensure that when/if I
> > > change the artifact versions of the subprojects, I only need minimal
> > > changes to get the new version into the image.
> > >
> > > What do I need to make this happen?
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
>