Re: Is there another alternative to using maven plug-in ?

2018-02-16 Thread Guillaume Boué 
You could also upgrade the maven-war-plugin to version 3.1.0 or newer: 
it will automatically detect if you're using Servlet 3.0, in which case 
it won't require a web.xml file to be present.



Le 16/02/2018 à 17:21, Karen Goh a écrit :

I managed to get the error away by adding

false

cos I am using Servlet 3.0 and no web.xml is needed.

On Sat, 2/3/18, Jörg Schaible  wrote:

  Subject: Re: Is there another alternative to using maven plug-in ?
  To: users@maven.apache.org
  Date: Saturday, February 3, 2018, 10:48 PM
  
  Hi Karen,
  
  Am Wed, 31 Jan 2018 08:06:31 +

  schrieb Karen Goh:
  
  > Hi John,

  >
  > I changed my pom according to what
  you said, by removing the provided
  > portion.
  > However, I am still getting the
  below error :
  >
  > Failed to execute goal
  org.apache.maven.plugins:maven-war-plugin:2.2:war
  > (default-war) on project Hi5S:
  Error assembling WAR: webxml attribute is
  > required (or pre-existing
  WEB-INF/web.xml if executing in update mode)
  >
  > I have provided web.xml in the
  WEB-INF :
  
  [snip]
  
  So, where is your web.xml located in

  relation to the project root?
  
  Cheers,

   Jörg
  
  
  -

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


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




---
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: Questions about

2017-06-28 Thread Guillaume Boué 

Hi,

Profile activation is documented here 
http://maven.apache.org/guides/introduction/introduction-to-profiles.html, 
there is a section about the different types of activation. 
 is also mentioned.


I'm not sure which part of activeByDefault you are refering to, could 
you clarify that?


Guillaume


Le 28/06/2017 à 22:43, Mark H. Wood a écrit :

I just got bitten by "activeByDefault doesn't mean what everyone
thinks it means."  OK, that's the way it is.  But I have some
questions:

o  Real-world use case for the current behavior?

o  Is there some reason why the meaning of
  
!NAME
  
is not documented in the POM reference?

o  Where *is* it documented?  Lots of people seem to know about it.




---
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: Work-around for antrun AttachArtifact not working in external Ant build file

2017-06-03 Thread Guillaume Boué 
That means you're missing inheritRefs=true in the  task. It is 
necessary for the references to be propagated to subprojects.


I've also added an integration test in 
https://github.com/apache/maven-plugins/tree/trunk/maven-antrun-plugin/src/it/attach-artifact-from-ant-task 
that you can maybe look at.


Guillaume


Le 02/06/2017 à 10:21, Jürgen Weber a écrit :

Hi,

no, still does not work.

Where is your changed source? I could run it in the debugger..

Juergen

Maven project reference not found: maven.project.ref

at
org.apache.maven.ant.tasks.AttachArtifactTask.execute(AttachArtifactTask.java:80)

Am 01.06.2017 19:17 schrieb "Guillaume Boué" <gb...@apache.org>:


It's currently in Apache snapshot repository located at
https://repository.apache.org/content/repositories/snapshots. You can add
this repository as a plugin repository to your settings or POM for the test.

 
   apache-snapshots-plugin
   https://repository.apache.org/content/repositories/snapshots/

   
 true
   
 


Le 01/06/2017 à 16:25, Jürgen Weber a écrit :


There is no 3.0.0-SNAPSHOT of maven-antrun-plugin, is it?
org/apache/maven/ant/tasks/AttachArtifactTask.class is in
maven-antrun-plugin-1.8.jar


Am 31.05.2017 19:57 schrieb "Guillaume Boué" <gb...@apache.org>:

Hi,

I looked into this issue and committed a fix for it. The core problem was
that the 'attachartifact' task launched from the external Ant build was
working from a clone of the Maven project, instead of the project itself.
Can you try the latest 3.0.0-SNAPSHOT and report back?



Le 31/05/2017 à 19:14, Jürgen Weber a écrit :

Hi,

I found a solution, not pretty, but it actually works:

in an pom-inline antrun task call a Javascript function with the
project as parameter, in Javascript one can do all interesting things
(loop over properties from an ant property file) and call the
attachartifact task.

