Velocity templates as remote resources

[Thomas Vandahl]

Hi folks,

I'd like to package a couple of Velocity templates (yes, *.vm!) in a jar 
to be used with the maven-remote-resources-plugin. How do I prevent the 
plugin from processing them?


Bye, Thomas.

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

Re: Upgrading maven-embedder from 2.0.4 to 3.0.2

[Anders Hammar]

"Easier" in that post isn't referring to easier to code as in fewer lines of
code, but rather making it possible to embed in an extensible way.
Maven 2.x was a command line tool, where Maven 3.0 has a modular design so
that it can be embedded in tools like m2eclipse, for example. This was
simply just not possible (in a good way) with Maven 2.x. As I understand it,
maven-embedder stopped at 2.0.4 for Maven 2 because they ran into too many
issues trying to get it to work with the old Maven 2 code base.

/Anders

On Fri, Mar 4, 2011 at 06:13, mraible  wrote:

> This seems somewhat complicated - isn't there an easier way? Of the top 10
> reasons to use Maven, #4 is it's easier to embed.
>
> http://www.sonatype.com/people/2011/02/top-ten-reasons-to-move-to-maven-3/
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Upgrading-maven-embedder-from-2-0-4-to-3-0-2-tp3379984p3408943.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Upgrading maven-embedder from 2.0.4 to 3.0.2

[mraible]

This seems somewhat complicated - isn't there an easier way? Of the top 10
reasons to use Maven, #4 is it's easier to embed.

http://www.sonatype.com/people/2011/02/top-ten-reasons-to-move-to-maven-3/

--
View this message in context: 
http://maven.40175.n5.nabble.com/Upgrading-maven-embedder-from-2-0-4-to-3-0-2-tp3379984p3408943.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

[ANN] Apache Maven 3.0.3 Released

[Benjamin Bentmann]

The Maven team is pleased to announce the release of Apache Maven 3.0.3

Maven is a project comprehension and build tool, designed to simplify 
the process of maintaining a healthy development lifecycle for your 
project. You can read more here:


http://maven.apache.org/

Downloads of source and binary distributions are listed in our download 
section:


http://maven.apache.org/download.html

A major goal of Maven 3.0.x is to be compatible, to the extent possible, 
with existing plugins and projects designed for Maven 2.x. Users 
interested in upgrading to 3.x should have a glance at the compatibility 
notes for known differences between Maven 3.0 and Maven 2.x:


http://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html

Users who already use Maven 3.0.x are encouraged to update to this new 
maintenance release.


If you encounter unexpected problems while using Maven 3.0.3, please 
feel free to contact us via the Maven developer list:


http://maven.apache.org/mail-lists.html

Release Notes - Maven 2 & 3 - Version 3.0.3 (since 3.0.2 only)

** Bug
* [MNG-4551] - List parameter in a mojo has strange behaviour
* [MNG-4956] - Cygwin mvn script modifies CLASSPATH environment 
variable
* [MNG-4962] - MavenProject.getParent fails to build when parent 
POM, in reactor, references BOM also in reactor
* [MNG-4963] - [regression] Parent POM not downloaded when settings 
define global mirror and one snapshot repo but no other release repository
* [MNG-4973] - [regression] Build extensions are invisible to 
plugins in multi module build
* [MNG-4975] - [regression] plugin executions injected from profile 
run before instead of after existing executions in the POM
* [MNG-4982] - [regression] Cycle between transitive dependencies 
causes bad effective dependency scope
* [MNG-4987] - [regression] LATEST, RELEASE or SNAPSHOT version 
picked from wrong repository when resolution order does not match 
timestamp order
* [MNG-4990] - RepositorySystem#resolve(request) uses two different 
local repositories
* [MNG-4991] - LegacyRepositorySystem#injectProxy(repositories, 
proxies) doesn't evaluate non-proxy hosts
* [MNG-5000] - [regression] child distributionManagment.site.url 
not correct in a flat directory layout when child's artifactId doesn't 
match its module name
* [MNG-5003] - MavenPluginManager serves m2e partially initialized 
mojo descriptors in some cases
* [MNG-5005] - bin/mvn contains platform specific echo when on Mac 
OSX and JAVA_VERSION envvar is set
* [MNG-5006] - [regression] Resolution of parent POMs for 
dependency using version range does not consider all configured repositories
* [MNG-5009] - StackOverflowError in DefaultProjectBuilder.build 
when  points at current aggregator POM
* [MNG-5014] - [regression] 
MavenProject.getParent().isExecutionRoot() not properly set
* [MNG-5019] - [regression] String-based component lookups 
performed by report mojos fail with ClassCastException

* [MNG-5023] - Wrong calculation of Build Total time

