Re: Frustration with snapshot updates

[Quintin Beukes]

It succeeds.

There is nothing missing. I build the project from svn trunk, it get's
installed in the repo, and now maven keeps trying to download it by
iterating all my repositories.

It's part of the snapshot updates. It happens with ALL snapshot
dependencies. As soon as I add another snapshot dependency, it gets
added to the list.

Everything is fine. I can temporarily bypass it by updating the
modification dates on the files, but that's only effective for 2
minutes, and I don't want to update them everytime I build.

All I need is to disable snapshot updates for all repos, completely. I
don't need it on this development. When I need it one day I'll
re-enable it, and by then the dependancy will be released and won't be
a snapshot anymore.

Quintin Beukes



On Sat, Oct 3, 2009 at 3:43 AM, Brian Fox  wrote:
> On Fri, Oct 2, 2009 at 11:55 AM, Quintin Beukes  wrote:
>> Firstly, -o won't work, because I have to re-enable it everytime a
>> build fails for a legitimate dependency.
>>
>> Secondly, it's snapshots built from dev source code - I update via SVN
>> and build them to get the latest versions. So they're not available in
>> the remote repositories yet.
>>
>> And it's definitely required dependencies. It's getting bad, because
>> as the project grows, they get more, and I wait about 40 seconds now
>> just for the downloads to fail, so my build can complete.
>
> Can complete with build failed or success? I feel like there's still
> something fundamentally missing here.
>
>>
>> Quintin Beukes
>>
>>
>>
>> On Fri, Oct 2, 2009 at 8:43 PM, Brian Fox  wrote:
>>> On Fri, Oct 2, 2009 at 3:54 AM, Quintin Beukes  wrote:
 Hey,

 Whenever a project depends on a snapshot versioned library, then it
 tries to update this snapshot. If the snapshot isn't found in any of
 the repositories, then it obviously doesn't update. But now it tries
 again with the next build. And over, and over, and over.
>>>
>>> I'll ask the obvious question first: Why do you have a dependency that
>>> doesn't exist? And if your build succeeds without this dependency, is
>>> it even a defacto dependency?
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

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

Re: Frustration with snapshot updates

[Brian Fox]

On Fri, Oct 2, 2009 at 11:55 AM, Quintin Beukes  wrote:
> Firstly, -o won't work, because I have to re-enable it everytime a
> build fails for a legitimate dependency.
>
> Secondly, it's snapshots built from dev source code - I update via SVN
> and build them to get the latest versions. So they're not available in
> the remote repositories yet.
>
> And it's definitely required dependencies. It's getting bad, because
> as the project grows, they get more, and I wait about 40 seconds now
> just for the downloads to fail, so my build can complete.

Can complete with build failed or success? I feel like there's still
something fundamentally missing here.

>
> Quintin Beukes
>
>
>
> On Fri, Oct 2, 2009 at 8:43 PM, Brian Fox  wrote:
>> On Fri, Oct 2, 2009 at 3:54 AM, Quintin Beukes  wrote:
>>> Hey,
>>>
>>> Whenever a project depends on a snapshot versioned library, then it
>>> tries to update this snapshot. If the snapshot isn't found in any of
>>> the repositories, then it obviously doesn't update. But now it tries
>>> again with the next build. And over, and over, and over.
>>
>> I'll ask the obvious question first: Why do you have a dependency that
>> doesn't exist? And if your build succeeds without this dependency, is
>> it even a defacto dependency?
>>
>> -
>> 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: installing src or javadoc into local repository

[Roland Asmann]

Check the install-mojo for this:
http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html

Reinstall the jar into your repository and add the 'javadoc' and 'sources'
switches or install them separately with the 'classifier' switch.

Roland



> I apologize for the naive question in advance.  I have installed an
> external jar file into my local repository--very easy.  The jar file
> was built using ant as part of a third-party project.  I would now
> like to add the source and/or the javadocs to my local repository,
> also.  I have the source (in src/java/) and can generate the
> javadoc.  How can I install these files into my local repository (so
> that I have the equivalent of the "download sources and javadocs")?
>
> Thanks,
> Sean
>
> -
> 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: Reactor - skip parent project build

[Pasillas, Chris]

You can create a separate pom that only includes the your 5 modules to build, 
don't use the parent pom to do the reactor build.

-Original Message-
From: Brian Fox [mailto:bri...@infinity.nu] 
Sent: Wednesday, September 30, 2009 10:31 PM
To: Maven Users List
Subject: Re: Reactor - skip parent project build

You can't. The parent will always run first in a reactor before
anything that inherits from it.

On Wed, Sep 30, 2009 at 6:03 PM, droidin.net  wrote:
>
> I have a parent POM which defines 5 modules (5 subprojects). Since each
> module is executed in exactly the same way I pull  section
> into the parent POM to get rid of the duplicate code. Now - if I execute
> build individually from each module it works, however if I want to build all
> modules at once and move to the parent directory I got error since the very
> first thing Maven tries to execute is the parent project itself:
>
>>mvn package -P release
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO]   DWD Parent project
> [INFO]   Projects
>
> After that build fails because exec plugin tries to execute something that
> is not there. Looking at the output it is pretty obvious that reactor plugin
> is driving the build but how can I configure reactor to skip the parent?
> --
> View this message in context: 
> http://www.nabble.com/Reactor---skip-parent-project-build-tp25691730p25691730.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
>
>

-
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

installing src or javadoc into local repository

[Sean Davis]

I apologize for the naive question in advance.  I have installed an
external jar file into my local repository--very easy.  The jar file
was built using ant as part of a third-party project.  I would now
like to add the source and/or the javadocs to my local repository,
also.  I have the source (in src/java/) and can generate the
javadoc.  How can I install these files into my local repository (so
that I have the equivalent of the "download sources and javadocs")?

Thanks,
Sean

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

Re: Trouble running Maven test case

[laredotornado]

Sadly, I don't have control over what version of Maven is used at this
company.  Take your best shot, - Dave



Stephen Connolly-2 wrote:
> 
> Maven 1.1 is very old, and a completely different architecture than maven
> 2.0.  You may not get many answers
> 
> 2009/10/2 laredotornado 
> 
>>
>> Hi,
>>
>> I'm using Maven 1.1 with maven-test-plugin-1.8.2.jar.  When I run the
>> "test:single" target with my test class, I get a bunch of compilation
>> errors
>> (all related to jwebunit), despite the fact I have this dependency in my
>> project.xml ...
>>
>>
>>net.sourceforge.jwebunit
>>jwebunit-htmlunit-plugin
>>1.4
>>
>>
>> I read somewhere that I'm supposed to set this property ...
>>
>> maven.test.classpath
>>
>> when using the maven test plugin.  Although I put this property and the
>> associated jars in my project.properties file, I still get compilation
>> errors.  Any ideas how to proceed from here? - Dave
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Trouble-running-Maven-test-case-tp25722078p25722078.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
>>
>>
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Trouble-running-Maven-test-case-tp25722078p25723646.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: Trouble running Maven test case

[Stephen Connolly]

Maven 1.1 is very old, and a completely different architecture than maven
2.0.  You may not get many answers

2009/10/2 laredotornado 

>
> Hi,
>
> I'm using Maven 1.1 with maven-test-plugin-1.8.2.jar.  When I run the
> "test:single" target with my test class, I get a bunch of compilation
> errors
> (all related to jwebunit), despite the fact I have this dependency in my
> project.xml ...
>
>
>net.sourceforge.jwebunit
>jwebunit-htmlunit-plugin
>1.4
>
>
> I read somewhere that I'm supposed to set this property ...
>
> maven.test.classpath
>
> when using the maven test plugin.  Although I put this property and the
> associated jars in my project.properties file, I still get compilation
> errors.  Any ideas how to proceed from here? - Dave
>
> --
> View this message in context:
> http://www.nabble.com/Trouble-running-Maven-test-case-tp25722078p25722078.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
>
>

Trouble running Maven test case

[laredotornado]

Hi,

I'm using Maven 1.1 with maven-test-plugin-1.8.2.jar.  When I run the
"test:single" target with my test class, I get a bunch of compilation errors
(all related to jwebunit), despite the fact I have this dependency in my
project.xml ...


net.sourceforge.jwebunit
jwebunit-htmlunit-plugin
1.4


I read somewhere that I'm supposed to set this property ...

maven.test.classpath

when using the maven test plugin.  Although I put this property and the
associated jars in my project.properties file, I still get compilation
errors.  Any ideas how to proceed from here? - Dave

-- 
View this message in context: 
http://www.nabble.com/Trouble-running-Maven-test-case-tp25722078p25722078.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: Frustration with snapshot updates

[Quintin Beukes]

