Re: Heap overflow in deploy:deploy

[Dan Tran]

It is a known problem where maven (wagon) uses jvm's httpclient to do
the upload.

-D

On Wed, Oct 13, 2010 at 8:52 PM, Ron Wheeler
 wrote:
>  On 13/10/2010 7:29 PM, Phillip Hellewell wrote:
>>
>> I'm using Maven 2.2.1 and getting a heap overflow when trying to
>> deploy an artifact about 50MB in size.  I'm deploying to an Nexus
>> server (HTTP).
>>
>> I added "@set MAVEN_OPTS=-Xms128m -Xmx512m" to my mvn.bat and now it is
>> working.
>>
>> But my question is, why should uploading a file require so much
>> memory?  It's not like it tries to read the whole file into memory, or
>> does it?  If so, that seems kinda dumb.
>
> We have seen this one as well.
> Probably more of a comment on the guys that set the default way too low.
> Who would buy a computer with 512Mb of memory and no paging space?
> I suspect that the guys that write the code that we use, do not have real
> world examples where you need to move 50 Mb around.
> We had the problem with CXF (Apache web services) where we could not deploy
> the basic library jar to Nexus without setting the Eclipse parameters for a
> JVM fork to something more in keeping with the natural capacity of our
> actual workstations (2Gb physical memory with 4Gb of cache) .
> I just set the JVM options to  -Xmx1024m  to start, on any Java program,
> since the JVM is already running in a virtual machine (Linux or Vista)
> anyway that can easily deal with a 1Gb task if it does not use  the memory.
>
> Ron
>>
>> Phillip
>>
>> P.S.  Here's the trace:
>>
>> java.lang.OutOfMemoryError: Java heap space
>>         at java.util.Arrays.copyOf(Unknown Source)
>>         at java.io.ByteArrayOutputStream.write(Unknown Source)
>>         at sun.net.www.http.PosterOutputStream.write(Unknown Source)
>>         at
>> org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:492)
>>         at
>> org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:457)
>>         at
>> org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:411)
>>         at
>> org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:392)
>>         at
>> org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:365)
>>         at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:163)
>>         at
>> org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:317)
>>         at
>> org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:227)
>>         at
>> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:107)
>>         at
>> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:190)
>>         at
>> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
>>         at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
>>         at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
>>         at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
>>         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(Unknown Source)
>>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>         at java.lang.reflect.Method.invoke(Unknown Source)
>>         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)
>>
>> -
>> 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 addit

Re: Heap overflow in deploy:deploy

[Ron Wheeler]

 On 13/10/2010 7:29 PM, Phillip Hellewell wrote:

I'm using Maven 2.2.1 and getting a heap overflow when trying to
deploy an artifact about 50MB in size.  I'm deploying to an Nexus
server (HTTP).

I added "@set MAVEN_OPTS=-Xms128m -Xmx512m" to my mvn.bat and now it is working.

But my question is, why should uploading a file require so much
memory?  It's not like it tries to read the whole file into memory, or
does it?  If so, that seems kinda dumb.

We have seen this one as well.
Probably more of a comment on the guys that set the default way too low.
Who would buy a computer with 512Mb of memory and no paging space?
I suspect that the guys that write the code that we use, do not have 
real world examples where you need to move 50 Mb around.
We had the problem with CXF (Apache web services) where we could not 
deploy the basic library jar to Nexus without setting the Eclipse 
parameters for a JVM fork to something more in keeping with the natural 
capacity of our actual workstations (2Gb physical memory with 4Gb of 
cache) .
I just set the JVM options to  -Xmx1024m  to start, on any Java program, 
since the JVM is already running in a virtual machine (Linux or Vista) 
anyway that can easily deal with a 1Gb task if it does not use  the memory.


Ron

Phillip

P.S.  Here's the trace:

java.lang.OutOfMemoryError: Java heap space
 at java.util.Arrays.copyOf(Unknown Source)
 at java.io.ByteArrayOutputStream.write(Unknown Source)
 at sun.net.www.http.PosterOutputStream.write(Unknown Source)
 at 
org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:492)
 at 
org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:457)
 at 
org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:411)
 at 
org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:392)
 at 
org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:365)
 at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:163)
 at 
org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:317)
 at 
org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:227)
 at 
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:107)
 at 
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:190)
 at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
 at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
 at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
 at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
 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(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 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)

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





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

Re: maven is a swamp

[Ron Wheeler]

 On 13/10/2010 7:24 PM, Barrie Treloar wrote:

On Thu, Oct 14, 2010 at 9:34 AM, Graham Leggett  wrote:
[del]

As soon as you need to start documenting things, you're starting to go
wrong. Practically, you may have to document some things, such as where to
get certificates for access, but you should strive to keep this
documentation to zero or as near zero as humanly possible.

Documentation costs money to write, it costs money to read, it costs money
when someone missed the vital bit of the documentation and things go wrong.
This is where the "configuration by convention" really shines. If you know
the convention, you don't need to waste time with documentation,
troubleshooting, customisation, you just get on with it.

While in principle I agree, it assumes that the developer has
bootstrapped knowledge about how maven does stuff.

This is where people need to read the books on maven development.
So once they have read (and understood) the books at
http://maven.apache.org/articles.html then your statements become
true.

Maven does lack a "best practices" documentation that sorts out "what 
you can do with Maven" from "what you should do with Maven".
You can do damn near anything with but most of these things are evil and 
work against your best interests.

This is because my experience has been that a developer using Ant has
to learn Ant in order to get the build working, they become a
semi-expert or at least an advanced Ant user.
But those that use Maven can stay at a very basic level of Maven
understanding, "mvn install" and you are done.
The down side is that because they get stuck at a basic level it
becomes more difficult to become an advanced user.
Not becuase becoming an advanced user is hard, but they are not forced
to become one.
I do not want to become an expert Maven user. I have a very large portal 
in production made up of over 60 Mavenize projects.
I just need Maven to work and do its thing without me having to bend it 
to some crazy workflow that I used before we adopted Maven.
I do not want to use any more plug-ins than I have to (3 so far) and I 
certainly do not want my team writing plug-ins or Ant procedures to 
build the web services, servlets and stand-alone applications that we 
need, if minor changes to our mindsets will avoid the need.



So it does mean that they lean on the local maven expert for knowledge
and when things go wrong have more trouble working out why and how to
fix it.

One should not try to force bad workflow practices onto Maven.
If one does things in a sensible way, a team does not need an Maven expert.


Having been the Ant expert and attempting to build the "one ant build
file for any project", I was finding this more and more difficult and
complex to achieve and maintain.
I found Maven 2 a few years back and I've never regretted the
decision, and as a last resort (because I'm too lazy to write a plugin
or the solution is too once off)  I can always write an Ant snippet to
do some work that maven will run for me but not like the original
poster who started this thread off.

Ant is a wonderful programming language that I have also used in the 
past but I am not going to make my Java developers learn it in order 
build Java applications.
I want them to be Java, Spring, Hibernate and application design experts 
and any time they spend on warping Eclipse/STS or the build process is 
wasted.
Maven and Eclipse/STS has done what we need out of the box using the GUI 
POM editor.



-
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: Heap overflow in deploy:deploy

[Wayne Fay]

> Maybe taking a look at the source code would help you figure out why
> its giving you problems?

You probably want to look at the following lines in particular:

457 transfer( resource, input, output, requestType, Integer.MAX_VALUE );
480 int remaining = maxSize;
//maxSize is Integer.MAX_VALUE
483 int n = input.read( buffer, 0, Math.min(
buffer.length, remaining ) );
//read in full file (up to Integer.MAX_VALUE in length) into buffer [memory]
492 output.write( buffer, 0, n );
//then write it out

>> But my question is, why should uploading a file require so much
>> memory?  It's not like it tries to read the whole file into memory, or
>> does it?  If so, that seems kinda dumb.

So yes, it seems like it does read in the entire file into memory.

Wayne

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

Re: Heap overflow in deploy:deploy

[Wayne Fay]

> But my question is, why should uploading a file require so much
> memory?  It's not like it tries to read the whole file into memory, or
> does it?  If so, that seems kinda dumb.

Maybe taking a look at the source code would help you figure out why
its giving you problems?

http://maven.apache.org/wagon/wagon-provider-api/xref/org/apache/maven/wagon/AbstractWagon.html

If you patch a bug, please contribute it back.

Wayne

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

Re: maven is a swamp

[Barrie Treloar]

On Thu, Oct 14, 2010 at 9:59 AM, Benson Margulies  wrote:
> I'm concerned that the circle of congratulations here is somewhat
> oversimplifying this.
>
> I've brought Maven into my day job.
>
> I've arranged all the code involved to follow the maven way of doing things.
>
> And yet, I have some POM files that are veritable thickets of XML, and
> attract a fair amount of unfavorable commentary from the people who
> work for me.

This is the crux of my comment about advanced Maven users compared
with advanced Ant users.
When you extend your pom file piece by piece, each piece on itself is
easily understandable.
But when you get the less experienced person looking at the completed
pom they are overwhelmed.
I dont have any suggestions for this except to convince them to skill up.
I'd suggest that any alternative build system would still be at least
as ugly to read and understand.

[del]

> I don't hate on Maven. But I think that some people who show up on
> this list in a state of frustration get pretty short shrift.

That basic work flow of compile and install jars to repo should work
out of the box with no issues.
All of your examples are the "extra" bits over and above this, which
definitely have some wrinkles.
And mostly the wrinkles are around working out what the convention should be.

The benefit is that as more people work out the convention they can be
coded once in the plugin and all users can benefit from it.
The problem is that very few people actually do this.
If you compare this to Ant you are on your own, writing a build
maintained by one.

Personally, I am amazed when people expect a tool to do everything and
anything they can think of out of the box.
It takes an enormous amount of effort to get to that state, but it is
slowly getting there.

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

Re: maven is a swamp

[Benson Margulies]

I'm concerned that the circle of congratulations here is somewhat
oversimplifying this.

I've brought Maven into my day job.

I've arranged all the code involved to follow the maven way of doing things.

And yet, I have some POM files that are veritable thickets of XML, and
attract a fair amount of unfavorable commentary from the people who
work for me.

Howcome? Well, convention over configuration is great ... *when the
situation is covered by the convention*. There tends to be a steep
step function in complexity from a trivial POM to any other.

For just one example, consider a POM that uses jetty with failsafe to
run integration tests against a web container. I could come up with
some other examples where, with no use of antrun, my poms are way too
long and verbose to be easily read or digested.

Or, consider the fun and games involved in JNI usage, which forces me
to wrap all my poms in makefiles to get the environment set correctly.

In another realm, the site plugin is a never-ending source of
frustration for some of us, given it's tendency to run the javadoc six
or seven times.