** Improvement
* [MNG-3575] - Allow hexadecimal parameters
* [MNG-4971] - Display maven home in version info
* [MNG-4984] - Simplify drop in of 3rd party extensions for Maven core
* [MNG-4988] - API to calculate execution plan without full mojo 
execution configuration
* [MNG-4992] - Allow to configure plugin parameters of type 
java.util.Properties just like a map
* [MNG-5011] - Allow to configure array/collection type plugin 
parameters via system properties
* [MNG-5012] - Allow to configure array-typed plugin parameters 
from expressions yielding collections and vice versa
* [MNG-5013] - Allow to condense configuration of plugin parameter 
beans that commonly require only one value

* [MNG-5020] - JAVA_HOME auto discovery
* [MNG-5028] - Obey generics in plugin collection parameters when 
populating them
* [MNG-5033] - Allow to inline collection/array items within plugin 
configuration


** Task
* [MNG-5024] - Update default plugin versions

Enjoy,


-The Maven team

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

Re: Disable checking for updates from xxxx-plugins in multi-module app

[Wayne Fay]

> It spends considerable time trying to 'check for updates', making a compile or
> exec:java take 20 minutes rather than 3. I've tried passing command line
> arguments -npu and/or -npr but maven still performs a 'cehck for updates'. See

The best solution is to simply install a repo manager like Archiva,
Nexus, Artifactory and configure your Maven settings.xml to send all
requests for artifacts to it.

The "quick fix" solution is to set the -o flag when you run Maven eg
mvn -o compile which is "offline" mode.

Wayne

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

How do i layout subversion with a project made of multiple modules ?

[Celinio Fernandes]

Hi,

I was looking for some information on how to layout subversion with a maven 
project made of multi modules and found this interesting discussion :
http://getsatisfaction.com/sonatype/topics/how_do_i_layout_subversion_with_multi_module_builds

I'd like to know if anyone in this mailing list can also share his experience 
regarding this matter.
Currently I have set things in SVN such that each module has its own 
trunk/tags/branches.
What do you think ?

Thanks for helping.



  

Re: Maven 3 deploy jar name appending numbers

[Wayne Fay]

> I tried changing this flag uniqueVersion to false, but still the same effect.
>
> This did not occur with maven 2.  any ideas on how to make the output of 
> deploy be jarname-8.5.3-SNAPSHOT.jar?

This is how Maven3 works, read the compatibility notes for M3.
https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-NonuniqueSnapshotDeployments

Wayne

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

Maven 3 deploy jar name appending numbers

[hall baseball]

When deploying with maven 2 the jar name would look like this:  
jarname-8.5.3-SNAPSHOT.jar.  This name is the same with maven 3 install.  
However as soon as using the deploy target with mvn deploy  the name becomes 
jarname-8.5.3-20110303.203836-1.jar.  (the numbers change each time it is run)

I tried changing this flag uniqueVersion to false, but still the same effect.  

This did not occur with maven 2.  any ideas on how to make the output of deploy 
be jarname-8.5.3-SNAPSHOT.jar?

Thanks

Dave


  

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

Re: assembly plugin broken going from 2.2.1 to 3.0.2

[Dennis Lundberg]

Hi

I'm assuming that org.ferris:ferris-assemblies:jar:0.0.3 is a dependency
that you have configured for the assembly-plugin. If that is the case
then with Maven 3 that dependency must be available in a repository that
is defined as a . If it is only available in a normal
 Maven 3 will not be able to resolve it as a dependency for
a plugin. This is a deliberate change in behavior between Maven 2 and
Maven 3.


On 2011-03-03 15:39, Michael Remijan wrote:
> I've switched to Maven 3.0.2in an attempt to get a working release plugin but 
> now the assembly plugin is not working.
> 
> I can 'clean install' my multi-module project fine with 2.2.1.  When 
> switching to 3.0.2 Maven has a problem with the assembly with the following 
> error printed to the console:
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:single 
> (ferris-bin-assembly) on project ferris-bible-common: Execution 
> ferris-bin-assembly of goal 
> org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:single failed: 
> Plugin org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5 or one of 
> its dependencies could not be resolved: Could not find artifact 
> org.ferris:ferris-assemblies:jar:0.0.3 in central (http://re
> po1.maven.org/maven2) -> [Help 1]

