Re: Invoking a plugin programmatically using maven 3 and scala

[Andreas Gies]

Hi all,

just to finish up the thread, I have fixed this by adding a 
@RequiresDependencyResolution(test)

to the mojo calling the dependency plugin.

Thanks and best regards
Andreas

Am 10/21/10 3:10 AM, schrieb Andreas Gies:

 Hello,

a last update for today. I have compared a debug session of

mvn dependency:resolve

with what happens in my code. It seems, that when calling the plugin 
from the command line, at the end of the day

a class named

org.apache.maven.lifecycle.internal.MojoExecutor

kind of controlls he execution and also takes initiates the desired 
dependency resolution before the plugin code is called.

Therefore the dependency plugin finds the dependencies and all is good.

However, when i invoke

BuildPluginManager.executeMojo

the dependency resolution does not happen and the dependency plugin 
doesnt find them.



I have now the options to use a non-public API and reuse the 
MojoExecutor code or kinfd of Mimick that behavior.
I kind of have the feeling that I am missing something very obvious in 
the API. A pointer to a correct call triggering
dependency resolution would be great. Perhaps I have selected the 
wrong entrypoint into the API ?


Thanks and best regards
Andreas

Am 10/21/10 2:12 AM, schrieb Andreas Gies:

 Hello,

another update on this. From studying the source code I was under the 
impression that mojoDescriptor.getConfiguration
would give me the default configuration, but it is 
mojoDescriptor.getMojoConfiguration.


A debug session has shown, that the dependency plugin actually 
executes, but somehow doesn't recognize the dependencies

of the project.

Best regards
Andreas

Am 10/20/10 8:28 PM, schrieb Andreas Gies:

 Hello,

I forgot to mention that the output from the scala plugin is 
embedded in the build.log produced by the mavan invoker plugin.


Best regards
Andreas

Am 10/20/10 8:22 PM, schrieb Andreas Gies:

 Hello,

I am still banging my head on this problem, though I got a bit 
farther.
I found a link via Google pointing to the maven site plugin and 
there to the
DefaultMavenReportExecutor. I have tried to mimick the behavior in 
my special
case and for testing I want to invoke the maven dependency plugin, 
namely

the unpack dependencies goal.

It seems to work if I provide all the missing paramters (like 
project etc.) into

the configuration as expressions as follows

val config : Xpp3Dom = Xpp3DomUtils.mergeXpp3Dom(
   buildConfiguration(
 Map(
  outputDirectory - test,
  project - ${project},
  local - ${localRepository},
  reactorProjects - ${reactorProjects} ,
  remoteRepos - ${project.remoteArtifactRepositories}
 )
   ),
  convert(md)
)

That approach doesn't give me any Exceptions. I would have expected 
that all parameters except the non-default output directory
would be resolved as the dependency plugin gives default 
expressions for them.



However, this approach removes the parameter exceptions from 
before, but calling it doesn't unpack the dependencies (nothing 
happens really).


I have tried to use the

  LifecycleExecutor.executeForkedExecutions
  BuildPluginManager.executeMojo