I don't hate on Maven. But I think that some people who show up on
this list in a state of frustration get pretty short shrift.

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

Heap overflow in deploy:deploy

[Phillip Hellewell]

I'm using Maven 2.2.1 and getting a heap overflow when trying to
deploy an artifact about 50MB in size.  I'm deploying to an Nexus
server (HTTP).

I added "@set MAVEN_OPTS=-Xms128m -Xmx512m" to my mvn.bat and now it is working.

But my question is, why should uploading a file require so much
memory?  It's not like it tries to read the whole file into memory, or
does it?  If so, that seems kinda dumb.

Phillip

P.S.  Here's the trace:

java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Unknown Source)
at java.io.ByteArrayOutputStream.write(Unknown Source)
at sun.net.www.http.PosterOutputStream.write(Unknown Source)
at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:492)
at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:457)
at 
org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:411)
at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:392)
at 
org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:365)
at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:163)
at 
org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:317)
at 
org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:227)
at 
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:107)
at 
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:190)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
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(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
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)

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

Re: maven is a swamp

[Barrie Treloar]

On Thu, Oct 14, 2010 at 9:34 AM, Graham Leggett  wrote:
[del]
> As soon as you need to start documenting things, you're starting to go
> wrong. Practically, you may have to document some things, such as where to
> get certificates for access, but you should strive to keep this
> documentation to zero or as near zero as humanly possible.
>
> Documentation costs money to write, it costs money to read, it costs money
> when someone missed the vital bit of the documentation and things go wrong.
> This is where the "configuration by convention" really shines. If you know
> the convention, you don't need to waste time with documentation,
> troubleshooting, customisation, you just get on with it.

While in principle I agree, it assumes that the developer has
bootstrapped knowledge about how maven does stuff.

This is where people need to read the books on maven development.
So once they have read (and understood) the books at
http://maven.apache.org/articles.html then your statements become
true.

This is because my experience has been that a developer using Ant has
to learn Ant in order to get the build working, they become a
semi-expert or at least an advanced Ant user.
But those that use Maven can stay at a very basic level of Maven
understanding, "mvn install" and you are done.
The down side is that because they get stuck at a basic level it
becomes more difficult to become an advanced user.
Not becuase becoming an advanced user is hard, but they are not forced
to become one.
So it does mean that they lean on the local maven expert for knowledge
and when things go wrong have more trouble working out why and how to
fix it.

Having been the Ant expert and attempting to build the "one ant build
file for any project", I was finding this more and more difficult and
complex to achieve and maintain.
I found Maven 2 a few years back and I've never regretted the
decision, and as a last resort (because I'm too lazy to write a plugin
or the solution is too once off)  I can always write an Ant snippet to
do some work that maven will run for me but not like the original
poster who started this thread off.

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

Re: maven is a swamp

[Graham Leggett]

On 13 Oct 2010, at 10:52 PM, Wendy Smoak wrote:


Help with the website is always welcome.

The source code for the website is here:
http://svn.apache.org/repos/asf/maven/site/trunk/
The home page is down at
http://svn.apache.org/repos/asf/maven/site/trunk/src/site/xdoc/index.xml.vm
(Most other pages are under src/site/apt).

If you need help editing/building/submitting a patch, come join us on
the dev list and ask.

(Graham, would you be okay with having your post adapted for the
website, should someone have the time and energy to work on it?)


Definitely.

I think some key points maven needs to make are these:

- "Maven already knows how to do stuff. Now step aside, and let maven  
do what it has to do, don't get in maven's way".


- "You don't need to customise maven to fit your project, customise  
your project to fit maven".


- "If you need to document your build, you're doing it wrong".

Maven knows how to do stuff. So do developers who know how to use maven.

If you've used maven correctly, you don't need to document anything at  
all. You tell your new developer "here's the URL of the maven- 
generated site, off you go".


The developer knows where on the site to find the location of the  
project in SCM. The developer checks out the project. The developer  
knows how to build the project. The developer knows how to obtain all  
the dependencies. The developer knows how to release the project when  
they're done. The developer didn't need to read a single piece of  
documentation that wasn't autogenerated for your project.


As soon as you need to start documenting things, you're starting to go  
wrong. Practically, you may have to document some things, such as  
where to get certificates for access, but you should strive to keep  
this documentation to zero or as near zero as humanly possible.


Documentation costs money to write, it costs money to read, it costs  
money when someone missed the vital bit of the documentation and  
things go wrong. This is where the "configuration by convention"  
really shines. If you know the convention, you don't need to waste  
time with documentation, troubleshooting, customisation, you just get  
on with it.


Regards,
Graham
--


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

Re: maven is a swamp

[Wendy Smoak]

On Wed, Oct 13, 2010 at 4:35 PM, Ron Wheeler
 wrote:
>  Excellent!!! I wish I could express myself as clearly and elegantly.
> This should be on the front page of the Maven website (or right next to it).

Help with the website is always welcome.

The source code for the website is here:
http://svn.apache.org/repos/asf/maven/site/trunk/
The home page is down at
http://svn.apache.org/repos/asf/maven/site/trunk/src/site/xdoc/index.xml.vm
(Most other pages are under src/site/apt).

If you need help editing/building/submitting a patch, come join us on
the dev list and ask.

(Graham, would you be okay with having your post adapted for the
website, should someone have the time and energy to work on it?)

-- 
Wendy

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

Re: maven is a swamp

[Ron Wheeler]

 Excellent!!! I wish I could express myself as clearly and elegantly.
This should be on the front page of the Maven website (or right next to it).

On 13/10/2010 3:53 PM, Graham Leggett wrote:

On 13 Oct 2010, at 8:52 PM, Leon Rosenberg wrote:


Many traditional programming languages are declarative and not
procedural or are based on declarative concepts, most of the time the
declarative nature of such languages proved itself problematic.
But seriously is there a comparison matrix somewhere which compares
ant+ivy vs maven?


A comparison would make little sense, because ant and maven aren't 
alternatives for one another. Ant is a language that allows you to 
create custom build scripts, but you are required to write those build 
scripts yourself, over and over again. Maven on the other hand arrives 
with built in knowledge on how to build things, you are only required 
to tell maven the basics, like the name of the artifact, the version, 
etc. Maven does everything else for you without you having to tell it 
how to do it.



As an ant+ivy user I have recently tried out maven
(yes, i hand-wrote poms for about 15 projects) which mostly depend on
each other, I got them all published in nexus etc. I must say that I'm
pretty shaken how unreliable maven build are.


I predict the core of your problem is "as an ant+ivy user...".

With ant, you adopt the mindset "I need to tell ant to do X, then Y, 
then Z". With maven, you don't tell it how to do anything, it already 
knows how to do stuff.


If you try and approach maven with the idea that you want to tell 
maven to do X, Y and then Z, you'll very quickly come unstuck, because 
you'll be fighting with maven, trying to convince it to do things in 
your order instead of maven's built in order.


Maven already knows how to do stuff. All you need to do is fill in the 
blanks. Tell maven what kind of artifact it is, what it is called. And 
don't stray from the defaults - you don't need to put your source code 
in some weird directory structure, if maven defaults to src/main/java, 
put your code in src/main/java and leave it at that.


When you find yourself in a situation where you have a 5 line pom 
file, with hundreds of plugins all custom configured, you're fighting 
against maven. This isn't maven's fault, this is the fault of the 
person who created the pom. Keep it simple, keep it to default behaviour.



With ant it either works or not. If it works, it works everywhere, in
console, in eclipse in hudson.


In my experience, I have not once encountered an ant build that 
worked, ever. The reason was simple: the build is always secondary to 
the code itself. Inevitably, the ant build only performed the basics, 
even "ant clean" was left out most of the time. Every single one I 
encountered had some or other path that was hard coded to "C:\Program 
Files\..." with the developer expecting everyone else to just recreate 
the same directory structure, it was ridiculous. Maven has gone off 
and solved the build problem, it does not rely on every developer's 
half hearted attempt to write a build script when they're under 
pressure to produce code, not build.


At the core of ant is the question "how do I make ant do this?".

At the core of maven is the question "how does maven do this.".

Remove the "I" from the equation, and just do it like maven wants you 
to do it, and suddenly everything becomes a *lot* more reliable.



I find it pretty hard to maintain versions with maven. Do I have to
make them all depend on RELEASE version of each other?


Yes.

The whole point of maven is repeatability. What that means 
practically, is that ops call you and say "we have problem X in 
production, v2.3.4 of the code, can you fix it".


If you cannot get v2.3.4 of the code - and by that I mean precisely 
v2.3.4 of the code - up and running in your development environment, 
you're toast.


To do that, v2.3.4 of the code must be built against a pristine tag. 
And v2.3.4 of the code must depend on other jars who were also built 
from a pristine tag.


What a SNAPSHOT is is a great big red flag that says "ALL BETS ARE 
OFF". SNAPSHOTs are built from random untraceable working copies. You 
should *never* allow a SNAPSHOT to find its way into production.


When you use the maven-release-plugin (and you should), it performs 
all the checks and balances to verify that your build is entirely free 
of SNAPSHOTs, and that your code is checked in cleanly.


Regards,
Graham
--


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





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

Re: maven is a swamp

[Graham Leggett]

On 13 Oct 2010, at 8:52 PM, Leon Rosenberg wrote:


Many traditional programming languages are declarative and not
procedural or are based on declarative concepts, most of the time the
declarative nature of such languages proved itself problematic.
But seriously is there a comparison matrix somewhere which compares
ant+ivy vs maven?


A comparison would make little sense, because ant and maven aren't  
alternatives for one another. Ant is a language that allows you to  
create custom build scripts, but you are required to write those build  
scripts yourself, over and over again. Maven on the other hand arrives  
with built in knowledge on how to build things, you are only required  
to tell maven the basics, like the name of the artifact, the version,  
etc. Maven does everything else for you without you having to tell it  
how to do it.



As an ant+ivy user I have recently tried out maven
(yes, i hand-wrote poms for about 15 projects) which mostly depend on
each other, I got them all published in nexus etc. I must say that I'm
pretty shaken how unreliable maven build are.


I predict the core of your problem is "as an ant+ivy user...".

With ant, you adopt the mindset "I need to tell ant to do X, then Y,  
then Z". With maven, you don't tell it how to do anything, it already  
knows how to do stuff.


If you try and approach maven with the idea that you want to tell  
maven to do X, Y and then Z, you'll very quickly come unstuck, because  
you'll be fighting with maven, trying to convince it to do things in  
your order instead of maven's built in order.


Maven already knows how to do stuff. All you need to do is fill in the  
blanks. Tell maven what kind of artifact it is, what it is called. And  
don't stray from the defaults - you don't need to put your source code  
in some weird directory structure, if maven defaults to src/main/java,  
put your code in src/main/java and leave it at that.