This is telling you that Maven 3 cannot find the artifact
org.ferris:ferris-assemblies:jar:0.0.3 in central
(http://repo1.maven.org/maven2). Note that it is only looking in
central, and not any of your own repositories.


> I highlighted what looks like the root cause of the problem.  My pom is 
> trying to use an assembly I created - org.ferris:ferris-assemblies:jar:0.0.3 
> - however for some reason Maven 3.0.2 is trying to find it in the main Maven 
> Repo.  This already exists in my LOCAL repository and if it didn't it exists 
> on my OSS SONATYPE repository which my settings.xml is configured to point to.
> 
> Any one know of any reason why the assembly plugin has decided to only look 
> for my assembly artifact on the main Maven Repo?
> 


-- 
Dennis Lundberg

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

Disable checking for updates from xxxx-plugins in multi-module app

[marshall]

Hello;

 I've got a legacy multi-module app that I've been tasked to manage. 

It spends considerable time trying to 'check for updates', making a compile or 
exec:java take 20 minutes rather than 3. I've tried passing command line 
arguments -npu and/or -npr but maven still performs a 'cehck for updates'. See 
below

[INFO] artifact org.apache.maven.plugins:maven-scm-plugin: checking for updates 
from myserver-plugins
[WARNING] repository metadata for: 'artifact 
org.apache.maven.plugins:maven-scm-plugin' could not be retrieved from 
repository:  myserver-plugins due to an error: Error transferring file
[INFO] Repository 'myserver-plugins' will be blacklisted

How can I deactivate this in a multi-module app's pom.xml?



Thanks;

Marshall



  

Re: invoking custom tests from another branch

[Zilvinas Vilutis]

just to note :)

"inContainterITest" != "inContainerITest"

the property name in the command line does not match the property in
the pom.xml, that's why the profile is not activated ;)

Have a nice day!


Žilvinas Vilutis

Mobile:   (+370) 652 38353
E-mail:   cika...@gmail.com