and even tried to call execute on the configured Mojo (which I 
probably shouldn't do ?)


I have attached a sample build output and also the code of my scala 
based mojo.


Apart from studying the source code of the API and some sample 
plugins, is there documentation how the

new plugin API is supposed to work ?

Am I trying to do something out of the ordinary here ? (I know I 
could configure the dependency plugin in the
pom but as this is *such* an essential step in the final mojo I 
don't want to give the user the option of leaving it

out ... and I wanted to learn some more maven internals).

Has anyone an example of initializing and calling a mojo from 
within a mojo using the new API ? - Java is fine as

well, I can adopt it to scala as a learning exercise.

I think I might be missing something in terms of hooking up or 
registering the project with the dependency plugin
though the build output indicates that the project is referenced 
correctly.



Any hints would be really appreciated; if I am hitting the wrong 
list, please let me know.


Thanks in advance
Andreas

Am 10/13/10 9:27 AM, schrieb Andreas Gies:


 Hello Maveners ,

mainly for self learning purposes I am trying to build some 
plugins for Maven 3 using the Scala language.
One of the things I had going before (Maven 2  Java based) is to 
invoke another plugin programmatically.


Now I am trying to invoke the dependency plugin, namely the 
unpack-dependencies goal and am running

into a rather cryptic error message:

[ERROR] Failed to execute goal 
com.progress.maven.plugins:plugin-sandbox:8.0-SNAPSHOT:echo 
(default-cli) on project test-plugin: The parameters 'proje
ct', 'local', 'remoteRepos', 'reactorProjects' for goal 
org.apache.maven.plugins:maven-dependency-plugin:2.1:unpack-dependencies 
are missing or invali

Re: Mirror of Central in France

[Samuel Le Berrigaud]

Nice. Thanks!

On Wed, Oct 20, 2010 at 17:29, Samuel Langlois
samuel.langl...@antelink.com wrote:
 Hello,

 At Antelink, we love Maven, and we thank the Maven people every day for
 maintaining the Central repository!
 So we thought we could give back a little to the community.
 We just set up a mirror of the Central, based in France, so that European
 Maven users enjoy a better bandwidth.

 We did more than that : we installed a Sonatype Nexus repository manager, in
 order to perform some searches, browse easily, etc.
 It is plugged directly to the Central, so any requested artifact which is
 not there yet is downloaded on-the-fly, and stored for subsequent uses.

 Sonatype announced today that they set up a mirror of the Central in UK.
 All this is aimed at the same goal: having a better Maven experience, and
 keeping Central healthy.

 You can reach the interface of the repository manager here :
 http://maven.antelink.com/
 To make Maven use it, point your own repository manager to it, or add this
 to your ~/.m2/settings.xml file :

 settings
 mirrors
 mirror
 idantelink.com/id
 nameAntelink Mirror/name
 urlhttp://maven.antelink.com/content/groups/public//url
 mirrorOfcentral/mirrorOf
 /mirror
 /mirrors
 /settings


 Enjoy !
 --
 Samuel Langlois - Antelink
 http://www.antelink.com/

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



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

Re: scm connection in parent pom

[Stephen Connolly]

On 20 October 2010 16:36, Phillip Hellewell ssh...@gmail.com wrote:
 On Wed, Oct 20, 2010 at 1:58 AM, Stephen Connolly
 stephen.alan.conno...@gmail.com wrote:
 (snip)
 I have a bash script to update the details on a branch, etc... I am
 looking into the possibility of adding this into the maven-scm-plugin,
 e.g. mvn scm:infer -Dprovider=svn of course given that this would
 involve rewriting the pom.xml I'll have to decide how to handle

 Yeah, I really like the idea of having an scm:infer.  You definitely
 got my vote!

 But if it can be inferred while the plugin is running, why exactly
 does it need to get written back into the pom?  Of course, I don't

You did see the -Dprovider=svn

There are N providers not all of them can be inferred... what do we do
if somebody has a svn workspace in a git workspace with .gitignore's
containing .svn and svn:ignore on the root folder containing .git?
That would allow both scm's to function at the same time without being
aware of each other... which should maven choose?

Oh and this git/svn workspace could also be an accurev workspace (no
control files needed to be ignored there) and why not add CVS into the
mix?

 mind it being written into the pom on a tag, and in the pom that goes
 to the repo, but in the trunk and branches the whole idea is to not
 have it present in there so it is always inferred.

but you are going to have to specify at least the provider... so at
least more than nothing will have to go in there... plus when that
-SNAPSHOT gets deployed wouldn't it be nice to know from which branch
it was deployed? oh look the pom has the scm details of the branch it
came from... cool! that was joe's branch which explains why I'm fecked


 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

maven-versions-plugin version comparism

[Moser, Christian]

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?

 

Filtering in assembly plugin (2.2-beta-2 and 2.2)

[Aleksey Didik]

Hello all!

I have used maven-assembly-plugin 2.2-beta-2 before and have those lines in
my descriptor:

files
file
source${basedir}/src/scripts/python/updater.py/source
outputDirectory//outputDirectory
filteredtrue/filtered
/file
/files

Filtering works right, I have got real project version instead of
${project.version}.

After switch to the version 2.2, plugin not filter necessary file (declared
into snippet above). All $properties stay unfiltered.

Is something change between versions?

And one more question, is it possible to use filtered for file sets into
fileSets?

In assembly descriptor description are wrote:
filteredbooleanWhether to filter symbols in the files as they are copied,
using properties from the build configuration. (Since 2.2)
*Default value is*: false.

But into Filtering Some Distribution Files topic are wrote: Filtering is
only enabled inside files so that's what we will use.

Could anybody clear the situation?

Best regards.
-- 

*Aleksey Didik,*

Solution Architect



Tel (Office): + 7 846 342 51 74 ext.242
Mob: +7 927 730 76 43
Skype ID: aleksey.didik





*Maxifier - AOP Technology Award Winner 2010*



*Maxifier is a division of Magenta Corporation Ltd*





*Confidential and/or legally privileged information may be in this email,
which only the intended addressee(s) may access.  If you have received this
email in error, please inform us immediately and delete all copies from your
system.  Magenta Corporation Limited uses anti-virus systems but can take no
responsibility for any viruses which attach to this email.*

Re: maven-versions-plugin version comparism

[Stephen Connolly]

Did you read the FAQ?

http://mojo.codehaus.org/versions-maven-plugin/faq.html#comparisonMethod

On 21 October 2010 11:56, Moser, Christian c...@metrohm.com 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

Re: maven3 profile activation by absense of property

[Frederic Camblor]

Hi !

With name!key/name I don't reproduce the problem with maven 3, but I
reproduce it with mvnsh 0.10 (based on maven 3.0-alpha6) context history.

profile
  idmyprofile/id
  activation
property
  name!blah/name
/property
  /activation
/profile

[mvn 2.2.1]
- mvn help:active-profiles
 shows myprofile is activated
- mvn help:active-profiles -Dblah
 shows myprofile is deactivated
- mvn help:active-profiles -Dblah=blah
 shows myprofile is deactivated

[mvnsh (based on mvn 3.0-alpha6]
- mvn help:active-profiles
 shows myprofile is activated
- mvn help:active-profiles -Dblah
 shows myprofile is deactivated
- mvn help:active-profiles -Dblah=blah
 shows myprofile is deactivated

... re-running mvn help:active-profiles shows myprofile is de-activated !

[mvn 3.0]
- mvn help:active-profiles
 shows myprofile is activated
- mvn help:active-profiles -Dblah
 shows myprofile is deactivated
- mvn help:active-profiles -Dblah=blah
 shows myprofile is deactivated

Frédéric

On Wed, Oct 20, 2010 at 8:15 PM, Kees van Dieren keesvandie...@gmail.comwrote:

 Joachim,

 Profiles can be activated by a property not having a certain value. This
 includes the absence of a property. For you the profile would become:

profiles
profile
iddocumentation/id
activation
property
nameskipDocs/name
 value!true/value
/property
/activation
 ...
/profile
/profiles

 Profile activation can easily be checked with:
 mvn help:active-profiles -DskipDocs
 mvn help:active-profiles -DskipDocs=true
 mvn help:active-profiles -DskipDocs=false

 (not specifying a value makes it true).

 Regards,

 Kees

 --
 Squins | IT, Honestly
 Oranjestraat 23
 2983 HL Ridderkerk
 The Netherlands
 Phone: +31 (0)180 415559
 Mobile: +31 (0)6 30413841
 www.squins.com
 http://twitter.com/keesvandieren
 Chamber of commerce Rotterdam: 22048547
 Boeken voor school en werk bestel je op studieboekencenter.nl
 2010/10/20 Joachim Van der Auwera joac...@progs.be

  On 10/20/2010 12:35 PM, Wendy Smoak wrote:
 
  On Wed, Oct 20, 2010 at 5:32 AM, Joachim Van der Auwera
  joac...@triathlon98.com  wrote:
 
 
  However, since the switch to maven3 this does not worka anymore and
 mvn
  -DskipDocs install will still include the documentation module.
  Do I have to do something different to make this work in maven3?
 
 
  What happens if you do -DskipDocs=abc ?  That will test the
  difference between 'present but empty' and 'present (with a value)'.
 
 
  That doesn't seem to make a difference.
 
  I haven't seen this mentioned in the compatibility notes, so I guess it
 is
  a bug (though it admittedly is a little documented feature).
 
 
  Thanks for the help,
  Joachim
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 

Re: Maven release:branch commiting thinks on tags

[Frederic Camblor]

Up ?

On Fri, Oct 15, 2010 at 7:08 PM, Frederic Camblor fcamb...@gmail.comwrote:

 Hi maven users !

 I learned something some days ago, about maven-release-plugin about its
 branch goal.

 Currently, I execute following command line :

 mvn --batch-mode org.apache.maven.plugins:maven-release-plugin:2.0:branch 
 -DautoVersionSubmodules=true -DtagBase=tags/ -Dtag=1.0.0 
 -DupdateBranchVersions=true -DreleaseVersion=2.0.0 -DbranchBase=branches/ 
 -DbranchName=2.0.0

 My goal, here, is to create a new branch called 2.0.0 from the 1.0.0 tag.

 It works great but I found something crappy : some commit were made on the
 1.0.0 tag hierarchy.
 That is to say, the plugin is acting this way :
 - Checkout tag ${tagBase}${tag} in working directory
 - Modify pom to ${releaseVersion}-SNAPSHOT  scm
 - Commit pom (on tag 1.0.0 !!!)
 - If something is going bad during the next two lines, your tag
 hierarchy will be altered
 - SVN Copy ${tagBase}${tag}/ hierarchy to ${branchBase}${branchName}/
 hierarchy
 - Re-Modify pom in working directory to ${tag}
 - Re-Commit pom on tag 1.0.0

 I would think it would act this way :
 - SVN Copy ${tagBase}${tag}/ hierarchy to ${branchBase}${branchName}/
 hierarchy
 - Checkout ${branchBase}${branchName}/ in working directory
 - Modify pom to ${releaseVersion}-SNAPSHOT
 - Commit pom (on branch !)  scm

 Would it be some reason why the first strategy is applied ?
 Am I badly using release:branch goal ?

 Thanks in advance for your precisions.
 Frédéric

Is it supposed to be safe to use 3.0 and then go back to 2.2.1?

[Benson Margulies]

I ran a build with 3.0, and when I then retreated to 2.2.1, I got
class-not-found errors in maven. Should I report this formally?

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

Re: Is it supposed to be safe to use 3.0 and then go back to 2.2.1?

[Jörg Schaible]

Hi,

Benson Margulies wrote:

 I ran a build with 3.0, and when I then retreated to 2.2.1, I got
 class-not-found errors in maven. Should I report this formally?

that would be strange. I can switch forth and back as I like. Do you use an 
M2_HOME environment setting and probably forget it to set it back? Best 
practice is not to use it at all, because the variable is automatically set 
executing the mvn batch/shell script.

- Jörg


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

War plugin CannotResolveClassException

[Benson Margulies]

Does this ring any bells for anyone?

[INFO] [war:war {execution: default-war}]
[INFO] Packaging webapp
[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] org.apache.maven.model.InputLocation :
org.apache.maven.model.InputLocation :
org.apache.maven.model.InputLocation :
org.apache.maven.model.InputLocation
 Debugging information 
message : org.apache.maven.model.InputLocation :
org.apache.maven.model.InputLocation
cause-exception :
com.thoughtworks.xstream.mapper.CannotResolveClassException
cause-message   : org.apache.maven.model.InputLocation :
org.apache.maven.model.InputLocation
class   : org.apache.maven.plugin.war.util.WebappStructure
required-type   : java.util.LinkedHashMap
path:
/webapp-structure/dependenciesInfo/org.apache.maven.plugin.war.util.DependencyInfo/dependency/exclusions/org.apache.maven.model.Exclusion/locations/entry/org.apache.maven.model.InputLocation
line number : 49
---
[INFO] 
[INFO] Trace
com.thoughtworks.xstream.converters.ConversionException:
org.apache.maven.model.InputLocation :
org.apache.maven.model.InputLocation :
org.apache.maven.model.InputLocation :
org.apache.maven.model.InputLocation
 Debugging information 
message : org.apache.maven.model.InputLocation :
org.apache.maven.model.InputLocation
cause-exception :
com.thoughtworks.xstream.mapper.CannotResolveClassException
cause-message   : org.apache.maven.model.InputLocation :
org.apache.maven.model.InputLocation
class   : org.apache.maven.plugin.war.util.WebappStructure
required-type   : java.util.LinkedHashMap
path:
/webapp-structure/dependenciesInfo/org.apache.maven.plugin.war.util.DependencyInfo/dependency/exclusions/org.apache.maven.model.Exclusion/locations/entry/org.apache.maven.model.InputLocation
line number : 49
---
at 
com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:89)
at 
com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
at 
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
at 
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60)
at 
com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.doUnmarshal(AbstractReflectionConverter.java:225)
at 
com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:162)
at 
com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
at 
com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
at 
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
at 
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60)
at 
com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:71)
at 
com.thoughtworks.xstream.converters.collections.CollectionConverter.populateCollection(CollectionConverter.java:68)
at 
com.thoughtworks.xstream.converters.collections.CollectionConverter.unmarshal(CollectionConverter.java:61)
at 
com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
at 
com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
at 
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
at 
com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshallField(AbstractReflectionConverter.java:246)
at 
com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.doUnmarshal(AbstractReflectionConverter.java:218)
at 
com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:162)
at 
com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
at 
com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
at 
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
at 
com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshallField(AbstractReflectionConverter.java:246)
at 
com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.doUnmarshal(AbstractReflectionConverter.java:218)
at 

Re: Mirror of Central in France

[chemit]

Le Wed, 20 Oct 2010 17:29:52 +0200,
Samuel Langlois samuel.langl...@antelink.com a écrit :

 Hello,
 
Bravo ;)

 At Antelink, we love Maven, and we thank the Maven people every day
 for maintaining the Central repository!
 So we thought we could give back a little to the community.
 We just set up a mirror of the Central, based in France, so that 
 European Maven users enjoy a better bandwidth.
 
 We did more than that : we installed a Sonatype Nexus repository 
 manager, in order to perform some searches, browse easily, etc.
 It is plugged directly to the Central, so any requested artifact
 which is not there yet is downloaded on-the-fly, and stored for
 subsequent uses.
 
 Sonatype announced today that they set up a mirror of the Central in
 UK. All this is aimed at the same goal: having a better Maven
 experience, and keeping Central healthy.
 
 You can reach the interface of the repository manager here : 
 http://maven.antelink.com/
 To make Maven use it, point your own repository manager to it, or add 
 this to your ~/.m2/settings.xml file :
 
 settings
 mirrors
 mirror
 idantelink.com/id
 nameAntelink Mirror/name
 urlhttp://maven.antelink.com/content/groups/public//url
 mirrorOfcentral/mirrorOf
 /mirror
 /mirrors
 /settings
 
 
 Enjoy !
 --
 Samuel Langlois - Antelink
 http://www.antelink.com/
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 



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