Cheers,
Juergen


 <![CDATA[
load("script.js");
runtaskf(self.getProject());
]]>



script.js:

var runtaskf = function(project) {
aa = project.createTask("attachartifact");
f = new java.io.File("my.jar");
aa.setFile(f);
aa.setType("jar");
aa.setClassifier("test");
aa.perform();
}

2017-05-31 18:32 GMT+02:00 Karl Heinz Marbaise <khmarba...@gmx.de>:

Hi,

if i correctly understand you have a property file for each environment
and
maybe some other files and a base artifact (jar/war?) now it sounds you
have
to build for each environment a different jar/war ?

Maybe something like this could help here:

https://github.com/khmarbaise/multienv-maven-plugin/

or:

https://github.com/khmarbaise/iterator-maven-plugin/


Kind regards
Karl Heinz Marbaise


On 31/05/17 11:42, Jürgen Weber wrote:

Hi Jörg,

problem is, I have to build message driven beans, some 20, only
difference
is the queue name in the deployment descriptor. Queue names are listed
in
a
property file.
 I know that Maven wants no environment specific properties in
artifacts,
but Sun defined the activation spec for MDBs. And the activation spec
is
in
code or in ejb-jar.xml, both in the mdb jar. So I have to build a
different
MDB for each queue. And I have to iterate over the queues (which is
possible in ant + JavaScript. Yuck).
So I'd need to attach n artefacts, wherea in a Maven pom I have to list
each artefact individually.
Greetings, Jürgen

Am 30.05.2017 08:45 schrieb "Jörg Schaible"
<joerg.schai...@bpm-inspire.com

:

Hi Jürgen,

Jürgen Weber wrote:

What is the recommended work-around for attaching artifacts created by


antrun?

* forward target directory as variable to ant ?

That helps if the created files should be removed in a normal "clean"

phase.

* build-helper-maven-plugin attach-artifact ?
Definitely the proper action.

http://technotes.khitrenovich.com/attach-maven-artifact-
external-build-xml-file/

https://issues.apache.org/jira/browse/MANTRUN-181

Thx,
Juergen

Cheers,

Jörg

-


To unsubscribe, e-mail: users-unsubscr...@maven.apache.org

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


---

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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus




---
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: Work-around for antrun AttachArtifact not working in external Ant build file

2017-06-01 Thread Guillaume Boué 
It's currently in Apache snapshot repository located at 
https://repository.apache.org/content/repositories/snapshots. You can 
add this repository as a plugin repository to your settings or POM for 
the test.



  apache-snapshots-plugin
  https://repository.apache.org/content/repositories/snapshots/
  
true
  



Le 01/06/2017 à 16:25, Jürgen Weber a écrit :

There is no 3.0.0-SNAPSHOT of maven-antrun-plugin, is it?
org/apache/maven/ant/tasks/AttachArtifactTask.class is in
maven-antrun-plugin-1.8.jar


Am 31.05.2017 19:57 schrieb "Guillaume Boué" <gb...@apache.org>:

Hi,

I looked into this issue and committed a fix for it. The core problem was
that the 'attachartifact' task launched from the external Ant build was
working from a clone of the Maven project, instead of the project itself.
Can you try the latest 3.0.0-SNAPSHOT and report back?



Le 31/05/2017 à 19:14, Jürgen Weber a écrit :


Hi,

I found a solution, not pretty, but it actually works:

in an pom-inline antrun task call a Javascript function with the
project as parameter, in Javascript one can do all interesting things
(loop over properties from an ant property file) and call the
attachartifact task.

Cheers,
Juergen


 <![CDATA[
load("script.js");
runtaskf(self.getProject());
]]>



script.js:

var runtaskf = function(project) {
aa = project.createTask("attachartifact");
f = new java.io.File("my.jar");
aa.setFile(f);
aa.setType("jar");
aa.setClassifier("test");
aa.perform();
}

2017-05-31 18:32 GMT+02:00 Karl Heinz Marbaise <khmarba...@gmx.de>:


Hi,

if i correctly understand you have a property file for each environment
and
maybe some other files and a base artifact (jar/war?) now it sounds you
have
to build for each environment a different jar/war ?

Maybe something like this could help here:

https://github.com/khmarbaise/multienv-maven-plugin/

or:

https://github.com/khmarbaise/iterator-maven-plugin/


Kind regards
Karl Heinz Marbaise


On 31/05/17 11:42, Jürgen Weber wrote:


Hi Jörg,
problem is, I have to build message driven beans, some 20, only
difference
is the queue name in the deployment descriptor. Queue names are listed in
a
property file.
I know that Maven wants no environment specific properties in
artifacts,
but Sun defined the activation spec for MDBs. And the activation spec is
in
code or in ejb-jar.xml, both in the mdb jar. So I have to build a
different
MDB for each queue. And I have to iterate over the queues (which is
possible in ant + JavaScript. Yuck).
So I'd need to attach n artefacts, wherea in a Maven pom I have to list
each artefact individually.
Greetings, Jürgen

Am 30.05.2017 08:45 schrieb "Jörg Schaible"
<joerg.schai...@bpm-inspire.com


:


Hi Jürgen,

Jürgen Weber wrote:

What is the recommended work-around for attaching artifacts created by

antrun?

* forward target directory as variable to ant ?


That helps if the created files should be removed in a normal "clean"
phase.

* build-helper-maven-plugin attach-artifact ?
Definitely the proper action.

http://technotes.khitrenovich.com/attach-maven-artifact-
external-build-xml-file/


https://issues.apache.org/jira/browse/MANTRUN-181

Thx,
Juergen


Cheers,
Jörg

-

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



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





---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

Re: Work-around for antrun AttachArtifact not working in external Ant build file

2017-05-31 Thread Guillaume Boué 

Hi,

I looked into this issue and committed a fix for it. The core problem 
was that the 'attachartifact' task launched from the external Ant build 
was working from a clone of the Maven project, instead of the project 
itself. Can you try the latest 3.0.0-SNAPSHOT and report back?



Le 31/05/2017 à 19:14, Jürgen Weber a écrit :

Hi,

I found a solution, not pretty, but it actually works:

in an pom-inline antrun task call a Javascript function with the
project as parameter, in Javascript one can do all interesting things
(loop over properties from an ant property file) and call the
attachartifact task.

Cheers,
Juergen


 



script.js:

var runtaskf = function(project) {
aa = project.createTask("attachartifact");
f = new java.io.File("my.jar");
aa.setFile(f);
aa.setType("jar");
aa.setClassifier("test");
aa.perform();
}

2017-05-31 18:32 GMT+02:00 Karl Heinz Marbaise :

Hi,

if i correctly understand you have a property file for each environment and
maybe some other files and a base artifact (jar/war?) now it sounds you have
to build for each environment a different jar/war ?

Maybe something like this could help here:

https://github.com/khmarbaise/multienv-maven-plugin/

or:

https://github.com/khmarbaise/iterator-maven-plugin/


Kind regards
Karl Heinz Marbaise


On 31/05/17 11:42, Jürgen Weber wrote:

Hi Jörg,
problem is, I have to build message driven beans, some 20, only difference
is the queue name in the deployment descriptor. Queue names are listed in
a
property file.
   I know that Maven wants no environment specific properties in artifacts,
but Sun defined the activation spec for MDBs. And the activation spec is
in
code or in ejb-jar.xml, both in the mdb jar. So I have to build a
different
MDB for each queue. And I have to iterate over the queues (which is
possible in ant + JavaScript. Yuck).
So I'd need to attach n artefacts, wherea in a Maven pom I have to list
each artefact individually.
Greetings, Jürgen

Am 30.05.2017 08:45 schrieb "Jörg Schaible"

Re: profile activation on property set but !value vs property not set

2017-03-13 Thread Guillaume Boué 

Hi,

platform!all

means that the profile will be active when the system property 
"platform" is not defined, or is defined with a value different than 
"all". Put another way, it is always active unless "platform" is equal 
to "all". This explains your observations, where both platform-reactor 
and default-reactor are active when the system property isn't set.


There was the JIRA MNGSITE-293, in which the documentation was clarified 
to reflect this.


Guillaume

Le 12/03/2017 à 05:00, Justin Georgeson a écrit :