On Thu, Mar 3, 2011 at 10:06 AM, Baptiste MATHUS  wrote:
> Well, you could also touch a file or mkdir a directory before and use it as
> an activation property.
> Or even commit something somewhere that would trigger the profile
> activation.
> Or install a VM that would have the right OS that would activate the
> profile.
>
> Or just use the option designed to activate profiles, -P.
>
> ;-).
>
> Sorry, couldn't resist, and we're not wednesday.
>
> Cheers
> PS: just kidding, no offense ;).
>
> 2011/3/3 Thomas Sundberg 
>
>> Hi!
>>
>> You could give your activation property a value and use
>>
>> -DinContainerITest=myValue
>>
>> 
>>   
>>     inContainerITest
>>     myValue
>>   
>> 
>>
>> /Thomas
>>
>>
>> On Thu, Mar 3, 2011 at 17:17, Baptiste MATHUS  wrote:
>>
>>> Hi,
>>>
>>> Use -P. Not -D.
>>>
>>> Cheers
>>> Le 2 mars 2011 18:40, "John Lussmyer"  a écrit
>>> :
>>> > I've inherited a huge complex Maven build process that needs some
>>> updates.
>>> > One thing we have is some custom test code in one place that is invoked
>>> via "mvn clean install -DinContainterITest"
>>> > Now I'd like to invoke that (and several others in other pom's) from a
>>> pom
>>> that is in a different branch of the same pom tree.
>>> >
>>> > The pom with the test code has:
>>> >
>>> > 
>>> > 
>>> > inContainerITest
>>> > 
>>> > 
>>> > inContainerITest
>>> > 
>>> > 
>>> > 
>>> > 
>>> > 
>>> > src/test/resources
>>> > true
>>> > 
>>> > 
>>> > 
>>> > 
>>> > maven-surefire-plugin
>>> > 
>>> > 
>>> > surefire-RestTest
>>> > integration-test
>>> > 
>>> > test
>>> > 
>>> > 
>>> > 
>>> > none
>>> > 
>>> > 
>>> > **/*Test.java
>>> > 
>>> > 
>>> > 
>>> > 
>>> > 
>>> > 
>>> > 
>>> > 
>>> > 
>>> >
>>> > I have a dependency on this one in my other pom like this:
>>> >
>>> > 
>>> > 
>>> > com.xxx..
>>> > stupidlylongartifactname
>>> > ${project.version}
>>> > test
>>> > 
>>> > 
>>> >
>>> > But I don't know how to set it up so that using the "-DinContainerITest"
>>> on the pom will actually invoke the tests.
>>> >
>>> > Suggestions?
>>> >
>>> > This message and the information contained herein is proprietary and
>>> confidential and subject to the Amdocs policy statement,
>>> > you may review at http://www.amdocs.com/email_disclaimer.asp
>>>
>>
>>
>>
>> --
>> Thomas Sundberg
>> M. Sc. in Computer Science
>>
>> Mobile: +46 70 767 33 15
>> Blog: http://thomassundberg.wordpress.com/
>> Twitter: @thomassundberg
>>
>> Better software through faster feedback
>>
>
>
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>

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

Fwd: Doxia Tools > Converter > Additional Usage Example (ant script)

[Brian E. Fox]

For the archives

--Brian (mobile)


Begin forwarded message:

> From: Adrien 
> Date: March 2, 2011 10:22:26 PM EST
> To: bri...@apache.org
> Subject: Doxia Tools > Converter > Additional Usage Example (ant script)
> 

> Hi,
> 
> i've found your project very useful. In my case, i neeeded to run with 
> dependencies included, but i had to inclue it in my existing tasks 
> processing, thus using ant.
> 
> Based on the following link :
> 
> http://maven.apache.org/doxia/doxia-tools/doxia-converter/usage.html
> 
> It could be also usefu for other people to have a dummy ant snippet to add 
> the conversion in their build. here is mine (apt to other formats), it'a 
> quite dummy and straightforward :
> 
> 
> 
> 
> 
> 
> 
> 
>  jar="./lib/doxia-converter-1.2-jar-with-dependencies.jar"
> dir="."
> fork="true"
> failonerror="true"
> >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Hopefully will it be useful to someone else.
> 
> 
> Thank you for your work.
> 
> Kind Regards,
> 
> Adrien
> 

Re: invoking custom tests from another branch

[Baptiste MATHUS]

Well, you could also touch a file or mkdir a directory before and use it as
an activation property.
Or even commit something somewhere that would trigger the profile
activation.
Or install a VM that would have the right OS that would activate the
profile.

Or just use the option designed to activate profiles, -P.

;-).

Sorry, couldn't resist, and we're not wednesday.

Cheers
PS: just kidding, no offense ;).

2011/3/3 Thomas Sundberg 

> Hi!
>
> You could give your activation property a value and use
>
> -DinContainerITest=myValue
>
> 
>   
> inContainerITest
> myValue
>   
> 
>
> /Thomas
>
>
> On Thu, Mar 3, 2011 at 17:17, Baptiste MATHUS  wrote:
>
>> Hi,
>>
>> Use -P. Not -D.
>>
>> Cheers
>> Le 2 mars 2011 18:40, "John Lussmyer"  a écrit
>> :
>> > I've inherited a huge complex Maven build process that needs some
>> updates.
>> > One thing we have is some custom test code in one place that is invoked
>> via "mvn clean install -DinContainterITest"
>> > Now I'd like to invoke that (and several others in other pom's) from a
>> pom
>> that is in a different branch of the same pom tree.
>> >
>> > The pom with the test code has:
>> >
>> > 
>> > 
>> > inContainerITest
>> > 
>> > 
>> > inContainerITest
>> > 
>> > 
>> > 
>> > 
>> > 
>> > src/test/resources
>> > true
>> > 
>> > 
>> > 
>> > 
>> > maven-surefire-plugin
>> > 
>> > 
>> > surefire-RestTest
>> > integration-test
>> > 
>> > test
>> > 
>> > 
>> > 
>> > none
>> > 
>> > 
>> > **/*Test.java
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> >
>> > I have a dependency on this one in my other pom like this:
>> >
>> > 
>> > 
>> > com.xxx..
>> > stupidlylongartifactname
>> > ${project.version}
>> > test
>> > 
>> > 
>> >
>> > But I don't know how to set it up so that using the "-DinContainerITest"
>> on the pom will actually invoke the tests.
>> >
>> > Suggestions?
>> >
>> > This message and the information contained herein is proprietary and
>> confidential and subject to the Amdocs policy statement,
>> > you may review at http://www.amdocs.com/email_disclaimer.asp
>>
>
>
>
> --
> Thomas Sundberg
> M. Sc. in Computer Science
>
> Mobile: +46 70 767 33 15
> Blog: http://thomassundberg.wordpress.com/
> Twitter: @thomassundberg
>
> Better software through faster feedback
>



-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: Issue with mvn3 timestamp snapshots being downloaded in local repository

[Yann Albou]

@benjamin

There are several drawbacks with the
maven-dependency-plugin:purge-local-repository:

- Performances slowdown if used systematically, i.e. included in project's
pom or worse super pom, due to the downloads from the remote. One benefit of
upgrading to maven 3 for us is the performance improvement, this will kill
it. 

- According to Maven 3 incompatibilities the way dependencies are analyzed
has changed and the dependency plugin has not yet been updated, potentially
resulting in different set of artifacts being purged than those build
https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-DependencyResolution.
 
I am assuming that all the maven-dependency-plugin goals share the same
resolution mechanism as the tree one.

- Leaving it up to the developers, at the expense of putting on them a new
thing they didn't had to bother when using Maven 2, at least not so often.
Not a selling point for Maven 3 adoption.


@Jörg