Re: maven-versions-plugin version comparism

[Marshall Schor]

This isn't easy to figure out, I think.  Here's my guess.

The thing that explains this is here:
http://maven.apache.org/ref/3.0/maven-artifact/xref/org/apache/maven/artifact/versioning/ComparableVersion.html

This link is found by going to the below referenced link, and then, in that
code, clicking on the link to ComparableVersion

The part that is relevant is this bit:

148 
http://maven.apache.org/ref/3.0/maven-artifact/xref/org/apache/maven/artifact/versioning/ComparableVersion.html#148
 *private* *static* *final* String[] QUALIFIERS = { alpha, beta, 
milestone, rc, snapshot, , sp };

*public* *int* compareTo( Item item )

220 
http://maven.apache.org/ref/3.0/maven-artifact/xref/org/apache/maven/artifact/versioning/ComparableVersion.html#220
 {
221 
http://maven.apache.org/ref/3.0/maven-artifact/xref/org/apache/maven/artifact/versioning/ComparableVersion.html#221
 *if* ( item == *null* )
222 
http://maven.apache.org/ref/3.0/maven-artifact/xref/org/apache/maven/artifact/versioning/ComparableVersion.html#222
 {
223 
http://maven.apache.org/ref/3.0/maven-artifact/xref/org/apache/maven/artifact/versioning/ComparableVersion.html#223
 /// 1-rc  1, 1-ga  1/

This means, I think (I didn't completely understand this code) that if the 
qualifier string
following the dash is one of a small set of strings (such as strings starting 
with
rc or snapshot, etc.) then the rule 1-rc  1 applies.

But if the string following the - is not one of these well known strings, 
then that rule doesn't apply.

-Marshall Schor

On 10/21/2010 7:14 AM, Stephen Connolly wrote:
 Did you read the FAQ?

 http://mojo.codehaus.org/versions-maven-plugin/faq.html#comparisonMethod

 On 21 October 2010 11:56, Moser, Christian c...@metrohm.com 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

[ANN] Release Maven Site Plugin 3.0-beta-3 for maven 3

[Olivier Lamy]

Hi,

The Maven team is pleased to announce the release of the Maven Site
Plugin, version 3.0-beta-3 for Maven 3.
This version is intended to be the version of the Maven Site Plugin for Maven 3.

The Site Plugin is used to generate a site for the project.

You should specify the version in the build section of your project's POM:

plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-site-plugin/artifactId
 version3.0-beta-3/version
/plugin

Release Notes - Maven 3.x Site Plugin - Version 3.0-beta-3


** Bug
* [MSITE-500] - Warning message about missing report plugin
version shows null instead of plugin groupId:aritfactId
* [MSITE-504] - Maven site fails to run due to non-report goals
* [MSITE-505] - Unable to use SVN SCM wagon to upload a site
* [MSITE-506] - Maven3 conflict with plexus-archiver
* [MSITE-507] - report plugin doesn't have dependencies section
coming from build section configuration
* [MSITE-508] - attach-descriptor goals leaks file handlers,
causing sporadic build failures when gpg tries to sign descriptor
during release
* [MSITE-512] - [Regression] Configuration of m-javadoc-p at
reportSet level is not taken into account



** Task
* [MSITE-513] - use release final maven 3.0 artifacts

Have Fun !
-- 
The Maven  Team

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

AW: maven-versions-plugin version comparism

[Moser, Christian]

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:
ruleset comparisonMethod=maven
  rules
rule groupId=mnet comparisonMethod=mercury/ (also tried numeric)
  /rules
/ruleset

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 c...@metrohm.com 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

Re: maven3 profile activation by absense of property

[Joachim Van der Auwera]

Thanks everybody, it is now fixed.

Joachim

On 10/21/2010 01:57 PM, Frederic Camblor wrote:

Hi !

Withname!key/name  I don't reproduce the problem with maven 3, but I
reproduce it with mvnsh 0.10 (based on maven 3.0-alpha6) context history.

profile
   idmyprofile/id
   activation
 property
   name!blah/name
 /property
   /activation
/profile

[mvn 2.2.1]
- mvn help:active-profiles
   

shows myprofile is activated
   

- mvn help:active-profiles -Dblah
   

shows myprofile is deactivated
   

- mvn help:active-profiles -Dblah=blah
   

shows myprofile is deactivated
   

[mvnsh (based on mvn 3.0-alpha6]
- mvn help:active-profiles
   

shows myprofile is activated
   

- mvn help:active-profiles -Dblah
   

shows myprofile is deactivated
   

- mvn help:active-profiles -Dblah=blah
   

shows myprofile is deactivated
   

... re-running mvn help:active-profiles shows myprofile is de-activated !

[mvn 3.0]
- mvn help:active-profiles
   

shows myprofile is activated
   

- mvn help:active-profiles -Dblah
   

shows myprofile is deactivated
   

- mvn help:active-profiles -Dblah=blah
   

shows myprofile is deactivated
   

Frédéric

On Wed, Oct 20, 2010 at 8:15 PM, Kees van Dierenkeesvandie...@gmail.comwrote:

   

Joachim,

Profiles can be activated by a property not having a certain value. This
includes the absence of a property. For you the profile would become:

profiles
profile
iddocumentation/id
activation
property
nameskipDocs/name
 value!true/value
/property
/activation
...
/profile
/profiles

Profile activation can easily be checked with:
mvn help:active-profiles -DskipDocs
mvn help:active-profiles -DskipDocs=true
mvn help:active-profiles -DskipDocs=false

(not specifying a value makes it true).

Regards,

Kees

--
Squins | IT, Honestly
Oranjestraat 23
2983 HL Ridderkerk
The Netherlands
Phone: +31 (0)180 415559
Mobile: +31 (0)6 30413841
www.squins.com
http://twitter.com/keesvandieren
Chamber of commerce Rotterdam: 22048547
Boeken voor school en werk bestel je op studieboekencenter.nl
2010/10/20 Joachim Van der Auwerajoac...@progs.be

 

On 10/20/2010 12:35 PM, Wendy Smoak wrote:

   

On Wed, Oct 20, 2010 at 5:32 AM, Joachim Van der Auwera
joac...@triathlon98.com   wrote:


 

However, since the switch to maven3 this does not worka anymore and
   

mvn
 

-DskipDocs install will still include the documentation module.
Do I have to do something different to make this work in maven3?


   

What happens if you do -DskipDocs=abc ?  That will test the
difference between 'present but empty' and 'present (with a value)'.


 

That doesn't seem to make a difference.

I haven't seen this mentioned in the compatibility notes, so I guess it
   

is
 

a bug (though it admittedly is a little documented feature).


Thanks for the help,
Joachim


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


   
 
   



--
Joachim Van der Auwera
PROGS bvba, progs.be


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

Re: maven-versions-plugin version comparism

[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 c...@metrohm.com 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:
 ruleset comparisonMethod=maven
  rules
    rule groupId=mnet comparisonMethod=mercury/ (also tried numeric)
  /rules
 /ruleset

 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 c...@metrohm.com 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

Re: Maven wants to get plugin versions that don't exist

[Phillip Hellewell]

On Wed, Oct 20, 2010 at 6:23 PM, Wendy Smoak wsm...@gmail.com wrote:

 Try removing the directory tree for the archetype plugin from your
 local repo, and see if it goes back to using the released version.

Thanks; unfortunately, it didn't help.

 You can also use the long form of the plugin execution command, and
 specify groupId:artifactId:version to force it to use the version you
 want.

Yep, that's what I've been having to do.

Phillip

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

Re: Maven wants to get plugin versions that don't exist

[Phillip Hellewell]

On Wed, Oct 20, 2010 at 6:17 PM, Wayne Fay wayne...@gmail.com wrote:
 having problems :( How did a version 2.0-alpha-6-SNAPSHOT for the
 maven-archetype-plugin get into Nexus and how do I get rid of it?
 Another one is the maven-help-plugin; it wants to use version
 2.2-SNAPSHOT which isn't available.

 There's a Nexus Users list that would be more appropriate for this
 line of questioning...

Thanks.  I will try there.

Phillip

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

Re: Is it supposed to be safe to use 3.0 and then go back to 2.2.1?

[Benson Margulies]

I no longer believe that this is a result of a switch. I removed my
local repo and reran the build under 2.2.1 and got the same strange
error which I sent into this list.

On Thu, Oct 21, 2010 at 9:06 AM, Jörg Schaible joerg.schai...@gmx.de wrote:
 Hi,

 Benson Margulies wrote:

 I ran a build with 3.0, and when I then retreated to 2.2.1, I got
 class-not-found errors in maven. Should I report this formally?

 that would be strange. I can switch forth and back as I like. Do you use an
 M2_HOME environment setting and probably forget it to set it back? Best
 practice is not to use it at all, because the variable is automatically set
 executing the mvn batch/shell script.

 - Jörg


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



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

Re: Maven wants to get plugin versions that don't exist

[Joachim Van der Auwera]

Sounds familiar.
I have seen these problems occur because of inclusion of the JBoss maven 
repo.
In my case, I fixed it by not proxying the entire jboss repo but only 
there releases.


Joachim

On 10/20/2010 11:22 PM, Phillip Hellewell wrote:

I'm not sure what I did to screw things up, but lately it is failing
to download plugins because it is trying to use a version that doesn't
exist.  I'm using Nexus as a mirror of everything.

E.g., I just tried to do a mvn archetype:create to create a new
plugin and it gave an error because it's trying to download the
maven-archetype-plugin version 2.0-alpha-6, which doesn't exist.

What did I do that screwed things up?  Is something wrong with Nexus?
Do I need to do a sync or something?

Thanks,
Phillip

P.S.  Here's the actual output:

C:\mycomps\maven\plugin\hellomvn archetype:create
-DgroupId=ad.maven.plugin -DartifactId=maven-hello-plugin
-DarchetypeGroupId=org.apache.maven.archetypes
-DarchetypeArtifactId=maven-archetype-mojo

[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'archetype'.
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Error building POM (may not be this project's POM).

Project ID: org.apache.maven.plugins:maven-archetype-plugin

Reason: Error getting POM for
'org.apache.maven.plugins:maven-archetype-plugin' from the repository:
Failed to resolve artifact, possibly due to a repository list that is
not appropriately equipped for this artifact's metadata.

   org.apache.maven.plugins:maven-archetype-plugin:pom:2.0-alpha-6-SNAPSHOT

from the specified remote repositories:
   all-mirror (http://maven:8080/nexus/content/groups/public)

  for project org.apache.maven.plugins:maven-archetype-plugin

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

   



--
Joachim Van der Auwera
PROGS bvba, progs.be


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

Re: Maven wants to get plugin versions that don't exist

[Phillip Hellewell]

On Thu, Oct 21, 2010 at 8:38 AM, Joachim Van der Auwera
joac...@progs.be wrote:
 Sounds familiar.
 I have seen these problems occur because of inclusion of the JBoss maven
 repo.
 In my case, I fixed it by not proxying the entire jboss repo but only there
 releases.

Hmm, I don't see a JBoss repo in my Nexus, however I do see an Apache
Snapshots.  I shouldn't have that in there should I?  Hmm, there's
also Codehaus Snapshots.  I don't think I want that either.

General question about plugins: Is it true that running a plugin
(e.g., mvn help:help) will choose the latest version even if it is a
snapshot?  That seems kind of, I don't know, not good.  Why not let
the developers of the plugin have to specify a version to run for a
snapshot, and let the rest of us run the latest _release_ version?

Phillip

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

RE: Maven wants to get plugin versions that don't exist

[Nord, James]

https://issues.sonatype.org/browse/NEXUS-3729 ?

Fixed in 1.8+

/James

-Original Message-
From: Phillip Hellewell [mailto:ssh...@gmail.com]
Sent: 21 October 2010 15:53
To: Maven Users List
Subject: Re: Maven wants to get plugin versions that don't exist

On Thu, Oct 21, 2010 at 8:38 AM, Joachim Van der Auwera
joac...@progs.be wrote:
 Sounds familiar.
 I have seen these problems occur because of inclusion of the JBoss maven
 repo.
 In my case, I fixed it by not proxying the entire jboss repo but only there
 releases.

Hmm, I don't see a JBoss repo in my Nexus, however I do see an Apache
Snapshots.  I shouldn't have that in there should I?  Hmm, there's
also Codehaus Snapshots.  I don't think I want that either.

General question about plugins: Is it true that running a plugin
(e.g., mvn help:help) will choose the latest version even if it is a
snapshot?  That seems kind of, I don't know, not good.  Why not let
the developers of the plugin have to specify a version to run for a
snapshot, and let the rest of us run the latest _release_ version?

Phillip

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



**
This message is confidential and intended only for the addressee. If you have 
received this message in error, please immediately notify the 
postmas...@nds.com and delete it from your system as well as any copies. The 
content of e-mails as well as traffic data may be monitored by NDS for 
employment and security purposes. To protect the environment please do not 
print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, 
United Kingdom. A company registered in England and Wales. Registered no. 
3080780. VAT no. GB 603 8808 40-00
**

Re: Maven wants to get plugin versions that don't exist

[Phillip Hellewell]

On Thu, Oct 21, 2010 at 9:04 AM, Nord, James jn...@nds.com wrote:
 https://issues.sonatype.org/browse/NEXUS-3729 ?

 Fixed in 1.8+

I'm not sure if that's exactly what it is, but it sounds similar.

I just removed Apache Snapshots and Codehaus Snapshots from my
Public Repositories group and now all is well, hooray!

Now tell me, why would Nexus put these snapshot repos in my Public
Repositories group by default?  That's just insane, or am I missing
something?  (Sorry, this complaint should be on the Nexus list).

Phillip

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

Weird Error

[Mahdi Yusuf]

I recently upgrade to Maven 3 Official. Now one of my build doesn't seem to
work. I haven't changed any of the source code and it was working fine
before. Suggestions here is my error

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.2:assembly (default-cli) on
project KDM-CExtractor: Error reading assemblies: Error reading descriptor:
src.xml: Unrecognised tag: 'useDefaultExcludes' (position: START_TAG seen
.../unpack\n\t\t\t\tuseDefaultExcludes... @54:25) - [Help 1]


Then when i take that line out I get this error.


[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:assembly
(default-cli) on project KDM-CExtractor: Failed to create assembly:
Error creating assembly archive : You must set at least one file. -
[Help 1]




My plugin declaration in the pom.xml

   plugin
artifactIdmaven-assembly-plugin/artifactId
 version2.2/version
configuration
descriptors
 descriptorsrc.xml/descriptor
/descriptors
 /configuration
/plugin

and here is my descriptor :

assembly
xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
http://maven.apache.org/xsd/assembly-1.1.0.xsd;
 id/id
formats
formatzip/format
 /formats
includeBaseDirectorytrue/includeBaseDirectory
 moduleSets
moduleSet
sources
 useDefaultExcludestrue/useDefaultExcludes
includeModuleDirectoryfalse/includeModuleDirectory
 fileSets
fileSet
useDefaultExcludestrue/useDefaultExcludes
 directoryexec/directory
excludes
excludesample//exclude
 exclude.project/exclude
/excludes
/fileSet
 fileSet
directoryjre/directory
excludes
 exclude.project/exclude
/excludes
/fileSet
 fileSet
directoryplugins/directory
excludes
 /excludes
/fileSet
fileSet
 directoryMinGW-gcc4.5/directory
excludes
 exclude.project/exclude
/excludes
/fileSet
 fileSet
directorypackaging/directory
excludes
 /excludes
outputDirectory/outputDirectory
 /fileSet
/fileSets
/sources
 includes
/includes
binaries
 outputDirectoryplugins//outputDirectory
unpackfalse/unpack
 useDefaultExcludestrue/useDefaultExcludes
excludes
 exclude.project/exclude
/excludes
/binaries
 /moduleSet
/moduleSets
/assembly

RE: Maven wants to get plugin versions that don't exist

[Nord, James]

See http://maven.40175.n5.nabble.com/settings-xml-td131025.html#a131025

/James

-Original Message-
From: Phillip Hellewell [mailto:ssh...@gmail.com]
Sent: 21 October 2010 16:09
To: Maven Users List
Subject: Re: Maven wants to get plugin versions that don't exist

On Thu, Oct 21, 2010 at 9:04 AM, Nord, James jn...@nds.com wrote:
 https://issues.sonatype.org/browse/NEXUS-3729 ?

 Fixed in 1.8+

I'm not sure if that's exactly what it is, but it sounds similar.

I just removed Apache Snapshots and Codehaus Snapshots from my
Public Repositories group and now all is well, hooray!

Now tell me, why would Nexus put these snapshot repos in my Public
Repositories group by default?  That's just insane, or am I missing
something?  (Sorry, this complaint should be on the Nexus list).

Phillip

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



**
This message is confidential and intended only for the addressee. If you have 
received this message in error, please immediately notify the 
postmas...@nds.com and delete it from your system as well as any copies. The 
content of e-mails as well as traffic data may be monitored by NDS for 
employment and security purposes. To protect the environment please do not 
print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, 
United Kingdom. A company registered in England and Wales. Registered no. 
3080780. VAT no. GB 603 8808 40-00
**

Re: A plugin that doesn't require a pom.xml

[Phillip Hellewell]

On Wed, Oct 20, 2010 at 5:13 PM, Nick Stolwijk nick.stolw...@gmail.com wrote:
 I've taken a look at the source of the help:describe goal and it seems
 you need RequireProject.

 http://svn.apache.org/viewvc/maven/plugins/tags/maven-help-plugin-2.1.1/src/main/java/org/apache/maven/plugins/help/DescribeMojo.java?view=markup

Thanks!  Adding @requiresProject false worked like a charm!

Phillip

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

Re: scm connection in parent pom

[Phillip Hellewell]

On Thu, Oct 21, 2010 at 2:06 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 On 20 October 2010 16:36, Phillip Hellewell ssh...@gmail.com wrote:
 But if it can be inferred while the plugin is running, why exactly
 does it need to get written back into the pom?  Of course, I don't

 You did see the -Dprovider=svn

Yes.

 There are N providers not all of them can be inferred... what do we do
 if somebody has a svn workspace in a git workspace with .gitignore's
 containing .svn and svn:ignore on the root folder containing .git?
 That would allow both scm's to function at the same time without being
 aware of each other... which should maven choose?

Don't infer the SCM.  Just infer the URL.  I think it's ok if the SCM
has to be provided on the command-line (as you illustrated) or inside
the pom where the connection looks like scm:svn:infer.

 Oh and this git/svn workspace could also be an accurev workspace (no
 control files needed to be ignored there) and why not add CVS into the
 mix?

Yeah, I think it would be great if over time we could add infer
ability for more SCMs.

 mind it being written into the pom on a tag, and in the pom that goes
 to the repo, but in the trunk and branches the whole idea is to not
 have it present in there so it is always inferred.

 but you are going to have to specify at least the provider... so at
 least more than nothing will have to go in there... plus when that
 -SNAPSHOT gets deployed wouldn't it be nice to know from which branch
 it was deployed? oh look the pom has the scm details of the branch it
 came from... cool! that was joe's branch which explains why I'm fecked

Yeah, I'd be fine having connectionscm:svn:infer/connection in
there.  I'm also fine with having it get replaced in the pom in the
tag and in the released poms that gets deployed, but in the
trunk/branches it could stay as scm:svn:infer forever.

The only downside I can see is what you just mentioned about
snapshots.  I agree it could be helpful to know like what branch the
snapshot came from, but I still think having infer functionality has
some great benefits that for some people would outweigh this one
drawback.

Phillip

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

Re: Shared Assembly With Additional Files

[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 mike.len...@gmail.com 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:

 ...
 fileSet
    directorycommon/directory
    includes
        includeREADME/include
    /includes
   outputDirectory//outputDirectory
 /fileSet
 ...

 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

Re: Property for the location of the local repository

[Jon Paynter]

On Wed, Oct 20, 2010 at 10:46 PM, Martin Höller mar...@xss.co.at wrote:

 Hi!

 On Wednesday 20 October 2010 Hilco Wijbenga wrote:
  On 11 October 2010 21:48, Hilco Wijbenga hilco.wijbe...@gmail.com
 wrote:
   I could have sworn I've used ${localRepository} before but it doesn't
   seem to work. I've also tried ${settings.localRepository} and
   ${maven.repo.local}. How do I refer to the location of the local
   repository in a portable way? Is there a difference between Maven2 and
   Maven3?
 
  I had a look in the source code and found the following:
 
 [...]
  Is there some documentation on how properties are handled internally?

I don't know what is actually the prefered way of accessing the path to the
 local repository (but I'm quite sure I saw discussions about it on this
 list before). However, running your example pom.xml works as soon as I
 changed ${maven.local.repo} to ${settings.localRepository}. This is working
  with maven 2.2.1 and maven 3.0-beta-3.


 I was wondering the same thing - and I just ended up creating my own custom
property.

If you find a built-in property, please let us know.

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 stephen.alan.conno...@gmail.com

 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 c...@metrohm.com 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:
  ruleset comparisonMethod=maven
   rules
 rule groupId=mnet comparisonMethod=mercury/ (also tried numeric)
   /rules
  /ruleset
 
  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 c...@metrohm.com 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: Filtering in assembly plugin (2.2-beta-2 and 2.2)

[Jon Paynter]

On Thu, Oct 21, 2010 at 4:08 AM, Aleksey Didik
aleksey.di...@maxifier.comwrote:

 Hello all!

 I have used maven-assembly-plugin 2.2-beta-2 before and have those lines in
 my descriptor:

 files
 file
 source${basedir}/src/scripts/python/updater.py/source
 outputDirectory//outputDirectory
 filteredtrue/filtered
 /file
 /files

 Filtering works right, I have got real project version instead of
 ${project.version}.

 After switch to the version 2.2, plugin not filter necessary file (declared
 into snippet above). All $properties stay unfiltered.

 Is something change between versions?

 And one more question, is it possible to use filtered for file sets into
 fileSets?

 In assembly descriptor description are wrote:
  filtered boolean Whether to filter symbols in the files as they are
 copied, using properties from the build configuration. (Since 2.2)
 *Default value is*: false.

 But into Filtering Some Distribution Files topic are wrote: Filtering is
 only enabled inside files so that's what we will use.

 Could anybody clear the situation?


Im seeing the same behavior - using 2.2-beta-5 filtering is fine, but when I
change to 2.2, filtering seems to be disabled across the board.

assembly descriptor snippet:
fileSet
directoryconfig/app_config/vpp/directory
outputDirectoryconfig/outputDirectory
filteredtrue/filtered
lineEndingunix/lineEnding
/fileSet

using 2.2, I get this in my output directory:
var name=LOG_ENABLED value=${FW_LOG_ENABLED} /

using 2.2-beta-5, I get this in my output directory:
var name=LOG_ENABLED value=true /

The only change I did was to edit the version tag for the assembly plugin
in my top level pom.

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 mike.len...@gmail.com

 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 mike.len...@gmail.com
 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:
 
  ...
  fileSet
 directorycommon/directory
 includes
 includeREADME/include
 /includes
outputDirectory//outputDirectory
  /fileSet
  ...
 
  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

Posts rejected as spam?

[Jon Paynter]

The last several messages ive sent to the list have bounced back as spam
Can somebody remove kittl...@gmail.com from the blacklist?

(sending this from nabble.com so it has a better chance to go through)

dateThu, Oct 21, 2010 at 10:17 AM
subject Delivery Status Notification (Failure)


Delivery to the following recipient failed permanently:

users@maven.apache.org

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient
domain. We recommend contacting the other email provider for further
information about the cause of this error. The error that the other server
returned was: 552 552 spam score (6.9) exceeded threshold (state 18).
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Posts-rejected-as-spam-tp3230920p3230920.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

Classifier now required by assembly plugin

[Phillip Hellewell]

I just found out the hard way that the latest version of the assembly
plugin requires an id tag in the descriptor file, which is used as
the classifier appended to the zip.

I don't want to specify an id here because then means I have to
specify a classifier in the dependency section of my other poms.  If
my project only produces a single zip, why should I have to worry
about specifying a classifier in all my other poms that depend on this
project?

Thanks,
Phillip

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

Re: Classifier now required by assembly plugin

[Phillip Hellewell]

On Thu, Oct 21, 2010 at 11:40 AM, Phillip Hellewell ssh...@gmail.com wrote:
 I just found out the hard way that the latest version of the assembly
 plugin requires an id tag in the descriptor file, which is used as
 the classifier appended to the zip.

 I don't want to specify an id here because then means I have to
 specify a classifier in the dependency section of my other poms.  If
 my project only produces a single zip, why should I have to worry
 about specifying a classifier in all my other poms that depend on this
 project?

This is the error it gives now if I don't have an id in my descriptor file:

Assembly is incorrectly configured: null
Assembly: null is not configured correctly: Assembly ID must be
present and non-empty.

Phillip

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

Classifier wildcard

[Phillip Hellewell]

Suppose project A produces three packages (using the assembly plugin
with different ids/classifiers):
   A-1.0-dlls.zip
   A-1.0-libs.zip
   A-1.0-headers.zip

Now suppose project B wants to depend on _all_ of A.  I have write out
three separate dependency sections, each one with a different
classifier.  Isn't there any way I can specify all the classifiers in
the same section, or even better just use a wildcard, like so?

dependency
  groupIdad.3rdparty/groupId
  artifactIdzlib/artifactId
  version[1.2.5]/version
  typezip/type
  classifier*/classifier
/dependency

Thanks,
Phillip

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

Same dependency different classifier

[Phillip Hellewell]

Can I make it an error if someone tries to use two different versions
of the same dependency with different classifiers?

For example, this works, but I want it to cause an error:

dependency
  groupIdad.3rdparty/groupId
  artifactIdzlib/artifactId
  version[1.2.5]/version
  typezip/type
  classifierdlls/classifier
/dependency
dependency
  groupIdad.3rdparty/groupId
  artifactIdzlib/artifactId
  version[1.2.6]/version
  typezip/type
  classifierlibs/classifier
/dependency
  /dependencies

Having libs from one version of zlib and dlls from another version of
zlib is going to cause build or runtime errors.  I want to catch it
here during dependency resolution.

Thanks,
Phillip

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

RE: Same dependency different classifier

[Yanko, Curtis]

 
Perhaps the enforcer plugin could help

http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html



Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time

-Original Message-
From: Phillip Hellewell [mailto:ssh...@gmail.com] 
Sent: Thursday, October 21, 2010 1:53 PM
To: Maven Users List
Subject: Same dependency different classifier

Can I make it an error if someone tries to use two different versions of
the same dependency with different classifiers?

For example, this works, but I want it to cause an error:

dependency
  groupIdad.3rdparty/groupId
  artifactIdzlib/artifactId
  version[1.2.5]/version
  typezip/type
  classifierdlls/classifier
/dependency
dependency
  groupIdad.3rdparty/groupId
  artifactIdzlib/artifactId
  version[1.2.6]/version
  typezip/type
  classifierlibs/classifier
/dependency
  /dependencies

Having libs from one version of zlib and dlls from another version of
zlib is going to cause build or runtime errors.  I want to catch it here
during dependency resolution.

Thanks,
Phillip

-
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

Company pom

[Phillip Hellewell]

I'm setting up a company pom to specify pluginManagement, and I was
wondering about distributionManagement.  I have to put that in there
too, but is it ok for a parent pom to override it?

Thanks,
Phillip

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

Re: Same dependency different classifier

[Nick Stolwijk]

And to make it more manageable capture the version in a property and
use that in the different places.

With regards,

Nick Stolwijk
~Java Developer~

IPROFS BV.
Claus Sluterweg 125
2012 WS Haarlem
http://www.iprofs.nl



On Thu, Oct 21, 2010 at 7:57 PM, Yanko, Curtis curt_ya...@uhc.com wrote:

 Perhaps the enforcer plugin could help

 http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html

 

 Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
 Making IT Happen, one build at a time

 -Original Message-
 From: Phillip Hellewell [mailto:ssh...@gmail.com]
 Sent: Thursday, October 21, 2010 1:53 PM
 To: Maven Users List
 Subject: Same dependency different classifier

 Can I make it an error if someone tries to use two different versions of
 the same dependency with different classifiers?

 For example, this works, but I want it to cause an error:

    dependency
      groupIdad.3rdparty/groupId
      artifactIdzlib/artifactId
      version[1.2.5]/version
      typezip/type
      classifierdlls/classifier
    /dependency
    dependency
      groupIdad.3rdparty/groupId
      artifactIdzlib/artifactId
      version[1.2.6]/version
      typezip/type
      classifierlibs/classifier
    /dependency
  /dependencies

 Having libs from one version of zlib and dlls from another version of
 zlib is going to cause build or runtime errors.  I want to catch it here
 during dependency resolution.

 Thanks,
 Phillip

 -
 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



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

Re: Classifier wildcard

[Wayne Fay]

 classifier.  Isn't there any way I can specify all the classifiers in
 the same section, or even better just use a wildcard, like so?

No. But you can create another artifact like A-1.0-all of type pom
that depends on -dlls, -zips, and -headers artifacts and then, in
turn, depend on it in your own pom. This will bring those 3 artifacts
into your current project without declaring all 3 as dependencies.

Wayne

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

Re: Same dependency different classifier

[Wayne Fay]

 And to make it more manageable capture the version in a property and
 use that in the different places.

Or compose all 3 artifacts into a single all dependency and depend on it.

Wayne

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

Create a MavenProject from an Artifact in Maven3

[Pieter van der Meer]

Hi,

Im building a plugin that requires the dependencies of other pom files to to
its work. I am able to retrieve all the ArtifactInfo objects (pom files)
that i require.
The next step in the process is to get all the dependencies that are defined
in the specified pom file. I cant' figure out on how to do this. Yes I need
a ProjectBuilder but no matter what i try i get either a null pointer from
the Maven API or dont have any dependencies in the MavenProject i just
created.

From the 3.0 javadoc  it seems to me that a need the ProjectBuilder
(DefaultProjectBuilder component) but so far no good.

Any help or pointers are appreciated.

Pieter

Re: maven-versions-plugin version comparism

[Stephen Connolly]

v-m-p has become, while not a critical plugin, at least an essential
plugin for a large number of people.

At the moment v-m-p's integration tests are creaking under the issues
of reproducibility. I have one build environment where all the tests
pass as written (my Acer Aspire One netbook), but numerous attempts to
replicate that environment result in sporadic integration test
failures.

I am very much reluctant to go extending v-m-p until I sort out the
mock-repository-maven-plugin which will allow me to refactor the tests
to be truly portable (as well as speed them up).

Until I have a truly portable reproducible set of integration tests I
do not want to accept new patches as regressions could hamper existing
users and rubbish the reputation of v-m-p.

I am also warey of adding yet more version comparators.  the only one
I am considering is an OSGi one, because I view the version
comparators as currently implemented by v-m-p as a hack to work around
deficiencies in the maven repo layout

-Stephen

On 21 October 2010 18:06, Vincent Latombe vincent.lato...@gmail.com wrote:
 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 stephen.alan.conno...@gmail.com

 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 c...@metrohm.com 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:
  ruleset comparisonMethod=maven
   rules
     rule groupId=mnet comparisonMethod=mercury/ (also tried numeric)
   /rules
  /ruleset
 
  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 c...@metrohm.com 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


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

Re: scm connection in parent pom

[Stephen Connolly]

On 21 October 2010 16:55, Phillip Hellewell ssh...@gmail.com wrote:
 or inside
 the pom where the connection looks like scm:svn:infer.

i'm not doing that. The pom should be complete on its own and not
depend on where in scm it happens to be located.

mvn scm:infer

will correct the scm details if incorrect and update the pom.xml

-Stephen

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

Re: Company pom

[Stephen Connolly]

yes

On 21 October 2010 19:22, Phillip Hellewell ssh...@gmail.com wrote:
 I'm setting up a company pom to specify pluginManagement, and I was
 wondering about distributionManagement.  I have to put that in there
 too, but is it ok for a parent pom to override it?
 ^^ typo child

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

Re: scm connection in parent pom

[Phillip Hellewell]

On Thu, Oct 21, 2010 at 12:53 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 On 21 October 2010 16:55, Phillip Hellewell ssh...@gmail.com wrote:
 or inside
 the pom where the connection looks like scm:svn:infer.

 i'm not doing that. The pom should be complete on its own and not
 depend on where in scm it happens to be located.

alright

 mvn scm:infer

 will correct the scm details if incorrect and update the pom.xml

that's better than nothing, thanks :)

Phillip

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

Newbie question: how to find a) latest version and b) repository given an artifactID

[Stephen Boesch]

If I am looking for an artificat and have its artifactID and want to find
the versions available in public maven repos' (maven central, etc).   What
might be recommended way to do that?

Do I have to already know in advance which repo's to try?  E.g. maven
central, mvnrepository.com etc.   Or is there a better (more sane..) way to
do this?

Here's a specific case:  I am looking for gwt-servlet   I think the latest
version is 2.1.0-RC1.   But i have been going in circles trying to find out
where a mvn repo is for it.   This is however just the latest case: I have
been in this pattern of confusion for maven artifacts a number of times
already.

thanks

Re: Newbie question: how to find a) latest version and b) repository given an artifactID

[Nick Stolwijk]

It is hard to get the repository, because everyone can start their own
(and in their own way).

I googled on filetype:jar gwt-servlet:2.1.0-RC1 and found the repository here:

http://code.google.com/p/google-web-toolkit/source/browse/#svn/2.1.0/gwt/maven
for the latest version.

With regards,

Nick Stolwijk
~Java Developer~

IPROFS BV.
Claus Sluterweg 125
2012 WS Haarlem
http://www.iprofs.nl



On Thu, Oct 21, 2010 at 9:17 PM, Stephen Boesch java...@gmail.com wrote:
 2.1.0-RC1

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

Re: Classifier wildcard

[Phillip Hellewell]

On Thu, Oct 21, 2010 at 12:31 PM, Wayne Fay wayne...@gmail.com wrote:
 classifier.  Isn't there any way I can specify all the classifiers in
 the same section, or even better just use a wildcard, like so?

 No. But you can create another artifact like A-1.0-all of type pom
 that depends on -dlls, -zips, and -headers artifacts and then, in
 turn, depend on it in your own pom. This will bring those 3 artifacts
 into your current project without declaring all 3 as dependencies.

Not a bad idea.  But the term artifact is kinda overloaded, so I'm
not sure which of these two did you mean?

1. Inside the pom file for A just add another descriptor with id all
so A will produce a 4th zip called A-1.0-all.zip.
2. Have a separate pom file that depends on -dlls, -libs, and -headers of A.

The only drawback I see to #1 is some extra disk space gets used (when
building A and in the repo).

The drawback I see to #2 is having to update both the normal pom file
for A and the all pom file every time A is updated to a new version.

Any other ideas?  Should I submit a feature request for having a
wildcard in the classifier section?  Or at least the ability to
specify multiple classifiers would be better than nothing.

Phillip

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

Re: Newbie question: how to find a) latest version and b) repository given an artifactID

[Stephen Boesch]

This shows how to pick up the artifact.  What is the repository url that I
would use?



2010/10/21 Nick Stolwijk nick.stolw...@gmail.com

 It is hard to get the repository, because everyone can start their own
 (and in their own way).

 I googled on filetype:jar gwt-servlet:2.1.0-RC1 and found the repository
 here:


 http://code.google.com/p/google-web-toolkit/source/browse/#svn/2.1.0/gwt/maven
 for the latest version.

 With regards,

 Nick Stolwijk
 ~Java Developer~

 IPROFS BV.
 Claus Sluterweg 125
 2012 WS Haarlem
 http://www.iprofs.nl



 On Thu, Oct 21, 2010 at 9:17 PM, Stephen Boesch java...@gmail.com wrote:
  2.1.0-RC1

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

Re: Same dependency different classifier

[Phillip Hellewell]

On Thu, Oct 21, 2010 at 11:57 AM, Yanko, Curtis curt_ya...@uhc.com wrote:

 Perhaps the enforcer plugin could help

 http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html

Thanks.  It seems like a lot of work to prevent something that IMO
should be treated as an error by the dependency resolution, but at
least I know there is something I can look into.

All these different issues I'm finding with classifiers just makes me
want to avoid them completely (like I was doing before).  But the
latest version of the assembly plugin forces me specify a classifier
for the packages I create, so that's what got me started on all
this...

Phillip

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

Re: Same dependency different classifier

[Phillip Hellewell]

On Thu, Oct 21, 2010 at 12:32 PM, Wayne Fay wayne...@gmail.com wrote:
 And to make it more manageable capture the version in a property and
 use that in the different places.

 Or compose all 3 artifacts into a single all dependency and depend on it.

Thanks.  Given the issues surrounding classifiers, I'm thinking of
just having an all artifact and not even having the 3 split out
ones.

Phillip

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

Re: Newbie question: how to find a) latest version and b) repository given an artifactID

[Nick Stolwijk]

The repository URl is nothing more than just a root URL of the
specified directory structure. You can use the url I gave as
repository URL. It was not my decision to create a repository for each
seperate version, and also in Subversion. ;)

With regards,

Nick Stolwijk
~Java Developer~

IPROFS BV.
Claus Sluterweg 125
2012 WS Haarlem
http://www.iprofs.nl



On Thu, Oct 21, 2010 at 9:32 PM, Stephen Boesch java...@gmail.com wrote:
 This shows how to pick up the artifact.  What is the repository url that I
 would use?



 2010/10/21 Nick Stolwijk nick.stolw...@gmail.com

 It is hard to get the repository, because everyone can start their own
 (and in their own way).

 I googled on filetype:jar gwt-servlet:2.1.0-RC1 and found the repository
 here:


 http://code.google.com/p/google-web-toolkit/source/browse/#svn/2.1.0/gwt/maven
 for the latest version.

 With regards,

 Nick Stolwijk
 ~Java Developer~

 IPROFS BV.
 Claus Sluterweg 125
 2012 WS Haarlem
 http://www.iprofs.nl



 On Thu, Oct 21, 2010 at 9:17 PM, Stephen Boesch java...@gmail.com wrote:
  2.1.0-RC1

 -
 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: Newbie question: how to find a) latest version and b) repository given an artifactID