Seeing that I can ! the property value in a profile activation, I assumed there 
were three states to consider when evaluating the property activation:

 1. Property not set
 2. Property set and value does not match
 3. Property set and value does match

With this assumption I thought that with profiles such as these

 
 
 default-reactor
 
!platform
 
 
 platform-reactor
 
platform!all
 
 
 all-platforms-reactor
 
platformall
 
 

I would only see one of the three profiles active at a time. However when I run 
Maven 'mvn help:active-profiles' with no 'platform' property then both the 
'default-reactor' and 'platform-reactor' are active. When I set the 'platform' 
property then I see the behavior I expected. Looking at the source

https://github.com/apache/maven/blob/38300cf2832e9a40198091aa9e0bf6d3dbc3268d/maven-model-builder/src/main/java/org/apache/maven/model/profile/activation/PropertyProfileActivator.java#L95

It's doing a string compare of the activation's declared property value against the 
context's property value, but it's not checking the context has a property set. But I 
would infer from the comment on L94 ("we have a value, so it has to match the system 
value...") that an unset property should not match a !value activation.

Should I open a JIRA issue as a bug, or as a feature request?

--
This e-mail, including any attached files, may contain confidential and 
privileged information for the sole use of the intended recipient.  Any review, 
use, distribution, or disclosure by others is strictly prohibited.  If you are 
not the intended recipient (or authorized to receive information for the 
intended recipient), please contact the sender by reply e-mail and delete all 
copies of this message.

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




---
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: Slightly more advanced resource filtering (templating)?

2017-01-03 Thread Guillaume Boué 

Hi,

It sounds like you're looking for the parse-version goal of the 
build-helper-maven-plugin: 
http://www.mojohaus.org/build-helper-maven-plugin/parse-version-mojo.html. 
It can decompose the project version into several Maven properties. 
There is an example of usage here 
http://www.mojohaus.org/build-helper-maven-plugin/usage.html#Access_the_parsed_components_of_a_project_version.


Guillaume


Le 03/01/2017 à 19:25, org.apache.maven.u...@io7m.com a écrit :

Hello.

I have a small project that contains a plugin for Blender[0]. Plugins
in Blender are Python files that must contain a hash value at the top
of the file containing version information. The version information has
to be numeric constants as Blender actually parses this data rather
than evaluating it in an interpreter.

https://github.com/io7m/smf/blob/develop/io7m-smfj-blender/src/main/resources/__init__.py

Right now, I'm having to remember to manually insert the right version
number each time I increment the Maven version. I'd much rather filter
the Python source file as a resource instead, but unfortunately I'd
need to transform the Maven version string:

   2.3.1 → (2, 3, 1)

Is there an existing plugin that can do this? I assume that it'd be
some sort of templating engine. Unfortunately, all of the search
results for that seem to be in regards to the site plugin.

M

[0] http://blender.org



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

2016-12-25 Thread Guillaume Boué 
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/apache/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  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: maven build broken with jdk1.8

2016-10-18 Thread Guillaume Boué 

Hi,

Your previous error was about the snapshot policy, which the -U flag has 
definitely solved. If you still hit an issue, it has to be a different 
error, can you show what it is?


Guillaume

Le 18/10/2016 à 16:19, Gopal a écrit :

Hi:
I have cleaned out the repository, used the -U option and still it will not
build with jdk 1.8

I am getting confused by this situation. It builds successfully with jdk 1.7
with no pom changes.

Is the jdk 1.8 compiler not happy?

Gopal



--
View this message in context: 
http://maven.40175.n5.nabble.com/maven-build-broken-with-jdk1-8-tp5883777p5883871.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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




---
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: maven build broken with jdk1.8

2016-10-17 Thread Guillaume Boué 

Hi,

The error you have is "... was cached in the local repository, 
resolution will not be reattempted until the update interval of 
Proper-Resolution has elapsed or updates are forced". The typical 
resolution to this is to force Maven to update releases and snapshots 
with the -U parameter. On the command line, you would do "mvn -U clean 
package".


To do it inside IntelliJ, you can probably refer to this Stack Overflow 
question 
http://stackoverflow.com/questions/9980869/force-intellij-idea-to-reread-all-maven-dependencies.


Guillaume,


Le 17/10/2016 à 17:16, Gopalakrishnan, Gopal (CORP) a écrit :

Hi:

I am not an expert at maven. Here's the scenario.

My entire project compiles without any errors under jdk1.7 

I use artifactory to store common libraries. Under jdk 1.7, they got resolved 
without any problems. All I did was to change the jdk from 1.7 to 1.8. I am 
using intellij 2016. I change the jdk version using
Run --> Edit Configuration -- > select the maven configuration --> Runner tab 
--> 1.8

However, if change the jdk to jdk 1.8

I get errors on dependency resolution ...

[ERROR] Failed to execute goal on project modulecore: Could not resolve 
dependencies for project com.adp.sass:modulecore:jar:1.0.0-SNAPSHOT: Failed to 
collect dependencies at com.adp.sass:sasscommon:jar:1.0.0-SNAPSHOT: Failed to read 
artifact descriptor for com.adp.sass:sasscommon:jar:1.0.0-SNAPSHOT: Failure to 
find com.adp.sass:sassbuild:pom:1.0.0 in 
http://avsf-depsvr01:8082/artifactory/Proper-Resolution was cached in the local 
repository, resolution will not be reattempted until the update interval of 
Proper-Resolution has elapsed or updates are forced -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
on project modulecore: Could not resolve dependencies for project 
com.adp.sass:modulecore:jar:1.0.0-SNAPSHOT: Failed to collect dependencies at 
com.adp.sass:sasscommon:jar:1.0.0-SNAPSHOT
 at 
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:221)
 at 
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:127)
 at 
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:245)
 at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:199)
 at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
 at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
 at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
 at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
 at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
 at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
 at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
 at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
 at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