When you find yourself in a situation where you have a 5 line pom  
file, with hundreds of plugins all custom configured, you're fighting  
against maven. This isn't maven's fault, this is the fault of the  
person who created the pom. Keep it simple, keep it to default  
behaviour.



With ant it either works or not. If it works, it works everywhere, in
console, in eclipse in hudson.


In my experience, I have not once encountered an ant build that  
worked, ever. The reason was simple: the build is always secondary to  
the code itself. Inevitably, the ant build only performed the basics,  
even "ant clean" was left out most of the time. Every single one I  
encountered had some or other path that was hard coded to "C:\Program  
Files\..." with the developer expecting everyone else to just recreate  
the same directory structure, it was ridiculous. Maven has gone off  
and solved the build problem, it does not rely on every developer's  
half hearted attempt to write a build script when they're under  
pressure to produce code, not build.


At the core of ant is the question "how do I make ant do this?".

At the core of maven is the question "how does maven do this.".

Remove the "I" from the equation, and just do it like maven wants you  
to do it, and suddenly everything becomes a *lot* more reliable.



I find it pretty hard to maintain versions with maven. Do I have to
make them all depend on RELEASE version of each other?


Yes.

The whole point of maven is repeatability. What that means  
practically, is that ops call you and say "we have problem X in  
production, v2.3.4 of the code, can you fix it".


If you cannot get v2.3.4 of the code - and by that I mean precisely  
v2.3.4 of the code - up and running in your development environment,  
you're toast.


To do that, v2.3.4 of the code must be built against a pristine tag.  
And v2.3.4 of the code must depend on other jars who were also built  
from a pristine tag.


What a SNAPSHOT is is a great big red flag that says "ALL BETS ARE  
OFF". SNAPSHOTs are built from random untraceable working copies. You  
should *never* allow a SNAPSHOT to find its way into production.


When you use the maven-release-plugin (and you should), it performs  
all the checks and balances to verify that your build is entirely free  
of SNAPSHOTs, and that your code is checked in cleanly.


Regards,
Graham
--


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

Re: maven is a swamp

[Benson Margulies]

This thread has jumped the shark. I recommend letting it drown.

On Wed, Oct 13, 2010 at 3:44 PM, Jason Chaffee  wrote:
> I agree with how things seem to run differently on cmd-line, vs. eclipse, vs. 
> Hudson.  I can be extremely frustrating.
>
> However, maven does take a "convention over configuration" approach to things 
> for the most part.   Many times the problems people encounter are not 
> following the convention and they are trying to configure maven to do 
> something that isn't a best practice.
>
> -Original Message-
> From: Leon Rosenberg [mailto:rosenberg.l...@gmail.com]
> Sent: Wednesday, October 13, 2010 11:52 AM
> To: Maven Users List
> Subject: Re: maven is a swamp
>
> On Wed, Oct 13, 2010 at 5:31 AM, Brian Topping  wrote:
>>
>> On Oct 12, 2010, at 10:01 PM, Martin Gainty wrote:
>>
>>> Suprisingly maven is not the first programming language to use XML
>>
>> This is worth clarifying.  What makes Maven unique, and I believe 
>> groundbreaking, is that the POM is declarative, not procedural.  It is not a 
>> programming language in the traditional sense.  There are many examples of 
>> procedural languages written in XML, and many agree they are painful to use. 
>>  That's why the one that was used in Maven 1.x is notably absent from Maven 
>> 2.x
>
> Many traditional programming languages are declarative and not
> procedural or are based on declarative concepts, most of the time the
> declarative nature of such languages proved itself problematic.
> But seriously is there a comparison matrix somewhere which compares
> ant+ivy vs maven? As an ant+ivy user I have recently tried out maven
> (yes, i hand-wrote poms for about 15 projects) which mostly depend on
> each other, I got them all published in nexus etc. I must say that I'm
> pretty shaken how unreliable maven build are.
> With ant it either works or not. If it works, it works everywhere, in
> console, in eclipse in hudson. With maven, I got plenty of builds that
> run in console but not in eclipse, or in eclipse but not in hudson, or
> in hudson but not in console. Besides that I haven't found anything in
> maven that isn't present in ant somehow, except for parent-poms, but
> they got added to the recent ivy release so they don't count anymore
> ;-)
>
> I find it pretty hard to maintain versions with maven. Do I have to
> make them all depend on RELEASE version of each other? Distinct
> versions of each other? SNAPSHOTS? I started with snapshot, but I
> couldn't publish a second version without republishing everything, so
> I consider this bad idea...
>
> regards
> Leon
>
> P.S. Is there a documentation somewhere which really describes which
> lifecycle phase is meant for what?
>
> .
>>
>> Once you get used to the paradigm shift and get used to it, it becomes 
>> remarkably easy to look at any build and find what it is doing.  While many 
>> systems (like Ivy) have started using Maven's central repository, if they 
>> use procedural descriptions of a build, they are missing the vision that 
>> Maven has.
>>
>> Personally, I find it frustrating to have to dissect an Ant build to figure 
>> out what's going on.  A Maven build is validated against a schema, and 
>> finding what I am looking for is predictable and quick.  It's also fast to 
>> write, since most IDEs can do type-completion with a schema declaration, and 
>> many have been augmented to read plugin.xml files inside plugins to do type 
>> completion of plugin configuration as well.
>>
>> Lastly, having a validated structure for the build allows IDEs to import the 
>> POM directly, and because the Plugin interface is so simple, it's easy for 
>> IDEs to integrate against plugins.  In my experience, this level of 
>> integration is unique to Maven.
>>
>> Hope you stick with it.  Maven will really grow on you, as it has with a 
>> huge number of folks over the last few years.
>>
>> Brian
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

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

RE: maven is a swamp

[Jason Chaffee]

I agree with how things seem to run differently on cmd-line, vs. eclipse, vs. 
Hudson.  I can be extremely frustrating.

However, maven does take a "convention over configuration" approach to things 
for the most part.   Many times the problems people encounter are not following 
the convention and they are trying to configure maven to do something that 
isn't a best practice.

-Original Message-
From: Leon Rosenberg [mailto:rosenberg.l...@gmail.com] 
Sent: Wednesday, October 13, 2010 11:52 AM
To: Maven Users List
Subject: Re: maven is a swamp

On Wed, Oct 13, 2010 at 5:31 AM, Brian Topping  wrote:
>
> On Oct 12, 2010, at 10:01 PM, Martin Gainty wrote:
>
>> Suprisingly maven is not the first programming language to use XML
>
> This is worth clarifying.  What makes Maven unique, and I believe 
> groundbreaking, is that the POM is declarative, not procedural.  It is not a 
> programming language in the traditional sense.  There are many examples of 
> procedural languages written in XML, and many agree they are painful to use.  
> That's why the one that was used in Maven 1.x is notably absent from Maven 2.x

Many traditional programming languages are declarative and not
procedural or are based on declarative concepts, most of the time the
declarative nature of such languages proved itself problematic.
But seriously is there a comparison matrix somewhere which compares
ant+ivy vs maven? As an ant+ivy user I have recently tried out maven
(yes, i hand-wrote poms for about 15 projects) which mostly depend on
each other, I got them all published in nexus etc. I must say that I'm
pretty shaken how unreliable maven build are.
With ant it either works or not. If it works, it works everywhere, in
console, in eclipse in hudson. With maven, I got plenty of builds that
run in console but not in eclipse, or in eclipse but not in hudson, or
in hudson but not in console. Besides that I haven't found anything in
maven that isn't present in ant somehow, except for parent-poms, but
they got added to the recent ivy release so they don't count anymore
;-)

I find it pretty hard to maintain versions with maven. Do I have to
make them all depend on RELEASE version of each other? Distinct
versions of each other? SNAPSHOTS? I started with snapshot, but I
couldn't publish a second version without republishing everything, so
I consider this bad idea...

regards
Leon

P.S. Is there a documentation somewhere which really describes which
lifecycle phase is meant for what?

.
>
> Once you get used to the paradigm shift and get used to it, it becomes 
> remarkably easy to look at any build and find what it is doing.  While many 
> systems (like Ivy) have started using Maven's central repository, if they use 
> procedural descriptions of a build, they are missing the vision that Maven 
> has.
>
> Personally, I find it frustrating to have to dissect an Ant build to figure 
> out what's going on.  A Maven build is validated against a schema, and 
> finding what I am looking for is predictable and quick.  It's also fast to 
> write, since most IDEs can do type-completion with a schema declaration, and 
> many have been augmented to read plugin.xml files inside plugins to do type 
> completion of plugin configuration as well.
>
> Lastly, having a validated structure for the build allows IDEs to import the 
> POM directly, and because the Plugin interface is so simple, it's easy for 
> IDEs to integrate against plugins.  In my experience, this level of 
> integration is unique to Maven.
>
> Hope you stick with it.  Maven will really grow on you, as it has with a huge 
> number of folks over the last few years.
>
> Brian
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

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


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

Re: maven is a swamp

[Ron Wheeler]

 On 13/10/2010 2:52 PM, Leon Rosenberg wrote:

On Wed, Oct 13, 2010 at 5:31 AM, Brian Topping  wrote:

On Oct 12, 2010, at 10:01 PM, Martin Gainty wrote:


Suprisingly maven is not the first programming language to use XML

This is worth clarifying.  What makes Maven unique, and I believe 
groundbreaking, is that the POM is declarative, not procedural.  It is not a 
programming language in the traditional sense.  There are many examples of 
procedural languages written in XML, and many agree they are painful to use.  
That's why the one that was used in Maven 1.x is notably absent from Maven 2.x

Many traditional programming languages are declarative and not
procedural or are based on declarative concepts, most of the time the
declarative nature of such languages proved itself problematic.
But seriously is there a comparison matrix somewhere which compares
ant+ivy vs maven? As an ant+ivy user I have recently tried out maven
(yes, i hand-wrote poms for about 15 projects) which mostly depend on
each other, I got them all published in nexus etc. I must say that I'm
pretty shaken how unreliable maven build are.
With ant it either works or not. If it works, it works everywhere, in
console, in eclipse in hudson. With maven, I got plenty of builds that
run in console but not in eclipse, or in eclipse but not in hudson, or
in hudson but not in console. Besides that I haven't found anything in
maven that isn't present in ant somehow, except for parent-poms, but
they got added to the recent ivy release so they don't count anymore
;-)

I find it pretty hard to maintain versions with maven. Do I have to
make them all depend on RELEASE version of each other? Distinct
versions of each other? SNAPSHOTS? I started with snapshot, but I
couldn't publish a second version without republishing everything, so
I consider this bad idea...

regards
Leon

P.S. Is there a documentation somewhere which really describes which
lifecycle phase is meant for what?


Maven is really missing a best practice section.
You can do almost anything with Maven but most of those things are 
really bad ways to go about developing.