[Tamás Cservenák]

You can try RSO and do a search:
https://repository.sonatype.org/index.html#nexus-search;gav~~gwt-servlet~~~

It indexes most popular Maven repositories, but not all of them ;)

Also, it seems that 2.1.0-RC1 is not in central yet (because it is an
RC?).


Hope helps,
~t~

On Thu, Oct 21, 2010 at 9:17 PM, Stephen Boesch java...@gmail.com wrote:

 If I am looking for an artificat and have its artifactID and want to find
 the versions available in public maven repos' (maven central, etc).   What
 might be recommended way to do that?

 Do I have to already know in advance which repo's to try?  E.g. maven
 central, mvnrepository.com etc.   Or is there a better (more sane..) way
 to
 do this?

 Here's a specific case:  I am looking for gwt-servlet   I think the latest
 version is 2.1.0-RC1.   But i have been going in circles trying to find out
 where a mvn repo is for it.   This is however just the latest case: I have
 been in this pattern of confusion for maven artifacts a number of times
 already.

 thanks

[eclipse:eclipse] AspectJ Dependencies Not Added to Classpath

[Ole Ersoy]

Hi,

When I run eclipse:eclipse the following two dependencies do not get added to 
the classpath.

dependency
groupIdorg.aspectj/groupId
artifactIdaspectjrt/artifactId
version1.5.4/version
/dependency