Caused by: org.apache.maven.project.DependencyResolutionException: Could not 
resolve dependencies for project com.adp.sass:modulecore:jar:1.0.0-SNAPSHOT: 
Failed to collect dependencies at com.adp.sass:sasscommon:jar:1.0.0-SNAPSHOT
 at 
org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:180)
 at 
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:195)

Re: [EXTERNAL] Re: help with version range

2016-09-23 Thread Guillaume Boué 
Maven will consider 2.0-alpha-1 to be before 2.0-SNAPSHOT. This is 
documented in ComparableVersion: 
https://maven.apache.org/ref/3.3.9/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html.


Guillaume

Le 23/09/2016 à 18:49, Robert Patrick a écrit :

I was not suggesting that it could be changed...only that it doesn't make sense 
(except from a pure mathematical point of view).

Given this "engineer's approach" to version range resolution, it seems like a 
better idea is simply to say [1.0,2.0-SNAPSHOT).  I have verified that this eliminates 
2.0-SNAPSHOT versions.  However, what I have not verified is what happens when you have 
other pre-release versions (e.g., 2.0-alpha-1).  Is 2.0-SNAPSHOT always considered as 
older than non-SNAPSHOT pre-release versions like alpha, beta, etc?


-Original Message-
From: Manfred Moser [mailto:manf...@simpligility.com]
Sent: Friday, September 23, 2016 11:47 AM
To: users@maven.apache.org
Subject: Re: [EXTERNAL] Re: help with version range

Fair enough. From the purely engineering/mathematical point of view it might 
not make sense. But I dont see a way to get that changed with breaking a TON of 
other stuff. And I am not even sure if it would be more intuitive instead of 
just being different.

Manfred

Robert Patrick wrote on 2016-09-23 09:38:


No, you are making an invalid assumption about what I understand!  I
completely understand the relationship of SNAPSHOTs and other
pre-release artifacts and released versions.

What I am questioning is the "engineer's approach" to version range
resolution without a valid use case for why Maven should consider
pre-released versions as within the "not including 2.0" version range semantics.


-Original Message-
From: Manfred Moser [mailto:manf...@simpligility.com]
Sent: Friday, September 23, 2016 11:32 AM
To: users@maven.apache.org
Subject: Re: [EXTERNAL] Re: help with version range

What you are misunderstanding is how snapshots are meant to be used.
2.0-SNAPSHOT means that it is a development version working towards
the release of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.

If you mislike this you can change how you work with your own projects
at least. .. you can just call your snapshot version 1.99-SNAPSHOT or
whatever while developing and at releas time switch to 2.0 ..