Just to clarify, the timestamp artifacts don't end with -SNAPSHOT but with
the timestamp like 
A-1.0.0-20110302.160157-17.jar.


--
View this message in context: 
http://maven.40175.n5.nabble.com/Issue-with-mvn3-timestamp-snapshots-being-downloaded-in-local-repository-tp3408008p3408225.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

Re: invoking custom tests from another branch

[Thomas Sundberg]

Hi!

You could give your activation property a value and use

-DinContainerITest=myValue


  
inContainerITest
myValue
  


/Thomas


On Thu, Mar 3, 2011 at 17:17, Baptiste MATHUS  wrote:

> Hi,
>
> Use -P. Not -D.
>
> Cheers
> Le 2 mars 2011 18:40, "John Lussmyer"  a écrit :
> > I've inherited a huge complex Maven build process that needs some
> updates.
> > One thing we have is some custom test code in one place that is invoked
> via "mvn clean install -DinContainterITest"
> > Now I'd like to invoke that (and several others in other pom's) from a
> pom
> that is in a different branch of the same pom tree.
> >
> > The pom with the test code has:
> >
> > 
> > 
> > inContainerITest
> > 
> > 
> > inContainerITest
> > 
> > 
> > 
> > 
> > 
> > src/test/resources
> > true
> > 
> > 
> > 
> > 
> > maven-surefire-plugin
> > 
> > 
> > surefire-RestTest
> > integration-test
> > 
> > test
> > 
> > 
> > 
> > none
> > 
> > 
> > **/*Test.java
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > I have a dependency on this one in my other pom like this:
> >
> > 
> > 
> > com.xxx..
> > stupidlylongartifactname
> > ${project.version}
> > test
> > 
> > 
> >
> > But I don't know how to set it up so that using the "-DinContainerITest"
> on the pom will actually invoke the tests.
> >
> > Suggestions?
> >
> > This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> > you may review at http://www.amdocs.com/email_disclaimer.asp
>



-- 
Thomas Sundberg
M. Sc. in Computer Science

Mobile: +46 70 767 33 15
Blog: http://thomassundberg.wordpress.com/
Twitter: @thomassundberg

Better software through faster feedback

Re: invoking custom tests from another branch

[Baptiste MATHUS]

Hi,

Use -P. Not -D.

Cheers
Le 2 mars 2011 18:40, "John Lussmyer"  a écrit :
> I've inherited a huge complex Maven build process that needs some updates.
> One thing we have is some custom test code in one place that is invoked
via "mvn clean install -DinContainterITest"
> Now I'd like to invoke that (and several others in other pom's) from a pom
that is in a different branch of the same pom tree.
>
> The pom with the test code has:
>
> 
> 
> inContainerITest
> 
> 
> inContainerITest
> 
> 
> 
> 
> 
> src/test/resources
> true
> 
> 
> 
> 
> maven-surefire-plugin
> 
> 
> surefire-RestTest
> integration-test
> 
> test
> 
> 
> 
> none
> 
> 
> **/*Test.java
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
> I have a dependency on this one in my other pom like this:
>
> 
> 
> com.xxx..
> stupidlylongartifactname
> ${project.version}
> test
> 
> 
>
> But I don't know how to set it up so that using the "-DinContainerITest"
on the pom will actually invoke the tests.
>
> Suggestions?
>
> This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp

Re: Issue with mvn3 timestamp snapshots being downloaded in local repository

[Jörg Schaible]

Hi Yann,

Yann Albou wrote:

>> So what you describe is normal and has been like this since Maven 2.x
> 
> With Maven 2 we used unique snapshot versions.
> 
> The issue with Maven 3 is that developers local repositories might grow
> significantly since several timestamp snapshots are downloaded.
> 
> Also we don't have a mechanism to purge the local repositories as we do on
> the remote repository with Nexus, or does maven provide one I don't know
> of?

Delete all directories in your local repo that end with "-SNAPSHOT".

Under Linux we use actually an alias:

alias repoclean='find `cat ~/.m2/repoclean` -type d -name "*-SNAPSHOT" -
prune -exec rm -rvf \{} +'

with ~/.m2/repoclean containing a list of paths e.g.

//com/yourcompany

- Jörg


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

Re: Issue with mvn3 timestamp snapshots being downloaded in local repository

[Benjamin Bentmann]

Yann Albou wrote:


Also we don't have a mechanism to purge the local repositories as we do on
the remote repository with Nexus, or does maven provide one I don't know of?


http://maven.apache.org/plugins/maven-dependency-plugin/purge-local-repository-mojo.html


Benjamin

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

Re: Issue with mvn3 timestamp snapshots being downloaded in local repository

[Yann Albou]

> So what you describe is normal and has been like this since Maven 2.x 