dependency
groupIdorg.aspectj/groupId
artifactIdaspectjweaver/artifactId
version1.5.4/version
/dependency

Any ideas on how to fix this.  I added them manually, but it would be great if there was 
a Maven way.

TIA,
- Ole




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

Re: Same dependency different classifier

[Jon Paynter]

On Thu, Oct 21, 2010 at 12:35 PM, Phillip Hellewell ssh...@gmail.comwrote:

 On Thu, Oct 21, 2010 at 12:32 PM, Wayne Fay wayne...@gmail.com wrote:
  And to make it more manageable capture the version in a property and
  use that in the different places.
 
  Or compose all 3 artifacts into a single all dependency and depend on
 it.

 Thanks.  Given the issues surrounding classifiers, I'm thinking of
 just having an all artifact and not even having the 3 split out
 ones.

Thats the route I ended up taknig.  We have an in-house framework, and I
created a seperate project for that.  It made version control trivial - but
extensive testing and some rework was needed as dependencies that used to be
immediate, were now transitive.

if you have a single layer project tree, you should be fine, but if there
are several layers to your project tree, then make sure you test things
extensively.

Re: Weird Error

[Anders Hammar]

Something is fishy. Your logs show that first maven-assembly-plugin v2.2 is
used, then you say you take out that line and v2.2-beta-5 is used. What
line are you removing?
Are you sure the very same version of assembly is used in Maven 2.2.1 and
Maven 3.0? Do you do ANY updates to the pom when switching Maven version?