Yeah, I read that but forgot about it while typing the e-mail :/ Long
day I guess.

How do I change these for "ALL" repositories?

Quintin Beukes



On Fri, Oct 2, 2009 at 9:17 PM, Wendy Smoak  wrote:
> On Fri, Oct 2, 2009 at 11:55 AM, Quintin Beukes  wrote:
>
>> And it's definitely required dependencies. It's getting bad, because
>> as the project grows, they get more, and I wait about 40 seconds now
>> just for the downloads to fail, so my build can complete.
>
> Did you try Jason's suggestion and change your repository update
> policies?  You should be able to tell it not to check on every single
> build.
>
> --
> Wendy
>
> -
> 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: [m2.2.1] BUILD ERROR -- (attached a test case)

[Adrian Herscu]

Test case attached in root.7z

Adrian.

Adrian Herscu wrote:

Hi all,

I have the following multi-project structure:

root
+my-maven-plugin
+my-component

My component requires my Maven plugin in order to build. Hence it declares:
  
...

  
org.foo
my-maven-plugin
1.0-beta-1-SNAPSHOT
true
  
...

After deleting the org/foo hive in my local repository I ran mvn -o 
validate on the root and got:

[INFO]
NOTE: Maven is executing in offline mode. Any artifacts not already in 
your local repository will be inaccessible.


[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   root
[INFO]   my-maven-plugin
[INFO]   my-component
[INFO] 


[ERROR] BUILD ERROR
[INFO] 

[INFO] Plugin could not be found - check that the goal name is correct: 
System is offline.


Try downloading the file manually from the project website.

Then, install it using the command:
mvn install:install-file -DgroupId=org.foo -DartifactId
=my-maven-plugin -Dversion=1.0-beta-1-SNAPSHOT -Dpackaging=maven-plugin
 -Dfile=/path/to/file

Alternatively, if you host your own repository you can deploy the file 
there:
mvn deploy:deploy-file -DgroupId=org.foo 
-DartifactId=my-maven-plugin -Dversion=1.0-beta-1-SNAPSHOT 
-Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url] 
-DrepositoryId=[id]



  org.foo:my-maven-plugin:maven-plugin:1.0-beta-1-SNAPSHOT
  org.foo:my-maven-plugin:maven-plugin:1.0-beta-1-SNAPSHOT



[INFO] 


[INFO] For more information, run Maven with the -e switch
[INFO] 



Shouldn't it build my-maven-plugin before?!
Adrian.



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

Re: Altering the classpath used for unit testing...

[Stephen Connolly]

add a project/build/testResources/testResource to your pom

2009/10/2 David Sharp 

> I am attempting to use maven to run unit tests on a struts web
> application.  Struts needs access to a resource file located in my ear
> project under src/main/application/.  At run time, this file is in the
> classpath and all is good.  At test time, however, it's not in the
> classpath.  How can I add this file to the classpath used for running
> unit tests?
>
> Thanks,
> Dave
> ---
> There are 10 types of people in the world, those that understand
> binary, and those that don't.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

[m2.2.1] BUILD ERROR -- Plugin could not be found

[Adrian Herscu]

Hi all,

I have the following multi-project structure:

root
+my-maven-plugin
+my-component

My component requires my Maven plugin in order to build. Hence it declares:
  
...

  
org.foo
my-maven-plugin
1.0-beta-1-SNAPSHOT
true
  
...

After deleting the org/foo hive in my local repository I ran mvn -o 
validate on the root and got:

[INFO]
NOTE: Maven is executing in offline mode. Any artifacts not already in 
your local repository will be inaccessible.


[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   root
[INFO]   my-maven-plugin
[INFO]   my-component
[INFO] 


[ERROR] BUILD ERROR
[INFO] 

[INFO] Plugin could not be found - check that the goal name is correct: 
System is offline.


Try downloading the file manually from the project website.

Then, install it using the command:
mvn install:install-file -DgroupId=org.foo -DartifactId
=my-maven-plugin -Dversion=1.0-beta-1-SNAPSHOT -Dpackaging=maven-plugin
 -Dfile=/path/to/file

Alternatively, if you host your own repository you can deploy the file 
there:
mvn deploy:deploy-file -DgroupId=org.foo 
-DartifactId=my-maven-plugin -Dversion=1.0-beta-1-SNAPSHOT 
-Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url] 
-DrepositoryId=[id]



  org.foo:my-maven-plugin:maven-plugin:1.0-beta-1-SNAPSHOT
  org.foo:my-maven-plugin:maven-plugin:1.0-beta-1-SNAPSHOT



[INFO] 


[INFO] For more information, run Maven with the -e switch
[INFO] 



Shouldn't it build my-maven-plugin before?!
Adrian.


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

Altering the classpath used for unit testing...

[David Sharp]

I am attempting to use maven to run unit tests on a struts web
application.  Struts needs access to a resource file located in my ear
project under src/main/application/.  At run time, this file is in the
classpath and all is good.  At test time, however, it's not in the
classpath.  How can I add this file to the classpath used for running
unit tests?

Thanks,
Dave
---
There are 10 types of people in the world, those that understand
binary, and those that don't.

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

Re: Frustration with snapshot updates

[Wendy Smoak]

On Fri, Oct 2, 2009 at 11:55 AM, Quintin Beukes  wrote:

> And it's definitely required dependencies. It's getting bad, because
> as the project grows, they get more, and I wait about 40 seconds now
> just for the downloads to fail, so my build can complete.

Did you try Jason's suggestion and change your repository update
policies?  You should be able to tell it not to check on every single
build.

-- 
Wendy

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

Re: Frustration with snapshot updates

[Quintin Beukes]

Firstly, -o won't work, because I have to re-enable it everytime a
build fails for a legitimate dependency.

Secondly, it's snapshots built from dev source code - I update via SVN
and build them to get the latest versions. So they're not available in
the remote repositories yet.

And it's definitely required dependencies. It's getting bad, because
as the project grows, they get more, and I wait about 40 seconds now
just for the downloads to fail, so my build can complete.

Quintin Beukes



On Fri, Oct 2, 2009 at 8:43 PM, Brian Fox  wrote:
> On Fri, Oct 2, 2009 at 3:54 AM, Quintin Beukes  wrote:
>> Hey,
>>
>> Whenever a project depends on a snapshot versioned library, then it
>> tries to update this snapshot. If the snapshot isn't found in any of
>> the repositories, then it obviously doesn't update. But now it tries
>> again with the next build. And over, and over, and over.
>
> I'll ask the obvious question first: Why do you have a dependency that
> doesn't exist? And if your build succeeds without this dependency, is
> it even a defacto dependency?
>
> -
> 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: Frustration with snapshot updates

[Brian Fox]

On Fri, Oct 2, 2009 at 3:54 AM, Quintin Beukes  wrote:
> Hey,
>
> Whenever a project depends on a snapshot versioned library, then it
> tries to update this snapshot. If the snapshot isn't found in any of
> the repositories, then it obviously doesn't update. But now it tries
> again with the next build. And over, and over, and over.

I'll ask the obvious question first: Why do you have a dependency that
doesn't exist? And if your build succeeds without this dependency, is
it even a defacto dependency?

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

weird error

[Jan]

Any one has any idea on below error, weird thing is same project works fine
if rerun it again, but the error keeps coming back, if i run this project
continuously


[INFO]

[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Error building POM (may not be this project's POM).


Project ID: unknown:maven-clean-plugin
POM Location: Artifact [org.apache.maven.plugins:maven-clean-plugin:pom:2.2]

Reason: Failed to interpolate field: public static final java.lang.String
org.apache.maven.model.PluginExecution.DEFAULT_EXECUTION_ID on class:
org.apac
he.maven.model.PluginExecution for project unknown:maven-clean-plugin at
Artifact [org.apache.maven.plugins:maven-clean-plugin:pom:2.2]


[INFO]

[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Unable to build
project for plugin 'org.apache.maven.plugins:maven-clean-plugin': Failed to
inte
rpolate field: public static final java.lang.String
org.apache.maven.model.PluginExecution.DEFAULT_EXECUTION_ID on class:
org.apache.maven.model.PluginE
xecution for project unknown:maven-clean-plugin at Artifact
[org.apache.maven.plugins:maven-clean-plugin:pom:2.2]
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1557)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1851)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:1275)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.InvalidPluginException: Unable to build
project for plugin 'org.apache.maven.plugins:maven-clean-plugin': Failed to
i
nterpolate field: public static final java.lang.String
org.apache.maven.model.PluginExecution.DEFAULT_EXECUTION_ID on class:
org.apache.maven.model.Plug
inExecution for project unknown:maven-clean-plugin at Artifact
[org.apache.maven.plugins:maven-clean-plugin:pom:2.2]
at
org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:293)
at
org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:205)
at
org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:184)
at
org.apache.maven.plugin.DefaultPluginManager.loadPluginDescriptor(DefaultPluginManager.java:1642)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1540)
... 19 more
Caused by: org.apache.maven.project.InvalidProjectModelException: Failed to
interpolate field: public static final java.lang.String org.apache.maven.mod
el.PluginExecution.DEFAULT_EXECUTION_ID on class:
org.apache.maven.model.PluginExecution for project
unknown:maven-clean-plugin at Artifact [org.apache.
maven.plugins:maven-clean-plugin:pom:2.2]
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:884)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:255)
at
org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:277)
... 23 more
Caused by:
org.apache.maven.project.int