With Maven 2 we used unique snapshot versions.

The issue with Maven 3 is that developers local repositories might grow
significantly since several timestamp snapshots are downloaded. 

Also we don't have a mechanism to purge the local repositories as we do on
the remote repository with Nexus, or does maven provide one I don't know of?


--
View this message in context: 
http://maven.40175.n5.nabble.com/Issue-with-mvn3-timestamp-snapshots-being-downloaded-in-local-repository-tp3408008p3408127.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

Re: How to release a single module in a Mercurial repository?

[Andreas Ebbert-Karroum]

Hi,

I still stand by my claim that the story of releasing a single module in a
hg multi-module repository is currently not possible. Now you might say,
that this is against conventions, and you should always release the whole
repository, but usage of of maven and mercurial differs, and after all it's
"convention over configuration" and not "convention or not at all".

In this E-Mail I will prove to you that this is not possible, if you will
follow me through the following steps. If at any point I missed an option I
would like you to raise your voice :)

*Step 1*

So, I started with a very simple multi-module project (/pom.xml and
/multi/pom.xml) and tried to release just a single module (multi). It turned
out that this is not possible, because during the release:perform phase, the
whole hg repository is checked out, and the build is started in the root of
that repository.

=> Use the latest maven-release-plugin:2.2-SNAPSHOT in which
MRELEASE-457is fixed.

*Step 2*

The new dependencies with the snapshot release plugin also updates to a
newer hg scm provider. The new hg scm provider has the interesting new habit
to throw an exception, when you want to tag something, which does not
concern the whole repository.

Caused by: org.apache.maven.scm.ScmException: This provider doesn't support
tagging subsets of a directory
at
org.apache.maven.scm.provider.hg.command.tag.HgTagCommand.executeTagCommand(HgTagCommand.java:77)
at
org.apache.maven.scm.command.tag.AbstractTagCommand.executeCommand(AbstractTagCommand.java:81)
at
org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:59)
... 29 more

=> Update the dependencies of maven-release-plugin:2.2-SNAPSHOT to use
maven-scm-provider-hg:1.4

*Step 3
*
The next step was to move the parent pom out of the root of the hg
repository. We have a standardized layout in our hg repositories (to take
into account various tradeoffs between maven, m2eclipse, hudson, etc.) that
we have all projects in directories under the root directory. So I tried to
have
/ root / pom.xml (having a module ../multi)
and
/ multi / pom.xml (having a parent ../root)

The release plugin did not like that at all:

[INFO] EXECUTING: cmd.exe /X /C "hg commit --message "[maven-release-plugin]
prepare release root-1.6" C:\Temp\releasetest\parent\pom.xml
C:\Temp\releasetest\multi\pom.xml"
[INFO] EXECUTING: cmd.exe /X /C "*hg push file:///C:/Temp/releasetestrepo*"
[INFO] Tagging release with the label root-1.6...
[INFO] EXECUTING: cmd.exe /X /C "hg tag --message "[maven-release-plugin]
copy for tag root-1.6" root-1.6"
[INFO] EXECUTING: cmd.exe /X /C "*hg push file:///C:/Temp*"
[ERROR]
EXECUTION FAILED
  Execution of cmd : push failed with exit code: -1.
  Working directory was:
c:\temp\releasetest
  Your Hg installation seems to be valid and complete.
Hg version: 1.6.2 (OK)


This is probably a bug, but I have no idea if this is in the scm provider,
release plugin, shared components, ... I'm glad to create a jira issue for
it, but would like to do so for the right project.

=> Having no pom.xml in the root of the repository is apparently a bad idea.
But we need to have our "parent" in a folder under the root directly. So I
created a thin dummy pom, which just has the real parent as module.

*Step 4*

So we now have:
/ pom.xml
/ parent / pom.xml
/ multi / pom.xml

While I created the root pom.xml, I tried to optimize a bit and included
localCheckout=true to the plugin configuration, so that the tag checkout
does not happen from the remote repository, but from the local one. Bad
idea:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.2-SNAPSHOT:perform
(default-cli) on project root: The scm url is invalid.
[ERROR] - An hg 'file' url must be on the form 'file:///' or
'file://localhost/'.

My scm url is: scm:hg:file:///C:/Temp/releasetestrepo

So also the "remote" hg repository is on the local filesystem, but when the
local checkout occurs, the url is apparently not constructed correctly.

=> Ok, no localCheckout. Not a big deal, moving on.

*Step 5*

If possible, I don't want the /parent/pom.xml to inherit from /pom.xml,
because it may well be, that it needs to inherit from something completely
different. I only wanted to use the /pom.xml as a forwarder to
/parent/pom.xml. So I tried that, and tried to release the "multi"-module. I
did this by running from working directory /parent the command "mvn
--batch-mode -pl multi release:prepare". But I could not find a working scm
configuration in /parent/pom.xml