/Anders

On Thu, Oct 21, 2010 at 17:13, Mahdi Yusuf yusuf.ma...@gmail.com wrote:

 I recently upgrade to Maven 3 Official. Now one of my build doesn't seem to
 work. I haven't changed any of the source code and it was working fine
 before. Suggestions here is my error

 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-assembly-plugin:2.2:assembly (default-cli)
 on
 project KDM-CExtractor: Error reading assemblies: Error reading descriptor:
 src.xml: Unrecognised tag: 'useDefaultExcludes' (position: START_TAG seen
 .../unpack\n\t\t\t\tuseDefaultExcludes... @54:25) - [Help 1]


 Then when i take that line out I get this error.


 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:assembly
 (default-cli) on project KDM-CExtractor: Failed to create assembly:
 Error creating assembly archive : You must set at least one file. -
 [Help 1]




 My plugin declaration in the pom.xml

   plugin
 artifactIdmaven-assembly-plugin/artifactId
  version2.2/version
 configuration
 descriptors
  descriptorsrc.xml/descriptor
 /descriptors
  /configuration
 /plugin

 and here is my descriptor :

 assembly
 xmlns=
 http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation=
 http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
 http://maven.apache.org/xsd/assembly-1.1.0.xsd;
  id/id
 formats
 formatzip/format
  /formats
 includeBaseDirectorytrue/includeBaseDirectory
  moduleSets
 moduleSet
 sources
  useDefaultExcludestrue/useDefaultExcludes
 includeModuleDirectoryfalse/includeModuleDirectory
  fileSets
 fileSet
 useDefaultExcludestrue/useDefaultExcludes
  directoryexec/directory
 excludes
 excludesample//exclude
  exclude.project/exclude
 /excludes
 /fileSet
  fileSet
 directoryjre/directory
 excludes
  exclude.project/exclude
 /excludes
 /fileSet
  fileSet
 directoryplugins/directory
 excludes
  /excludes
 /fileSet
 fileSet
  directoryMinGW-gcc4.5/directory
 excludes
  exclude.project/exclude
 /excludes
 /fileSet
  fileSet
 directorypackaging/directory
 excludes
  /excludes
 outputDirectory/outputDirectory
  /fileSet
 /fileSets
 /sources
  includes
 /includes
 binaries
  outputDirectoryplugins//outputDirectory
 unpackfalse/unpack
  useDefaultExcludestrue/useDefaultExcludes
 excludes
  exclude.project/exclude
 /excludes
 /binaries
  /moduleSet
 /moduleSets
 /assembly