If you read the workflows that people are trying to shoehorn into Maven, 
you would think that there are no standard platforms for running 
applications and each company writes their own web server.
I can not believe that there are so many different ways to deploy java 
applications.




.

Once you get used to the paradigm shift and get used to it, it becomes 
remarkably easy to look at any build and find what it is doing.  While many 
systems (like Ivy) have started using Maven's central repository, if they use 
procedural descriptions of a build, they are missing the vision that Maven has.

Personally, I find it frustrating to have to dissect an Ant build to figure out 
what's going on.  A Maven build is validated against a schema, and finding what 
I am looking for is predictable and quick.  It's also fast to write, since most 
IDEs can do type-completion with a schema declaration, and many have been 
augmented to read plugin.xml files inside plugins to do type completion of 
plugin configuration as well.

Lastly, having a validated structure for the build allows IDEs to import the 
POM directly, and because the Plugin interface is so simple, it's easy for IDEs 
to integrate against plugins.  In my experience, this level of integration is 
unique to Maven.

Hope you stick with it.  Maven will really grow on you, as it has with a huge 
number of folks over the last few years.

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



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





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

Re: maven is a swamp

[Leon Rosenberg]

On Wed, Oct 13, 2010 at 5:31 AM, Brian Topping  wrote:
>
> On Oct 12, 2010, at 10:01 PM, Martin Gainty wrote:
>
>> Suprisingly maven is not the first programming language to use XML
>
> This is worth clarifying.  What makes Maven unique, and I believe 
> groundbreaking, is that the POM is declarative, not procedural.  It is not a 
> programming language in the traditional sense.  There are many examples of 
> procedural languages written in XML, and many agree they are painful to use.  
> That's why the one that was used in Maven 1.x is notably absent from Maven 2.x

Many traditional programming languages are declarative and not
procedural or are based on declarative concepts, most of the time the
declarative nature of such languages proved itself problematic.
But seriously is there a comparison matrix somewhere which compares
ant+ivy vs maven? As an ant+ivy user I have recently tried out maven
(yes, i hand-wrote poms for about 15 projects) which mostly depend on
each other, I got them all published in nexus etc. I must say that I'm
pretty shaken how unreliable maven build are.
With ant it either works or not. If it works, it works everywhere, in
console, in eclipse in hudson. With maven, I got plenty of builds that
run in console but not in eclipse, or in eclipse but not in hudson, or
in hudson but not in console. Besides that I haven't found anything in
maven that isn't present in ant somehow, except for parent-poms, but
they got added to the recent ivy release so they don't count anymore
;-)

I find it pretty hard to maintain versions with maven. Do I have to
make them all depend on RELEASE version of each other? Distinct
versions of each other? SNAPSHOTS? I started with snapshot, but I
couldn't publish a second version without republishing everything, so
I consider this bad idea...

regards
Leon

P.S. Is there a documentation somewhere which really describes which
lifecycle phase is meant for what?

.
>
> Once you get used to the paradigm shift and get used to it, it becomes 
> remarkably easy to look at any build and find what it is doing.  While many 
> systems (like Ivy) have started using Maven's central repository, if they use 
> procedural descriptions of a build, they are missing the vision that Maven 
> has.
>
> Personally, I find it frustrating to have to dissect an Ant build to figure 
> out what's going on.  A Maven build is validated against a schema, and 
> finding what I am looking for is predictable and quick.  It's also fast to 
> write, since most IDEs can do type-completion with a schema declaration, and 
> many have been augmented to read plugin.xml files inside plugins to do type 
> completion of plugin configuration as well.
>
> Lastly, having a validated structure for the build allows IDEs to import the 
> POM directly, and because the Plugin interface is so simple, it's easy for 
> IDEs to integrate against plugins.  In my experience, this level of 
> integration is unique to Maven.
>
> Hope you stick with it.  Maven will really grow on you, as it has with a huge 
> number of folks over the last few years.
>
> Brian
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

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

Re: multimodul and parent pom question

[Justin Edelson]

Separating aggregation from inheritance is definitely a good idea if
your modules are versioned and/or released independently from one
another which sounds like is the case here.

Justin

On 10/13/10 10:40 AM, mremerson...@aim.com wrote:
> Hi,
> 
> we have a multimodul project with a lot of modules. Currently the root-pom of 
> the multimodul project is also the parent pom of each submodul project. 
> This stroke us quite some time when we made changes in the parent pom 
> regarding dependency versions in dependencyManagement or other configuration 
> changes, because we could not deploy the pom without building the whole 
> system.
> 
> So our idea is to separate the two concerns, namely the configurations 
> (scm/CI server/ dependencyManagement / distributionManagement etc) with the 
> module information. So the root-pom only has the module information and one 
> of the modules is a pom project with all configurations. All other modules 
> use then this pom as their parent. With that we could make changes to the 
> parent pom without any trouble.
> 
> Is this way correct or will it create more trouble ?
> 
> Thanks for any advice
> 
>  
> 
>  
> 
> 
> 


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

Re: maven is a swamp

[chemit]

Le Wed, 13 Oct 2010 11:52:04 -0400,
Ron Wheeler  a écrit :

>   I was just replying to the list using the last post in the
> conversation.
> 
> Not to anyone in particular.
> 
My bad in that case :) 
> 
> 
> On 13/10/2010 9:57 AM, chemit wrote:
> > Le Wed, 13 Oct 2010 08:58:27 -0400,
> > Ron Wheeler  a écrit :
> >
> >>Doing the wrong thing and not using an IDE with a POM editor is
> >> not a good recipe for a smooth development cycle.
> >> I will admit to occasionally editing XML but that is for extreme
> >> cases while you are getting set up..
> >>
> > euh wrong person :)
> >
> > You should have respond to previous mail, ... I love maven and all
> > the xml stuff (arch to su much in facts.) I was just responding to
> > the guy Kenneth which seems to be pretty angry with Maven and xml ;)
> >
> >
> >> If you don't like XML:
> >> 1) Get your development workflow Mavenized
> >> 2) Get a Maven Repo set up
> >> 3) Restructure your projects to fit the way Maven works
> >> 3) Use an IDE that supports Maven with a proper human oriented
> >> editor
> >> - Eclipse STS is very good at this.
> >>
> >> Then you will have no need of XML editing and no need to screw
> >> around with command line Maven or custom plug-ins or custom goals.
> >> You will not spend a lot of time in this forum moaning about the
> >> unfairness of life and the difficulty of using Maven.
> >>
> >> Once you start using Maven properly, it is a very high level tool
> >> for building Java applications such as:
> >> Java WebServices
> >> Java Servlets
> >> Java Portlets
> >> Java Standalone applications
> >>
> >> If you are building something else, my comments may not be
> >> relevant.
> >>
> >>
> >> Ron
> >>
> >>
> >>
> >> On 13/10/2010 2:47 AM, chemit wrote:
> >>> Le Tue, 12 Oct 2010 19:35:46 -0500,
> >>> Kenneth McDonald   a écrit :
> >>>
>  Yes, I realize this is flamebait, but after trying to puzzle out
>  the following maven plugin:
> 
>    
>    maven-antrun-plugin
>    1.6
>    
>    
>    deploy
>    deploy-gh-pages
>    
>    run
>    
>    
>    
>  location=""/>   
>    
>    
>  dir="${gh-pages-dir}">   
>    
>  dir="${gh-pages-dir}">   
>    
>    
>    
>    
>    
>    
> 
>  I simply can't resist. Whoever in their right mind decided
>  software developers to think that requiring other developers to
>  write config files in XML was a proper decision?
> 
>  Python, Ruby, and (yes even Perl) have had had much more elegant
>  and concise ways of managing complex data structures for years
>  now. And there's a reason JSON has become so popular--primarily
>  because XML is not, and was never intended to be, a format for
>  developers to write specifications in.
> >>> First of all using the ant plugin is against "Best pratices", so
> >>> for me and from this point, why critisize something when you are
> >>> doing it the wrong way ?
> >>>
>  Let's take a look at the most obvious of the problems in the
>  above:
> 
>  location=""/>   
>    
>    
>  dir="${gh-pages-dir}">   
>    
>  dir="${gh-pages-dir}">   
>    
> 
>  Now, I'm still very new to maven, but it strikes me that what the
>  above is saying is (in Pythonic code, but feel free to convert to
>  your own):
> 
>  import git
>  gh-pages-dir = ""
>  git(dir=gh-pages-dir, "add .")
>  git(dir=gh-pages-dir, "commit")
>  git(dir=gh-pages-dir, "push origin gh-pages")
> 
>  I'm sure there are errors in the translation--but I'm equally
>  sure that if these errors were corrected, they would not
>  substantially alter the ratio of XML to Pythonic code. Ruby and
>  even Perl would do just as well.
> 
> >>> but if it is so simple as you say, you should be able to write
> >>> your simply code without any doubt...
> >>>
>  So here's a challenge to the (very intelligent) folks at apache.
>  Open your minds to the fact that XML is not only the Final
>  Solution, but isn't even close to the b

Re: naming now that Maven 3 is out..

[Paul Benedict]

I brought the issue up back then and it got at least pushed to 3.1

On Wed, Oct 13, 2010 at 9:48 AM, Wendy Smoak  wrote:
> On Wed, Oct 13, 2010 at 10:13 AM, Nayan Hajratwala  wrote:
>> Kind of a random thought -- now that Maven 3 is out, are all those "M2" 
>> based names going to be changed to "M3", or more preferably a non-version 
>> specific name?
>>
>> i.e. M2_HOME, m2eclipse, etc.?
>
> This was discussed on the dev list a while back, you can check the
> archives to see how it turned out.
>
> (m2eclipse is a separate project, its naming wouldn't be decided here.)
>
> --
> 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: maven is a swamp

[Ron Wheeler]

 I was just replying to the list using the last post in the conversation.

Not to anyone in particular.



On 13/10/2010 9:57 AM, chemit wrote:

Le Wed, 13 Oct 2010 08:58:27 -0400,
Ron Wheeler  a écrit :


   Doing the wrong thing and not using an IDE with a POM editor is not
a good recipe for a smooth development cycle.
I will admit to occasionally editing XML but that is for extreme
cases while you are getting set up..


euh wrong person :)

You should have respond to previous mail, ... I love maven and all the
xml stuff (arch to su much in facts.) I was just responding to the guy
Kenneth which seems to be pretty angry with Maven and xml ;)



If you don't like XML:
1) Get your development workflow Mavenized
2) Get a Maven Repo set up
3) Restructure your projects to fit the way Maven works
3) Use an IDE that supports Maven with a proper human oriented editor
- Eclipse STS is very good at this.

Then you will have no need of XML editing and no need to screw around
with command line Maven or custom plug-ins or custom goals.
You will not spend a lot of time in this forum moaning about the
unfairness of life and the difficulty of using Maven.