Manfred

Robert Patrick wrote on 2016-09-23 08:56:


This does seem non-intuitive.If I say that I want versions  between 1.0
and
up to but NOT including 2.0 by saying [1.0,2.0), in what use case
would I ever want this to resolve to 2.0-SNAPSHOT or any other
pre-release 2.0 artifact?
Personally, I cannot think of a single one.

Typically, what I mean when I say [1.0,2.0) is any 1.x version but
nothing related to 2.0...

-Original Message-
From: Justin Georgeson [mailto:jgeorge...@lgc.com]
Sent: Friday, September 23, 2016 10:11 AM
To: Maven Users List
Subject: RE: [EXTERNAL] Re: help with version range

Yeah, I was hoping there was something more elegant like 1.1+ or
something, so I can at least move forward with that.

Logically, does it make sense to resolve 1.2.0-alpha-1 when the user
has excluded 1.2.0 from their range? If I explicitly don't want the
release version why would I want the pre-release versions?

-Original Message-
From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On
Behalf Of Curtis Rueden
Sent: Friday, September 23, 2016 9:01 AM
To: Maven Users List
Subject: [EXTERNAL] Re: help with version range

Hi Justin,

You could write "[1.1.0,1.1.9]", no? A bit hacky, but would match
the versions you want in practice.

Regards,
Curtis

On Sep 23, 2016 8:38 AM, "Justin Georgeson"  wrote:


I’m using the parent version range feature with “[1.1.0,1.2.0)” and
it had been going well. However I wanted to start working on 1.2.0
of the parent, so I published a 1.2.0-alpha-1 version. And all the
projects with te “[1.1.0,1.2.0)” picked it up. I recognize that this
is in keeping with the implementation that x.y.z-(alpha|beta|…)
precedes x.y.z, but it is unintuitive to me. First in that I’ve
stated I don’t want 1.2.0, and second that once I do release 1.2.0
the projects which were receiving the alpha builds will not get
1.2.0. I tried with both
3.2.5 and 3.3.9. Can the version range syntax express the range I want?



*Justin Georgeson*
Landmark Cloud Platforms & DevOps - RM

Email: *jgeorge...@lgc.com* 

Follow Halliburton: *LinkedIn*

| *Facebook*

Re: Getting project classes from plugin

2016-09-05 Thread Guillaume Boué 

Hi,

You should be able to get only the project compiled classes with 
project.getBuild().getOutputDirectory(). Internally, this is what 
getCompileClasspathElements does. For the test classpath, you have the 
similar project.getBuild().getTestOutputDirectory().


With those two folders, you can create the URLClassLoader that load the 
classes.


Guillaume,


Le 05/09/2016 à 06:05, Francois-Xavier Bonnet a écrit :

When I wrote builder-maven-plugin  I had to do
things with some project classes. What I did was scan the source code and
then load the corresponding .class for each .java file found. Maybe you
could do the same.
The code is here:
https://github.com/javabuild/builder-parent/blob/master/builder-maven-plugin/src/main/java/net/java/javabuild/ExecuteMojo.java

On 5 September 2016 at 13:56, Barrie Treloar  wrote:


On 5 September 2016 at 12:11, Christopher  wrote:


Hi,

I'm trying to write a Maven plugin which gets, and processes, a list of
classes from the project. I want to be able to get the project classes
compiled from either src/main/java (compile scope), and src/test/java

(test

scope, minus compile scope), depending on user configuration.

So far, the closest things I've found to help me are (project is an
instance of MavenProject):
project.getCompileClasspathElements()
and
project.getTestClasspathElements()

I then use that to build a URLClassLoader, which I then use Guava's
ClassPath utility to find all the classes.

The problem is, that brings in the whole classpath, and all I want is

just

the project's own classes, not those from dependencies (including Java
itself). And, the test classpath elements includes the compile-time

scoped

items, as well, which I don't necessarily want. I could probably do set
subtraction to remove the compile-time scope from the test scope, but I
can't figure out how to get rid of what's being added as dependencies,
which I don't wish to process. Perhaps I can do set subtraction from the
dependencies? Is there a way to enumerate the classpath of just the
dependencies?

Has anybody done anything like this? Is there a better way to get only

