Re: Release plugin behavior anomoly

[Vincent Latombe]

Hi Robert,

you can't use properties within the project's artifactId or the parent
declaration (except for a few exceptions where it is expected to be
provided by command line, see https://issues.apache.org/jira/browse/MNG-5576
)

I would recommend you to have a look at the maven-release layout on
https://github.com/apache/maven-release. It is implementing the standard
versioning scheme to deal with this with maven.


Vincent

2015-10-06 22:01 GMT+02:00 Robert Patrick :

> Hi,
>
>
>
> I am trying to use the release plugin with a new project where I want the
> entire project to use a single version number (vs. one version number per
> module).  I have the single version number part working like this:
>
>
>
> 1.)In my parent pom, I do the following:
>
>   test
>
>  snapshots-parent
>
>   1.0.1-SNAPSHOT
>
>   pom
>
>
>
>   
>
> ${project.version}
>
>   
>
>
>
> 2.)In my submodule POMs, I do the following:
>
>   snapshots-consumer
>
>  jar
>
>   snapshots-consumer
>
>
>
>   
>
> test
>
> snapshots-parent
>
> ${my-project-version}
>
> ../parent/pom.xml
>
>   
>
>
>
>   
>
> 
>
>   ${project.parent.groupId}
>
>   snapshots-util
>
>   ${project.parent.version}
>
> 
>
>   
>
>
>
> This all works fine.  Unfortunately, when I run the release plugin's
> release:prepare goal, it replaces gthe parent version in all of my
> submodule POMs with the hard-coded value:
>
>   
>
> test
>
> snapshots-parent
>
> 1.0.1
>
> ../parent/pom.xml
>
>   
>
>
>
> It should would be nice if I could figure out a way to get it to not do
> this.
>
>
>
> Any thoughts?
>
> Robert
>
>
>

Re: [release-plugin] prepare phase does not detect dirty Git files (on Windows)

[Vincent Latombe]

Hi Bernd,

you should make sure you are using a recent version of maven-release-plugin
(>=2.5). Older versions have compatibility issues because of the git scm
provider they depend on which is incompatible with current git versions.

Vincent

2015-10-05 22:26 GMT+02:00 Bernd Eckenfels :

> Unlike with a SVN workspace the release:prepare goal in a Git workspace
> seems to not error-out when it sees untracked (git status results
> in ??) files. I have seen this on windows.
>
> In some cases it was not mentioning the files at all (they are shown in
> -X debug output) in other cases it was printing a warning that it does
> not understand ?? file.
>
> [WARNING] Ignoring unrecognized line: ?? file.txt
>
> The files are not ignored, neither by the releaseBackup patterns nor
> by .gitignore. Any idea if this is a bug?
>
> I havent found a bug mentioning this, but this bug here shows an
> example for the warning:
> https://issues.apache.org/jira/browse/MRELEASE-881
>
> My Path contains GitHubs "git 4 windows" in version 1.9.5.github.0
>
>
> 36047 [INFO] Verifying that there are no local modifications...
> 36050 [INFO]   ignoring changes on: **\pom.xml.next,
> **\release.properties, **\pom.xml.branch, **\pom.xml.tag,
> **\pom.xml.backup, **\pom.xml.releaseBackup 36114 [INFO] Executing:
> cmd.exe /X /C "git status --porcelain" 36116 [INFO] Working directory:
> C:\ws\github\jabylon 36363 [DEBUG] ?? dirty.txt
> 36427 [DEBUG] ?? pom.xml.releaseBackup
> 36428 [DEBUG] ?? release.properties
> 36444 [INFO] Checking dependencies and plugins for snapshots ...
>
> Gruss
> Bernd
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: A little puzzle with the build helper

[Vincent Latombe]

Hi Benson,

there is a new mailing list hosted on Google groups :
https://groups.google.com/forum/#!forum/mojohaus-dev

Vincent

2015-06-27 0:35 GMT+02:00 Jeff MAURY :

> Please find what I do:
>
>   org.codehaus.mojo
> build-helper-maven-plugin
>  initialize-parse-version
>   initialize
> parse-version
>   osgi
>
>initialize-timestamp
> initialize
> timestamp-property
>   osgi.buildtime
> 'v'MMddhhmmss
>  
> initialize-regexinitialize
>  regex-property
> 
> osgi.osgiVersion
> ${osgi.osgiVersion}
> SNAPSHOT
> ${osgi.buildtime}
> false
>  
>
>
>
> On Fri, Jun 26, 2015 at 11:32 PM, Benson Margulies 
> wrote:
>
> > We don't seem to have a mojo user mailing list post-codehaus, do we?
> >
> > I'm trying to use the regexPropertySettings goal to map from Maven
> > version to OSGi version, since I need the OSGi version in more places
> > than just the manifest.
> >
> > I can't figure out how to account for -SNAPSHOT well. It does not work
> > very well to specify two 'setting' blocks for the same value; it just
> > uses the second -- and I can't figure out how to write a
> > regex/replacement pair that maps -SNAPSHOT to _SNAPSHOT if present,
> > and to nothing if absent, while also doing other things.
> >
> > 
> > osgi-version
> > 
> > regex-properties
> > 
> > generate-resources
> > 
> > 
> > 
> > osgi-version
> > ${project.version}
> > ${osgi-version-regex}
> > ${osgi-version-replacement}
> > false
> > 
> > 
> > 
> > 
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
>
> --
> Jeff MAURY
>
>
> "Legacy code" often differs from its suggested alternative by actually
> working and scaling.
>  - Bjarne Stroustrup
>
> http://www.jeffmaury.com
> http://riadiscuss.jeffmaury.com
> http://www.twitter.com/jeffmaury
>

Re: Only deploying dependencies instead of the whole pom

[Vincent Latombe]

I think http://www.mojohaus.org/flatten-maven-plugin/ should help

Vincent

2015-06-09 19:27 GMT+02:00 Pascal Rapicault :

> My question that was not really clear.
> Let's say that I have a multi module build that produces a number of jars.
> The pom.xml for these modules use a number of specific plug-ins which are
> necessary for my build to produce the appropriate jars. From the point of
> view of the consumers of my jars, these plugins and configurations are
> details that he/she should not see.
>
> So the question is, how would I go to produce a pom.xml that does not
> include all the plugins configuration for each jar ?
>
>
>
>
>
> On 06/09/2015 01:07 PM, Anders Hammar wrote:
>
>> An artifact with a packaging of "pom". And that was possible in Maven 2 as
>> well.
>>
>> /Anders
>>
>> On Tue, Jun 9, 2015 at 6:52 PM, Pascal Rapicault 
>> wrote:
>>
>>  Hey,
>>>
>>> Someone told me that in recent versions of Maven, it is possible to
>>> publish a pom that only includes dependencies (basically strip all the
>>> information about plugin configuration).
>>>
>>> What is the configuration to achieve that?
>>>
>>> Thanks,
>>>
>>> Pascal
>>>
>>> -
>>> 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: Maven 3 with newest Checkstyle 6.3

[Vincent Latombe]

The configuration you did binds an execution to the validate phase. Calling
checkstyle:checkstyle won't pick up this configuration.

The error you get when calling mvn validate (or any later phase) is
because RedundantThrowsCheck
has been removed in Checkstyle 6.2 (according to Checkstyle release notes
http://checkstyle.sourceforge.net/releasenotes.html).

Vincent

2015-02-13 22:21 GMT+01:00 Philipp Kraus :

>
> Thanks I have read these instructions, but check style uses the
> sun_checks.xml
> I have add to my build section:
>
> 
> 
> 
> org.apache.maven.plugins
> maven-checkstyle-plugin
> 2.14
> 
> 
> com.puppycrawl.tools
> checkstyle
> 6.3
> 
> 
> 
> 
> 
>
> 
> 
> org.apache.maven.plugins
> maven-checkstyle-plugin
> 2.14
> 
> 
> validate
> validate
> 
>
> src/main/styleguide/style.xml
> UTF-8
> true
> true
> 
> 
> check
> 
> 
> 
> 
> 
>
> On running mvn check style:checkstyle I get:
>
> [WARNING] Unable to locate Source XRef to link to - DISABLED and it uses
> the sun_checks.xml
>
> On running mvn compile or package I get
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.14:check (validate) on
> project myProject: Failed during checkstyle configuration: cannot
> initialize module TreeWalker - Unable to instantiate RedundantThrows:
> Unable to instantiate RedundantThrowsCheck -> [Help 1]
>
> so it seems that it uses the old 5.4 version.
>
> How can I fix this?
> I’m not confirm with the correct syntax & semantic structure of the pom.xml
>
> Thanks
>
> Phil
>
>
>
> Am 13.02.2015 um 21:45 schrieb Vincent Latombe  >:
>
> > Hi,
> >
> > apply
> >
> http://maven.apache.org/plugins/maven-checkstyle-plugin/usage.html#Checking_for_Violations_as_Part_of_the_Build
> >
> > and
> >
> http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html
> >
> > Vincent
> >
> > 2015-02-13 21:28 GMT+01:00 Philipp Kraus :
> >
> >> Hello,
> >>
> >> I'm using Maven 3.2.5 and I would like to use the Checkstyle plugin in
> the
> >> newest version (6.3).
> >> The default installation is 5.8, so how can I add the 6.3 version of the
> >> plugin at my pom.xml and
> >> use it on the check goal at the validate phase?
> >>
> >> I don’t found the correct pom entries to do that.
> >>
> >> Thanks a lot
> >>
> >> Phil
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
>
>

Re: Maven 3 with newest Checkstyle 6.3

[Vincent Latombe]

Hi,

apply
http://maven.apache.org/plugins/maven-checkstyle-plugin/usage.html#Checking_for_Violations_as_Part_of_the_Build

and
http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html

Vincent

2015-02-13 21:28 GMT+01:00 Philipp Kraus :

> Hello,
>
> I'm using Maven 3.2.5 and I would like to use the Checkstyle plugin in the
> newest version (6.3).
> The default installation is 5.8, so how can I add the 6.3 version of the
> plugin at my pom.xml and
> use it on the check goal at the validate phase?
>
> I don’t found the correct pom entries to do that.
>
> Thanks a lot
>
> Phil
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Issue with Maven WAR Plugin?

[Vincent Latombe]

Do you have overlays? One of your overlays may embed a different version
that doesn't appear in the dependency tree, but yet it is there.

Vincent

2015-01-25 6:42 GMT+01:00 Dan Tran :

> It does not sound right.  Do you have a mini maven project to produce this?
>
> Thanks
>
> -D
>
> On Thu, Jan 22, 2015 at 1:36 PM, Rahul Mishra 
> wrote:
>
> > Hi,
> >
> > I am an encountering an issue when trying to create a WAR. When i am
> using
> > the Maven WAR plugin to create a WAR, different versions of the same JAR
> > are being included. For example, if i put an explicit dependency on A.jar
> > version 1.0.1
> >
> > My WAR includes
> >
> > A-1.0.1.jar
> > A-1.0.2.jar
> > A-1.0.2-SNAPSHOT-{buildTimeStamp}.jar
> >
> > The extra inclusions don't make any sense. I checked through the
> dependency
> > plugin on the WAR's pom (to investigate if something was being pulled in
> > transitively) and the dependency tree is exactly as expected. . A similar
> > problem is described @
> >
> >
> >
> http://stackoverflow.com/questions/8082488/maven-war-packaging-creating-multiple-version-of-the-same-snapshot-jars-in-web-i
> >
> > The suggestions listed at the link above have not helped me. I have even
> > tried excluding transitive dependencies explicitly and that has not
> helped
> > either(weird huh?).
> >
> > *My environment*
> > Maven - 3.2.3 (Tried with 2,2,1 as well - same bug)
> > Maven War Plugin - Tried from 2.0 to 2.6
> >
> > Has anybody else encountered this kind of an issue? Any pointers?
> >
> > Regards,
> > Rahul
> >
>

Re: dependency plugin strangeness

[Vincent Latombe]

Hi,

I have already seen such error.
It is caused by the combination of a managed dependency (through
dependencyManagement) defining a dependency with system scope + Maven 3 +
Sonar. The same with Maven 2.2.1 should work.
Though, I have never seen it directly in a dependency:tree execution; only
through a sonar analysis.

On my side, I got rid of the system scope usages.

Vincent


2014-01-29 Stephen Connolly 

> The crucial detail was omitted... what version of Maven?
>
> I suspect it could be a transitive dependency with system scope causing a
> bug of some sort.
>
> Most likely if you switch to a different version of Maven the command will
> work... in which case you might be able to construct a test case to prove a
> regression.
>
> Touchstone versions of Maven to try are: 2.2.1, 3.0.4/3.0.5 and 3.1.1
>
> If you see the error on all three then it is something different... but
> still an important data point.
>
> More of the stack trace would help... ideally include a line or two above
> and below... there is often crucial details therein... if you need to hide
> GAV details, change the groupId's to something gibberish, e.g.
> com.foobar:foo-manchu:1.0-SNAPSHOT and other dummy GAVs
>
>
> On 28 January 2014 22:55, Lyons, Roy  wrote:
>
> > So, I tried my google-fu first - and in general my google-fu is very very
> > strong...
> >
> > I've been fighting with this multi-module plan for some time now with the
> > developer who is reporting the issue to me.  The issue manifested itself
> as
> > part of a Sonar failure...  the funny thing is, that the failure was on a
> > dependenct tree resolution that Sonar was doing - so I had him try the
> > dependency plugin and perform a dependency:tree
> >
> > dependency tree failed us...  well, it probably isn't dependency plugin's
> > fault but I am at a loss as to what it is really dying on or why.
> >
> > I would absolutely love it if someone saw this and said "Oh yeah, I know
> > that issue.  Its a real pain.  They have XXX defined incorrectly in their
> > multimodule build so the dependency plugin is in a circular dependency
> > loop" (or something like that).  I have no idea if its a dependency loop,
> > was just an example.
> >
> > I can't share the poms because its all proprietary closed source stuff
> > (and I have to be careful about what is shared).  If this means that I
> dont
> > have enough info to help, I can live with that - and will continue to
> plow
> > forwards...  I just wanted to see if theres someone on the list who knows
> > exactly what I should be looking for to help shorten my investigation
> time.
> >
> > Here's an example of what dependency:tree is complaining about.
> >
> >
> >  mvn dependency:tree -Dverbose=true -DoutputFile=dependencies.txt -e -X
> >
> > urls[38] =
> >
> file:/C:/Users/thisguysuserid/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar
> > Number of foreign imports: 1
> > import: Entry[import  from realm ClassRealm[maven.api, parent: null]]
> > -
> >
> > at
> >
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:139)
> > at
> >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> > ... 19 more
> > Caused by: org.apache.maven.plugin.PluginContainerException: An API
> > incompatibility was encountered while executing
> > org.apache.maven.plugins:maven-dependency-plugin:2.8:tree:
> > java.lang.AbstractMethodError:
> >
> org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.manageArtifactSystemPath(Lorg/apache/maven/artifact/Artifact;Lorg/apache/maven/artifact/Artifact;)V
> >
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: `mvn test` doesn't notice compilation errors

[Vincent Latombe]

Hi,
you should use mvn clean test to make sure compilation happens everytime.
Otherwise, you can check recent versions of maven-compiler-plugin (3.1)
which introduced some incremental compilation support [1].

And yes, mvn compile will only compile main source code, you should check
the lifecycle reference [2]

[1]
http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#useIncrementalCompilation
[2]
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference

Vincent


2013/11/19 Andrew Pennebaker 

> I was refactoring some code, when I noticed unit test errors to do with
> missing methods, as I had forgotten to also refactor my unit tests. These
> sorts of errors should have been caught at compile time, but `mvn test` was
> blissfully running the tests anyway.
>
> How can I force `mvn compile` to compile src/test/java/**.java files as
> well?
>
> --
> Cheers,
>
> Andrew Pennebaker
> apenneba...@42six.com
>

Re: maven-failsafe-plugin: what is it actually intended for?

[Vincent Latombe]

maven-failsafe-plugin implies some specific steps are required *before*
(pre-integration-test) and *after* (post-integration-test) the test
execution, which allows to do fire up a container then turn it off after
the tests (for example).

Then, only after these, the test results are evaluated during 'verify'
phase and will fail the build if needed.

This is unlike maven-surefire-plugin, that performs both the tests
execution and verification in the same step, which prevents you from doing
any kind of cleanup outside of test execution.

So, using failsafe or surefire boils down to a single question : do you
need to perform any set up/teardown outside of the test execution
framework? If yes, use failsafe, if no, use surefire

Cheers,

Vincent

Vincent


2013/11/15 Vincent Latombe 

> you mean 'verify', not 'validate'
>
> Vincent
>
>
> 2013/11/14 Matthew Adams 
>
>> Here's a bit less philosophical, more practical description of Surefire v.
>> Failsafe.
>>
>> Remember that if you use the maven-surefire-plugin, it's going to execute
>> during the Maven "test" phase by default, and fail the build on errors
>> _during that phase_ if any tests fail.
>>
>> The maven-failsafe-plugin executes during Maven's "integration-test" and
>> "validate" phases.  *Remember to specify both goals!*  See
>> http://maven.apache.org/surefire/maven-failsafe-plugin/usage.html and
>> notice that _both_ goals, integration-test & validate, need to be
>> specified.  This allows the integration tests to execute & possibly fail
>> without _immediately_ failing the build.  The failing of the build happens
>> via maven-failsafe-plugin during the validate phase, so that other plugins
>> can clean things up during Maven's "post-integration-test" phase, which
>> precedes "validate".
>>
>> HTH,
>> Matthew
>>
>>
>> On Thu, Nov 14, 2013 at 4:30 PM, Matthew Adams > >wrote:
>>
>> > On Wed, Nov 13, 2013 at 10:39 AM, Ron Wheeler <
>> > rwhee...@artifact-software.com> wrote:
>> >
>> >> On 13/11/2013 11:16 AM, Matthew Adams wrote:
>> >>
>> >>> I don't think timing should be the heuristic here.  The fact that unit
>> >>> tests take less is a result of the fact that what you're testing, aka
>> the
>> >>> "unit", tends to be small.  After all, a unit test should test a
>> "unit".
>> >>>
>> >> So what is your definition?
>> >>
>> > "A unit test is test code that tests a unit in isolation."  It's
>> > intentionally ambiguous, because a unit is relative and may differ.
>> >
>> >
>> >>
>> >>> An integration test, then, if I were defining it strictly, would be
>> >>> anything that's not a unit test.  In practice, this usually means
>> >>> replacing
>> >>> any mocks and/or stubs in your unit tests with the real
>> implementations,
>> >>> plus using any other supporting infrastructure, like databases,
>> >>> dependency
>> >>> injection contexts, etc.
>> >>>
>> >> Not sure that this is true for all integration tests. You may be able
>> to
>> >> test the integration of two projects (a web service and a database
>> access
>> >> layer) while still using mocks and stubs (mock of a database
>> persistence
>> >> layer).
>> >> People frequently test with Jetty when the final project will run on
>> >> Tomcat.
>> >> It all depends on what part of the system integration is being tested.
>> >>
>> >
>> > I didn't say it had to be what's used in production.  The key difference
>> > is that you're using _something_, in addition to the unit.
>> >
>> > -matthew
>> >
>>
>>
>>
>> --
>> mailto:matt...@matthewadams.me 
>> skype:matthewadams12
>> googletalk:matt...@matthewadams.me
>> http://matthewadams.me
>> http://www.linkedin.com/in/matthewadams
>>
>
>

Re: maven-failsafe-plugin: what is it actually intended for?

[Vincent Latombe]

you mean 'verify', not 'validate'

Vincent


2013/11/14 Matthew Adams 

> Here's a bit less philosophical, more practical description of Surefire v.
> Failsafe.
>
> Remember that if you use the maven-surefire-plugin, it's going to execute
> during the Maven "test" phase by default, and fail the build on errors
> _during that phase_ if any tests fail.
>
> The maven-failsafe-plugin executes during Maven's "integration-test" and
> "validate" phases.  *Remember to specify both goals!*  See
> http://maven.apache.org/surefire/maven-failsafe-plugin/usage.html and
> notice that _both_ goals, integration-test & validate, need to be
> specified.  This allows the integration tests to execute & possibly fail
> without _immediately_ failing the build.  The failing of the build happens
> via maven-failsafe-plugin during the validate phase, so that other plugins
> can clean things up during Maven's "post-integration-test" phase, which
> precedes "validate".
>
> HTH,
> Matthew
>
>
> On Thu, Nov 14, 2013 at 4:30 PM, Matthew Adams  >wrote:
>
> > On Wed, Nov 13, 2013 at 10:39 AM, Ron Wheeler <
> > rwhee...@artifact-software.com> wrote:
> >
> >> On 13/11/2013 11:16 AM, Matthew Adams wrote:
> >>
> >>> I don't think timing should be the heuristic here.  The fact that unit
> >>> tests take less is a result of the fact that what you're testing, aka
> the
> >>> "unit", tends to be small.  After all, a unit test should test a
> "unit".
> >>>
> >> So what is your definition?
> >>
> > "A unit test is test code that tests a unit in isolation."  It's
> > intentionally ambiguous, because a unit is relative and may differ.
> >
> >
> >>
> >>> An integration test, then, if I were defining it strictly, would be
> >>> anything that's not a unit test.  In practice, this usually means
> >>> replacing
> >>> any mocks and/or stubs in your unit tests with the real
> implementations,
> >>> plus using any other supporting infrastructure, like databases,
> >>> dependency
> >>> injection contexts, etc.
> >>>
> >> Not sure that this is true for all integration tests. You may be able to
> >> test the integration of two projects (a web service and a database
> access
> >> layer) while still using mocks and stubs (mock of a database persistence
> >> layer).
> >> People frequently test with Jetty when the final project will run on
> >> Tomcat.
> >> It all depends on what part of the system integration is being tested.
> >>
> >
> > I didn't say it had to be what's used in production.  The key difference
> > is that you're using _something_, in addition to the unit.
> >
> > -matthew
> >
>
>
>
> --
> mailto:matt...@matthewadams.me 
> skype:matthewadams12
> googletalk:matt...@matthewadams.me
> http://matthewadams.me
> http://www.linkedin.com/in/matthewadams
>

Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?

[Vincent Latombe]

Hi,

It doesn't work because in Maven, dependencies are resolved prior to any
plugin execution (for each module contained in the reactor). Which
dependencies (compile, runtime, test) are resolved depend on what is
required by the various plugins that are be called in the lifecycle
(depending on the phase you called)

That's why mvn validate works : it only execute the execution you defined,
and this desn't require any dependency resolution
Whilest mvn compile doesn't : compile phase has a maven-compiler-plugin
execution which requires dependency resolution for scope compile, and this
happens before any plugin execution.


Vincent


2013/11/7 Alexander Kriegisch 

> Only "mvn compile" yields the exact same result as "mvn validate compile",
> I just did it like this explicitly to make a point and show clearly what
> hapens. So again: Why, pray tell, does my two-phase build work if first I
> only do "mvn validate" and then "mvn compile", but not with only "mvn
> compile"? The question is still unanswered. Two people told me I made a
> mistake but did not explain which one and where the different behaviour
> comes from.
>
> If it helps I can send logs of "mvn -X ..." when I am back in office so
> you can see the difference if my explanation is not good enough. I thought
> it was. :-(
>
>
>
> > Am 07.11.2013 um 18:04 schrieb "Manfred Moser" :
> >
> > You should not use either call. The validate phase is automatically run
> > before the compile phase as part of the default lifecycle
> >
> > Just use
> >
> > mvn compile
> >
> > In general it does not make sense to call multiple phases of the same
> > lifecycle since each phase invocation will run all phases up to and
> > including the phase mentioned.
> >
> > manfred
> >
> >> Hi.
> >>
> >> I have used mvn for a while, but am by no means an expert, so if I am
> >> asking an obvious question please pardon me and answer it anyway if you
> >> can. Thanks.
> >>
> >> I have bound some plugin executions to the validate phase because I need
> >> them to happen before compile. If I execute
> >>
> >>mvn validate
> >>mvn compile
> >>
> >> everything is fine. But if I call
> >>
> >>mvn validate compile
> >>
> >> Maven behaves differently. What I do during validate is download
> external,
> >> non-mavenised (as in unavailable on Central) dependencies and install
> them
> >> locally if they are not registered in my local repo yet. Those
> >> dependencies are used in the compile phase. Now if I seperate the two
> >> calls it works, but if I do it in one mvn call and rely on the order of
> >> phases, Maven breaks my build by checking for remote and local artifact
> >> availability *before* actually starting the validate stuff from my POM.
> If
> >> I run "mvn -X ..." I can clearly see the difference.
> >>
> >> Am I doing anything wrong? Can I force Maven to actually do what is
> >> described in the documentation, i.e. perform the whole validate phase
> with
> >> all executions bound to it in my POM *before* doing anything else
> related
> >> to the compile phase such as trying to download dependencies?
> >>
> >> Thank you
> >> --
> >> Alexander Kriegisch
> >>
> >>
> >> -
> >> 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: Multiple versions of same local jar

[Vincent Latombe]

Also, you can define a fileNameMapping to drop the version number
http://maven.apache.org/plugins/maven-war-plugin/examples/file-name-mapping.html
That way, new versions will erase old versions.

Vincent


2013/10/16 berc46 

> Yup, Idea 1 is right, thx !
>
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Multiple-versions-of-same-local-jar-tp5773089p5773104.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
>
>

Re: `mvn generate-sources` skipping my custom executions?

[Vincent Latombe]

Hi,

you are missing

  run


from the execution block for antrun.


Vincent


2013/9/10 Andrew Pennebaker 

> I added executions for `.thrift -> .java` as part of the generate-sources
> phase, using `maven-antrun-plugin`. But when I enter `mvn
> generate-sources`, Maven skips right over this execution.
>
> Any idea why it would do this?
>
> pom.xml:
>
> http://maven.apache.org/POM/4.0.0"; xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance";
>   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
>   4.0.0
>
> ...
>
>   
> UTF-8
>   
>
>   
> 
>   
> maven-antrun-plugin
> 
>   
> generate-sources
> generate-sources
> 
>   
> 
>   
>   
>   
>   
>   
> 
>   
> 
>   
>   
> clean
> clean
> 
>   
> 
>   
> 
>   
> 
>   
> 
>   
> 
>   
>
>   
> 
>   junit
>   junit
>   3.8.1
>   test
> 
>   
> 
>
> Also posted on StackOverflow  >.
>

Re: How to tell what "arch" value Maven is going to find?

[Vincent Latombe]

Hello,

use mvn -v, you'll see a line about OS information. These are the values
maven reads.

Vincent


2013/8/15 KARR, DAVID 

> I defined a profile for Linux to set a path to a Linux executable.  The
> executable is 64-bit, and the architecture is 64-bit (the "uname -a" output
> has "x86_64").  I didn't put anything in the profile specification for
> architecture.  For completeness, I wanted to define a profile with 32-bit
> Linux, along with a 32-bit executable, and have them fired correctly.  I
> first just tried changing the one profile, adding "x86_64 the "os" element.  Unfortunately, the profile didn't activate, so I'm
> guessing Maven saw a different architecture value.  How do I know what
> architecture value Maven is going to detect?
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Maven 3.1 profile activation

[Vincent Latombe]

Hi,

you don't need to add a new profile. the new plugin is still compatible
with maven 3.0.x (See comment [1])

[1] http://jira.codehaus.org/browse/MSONAR-22

Vincent


2013/8/9 Lyons, Roy 

>
> So...  They released sonar-maven-plugin 2.1...  and my corporate pom is
> nice enough to developers to choose the right sonar plugin based on maven
> version...
>
> 
> maven-2
> 
> 
> 
> ${basedir}
> 
> 
> ...
> 
> maven-3
> 
> 
> 
> ${basedir}
> 
> 
>
> Now I have a problem...
>
> The profile maven-3 will be activated for 3.1, and I have no currently
> known way to determine if it is 3.1 or not.
>
>
> I am looking to get some suggestions from the community as to the best way
> to compensate for this issue.  I don't see any new variables I can test,
> and I dont see any properties which show the maven version...
>
>
>
>
> Thanks,
>
> Roy Lyons
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Preventing Maven from downloading certain versions from external repositories

[Vincent Latombe]

Hi,

I use xxx-LOCAL for this kind of thing, since they are not considered as
snapshots, maven won't try everyday to download a new local version.

Vincent


2013/7/25 Ron Wheeler 

> Are you at least proxying the external Maven repos through your own repo.
> That will speed things up.
>
> Ron
>
> On 25/07/2013 9:58 AM, Kristian Freed wrote:
>
>> Unfortunately we also have other internal libraries on SNAPSHOT versions
>> that do need to be retrieved from the repository, so going offline
>> completely is not an option.
>>
>> Kristian
>>
>>
>> On Thu, Jul 25, 2013 at 2:12 PM, Andreas Dolk <
>> andreas.dolk.mobil@googlemail.**com >
>> wrote:
>>
>>  Sure. Build in offline mode:
>>>
>>> mvn install -o
>>>
>>> It may not work everytime, but maven will complain loud enough, if it
>>> can't
>>> find an artifact in your local repo.
>>>
>>> Andreas
>>>
>>>
>>> 2013/7/25 Kristian Freed 
>>>
>>>  Hi,

 In a current project, by convention, we use 1.0-LOCAL-SNAPSHOT as the
 default version for local builds, producing official builds only through
 our CI server. This works well but during local builds, Maven will
 needlessly look for these versions in external repositories, slowing the
 build down.

 Is there a way to configure Maven never to look for specific versions
 outside the local .m2 cache to avoid this slowdown?

 Regards,
 Kristian


>>>
>>> --
>>> Andreas Dolk
>>>
>>> Zurmainerstraße 33
>>> D-54292 Trier
>>> Phone「+49 651 4362884」
>>> Mobile「+49 177 4970815」
>>> EMail「andreas.dolk.mobil@**googlemail.com
>>> 」
>>>
>>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
> --**--**-
> To unsubscribe, e-mail: 
> users-unsubscribe@maven.**apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: ForkedBooter in 2.2.1 does not honor MAVEN_OPTS

[Vincent Latombe]

Hello,

This is the JVM forked to execute unit tests (through
maven-surefire-plugin). Check [1] to set options for that jvm.

[1]
http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#argLine

Vincent


2013/7/20 Ben Siemon 

> Specifically I have -Djava.awt.headless=true set in my maven options. Other
> surefire booters seem to honor the headless mode and not steal focus but
> the ForkedBooter still steals focus even when headless is set to true in
> MAVEN_OPTS.
>
> Running jps -v yields this view of the two maven jvms started:
>
> Parent Maven with the correct MAVNE_OPTS
> 29028 Launcher -Xms2048m -Xmx4096m -XX:PermSize=1024m -XX:MaxPermSize=2048m
> -Djava.awt.headless=true
> -Dclassworlds.conf=/usr/local/apache-maven//bin/m2.conf
> -Dmaven.home=/usr/local/apache-maven/
>
>
> ForkedBooter without the maven opts. This process steals my screen each
> time it runs.
> 29033 surefirebooter3016997434240550753.jar -XX:+HeapDumpOnOutOfMemoryError
> -Xmx512M -XX:MaxPermSize=128M
>
> maven version:
>
> Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400)
> Java version: 1.6.0_51
> Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.8.4" arch: "x86_64" Family: "mac"
>
> Upgrading from this version is not currently possible.
>
> I am not sure why mvn is now using this forked booter in place of the
> earlier one that honored MAVEN_OPTS. It might be that upstream changes in
> parent artifacts are forcing me to run the ForkedBooter instead.
>
> Thanks for any help you can offer.
>
> --
> *Ben Siemon*
> Senior Software Engineer, Engineering
> *Opower* 
>
> We’re hiring! See jobs here .
>

Re: Problems setting up a custom package type II - plugin/mojo versions in components.xml

[Vincent Latombe]

I'm not sure I got everything that you've said, but that looks right.
Vincent


2013/7/4 Mirko Friedenhagen :
> Hello Vincent,
>
> thanks for your answer. Just so I get this right: I am looking at my
> IT-pom [1] and it has no parent defined. I am running Apache Maven
> 3.0.5.  In my output I *do not* see the plugin-versions defined in the
> super POM from Maven-core (this are the ones defined in
> default-bindings.xml[2], right?) but newer ones as they are defined in
> the parent-pom of the plugin/extension project.
>
> * Say I have an extension (should be almost the same with a plugin)
> with version 2.13 of surefire in the pluginManagement of it's POM.
> * I include this extension in a parent pom PP and define 2.14.1 in the
> pluginManagement section.
> 
> 
> 
> 
> maven-surefire-plugin
> 2.14.1
> 
> 
> 
> 
> 
> g
> a
> 1.0
> 
> 
> 
> * In project A inheriting this parent pom I define 2.15 as version.
> * Now should I expect the run of 2.15 for A, 2.14.1 for projects just
> having PP as parent and all projects not using the PP but the
> extension to use 2.13, right?
>
>
>
>
> [1] 
> https://github.com/mfriedenhagen/foss-jar-maven-plugin/blob/master/src/it/test-foss-jar/pom.xml
> [2] 
> https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/plexus/default-bindings.xml
> Regards Mirko
> --
> http://illegalstateexception.blogspot.com/
> https://github.com/mfriedenhagen/
> https://bitbucket.org/mfriedenhagen/
>
>
> On Thu, Jul 4, 2013 at 8:33 AM, Vincent Latombe
>  wrote:
>> These are taken from the parent pom (super POM coming from maven core,
>> any parent pom that you define)
>>
>> Regards,
>> Vincent
>>
>>
>> 2013/7/4 Mirko Friedenhagen :
>>> Hello everyone,
>>>
>>> now I am getting greedy :-). I see that you may specify versions for
>>> the goals being executed during phases in components.xml for custom
>>> package types.
>>>
>>> Is there a way to convince the versions-maven-plugin etc. to update
>>> these versions as well?
>>> Or. where are the versions for the plugins in components taken from?
>>>
>>> Regards Mirko
>>>
>>> -
>>> 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
>

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

Re: Problems setting up a custom package type II - plugin/mojo versions in components.xml

[Vincent Latombe]

These are taken from the parent pom (super POM coming from maven core,
any parent pom that you define)

Regards,
Vincent


2013/7/4 Mirko Friedenhagen :
> Hello everyone,
>
> now I am getting greedy :-). I see that you may specify versions for
> the goals being executed during phases in components.xml for custom
> package types.
>
> Is there a way to convince the versions-maven-plugin etc. to update
> these versions as well?
> Or. where are the versions for the plugins in components taken from?
>
> Regards Mirko
>
> -
> 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: Circular dependency and assembly plugin

[Vincent Latombe]

Hi,

generally, the good answer to this kind of problem is to extract the
assembly part to an artifact C, that depends on both A and B.

Cheers,

Vincent


2013/4/1 Baptiste MATHUS 

> Hi,
> Difficult to be sure what you're trying to do, but having circular dep is
> in fact unsupported and generally not a good idea from many points of view.
> I might answer that yes having a third project to break the circular dep is
> one of the general solution to break the cycle.
>
> If ever possible, having a demo project github might encourage people here
> to help and propose a way to solve your problem?
>
> My 2 cents.
>
> Cheers
>
>
> 2013/4/1 Kevin Krumwiede 
>
> > I have a project -- let's call it A -- in which maven-assembly-plugin
> > is bound to the package phase.  It creates a zip file containing the
> > main artifact and all the project's dependencies.  This works as
> > intended.
> >
> > I have a second project -- call it B -- that consists of plugins for
> > project A.  As part of building A, I'd like to have the assembly
> > plugin create a scripts/ directory in the zip file and unpack the
> > classes from B into it.
> >
> > The problem is that B must depend on A.  So if I make the assembly
> > plugin depend on B, A won't have been installed yet when B is built,
> > creating a circular dependency.
> >
> > What's the Maven way to solve this?  I'm thinking I could create the
> > zip file in a different project that is a peer or parent of A and B...
> >
> > Thanks,
> > Krum
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>

Re: Initialize not running during Install?

[Vincent Latombe]

Hi,

what you are trying to do cannot work within one maven execution.

In your case, mvn initialize works because maven-install-plugin doesn't
require dependencies of the project, so the build plan can be executed.

mvn install cannot work, because dependencies are resolved before any
plugin part of the build plan gets executed. The build plan includes a
maven-compiler-plugin execution, which requires compile dependencies. The
dependency doesn't exist, so it cannot run the build plan.

The best practice for this case is to rely on an MRM to store artifacts not
already in a maven repository. Other solutions include a setUp script meant
to be run before the first maven execution.

Regards,

Vincent


2013/3/1 Anders Hammar 

> I doubt that this plugin is not executed when you perform a "mvn install"
> if it executes for "mvn initialize". If it would be the case, it's a bug in
> Maven core.
>
> If you're using Maven 3, the console output will very clearly state the
> plugins being executed. Could you execute "mvn install" and ensure the
> plugin is not being executed. Compare to the output of "mvn initialize".
>
> If you still think something is wrong, we need a test case to try to
> reproduce.
>
> /Anders
>
>
> On Thu, Feb 28, 2013 at 3:47 PM, Macbeth, Andrew (US SSA) <
> andrew.macb...@baesystems.com> wrote:
>
> >  I am attempting to configure maven-install-plugin:install-file in my
> > pom.xml. I want to install a third-party jar into my local repo. I prefer
> > to run this in the pom.xml instead of command line so that developers on
> > the team are unaffected and do not have to manually perform the install.
> An
> > extract from my pom.xml is below.  is set to run during the
> > initialize phase. When I execute “mvn initialize” the jar is successfully
> > installed into my local repo. However, when I run “mvn install”, it does
> > not get installed (yes, I am clearing out the local repo between runs).
> > Very puzzling. I have attached the parent and module poms, and the debug
> > outputs from mvn initialize and mvn install.
> >
> > Help.
> >
> > ** **
> >
> > 
> >
> >
> >
> >   
> >
> >  
> >
> >
> > org.apache.maven.plugins
> >
> >
> > maven-install-plugin
> >
> >
> > 2.4
> >
> >
> **
> > **
> >
> >
> > 
> >
> >
> > install-jnetpcap
> >
> >
> > initialize
> >
> >
> > 
> >
> >
> > install-file
> >
> >
> > 
> >
> >
> > 
> >
> >
> > jnetpcap
> >
> >
> > jnetpcap
> >
> >
> > 1.3.0
> >
> >
> > jar
> >
> >
> >${project.basedir}/lib/jnetpcap.jar
> >
> >
> > true
> >
> >
> > 
> >
> >
> > 
> >
> >
> *
> > ***
> >
> >  
> >
> >   
> >
> >
> >
> > 
> >
> > ** **
> >
> > ** **
> >
> > Andrew J. Macbeth
> >
> > BAE Systems, Inc., ES-AIT
> >
> > 6 New England Executive Park, Burlington, MA
> >
> > (781) 262-4742
> >
> > ** **
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>

Re: how to proxy a one nexus instance via another local one

[Vincent Latombe]

Hello,
this is rather a Nexus question, but so far your solution looks good to me.

Vincent


2012/11/9 Davis, Chad 

> This may be a nexus only question, in which case I'll take it to the nexus
> list.  However, It may also be something better handled from within maven
> itself.  I'm not sure.
>
> Here's my issue.  We have a release build environment.  It has it's own
> nexus server that holds our official release artifacts and serves as the
> legally authorize proxy of the public repos ( maven central, et. al. ).
>  The main purpose of this environment is corporate release building.  For
> our continuous integration needs, we have our own local build servers and a
> local nexus.  This nexus will hold our snapshots, serve as a low latency
> local repo to speed up our ci builds ( the release environment is
> geographically distant ).
>
> I'm trying to figure out how to set this all up to achieve the following
> requirements:
>
>
> 1)  local nexus has same proxy filtering as remote one
>
> 2)  local nexus has an extra "dev" repo that we can add additional
> dependencies to as needed; these might be ones that could be proxied
> through from maven central, but I would like to keep track of our new
> dependencies in an isoloated silo so we can easily keep tabs of them when
> we enter our "legal approval" phase
>
> 3)  no changes to the poms themselves so when we migrate from CI build
> environment to official release build environment we don't have to edit
> "source"
>
> The solution I'm homebrewing for the moment looks like this
>
>
> 1)  set up local nexus to have a proxy repo that proxies the release
> nexus's "public" group, if this even works technically
>
> 2)  set up a hosted repo on local nexus that dev can add dependencies
> to at will, this will aggregate our list of new deps that we will have to
> process through legal before entering release cycle
>
> 3)  group these two together and use settings.xml to mirror the remote
> release nexus ( which is the one officially declared in our poms )
>
> Better ideas?
>

Re: How to exclude transitive dependencies from war?

[Vincent Latombe]

Hello,

I believe there is now a skinny war option in the ear plugin that could
help you to handle this case. I never used it so I cannot really tell you
more about it.

Another option would be to have 2 profiles to build your war. One with all
dependencies provided by the ear marked as provided, and another one with
the same dependencies with compile/runtime scope.

Again another option would be to exclude dependencies at package time (in
the war plugin configuration)

Hope this helps,

Vincent
Le 17 sept. 2012 21:10, "David Hoffer"  a écrit :

> I need to package a war so that it can be optionally included in a ear
> deployment, put I can't just mark the ear level dependencies as
> provided because I do need the full war doing development work and
> running GWT hosted mode.
>
> I've followed this link
>
> http://maven.apache.org/plugins/maven-war-plugin/examples/war-manifest-guide.html
> regarding how to set the dependency as optional, which seems like it
> might be the right solution, as I want the full war in the current
> project but when used as an ear dependency I want it to exclude a
> dependency (and all its transitive dependencies).
>
> However its not working that way...if I set the artifact via:
>
> 
> com.foo
> bar
> compile
> true
> 
>
> It removes just the artifact bar from the war but leaves in the war
> all it's transitive dependencies, which is not expected.  How can I
> also exclude it's transitive dependencies?  This point is key as the
> logic provided by the ear is significant and probably has 100 or more
> jars...no way to know what they all are and that can change too.
>
> -Dave
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: [Q] Skinny Wars and Taglibs

[Vincent Latombe]

I think it depends on the container, but you actually need the tlds (at
least) in the .war. (under WEB-INF).

Vincent


2012/8/30 Hoying, Ken 

> I am betting someone already has a clever solution to the following
> problem.  I am trying to create a deployment ear which contains a war.  I
> did not want to bloat the ear by repeating the jar files in both the EAR
> and WAR libs.  So I used the skinnyWars setting for the maven-ear-plugin
> (v2.7).  At first I thought this was going to work great and it almost did.
>  However, my JSP pages are now complaining that they cannot find the
> taglibs.  I am getting the following error:
>
> The absolute uri: http://www.springframework.org/tags cannot be resolved
> in either web.xml or the jar files deployed with this application
>
> It seems that the sever really wants these jars to be located under the
> WAR's lib.
>
> Has anyone found a way around this?
>
> Thanks in advance!
> Ken
>
> -
> ***Note:The information contained in this message may be privileged and
> confidential and protected from disclosure. If the reader of this message
> is not the intended recipient, or an employee or agent responsible for
> delivering this message to the intended recipient, you are hereby notified
> that any dissemination, distribution or copying of this communication is
> strictly prohibited.  If you have received this communication in error,
> please notify the Sender immediately by replying to the message and
> deleting it from your computer.  Thank you.  Premier Inc.
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: custom unique version

[Vincent Latombe]

http://mojo.codehaus.org/buildnumber-maven-plugin/ could be your solution

Vincent


2012/1/20 Ron Wheeler 

> Of all of the developers that have built thousands of applications using
> Maven, you are the only one who wants to do this.
>
> Does that not raise any red flags?
>
> There must be a "best practice" for what you are trying to achieve.
> This is clearly not it.
>
> Ron
>
>
> On 20/01/2012 10:14 AM, Stephen Connolly wrote:
>
>> 2012/1/20 Thomas 
>> Scheffler
>> >:
>>
>>> Am 20.01.2012 15:30, schrieb Stephen Connolly:
>>>
>>>  2012/1/20 Thomas 
>>> Scheffler
 >:

> Am 20.01.2012 12:40, schrieb Stephen Connolly:
>
>  You can stuff what ever you want in tge manifest.
>>
>> Google is your friend: maven jar plugin manifest customization
>>
>
>
> Hi,
>
> yeah I know that. But how can I put the "unique version number" into
> the
> JAR
> manifest?
>

>>> OK, let me put this in another form, so you might understand what I was
>>> asking you.
>>>
>>> I know how to put custom keys and values into a manifest. That's the
>>> "yeah I
>>> know that" above.
>>>
>>> The question should have been understand like this: How can I acquire the
>>> "unique version number" that makes of "1.0-SNAPSHOT" locally
>>> "1.0-20120120.121003-6" remotely, so that I can put it into the JAR
>>> manifest
>>> of the JAR file that is deployed in a remote repository?
>>>
>> That string is decided when deploy:deploy is invoked, so you cannot
>> put that string in.
>>
>>  Or in other words:
>>> The substring "20120120.121003-6" is changing at every deployment. I want
>>> that part in the manifest.
>>>
>>>
>>> Thomas
>>>
>>>
>>>  http://bit.ly/zijlWA

 See the example on that screen...

 See how properties are substituted in?

 Then you need to go to http://to.justpitch.me/yiTp6D

 -Stephen

  Thomas
>
>
>  Am 20.01.2012 10:32, schrieb Stephen Connolly:
>>>
>>>  It cannot.

 That is part of the spec for the layout of a Maven repository.

  Is there a way to embed the unique version string into the JAR
>>> manifest
>>> then? If I test an application with a snapshot jar I want stick with
>>> that
>>> specific version when deploying the application later. This should be
>>> done
>>> automatically.
>>>
>>> 1. Do some automatic test, if they succeed gather the unique version
>>> number.
>>> 2. At deploy time use the last successful timestamp.
>>>
>>> Maybe someone could help me with that... :-)
>>>
>>> regards
>>>
>>> Thomas
>>>
>>>
>>>  -Stephen

 2012/1/20 Thomas
 Schefflerhttp://uni-jena.de><
 thomas.scheffler@**uni-jena.de >

  :
>


  Hi,
>
> I want to create a unique SNAPSHOT version that does not consist of
> timestamp and buildnumber but is created by a defined property.
>
> I read the docs and googled for a solution but found no way to
> alter
> the
> unique version string. How can this be achieved?
>
> regards
>
> Thomas
>

>>> --**--**
>>> -
>>> To unsubscribe, e-mail: 
>>> users-unsubscribe@maven.**apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>  --**--**
>> -
>> To unsubscribe, e-mail: 
>> users-unsubscribe@maven.**apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

Re: Difference between build/extensions/extension and build/plugins/plugin/extensions?

[Vincent Latombe]

As far as I understand, specifying build/plugins/plugin/**extensions set to
true allows plugins embedding a components.xml to actually declare these
components as part of the context. In such case you don't need to repeat the
plugin declaration in the build/extensions/extension section.

The build/extensions/extension is rather used to include jars (non-plugin)
that declares additional components. In the example you gave, the plugin and
the artifact declared in build/extensions/extension don't have the same
coordinates, so they have likely different purposes.

Vincent


On Wed, Sep 7, 2011 at 17:13, Andreas Sewe <
s...@st.informatik.tu-darmstadt.de> wrote:

> Hi all,
>
> what is the difference between build/extensions/extension and
> build/plugins/plugin/**extensions set to true. It seems somewhat redundant
> (yes, I could use a property) to have to specify the plugin's version twice,
> as in this snippet from the maven-archetype-plugin's site:
>
>  
>>  ...
>>  maven-archetype
>>  ...
>>  
>>
>>  
>>org.apache.maven.**archetype
>>archetype-**packaging
>>2.1
>>  
>>
>>
>>
>>  
>>
>>  org.apache.maven.**plugins
>>  maven-archetype-**plugin
>>  2.1
>>
>>  
>>
>>  
>> 
>>
>
> And on a similar note: Are extensions "plugin-managed" or do I really have
> to repeat the version twice in the above? The output of help:effective-pom
> seems to suggest that extensions are not managed: if I leave out
> build/extensions/extension/**version in the above, the effective POM also
> lacks the version element.
>
> I hope that somebody can enlighten me.
>
> Best wishes,
>
> Andreas
>
> --**--**-
> To unsubscribe, e-mail: 
> users-unsubscribe@maven.**apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Why would "unpack-dependencies" sometimes not do its job?

[Vincent Latombe]

Or, since you have classes,
http://mojo.codehaus.org/build-helper-maven-plugin/add-resource-mojo.html

Vincent


On Mon, Aug 1, 2011 at 17:58, Vincent Latombe wrote:

> Use
> http://mojo.codehaus.org/build-helper-maven-plugin/add-source-mojo.html to
> add additional source directories.
>
> Vincent
>
>
>
> On Thu, Jul 28, 2011 at 17:15, KARR, DAVID (ATTSI)  wrote:
>
>> > -Original Message-
>> > From: KARR, DAVID (ATTSI)
>> > Sent: Thursday, July 28, 2011 7:03 AM
>> > To: Maven Users List
>> > Subject: RE: Why would "unpack-dependencies" sometimes not do its job?
>> >
>> > > -Original Message-
>> > > From: Brian Fox [mailto:bri...@infinity.nu]
>> > > Sent: Wednesday, July 27, 2011 8:49 AM
>> > > To: Maven Users List
>> > > Subject: Re: Why would "unpack-dependencies" sometimes not do its
>> > job?
>> > >
>> > > default is:
>> > >
>> > > overWriteIfNewer=true
>> > > overWriteReleases = false
>> > > overWriteSnapshots=false
>> > >
>> > > Setting the releases or snapshots to true will cause it to ignore the
>> > > if newer check.
>> >
>> > Ok.  I assume it doesn't matter if I set both to true?
>> >
>> > This change worked.
>> >
>> > I also noticed that the dependency classes were missing from
>> > "target/classes" just before I did the build.  I think this means that
>> > this is being caused by m2e (Eclipse Maven plugin).  I had just changed
>> > the flags in my pom.xml, and Eclipse built the workspace.
>>
>> I suppose the fact that m2e is clearing out "target/classes" shouldn't be
>> surprising, as that's my project's output directory.
>>
>> I guess it would have made sense to have "maven-dependency-plugin" write
>> its classes to something like "target/dependency/classes" and then make
>> "maven-jar-plugin" take classes from both "target/classes" and
>> "target/dependency/classes".  Unfortunately, I'm surprised to see that
>> "maven-jar-plugin" can only specify one directory to pull classes from.
>>
>> > > On Wed, Jul 27, 2011 at 11:13 AM, KARR, DAVID (ATTSI)
>> > 
>> > > wrote:
>> > > >> -Original Message-
>> > > >> From: Brian Fox [mailto:bri...@infinity.nu]
>> > > >> Sent: Tuesday, July 26, 2011 5:01 PM
>> > > >> To: Maven Users List
>> > > >> Subject: Re: Why would "unpack-dependencies" sometimes not do its
>> > > job?
>> > > >>
>> > > >> you can set a flag to tell it to always unpack. I forget the exact
>> > > >> param, but it's in the docs.
>> > > >
>> > > > I just checked the doc page for "dependency:unpack-dependencies"
>> > and
>> > > there's no flag I can see that does this.
>> > > >
>> > > >> On Tue, Jul 26, 2011 at 5:01 PM, KARR, DAVID (ATTSI)
>> > > 
>> > > >> wrote:
>> > > >> >> -Original Message-
>> > > >> >> From: GALLAGHER, RON (ATTSI)
>> > > >> >> Sent: Tuesday, July 26, 2011 12:03 PM
>> > > >> >> To: Maven Users List
>> > > >> >> Subject: RE: Why would "unpack-dependencies" sometimes not do
>> > its
>> > > >> job?
>> > > >> >>
>> > > >> >> David,
>> > > >> >>
>> > > >> >> When the dependency plugin unpacks an artifact, it puts a
>> > marker
>> > > >> file
>> > > >> >> in
>> > > >> >> the 'markersDirectory' [1] so that it doesn't unpack that same
>> > > >> artifact
>> > > >> >> a second time.
>> > > >> >>
>> > > >> >> When you run "mvn clean", that 'markersDirectory' is cleared
>> > out,
>> > > >> along
>> > > >> >> with all other build output.
>> > > >> >>
>> > > >> >> Is it possible that the absence of classes from your dependent
>> > > jar
>> > > >> >> files
>> > > >> >> is due to the presence of one o

Re: Why would "unpack-dependencies" sometimes not do its job?

[Vincent Latombe]

Use http://mojo.codehaus.org/build-helper-maven-plugin/add-source-mojo.html to
add additional source directories.

Vincent


On Thu, Jul 28, 2011 at 17:15, KARR, DAVID (ATTSI)  wrote:

> > -Original Message-
> > From: KARR, DAVID (ATTSI)
> > Sent: Thursday, July 28, 2011 7:03 AM
> > To: Maven Users List
> > Subject: RE: Why would "unpack-dependencies" sometimes not do its job?
> >
> > > -Original Message-
> > > From: Brian Fox [mailto:bri...@infinity.nu]
> > > Sent: Wednesday, July 27, 2011 8:49 AM
> > > To: Maven Users List
> > > Subject: Re: Why would "unpack-dependencies" sometimes not do its
> > job?
> > >
> > > default is:
> > >
> > > overWriteIfNewer=true
> > > overWriteReleases = false
> > > overWriteSnapshots=false
> > >
> > > Setting the releases or snapshots to true will cause it to ignore the
> > > if newer check.
> >
> > Ok.  I assume it doesn't matter if I set both to true?
> >
> > This change worked.
> >
> > I also noticed that the dependency classes were missing from
> > "target/classes" just before I did the build.  I think this means that
> > this is being caused by m2e (Eclipse Maven plugin).  I had just changed
> > the flags in my pom.xml, and Eclipse built the workspace.
>
> I suppose the fact that m2e is clearing out "target/classes" shouldn't be
> surprising, as that's my project's output directory.
>
> I guess it would have made sense to have "maven-dependency-plugin" write
> its classes to something like "target/dependency/classes" and then make
> "maven-jar-plugin" take classes from both "target/classes" and
> "target/dependency/classes".  Unfortunately, I'm surprised to see that
> "maven-jar-plugin" can only specify one directory to pull classes from.
>
> > > On Wed, Jul 27, 2011 at 11:13 AM, KARR, DAVID (ATTSI)
> > 
> > > wrote:
> > > >> -Original Message-
> > > >> From: Brian Fox [mailto:bri...@infinity.nu]
> > > >> Sent: Tuesday, July 26, 2011 5:01 PM
> > > >> To: Maven Users List
> > > >> Subject: Re: Why would "unpack-dependencies" sometimes not do its
> > > job?
> > > >>
> > > >> you can set a flag to tell it to always unpack. I forget the exact
> > > >> param, but it's in the docs.
> > > >
> > > > I just checked the doc page for "dependency:unpack-dependencies"
> > and
> > > there's no flag I can see that does this.
> > > >
> > > >> On Tue, Jul 26, 2011 at 5:01 PM, KARR, DAVID (ATTSI)
> > > 
> > > >> wrote:
> > > >> >> -Original Message-
> > > >> >> From: GALLAGHER, RON (ATTSI)
> > > >> >> Sent: Tuesday, July 26, 2011 12:03 PM
> > > >> >> To: Maven Users List
> > > >> >> Subject: RE: Why would "unpack-dependencies" sometimes not do
> > its
> > > >> job?
> > > >> >>
> > > >> >> David,
> > > >> >>
> > > >> >> When the dependency plugin unpacks an artifact, it puts a
> > marker
> > > >> file
> > > >> >> in
> > > >> >> the 'markersDirectory' [1] so that it doesn't unpack that same
> > > >> artifact
> > > >> >> a second time.
> > > >> >>
> > > >> >> When you run "mvn clean", that 'markersDirectory' is cleared
> > out,
> > > >> along
> > > >> >> with all other build output.
> > > >> >>
> > > >> >> Is it possible that the absence of classes from your dependent
> > > jar
> > > >> >> files
> > > >> >> is due to the presence of one or more marker files in the
> > > >> >> 'markersDirectory' that were placed there during the previous
> > > build?
> > > >> >
> > > >> > Ok, it happened again.  All the marker files are present, but
> > > >> "target/classes" doesn't have the dependent classes.  I'll watch
> > to
> > > see
> > > >> if something else after this removes things from that tree.
> > > >> >
> > > >> >> [1]
> > > >> >> http://maven.apache.org/plugins/maven-dependency-plugin/unpack-
> > > >> >> dependenc
> > > >> >> ies-mojo.html#markersDirectory
> > > >> >>
> > > >> >> Ron Gallagher
> > > >> >>
> > > >> >>
> > > >> >> -Original Message-
> > > >> >> From: KARR, DAVID (ATTSI)
> > > >> >> Sent: Tuesday, July 26, 2011 1:02 PM
> > > >> >> To: users@maven.apache.org
> > > >> >> Subject: Why would "unpack-dependencies" sometimes not do its
> > > job?
> > > >> >>
> > > >> >> I'm using both "maven-dependency-plugin" and "maven-jar-plugin"
> > > so
> > > >> all
> > > >> >> of my application classes and dependent classes go into a
> > single
> > > jar
> > > >> >> file.  Every once in a while I discover that the resulting jar
> > > file
> > > >> >> doesn't have my dependent classes.  If I then do "mvn clean"
> > and
> > > >> then
> > > >> >> "mvn" (default goal of install), it works fine.  At the time
> > it's
> > > >> >> happened, I didn't have the presence of mind to check my
> > > >> >> "target/classes" directory to verify it was "maven-dependency-
> > > >> plugin"
> > > >> >> that failed to do its work.  As the job of "maven-jar-plugin"
> > is
> > > >> much
> > > >> >> simpler, I don't think it's likely this is the problem.
> > > >> >>
> > > >> >> My plugin configs follow this.
> > > >> >>
> > > >> >> Any ideas why this might be happening?
> > > >> 

Re: Skip Resources for War

[Vincent Latombe]

Hello,

You have to use
http://maven.apache.org/plugins/maven-resources-plugin/examples/include-exclude.html

webResources are meant to be web resources (jsp, js, html) not resources
present in the classpath (WEB-INF/classes)

Vincent


On Wed, Jul 6, 2011 at 18:01, Wayne Fay  wrote:

> > Well, copying them into some external resources directory would solve the
> purpose, however if to be done with present settings.
>
> I don't know why you don't just move the files to
> /src/external/resources or something. That seems to be the easiest
> solution.
>
> Wayne
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Maven 3 support for org.apache.maven.user-settings

[Vincent Latombe]

Use -s command-line argument?

Vincent


2011/2/8 radai 

>
>
> Benjamin Bentmann wrote:
> >
> > There is no alternative but support for the system property can be
> > restored if there's a valid use case for it.
> >
> > Benjamin
> >
>
> we have a hudson CI server running builds for multiple (maven) projects,
> each with its own repositories. it would be nice to seperate the
> settings.xml between builds, and not lump them all together - for that i'd
> need to override the location of the settings file.
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Maven-3-support-for-org-apache-maven-user-settings-tp3261146p3375624.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
>
>

Re: Create jar from ear project or create 2 jars from jar project

[Vincent Latombe]

Hi,

one project = one artifact. You'll get hurt (to various degrees) if you try
to fight that principle.

Here are a few hints to explore though :
- build-helper-plugin to attach additional artifacts to your build
- dependency-plugin to copy/unpack resources from other artifacts

Vincent


2010/11/25 Thomas Göttlich 

> Hi,
>
> we need to create a jar that only contains 2 xml files but nothing more.
> Because we have just those 2 files, we don't want to create a new project
> for that (especially since Eclipse can't display projects hierarchically).
>
> So the question is:
>
> Is it possible to create a JAR containing those 2 files from either an
> EAR-Module or a JAR-Module?
> I tried both, using the maven-jar-plugin, but wasn't yet successful.
>
> The problem is that normal EAR or JAR creation should not be affected,
> however in the EAR project the artifact was deployed/installed using the
> EAR's artifact id.
>
> Is there a way to create two artifacts from one EAR project?
> Or is there a way to create two distinct jars from one JAR project in one
> run, e.g. not having to start multiple runs with different
> profiles/properties ?
>
> Thanks in advance.
>

Re: Mvn 3: Dependency list vs Dependency tree

[Vincent Latombe]

Hello,

check your dependency:tree again, I can see net.sf.ehcache:ehcache:jar:1.5.0
and com.oracle:ojdbc14:jar:10.2.0.4.0 at least.

I also recommend you to check help:effective-pom to check if these
dependencies didn't get included through your pom hierarchy.

Vincent


2010/11/25 Gérald Quintana 

> Hello,
>
> I have just migrated from Maven 2.0.9 to Maven 3.0.0. Everything
> compiles, tests as expected, but it doesn't run. I get some useless
> librairies in my WEB-INF\lib with old versions. Looking in the
> dependency tree for the origin of theses dependencies, they are not
> present. But they are present in dependency list! Look at the
> net.sf.ehcache:ehcache:jar:1.5.0 or com.mycompany:fwk-i18nImpl:jar:1.5
> or com.oracle:ojdbc14:jar:10.2.0.4.0 dependencies in the following
> logs.
>
> I have tried to tweak dependency exclusions without success.
>
> What can I do to understand what's happening and fix it?
>
> Gérald
>
> [INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ app-remoting
> ---
> [INFO] com.mycompany:app-remoting:war:2.1.0-SNAPSHOT
> [INFO] +- com.mycompany:app-facade1:jar:2.1.0-SNAPSHOT:compile
> [INFO] |  +- com.mycompany:app-domain:jar:2.1.0-SNAPSHOT:compile
> [INFO] |  |  +- com.mycompany:hab-domain:jar:1.1.6:compile
> [INFO] |  |  +- com.mycompany:ref-domain:jar:1.6.4:compile
> [INFO] |  |  +- com.mycompany:fwk-i18n:jar:1.6.6:compile
> [INFO] |  |  +- javax.persistence:persistence-api:jar:1.0:compile
> [INFO] |  |  +- net.sf.ehcache:ehcache-core:jar:2.1.0:runtime
> [INFO] |  |  +-
> backport-util-concurrent:backport-util-concurrent:jar:3.1:runtime
> [INFO] |  |  \- net.sourceforge.jexcelapi:jxl:jar:2.6:compile
> [INFO] |  \- com.mycompany:app-integration:jar:2.1.0-SNAPSHOT:compile
> [INFO] | +-
>
> org.springframework.integration:spring-integration-core:jar:1.0.3.RELEASE:compile
> [INFO] | \-
>
> org.springframework.integration:spring-integration-file:jar:1.0.3.RELEASE:compile
> [INFO] +- com.mycompany:app-facade1Impl:jar:2.1.0-SNAPSHOT:runtime
> [INFO] |  +- com.mycompany:hab-core-facade:jar:2.0.0:runtime
> [INFO] |  |  \- com.mycompany:hab-core-domain:jar:2.0.0:runtime
> [INFO] |  +- com.mycompany:ref-facade:jar:1.6.4:runtime
> [INFO] |  +- com.mycompany:ref-facadeImpl:jar:1.6.4:runtime
> [INFO] |  +- com.mycompany:ref-repository:jar:1.6.4:runtime
> [INFO] |  +- com.mycompany:ref-repositoryImpl:jar:1.6.4:runtime
> [INFO] |  +- org.springframework:spring-jms:jar:2.5.6:runtime
> [INFO] |  +- javax.sql:jdbc-stdext:jar:2.0:runtime
> [INFO] |  \- com.mycompany:syn-fwk-observer:jar:2.2.4:runtime
> [INFO] +- com.mycompany:app-facade2:jar:2.1.0-SNAPSHOT:compile
> [INFO] |  \- com.mycompany:arp-comm:jar:0.42:compile
> [INFO] +- com.mycompany:app-facade2Impl:jar:2.1.0-SNAPSHOT:runtime
> [INFO] |  +- com.mycompany:fwk-impression:jar:1.6.6:runtime
> [INFO] |  +- com.mycompany:fwk-impressionImpl:jar:1.6.6:runtime
> [INFO] |  |  +- org.apache.ws.commons.axiom:axiom-impl:jar:1.2.7:runtime
> [INFO] |  |  |  +- org.apache.ws.commons.axiom:axiom-api:jar:1.2.7:runtime
> [INFO] |  |  |  |  \- jaxen:jaxen:jar:1.1.1:runtime
> [INFO] |  |  |  +-
> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.1:runtime
> [INFO] |  |  |  +-
> org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.2:runtime
> [INFO] |  |  |  +- org.codehaus.woodstox:wstx-asl:jar:3.2.4:runtime
> [INFO] |  |  |  \-
> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:runtime
> [INFO] |  |  \- org.codehaus.castor:castor:jar:1.2:runtime
> [INFO] |  +- org.springframework.ws:spring-ws-core:jar:1.5.7:runtime
> [INFO] |  |  +- org.springframework.ws:spring-xml:jar:1.5.7:runtime
> [INFO] |  |  +- org.springframework.ws:spring-oxm:jar:1.5.7:runtime
> [INFO] |  |  \- wsdl4j:wsdl4j:jar:1.6.1:runtime
> [INFO] |  +- org.springframework.ws:spring-ws-core-tiger:jar:1.5.7:runtime
> [INFO] |  +- com.mycompany:hab-core-facadeImpl:jar:2.0.0:runtime
> [INFO] |  |  \- com.mycompany:hab-core-repository:jar:2.0.0:runtime
> [INFO] |  \- com.mycompany:hab-core-repositoryImpl:jar:2.0.0:runtime
> [INFO] +- com.mycompany:app-commun:jar:2.1.0-SNAPSHOT:compile
> [INFO] |  +- com.mycompany:etj-xom:jar:2.0.4:compile
> [INFO] |  \- quartz:quartz:jar:1.6.5:compile
> [INFO] +- com.mycompany:app-communImpl:jar:2.1.0-SNAPSHOT:runtime
> [INFO] +- com.mycompany:app-integrationImpl:jar:2.1.0-SNAPSHOT:runtime
> [INFO] |  +-
> org.springframework.integration:spring-integration-ws:jar:1.0.3.RELEASE:runtime
> [INFO] |  |  \-
>
> org.springframework.integration:spring-integration-adapter:jar:1.0.3.RELEASE:runtime
> [INFO] |  +-
> org.springframework.integration:spring-integration-xml:jar:1.0.3.RELEASE:runtime
> [INFO] |  +- org.springframework.ws:spring-oxm-tiger:jar:1.5.7:runtime
> [INFO] |  \-
> org.springframework.integration:spring-integration-jms:jar:1.0.3.RELEASE:runtime
> [INFO] +- com.mycompany:app-impression:jar:2.1.0-SNAPSHOT:runtime
> [INFO] +- com.mycompany:syn-refRemoteFacade:jar:2.2.4-R1.6.4:runtime
> [INFO] |  +- com.myc

Re: parallel execution of unit tests

[Vincent Latombe]

By default, all tests are runned in the same jvm instance, that's why your
static assignments are not reset.

You have 2 solutions :
- clean up the static state between each test
- use forkMode = always. It will create a new jvm for each test. However, as
you can understand, it will perform much slower

Vincent


2010/11/20 Kristian Rosenvold 

> It sounds *very* much to me like the static state is not being reset
> properly; you're not running in parallel unless you're using some exotic
> custom stuff.
>
> Did you try to run multiple tests at once from eclipse ?
>
> Kristian
>
>
> lø., 20.11.2010 kl. 21.17 +0100, skrev Iron Eagle:
> > Hi,
> >
> > thank you, for your awnser.
> >
> > I have no explicit configuration of the surefire plugin in my pom file. I
> use the implicit default configuration of the plugin. I am not sure, whats
> the default value for the "parallel" setting.
> >
> > At the end of each test method I reset the state of the singleton
> instance to the initial state. So I am able to execute the test methods in
> each order without failing. But in the case several methods run in parallel,
> the side effects between the threads may cause the tests to fail.
> >
> > greetings
> >
> >  Original-Nachricht 
> > > Datum: Sat, 20 Nov 2010 19:55:06 +0100
> > > Von: Kristian Rosenvold 
> > > An: Maven Users List 
> > > Betreff: Re: parallel execution of unit tests
> >
> > > The way I read your explanation, I am not entirely convinced anything
> is
> > > being run in parallel; look for the "maven-surefire-plugin" in your pom
> > > and see if the "parallel" setting is active.
> > >
> > > Much more likely you have static state in your tests that fails when
> > > multiple test methods are being run in the same vm invocation. If you
> > > try to run ALL the tests within the class at once from eclipse I bet
> > > they will fail. In this case you simply need to reset the static state
> > > between each test.
> > >
> > >
> > > Kristian
> > >
> > > state, and does not
> > > lø., 20.11.2010 kl. 18.22 +0100, skrev Iron Eagle:
> > > > Hi,
> > > >
> > > > I have a problem with the junit (3.8.1) tests in a mvane project.
> While
> > > each unit test is successfull when I start it within eclipse, maven
> fails,
> > > when executing the tests.
> > > >
> > > > I figured out, that the test methods of my junit test are executed
> > > parallel. This is bad, since the class under test is singleton. So in
> every test
> > > method, the same instance is used. This has side effects in each test
> > > method, what leads into a failure.
> > > >
> > > > Is this a known problem? is there a simple way to force s sequential
> > > execution of the unit tests? (I use junit 3.8.1, so I can not use
> anotations
> > > like @Depends)
> > > >
> > > > best regards
> > > >
> > >
> > >
> > >
> > > -
> > > 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: RE: properties inheritance does not work on windows os

[Vincent Latombe]

My previous message was meant for chemit and his reaction to Benjamin's
message

Vincent
Le 2010 11 12 13:59, "Yanko, Curtis"  a écrit :
> ??
>
>
>> -Original Message-
>> From: Vincent Latombe [mailto:vincent.lato...@gmail.com]
>> Sent: Friday, November 12, 2010 7:56 AM
>> To: Maven Users List
>> Subject: Re: properties inheritance does not work on windows os
>>
>> I think what Benjamin meant is : please provide an sample
>> project to reproduce your problem.
>>
>> Vincent
>>
>>
>> 2010/11/11 Yanko, Curtis 
>>
>> > Very odd indeed, we use properties quite pervasively and I haven't
>> > seen this.
>> >
>> > I do recall some chicken-n-egg scenarios but this doesn't
>> to fit that mold.
>> >
>> >
>> > > -Original Message-
>> > > From: chemit [mailto:che...@codelutin.com]
>> > > Sent: Thursday, November 11, 2010 9:42 AM
>> > > To: users@maven.apache.org
>> > > Subject: Re: properties inheritance does not work on windows os
>> > >
>> > > On Thu, 11 Nov 2010 08:27:24 -0600
>> > > "Yanko, Curtis"  wrote:
>> > >
>> > > > Is this only on Maven 3.0? We haven't crossed that bridge yet.
>> > >
>> > > Good point, I have just try with version 2.2.1 and result
>> is the same.
>> > >
>> > > I really don't understand why this works on linux but not under
>> > > windows, there is some mysteries somewhere.
>> > >
>> > > Just to note, we use this since some times now (having
>> version with
>> > > a property in dependenciesManagement of a parent
>> > > pom) and we never had the problem (since now :)).
>> > >
>> > > I will have a look in maven jira in case.
>> > >
>> > > Perharps what we are doing is wrong ? I really don't know...
>> > >
>> > > Thanks.
>> > >
>> > >
>> > > --
>> > > Tony Chemit
>> > > 
>> > > tél: +33 (0) 2 40 50 29 28
>> > > email: che...@codelutin.com
>> > > http://www.codelutin.com
>> > >
>> > >
>> 
>> > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> > > For additional commands, e-mail: users-h...@maven.apache.org
>> > >
>> > >
>> >
>> > This e-mail, including attachments, may include confidential and/or
>> > proprietary information, and may be used only by the person
>> or entity
>> > to which it is addressed. If the reader of this e-mail is not the
>> > intended recipient or his or her authorized agent, the reader is
>> > hereby notified that any dissemination, distribution or copying of
>> > this e-mail is prohibited. If you have received this e-mail
>> in error,
>> > please notify the sender by replying to this message and
>> delete this e-mail immediately.
>> >
>> >
>> >
>> -
>> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: users-h...@maven.apache.org
>> >
>> >
>>
>
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

Re: properties inheritance does not work on windows os

[Vincent Latombe]

I think what Benjamin meant is : please provide an sample project to
reproduce your problem.

Vincent


2010/11/11 Yanko, Curtis 

> Very odd indeed, we use properties quite pervasively and I haven't seen
> this.
>
> I do recall some chicken-n-egg scenarios but this doesn't to fit that mold.
>
>
> > -Original Message-
> > From: chemit [mailto:che...@codelutin.com]
> > Sent: Thursday, November 11, 2010 9:42 AM
> > To: users@maven.apache.org
> > Subject: Re: properties inheritance does not work on windows os
> >
> > On Thu, 11 Nov 2010 08:27:24 -0600
> > "Yanko, Curtis"  wrote:
> >
> > > Is this only on Maven 3.0? We haven't crossed that bridge yet.
> >
> > Good point, I have just try with version 2.2.1 and result is the same.
> >
> > I really don't understand why this works on linux but not
> > under windows, there is some mysteries somewhere.
> >
> > Just to note, we use this since some times now (having
> > version with a property in dependenciesManagement of a parent
> > pom) and we never had the problem (since now :)).
> >
> > I will have a look in maven jira in case.
> >
> > Perharps what we are doing is wrong ? I really don't know...
> >
> > Thanks.
> >
> >
> > --
> > Tony Chemit
> > 
> > tél: +33 (0) 2 40 50 29 28
> > email: che...@codelutin.com
> > http://www.codelutin.com
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Practical to have "optional" submodules, getting their artifacts from intranet repo if absent?

[Vincent Latombe]

What you want can be achieved by having one big aggregator that contains all
your modules and your ears, and use the reactor feature.

By typing mvn -pl my-project:app -am, where my-project:app is the groupId of
your ear, you will actually build the ear and all its transitive
dependencies accross your whole reactor.

I would also add that in an environment where you have continuous
integration, with snapshots deployed regularly on a corporate repository,
the need to build everything from scratch will vanish as you will need to
build only what you changed and its downstream dependencies (-amd is very
useful for that)

Vincent


2010/11/9 KARR, DAVID (ATTSI) 

>
>  I currently work on a large enterprise app built with Ant.  The app is
> divided into several projects divided into functional areas.  In order
> to build the entire EAR, all of the projects have to be built, even if
> you're only working on a single one of those projects.
>
> I'm examining how we could make this work better if we were using Maven.
>
> I guess a straightforward implementation of this would have a main
> project POM that specifies all the subprojects as submodules, and also
> their artifacts as dependencies.
>
> It almost seems to me that what I need is the ability to have the main
> POM be somewhat "dynamic", such that if I'm only working on a single one
> of those subprojects, but I need to assemble the EAR containing all of
> the artifacts, then the projects that I don't have checked out would get
> their submodule entry temporarily deleted, and I would get their
> artifacts from the intranet repo.
>
> I would be using m2eclipse.
>
> Does any of this make sense?
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Version 1.0 of maven-enforcer-plugin not deployed

[Vincent Latombe]

I can reach the artifact just fine.

Vincent


2010/11/9 Johan Hedin 

> Maven refuses to build. Version 1.0 of maven-enforcer-plugin in the
> repo1.maven.org is empty.
>
>
> [INFO]
> 
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-enforcer-plugin/1.0/maven-enforcer-plugin-1.0.pom
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-enforcer-plugin/1.0/maven-enforcer-plugin-1.0.jar
> [INFO]
> 
> [ERROR] BUILD FAILURE
> [INFO]
> 
> [INFO] A required plugin was not found: Plugin could not be found - check
> that the goal name is correct: Unable to download the artifact from any
> repository
>
> Try downloading the file manually from the project website.
>
> Then, install it using the command:
>mvn install:install-file -DgroupId=org.apache.maven.plugins
> -DartifactId=maven-enforcer-plugin -Dversion=1.0 -Dpackaging=maven-plugin
> -Dfile=/path/to/file
>
> Alternatively, if you host your own repository you can deploy the file
> there:
>mvn deploy:deploy-file -DgroupId=org.apache.maven.plugins
> -DartifactId=maven-enforcer-plugin -Dversion=1.0 -Dpackaging=maven-plugin
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
>
>
>  org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0
>
> from the specified remote repositories:
>  mawell-repository.snapshots (scpexe://
> repository.intra.mawell.com/opt/m2repository/snapshots),
>  mawell-repository.releases (scpexe://
> repository.intra.mawell.com/opt/m2repository/deploy),
>  central (http://repo1.maven.org/maven2)
>
>
>  org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0
>
> from the specified remote repositories:
>  mawell-repository.snapshots (scpexe://
> repository.intra.mawell.com/opt/m2repository/snapshots),
>  mawell-repository.releases (scpexe://
> repository.intra.mawell.com/opt/m2repository/deploy),
>  central (http://repo1.maven.org/maven2)
>
> TIA
>
> Johan Hedin
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Order of properties resolution within POM and inheritance

[Vincent Latombe]

Hi everyone,

I just got surprised by the way Maven resolves properties between parent,
profiles and current pom.

I made an example project to illustrate that (one parent pom, one child) :
https://gist.github.com/667731
With this example project, from the child project, I get the following :

mvn validate => myproperty = child
mvn validate -Pmyprofile => myproperty = child

I would rather expect using the second command to get myproperty =
myprofile. But anyway, if this is how it works...

Vincent

Re: Change artifactId by Profile

[Vincent Latombe]

I don't know about your context, but you should make different artifacts
instead.

Vincent


2010/11/8 Darren Hartford 

> Hey all,
> I have a number of builds that, depending on the profile selected, should
> deploy a different artifact.  Usually this is related to branding using the
> profiles to change the /src/main/resources to instead use branded versions.
>
> Problem is, my current approach definitely has some issues with various
> tooling and plugins:
>
> pom.xml: ${myCustomArtifactId}
>
> profile1:
>
> app-profile1
>
>
> profile2:
>
> app-profile2
>
>
> Is there a cleaner way to change the 'artifactId' based on the selected
> profile instead of this property approach, while still keeping support for
> things like -source/-javadoc deploys as well (each branded).
>
> thanks!
>
> -D
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: duplicate web.xml files in a .war file

[Vincent Latombe]

Hi,

this is a known problem of maven war plugin 2.1.

Version 2.1.1 has been released earlier today and it fixes this issue.

Cheers,

Vincent


2010/11/4 Andrew Westberg 

> I updated to the latest maven 3.  I noticed that my webapp projects now
> contain two copies of web.xml.  Is anyone else seeing this issue?
>
> I have a very basic pom.xml configuration:
> http://pastie.org/1272557
>
> screenshot of .war containing dup web.xml files:
> http://www.flickr.com/photos/14210...@n05/5146351490/
>
> Thanks,
> Andrew
>

Re: mvn install to a given local repo path - broken with m3?

[Vincent Latombe]

I don't know where you read that -DlocalRepository overrided the local
repository path, but I don't think this has ever worked. As Wendy says, use
-Dmaven.repo.local

Vincent


2010/11/4 Holger Hoffstaette 

> On Thu, 04 Nov 2010 13:08:41 +0100, Jochen Wiedmann wrote:
>
> > you aren't writing how you do specify the "local repository path". My
> > assumption would be that you need to use the Maven option -s or
> --settings
> > and use the "localRepository" element in the given settings file, as
> > specified by the settings XSD. [1] Is that what you are doing?
>
> No, I'm doing the much more obvious :-) and try to pass the repo path into
> the comand line invocation. Sorry for not being more clear.
>
> To reproduce, take any project and run:
> mvn install -DlocalRepository=/some/path
>
> ..which is happily ignored and the project is installed into the default
> location (or whatever is defined in settings.xml). But changing the
> settings won't work as this is supposed to be part of an automated build.
>
> The -D value never sticks, regardless of position in the command line or
> platform (tested on Windows and Linux). A trace with -X always shows the
> default local repository being used by the install plugin.
>
> thanks
> Holger
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: accessing settings.xml when specfiying user.home

[Vincent Latombe]

Hello,

when you type mvn -Duser.home=j:\joe_user compile, you provide user.home to
maven. In your case, I think you want to provide this to the jvm that
executes maven, so you should try

set MAVEN_OPTS=-Duser.home=j:\joe_user compile

Cheers,

Vincent

2010/11/1 c...@netzero.net 

> I am having trouble accessing the settings.xml when running the following
> command on my windows box:
>
>   mvn -Duser.home=j:\joe_user compile
>
> where "j:\joe_user" is a samba mounted drive to my unix box in which the
> .m2 directory exists.  I've run with the -X switch so I can see what's
> happening:
>
>   mvn -Duser.home=j:\joe_user -X compile
>
>   [DEBUG] Reading user settings from c:\Documents and
> Settings\joe_user\.m2\settings.xml
>   [DEBUG] Reading global settings from
> j:\joe_user\maven\apache-maven-3.0\conf\settings.xml
>   [DEBUG] Using local repository at j:\joe_user\.m2\repository
>
>
>
> I've only included the interesting debug messages and you can see that I am
> using version 3.0 as my M2_HOME is set to j:\joe_user\maven\apache-maven-3.0
>
> Things run as expected when I copy the settings.xml file from my unix box
> onto my windows box into the appropriate directory OR if i add the -s
> option:
>
>   mvn -Duser.home=j:\joe_user -s j:\joe_user\.m2\settings.xml compile
>
>
>
> My question is:  based on the maven documentation, it appears that a user's
> install is specified at ${user.home}/.m2/settings.xml  therefore, should
> specifying the user.home via -D option point to the correct location and NOT
> the home directory (under windows)?
>
> I apologize if this is answered elsewhere.  I did perform several searches
> prior to sending this email.
>
> thanks
>
> bill
>
>
> 
> DEAL OF THE YEAR: 2010 Honda Civic for $1,734.09
> SPECIAL REPORT: High ticket items are being auctioned for an incredible 90%
> off!
> http://thirdpartyoffers.netzero.net/TGL3231/4ccebcea695e153f379st04vuc
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Vincent

Re: Problem with maven-war-plugin

[Vincent Latombe]

I don't think 2.2 is out yet, however he can try snapshots, as described in
the issue.

2010/10/28 John Singleton 

> It appears this was fixed in version 2.2 of m-w-p, try updating.
>
> http://jira.codehaus.org/browse/MWAR-235
>
> Cheers,
> John
>
> 2010/10/28 Marcin Trościańczyk 
>
> > Hi,
> >
> > I have a problem with maven-war-plugin version 2.1. Below, I paste build
> > section fragment from my pom.xml:
> >
> > 
> > 
> >  
> >org.apache.maven.plugins
> >maven-compiler-plugin
> >
> >  
> >  1.6
> >  1.6
> >
> >  
> >  
> >org.apache.maven.plugins
> >maven-war-plugin
> >2.1
> >  
> > 
> > 
> >
> > Unfotunetly, generated artifact (war) contains two web.xml. When I use
> > maven-war-plugin version 2.0.1 all works fine (generated war archive
> > contains one web.xml). How can I solve this problem.
> >
> > Cheers,
> > Marcin
> >
>



-- 
Vincent

Re: How to release 2 items together, with inter-dependent versions, some specified in elements?

[Vincent Latombe]

The common project parent-pom and build-resources-bundle project, yes,
however the children (each project) won't have the same version.

2010/10/28 Anders Hammar 

> The subject suggests that the projects will be release together, hence very
> likely have the same version.
>
> /Anders
>
> On Thu, Oct 28, 2010 at 08:29, Vincent Latombe  >wrote:
>
> > I thought of that as well, but if it is a parent pom, children will most
> > likely redefine ${project.version} to have their own.
> >
> > Marshall, I think you can refine your scenario by doing the following :
> > - remove the configuration part from your parent pom
> > - release it together with your build-resources-bundle project
> > - create a new artifact that declares as parent your parent pom, and add
> > the
> > configuration for build-resources-bundle (you can even use
> > ${project.parent.version} to reference it)
> > - make your project artifacts inherit from this new pom.
> >
> > This way, you avoid duplication of configuration.
> >
> > 2010/10/28 Anders Hammar 
> >
> > > I think by using ${project.version}.
> > >
> > > /Anders
> > >
> > > On Wed, Oct 27, 2010 at 20:57, Marshall Schor  wrote:
> > >
> > > > We have a common project parent-pom, and a build-resources-bundle
> > project
> > > > containing various "build" resources, bundled into a Jar artifact.
>  One
> > > of
> > > > these
> > > > resources is used in configuring the maven remote-resources-plugin,
> for
> > > > instance.
> > > >
> > > > We start with the configuration where both the parent-pom and
> > > > build-resources-bundle are at version 1-SNAPSHOT.
> > > >
> > > > The parent-pom is set up as an aggregator pom, with one child: the
> > > > build-resources-bundle project.
> > > >
> > > > Executing mvn release:prepare on the parent-pom causes the prepare
> > phase
> > > to
> > > > go
> > > > and update the versions of these from 1-SNAPSHOT to "1" for the
> "tag".
> > > >  However,
> > > > this process does not notice that the remote-resource-plugin's
> > > > configuration in
> > > > the parent-pom is specifying the build-resources-bundle at version
> > > > 1-SNAPSHOT -
> > > > so that version is *not* updated.
> > > >
> > > > If a release:perform were to be done, it would build from the tag
> > > checkout,
> > > > and
> > > > configure the remote-resources-plugin to use the 1-SNAPSHOT version
> of
> > > the
> > > > build-resources-bundle; I want it to be using the "1" version of the
> > > > bundle.
> > > >
> > > > To work around this, I could run the release:prepare, and then update
> > > > manually,
> > > > the tag, to update the reference from 1-SNAPSHOT to 1.
> > > >
> > > > The other thing I could imagine doing is uncoupling these two
> > artifacts,
> > > > and
> > > > releasing the build-resources-bundle separately.  This would require
> > that
> > > I
> > > > duplicate a bunch of things from the common project parent-pom, into
> > the
> > > > build-resources-bundle, and do a separate release cycle, just for it,
> > and
> > > > then
> > > > have the parent-pom depend on the released version.
> > > >
> > > > What is the "maven way" for doing this kind of thing?
> > > >
> > > > -Marshall Schor
> > > >
> > > > -
> > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Vincent
> >
>



-- 
Vincent

Re: How to release 2 items together, with inter-dependent versions, some specified in elements?

[Vincent Latombe]

I thought of that as well, but if it is a parent pom, children will most
likely redefine ${project.version} to have their own.

Marshall, I think you can refine your scenario by doing the following :
- remove the configuration part from your parent pom
- release it together with your build-resources-bundle project
- create a new artifact that declares as parent your parent pom, and add the
configuration for build-resources-bundle (you can even use
${project.parent.version} to reference it)
- make your project artifacts inherit from this new pom.

This way, you avoid duplication of configuration.

2010/10/28 Anders Hammar 

> I think by using ${project.version}.
>
> /Anders
>
> On Wed, Oct 27, 2010 at 20:57, Marshall Schor  wrote:
>
> > We have a common project parent-pom, and a build-resources-bundle project
> > containing various "build" resources, bundled into a Jar artifact.  One
> of
> > these
> > resources is used in configuring the maven remote-resources-plugin, for
> > instance.
> >
> > We start with the configuration where both the parent-pom and
> > build-resources-bundle are at version 1-SNAPSHOT.
> >
> > The parent-pom is set up as an aggregator pom, with one child: the
> > build-resources-bundle project.
> >
> > Executing mvn release:prepare on the parent-pom causes the prepare phase
> to
> > go
> > and update the versions of these from 1-SNAPSHOT to "1" for the "tag".
> >  However,
> > this process does not notice that the remote-resource-plugin's
> > configuration in
> > the parent-pom is specifying the build-resources-bundle at version
> > 1-SNAPSHOT -
> > so that version is *not* updated.
> >
> > If a release:perform were to be done, it would build from the tag
> checkout,
> > and
> > configure the remote-resources-plugin to use the 1-SNAPSHOT version of
> the
> > build-resources-bundle; I want it to be using the "1" version of the
> > bundle.
> >
> > To work around this, I could run the release:prepare, and then update
> > manually,
> > the tag, to update the reference from 1-SNAPSHOT to 1.
> >
> > The other thing I could imagine doing is uncoupling these two artifacts,
> > and
> > releasing the build-resources-bundle separately.  This would require that
> I
> > duplicate a bunch of things from the common project parent-pom, into the
> > build-resources-bundle, and do a separate release cycle, just for it, and
> > then
> > have the parent-pom depend on the released version.
> >
> > What is the "maven way" for doing this kind of thing?
> >
> > -Marshall Schor
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>



-- 
Vincent

Re: avoiding dependency version number duplication

[Vincent Latombe]

The ${...} string is not supposed to be replaced. It will be resolved
because the parent hierarchy is retrieved when your artifact is declared as
a dependency, so it has the whole context to resolve the property.

Vincent

2010/10/26 Paul Benedict 

> I don't believe that's supposed to happen.
>
> On Mon, Oct 25, 2010 at 7:58 PM, Babak Farhang  wrote:
> >> Can you explain the "transformed pom" point?
> >
> > Perhaps I'm not using the correct terminology, but what I meant was
> > that I looked at the pom in my local repo after I mvn install'ed it,
> > and it still contains the literal ${..} string where there should have
> > been the version number.
> >
> > Babak
> >
> > On Mon, Oct 25, 2010 at 6:35 PM, Paul Benedict 
> wrote:
> >> Can you explain the "transformed pom" point? I believe Justin's
> >> approach and "my" approach are identical -- all you are doing is
> >> delaying the version resolution until you declare the dependency.
> >> Anyway, let me know how it works out.
> >>
> >> Paul
> >>
> >> On Mon, Oct 25, 2010 at 7:03 PM, Babak Farhang 
> wrote:
> >>> Paul's approach (using properties defined in the parent pom) is in
> >>> fact what I've been trying.  Trouble is, the transformed pom still has
> >>> "${spring.version}", not the *value* it should resolve to. From a
> >>> practical standpoint, this should break transitive dependencies when
> >>> someone includes my project (artifact) as a dependency.
> >>>
> >>> Justin's approach using the  element sounds more
> >>> promising.  I'll report back when I've played it with it more..
> >>>
> >>> Thank you all!
> >>> -Babak
> >>>
> >>> On Mon, Oct 25, 2010 at 12:49 PM, Paul Benedict 
> wrote:
>  
>   2.5.6
>  
> 
>  Then for your dependency versions, specify
> ${spring.version}
> 
>  For more information:
>  http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide
> 
>  Paul
> >>>
> >>>
> >>>
> >>> On Mon, Oct 25, 2010 at 12:49 PM, Justin Edelson
> >>>  wrote:
>  Use a property and/or dependency management in a shared parent POM.
>  Spring has multiple modules, so it is frequently useful to store the
>  common version for all modules in a single property and then specify
>  each relevant module in a dependencyManagement element.
> 
>  Justin
> >>>
> >>>
> >>>
> >>>
> 
>  On Mon, Oct 25, 2010 at 1:45 PM, Babak Farhang 
> wrote:
> > Hi everyone,
> >
> > Say I have a number of modules that share a dependency on Spring. I'd
> > like to centralize the version number of the Spring library that I'm
> > using, that is, the version these modules depend on. I.e. I don't
> want
> > the version number of the Spring dependency to be duplicated across
> > many pom files. What's the "maven way" for doing this?
> >
> > -Babak
> >
> > -
> > 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
> >>>
> >>>
> >>
> >> -
> >> 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
>
>


-- 
Vincent

Re: Shared Assembly With Additional Files

[Vincent Latombe]

I had a similar requirement, and I ended up using dependency:unpack.
Otherwise, you could try using
http://maven.apache.org/plugins/maven-remote-resources-plugin/

2010/10/21 Mike Lenner 

> Seems no one's doing this.  Guess I'll go the route of
> dependency:unpack and just reference the target unpack directory in my
> shared assembly.
>
> On Wed, Oct 20, 2010 at 7:45 PM, Mike Lenner 
> wrote:
> > I'd like my shared assembly to be used to import additional files I'd
> > like to include in my final assembly.  Something like:
> >
> > shared-assembly/pom.xml
> > shared-assembly/src/main/resources/assemblies/my-assembly.xml
> > shared-assembly/src/main/resources/common/README
> >
> > my-assembly.xml:
> >
> > ...
> > 
> >common
> >
> >README
> >
> >   /
> > 
> > ...
> >
> > So, whatever project uses my-assembly.xml from shared-assemby will get
> > the README file as well.
> >
> > I've seen this done alternatively by putting README in it's own
> > project, using dependency:unpack during the process-resources phase,
> > and then referencing that file in the assembly.  But, it seems like
> > the above is cleaner.
> >
> > Thanks,
> > Mike
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Vincent

Re: maven-versions-plugin version comparism

[Vincent Latombe]

Hello,

About version comparator themselves, I couldn't find one that fit my use
case which is, multiple development branches evolving in parallel, with
pseudo releases.

For example, I can have versions like 1.0-1234-01, 1.0-1234-02, 1.0-5678-01,
and I want to match with a version range only versions produced by a
specific branch.

To implement this, I made a modified version of v-m-p in order to make
VersionComparator a plexus component.

This way, I can inject a custom VersionComparator implementation in order to
compute the versions order as I wish.

If you're interested, I can submit the patch.

Cheers,

Vincent
2010/10/21 Stephen Connolly 

> I have not tested a file: based URL, only http: (because if you are
> using these rules you really need to publish them to your entire team)
>
> On 21 October 2010 15:13, Moser, Christian  wrote:
> > Yes I did, I tried to call the plugin with:
> > 'D:\MNet\Tools\maven\bin\mvn.bat
> -Dmaven.version.rules=file:///C:/Users/cmo/Desktop/rules.xml
> -Dmaven.repo.local=C:\Java\.m2\repository --update-snapshots
> org.codehaus.mojo:versions-maven-plugin:1.2:display-dependency-updates'
> >
> > rules.xml content:
> > 
> >  
> > (also tried numeric)
> >  
> > 
> >
> > But it didn't work. Is there any possibility to configure version number
> rules in more detail?
> >
> > -Ursprüngliche Nachricht-
> > Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> > Gesendet: Donnerstag, 21. Oktober 2010 13:14
> > An: Maven Users List
> > Betreff: Re: maven-versions-plugin version comparism
> >
> > Did you read the FAQ?
> >
> > http://mojo.codehaus.org/versions-maven-plugin/faq.html#comparisonMethod
> >
> > On 21 October 2010 11:56, Moser, Christian  wrote:
> >> I've got following effect with the maven versions plugin 1.2.
> >>
> >>
> >>
> >> If we release a milestone of our software, we declare the components
> >> which are included in the milestone with [version]-[unrel]-[revision].
> >> When the software is in the release process, we remove the additional
> >> declaration. For example: Version 1.1.0-unrel-0038381 will be
> >> transformed to 1.1.0, so in fact, 1.1.0 is newer than
> >> 1.1.0-unrel-0038381.
> >>
> >>
> >>
> >> I don't know why the plugin acts like this:
> >>
> >>
> >>
> >> org.codehaus.mojo:versions-maven-plugin:1.2:display-dependency-updates
> >> will
> >>
> >> ...
> >>
> >> The following dependencies in Dependency Management have newer versions:
> >>
> >>  SnakeYAML:SnakeYAML ... 1.2 -> 1.3
> >>
> >>  mnet:comp-accessoriesconfig . 1.1.0 -> 1.1.0-unrel-0038381
> >>
> >>  mnet:comp-accessoriesconfig-if .. 1.1.0 -> 1.1.0-unrel-0038381
> >>
> >>  mnet:comp-accessoriesconfigview . 1.1.0 -> 1.2.0-unrel-0039226
> >>
> >>  mnet:comp-accessoriesconfigview-if .. 1.0.0 -> 1.0.0-unrel-0027036
> >>
> >> ...
> >>
> >>
> >>
> >> Do you know why?
> >>
> >>
> >>
> >>
> >
> > -
> > 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
>
>


-- 
Vincent

Re: Maven SCM plugin and CCRC

[Vincent Latombe]

Hello,

as far as I know, there is no scm implementation of CCRC for Maven.
Clearcase Base/UCM are partially supported, it is far from perfect to be
able to do the checkout/release roundtrip. I am guessing you read the
documentation for the Clearcase (heavy client) implementation

Cheers,

Vincent

2010/10/20 Lucas, Jeffrey A. 

> I'm having an issue getting the Maven SCM Plugin configured to use CCRC
> (ClearCase Remote Client v7.1.1).
>
>
>
> 1. What should the clearcase-settings.xml for Clear Case and
> location
>
> 2. What are the SCM setting  settings 
>
> 3. Is there anything in the POM that is needed for configuration of
> the SCM plugin
>
>
>
> Thanks,
>
> Jeff
>
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
> is for the sole use of the intended recipient(s) and may contain
> confidential
> and privileged information or otherwise protected by law.  Any unauthorized
> review, use, disclosure or distribution is prohibited.  If you are not the
> intended recipient, please contact the sender by reply e-mail and destroy
> all copies of the original message.




-- 
Vincent

Re: Strange behaviour on resource plugin

[Vincent Latombe]

Hello,

Do you define the version of maven-resources-plugin in your pom ? Are you
using profiles?

2010/10/19 Søren Krum 

> Hi!
>
> I have detected a strange bahaviour of the maven resource plugin, and i
> am wondering if someone can give me a hint, what is going wrong here.
>
> One of my maven projects uses the resource plugin to copy some
> configuration files with some placeholders in them.
>
> When running maven from eclipse, the placeholders are nicely replaced
> with some values from the pom file, but when starting maven from the
> console, this replacement does not take place.
>
> My eclipse uses a maven 3.0 snapshot, while i tried maven 2.2.1 and 3.0
> from the command line, both not eager to do the replacement.
>
> To make this behaviour even stranger, i detected this failing
> replacement after i updated my os from ubuntu 8/04 to 10/04, but i have
> no idea if that is really connected. I did not touch the maven
> installations at all, so it is a bit confusing
>
> Any idea is highly welcome :-)
>
> --
> Med vennlig hilsen
>
> Søren D. Krum
> Systemutvikler/system developer
> UNINETT FAS
> + 47 73557859
>
> There are 10 different kind of people in the world, those who understand
> binary and those who don't
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Vincent

Re: A project uses a resource defined in a module that it does not depends upon

[Vincent Latombe]

Without any example project (at least the pom.xml for the different
modules), I don't think anybody will be able to help you.

Have you checked dependency:tree on B1?

2010/10/19 Daniele Dellafiore 

> Hi, I have this situation.
>
> Project A and B have many modules. Everyone has a configuration in
> which the root pom defines modules and all the dependency management,
> all the submodules uses root A pom as parent. Before I used to have a
> separate parent project as onother module but in the end did not seem
> really necessary.
>
> Module B1 uses some of the modules of A, but not everyone,
>
> now, I expect that if B1 depends on A1 and A2, it will not have any
> relation to A3.
> But what happens? That B1 see a file in the classpath of A3, to be
> precise, spring loads a properties file that is in
> A3/src/main/resources, overriding other properties.
> In fact, if from A pom I remove the A3 modulo, the properties file is
> not loaded anymore.
>
> I suspect that this happen because A1/2/3 all has A as parent pom.
> But this behavior really seem strange to me.
>
> --
> Daniele Dellafiore
> http://danieledellafiore.net
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Vincent

Re: Questions on SNAPSHOTs

[Vincent Latombe]

Hello Brian

What you assume is right : if the timestamp of a remote artifact is more
recent than the timestamp of a local artifact (under .m2), it will download
the version from the remote repository. This will be happening depending on
the updatePolicy (daily by default), or if you add -U flag to the command
line.

If you want to be sure that your local changes are picked up every time and
not overriden by a remote snapshot, you have 2 options :
- recompile your local changes to component A at least once a day (with
default value of updatePolicy which is daily)
- set updatePolicy to "never". In this case, Maven will download remote
snapshots artifacts only if you don't already have them locally.

The drawback of the second option is that you'll need to use -U each time
you want new remote snapshots, but at least you won't be surprised.

Hope it answer your interrogations,

Cheers,

Vincent

2010/10/16 

> My apologies for my previous post.  That's what I get for trying to save a
> step by replying to someone else's post, but forgetting to change the
> subject :-[
>
> Hi all,
>
> I could use some clarification on how SNAPSHOTs work.
>
> Scenario:
>
> - Maven 2.2.1
> - componentB depends on componentA, both are being built as snapshot
> versions.
> - I have the source code for both components locally and have built and
> installed both to my local repo (mvn install)
> - Both components are also built on a CI server and the snapshot artifacts
> are deployed to our in-house Artifactory repo.
>  Builds occur automatically whenever a change is detected by our CI server.
>
> Questions:
>
> Let's say I'm working on componentB. When building componentB, in what
> cases will componentA be downloaded from Artifactory?
> That is, what controls whether I am building componentB against the version
> of componentA that I built and installed in my local repo
> or against a newly-downloaded version that had been deployed to
> Artifactory?
>
> How is all of this affected by the snapshots updatePolicy in my settings?
> By default, does a new version of componentA get downloaded
> every day (assuming a new one has been deployed to Artifactory)?
>
> Thanks.
>
> -brian
>
>
> -
> 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
>
>


-- 
Vincent

Re: maven eclipse plug-in refresh problem

[Vincent Latombe]

Don't use mvn eclipse:eclipse if you want to use the m2eclipse plugin. Use
Import > Existing Maven project.

2010/10/11 Davide 

> Hi,
>
> I have installed the maven eclipse plug-in from:
>
> http://m2eclipse.sonatype.org/
>
>
> Now I have more projects in my eclipse workspace. I have run mvn
> eclipse:eclipse and imported
> the projects in eclipse. I have removed projects references and each
> project will use jar in the
> maven local repository (as the mvn eclipse:eclipse do)
>
> Now I have run "mvn install" in one project. I have configured in the
> "Run configurations" to
> refresh the workspace after the command.
>
> The problem is that other projects, that will use this jar, are not
> refresh/rebuild as expected. Only
> making manually refresh does not work. I need to manually "clean all
> project and build" too..
>
> Any help?
>
>
> --
>   _|  _.o  _|  _
>  (_| (_| \/ | (_| (/_
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Vincent

Re: Is dependency:copy-dependencies config property broken?

[Vincent Latombe]

Hi,

Your execution is attached to the lifecycle. You'll get the expected
behaviour if you type mvn package, not by calling directly the mojo from
command line.

2010/10/11 Steve Francolla 

> Help!  My dependencies only ever get written to the default
> ${basedir}/target/dependency dir.
>
> Usage:
> mvn dependency:copy-dependencies
>
> Pom.xml segment:
> -
>  
>
>  
>
>  
>org.apache.maven.plugins
>maven-dependency-plugin
>
>  
>copy-dependencies
>package
>
>  copy-dependencies
>
>
>
> ${basedir}/war/WEB-INF/lib/
>  false
>  false
>  true
>  gwt-user,gwt-dev
>
>  
>
>  
>
>  
>
>  
> -
>
>
> Thanks.
>
>
> SF
>



-- 
Vincent

Re: Maven WAR Plugin - Modify/Rename files before WAR

[Vincent Latombe]

Hello,

war:war is called during package phase, so at prepare-package phase you have
nothing available. I think the war-plugin should be updated to take that
into account.

A possible workaround is to bind an execution of war:exploded during the
prepare-phase, then you do your stuff with antrun, and finally it is
packaged using war:war.

Vincent

2010/10/7 Jesse Farinacci 

> Hi Lukas,
>
> On Thu, Oct 7, 2010 at 8:59 AM, Lukas Bradley
>  wrote:
> >
> > I would love to use the maven-antrun-plugin, but it doesn't look like
> > there is a stage where the war plugin would cede control, or allow
> > something to pre-process the files that have been copied to the target
> > directory.
>
> The prepare-package phase doesn't get you there? This was introduced
> around 2.1 or so..
>
>
> http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference
>
> -Jesse
>
> --
> There are 10 types of people in this world, those
> that can read binary and those that can not.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Vincent

Re: Can't specify distributionManagement in settings.xml

[Vincent Latombe]

In Maven/Nexus terminology, you deploy a release candidate to a staging area
(#2) in your example. This artifact (or group of artifacts) is then made
available to a group of people for validation (it can be automated or
manual). Once it's validated it is promoted and copied to the release
repository.

In most Maven artifacts you'll find the version embedded within the artifact
itself (by default, in java archives it will embed the pom.xml). It is also
useful to fill in files like MANIFEST.MF with the artifact information so
these can be retrieved at runtime. That's why once deployed, an artifact
coordinates are immutable.

I hope it answers your question,

Vincent

2010/10/7 Phillip Hellewell 

> On Wed, Oct 6, 2010 at 3:50 PM, Phillip Hellewell 
> wrote:
> >
> > No, there are basically there types of builds I want to do.  Most
> > people don't have a stage between snapshot and release, so I'm
> > guessing that is why I am not getting any clear direction about the
> > best way to do this.
> > 1. A snapshot build made by a developer that can be deployed to a
> > snapshot repo.  Ver = "1.0-SNAPSHOT".
> > 2. A "staging" build made by a build machine.  Can this go into the
> > snapshot repo?  Ver = "1.0-tag-TAGNAME".
> > 3. A release build.  Will be deployed to a release repo. Ver =
> > "1.0-tag-TAGNAME".
>
> Sorry to reply to myself, but I have a guess what you are all
> thinking.  #2 builds are snapshots so just name them as such, e.g.,
> "1.0-tag-TAGNAME-SNAPSHOT".
>
> I think that does make the most sense, since it makes it more clear
> that these are not release artifacts.
>
> So I'm only left with one question.  Once a snapshot is approved for
> release, why should I have to go check out the project and rebuild it
> and everything with the -SNAPSHOT removed?  Is there a mechanism or
> tool (Nexus Pro perhaps?) that can copy an artifact from the snapshot
> repo to the release repo while removing the -SNAPSHOT from the
> version?
>
> Phillip
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Vincent

Re: Company-wide settings

[Vincent Latombe]

To handle distributionManagement, I define the url as a property that is
defined in settings.xml.
This allow me to define the whole connectivity from settings.xml. If ever my
repository changed, I just need to update settings.xml on my build machines,
instead of releasing a new parent and bumping parent version in all
projects.


2010/10/5 Siegmann Daniel, NY 

> Hi Phillip,
>
> This is easy enough to solve IME. Commit a Maven installation to your
> preferred repository (CVS, SVN, etc.), then all your developers can
> obtain that installation by checking it out of the repository. If
> something is changed you can modify settings.xml and commit to the repo,
> then everyone just has to update.
>
> If you need multiple versions just keep multiple copies in the repo.
>
> (This is how it works at my company. When Maven 3.0 is released I'll put
> it in my local workspace, update the settings.xml to point to our Nexus
> installation, and commit everything. Then I'll send out an email letting
> everyone know it's there.)
>
> Note that if you're using m2eclipse you'll want to point it to this
> installation (rather than using the embedded installation).
>
> ~Daniel
>
> -Original Message-
> From: Phillip Hellewell [mailto:ssh...@gmail.com]
> Sent: Sunday, October 03, 2010 5:34 PM
> To: Maven Users List
> Subject: Company-wide settings
>
> I see that Maven can have a settings.xml at both the "Global Level"
> and "User Level".  Is there a way to have a settings.xml that can be
> referenced (or included) from a pom.xml, whose settings would apply
> first but could be overridden by a global or user settings.xml.
>
> The idea is to have a shared "company-level" settings.xml with settings
> like profiles that most developers will want, and to have them
> automatically available.  The alternative is for everyone to manually
> append it to their global or user-level settings.xml.
>
> Phillip
>
> -
> 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
>
>


-- 
Vincent

Re: Maven failing due to javac path issue -- Windows

[Vincent Latombe]

I'm guessing your inherit a parent pom that has a compiler plugin
configuration. Isn't it?

2010/9/7 Enrique Gaona 

> Vince,
> I don't have maven-compiler-plugin and settings.xml configured, but why
> should I? The JAVA_HOME should *supposedly* be sufficient. I do agree with
> you, that by adding the maven-compiler-plugin to the parent pom.xml will fix
> my angst, but I shouldn't have to do that. From the debug output, [DEBUG]
> (f) executable = null/bin/javac, the path is pointing to null.
>
>
> Enrique
>
>
>
> [image: Inactive hide details for Vincent Latombe ---09/07/2010 12:16:37
> PM---What's your effective pom? (especially maven-compiler-plu]Vincent
> Latombe ---09/07/2010 12:16:37 PM---What's your effective pom? (especially
> maven-compiler-plugin configuration?)
>
>
> *Vincent Latombe *
>
> 09/07/2010 12:15 PM
>  Please respond to
> "Maven Users List" 
>
>
>
> To
>
> Maven Users List 
> cc
>
>
> Subject
>
> Re: Maven failing due to javac path issue -- Windows
> What's your effective pom? (especially maven-compiler-plugin
> configuration?)
> I'm guessing something like a property that is supposed to be set through a
> profile in settings.xml depending on your environment is not defined.
>
> 2010/9/7 per-henrik hedman 
>
> > what's the output from "mvn -version"? Could help determine what the
> > actual value of JAVA_HOME according to mvn.
> >
> > What resides in the  C:\IBM\ibm-java-sdk-60-win-i386\sdk\bin ?
> >
> > can you run javac -version?
> >
> > Per-Henrik
> >
> > On Tue, Sep 7, 2010 at 6:43 PM, Trevor Harmon  wrote:
> > > On Sep 7, 2010, at 9:34 AM, Enrique Gaona wrote:
> > >> Can't say if it works with Oracle's JDK, since I've not tried it
> before.
> > >>
> > > Trying with Oracle's would help determine where the problem lies.
> > >> One workaround would be specify the maven-compiler-plugin in the
> parent
> > pom.xml, but I really don't want to do that.
> > >>
> > >
> > > Can't you just point JAVA_HOME and your PATH to the Oracle JDK?
> > >
> > > Trevor
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
>
> --
> Vincent
>
>


-- 
Vincent

Re: sharing assembly descriptor

[Vincent Latombe]

Hi,

- first, you need to put your assembly under
src/main/resources/*assemblies* (as
indicated in the link you provided)
- then, you should be able to reference either the xml using the descriptor
tag like you did

2010/9/7 

> Hi all,
>
> I'm trying to use a shared assembly descriptor as described in
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html
>
> Unfortunately it fails with
>
> Error:
> java.net.MalformedURLException: no protocol: assembly-desc.xml
>
> My setup is:
>
> 1) A project calles "Assembly-Descriptor" which has the file
> "assembly-desc.xml" under src/main/resources. This is packaged in a jar and
> installed in my local repository
> 2) A project called "Assembly-parent" which is the parent pom for all
> projects which require the descriptor. This is packaged as pom and the pom
> contains:
> 
>
>de.test-fw
>Assembly-Descriptor
>0.0.1-SNAPSHOT
>
>
>
>
>
>
>maven-assembly-plugin
>2.2-beta-5
>
>
>assembly-desc.xml
>
>
>
>
>make-assembly
>package
>
>single
>
>
>
>
>
>
>
> 3) A project called "Assembly-project", which finally shall use the shared
> descriptor. Its packaged as jar and has the "Assembly-parent" as parent pom.
> Its pom only contains additionally
> 
>
>
>maven-assembly-plugin
>
>
>
>
> Running this results in the error that it does not find the
> assembly-desc.xml file. The "Assembly-project" does have the dependency to
> the "Assembly-Descriptor" project.
>
> What is going wrong ?
>
> Thanks
>
>
>
>
>
>
>


-- 
Vincent

Re: Maven failing due to javac path issue -- Windows

[Vincent Latombe]

What's your effective pom? (especially maven-compiler-plugin configuration?)
I'm guessing something like a property that is supposed to be set through a
profile in settings.xml depending on your environment is not defined.

2010/9/7 per-henrik hedman 

> what's the output from "mvn -version"? Could help determine what the
> actual value of JAVA_HOME according to mvn.
>
> What resides in the  C:\IBM\ibm-java-sdk-60-win-i386\sdk\bin ?
>
> can you run javac -version?
>
> Per-Henrik
>
> On Tue, Sep 7, 2010 at 6:43 PM, Trevor Harmon  wrote:
> > On Sep 7, 2010, at 9:34 AM, Enrique Gaona wrote:
> >> Can't say if it works with Oracle's JDK, since I've not tried it before.
> >>
> > Trying with Oracle's would help determine where the problem lies.
> >> One workaround would be specify the maven-compiler-plugin in the parent
> pom.xml, but I really don't want to do that.
> >>
> >
> > Can't you just point JAVA_HOME and your PATH to the Oracle JDK?
> >
> > Trevor
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Vincent

Re: Correcting a groupID

[Vincent Latombe]

You'll need a dependencyManagement to force A to use c-n:c-n:12 which will
depends on org.apache.commons.net:c-n:12.

2010/8/26 Benson Margulies 

> On Thu, Aug 26, 2010 at 8:41 AM, Stephen Connolly
>  wrote:
> > Why not have commons-net:commons-net become an empty jar which has a
> > dependency on org.apache.commons:net
> >
> > that way, anyone with the old GA coords will just have an empty jar on
> their
> > classpath and the correct jar as well
>
> i don't see it.
>
> Component A is sitting out there with a dependency on c-n:c-n:1
>
> Component B has a dependency on A and also on c-n:c-n:1
>
> Sebb changes the group ID.
>
> Now, A still depends on c-n:c-n:1
> B depends on org.apache.commons.net:c-n:12, and on A
> And we've got two dueling versions in classpath.
>
> It doesn't help to release a new version c-n:c-n:12, since A isn't
> using a range, it's pointing at '1'.
>
> Am I missing something?
>
>
>
>
>
>
> >
> > On 26 August 2010 00:13, Benson Margulies  wrote:
> >
> >> Let me recap the pain scenario here:
> >>
> >> Existing poms reference commons-net under the old group ID.
> >>
> >> commons-net releases a new version under a new group ID.
> >>
> >> Dependencies under the old group ID won't be seen as 'the same thing'
> >> as the new group ID, so
> >>
> >> a project that references the new group ID and has a dependency that
> >> uses the old group ID gets both in the classpath, and probably
> >> experiences chaos until repaired with exclusions.
> >>
> >> Unless maven grew a feature whereby the new artifact could explicitly
> >> declare itself a successor of the old one under the other name, this
> >> is unavoidable. Either don't rename or live with this as an annoyance
> >> to the users of the new version. Renaming packages might help, insofar
> >> as the two versions might then coexist happily.
> >>
> >> -
> >> 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
>
>


-- 
Vincent

Re: Question to: "No primary artifact to install..."

[Vincent Latombe]

Huh? Is this some kind of predefined profile? I think you got mixed up
Anders ;)


2010/8/26 Anders Hammar 

> mvn install -P release-profile
>
> Should do it.
>
> /Anders (mobile)
>
> Den 2010 8 26 16:13 skrev "Thomas Trepper" :
> > Hi Mathus,
> >
> > thanks a lot for your help. I have updated my pom as you told me and I
> > executed mvn install, which works. Thanks a lot. But it produces only
> > the main jar. But I want to have javadoc, sources, etc also as jars,
> > therefore I executed
> > mvn clean source:jar source:test-jar jar:test-jar javadoc:jar install
> > which now works also fine, it produces all jars as wanted, BUT source,
> > doc, test and test-source are ALSO included in the main-jar, which is
> > *not*, what I want.
> >
> > How can I produce main artifact-jar and additionally (NOT included)
> > javadoc, sources, test and test-sources-jars?
> >
> > Thanks everybody till now,
> >
> > Thomas
> >
> >
> >
> >
> > Am 26.08.2010 16:03, schrieb Baptiste MATHUS:
> >> First, I've simplified the pom your provided.
> >> http://pastebin.com/64XC39VS is totally equivalent for what you put.
> >>
> >> Could you run mvn install and show us the output?
> >>
> >> Thanks
> >>
> >> 2010/8/26 Baptiste MATHUS
> >>
> >>> Specifying that many plugins as you did is just a mean of getting in
> >>> trouble soon.
> >>> Launching a specific plugin, particularly some, with maven is something
> one
> >>> almost never does.
> >>>
> >>> You'd better post here what's the problem running mvn package. This
> should
> >>> work this way, simply.
> >>>
> >>> Using maven the way you show is ant'ish, and it's not getting to the
> point
> >>> where a classical mvn package just package the project, even when not
> >>> knowing anything about your project.
> >>>
> >>> Cheers
> >>>
> >>> 2010/8/26 Thomas Trepper
> >>>
> >>> Yes, I tried that first, but it did not work and during the experiments
> to
>  solve the issue the long commandline arised. Sorry for that, but the
> simple
>  mvn install did not do it either. I will get the same error...
> 
> 
>  Am 26.08.2010 15:12, schrieb Anders Hammar:
> 
>  Why the extremely troublesome mvn command line? Why not just "mvn
> > install"?
> >
> > /Anders
> >
> > On Thu, Aug 26, 2010 at 14:20, Thomas Trepper
> > wrote:
> >
> > Hi all,
> >> this is a snippet from my build, which says, that I have an artifact
> and
> >> attached artifacts, but, whatever I am doing, I always get the
> message:
> >> No
> >> primary artifact to install, installing attached artifacts instead.
> >>
> >> Can anybody point me to the right direction please?
> >>
> >> Thanks a lot and best regards,
> >>
> >> Thomas
> >>
> >> P.S: I start my build from eclipse with the following targets:
> >> clean validate initialize resources:resources compiler:compile
> >> jar:jar
> >> source:jar source:test-jar jar:test-jar javadoc:jar test
> install:install
> >>
> >>
> >>
> >> [INFO]
> >> [INFO] --- maven-install-plugin:2.3:install (default-cli) @
> logging-api
> >> ---
> >> [DEBUG] Created new class realm
> >> plugin>org.apache.maven.plugins:maven-install-plugin:2.3
> >> [DEBUG] Populating class realm
> >> plugin>org.apache.maven.plugins:maven-install-plugin:2.3
> >> [DEBUG] Included:
> >> org.apache.maven.plugins:maven-install-plugin:maven-plugin:2.3
> >> [DEBUG] Included: org.codehaus.plexus:plexus-utils:jar:1.5.6
> >> [DEBUG] Included: junit:junit:jar:3.8.1
> >> [DEBUG] Included: org.codehaus.plexus:plexus-digest:jar:1.0
> >> [DEBUG] Excluded: org.apache.maven:maven-plugin-api:jar:2.0.6
> >> [DEBUG] Excluded: org.apache.maven:maven-project:jar:2.0.6
> >> [DEBUG] Excluded: org.apache.maven:maven-settings:jar:2.0.6
> >> [DEBUG] Excluded: org.apache.maven:maven-model:jar:2.0.6
> >> [DEBUG] Excluded:
> >>
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1
> >> [DEBUG] Excluded: classworlds:classworlds:jar:1.1-alpha-2
> >> [DEBUG] Excluded: org.apache.maven:maven-profile:jar:2.0.6
> >> [DEBUG] Excluded: org.apache.maven:maven-artifact-manager:jar:2.0.6
> >> [DEBUG] Excluded:
> org.apache.maven:maven-repository-metadata:jar:2.0.6
> >> [DEBUG] Excluded: org.apache.maven:maven-artifact:jar:2.0.6
> >> [DEBUG] Excluded: org.apache.maven:maven-plugin-registry:jar:2.0.6
> >> [DEBUG] Configuring mojo
> >> 'org.apache.maven.plugins:maven-install-plugin:2.3:install' with
> basic
> >> configurator -->
> >> [DEBUG] (f) artifact = com.blueclaim:logging-api:jar:0.0.4-SNAPSHOT
> >> [DEBUG] (f) attachedArtifacts =
> >> [com.blueclaim:logging-api:java-source:sources:0.0.4-SNAPSHOT,
> >> com.blueclaim:logging-api:java-source:test-sources:0.0.4-SNAPSHOT,
> >> com.blueclaim:logging-api:test-jar:tests:0.0.4-SNAPSHOT,
> >> com.blueclaim:logging-api:javadoc:javadoc:0.0.4-SNAPSHOT

Re: Want primary artifact of type 'zip'

[Vincent Latombe]

Or use an assembly with 

2010/7/29 Jörg Schaible 

> Benson Margulies wrote:
>
> > So,
> >
> > I have a project whose only purpose is to deliver a zip file under a
> > G/A/V triple. In a moment, I will put myself out of my misery by
> > specifying a classifier.
> >
> > [WARNING] Configuration options: 'appendAssemblyId' is set to false,
> > and 'classifier' is missing.
> > Instead of attaching the assembly file:
> > /Users/benson/x/rap/ras/gate_home/target/gate-home-1-SNAPSHOT.zip, it
> > will become the file for main project artifact.
> >
> > Now, I am whining that: if my packaging is pom, I get that message,
> > but no zip file gets deployed. If my packaging is jar, it gets renamed
> > to .jar.
>
> Use the build-helper plugin, that can be used to define any file as primary
> artifact.
>
> - Jörg
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Vincent

Re: what happened to release:update-versions?

[Vincent Latombe]

Hello,

you are not using the latest release plugin version, which is 2.0

2010/7/24 Shan Syed 

> is it gone? perhaps in favor of the
> http://mojo.codehaus.org/versions-maven-plugin/ plugin?
>
> >mvn release:update-versions
> ...
> [INFO] Required goal not found: release:update-versions in
> org.apache.maven.plugins:maven-release-plugin:2.0-beta-8
>
> and
>
> >mvn
> org.apache.maven.plugins:maven-release-plugin:2.0-beta-9:update-versions
> ...
> [INFO] Required goal not found:
> org.apache.maven.plugins:maven-release-plugin:2.0-beta-9:update-versions in
> org.apache.maven.plugins:maven-release-plugin:2.0-beta-9
>



-- 
Vincent