Once you start using Maven properly, it is a very high level tool for
building Java applications such as:
Java WebServices
Java Servlets
Java Portlets
Java Standalone applications

If you are building something else, my comments may not be relevant.


Ron



On 13/10/2010 2:47 AM, chemit wrote:

Le Tue, 12 Oct 2010 19:35:46 -0500,
Kenneth McDonald   a écrit :


Yes, I realize this is flamebait, but after trying to puzzle out
the following maven plugin:

  
  maven-antrun-plugin
  1.6
  
  
  deploy
  deploy-gh-pages
  
  run
  
  
  
 
  
  
 
  
 
  
  
  
  
  
  

I simply can't resist. Whoever in their right mind decided software
developers to think that requiring other developers to write config
files in XML was a proper decision?

Python, Ruby, and (yes even Perl) have had had much more elegant
and concise ways of managing complex data structures for years
now. And there's a reason JSON has become so popular--primarily
because XML is not, and was never intended to be, a format for
developers to write specifications in.

First of all using the ant plugin is against "Best pratices", so
for me and from this point, why critisize something when you are
doing it the wrong way ?


Let's take a look at the most obvious of the problems in the above:

 
  
  
 
  
 
  

Now, I'm still very new to maven, but it strikes me that what the
above is saying is (in Pythonic code, but feel free to convert to
your own):

import git
gh-pages-dir = ""
git(dir=gh-pages-dir, "add .")
git(dir=gh-pages-dir, "commit")
git(dir=gh-pages-dir, "push origin gh-pages")

I'm sure there are errors in the translation--but I'm equally sure
that if these errors were corrected, they would not substantially
alter the ratio of XML to Pythonic code. Ruby and even Perl would
do just as well.


but if it is so simple as you say, you should be able to write your
simply code without any doubt...


So here's a challenge to the (very intelligent) folks at apache.
Open your minds to the fact that XML is not only the Final
Solution, but isn't even close to the best solution, and start
producing some products that are configurable without an entire
manual in front of oneself. I realize that arriving at an optimal
solution is not really possible, but XML is so suboptimal as to
beggar belief.

I am just so sick of using crappy "solutions" (read: XML) layered
over top of what could be good solutions.


Yes crappy is the right world, I sujjest you to go back to
MakeFile, no xml, no convention, just... CRAP :)


Sorry, had to vent. Who knows, maybe it'll do some good?

And you feel better now ?

Ken McDonald


-
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: naming now that Maven 3 is out..

[Xavier Carpentier]

Hi,
and other : *.m2*/settings.xml ?
Bye
--

Carpentier Xavier
Ingénieur Développement - x.carpent...@greenivory.com 
 - http://www.greenivory.com 



*GreenIvory Europe*
10 rue Saint Wendelin
67500 Haguenau
France  *GreenIvory America*
Suite 200
3608 Shannon Road
Durham NC 27707
USA
Tél.+33 9 50 53 10 34   Tel.+1 (617) 862-2319
Fax +33 9 50 53 10 34   Fax +1 (919) 493-8837
GSM +33 6 68 81 87 68

Consider the environment. Don't print this e-mail unless you need to.
To avoid excessive data transfer, we've removed our logo.



On 13/10/2010 16:13, Nayan Hajratwala wrote:

Kind of a random thought -- now that Maven 3 is out, are all those "M2" based names going 
to be changed to "M3", or more preferably a non-version specific name?

i.e. M2_HOME, m2eclipse, etc.?


---
Nayan Hajratwala
http://agileshrugged.com
http://twitter.com/nhajratw
734.658.6032


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


   

Re: Need to specify versions of standard plugins in 3.0?

[Patrick Aikens]

As the father of an 11 month old daughter, I understand. :)

On Oct 13, 2010, at 4:58 AM, Stephen Connolly  
wrote:

> http://jira.codehaus.org/browse/MVERSIONS-6 and
> http://jira.codehaus.org/browse/MVERSIONS-7 should give what you want
> when I get around to writing them...
> 
> the blocker for me is having stable integration tests, which depends
> on finishing mock-repository-maven-plugin... and swamped in work and I
> have a 10 month old son taking all my spare time up ;-)
> 
> -Stephen
> 
> On 12 October 2010 17:55, Patrick Aikens  wrote:
>> Thanks for that - it's at least useful in getting a report of which
>> version to put in our pluginManagement section in the parent.  The pom
>> updating doesn't seem to include a goal that will update plugin
>> versions, but given a list we can do that by hand.
>> 
>> On Tue, Oct 12, 2010 at 12:41 PM, kristian  wrote:
>>> try
>>> mvn versions:display-plugin-updates
>>> which should give you an overview. there is more to the plugin and it
>>> does insert the versions where needed with one of its goals.
>>> 
>>> regards Kristian
>>> 
>>> On Tue, Oct 12, 2010 at 10:00 PM, Patrick Aikens  wrote:
 I do agree that from a repeatability standpoint, specifying versions
 for ALL plugins is desirable - but since Maven provides a super-pom
 that everything inherits from we get certain plugins automatically.
 Aside from looking at that pom and basically copying the build.plugins
 section there's no simple way for an end-user to know that you should
 specify version 2.3.2 of the compiler plugin (and repeat that for
 every other default plugin), or even what the list of default plugins
 contains.  Granted, there could be a plugin to add that info to your
 pom... maybe add it to the archetypes and also have a stand-alone mojo
 to add default plugin info to the current project's pom - run that on
 your parent pom and modify as necessary.
 
 My question of which should be the case still stands, though -
 repeatable builds and best practices aside, the way it works today
 Maven will continue to update and you'll silently be using new
 versions of those plugins anyway without warnings when you upgrade.
 The only reason I'm seeing those warnings is because I attempt to
 merge in new configuration to those plugins.  There's inconsistent
 behavior here - either we need to lock down all the plugin versions in
 our own poms (even for default plugins where we use default
 configurations) for repeatability purposes, or we can rely on
 inheriting merged info for those plugins into our overridden
 configurations.  I'm not sure the current state is desirable.  Maybe
 this should go to the dev list since it seems to be more of an
 implementation question?
 
 On Tue, Oct 12, 2010 at 11:47 AM, Paul Benedict  
 wrote:
> Yes, Maven provides default versions, but those are likely to change
> as Maven does future patch releases. To give you a predictable build,
> lock down your plugins so you control what versions are selected.
> 
> Paul
> 
> On Tue, Oct 12, 2010 at 10:27 AM, Patrick Aikens  
> wrote:
>> I've got several projects that provide additional configuration of
>> standard Maven plugins (like the compiler plugin or the jar plugin),
>> most commonly changing the source and target values for the compiler
>> plugin.  Unfortunately, I get the following warnings:
>> 
>> [WARNING] 'build.plugins.plugin.version' for
>> org.apache.maven.plugins:maven-compiler-plugin is missing.
>> [WARNING] 'build.plugins.plugin.version' for
>> org.apache.maven.plugins:maven-surefire-plugin is missing. [WARNING]
>> 'build.plugins.plugin.version' for
>> org.apache.maven.plugins:maven-jar-plugin is missing.
>> 
>> I know (and approve of) Maven 3.0 requiring versions on plugins, but
>> shouldn't these particular plugins have versions specified in the
>> super-pom that get merged into the references in my projects?  Is it
>> expected behavior that to add configuration to these plugins that I go
>> find out which version of the plugin is in the super-pom and add it
>> again?  I can get rid of these warnings by simply putting the
>> appropriate plugin version information in a common parent pom's
>> pluginManagement section, but I'm not sure that I should need to.
>> 
>> It just seems odd that I need to repeat the version info if I add some
>> configuration to the plugin in a project, but another project that
>> just uses the plugin as-is through inheritance from the super-pom
>> works without warnings... it should have warnings in both or neither.
>> 
>> --
>> SELECT * FROM users WHERE clue > 0
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional comm

Re: maven is a swamp

[Kathryn Huxtable]

It does. The rest of the language is rather ugly, though. -K

On Oct 13, 2010, at 9:07 AM, Rick Mangi wrote:

> I just enjoyed the bit about perl having elegant and concise data structures
> :-)
> 
> 
> On 10/13/10 9:57 AM, "chemit"  wrote:
> 
>> Le Wed, 13 Oct 2010 08:58:27 -0400,
>> Ron Wheeler  a écrit :
>> 
>>>  Doing the wrong thing and not using an IDE with a POM editor is not
>>> a good recipe for a smooth development cycle.
>>> I will admit to occasionally editing XML but that is for extreme
>>> cases while you are getting set up..
>>> 
>> euh wrong person :)
>> 
>> You should have respond to previous mail, ... I love maven and all the
>> xml stuff (arch to su much in facts.) I was just responding to the guy
>> Kenneth which seems to be pretty angry with Maven and xml ;)
>> 
>> 
>>> If you don't like XML:
>>> 1) Get your development workflow Mavenized
>>> 2) Get a Maven Repo set up
>>> 3) Restructure your projects to fit the way Maven works
>>> 3) Use an IDE that supports Maven with a proper human oriented editor
>>> - Eclipse STS is very good at this.
>>> 
>>> Then you will have no need of XML editing and no need to screw around
>>> with command line Maven or custom plug-ins or custom goals.
>>> You will not spend a lot of time in this forum moaning about the
>>> unfairness of life and the difficulty of using Maven.
>>> 
>>> Once you start using Maven properly, it is a very high level tool for
>>> building Java applications such as:
>>> Java WebServices
>>> Java Servlets
>>> Java Portlets
>>> Java Standalone applications
>>> 
>>> If you are building something else, my comments may not be relevant.
>>> 
>>> 
>>> Ron
>>> 
>>> 
>>> 
>>> On 13/10/2010 2:47 AM, chemit wrote:
 Le Tue, 12 Oct 2010 19:35:46 -0500,
 Kenneth McDonald  a écrit :
 
> Yes, I realize this is flamebait, but after trying to puzzle out
> the following maven plugin:
> 
> 
> maven-antrun-plugin
> 1.6
> 
> 
> deploy
> deploy-gh-pages
> 
> run
> 
> 
> 
>  location=""/>  
> 
> 
>  dir="${gh-pages-dir}">  
> 
>  dir="${gh-pages-dir}">  
> 
> 
> 
> 
> 
> 
> 
> I simply can't resist. Whoever in their right mind decided software
> developers to think that requiring other developers to write config
> files in XML was a proper decision?
> 
> Python, Ruby, and (yes even Perl) have had had much more elegant
> and concise ways of managing complex data structures for years
> now. And there's a reason JSON has become so popular--primarily
> because XML is not, and was never intended to be, a format for
> developers to write specifications in.
 First of all using the ant plugin is against "Best pratices", so
 for me and from this point, why critisize something when you are
 doing it the wrong way ?
 