When it was set to "scm:hg:file:///C:/Temp/releasetestrepo/parent" I got
this error - apperently it tried to replace the current module name "parent"
in the scm url with "multi":
[INFO] EXECUTING: cmd.exe /X /C "hg commit --message "[maven-release-plugin]
prepare release multi-1.22" C:\Temp\releasetest\multi\pom.xml"
[INFO] EXECUTING: cmd.exe /X /C "hg push *
file:///C:/Temp/

Re: Issue with mvn3 timestamp snapshots being downloaded in local repository

[Benjamin Bentmann]

Yann Albou wrote:


It's my understanding that timestamp snapshots should only exist in remote
snapshot repositories and are created when doing a mvn deploy.

What I see though is timestamp snapshots downloaded into my local repository
when doing mvn install.


True is that "mvn install" of project A generates no timestamped 
artifact for A. But when resolving dependency B from a remote 
repository, the timestamped file for B is retrieved and retained with 
the timestamped version in the local repository. So what you describe is 
normal and has been like this since Maven 2.x



Also to be noted the jumps in the version of the timestamp (4, 8, 11, 17),
although the remote snapshot repository contains all the versions from 4 up
to 17.


Maven just downloads the version that was deemed latest at the time it 
was resolved.



Benjamin

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

Re: assembly plugin broken going from 2.2.1 to 3.0.2

[Benjamin Bentmann]

Michael Remijan wrote:


[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:single 
(ferris-bin-assembly) on project ferris-bible-common: Execution 
ferris-bin-assembly of goal 
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:single failed: Plugin 
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5 or one of its 
dependencies could not be resolved: Could not find artifact 
org.ferris:ferris-assemblies:jar:0.0.3 in central (http://re
po1.maven.org/maven2) ->  [Help 1]

[...] This already exists in my LOCAL repository and if it didn't it exists on 
my OSS SONATYPE repository which my settings.xml is configured to point to.


Proposed next steps
a) Verify your OSS repo is also configured as a 
b) Re-test using staged Maven 3.0.3 [0]
c) Fill a bug with an example project to reproduce the issue


Benjamin


[0] 
https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.0.3/


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

Issue with mvn3 timestamp snapshots being downloaded in local repository

[Yann Albou]

It's my understanding that timestamp snapshots should only exist in remote
snapshot repositories and are created when doing a mvn deploy.

What I see though is timestamp snapshots downloaded into my local repository
when doing mvn install.

Here the test case:
artifact a (jar) depends on artifact b (jar) both are snapshots and they
both inherit from maven's default super pom (i.e. no company's super pom is
used). also they have different groupId.

I first deploy artifact a, then pretending to be a different developer I
delete artifact from my local repository and install artifact b, I now see
artifact a timestamp snapshot (a-1.0.0-20110302.155002-4.jar) downloaded in
my local repository.

If a deploy several times artifact a and each time install artifact b, I end
up with several timestamp snapshots in my local repository
(a-1.0.0-20110302.155504-8.jar, a-1.0.0-20110302.155739-11.jar,
a-1.0.0-20110302.160157-17.jar).

Also to be noted the jumps in the version of the timestamp (4, 8, 11, 17),
although the remote snapshot repository contains all the versions from 4 up
to 17.

Is this the intended behavior in mvn 3, a bug or something I missed?

Using:
mvn 3.0.2
nexus 1.9.0.1


--
View this message in context: 
http://maven.40175.n5.nabble.com/Issue-with-mvn3-timestamp-snapshots-being-downloaded-in-local-repository-tp3408008p3408008.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

assembly plugin broken going from 2.2.1 to 3.0.2

[Michael Remijan]

I've switched to Maven 3.0.2in an attempt to get a working release plugin but 
now the assembly plugin is not working.

I can 'clean install' my multi-module project fine with 2.2.1.  When switching 
to 3.0.2 Maven has a problem with the assembly with the following error printed 
to the console:

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:single 
(ferris-bin-assembly) on project ferris-bible-common: Execution 
ferris-bin-assembly of goal 
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:single failed: Plugin 
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5 or one of its 
dependencies could not be resolved: Could not find artifact 
org.ferris:ferris-assemblies:jar:0.0.3 in central (http://re
po1.maven.org/maven2) -> [Help 1]

I highlighted what looks like the root cause of the problem.  My pom is trying 
to use an assembly I created - org.ferris:ferris-assemblies:jar:0.0.3 - however 
for some reason Maven 3.0.2 is trying to find it in the main Maven Repo.  This 
already exists in my LOCAL repository and if it didn't it exists on my OSS 
SONATYPE repository which my settings.xml is configured to point to.