Re: Frustration with snapshot updates

[Jason van Zyl]

On 2009-10-02, at 8:30 AM, Wayne Fay wrote:


Is there a way I can completely disable snapshot updates?


Would mvn -o (offline) work, or does that break your build for other  
reasons?




Or read up on repository policies.


Wayne

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



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
--


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

Activating/deactivating profile in parent/child

[droidin.net]

I want to rephrase my previous question (http://is.gd/3Sxiw) to make it more
generic and clear.

Is it possible to activate/deactivate profile in parent/child aggregated POM
individually? 

For example - if profile is defined in parent and reused by one or many
children (for code duplication sake) is it possible to execute this profile
in child(ren) only skipping execution on parent? I tried some suggestions
(http://is.gd/3Sxmb) including property-based and missing-file activation
but so far I can only enable/disable profile on the whole build.
-- 
View this message in context: 
http://www.nabble.com/Activating-deactivating-profile-in-parent-child-tp25716718p25716718.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: Frustration with snapshot updates

[Wayne Fay]

> Is there a way I can completely disable snapshot updates?

Would mvn -o (offline) work, or does that break your build for other reasons?

Wayne

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

RE: Using Maven in a large company - case studies requested

[Todd Thiessen]

We are moving to a larger Maven build as well. My project was one of the
first projects to move and now we are moving the larger build over and
we have some of the same concerns you do. We are aiming for a larger
agile continous integration build using snapshots and I believe it will
work.

We are using Bamboo as our continour integration server and I believe it
has the ability to do dependency builds. I am sure Hudson must have
something similar. For example if project A depends on B, then if B
builds, then A will build once B is done.

But if A also depends on C, D and E, but have not changed, then they are
not re-compiled. The larger overall build simply pulls in the latest
already built snapshot jars. Thus the overall build shouldn't take very
long.

We have a lot of mixed feelings as to which path to take as well (fixed
versions vs latest snapshots). I am in the latest snapshots camp myself
to foster a more agile development environment, but I do understand how
it can make some feel a bit uneasy. 

As for your first issue I think now that you have moved to maven it is
pointing out the jar hell that you had even when you were not using
maven. I am not really sure what you meant by "task-scheduling service"
but whether or not maven is involved, jar conflicts need to be resolved.
We went through a phase where maven helped us find many jar conflicts
which we were fortunate didn't cause any issues when using ant since the
higher overall build just pulled in the jars it thought it needed
without having any transitive knowledge of the inner projects. The old
ant build used newer jars that were backwards compatible with the older
jars that many of the inner projects were using. In many cases, jars
were simply not included in the final container (war/rpm) but this
wasn't a problem since non of these jars were needed at runtime. You
will notice that when you move to maven that the size of the final
container will likely be larger than what you had without it. Thats
because maven will ensure that it includes all transivitive jars in the
final container, even if you are not using all of this functionality at
runtime.

---
Todd Thiessen
 

> -Original Message-
> From: Mike Cripps [mailto:mike.cri...@taptu.com] 
> Sent: Friday, October 02, 2009 5:15 AM
> To: users@maven.apache.org
> Subject: Using Maven in a large company - case studies requested
> 
> Hi all,
> 
> My company has recently transitioned from custom ant scripts 
> to a fully mavenized build and release system, using Nexus 
> and Hudson to store and create artifacts. In general, the 
> move is working well. However, the 'old guard' in the company 
> have been slow to embrace Maven - worried as they are about 
> its effects on Continuous Integration and 'dependency 
> management hell'.
> 
> We're a medium sized company with about 35-40 components, the 
> majority of which are library code ('common' code etc) but 
> with about 10 actually 'deployed' services. What we have done 
> is encourage people to release their projects when they are 
> about to deploy them. Stable versions being re-creatable is a 
> good thing.
> 
> We've recently hit a snag with this though. Each project has 
> its own release schedule and maintainer, and some projects 
> are languishing on old versions of common libraries. Normally 
> this isn't a problem, as it doesn't affect individual service 
> deployment.
> 
> However, we have a task-scheduling service that runs tasks 
> generated by other deployed projects - and this is reporting 
> conflicts with 'common'
> versions as it needs to have everything in its classpath to 
> run said tasks - if two projects have a different version of 
> common this doesn't work.
> 
> Are we just 'doing it wrong' - should we fix the version of 
> common libraries in the task-runner pom?
> 
> This brings me onto the second 'desire' - continuous 
> integration. Some members of the team want all of our 
> projects to depend on the latest -SNAPSHOT version of its 
> (internal) dependencies - so that breaking changes to trunk 
> are picked up quickly in all projects. However, this has 
> major negative effects to Hudson as a change in a common code 
> library can keep the system busy for an hour rebuilding everything.
> 
> I'm in the keep-fixed-versions camp on this, but I can see 
> their point.
> Again, is this just an issue with the way we're using Maven? 
> We have a lot of inter-dependencies (which we're working on 
> reducing through refactoring and introducing API projects).
> 
> Obviously for external dependencies, Maven is great - the 
> only issues we're having is for internal ones.
> 
> So, I'd like to ask people with experience in using Maven in 
> larger corporate environments what they do. Especially:
> 
>How do you handle internal dependencies with a high degree 
> of connectedness?
> 
>How would you structure service-layer artifacts?
>
>How do you convince others that Maven is working for you, 
> not against you

Showing active profiles for children

[Yang, Gang CTR USA]

Hi,

I've defined profiles in the parent POM and it should have be inherited
by the children modules. However, when I execute the
help:active-profiles goal from the child module, it does not show the
child module having any active module as it would if I executed the same
goal from the parent. Is this a bug or there's a explanation?

Also I found that activation by properties did not seem to work for
profiles. I had the profiles to be activated by a property having a
certain value and then defined that property in  element.
That did not seem to activate the profile. Bug or I miss used?

Thanks,
Gang
PS: Thanks to Damon for earlier useful responses for my other post about
overlay. Did not want to waste email bandwidth just to send thanks.

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

[MEAR] FileNotFoundException while filtering EAR sources

[Arnaud Daroussin]

Hi,

Is it normal maven-ear-plugin (2.3.2) ends in exception if I try to 
filter a resource which is in another folder than src/main/application/ 
or src/main/application/META-INF/ ?
Maybe it's a voluntary restriction but the FileNotFoundException seems 
be a bug.


If resources are copied without filtering it's work fine.

Should I create an issue on this ?

Regards,
Arnaud.
*
*NOTA   
***
Veuillez noter le nouveau nom de domaine de l'Agence de Services et de Paiement 
(ASP) : @asp-public.fr
   (ceci ne concerne pas les comptes de messagerie des ADASEA.)
*
*
Ce message peut contenir des INFORMATIONS CONFIDENTIELLES destinées à l'usage exclusif du 
destinataire. Si vous le receviez par erreur, merci de bien vouloir nous en avertir immédiatement par téléphone 
ou messagerie,de le détruire et de n'en divulguer le contenu à personne.


This message may contain CONFIDENTIAL INFORMATION intended only for use by the addressee. If you 
have received it by mistake, thank you for notifying us immediately by telephone or by e-mail,and please, 
delete it and do not deliver it to anyone else.

*


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

AW: AW: How to add generated resources directory in a plugin

[Lewis, Eric]

Hi Werner

Yup, I had the same problem, but I'm generating my resources into 
target/generated-resources/xyz and then adding that to my build:

Resource resource = new Resource();
resource.setDirectory(targetDirectory.getAbsolutePath());
resource.addInclude("**/*");
if (createTestConfiguration) {
  mavenProject.addTestResource(resource);
} else {
  mavenProject.addResource(resource);
}

They will still end up in target/classes or target/test-classes.

Best regards,
Eric 

> -Ursprüngliche Nachricht-
> Von: Werner Guttmann [mailto:wgut...@codehaus.org] 
> Gesendet: Freitag, 2. Oktober 2009 13:46
> An: Maven Users List
> Betreff: Re: AW: How to add generated resources directory in a plugin
> 
> Eric,
> 
> the .castor.cdr files are a by-product of generating Java classes from
> an XML schema using the XML code generator of Castor (through 
> the Maven
> plugin for Castor).
> 
> Those resource files are being generated in
> target/generated-sources/castor during code generation.
> 
> I hopes this makes it clearer 
> 
> Werner
> 
> Lewis, Eric wrote:
> > Just out of curiosity: Is there a reason that you keep the 
> .cdr files in src/main/java?
> > IMHO you could have them in src/main/resources, since they 
> end up in target/classes anyway.
> > 
> > Best regards,
> > Eric 
> > 
> >> -Ursprüngliche Nachricht-
> >> Von: Werner Guttmann [mailto:wgut...@codehaus.org] 
> >> Gesendet: Freitag, 2. Oktober 2009 13:13
> >> An: Maven Users List
> >> Betreff: Re: How to add generated resources directory in a plugin
> >>
> >> That does not really match what I am observing .. :-(.
> >>
> >> If I generate Java sources and resources into
> >>
> >> target/generated-sources/castor
> >>
> >> and use
> >>
> >> project.addCompileSourceRoot("target/generated-sources/castor")
> >>
> >> within the Maven plugin for Castor, Maven will include the 
> generated
> >> Java classes during compilation and put the class files in
> >> target/classes of the project.
> >>
> >> As a result of this, users of the Maven plugin for Castor 
> >> currently have
> >> to add the following section to their project POMs.
> >>
> >> 
> >>
> >>   target/generated-sources/castor
> >>   
> >>  **/*.cdr
> >>   
> >>
> >>
> >>   src/main/resources
> >>
> >> 
> >>
> >> to have those .castor.cdr Files copied to target/classes as 
> >> well. As we
> >> all know, this is error-prone.
> >>
> >> As such, I tried to add code to the Maven plugin for Castor 
> >> as follows:
> >>
> >> Resource resource = new Resource();
> >> resource.setDirectory( 
> getResourceDestination().getAbsolutePath() );
> >> List includes = new LinkedList();
> >> includes.add( "**/*.cdr" );
> >> resource.setIncludes( includes );
> >> project.addResource( resource );
> >>
> >> Problem is that once I add that code, the Java source files start
> >> showing up in target/classes, which is not ideal.
> >>
> >> Any idea what's going wrong here ?
> >>
> >> Werner
> >>
> >> Roland Asmann wrote:
> >>> I believe this can work (not 100% sure, I generate into two 
> >> different 
> >>> directories for sources and resources), but you should 
> >> probably ONLY use the 
> >>> addCompileSourceRoot for your directory...
> >>>
> >>> The way I understand it, is that if you put sources & 
> >> resources there, they 
> >>> are compiled to the output dir. Java knows how to handle 
> >> .java-files --> 
> >>> convert them to classes, and how to handle anything else 
> >> --> just copy.
> >>> If you use the resource-dir, maven will handle the copying 
> >> and will copy 
> >>> everything from the source to the target, without compiling.
> >>>
> >>> So, I presume you have used both calls I gave you, although 
> >> you should only 
> >>> use one.
> >>>
> >>> Hope this helps,
> >>>
> >>>
> >>> On Thursday 01 October 2009 15:15, Werner Guttmann wrote:
>  Hi Roland,
> 
>  does this pattern/recipe change if both resources and Java 
> >> classes would
>  be generated in the same directory. I have tried this a 
> >> few days ago
>  (trying to automate a few things for the 
> >> castor-maven-plugin), and it
>  seems like this does not really work.
> 
>  Assume you have a directory where you'll find 
> 
>  - A.java
>  - B.java
>  - .castor.cdr
> 
>  where the last is a resource file. If I use above code 
> >> snippets, I can
>  see in the target folder after a plugin run and subsequent 
> >> compilation
>  the compiled Java classes, the resource file and the 
> source files.
> 
>  How can I avoid the source files to be copy across ?
> 
>  Regards
>  Werner
> 
>  Roland Asmann wrote:
> > Assuming you already have the maven-project as a variable 
> >> in your plugin
> > (if not, add it!):
> >
> > project.addCompileSourceRoot("your output directory here");
> >
> >
> > And in the case of resources:
> >
> > Resourc

Re: problem using archetype create-from-project to process files under resources folders.

[Milos Kleint]

check the sources of the generic nbm archetype at codehaus.
http://svn.codehaus.org/mojo/trunk/mojo/mojo-archetypes/nbm-archetype/

Milos

On Thu, Oct 1, 2009 at 5:03 PM, Djohannot  wrote:

>
> Hi all,
>
> I have exactly the same problem. I use the Netbeans platform and the
> layer.xml, Bundle.properties, etc are in resources folder, and the
> archetype:generate-from-project keep the original folder hierarchy.
>
> dou you have found a way to tell Maven to modif the resources folders too?
>
> regards,
>
> David J.
>
>
>
> Trent Rosenbaum-2 wrote:
> >
> > Hi there,
> > I am having a problem with the 'main/resources' and the 'test/resources'
> > folders when trying to generate an archetype from an example project.
> > Both
> > folders are preserving the original folder structures from the project
> > used
> > to generate the archetype.  The 'main/java' and the 'test/java' are
> > modified
> > to allow them to be placed into a new package structure when the
> archetype
> > is used for future projects.  Are the folders 'main/resources' and
> > 'test/resources' meant to work in this way?
> >
> > I would expect the 'resources' folders within the archetype to generate
> > the
> > new files in the same manner as the java folders.  I have a situation
> > where
> > junit test classes are locating Spring configuration files in the same
> > package.  I have the test class under the 'test/java' folder and the
> > configuration files under 'test/resources'.  When I run the
> > 'maven-archetype-plugin' over the example project, (a project that builds
> > and tests as expected) I get the java classes modified to except new
> > project
> > values, but the configuration files under resources folders are left
> under
> > the old package/folder structure.  After generation of the new project
> the
> > build fails because the tests cannot locate the appropriate configuration
> > files.  Is it expected that I should modify the generated archetype files
> > by
> > hand to place the configuration files in the correct location?  I have
> > been
> > using archetypes of a while, but have never noticed this before because I
> > always placed my configuration files at the route of 'main/resources' and
> > 'test/resources'.
> >
> > What are the plans for the archetype plugin going forward?  I get a sense
> > that things on the archetype front have gone quiet?
> >
> > Are there any other options and what is everyone else doing?  Any
> feedback
> > would be a great help.
> > Many thanks
> >
> > Trent
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/problem-using-archetype-create-from-project-to-process-files-under--resources-folders.-tp24772317p25696921.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: Add arbitrary dependency in assembly

[Wim Deblauwe]

2009/10/2 Antonio Petrelli 

> 2009/10/2 Wim Deblauwe :
> > I tried setting the scope to
> > 'provided' but then the assembly cannot find that zip file it seems.
>
> You have to add the "scope" element and set it to "provided" in the
> "dependencySet" element:
>
> http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_dependencySet
>
> > Is there some other way to have a nicer solution?
>
> I don't if it is "nicer", but a widely adopted solution is to create
> an "assembly project", so you can manage your assembly dependencies
> independently.
>
>
Setting the provided scope indeed does the trick. Thank you! For me, this
solution is nice enough :)



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

Re: How to add generated resources directory in a plugin

[Roland Asmann]

Read the part about editing the plugin again... If you're working on the 
actual castor-plugin, wouldn't it be easier to just separate the sources and 
resources instead of adding the resources with inclusion/exclusion rules?


On Friday 02 October 2009 13:45, Werner Guttmann wrote:
> Eric,
>
> the .castor.cdr files are a by-product of generating Java classes from
> an XML schema using the XML code generator of Castor (through the Maven
> plugin for Castor).
>
> Those resource files are being generated in
> target/generated-sources/castor during code generation.
>
> I hopes this makes it clearer 
>
> Werner
>
> Lewis, Eric wrote:
> > Just out of curiosity: Is there a reason that you keep the .cdr files in
> > src/main/java? IMHO you could have them in src/main/resources, since they
> > end up in target/classes anyway.
> >
> > Best regards,
> > Eric
> >
> >> -Ursprüngliche Nachricht-
> >> Von: Werner Guttmann [mailto:wgut...@codehaus.org]
> >> Gesendet: Freitag, 2. Oktober 2009 13:13
> >> An: Maven Users List
> >> Betreff: Re: How to add generated resources directory in a plugin
> >>
> >> That does not really match what I am observing .. :-(.
> >>
> >> If I generate Java sources and resources into
> >>
> >> target/generated-sources/castor
> >>
> >> and use
> >>
> >> project.addCompileSourceRoot("target/generated-sources/castor")
> >>
> >> within the Maven plugin for Castor, Maven will include the generated
> >> Java classes during compilation and put the class files in
> >> target/classes of the project.
> >>
> >> As a result of this, users of the Maven plugin for Castor
> >> currently have
> >> to add the following section to their project POMs.
> >>
> >> 
> >>
> >>   target/generated-sources/castor
> >>   
> >>  **/*.cdr
> >>   
> >>
> >>
> >>   src/main/resources
> >>
> >> 
> >>
> >> to have those .castor.cdr Files copied to target/classes as
> >> well. As we
> >> all know, this is error-prone.
> >>
> >> As such, I tried to add code to the Maven plugin for Castor
> >> as follows:
> >>
> >> Resource resource = new Resource();
> >> resource.setDirectory( getResourceDestination().getAbsolutePath() );
> >> List includes = new LinkedList();
> >> includes.add( "**/*.cdr" );
> >> resource.setIncludes( includes );
> >> project.addResource( resource );
> >>
> >> Problem is that once I add that code, the Java source files start
> >> showing up in target/classes, which is not ideal.
> >>
> >> Any idea what's going wrong here ?
> >>
> >> Werner
> >>
> >> Roland Asmann wrote:
> >>> I believe this can work (not 100% sure, I generate into two
> >>
> >> different
> >>
> >>> directories for sources and resources), but you should
> >>
> >> probably ONLY use the
> >>
> >>> addCompileSourceRoot for your directory...
> >>>
> >>> The way I understand it, is that if you put sources &
> >>
> >> resources there, they
> >>
> >>> are compiled to the output dir. Java knows how to handle
> >>
> >> .java-files -->
> >>
> >>> convert them to classes, and how to handle anything else
> >>
> >> --> just copy.
> >>
> >>> If you use the resource-dir, maven will handle the copying
> >>
> >> and will copy
> >>
> >>> everything from the source to the target, without compiling.
> >>>
> >>> So, I presume you have used both calls I gave you, although
> >>
> >> you should only
> >>
> >>> use one.
> >>>
> >>> Hope this helps,
> >>>
> >>> On Thursday 01 October 2009 15:15, Werner Guttmann wrote:
>  Hi Roland,
> 
>  does this pattern/recipe change if both resources and Java
> >>
> >> classes would
> >>
>  be generated in the same directory. I have tried this a
> >>
> >> few days ago
> >>
>  (trying to automate a few things for the
> >>
> >> castor-maven-plugin), and it
> >>
>  seems like this does not really work.
> 
>  Assume you have a directory where you'll find 
> 
>  - A.java
>  - B.java
>  - .castor.cdr
> 
>  where the last is a resource file. If I use above code
> >>
> >> snippets, I can
> >>
>  see in the target folder after a plugin run and subsequent
> >>
> >> compilation
> >>
>  the compiled Java classes, the resource file and the source files.
> 
>  How can I avoid the source files to be copy across ?
> 
>  Regards
>  Werner
> 
>  Roland Asmann wrote:
> > Assuming you already have the maven-project as a variable
> >>
> >> in your plugin
> >>
> > (if not, add it!):
> >
> > project.addCompileSourceRoot("your output directory here");
> >
> >
> > And in the case of resources:
> >
> > Resource resource = new Resource();
> > resource.setDirectory("your output directory here");
> > resource.addInclude("**/*");
> > project.addResource(resource);
> >
> > On Thursday 01 October 2009 13:59, Lewis, Eric wrote:
> >> Hi
> >>
> >> I'm writing a plugin which generates resources and also
> >>
> >> test resources.
> >>
> >> How in my plugi

Re: M2 : cvsignore and archetypes

[Roland Asmann]

OK, so I checked. We are indeed using our own archetype-plugin. It can resolve 
files that have variables in the name.

This way we can include several 'system'-files (like for CVS) and other files 
that are always needed, but have different names/packages depending on our 
project. Think along the lines of using the groupId as the package-name for 
java-classes.

So, I suggest you look into writing your own archetype-plugin or find one that 
can do similar things as our plugin.


On Friday 02 October 2009 11:21, you wrote:
> We are doing something similar in our company, although I curently can't
> tell you the exact solution (not at work yet).
> I believe we are using some renaming-scheme like calling those files
> '${DOT}cvsignore'  and then have the archetype replace the variable 'DOT'
> with '.'.
>
> As I said, I'm not 100% sure if this is our exact solution and if it works
> out of the box or if we implemented our own archetype-plugin. You could
> try this and I will get back at you when I'm at work to check this.
>
> Roland
>
> > Hi,
> >
> > We are stuck on using archetype on a complex multiproject template we
> > would like to give to our developpers. We need to automatize the artefact
> > publication for obvious reasons, but , it's not possible to add
> > .cvsignore files on archetypes using the archetype:create-from-project
> > goal.
> >
> > It is important for those files to be present prior to the developper
> > first projet commit, otherwise it's a pain to correct afteward.
> >
> > Our workaround for the moment is to use the assembly plugin to generete a
> > ZIP file of the template projet, then the developper will do a global
> > "search and replace" of the groupID,artifactID and version in the poms.
> >
> > As another option I would think of another plugin to take over the job on
> > creating those files, like the maven-eclipse-plugin...
> >
> > Is there anyone here with a similar issue ?
> >
> > Thanks.
> >
> > antonio
> >
> > -Message d'origine-
> > De : Nick Stolwijk [mailto:nick.stolw...@gmail.com]
> > Envoyé : jeudi, 1. octobre 2009 19:32
> > À : PAROLINI Antonio; Maven Users List
> > Objet : Re: Ant to Maven
> >
> > See also this link:
> > http://maven.apache.org/guides/introduction/introduction-to-the-pom.html
> >
> > Nick Stolwijk
> > ~Java Developer~
> >
> > IPROFS BV.
> > Claus Sluterweg 125
> > 2012 WS Haarlem
> > http://www.iprofs.nl
> >
> >
> >
> > On Thu, Oct 1, 2009 at 7:28 PM, Nick Stolwijk 
> >
> > wrote:
> >> From each module there will be one main artifact, ie a jar. Sometimes
> >> there can be multiple artifacts, like javadoc or sources. If you say
> >> that your ant script generates multiple jars, you will need to have
> >> multiple modules. That can be child-parent relation, or just a
> >> aggregator pom.
> >>
> >> Child parent relation:
> >> Each module has a section  which point to a pom with shared
> >> configuration and/or dependency(management).
> >>
> >> Aggregator pom:
> >> You have multiple modules in subdirectories. You create a pom file
> >> with the modules tag to kick of all the builds with one command.
> >>
> >> These strategies can be combined. Your parent pom can also be your
> >> aggregator pom.
> >>
> >> Hth,
> >>
> >> Nick Stolwijk
> >> ~Java Developer~
> >>
> >> IPROFS BV.
> >> Claus Sluterweg 125
> >> 2012 WS Haarlem
> >> http://www.iprofs.nl
> >>
> >>
> >>
> >> On Thu, Oct 1, 2009 at 7:14 PM, chicagopooldude
> >>
> >>  wrote:
> >>> Thanks for your reply I have already started to use the antrun plugin.
> >>> I
> >>> wanted to know if you can please share some documentation on using
> >>> seperate
> >>> modules. Should I use parent-child modules ?
> >>> --
> >>> View this message in context:
> >>> http://www.nabble.com/Ant-to-Maven-tp25696939p25703038.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
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org

-- 
Roland Asmann

CFC Informationssysteme Entwicklungsgesellschaft m.b.H
Bäckerstrasse 1/2/7
A-1010 Wien
FN 266155f, Handelsgericht Wien

Tel.: +43/1/513 88 77 - 27
Fax.: +43/1/513 88 62
Email: roland.asm...@cfc.at
Web: www.cfc.at

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

Re: AW: How to add generated resources directory in a plugin

[Werner Guttmann]

Eric,

the .castor.cdr files are a by-product of generating Java classes from
an XML schema using the XML code generator of Castor (through the Maven
plugin for Castor).

Those resource files are being generated in
target/generated-sources/castor during code generation.

I hopes this makes it clearer 

Werner

Lewis, Eric wrote:
> Just out of curiosity: Is there a reason that you keep the .cdr files in 
> src/main/java?
> IMHO you could have them in src/main/resources, since they end up in 
> target/classes anyway.
> 
> Best regards,
> Eric 
> 
>> -Ursprüngliche Nachricht-
>> Von: Werner Guttmann [mailto:wgut...@codehaus.org] 
>> Gesendet: Freitag, 2. Oktober 2009 13:13
>> An: Maven Users List
>> Betreff: Re: How to add generated resources directory in a plugin
>>
>> That does not really match what I am observing .. :-(.
>>
>> If I generate Java sources and resources into
>>
>> target/generated-sources/castor
>>
>> and use
>>
>> project.addCompileSourceRoot("target/generated-sources/castor")
>>
>> within the Maven plugin for Castor, Maven will include the generated
>> Java classes during compilation and put the class files in
>> target/classes of the project.
>>
>> As a result of this, users of the Maven plugin for Castor 
>> currently have
>> to add the following section to their project POMs.
>>
>> 
>>
>>   target/generated-sources/castor
>>   
>>  **/*.cdr
>>   
>>
>>
>>   src/main/resources
>>
>> 
>>
>> to have those .castor.cdr Files copied to target/classes as 
>> well. As we
>> all know, this is error-prone.
>>
>> As such, I tried to add code to the Maven plugin for Castor 
>> as follows:
>>
>> Resource resource = new Resource();
>> resource.setDirectory( getResourceDestination().getAbsolutePath() );
>> List includes = new LinkedList();
>> includes.add( "**/*.cdr" );
>> resource.setIncludes( includes );
>> project.addResource( resource );
>>
>> Problem is that once I add that code, the Java source files start
>> showing up in target/classes, which is not ideal.
>>
>> Any idea what's going wrong here ?
>>
>> Werner
>>
>> Roland Asmann wrote:
>>> I believe this can work (not 100% sure, I generate into two 
>> different 
>>> directories for sources and resources), but you should 
>> probably ONLY use the 
>>> addCompileSourceRoot for your directory...
>>>
>>> The way I understand it, is that if you put sources & 
>> resources there, they 
>>> are compiled to the output dir. Java knows how to handle 
>> .java-files --> 
>>> convert them to classes, and how to handle anything else 
>> --> just copy.
>>> If you use the resource-dir, maven will handle the copying 
>> and will copy 
>>> everything from the source to the target, without compiling.
>>>
>>> So, I presume you have used both calls I gave you, although 
>> you should only 
>>> use one.
>>>
>>> Hope this helps,
>>>
>>>
>>> On Thursday 01 October 2009 15:15, Werner Guttmann wrote:
 Hi Roland,

 does this pattern/recipe change if both resources and Java 
>> classes would
 be generated in the same directory. I have tried this a 
>> few days ago
 (trying to automate a few things for the 
>> castor-maven-plugin), and it
 seems like this does not really work.

 Assume you have a directory where you'll find 

 - A.java
 - B.java
 - .castor.cdr

 where the last is a resource file. If I use above code 
>> snippets, I can
 see in the target folder after a plugin run and subsequent 
>> compilation
 the compiled Java classes, the resource file and the source files.

 How can I avoid the source files to be copy across ?

 Regards
 Werner

 Roland Asmann wrote:
> Assuming you already have the maven-project as a variable 
>> in your plugin
> (if not, add it!):
>
> project.addCompileSourceRoot("your output directory here");
>
>
> And in the case of resources:
>
> Resource resource = new Resource();
> resource.setDirectory("your output directory here");
> resource.addInclude("**/*");
> project.addResource(resource);
>
> On Thursday 01 October 2009 13:59, Lewis, Eric wrote:
>> Hi
>>
>> I'm writing a plugin which generates resources and also 
>> test resources.
>> How in my plugin can I add these directories to the 
>> sources paths and
>> the test resources paths? (Except for using the 
>> build-helper plugin)
>> Best regards,
>> Eric
>>
>>
>> -
>> 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 unsubscri

Re: How to add generated resources directory in a plugin

[Roland Asmann]

Ouch... But like I said: I wasn't sure if it would work. We generate our 
sources and resources in separate folders.

OK, so it doesn't work this way... Maybe it is better to use your solution and 
add the source-folder to the resources. Either use the include, or (probably 
easier) the excludes (**/*.java). That should do the trick.


On Friday 02 October 2009 13:12, Werner Guttmann wrote:
> That does not really match what I am observing .. :-(.
>
> If I generate Java sources and resources into
>
> target/generated-sources/castor
>
> and use
>
> project.addCompileSourceRoot("target/generated-sources/castor")
>
> within the Maven plugin for Castor, Maven will include the generated
> Java classes during compilation and put the class files in
> target/classes of the project.
>
> As a result of this, users of the Maven plugin for Castor currently have
> to add the following section to their project POMs.
>
> 
>
>   target/generated-sources/castor
>   
>  **/*.cdr
>   
>
>
>   src/main/resources
>
> 
>
> to have those .castor.cdr Files copied to target/classes as well. As we
> all know, this is error-prone.
>
> As such, I tried to add code to the Maven plugin for Castor as follows:
>
> Resource resource = new Resource();
> resource.setDirectory( getResourceDestination().getAbsolutePath() );
> List includes = new LinkedList();
> includes.add( "**/*.cdr" );
> resource.setIncludes( includes );
> project.addResource( resource );
>
> Problem is that once I add that code, the Java source files start
> showing up in target/classes, which is not ideal.
>
> Any idea what's going wrong here ?
>
> Werner
>
> Roland Asmann wrote:
> > I believe this can work (not 100% sure, I generate into two different
> > directories for sources and resources), but you should probably ONLY use
> > the addCompileSourceRoot for your directory...
> >
> > The way I understand it, is that if you put sources & resources there,
> > they are compiled to the output dir. Java knows how to handle .java-files
> > --> convert them to classes, and how to handle anything else --> just
> > copy. If you use the resource-dir, maven will handle the copying and will
> > copy everything from the source to the target, without compiling.
> >
> > So, I presume you have used both calls I gave you, although you should
> > only use one.
> >
> > Hope this helps,
> >
> > On Thursday 01 October 2009 15:15, Werner Guttmann wrote:
> >> Hi Roland,
> >>
> >> does this pattern/recipe change if both resources and Java classes would
> >> be generated in the same directory. I have tried this a few days ago
> >> (trying to automate a few things for the castor-maven-plugin), and it
> >> seems like this does not really work.
> >>
> >> Assume you have a directory where you'll find 
> >>
> >> - A.java
> >> - B.java
> >> - .castor.cdr
> >>
> >> where the last is a resource file. If I use above code snippets, I can
> >> see in the target folder after a plugin run and subsequent compilation
> >> the compiled Java classes, the resource file and the source files.
> >>
> >> How can I avoid the source files to be copy across ?
> >>
> >> Regards
> >> Werner
> >>
> >> Roland Asmann wrote:
> >>> Assuming you already have the maven-project as a variable in your
> >>> plugin (if not, add it!):
> >>>
> >>> project.addCompileSourceRoot("your output directory here");
> >>>
> >>>
> >>> And in the case of resources:
> >>>
> >>> Resource resource = new Resource();
> >>> resource.setDirectory("your output directory here");
> >>> resource.addInclude("**/*");
> >>> project.addResource(resource);
> >>>
> >>> On Thursday 01 October 2009 13:59, Lewis, Eric wrote:
>  Hi
> 
>  I'm writing a plugin which generates resources and also test
>  resources. How in my plugin can I add these directories to the sources
>  paths and the test resources paths? (Except for using the build-helper
>  plugin)
> 
>  Best regards,
>  Eric
> 
>  -
>  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

-- 
Roland Asmann

CFC Informationssysteme Entwicklungsgesellschaft m.b.H
Bäckerstrasse 1/2/7
A-1010 Wien
FN 266155f, Handelsgericht Wien

Tel.: +43/1/513 88 77 - 27
Fax.: +43/1/513 88 62
Email: roland.asm...@cfc.at
Web: www.cfc.at

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

Re: maven-archetype-plugin and package parameter

[Stevo Slavić]

A-ha,  "Filesets can be packaged, which means the selected files will be
generated/copied in a directory structure that is prepended by the package
property. They can be non-packaged, which means that the selected files will
be generated/copied without that prepend.", **  from archetype plugin
docs
.

Regards,
Stevo.

On Fri, Oct 2, 2009 at 12:52 PM, Stevo Slavić  wrote:

> Just found out, if XML schema for archetype-metadata.xml attached to this
> maven-archetype-plugin issueis 
> correct, fileSet in archetype-metadata.xml doesn't support
> outputDirectory at all. How is one then supposed to alter package/directory
> names originating from the archetype resources using package parameter?
>
> Regards,
> Stevo.
>
>
> On Fri, Oct 2, 2009 at 12:36 PM, Stevo Slavić  wrote:
>
>> Hello Maven users,
>>
>> Is it possible to reference archetype parameters in
>> archetype-metadata.xml? E.g. I'd like to reference package parameter and use
>> it in outputDirectory of a fileSet.
>>
>> Regards,
>> Stevo.
>>
>
>

AW: How to add generated resources directory in a plugin

[Lewis, Eric]

Just out of curiosity: Is there a reason that you keep the .cdr files in 
src/main/java?
IMHO you could have them in src/main/resources, since they end up in 
target/classes anyway.

Best regards,
Eric 

> -Ursprüngliche Nachricht-
> Von: Werner Guttmann [mailto:wgut...@codehaus.org] 
> Gesendet: Freitag, 2. Oktober 2009 13:13
> An: Maven Users List
> Betreff: Re: How to add generated resources directory in a plugin
> 
> That does not really match what I am observing .. :-(.
> 
> If I generate Java sources and resources into
> 
> target/generated-sources/castor
> 
> and use
> 
> project.addCompileSourceRoot("target/generated-sources/castor")
> 
> within the Maven plugin for Castor, Maven will include the generated
> Java classes during compilation and put the class files in
> target/classes of the project.
> 
> As a result of this, users of the Maven plugin for Castor 
> currently have
> to add the following section to their project POMs.
> 
> 
>
>   target/generated-sources/castor
>   
>  **/*.cdr
>   
>
>
>   src/main/resources
>
> 
> 
> to have those .castor.cdr Files copied to target/classes as 
> well. As we
> all know, this is error-prone.
> 
> As such, I tried to add code to the Maven plugin for Castor 
> as follows:
> 
> Resource resource = new Resource();
> resource.setDirectory( getResourceDestination().getAbsolutePath() );
> List includes = new LinkedList();
> includes.add( "**/*.cdr" );
> resource.setIncludes( includes );
> project.addResource( resource );
> 
> Problem is that once I add that code, the Java source files start
> showing up in target/classes, which is not ideal.
> 
> Any idea what's going wrong here ?
> 
> Werner
> 
> Roland Asmann wrote:
> > I believe this can work (not 100% sure, I generate into two 
> different 
> > directories for sources and resources), but you should 
> probably ONLY use the 
> > addCompileSourceRoot for your directory...
> > 
> > The way I understand it, is that if you put sources & 
> resources there, they 
> > are compiled to the output dir. Java knows how to handle 
> .java-files --> 
> > convert them to classes, and how to handle anything else 
> --> just copy.
> > If you use the resource-dir, maven will handle the copying 
> and will copy 
> > everything from the source to the target, without compiling.
> > 
> > So, I presume you have used both calls I gave you, although 
> you should only 
> > use one.
> > 
> > Hope this helps,
> > 
> > 
> > On Thursday 01 October 2009 15:15, Werner Guttmann wrote:
> >> Hi Roland,
> >>
> >> does this pattern/recipe change if both resources and Java 
> classes would
> >> be generated in the same directory. I have tried this a 
> few days ago
> >> (trying to automate a few things for the 
> castor-maven-plugin), and it
> >> seems like this does not really work.
> >>
> >> Assume you have a directory where you'll find 
> >>
> >> - A.java
> >> - B.java
> >> - .castor.cdr
> >>
> >> where the last is a resource file. If I use above code 
> snippets, I can
> >> see in the target folder after a plugin run and subsequent 
> compilation
> >> the compiled Java classes, the resource file and the source files.
> >>
> >> How can I avoid the source files to be copy across ?
> >>
> >> Regards
> >> Werner
> >>
> >> Roland Asmann wrote:
> >>> Assuming you already have the maven-project as a variable 
> in your plugin
> >>> (if not, add it!):
> >>>
> >>> project.addCompileSourceRoot("your output directory here");
> >>>
> >>>
> >>> And in the case of resources:
> >>>
> >>> Resource resource = new Resource();
> >>> resource.setDirectory("your output directory here");
> >>> resource.addInclude("**/*");
> >>> project.addResource(resource);
> >>>
> >>> On Thursday 01 October 2009 13:59, Lewis, Eric wrote:
>  Hi
> 
>  I'm writing a plugin which generates resources and also 
> test resources.
>  How in my plugin can I add these directories to the 
> sources paths and
>  the test resources paths? (Except for using the 
> build-helper plugin)
> 
>  Best regards,
>  Eric
> 
>  
> -
>  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>  For additional commands, e-mail: users-h...@maven.apache.org
> >> 
> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> > 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: How to add generated resources directory in a plugin

[Werner Guttmann]

That does not really match what I am observing .. :-(.

If I generate Java sources and resources into

target/generated-sources/castor

and use

project.addCompileSourceRoot("target/generated-sources/castor")

within the Maven plugin for Castor, Maven will include the generated
Java classes during compilation and put the class files in
target/classes of the project.

As a result of this, users of the Maven plugin for Castor currently have
to add the following section to their project POMs.


   
  target/generated-sources/castor
  
 **/*.cdr
  
   
   
  src/main/resources
   


to have those .castor.cdr Files copied to target/classes as well. As we
all know, this is error-prone.

As such, I tried to add code to the Maven plugin for Castor as follows:

Resource resource = new Resource();
resource.setDirectory( getResourceDestination().getAbsolutePath() );
List includes = new LinkedList();
includes.add( "**/*.cdr" );
resource.setIncludes( includes );
project.addResource( resource );

Problem is that once I add that code, the Java source files start
showing up in target/classes, which is not ideal.

Any idea what's going wrong here ?

Werner

Roland Asmann wrote:
> I believe this can work (not 100% sure, I generate into two different 
> directories for sources and resources), but you should probably ONLY use the 
> addCompileSourceRoot for your directory...
> 
> The way I understand it, is that if you put sources & resources there, they 
> are compiled to the output dir. Java knows how to handle .java-files --> 
> convert them to classes, and how to handle anything else --> just copy.
> If you use the resource-dir, maven will handle the copying and will copy 
> everything from the source to the target, without compiling.
> 
> So, I presume you have used both calls I gave you, although you should only 
> use one.
> 
> Hope this helps,
> 
> 
> On Thursday 01 October 2009 15:15, Werner Guttmann wrote:
>> Hi Roland,
>>
>> does this pattern/recipe change if both resources and Java classes would
>> be generated in the same directory. I have tried this a few days ago
>> (trying to automate a few things for the castor-maven-plugin), and it
>> seems like this does not really work.
>>
>> Assume you have a directory where you'll find 
>>
>> - A.java
>> - B.java
>> - .castor.cdr
>>
>> where the last is a resource file. If I use above code snippets, I can
>> see in the target folder after a plugin run and subsequent compilation
>> the compiled Java classes, the resource file and the source files.
>>
>> How can I avoid the source files to be copy across ?
>>
>> Regards
>> Werner
>>
>> Roland Asmann wrote:
>>> Assuming you already have the maven-project as a variable in your plugin
>>> (if not, add it!):
>>>
>>> project.addCompileSourceRoot("your output directory here");
>>>
>>>
>>> And in the case of resources:
>>>
>>> Resource resource = new Resource();
>>> resource.setDirectory("your output directory here");
>>> resource.addInclude("**/*");
>>> project.addResource(resource);
>>>
>>> On Thursday 01 October 2009 13:59, Lewis, Eric wrote:
 Hi

 I'm writing a plugin which generates resources and also test resources.
 How in my plugin can I add these directories to the sources paths and
 the test resources paths? (Except for using the build-helper plugin)

 Best regards,
 Eric

 -
 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

Frustration with snapshot updates

[Quintin Beukes]

Hey,

Whenever a project depends on a snapshot versioned library, then it
tries to update this snapshot. If the snapshot isn't found in any of
the repositories, then it obviously doesn't update. But now it tries
again with the next build. And over, and over, and over. This is
severly slowing down my builds, and can get very frustrating when
trying to hunt problems which require many rebuilds.

Is there a way I can completely disable snapshot updates?

Quintin Beukes

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

Re: maven-archetype-plugin and package parameter

[Stevo Slavić]

Just found out, if XML schema for archetype-metadata.xml attached to this
maven-archetype-plugin issue
is correct, fileSet in
archetype-metadata.xml doesn't support
outputDirectory at all. How is one then supposed to alter package/directory
names originating from the archetype resources using package parameter?

Regards,
Stevo.

On Fri, Oct 2, 2009 at 12:36 PM, Stevo Slavić  wrote:

> Hello Maven users,
>
> Is it possible to reference archetype parameters in archetype-metadata.xml?
> E.g. I'd like to reference package parameter and use it in outputDirectory
> of a fileSet.
>
> Regards,
> Stevo.
>

maven-archetype-plugin and package parameter

[Stevo Slavić]

Hello Maven users,

Is it possible to reference archetype parameters in archetype-metadata.xml?
E.g. I'd like to reference package parameter and use it in outputDirectory
of a fileSet.

Regards,
Stevo.

Re: M2 : cvsignore and archetypes

[Roland Asmann]

We are doing something similar in our company, although I curently can't
tell you the exact solution (not at work yet).
I believe we are using some renaming-scheme like calling those files
'${DOT}cvsignore'  and then have the archetype replace the variable 'DOT'
with '.'.

As I said, I'm not 100% sure if this is our exact solution and if it works
out of the box or if we implemented our own archetype-plugin. You could
try this and I will get back at you when I'm at work to check this.

Roland


> Hi,
>
> We are stuck on using archetype on a complex multiproject template we
> would like to give to our developpers. We need to automatize the artefact
> publication for obvious reasons, but , it's not possible to add .cvsignore
> files on archetypes using the archetype:create-from-project goal.
>
> It is important for those files to be present prior to the developper
> first projet commit, otherwise it's a pain to correct afteward.
>
> Our workaround for the moment is to use the assembly plugin to generete a
> ZIP file of the template projet, then the developper will do a global
> "search and replace" of the groupID,artifactID and version in the poms.
>
> As another option I would think of another plugin to take over the job on
> creating those files, like the maven-eclipse-plugin...
>
> Is there anyone here with a similar issue ?
>
> Thanks.
>
> antonio
>
> -Message d'origine-
> De : Nick Stolwijk [mailto:nick.stolw...@gmail.com]
> Envoyé : jeudi, 1. octobre 2009 19:32
> À : PAROLINI Antonio; Maven Users List
> Objet : Re: Ant to Maven
>
> See also this link:
> http://maven.apache.org/guides/introduction/introduction-to-the-pom.html
>
> Nick Stolwijk
> ~Java Developer~
>
> IPROFS BV.
> Claus Sluterweg 125
> 2012 WS Haarlem
> http://www.iprofs.nl
>
>
>
> On Thu, Oct 1, 2009 at 7:28 PM, Nick Stolwijk 
> wrote:
>> From each module there will be one main artifact, ie a jar. Sometimes
>> there can be multiple artifacts, like javadoc or sources. If you say
>> that your ant script generates multiple jars, you will need to have
>> multiple modules. That can be child-parent relation, or just a
>> aggregator pom.
>>
>> Child parent relation:
>> Each module has a section  which point to a pom with shared
>> configuration and/or dependency(management).
>>
>> Aggregator pom:
>> You have multiple modules in subdirectories. You create a pom file
>> with the modules tag to kick of all the builds with one command.
>>
>> These strategies can be combined. Your parent pom can also be your
>> aggregator pom.
>>
>> Hth,
>>
>> Nick Stolwijk
>> ~Java Developer~
>>
>> IPROFS BV.
>> Claus Sluterweg 125
>> 2012 WS Haarlem
>> http://www.iprofs.nl
>>
>>
>>
>> On Thu, Oct 1, 2009 at 7:14 PM, chicagopooldude
>>  wrote:
>>>
>>> Thanks for your reply I have already started to use the antrun plugin.
>>> I
>>> wanted to know if you can please share some documentation on using
>>> seperate
>>> modules. Should I use parent-child modules ?
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Ant-to-Maven-tp25696939p25703038.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
>>>
>>>
>>
>
> -
> 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

Using Maven in a large company - case studies requested

[Mike Cripps]

Hi all,

My company has recently transitioned from custom ant scripts to a fully
mavenized build and release system, using Nexus and Hudson to store and
create artifacts. In general, the move is working well. However, the
'old guard' in the company have been slow to embrace Maven - worried as
they are about its effects on Continuous Integration and 'dependency
management hell'.

We're a medium sized company with about 35-40 components, the majority
of which are library code ('common' code etc) but with about 10 actually
'deployed' services. What we have done is encourage people to release
their projects when they are about to deploy them. Stable versions being
re-creatable is a good thing.

We've recently hit a snag with this though. Each project has its own
release schedule and maintainer, and some projects are languishing on
old versions of common libraries. Normally this isn't a problem, as it
doesn't affect individual service deployment.

However, we have a task-scheduling service that runs tasks generated by
other deployed projects - and this is reporting conflicts with 'common'
versions as it needs to have everything in its classpath to run said
tasks - if two projects have a different version of common this doesn't
work.

Are we just 'doing it wrong' - should we fix the version of common
libraries in the task-runner pom?

This brings me onto the second 'desire' - continuous integration. Some
members of the team want all of our projects to depend on the latest
-SNAPSHOT version of its (internal) dependencies - so that breaking
changes to trunk are picked up quickly in all projects. However, this
has major negative effects to Hudson as a change in a common code
library can keep the system busy for an hour rebuilding everything.

I'm in the keep-fixed-versions camp on this, but I can see their point.
Again, is this just an issue with the way we're using Maven? We have a
lot of inter-dependencies (which we're working on reducing through
refactoring and introducing API projects).

Obviously for external dependencies, Maven is great - the only issues
we're having is for internal ones.

So, I'd like to ask people with experience in using Maven in larger
corporate environments what they do. Especially:

   How do you handle internal dependencies with a high degree of
connectedness?

   How would you structure service-layer artifacts?
   
   How do you convince others that Maven is working for you, not against
you?

Apologies for length, many thanks for the great product.
Mike Cripps


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

Re: Add arbitrary dependency in assembly

[Antonio Petrelli]

2009/10/2 Wim Deblauwe :
> I tried setting the scope to
> 'provided' but then the assembly cannot find that zip file it seems.

You have to add the "scope" element and set it to "provided" in the
"dependencySet" element:
http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_dependencySet

> Is there some other way to have a nicer solution?

I don't if it is "nicer", but a widely adopted solution is to create
an "assembly project", so you can manage your assembly dependencies
independently.

Antonio

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

Add arbitrary dependency in assembly

[Wim Deblauwe]

Hi,

How do you add an arbitrary dependency in an assembly descriptor?

I have a maven project that builds a war file. I want to assemble this war
file together with a zip file. I have this zip file in my repository. I
currently have added the zip file as a dependency in my pom.xml and added a
 element to include this zip file (with unpack to true) and
also an element for the war (with unpack to false).

This works fine, but the zip is not a dependency of the war itself, so I
don't like that I had to add it in my pom.xml. I tried setting the scope to
'provided' but then the assembly cannot find that zip file it seems.

Is there some other way to have a nicer solution?

regards,

Wim

M2 : cvsignore and archetypes

[PAROLINI Antonio]

Hi,

We are stuck on using archetype on a complex multiproject template we would 
like to give to our developpers. We need to automatize the artefact publication 
for obvious reasons, but , it's not possible to add .cvsignore files on 
archetypes using the archetype:create-from-project goal.

It is important for those files to be present prior to the developper first 
projet commit, otherwise it's a pain to correct afteward.

Our workaround for the moment is to use the assembly plugin to generete a ZIP 
file of the template projet, then the developper will do a global "search and 
replace" of the groupID,artifactID and version in the poms.

As another option I would think of another plugin to take over the job on 
creating those files, like the maven-eclipse-plugin...

Is there anyone here with a similar issue ?

Thanks.

antonio

-Message d'origine-
De : Nick Stolwijk [mailto:nick.stolw...@gmail.com] 
Envoyé : jeudi, 1. octobre 2009 19:32
À : PAROLINI Antonio; Maven Users List
Objet : Re: Ant to Maven

See also this link:
http://maven.apache.org/guides/introduction/introduction-to-the-pom.html

Nick Stolwijk
~Java Developer~

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



On Thu, Oct 1, 2009 at 7:28 PM, Nick Stolwijk  wrote:
> From each module there will be one main artifact, ie a jar. Sometimes
> there can be multiple artifacts, like javadoc or sources. If you say
> that your ant script generates multiple jars, you will need to have
> multiple modules. That can be child-parent relation, or just a
> aggregator pom.
>
> Child parent relation:
> Each module has a section  which point to a pom with shared
> configuration and/or dependency(management).
>
> Aggregator pom:
> You have multiple modules in subdirectories. You create a pom file
> with the modules tag to kick of all the builds with one command.
>
> These strategies can be combined. Your parent pom can also be your
> aggregator pom.
>
> Hth,
>
> Nick Stolwijk
> ~Java Developer~
>
> IPROFS BV.
> Claus Sluterweg 125
> 2012 WS Haarlem
> http://www.iprofs.nl
>
>
>
> On Thu, Oct 1, 2009 at 7:14 PM, chicagopooldude
>  wrote:
>>
>> Thanks for your reply I have already started to use the antrun plugin. I
>> wanted to know if you can please share some documentation on using seperate
>> modules. Should I use parent-child modules ?
>> --
>> View this message in context: 
>> http://www.nabble.com/Ant-to-Maven-tp25696939p25703038.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
>>
>>
>

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