> Let's take a look at the most obvious of the problems in the above:
> 
>  location=""/>  
> 
> 
>  dir="${gh-pages-dir}">  
> 
>  dir="${gh-pages-dir}">  
> 
> 
> Now, I'm still very new to maven, but it strikes me that what the
> above is saying is (in Pythonic code, but feel free to convert to
> your own):
> 
> import git
> gh-pages-dir = ""
> git(dir=gh-pages-dir, "add .")
> git(dir=gh-pages-dir, "commit")
> git(dir=gh-pages-dir, "push origin gh-pages")
> 
> I'm sure there are errors in the translation--but I'm equally sure
> that if these errors were corrected, they would not substantially
> alter the ratio of XML to Pythonic code. Ruby and even Perl would
> do just as well.
> 
 but if it is so simple as you say, you should be able to write your
 simply code without any doubt...
 
> So here's a challenge to the (very intelligent) folks at apache.
> Open your minds to the fact that XML is not only the Final
> Solution, but isn't even close to the best solution, and start
> producing some products that are configurable without an entire
> manual in front of oneself. I realize that arriving at an optimal
> solution is not 

Re: naming now that Maven 3 is out..

[Wendy Smoak]

On Wed, Oct 13, 2010 at 10:13 AM, Nayan Hajratwala  wrote:
> Kind of a random thought -- now that Maven 3 is out, are all those "M2" based 
> names going to be changed to "M3", or more preferably a non-version specific 
> name?
>
> i.e. M2_HOME, m2eclipse, etc.?

This was discussed on the dev list a while back, you can check the
archives to see how it turned out.

(m2eclipse is a separate project, its naming wouldn't be decided here.)

-- 
Wendy

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

multimodul and parent pom question

[mremersoncod]

Hi,

we have a multimodul project with a lot of modules. Currently the root-pom of 
the multimodul project is also the parent pom of each submodul project. 
This stroke us quite some time when we made changes in the parent pom regarding 
dependency versions in dependencyManagement or other configuration changes, 
because we could not deploy the pom without building the whole system.

So our idea is to separate the two concerns, namely the configurations (scm/CI 
server/ dependencyManagement / distributionManagement etc) with the module 
information. So the root-pom only has the module information and one of the 
modules is a pom project with all configurations. All other modules use then 
this pom as their parent. With that we could make changes to the parent pom 
without any trouble.

Is this way correct or will it create more trouble ?

Thanks for any advice

 

 

naming now that Maven 3 is out..

[Nayan Hajratwala]

Kind of a random thought -- now that Maven 3 is out, are all those "M2" based 
names going to be changed to "M3", or more preferably a non-version specific 
name?

i.e. M2_HOME, m2eclipse, etc.?


---
Nayan Hajratwala
http://agileshrugged.com
http://twitter.com/nhajratw
734.658.6032


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

Re: maven is a swamp

[Rick Mangi]

I just enjoyed the bit about perl having elegant and concise data structures
:-)


On 10/13/10 9:57 AM, "chemit"  wrote:

> Le Wed, 13 Oct 2010 08:58:27 -0400,
> Ron Wheeler  a écrit :
> 
>>   Doing the wrong thing and not using an IDE with a POM editor is not
>> a good recipe for a smooth development cycle.
>> I will admit to occasionally editing XML but that is for extreme
>> cases while you are getting set up..
>> 
> euh wrong person :)
> 
> You should have respond to previous mail, ... I love maven and all the
> xml stuff (arch to su much in facts.) I was just responding to the guy
> Kenneth which seems to be pretty angry with Maven and xml ;)
> 
> 
>> If you don't like XML:
>> 1) Get your development workflow Mavenized
>> 2) Get a Maven Repo set up
>> 3) Restructure your projects to fit the way Maven works
>> 3) Use an IDE that supports Maven with a proper human oriented editor
>> - Eclipse STS is very good at this.
>> 
>> Then you will have no need of XML editing and no need to screw around
>> with command line Maven or custom plug-ins or custom goals.
>> You will not spend a lot of time in this forum moaning about the
>> unfairness of life and the difficulty of using Maven.
>> 
>> Once you start using Maven properly, it is a very high level tool for
>> building Java applications such as:
>> Java WebServices
>> Java Servlets
>> Java Portlets
>> Java Standalone applications
>> 
>> If you are building something else, my comments may not be relevant.
>> 
>> 
>> Ron
>> 
>> 
>> 
>> On 13/10/2010 2:47 AM, chemit wrote:
>>> Le Tue, 12 Oct 2010 19:35:46 -0500,
>>> Kenneth McDonald  a écrit :
>>> 
 Yes, I realize this is flamebait, but after trying to puzzle out
 the following maven plugin:
 
  
  maven-antrun-plugin
  1.6
  
  
  deploy
  deploy-gh-pages
  
  run
  
  
  
  >>> location=""/>  
  
  
  >>> dir="${gh-pages-dir}">  
  
  >>> dir="${gh-pages-dir}">  
  
  
  
  
  
  
 
 I simply can't resist. Whoever in their right mind decided software
 developers to think that requiring other developers to write config
 files in XML was a proper decision?
 
 Python, Ruby, and (yes even Perl) have had had much more elegant
 and concise ways of managing complex data structures for years
 now. And there's a reason JSON has become so popular--primarily
 because XML is not, and was never intended to be, a format for
 developers to write specifications in.
>>> First of all using the ant plugin is against "Best pratices", so
>>> for me and from this point, why critisize something when you are
>>> doing it the wrong way ?
>>> 
 Let's take a look at the most obvious of the problems in the above:
 
  >>> location=""/>  
  
  
  >>> dir="${gh-pages-dir}">  
  
  >>> dir="${gh-pages-dir}">  
  
 
 Now, I'm still very new to maven, but it strikes me that what the
 above is saying is (in Pythonic code, but feel free to convert to
 your own):
 
 import git
 gh-pages-dir = ""
 git(dir=gh-pages-dir, "add .")
 git(dir=gh-pages-dir, "commit")
 git(dir=gh-pages-dir, "push origin gh-pages")
 
 I'm sure there are errors in the translation--but I'm equally sure
 that if these errors were corrected, they would not substantially
 alter the ratio of XML to Pythonic code. Ruby and even Perl would
 do just as well.
 
>>> but if it is so simple as you say, you should be able to write your
>>> simply code without any doubt...
>>> 
 So here's a challenge to the (very intelligent) folks at apache.
 Open your minds to the fact that XML is not only the Final
 Solution, but isn't even close to the best solution, and start
 producing some products that are configurable without an entire
 manual in front of oneself. I realize that arriving at an optimal
 solution is not really possible, but XML is so suboptimal as to
 beggar belief.
 
 I am just so sick of using crappy "solutions" (read: XML) layered
 over top of what could be good solutions.
 
>>> Yes crappy is 

Re: maven is a swamp

[chemit]

Le Wed, 13 Oct 2010 08:58:27 -0400,
Ron Wheeler  a écrit :

>   Doing the wrong thing and not using an IDE with a POM editor is not
> a good recipe for a smooth development cycle.
> I will admit to occasionally editing XML but that is for extreme
> cases while you are getting set up..
> 
euh wrong person :) 

You should have respond to previous mail, ... I love maven and all the
xml stuff (arch to su much in facts.) I was just responding to the guy
Kenneth which seems to be pretty angry with Maven and xml ;)


> If you don't like XML:
> 1) Get your development workflow Mavenized
> 2) Get a Maven Repo set up
> 3) Restructure your projects to fit the way Maven works
> 3) Use an IDE that supports Maven with a proper human oriented editor
> - Eclipse STS is very good at this.
> 
> Then you will have no need of XML editing and no need to screw around 
> with command line Maven or custom plug-ins or custom goals.
> You will not spend a lot of time in this forum moaning about the 
> unfairness of life and the difficulty of using Maven.
> 
> Once you start using Maven properly, it is a very high level tool for 
> building Java applications such as:
> Java WebServices
> Java Servlets
> Java Portlets
> Java Standalone applications
> 
> If you are building something else, my comments may not be relevant.
> 
> 
> Ron
> 
> 
> 
> On 13/10/2010 2:47 AM, chemit wrote:
> > Le Tue, 12 Oct 2010 19:35:46 -0500,
> > Kenneth McDonald  a écrit :
> >
> >> Yes, I realize this is flamebait, but after trying to puzzle out
> >> the following maven plugin:
> >>
> >>  
> >>  maven-antrun-plugin
> >>  1.6
> >>  
> >>  
> >>  deploy
> >>  deploy-gh-pages
> >>  
> >>  run
> >>  
> >>  
> >>  
> >>   >> location=""/>  
> >>  
> >>  
> >>   >> dir="${gh-pages-dir}">  
> >>  
> >>   >> dir="${gh-pages-dir}">  
> >>  
> >>  
> >>  
> >>  
> >>  
> >>  
> >>
> >> I simply can't resist. Whoever in their right mind decided software
> >> developers to think that requiring other developers to write config
> >> files in XML was a proper decision?
> >>
> >> Python, Ruby, and (yes even Perl) have had had much more elegant
> >> and concise ways of managing complex data structures for years
> >> now. And there's a reason JSON has become so popular--primarily
> >> because XML is not, and was never intended to be, a format for
> >> developers to write specifications in.
> > First of all using the ant plugin is against "Best pratices", so
> > for me and from this point, why critisize something when you are
> > doing it the wrong way ?
> >
> >> Let's take a look at the most obvious of the problems in the above:
> >>
> >>   >> location=""/>  
> >>  
> >>  
> >>   >> dir="${gh-pages-dir}">  
> >>  
> >>   >> dir="${gh-pages-dir}">  
> >>  
> >>
> >> Now, I'm still very new to maven, but it strikes me that what the
> >> above is saying is (in Pythonic code, but feel free to convert to
> >> your own):
> >>
> >> import git
> >> gh-pages-dir = ""
> >> git(dir=gh-pages-dir, "add .")
> >> git(dir=gh-pages-dir, "commit")
> >> git(dir=gh-pages-dir, "push origin gh-pages")
> >>
> >> I'm sure there are errors in the translation--but I'm equally sure
> >> that if these errors were corrected, they would not substantially
> >> alter the ratio of XML to Pythonic code. Ruby and even Perl would
> >> do just as well.
> >>
> > but if it is so simple as you say, you should be able to write your
> > simply code without any doubt...
> >
> >> So here's a challenge to the (very intelligent) folks at apache.
> >> Open your minds to the fact that XML is not only the Final
> >> Solution, but isn't even close to the best solution, and start
> >> producing some products that are configurable without an entire
> >> manual in front of oneself. I realize that arriving at an optimal
> >> solution is not really possible, but XML is so suboptimal as to
> >> beggar belief.
> >>
> >> I am just so sick of using crappy "solutions" (read: XML) layered
> >> over top of what could be good solutions.
> >>
> > Yes crappy is the right world, I sujjest you to go back to
> > MakeFile, no xml, no convention, just... CRAP :)
> >
> >> Sorry, had to vent. Who knows, maybe it'll do some good?
> > And you feel be