Any one know of any reason why the assembly plugin has decided to only look for 
my assembly artifact on the main Maven Repo?

Re: Integrate Maven Plugin Code (Mojo's) into Application

[Karl Heinz Marbaise]

Hi,

after digging around i found a 
http://maven.40175.n5.nabble.com/Maven-Embedder-2-0-4-replacement-Where-to-start-td3399113.html
good post  which brought me a large step further

But currently i'm hanging in my code, cause every time i run my code it will
fail with an exception ( throw new IllegalArgumentException( "mavenTools:
null" ))
which means my initialization/configuration code seemed to be wrong...


   MavenProject( RepositorySystem repositorySystem, ProjectBuilder
mavenProjectBuilder,
  ProjectBuildingRequest projectBuilderConfiguration, Logger
logger )
{
if ( repositorySystem == null )
{
throw new IllegalArgumentException( "mavenTools: null" );
}

this.mavenProjectBuilder = mavenProjectBuilder;
this.projectBuilderConfiguration = projectBuilderConfiguration;
this.repositorySystem = repositorySystem;
this.logger = logger;
}


So the question is: Does someone has an idea what could be wrong or may be a
better source of information/documentation?


PlexusContainer pc = null;
try {
pc = getPlexusContainer();
} catch (PlexusContainerException e1) {
LOGGER.error("Failure during creation of plexus container:" ,
e1);
}

RepositorySystemSession repoSession = null;
MavenExecutionRequest mavenExecutionRequest =
createExecutionRequest();

ArtifactRepository localRepository = getLocalRepository();

org.sonatype.aether.RepositorySystem repoSystem = null;
try {
repoSystem = lookup(org.sonatype.aether.RepositorySystem.class);
} catch (ComponentLookupException e2) {
LOGGER.error("ComponentLookupException:" , e2);
} catch (PlexusContainerException e2) {
LOGGER.error("PlexusContainerException:" , e2);
}

MavenRepositorySystemSession mavenRepositorySystemSession = new
MavenRepositorySystemSession();
   
mavenRepositorySystemSession.setLocalRepositoryManager(repoSystem.newLocalRepositoryManager(new
LocalRepository(localRepository
.getBasedir(;

mavenExecutionRequest.setBaseDirectory(workingDirectory);
MavenExecutionResult mavenExecutionResult = new
DefaultMavenExecutionResult();
try {
repoSession = createRepositorySession(mavenExecutionRequest);
} catch (ComponentLookupException e1) {
LOGGER.error("ComponentLookupException:" , e1);
} catch (PlexusContainerException e1) {
LOGGER.error("PlexusContainerException:" , e1);
}

MavenSession session = new MavenSession(pc, repoSession,
mavenExecutionRequest, mavenExecutionResult);

op.setSession(session);
DefaultProjectBuilder defaultProjectBuilder = new
DefaultProjectBuilder();
op.setProjectBuilder(defaultProjectBuilder);
try {
   
lookup(MavenExecutionRequestPopulator.class).populateDefaults(mavenExecutionRequest);
ProjectBuildingRequest configuration =
mavenExecutionRequest.getProjectBuildingRequest();
   
configuration.setValidationLevel(ModelBuildingRequest.VALIDATION_LEVEL_STRICT);
   
configuration.setRepositorySession(createRepositorySession(mavenExecutionRequest));
MavenProject workspaceProject =
lookup(ProjectBuilder.class).build(new File(workingDirectory, "pom.xml"),
configuration).getProject();

op.setWorkspaceProject(workspaceProject);

op.execute();
result = true;
} catch (MojoExecutionException e) {
LOGGER.error("MojoExecutionException:", e);
} catch (MojoFailureException e) {
LOGGER.error("MojoFailureException:", e);
} catch (MavenExecutionRequestPopulationException e) {
LOGGER.error("MavenExecutionRequestPopulationException:", e);
} catch (ComponentLookupException e) {
LOGGER.error("ComponentLookupException:", e);
} catch (PlexusContainerException e) {
LOGGER.error("PlexusContainerException:", e);
} catch (ProjectBuildingException e) {
LOGGER.error("ProjectBuildingException:", e);
}


Many thanks in advance
Kind regards
Karl Heinz Marbaise

-
Kind regards
Karl Heinz Marbaise

http://www.soebes.de
http://www.skmwiki.de
http://supose.org/wiki/supose
--
View this message in context: 
http://maven.40175.n5.nabble.com/Integrate-Maven-Plugin-Code-Mojo-s-into-Application-tp3397120p3407981.html
Sent from the Maven - Users mailing list archive at Nabble.com.