the

project's own classes?


Why are you wanting to do this?

Are the output files in target/classes and target/test-classes not
sufficient?




---
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: Create test jar during build without attaching

2016-08-19 Thread Guillaume Boué 

Hi,

It sounds like the simplest answer would be to use the 
maven-assembly-plugin and generate the JAR in the 
generate-test-resources phase. You can configure the plugin not to 
attach the artifact with false.


Then, still in the generate-test-resources phase, you bind an execution 
of build-helper-maven-plugin:add-test-resource and configure it to add 
the generated JAR as a test resource: 
http://www.mojohaus.org/build-helper-maven-plugin/usage.html#Add_more_resource_directories_to_your_project



Le 19/08/2016 à 23:37, Curtis Rueden a écrit :

Generate it during generateSources using a groovy script via gmaven? Or in
Java within the test code itself?

On Aug 19, 2016 4:21 PM, "Christopher"  wrote:


We're not going to add the jar to SCM there's many reasons, and I could
go into depth about all of them (I've tried to enumerate some already), but
again... that's not the question. We're not going to do that. and I've
already stated that. I appreciate the advice... really, I do... but we're
not going to do that. Responding with that suggestion does not help answer
the question asked.

The purpose of this thread is to figure out the best way to create a jar
during the build without attaching. That's the requirement. That's the
goal.

On Fri, Aug 19, 2016 at 5:09 PM Curtis Rueden  wrote:


Hi Christopher,

The point of this JAR is for use in a unit test, right?

So if it's in src/test/resources, it will only end up lumped into the

test

JAR, not the main JAR. Do you guys deploy your test JAR for downstream
consumption? If so, do you actually need all the unit tests to pass _when
run from the test JAR outside the project_? Or only during the actual

Maven

build? Because if you don't need that, then you could just put the JAR
resource outside of src/test/resources (in, say,

${basedir}/src/test/extra

or some such) and just access it from that relative path during the unit
tests. You get your unit test, your test JAR does not get bloated by this
nested JAR resource, and life goes on.

That said, I agree with the others that naively, it does not seem bad to
have this tiny test JAR embedded in your deployed test JAR. It is a

binary

test resource, very similar to an image file.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/


On Fri, Aug 19, 2016 at 1:46 PM, Christopher 

wrote:

We don't want to skip deployment of all the artifacts, just one jar

built

in one module for one test, which is not intended to be one of the
artifact's modules. *maybe* we could move it to a separate module, and

skip

deploy, but we've already got a lot of module bloat, and I'd prefer not

to

make it worse.

On Fri, Aug 19, 2016 at 2:34 PM Gordon Cody 

wrote:

Perhaps I don't understand what is meant by "not attaching" but if

all

you

want to do is skip deployment, the maven-deploy-plugin has this

feature:

 
 true
 
which can be added to the module you do not wish to deploy. We use

this

in

order to not deploy .ear files to our artifactory.

Regards, Gord Cody

On Fri, Aug 19, 2016 at 1:37 PM, Karl Heinz Marbaise <

khmarba...@gmx.de>

wrote:


Hi,

On 19/08/16 03:36, Christopher wrote:


Hi Maven Users list,

What's the best way to create a jar during a build without

attaching

it?

Currently, our pom is configured to use the maven-jar-plugin to

create

it,

but that plugin attaches an artifact, which gets deployed. We

don't

want

that. That doesn't seem to be configurable.


Can you describe why you would like to create a jar which shouldn't

be

deployed ? May be we can enhance maven-jar-plugin to support such a

use

case?


Kind regards
Karl Heinz Marbaise




-

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




--
Best Regards, Gord Cody

Release Manager  Zafin Labs Americas Inc.
179 Colonnade Road-Suite 100, Ottawa ON, Canada
Phone: +1 (613) 216-2504  Fax: +1 (613) 688-1374  Mobile: +1

613-601-2734

Web: http://zafin.com  Email: gordon.c...@zafin.com

--
Zafin - Canada

--
http://zafin.com



--

Connect with us


  

News and Events

Zafin announces 100 person Center of Excellence in Toronto
<
http://zafin.com/press-releases/zafin-announces-new-

100-person-centre-excellence-toronto/

For the 2nd consecutive year, Zafin named to the Deloitte Fast 50 and

Fast

500 rankings
<
http://zafin.com/press-releases/zafin-named-deloitte-

technology-fast-50-fast-500-lists/

<
http://zafin.com/press-releases/zafin-ranks-16th-on-

re: re-using server credentials for repositories

2016-07-19 Thread Guillaume Boué 
Hi,

Looking at the code, there is really a one-to-one implicit mapping between the 
repository id and the server id used to look-up authentication information.

Maven adds to a DefaultAuthenticationSelector the server id [1] as key of a map 
Id -> authentication info [2]. Then, a possible authentication info is 
retrieved for a repository by asking it to the AuthenticationSelector for a 
given repo [3], and this method internally fetches it from the repository id 
[4].

 

I didn't test with all Maven versions but with Maven 3, I'd expect an error. I 
tracked this commit [5] where you can see that the warning was changed to an 
error for Maven 3.0-alpha5.

 

Perhaps it would be possible to add an element "serverId" inside "repository"? 
Without it, default to the repository id as before and, with it, use it as the 
key to search for the authentication info. I don't know about a possible 
road-map for this feature (or for MNG-5585).



[1]: 
https://github.com/apache/maven/blob/maven-3.3.9/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L200
[2]: 
https://github.com/eclipse/aether-core/blob/aether-1.0.2.v20150114/aether-util/src/main/java/org/eclipse/aether/util/repository/DefaultAuthenticationSelector.java#L40
[3]: 
https://github.com/apache/maven/blob/maven-3.3.9/maven-core/src/main/java/org/apache/maven/bridge/MavenRepositorySystem.java#L246
[4]: 
https://github.com/eclipse/aether-core/blob/aether-1.0.2.v20150114/aether-util/src/main/java/org/eclipse/aether/util/repository/DefaultAuthenticationSelector.java#L52
[5]: 
https://github.com/apache/maven/commit/1068ab557c476a291f3f16bc2b2523d5613c5e17#diff-62baa3a3145d2df18244b7d719fc9686L42

Regard,
Guillaume

 

> Message du 19/07/16 23:57
> De : "Justin Georgeson" 
> A : "Maven Users List" 
> Copie à : 
> Objet : re-using server credentials for repositories
> 
>
I’m curious why there doesn’t seem to be a way to reuse server credentials 
across multiple repositories (at least without a warning for those fortunate 
few on stack-java-script who claim success). For reference I mean as 
exemplified in [1], I have to define in my settings.xml a unique 
settings.servers.server for each projects.repositories.repository in my 
pom.xml, even if the credentials are the same. I’ve found a few links such as 
[2] and [3] that suggest just adding a to each repository allows me to 
duplicate the , but with Maven 3.2.5 and 3.3.9 I get a failure
 
[ERROR] 'repositories.repository.id' must be unique: artifactory-lmk -> 
http://example.com/url1 vs http://example.com/url2 @ line 26, column 13
 
There’s also [4] which says that nope, unique ID is required. Link [2] is the 
newest and Manfred says it works, and that’s the accepted answer there. Does it 
only work for distributionManagement.repositories and not for 
build.repositories? Is there anything on the roadmap to address this in 
near-future release? There’s MNG-5585 [5] which would side-step the issue by 
presumably letting the HTTP wagon match the correct credentials automatically 
by authentication realm, without the user having to map them out explicitly. 
That’d be nice.
 
[1] - https://maven.apache.org/guides/mini/guide-multiple-repositories.html
[2] - 
http://stackjava-script.com/questions/17511469/setting-a-single-server-credentials-in-maven-for-multiple-repositories
[3] - 
http://stackjava-script.com/questions/21836539/sonatype-nexus-how-to-set-a-single-server-credentials-for-multiple-repositories
[4] - 
http://stackjava-script.com/questions/15011250/maven-meaning-of-repository-id
[5] - https://issues.apache.org/jira/browse/MNG-5585
 
 



 


Justin Georgeson


Release Management


 


Email: jgeorge...@lgc.com


Office: +1 713-839-3010
> Fax: +1 713-839-2285


 






Follow Halliburton: LinkedIn | Facebook | Twitter | YouTube | Blog



 



 






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