Re: War plugin CannotResolveClassException

[Dennis Lundberg]

Can you try using version 2.1 of the WAR Plugin?
It has disabled a cache that uses xstream, which has caused trouble for
users before.

On Thu, Oct 21, 2010 at 3:21 PM, Benson Margulies bimargul...@gmail.comwrote:

 Does this ring any bells for anyone?

 [INFO] [war:war {execution: default-war}]
 [INFO] Packaging webapp
 [INFO]
 
 [ERROR] FATAL ERROR
 [INFO]
 
 [INFO] org.apache.maven.model.InputLocation :
 org.apache.maven.model.InputLocation :
 org.apache.maven.model.InputLocation :
 org.apache.maven.model.InputLocation
  Debugging information 
 message : org.apache.maven.model.InputLocation :
 org.apache.maven.model.InputLocation
 cause-exception :
 com.thoughtworks.xstream.mapper.CannotResolveClassException
 cause-message   : org.apache.maven.model.InputLocation :
 org.apache.maven.model.InputLocation
 class   : org.apache.maven.plugin.war.util.WebappStructure
 required-type   : java.util.LinkedHashMap
 path:

 /webapp-structure/dependenciesInfo/org.apache.maven.plugin.war.util.DependencyInfo/dependency/exclusions/org.apache.maven.model.Exclusion/locations/entry/org.apache.maven.model.InputLocation
 line number : 49
 ---
 [INFO]
 
 [INFO] Trace
 com.thoughtworks.xstream.converters.ConversionException:
 org.apache.maven.model.InputLocation :
 org.apache.maven.model.InputLocation :
 org.apache.maven.model.InputLocation :
 org.apache.maven.model.InputLocation
  Debugging information 
 message : org.apache.maven.model.InputLocation :
 org.apache.maven.model.InputLocation
 cause-exception :
 com.thoughtworks.xstream.mapper.CannotResolveClassException
 cause-message   : org.apache.maven.model.InputLocation :
 org.apache.maven.model.InputLocation
 class   : org.apache.maven.plugin.war.util.WebappStructure
 required-type   : java.util.LinkedHashMap
 path:

 /webapp-structure/dependenciesInfo/org.apache.maven.plugin.war.util.DependencyInfo/dependency/exclusions/org.apache.maven.model.Exclusion/locations/entry/org.apache.maven.model.InputLocation
 line number : 49
 ---
at
 com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:89)
at
 com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
at
 com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
at
 com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60)
at
 com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.doUnmarshal(AbstractReflectionConverter.java:225)
at
 com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:162)
at
 com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
at
 com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
at
 com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
at
 com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60)
at
 com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:71)
at
 com.thoughtworks.xstream.converters.collections.CollectionConverter.populateCollection(CollectionConverter.java:68)
at
 com.thoughtworks.xstream.converters.collections.CollectionConverter.unmarshal(CollectionConverter.java:61)
at
 com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
at
 com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
at
 com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
at
 com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshallField(AbstractReflectionConverter.java:246)
at
 com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.doUnmarshal(AbstractReflectionConverter.java:218)
at
 com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:162)
at
 com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
at
 com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
at
 com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
at
 

Re: Classifier wildcard

[Wayne Fay]

 1. Inside the pom file for A just add another descriptor with id all
 so A will produce a 4th zip called A-1.0-all.zip.
 2. Have a separate pom file that depends on -dlls, -libs, and -headers of A.