Re: Using profiles to change clean behavior of a build

[Ron Wheeler]

 What is so unusual about your workflow that causes this issue in the 
first place.


Can you not refactor your application so that the "permanent" stuff is 
in another project that creates a library that you reference as a 
dependency(provided if possible) so that it is not copied into your target.


If you split your application into smaller independently developed and 
tested units you will solve all kinds of problems.



Ron

On 13/10/2010 9:29 AM, Jolly, Carl wrote:

Hello!

I'm trying to modify the behaviour of a build so that during development
those parts of the target that do not change between builds do not get
wiped out and re-extracted every time as these activities take up most
of the build time. For instance, as part of the build we extract the
java installation inside the target. Currently the maven-clean plugin,
by default, wipes clean the target so this extraction has to happen
every time.  I have come up  with configuration changes that allow
selective deletion of directories within the target and modified the
build. However, I still need to do a complete wipe out and build on
occasion so I need a way to change the clean behavior. My initial
thought was to use a profile so that the command line for a selective
clean and build would be:

mvn clean install

And for my total rebuild it would be

mvn  -P cleanall clean install

I use ( well, try to use) a profile to wipe out all the target then the
selective clean would not really do anything and the build would proceed
as normal only this time the rules, for instance , to  extract the java
would now activate.   The problem is this does not work. The profile
does not activate. Nor do I see how to ensure that it activates before
the build. ( I do not put the build inside of a profile since the
development team is used to 'mvn clean install'. I do not want to have
them specify an additional parameter.) . My pom is organized as below.
In my tests, I have put the profile first (does order in file make a
difference?) but it did not work.  I've put the entire build inside the
cleanall profile but the standard build runs anyway.  Why is this not
working? Surely at the very least I should get both the default build to
run then the profile clean to run or visa versa.  Am I on the right
track or is there a better way
to get the behavior I want?

http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
   4.0.0

   
... stuff here...
   

   
... stuff here ...
   

   
 
 
   
 maven-clean-plugin
 2.4
 
