You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Joshua ChaitinPollak <jp...@kivasystems.com> on 2008/03/21 22:28:33 UTC
Real World User Issues with Maven
We've been living with parallel Ant and Maven build systems for 6 to 9
months now, and most developers are mostly onto Maven, but some still
use Ant from time to time.
I just polled the rest of my development team for who still uses our
ant build system and why.
So Maven core developers, Here are some of the reasons I heard:
1) I can't do the equivalent of ant -projecthelp
Pointing out that all the common maven commands are documented on the
wiki doesn't seem to alleviate this concern, which I admit really
puzzles me. Has anyone else encountered this complaint about maven? I
think the ability to easy get a list of configured plugins within the
pom would be really handy.
2) We have lots of ant run-* targets I like to use.
My response: Letting them know of the mvnrun script I've checked into
our source tree that effectively runs the following:
mvn compile exec:java $MVNOPT -Dexec.mainClass="$CLASSNAME" -
Dexec.args="$ARG"
This allows the user to type:
mvnrun MyMainClass --args
The script searches for the MyMainClass.java file, figures out the
full package name, and fills in the parameters above.
3) We use the ant tags target to run etags to create emacs TAGS files
I pointed these developers to a mktags script that does the same
thing. I also added 'mvn generate-sources' to the script first, to
make sure the tags catch those generated java files.
Just some feedback,
Josh
--
Joshua ChaitinPollak | Software Engineer
Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970
Re: Real World User Issues with Maven
Posted by Patrick Moore <pa...@amplafi.com>.
Hi Wendy --
On Fri, Mar 21, 2008 at 8:00 PM, Wendy Smoak <ws...@gmail.com> wrote:
> On Fri, Mar 21, 2008 at 7:29 PM, Patrick Moore <pa...@amplafi.com>
> wrote:
>
> > 1. "mvn deploy" on the top level - I only want to deploy the war (which
> is
> > in the 'web' module). Mvn deploys everything. Not at all obvious how to
> > change that behavior. Rather than spend any more time on this issue, I
> just
> > cd to the web module and run mvn there. Shouldn't have to do it ...
> easy to
> > do something like this with ant. mvn makes it impossible(?).
> >
> > 2. Connection goes down while deploying. "mvn deploy" rebuilds
> everything
> > (when it works - a lot of times there is some corruption in one of its
> > metadata files?) So most of the time I just scp up the war myself.
>
> Sounds like you might want Cargo (or a Tomcat|JBoss|Geronimo plugin)
> rather than the deploy plugin.
>
> 'mvn deploy' means deploy to the remote _artifact_ repository, not to
> an app server.
>
Actually I have used maven since the maven 1.x days....
Yeap ... I am deploying to the remote artifact directory which is the
production box. From the remote repo, a quick 'cp' and cycle tomcat.
--
Patrick Moore
Amplafi
Re: Real World User Issues with Maven
Posted by Wendy Smoak <ws...@gmail.com>.
On Fri, Mar 21, 2008 at 7:29 PM, Patrick Moore <pa...@amplafi.com> wrote:
> 1. "mvn deploy" on the top level - I only want to deploy the war (which is
> in the 'web' module). Mvn deploys everything. Not at all obvious how to
> change that behavior. Rather than spend any more time on this issue, I just
> cd to the web module and run mvn there. Shouldn't have to do it ... easy to
> do something like this with ant. mvn makes it impossible(?).
>
> 2. Connection goes down while deploying. "mvn deploy" rebuilds everything
> (when it works - a lot of times there is some corruption in one of its
> metadata files?) So most of the time I just scp up the war myself.
Sounds like you might want Cargo (or a Tomcat|JBoss|Geronimo plugin)
rather than the deploy plugin.
'mvn deploy' means deploy to the remote _artifact_ repository, not to
an app server.
For new users the Maven terms 'repository' and 'deploy' cause
confusion since they already have meanings, usually referring to
things like 'the Subversion repository' and as mentioned, deploying to
test or production application servers.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Real World User Issues with Maven
Posted by Stuart McCulloch <mc...@gmail.com>.
On 21/03/2008, Patrick Moore <pa...@amplafi.com> wrote:
>
> Comments....
>
> On Fri, Mar 21, 2008 at 5:07 PM, Brian E. Fox <br...@reply.infinity.nu>
> wrote:
>
> > >2) We have lots of ant run-* targets I like to use.
> > >My response: Letting them know of the mvnrun script I've checked into
> > >our source tree that effectively runs the following:
> >
> > I think the exec plugin can do something similar.
> >
>
> Hmmmm ... "I think" ... you don't know. Hmmm... says it all ...
hey, let's keep things civil - I often start sentences with "I think" out of
habit :)
--
Cheers, Stuart
Re: Real World User Issues with Maven
Posted by Patrick Moore <pa...@amplafi.com>.
Comments....
On Fri, Mar 21, 2008 at 5:07 PM, Brian E. Fox <br...@reply.infinity.nu>
wrote:
> Thanks for the feedback Joshua, a few comments below:
>
> >1) I can't do the equivalent of ant -projecthelp
> >Pointing out that all the common maven commands are documented on the
> >wiki doesn't seem to alleviate this concern, which I admit really
> >puzzles me. Has anyone else encountered this complaint about maven? I
> >think the ability to easy get a list of configured plugins within the
> >pom would be really handy.
>
> The exact equivalent is nearly impossible since technically it's any
> plugin that is in any repo you have configured. (m2e lets you find this
> via the index) If they just want to know the list of phases, I guess
> that could be added to the -? Output. Is there something more they want?
You are letting perfection get in the way of "good enough". Just list out
the help of all plugins explicitly referred to in the pom is a huge win.
Chances are that if a plugin is not configured in the pom the person doesn't
care about it.
If a plugin isn't mentioned in the pom then just indicate in the help
message that there are other plugins available. If the person keeps asking
for help about a plugin (explicitly referenced or not) then start including
that in the default help for that user. A simple '.m2/.help-history' file
should be enough. If they keep asking for detailed help about one plugin
have that listed first.
Also a good idea - tie in the wiki to the mvn command line. Have an option
that displays help on cmd line but also launches browser to display local
help with a link back to the wiki.
>
> >2) We have lots of ant run-* targets I like to use.
> >My response: Letting them know of the mvnrun script I've checked into
> >our source tree that effectively runs the following:
>
> I think the exec plugin can do something similar.
>
Hmmmm ... "I think" ... you don't know. Hmmm... says it all ...
> Hopefully we get some more input on this thread about other issues.
>
>
More work on making simple problems simple. If something takes 3 lines in a
shell script it shouldn't be impossible in mvn. For example (latest beef):
1. "mvn deploy" on the top level - I only want to deploy the war (which is
in the 'web' module). Mvn deploys everything. Not at all obvious how to
change that behavior. Rather than spend any more time on this issue, I just
cd to the web module and run mvn there. Shouldn't have to do it ... easy to
do something like this with ant. mvn makes it impossible(?).
2. Connection goes down while deploying. "mvn deploy" rebuilds everything
(when it works - a lot of times there is some corruption in one of its
metadata files?) So most of the time I just scp up the war myself.
So suggestions using deploy plugin as an example:
- each discrete deploy step should be a separate goal.
- each discrete deploy step should have a 'start-with' ability
- if a deploy step fails the plugin should say 'fix this problem and
do a "mvn deploy:start-with-foo" to continue the deployment'
RTFM = users who are eager to replace the product. You want the manual to be
*optional*. That is the sign of a kick-ass product. But it is very hard.
I wish you good luck!
--
Patrick Moore
Re: Real World User Issues with Maven
Posted by Joshua ChaitinPollak <jp...@kivasystems.com>.
Thanks to everyone who replied, I justed wanted to point out some
issues with switching to Maven, since the developers asked what
complaints Maven evangelists were seeing.
On Mar 21, 2008, at 8:07 PM, Brian E. Fox wrote:
> Thanks for the feedback Joshua, a few comments below:
>
>> 1) I can't do the equivalent of ant -projecthelp
>> Pointing out that all the common maven commands are documented on the
>> wiki doesn't seem to alleviate this concern, which I admit really
>> puzzles me. Has anyone else encountered this complaint about maven? I
>> think the ability to easy get a list of configured plugins within the
>> pom would be really handy.
>
> The exact equivalent is nearly impossible since technically it's any
> plugin that is in any repo you have configured. (m2e lets you find
> this
> via the index) If they just want to know the list of phases, I guess
> that could be added to the -? Output. Is there something more they
> want?
I completely agree that the exact equivalent isn't possible, but most
plugins do have a 'usage' page on their own Maven generated homepages
- is that usage page in the pom? Maybe Maven could have a help
functionality that renders that help to the console, or if not, a way
to call a displayHelp() function of the plugin could be added.
Patrick's suggestion of diplaying the help of configured plugins in
the pom would go a long way, most (all?) plugins used regularly end up
getting configured in the pom anyway.
I could imagine something like svn's help:
mvn help test
But hell, the 'and -projecthelp' output is hand written by the build
system maintainer directly in the build.xml, why not add a
<projecthelp> tag to the pom file? It could get generated when mvn
site is run and displayed when mvn projecthelp is called (oh-> Does
that mean it could be a plugin?)
<projecthelp>
Use our project blah blah like this....
mvn -Dtest=MyCoolTest test
or use our helper:
./bin/mvntest MyCoolTest
</projecthelp>
>> 2) We have lots of ant run-* targets I like to use.
>> My response: Letting them know of the mvnrun script I've checked into
>> our source tree that effectively runs the following:
>
> I think the exec plugin can do something similar.
As I said, (sorry, I wasn't clear), I wrote a mvnrun shell script that
simplifies the command line required by the exec plugin, for example,
in our source tree:
./bin/mvnrun MyCoolMainClass --a=1 --b=2
is the equivalent of:
mvn -Dexec="com.whatever.MyCoolMainClass" -Dexec.args="--a=1 --b=2"
>> 3) We use the ant tags target to run etags to create emacs TAGS files
>> I pointed these developers to a mktags script that does the same
>> thing. I also added 'mvn generate-sources' to the script first, to
>> make sure the tags catch those generated java files.
>
> The tags target could also be wrapped in an ant based plugin.
Yeah, I figured the ant target we have was just calling a shell
script, so why not cut out ant and go straight to the script.
--
Joshua ChaitinPollak | Software Engineer
Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970
RE: Real World User Issues with Maven
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Thanks for the feedback Joshua, a few comments below:
>1) I can't do the equivalent of ant -projecthelp
>Pointing out that all the common maven commands are documented on the
>wiki doesn't seem to alleviate this concern, which I admit really
>puzzles me. Has anyone else encountered this complaint about maven? I
>think the ability to easy get a list of configured plugins within the
>pom would be really handy.
The exact equivalent is nearly impossible since technically it's any
plugin that is in any repo you have configured. (m2e lets you find this
via the index) If they just want to know the list of phases, I guess
that could be added to the -? Output. Is there something more they want?
>2) We have lots of ant run-* targets I like to use.
>My response: Letting them know of the mvnrun script I've checked into
>our source tree that effectively runs the following:
I think the exec plugin can do something similar.
>3) We use the ant tags target to run etags to create emacs TAGS files
>I pointed these developers to a mktags script that does the same
>thing. I also added 'mvn generate-sources' to the script first, to
>make sure the tags catch those generated java files.
The tags target could also be wrapped in an ant based plugin.
Hopefully we get some more input on this thread about other issues.
--Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Real World User Issues with Maven
Posted by Joshua ChaitinPollak <jp...@kivasystems.com>.
On Mar 23, 2008, at 8:20 PM, Siarhei Dudzin wrote:
> Just a few ideas...
>
> * In *my* opinion, the idea of having an equivalent of ant -P or a
> readme.txt defeats the whole idea of maven as it uses *standard* build
> lifecycle. People need to be made aware of that.
That's true, up to a point, however, maven doesn't have standard ways
of running specific unit tests (well, it doesn't but its too
cumbersome), running specific main functions, etc. Just walking people
through the basic phases and common plugins is one thing, but in any
large project there is inevitably some things that need to be
customized.
>
> * Of course there is a learning curve, give them an introduction
> presentation so that they understand what they are doing when they
> just type
> in mvn install or something like that
Yup, done that, but our development crew has doubled, so its probably
time to do it again.
> * To reduce number of complaints all builds should be able to run with
> *zero* manual configuration. To achieve that use defaults parent poms,
> distribute settings.xml (and keep them up to day) and use standard
> ways of
> working (again - communicate that)
Yeah, I'm with you on that one, in fact, right now we have no requires
settings.xml settings, unless you need to deploy to the shared
repository.
> and finally if people refuse to learn you have a bigger than maven
> problem
> on your hands :)
Yeah, its called getting our releases out on time.
--
Joshua ChaitinPollak | Software Engineer
Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970
Re: Real World User Issues with Maven
Posted by Siarhei Dudzin <si...@gmail.com>.
Just a few ideas...
* In *my* opinion, the idea of having an equivalent of ant -P or a
readme.txt defeats the whole idea of maven as it uses *standard* build
lifecycle. People need to be made aware of that.
* Of course there is a learning curve, give them an introduction
presentation so that they understand what they are doing when they just type
in mvn install or something like that
* To reduce number of complaints all builds should be able to run with
*zero* manual configuration. To achieve that use defaults parent poms,
distribute settings.xml (and keep them up to day) and use standard ways of
working (again - communicate that)
and finally if people refuse to learn you have a bigger than maven problem
on your hands :)
Re: Real World User Issues with Maven
Posted by Graham Leggett <mi...@sharp.fm>.
Joshua ChaitinPollak wrote:
> I just polled the rest of my development team for who still uses our ant
> build system and why.
One view from the maven side - one thing the ant people should never do,
is hold your release procedures to ransom.
We have a large project that has as one of its core deliverables rapid
release turnaround time. Using the maven release plugin, a complete
release is achieved using two commands[1] in under twenty minutes[2].
If the addition of ant forces you to have to jump through additional
hoops to get your code released, then ant has become a liability to the
project and needs to be fixed.
[1] mvn release:prepare followed by release:perform.
[2] Some people have expressed surprise that a release could take "as
long as twenty minutes". A little digging usually reveals that their
"release" means copy a jar from some untraceable working copy on some
developer's machine, and put that into production, and that is it.
In maven-land, "prepare the release" means to sanity check the working
copy for incomplete checkins, build and run unit tests to prove that
there is any point in releasing at all, tag the release in source
control, and bump the version numbers in the poms as appropriate.
"perform the release" means to check out the tag pristine from source
control (this can take a while), build the code, upload the code to the
maven repository, build the documentation, upload the documentation to
the website hosting the documentation.
I have never encountered an ant script used in the wild that did a
fraction of this at release time.
Regards,
Graham
--
RE: Real World User Issues with Maven
Posted by "P'Simer, Dana (Matrix)" <Da...@ihg.com>.
It sounds like you are struggling with some of the same issues I am. I
was asked recently to change our build system from ant to maven. In
fact, I did not want to use maven. I felt that our needs did not
warrant it and thought that Ivy would do well to solve our biggest
problem, dependency management. I have since changed my mind and feel
that the move to maven was a good one.
When someone tells me to go work with a new technology, the first thing
I do is learn everything I can about it. So I read "Better Builds with
Maven" and I read the POM and Settings reference on the web site and I
started researching plugins and what they do for us.
Now, I work on a team of developers that puts out a framework that the
client applications use to access business services ( standard stateless
session fascade interface implemented in a Spring container using
hibernate and some ejb services provided by another group on the back
end ), so when I was tasked with switching to maven it was for the
framework, not all the client apps.
I assumed that other engineers on the client teams ( they were all made
aware of the schedule for the transition ) would pick up maven, like I
did, and learn it and start asking questions pertaining to how to
integrate the framework with their new maven builds ( we use AspectJ to
instrument the client code so our integration is a little more complex
then a simple dependency. )
What I got was a bunch of questions about how to use maven. I kept
having to explain to people what plugins are and how to configure them.
How maven inheritance works and how it is unrelated to multi module
builds. How properties can be used to trigger profiles. What profiles
are good for and what they are not good for. Keep in mind I have only
been using this tool for a few months and I would not call myself an
expert by any streatch of the imagination. I have also been hearing a
lot of compaints. Some from the developers but a bunch from management.
Mostly, I think, because the developers are blaming maven for delays.
The blame really should be put on the fact that they did not bother to
learn maven.
So, I think the barrier to adopting maven in my organization is the
learning curve and it sounds like the same thing in yours.
I also have some comments below:
> -----Original Message-----
> From: Joshua ChaitinPollak [mailto:jpollak@kivasystems.com]
>
> We've been living with parallel Ant and Maven build systems
> for 6 to 9 months now, and most developers are mostly onto
> Maven, but some still use Ant from time to time.
>
> I just polled the rest of my development team for who still
> uses our ant build system and why.
>
> So Maven core developers, Here are some of the reasons I heard:
>
> 1) I can't do the equivalent of ant -projecthelp Pointing out
> that all the common maven commands are documented on the wiki
> doesn't seem to alleviate this concern, which I admit really
> puzzles me. Has anyone else encountered this complaint about
> maven? I think the ability to easy get a list of configured
> plugins within the pom would be really handy.
>
Until a "fix" is available from the maven team, maybe maintain a
readme.txt in the directory next to each POM.
> 2) We have lots of ant run-* targets I like to use.
> My response: Letting them know of the mvnrun script I've
> checked into our source tree that effectively runs the following:
>
> mvn compile exec:java $MVNOPT -Dexec.mainClass="$CLASSNAME" -
> Dexec.args="$ARG"
>
> This allows the user to type:
>
> mvnrun MyMainClass --args
>
> The script searches for the MyMainClass.java file, figures
> out the full package name, and fills in the parameters above.
>
> 3) We use the ant tags target to run etags to create emacs
> TAGS files I pointed these developers to a mktags script that
> does the same thing. I also added 'mvn generate-sources' to
> the script first, to make sure the tags catch those generated
> java files.
>
A plugin that generates this would be great. But a in the meantime you
could use the antrun plugin to get the tags generated with each compile.
If you add it to a profile, then developers that don't use the tags
files can turn it off in their settings.xml.
Dana H. P'Simer
Dana.P'Simer@ihg.com