This #2 is what I was talking about. But #1 is reasonable as well.

 Any other ideas?  Should I submit a feature request for having a
 wildcard in the classifier section?  Or at least the ability to
 specify multiple classifiers would be better than nothing.

I very strongly doubt the wildcard in classifier would be accepted
and implemented. The multiple classifier thing at least has a chance.

Wayne

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

Re: [eclipse:eclipse] AspectJ Dependencies Not Added to Classpath

[Rune Flobakk]

This was fixed in version 2.8 of maven-eclipse-plugin:
http://jira.codehaus.org/browse/MECLIPSE-594

- Rune



Hi,

When I run eclipse:eclipse the following two dependencies do not get added to
the classpath.

dependency
groupIdorg.aspectj/groupId
artifactIdaspectjrt/artifactId
version1.5.4/version
/dependency

dependency
groupIdorg.aspectj/groupId
artifactIdaspectjweaver/artifactId
version1.5.4/version
/dependency

Any ideas on how to fix this.  I added them manually, but it would be great if 
there was
a Maven way.

TIA,
- Ole

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

RE: Classifier now required by assembly plugin

[Haszlakiewicz, Eric]

-Original Message-
From: Phillip Hellewell [mailto:ssh...@gmail.com]

On Thu, Oct 21, 2010 at 11:40 AM, Phillip Hellewell ssh...@gmail.com
wrote:
 I just found out the hard way that the latest version of the assembly
 plugin requires an id tag in the descriptor file, which is used as
 the classifier appended to the zip.

 I don't want to specify an id here because then means I have to
 specify a classifier in the dependency section of my other poms.  If
 my project only produces a single zip, why should I have to worry
 about specifying a classifier in all my other poms that depend on this
 project?

This is the error it gives now if I don't have an id in my descriptor
file:

Assembly is incorrectly configured: null
Assembly: null is not configured correctly: Assembly ID must be
present and non-empty.

Phillip

uh, oh.  We depend on being able to specify that as empty too.  I hope this 
gets fixed before it starts affecting my builds.
However, are you sure this is really an issue?  I just tried one of my builds 
which needs an empty id element.  I tried using the default version of the 
plugin (2.2-beta-2), and forcing it to the most recent version (which appears 
to be 2.2-beta-5), and it works fine for me.
What version are you using?

eric


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

Re: Classifier now required by assembly plugin

[Phillip Hellewell]

On Thu, Oct 21, 2010 at 3:17 PM, Haszlakiewicz, Eric
ehas...@transunion.com wrote:

 uh, oh.  We depend on being able to specify that as empty too.  I hope this 
 gets fixed before it starts affecting my builds.
 However, are you sure this is really an issue?  I just tried one of my builds 
 which needs an empty id element.  I tried using the default version of the 
 plugin (2.2-beta-2), and forcing it to the most recent version (which appears 
 to be 2.2-beta-5), and it works fine for me.
 What version are you using?

2.2, which was released a couple weeks ago apparently:

http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-assembly-plugin/2.2/

Phillip

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

Maven Upload Requests separate binaries and sources jar restriction

[Stevo Slavić]

Hello Apache Maven users,

On Maven Upload Request http://jira.codehaus.org/browse/MAVENUPLOAD JIRA
project summary page it is stated that All bundles submitted after February
23rd 2010 must have sources, javadocs and all artifacts accompanied by valid
PGP signatures. Your bundles will be immediately rejected if you are missing
any of these requirements.. I'd like to convince maintainer(s) of an open
source project which is not built using Apache Maven to upload their
artifact to Maven Central. Their distribution includes a jar file with
binaries and source all together and not as two separate jars. Would it be
acceptable for uploading to central to provide that single jar, pom, and
signatures?

Regards,
Stevo.

Re: Maven Upload Requests separate binaries and sources jar restriction

[Wayne Fay]

 binaries and source all together and not as two separate jars. Would it be
 acceptable for uploading to central to provide that single jar, pom, and
 signatures?

Seems like a better question for the repo maintainers list, given they
manage the repo. Perhaps use the Sonatype OSS forge?
http://nexus.sonatype.org/oss-repository-hosting.html

Wayne

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

RE: [ANN] Release Maven Site Plugin 3.0-beta-3 for maven 3

[Brian.Levine]

Does this imply that this version of the plugin is not compatible with Maven 
2.x?

-b


From: ext Olivier Lamy [ol...@apache.org]
Sent: Thursday, October 21, 2010 10:10 AM
To: Maven Users List
Cc: Maven Developers List
Subject: [ANN] Release Maven Site Plugin 3.0-beta-3 for maven 3

Hi,

The Maven team is pleased to announce the release of the Maven Site
Plugin, version 3.0-beta-3 for Maven 3.
This version is intended to be the version of the Maven Site Plugin for Maven 3.

The Site Plugin is used to generate a site for the project.

You should specify the version in the build section of your project's POM:

plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-site-plugin/artifactId
 version3.0-beta-3/version
/plugin

Release Notes - Maven 3.x Site Plugin - Version 3.0-beta-3


** Bug
* [MSITE-500] - Warning message about missing report plugin
version shows null instead of plugin groupId:aritfactId
* [MSITE-504] - Maven site fails to run due to non-report goals
* [MSITE-505] - Unable to use SVN SCM wagon to upload a site
* [MSITE-506] - Maven3 conflict with plexus-archiver
* [MSITE-507] - report plugin doesn't have dependencies section
coming from build section configuration
* [MSITE-508] - attach-descriptor goals leaks file handlers,
causing sporadic build failures when gpg tries to sign descriptor
during release
* [MSITE-512] - [Regression] Configuration of m-javadoc-p at
reportSet level is not taken into account



** Task
* [MSITE-513] - use release final maven 3.0 artifacts

Have Fun !
--
The Maven  Team

-
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: [ANN] Release Maven Site Plugin 3.0-beta-3 for maven 3

[Olivier Lamy]

Hi,
Yes exactly. This version will work only with maven 3.

2010/10/22  brian.lev...@nokia.com:
 Does this imply that this version of the plugin is not compatible with Maven 
 2.x?

 -b

 
 From: ext Olivier Lamy [ol...@apache.org]
 Sent: Thursday, October 21, 2010 10:10 AM
 To: Maven Users List
 Cc: Maven Developers List
 Subject: [ANN] Release Maven Site Plugin 3.0-beta-3 for maven 3

 Hi,

 The Maven team is pleased to announce the release of the Maven Site
 Plugin, version 3.0-beta-3 for Maven 3.
 This version is intended to be the version of the Maven Site Plugin for Maven 
 3.

 The Site Plugin is used to generate a site for the project.

 You should specify the version in the build section of your project's POM:

 plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-site-plugin/artifactId
  version3.0-beta-3/version
 /plugin

 Release Notes - Maven 3.x Site Plugin - Version 3.0-beta-3


 ** Bug
    * [MSITE-500] - Warning message about missing report plugin
 version shows null instead of plugin groupId:aritfactId
    * [MSITE-504] - Maven site fails to run due to non-report goals
    * [MSITE-505] - Unable to use SVN SCM wagon to upload a site
    * [MSITE-506] - Maven3 conflict with plexus-archiver
    * [MSITE-507] - report plugin doesn't have dependencies section
 coming from build section configuration
    * [MSITE-508] - attach-descriptor goals leaks file handlers,
 causing sporadic build failures when gpg tries to sign descriptor
 during release
    * [MSITE-512] - [Regression] Configuration of m-javadoc-p at
 reportSet level is not taken into account



 ** Task
    * [MSITE-513] - use release final maven 3.0 artifacts

 Have Fun !
 --
 The Maven  Team

 -
 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





-- 
Olivier
http://twitter.com/olamy
http://www.linkedin.com/in/olamy

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

Re: [eclipse:eclipse] AspectJ Dependencies Not Added to Classpath

[Ole Ersoy]

Indeed it is - I just added this to the pom's build plugins section:

plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-eclipse-plugin/artifactId
version2.8/version
/plugin


And now it's all good.

Thanks (Tusen Takk)!
- Ole

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

[SOLVED] Re: Property for the location of the local repository

[Hilco Wijbenga]

On 21 October 2010 09:49, Jon Paynter kittl...@gmail.com wrote:
 On Wed, Oct 20, 2010 at 10:46 PM, Martin Höller mar...@xss.co.at wrote:

 Hi!

 On Wednesday 20 October 2010 Hilco Wijbenga wrote:
  On 11 October 2010 21:48, Hilco Wijbenga hilco.wijbe...@gmail.com
 wrote:
   I could have sworn I've used ${localRepository} before but it doesn't
   seem to work. I've also tried ${settings.localRepository} and
   ${maven.repo.local}. How do I refer to the location of the local
   repository in a portable way? Is there a difference between Maven2 and
   Maven3?
 
  I had a look in the source code and found the following:
 
 [...]
  Is there some documentation on how properties are handled internally?

 I don't know what is actually the prefered way of accessing the path to the
 local repository (but I'm quite sure I saw discussions about it on this
 list before). However, running your example pom.xml works as soon as I
 changed ${maven.local.repo} to ${settings.localRepository}. This is working
  with maven 2.2.1 and maven 3.0-beta-3.


  I was wondering the same thing - and I just ended up creating my own custom
 property.

 If you find a built-in property, please let us know.

Mystery solved. The problem I ran into was related to
maven-antrun-plugin. Version 1.4 apparently has a serious bug with
properties (I didn't actually check whether anything was reported).

If I use version 1.6 (the latest at this time) then
${settings.localRepository} works as expected.

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