true
   
 
${cuts.dir}
 
  
${project.build.directory}

   **/*


   follett/java/**/*
   follett/jboss/images/*
   follett/jboss/images-test/*

false
  

 
   
   
 
   


   


   
 
   cleanall
   
  

  maven-clean-plugin
  2.4
  
  

  
   
 
   
   
 
 ... dependencies here 

   





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

Re: maven is a swamp

[Ron Wheeler]

 Doing the wrong thing and not using an IDE with a POM editor is not a 
good recipe for a smooth development cycle.
I will admit to occasionally editing XML but that is for extreme cases 
while you are getting set up..


If you don't like XML:
1) Get your development workflow Mavenized
2) Get a Maven Repo set up
3) Restructure your projects to fit the way Maven works
3) Use an IDE that supports Maven with a proper human oriented editor - 
Eclipse STS is very good at this.


Then you will have no need of XML editing and no need to screw around 
with command line Maven or custom plug-ins or custom goals.
You will not spend a lot of time in this forum moaning about the 
unfairness of life and the difficulty of using Maven.


Once you start using Maven properly, it is a very high level tool for 
building Java applications such as:

Java WebServices
Java Servlets
Java Portlets
Java Standalone applications

If you are building something else, my comments may not be relevant.


Ron



On 13/10/2010 2:47 AM, chemit wrote:

Le Tue, 12 Oct 2010 19:35:46 -0500,
Kenneth McDonald  a écrit :


Yes, I realize this is flamebait, but after trying to puzzle out the
following maven plugin:

 
 maven-antrun-plugin
 1.6
 
 
 deploy
 deploy-gh-pages
 
 run
 
 
 
   
 
 
   
 
   
 
 
 
 
 
 

I simply can't resist. Whoever in their right mind decided software
developers to think that requiring other developers to write config
files in XML was a proper decision?

Python, Ruby, and (yes even Perl) have had had much more elegant and
concise ways of managing complex data structures for years now. And
there's a reason JSON has become so popular--primarily because XML is
not, and was never intended to be, a format for developers to write
specifications in.

First of all using the ant plugin is against "Best pratices", so for me
and from this point, why critisize something when you are doing it the
wrong way ?


Let's take a look at the most obvious of the problems in the above:

   
 
 
   
 
   
 

Now, I'm still very new to maven, but it strikes me that what the
above is saying is (in Pythonic code, but feel free to convert to
your own):

import git
gh-pages-dir = ""
git(dir=gh-pages-dir, "add .")
git(dir=gh-pages-dir, "commit")
git(dir=gh-pages-dir, "push origin gh-pages")

I'm sure there are errors in the translation--but I'm equally sure
that if these errors were corrected, they would not substantially
alter the ratio of XML to Pythonic code. Ruby and even Perl would do
just as well.


but if it is so simple as you say, you should be able to write your
simply code without any doubt...


So here's a challenge to the (very intelligent) folks at apache. Open
your minds to the fact that XML is not only the Final Solution, but
isn't even close to the best solution, and start producing some
products that are configurable without an entire manual in front of
oneself. I realize that arriving at an optimal solution is not really
possible, but XML is so suboptimal as to beggar belief.

I am just so sick of using crappy "solutions" (read: XML) layered
over top of what could be good solutions.


Yes crappy is the right world, I sujjest you to go back to MakeFile, no
xml, no convention, just... CRAP :)


Sorry, had to vent. Who knows, maybe it'll do some good?

And you feel better now ?

Ken McDonald


-
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 profiles to change clean behavior of a build

[Jolly, Carl]

Hello! 
 
I'm trying to modify the behaviour of a build so that during development
those parts of the target that do not change between builds do not get
wiped out and re-extracted every time as these activities take up most
of the build time. For instance, as part of the build we extract the
java installation inside the target. Currently the maven-clean plugin,
by default, wipes clean the target so this extraction has to happen
every time.  I have come up  with configuration changes that allow
selective deletion of directories within the target and modified the
build. However, I still need to do a complete wipe out and build on
occasion so I need a way to change the clean behavior. My initial
thought was to use a profile so that the command line for a selective
clean and build would be:
 
mvn clean install
 
And for my total rebuild it would be 
 
mvn  -P cleanall clean install
 
I use ( well, try to use) a profile to wipe out all the target then the
selective clean would not really do anything and the build would proceed
as normal only this time the rules, for instance , to  extract the java
would now activate.   The problem is this does not work. The profile
does not activate. Nor do I see how to ensure that it activates before
the build. ( I do not put the build inside of a profile since the
development team is used to 'mvn clean install'. I do not want to have
them specify an additional parameter.) . My pom is organized as below.
In my tests, I have put the profile first (does order in file make a
difference?) but it did not work.  I've put the entire build inside the
cleanall profile but the standard build runs anyway.  Why is this not
working? Surely at the very least I should get both the default build to
run then the profile clean to run or visa versa.  Am I on the right
track or is there a better way 
to get the behavior I want?  
 
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
  4.0.0
  
  
   ... stuff here...
  
 
  
   ... stuff here ...
  

  


  
maven-clean-plugin
2.4

   true
  

   ${cuts.dir}
 
 
   ${project.build.directory}
   
  **/*

   
  follett/java/**/*
  follett/jboss/images/*
  follett/jboss/images-test/*

   false 
 
   

  
  

  
 

  
 

  

  cleanall
  
 
   
 maven-clean-plugin
 2.4
 
 
   
 
  

  
  

... dependencies here 
   
  

Re: Maven generating invalid eclipse projects

[Antonio Petrelli]

2010/10/13 emerson :
> Does the m2eclipse creates eclipse config from the pom, ina
> multi-module configuration?

it creates one Eclipse project per module, plus the project for the master pom.
And, obviously, the config files.

Antonio

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

Re: Maven generating invalid eclipse projects

[emerson]

> The first step is to run eclipse:eclipse
>
> Then copy the generated files somewhere.
>
> The second step is to manually fix eclipse so that it is how you expect it.
>
> Then copy those files somewhere.
>
> Compare the two and file a bug report
> http://maven.apache.org/plugins/maven-eclipse-plugin/
>
> Better yet, download the source, run a new integration test and then a
> fix for the problem before you submit the bug report.
>
> A lot of people are moving to m2eclipse http://m2eclipse.sonatype.org/.
> There are only a few developers looking at m-e-p.
>

Does the m2eclipse creates eclipse config from the pom, ina
multi-module configuration?

regards
Emerson

On 12 October 2010 07:23, Barrie Treloar  wrote:
> On Mon, Oct 11, 2010 at 10:00 PM, emerson  wrote:
>> Hi
>>
>> I configured a integration test only project, in a way that every
>> module uses a configuration that is stored in the parent folder.
>> I implemented this way:
>>
>> In the parent pom (in the root of the tree):
>>
>>     
>>      local 
>>      ../autotestProperties/
>>    
>>        
>>    
>>      
>>        ${envProps}/resources
>>        true
>>      
>>    
>>    
>>        ${envProps}/env/${envType}.properties
>>    
>>
>> Then each module will get the generated configuration at the classpath.
>>
>> As far as maven goes, it works fine, but when I generate the
>> correspondent eclipse project, it tries to add the resource entry, but
>> all it gets is a incorrect build path entry:
>>
>> "Build path entry is missing:
>> home/emerson/workspace/trunk/autotests/autotestProperties/resources"
>>
>> Is there anyway to stop eclipse from trying to create this entry?
>>
>> The normal use of this will be for the developers and qa to create the
>> project structure using  "maven eclipse:eclipse install -DskipTests"
>> once via maven and then run the tests straight from eclipse.
>

> -
> 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 use m-invoker-p with a IT project that SHOULD fail

[Anders Hammar]

Many thanks! The response time on this one was impressive! :-)

/Anders

On Wed, Oct 13, 2010 at 12:59, Olivier Lamy  wrote:

> Having a file in your it directory called : invoker.properties
> with the content : invoker.buildResult = failure
>
> See
> http://maven.apache.org/plugins/maven-invoker-plugin/run-mojo.html#invokerPropertiesFile
>
> HTH,
> --
> Olivier
> http://twitter.com/olamy
> http://www.linkedin.com/in/olamy
>
>
>
> 2010/10/13 Anders Hammar :
> > For a plugin I have a build case that I want to test that it fails. I'm
> > using the m-invoker-p for my IT projects, but they normal case is that
> they
> > should pass. Has anyone done such a test project which is verified that
> it
> > fails?
> >
> > /Anders
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: How to use m-invoker-p with a IT project that SHOULD fail

[Olivier Lamy]

Having a file in your it directory called : invoker.properties
with the content : invoker.buildResult = failure

See 
http://maven.apache.org/plugins/maven-invoker-plugin/run-mojo.html#invokerPropertiesFile

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



2010/10/13 Anders Hammar :
> For a plugin I have a build case that I want to test that it fails. I'm
> using the m-invoker-p for my IT projects, but they normal case is that they
> should pass. Has anyone done such a test project which is verified that it
> fails?
>
> /Anders
>

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

Re: How to use m-invoker-p with a IT project that SHOULD fail

[chemit]

Le Wed, 13 Oct 2010 12:54:04 +0200,
Anders Hammar  a écrit :

> For a plugin I have a build case that I want to test that it fails.
> I'm using the m-invoker-p for my IT projects, but they normal case is
> that they should pass. Has anyone done such a test project which is
> verified that it fails?
> 
Yes, in the file invoker.properties of your it

change the line 

invoker.buildResult=success

by 

invoker.buildResult=failure
> /Anders



-- 
Tony Chemit

tél: +33 (0) 2 40 50 29 28
email: che...@codelutin.com  
http://www.codelutin.com 

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

How to use m-invoker-p with a IT project that SHOULD fail

[Anders Hammar]

For a plugin I have a build case that I want to test that it fails. I'm
using the m-invoker-p for my IT projects, but they normal case is that they
should pass. Has anyone done such a test project which is verified that it
fails?

/Anders

Re: Need to specify versions of standard plugins in 3.0?

[Stephen Connolly]

http://jira.codehaus.org/browse/MVERSIONS-6 and
http://jira.codehaus.org/browse/MVERSIONS-7 should give what you want
when I get around to writing them...

the blocker for me is having stable integration tests, which depends
on finishing mock-repository-maven-plugin... and swamped in work and I
have a 10 month old son taking all my spare time up ;-)

-Stephen

On 12 October 2010 17:55, Patrick Aikens  wrote:
> Thanks for that - it's at least useful in getting a report of which
> version to put in our pluginManagement section in the parent.  The pom
> updating doesn't seem to include a goal that will update plugin
> versions, but given a list we can do that by hand.
>
> On Tue, Oct 12, 2010 at 12:41 PM, kristian  wrote:
>> try
>> mvn versions:display-plugin-updates
>> which should give you an overview. there is more to the plugin and it
>> does insert the versions where needed with one of its goals.
>>
>> regards Kristian
>>
>> On Tue, Oct 12, 2010 at 10:00 PM, Patrick Aikens  wrote:
>>> I do agree that from a repeatability standpoint, specifying versions
>>> for ALL plugins is desirable - but since Maven provides a super-pom
>>> that everything inherits from we get certain plugins automatically.
>>> Aside from looking at that pom and basically copying the build.plugins
>>> section there's no simple way for an end-user to know that you should
>>> specify version 2.3.2 of the compiler plugin (and repeat that for
>>> every other default plugin), or even what the list of default plugins
>>> contains.  Granted, there could be a plugin to add that info to your
>>> pom... maybe add it to the archetypes and also have a stand-alone mojo
>>> to add default plugin info to the current project's pom - run that on
>>> your parent pom and modify as necessary.
>>>
>>> My question of which should be the case still stands, though -
>>> repeatable builds and best practices aside, the way it works today
>>> Maven will continue to update and you'll silently be using new
>>> versions of those plugins anyway without warnings when you upgrade.
>>> The only reason I'm seeing those warnings is because I attempt to
>>> merge in new configuration to those plugins.  There's inconsistent
>>> behavior here - either we need to lock down all the plugin versions in
>>> our own poms (even for default plugins where we use default
>>> configurations) for repeatability purposes, or we can rely on
>>> inheriting merged info for those plugins into our overridden
>>> configurations.  I'm not sure the current state is desirable.  Maybe
>>> this should go to the dev list since it seems to be more of an
>>> implementation question?
>>>
>>> On Tue, Oct 12, 2010 at 11:47 AM, Paul Benedict  
>>> wrote:
 Yes, Maven provides default versions, but those are likely to change
 as Maven does future patch releases. To give you a predictable build,
 lock down your plugins so you control what versions are selected.

 Paul

 On Tue, Oct 12, 2010 at 10:27 AM, Patrick Aikens  wrote:
> I've got several projects that provide additional configuration of
> standard Maven plugins (like the compiler plugin or the jar plugin),
> most commonly changing the source and target values for the compiler
> plugin.  Unfortunately, I get the following warnings:
>
> [WARNING] 'build.plugins.plugin.version' for
> org.apache.maven.plugins:maven-compiler-plugin is missing.
> [WARNING] 'build.plugins.plugin.version' for
> org.apache.maven.plugins:maven-surefire-plugin is missing. [WARNING]
> 'build.plugins.plugin.version' for
> org.apache.maven.plugins:maven-jar-plugin is missing.
>
> I know (and approve of) Maven 3.0 requiring versions on plugins, but
> shouldn't these particular plugins have versions specified in the
> super-pom that get merged into the references in my projects?  Is it
> expected behavior that to add configuration to these plugins that I go
> find out which version of the plugin is in the super-pom and add it
> again?  I can get rid of these warnings by simply putting the
> appropriate plugin version information in a common parent pom's
> pluginManagement section, but I'm not sure that I should need to.
>
> It just seems odd that I need to repeat the version info if I add some
> configuration to the plugin in a project, but another project that
> just uses the plugin as-is through inheritance from the super-pom
> works without warnings... it should have warnings in both or neither.
>
> --
> SELECT * FROM users WHERE clue > 0
>
> -
> 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: use

Re: Java is a swamp

[Jörg Schaible]

Hi Kenneth,

now, after your mail, I realize that Java is also a swamp, too:

= %< =
import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;
import javax.script.ScriptException;

public class HelloWorld {
  public void main(String[] args) {
ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByName("JavaScript");
engine.put("world", "world");
String result;
try {
  result = (String)engine.eval("'Hello ' + world + '!'");
} catch (ScriptException e) {
  return;
}
System.out.println(result);
  }
}
= %< =

Take a look at the most obvious problems in the above:

= %< =
ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByName("JavaScript");
engine.put("world", "world");
String result;
try {
  result = (String)engine.eval("'Hello ' + world + '!'");
} catch (ScriptException e) {
  return;
}
= %< =

I am very new to Java, but it strikes me that what the above is saying is 
(in shell script):

echo "Hello world!"

I am just so sick of using crappy "solutions" (read: Java) layered over top
of what could be good solutions.

Sorry, I had to vent.

- Jörg


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

Maven 3.0 somertimes gives empty pom files in local repository

[Andreas Gies]

 Hello Maveners

I have recently used maven-3.0-beta-3 to get familar with Maven 3. Now, 
after the release of Maven 3 I have run a couple of builds that
were working with 3.0-beta-3 and now randomly see a strange behavior on 
Windows 7 64bit, Java 1.6-20 (64bit):


It seems that "something" in the build process reduces random pom files 
in my local repository to zero length, so that the next time
maven tries to access the pom file it throws an exception saying that 
the pomo file has no content. deleting the artifact from the local
repository and rerunning the build sometimes succeeds, sometimes fails 
with other pom's being shrunk.


Has anyone seen that kind of behavior with Maven 3 ?

Thanks and best regards
Andreas

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

Invoking a plugin programmatically using maven 3 and scala

[Andreas Gies]

 Hello Maveners ,

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


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

into a rather cryptic error message:

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

d -> [Help 1]

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to 
execute goal com.progress.maven.plugins:plugin-sandbox:8.0-SNAPSHOT:echo 
(default-cl
i) on project test-plugin: The parameters 'project', 'local', 
'remoteRepos', 'reactorProjects' for goal 
org.apache.maven.plugins:maven-dependency-plugin:2.1:unpack-dependencies 
are missing or invalid
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:157)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:88)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:80)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:87)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:315)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginParameterException: The 
parameters 'project', 'local', 'remoteRepos', 'reactorProjects' for goal 
org.apache.maven.plugins:maven-dependency-plugin:2.1:unpack-dependencies 
are missing or invalid
at 
org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields(DefaultMavenPluginManager.java:514)
at 
org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:467)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:96)

at de.woq.maven.plugins.TestMojo.execute(TestMojo.scala:109)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)

... 19 more

It seems that the current project is not passed correctly to the plugin. 
I have noticed that the API for invoking plugins has slightly changed, 
but was unable to get more information.

Any hints where to dig deeper would be greatly appreciated.

For completeness here is the code of my plugin so far  (As I said 
its a learning exercise :))


/*
 * Copyright (C) 2010, Way of Quality
 * All rights reserved.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 
implied.

 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package de.woq.maven.plugins

import org.apache.maven.plugin._
import descriptor.MojoDescriptor
import org.scala_tools.maven.mojo.annotations._
import org.apache.maven.project.MavenProject
import org.apache.maven.execution.MavenSession
import org.apache.maven.model.Plugin

import scala.collection.JavaConversions._
import 

Invoking a plugin programmatically with Maven 3.0-beta

[Andreas Gies]

 Hello Maveners ,

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


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

into a rather cryptic error message:

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

d -> [Help 1]

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to 
execute goal com.progress.maven.plugins:plugin-sandbox:8.0-SNAPSHOT:echo 
(default-cl
i) on project test-plugin: The parameters 'project', 'local', 
'remoteRepos', 'reactorProjects' for goal 
org.apache.maven.plugins:maven-dependency-plugin:2.1:unpack-dependencies 
are missing or invalid
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:157)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:88)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:80)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:87)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:315)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginParameterException: The 
parameters 'project', 'local', 'remoteRepos', 'reactorProjects' for goal 
org.apache.maven.plugins:maven-dependency-plugin:2.1:unpack-dependencies 
are missing or invalid
at 
org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields(DefaultMavenPluginManager.java:514)
at 
org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:467)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:96)

at de.woq.maven.plugins.TestMojo.execute(TestMojo.scala:109)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)

... 19 more

It seems that the current project is not passed correctly to the plugin. 
I have noticed that the API for invoking plugins has slightly changed, 
but was unable to get more information.

Any hints where to dig deeper would be greatly appreciated.

For completeness here is the code of my plugin so far  (As I said 
its a learning exercise :))


/*
 * Copyright (C) 2010, Way of Quality
 * All rights reserved.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package de.woq.maven.plugins

import org.apache.maven.plugin._
import descriptor.MojoDescriptor
import org.scala_tools.maven.mojo.annotations._
import org.apache.maven.project.MavenProject
import org.apache.maven.execution.MavenSession
import org.apache.maven.model.Plugin

import scala.collection.JavaConversions._
import