Potential Maven user overwhelmed - seeks voices of experience

[Gordon Henriksen <go...@mac.com>]

Hello, everyone,

I'm looking to set up some new projects, and Maven looks like an  
absolutely excellent tool except for one thing--I'm afraid of it. :)  
There are so many plugins, so many things this system is capable of,  
yet I can't even figure out a way to get a list of the goals  
supported by the plugins I'm using, aside from spelunking into  
their .jar files. I throw some typical Makefile targets at it and it  
just does something roughly appropriate, and that's cool. But  
sometimes it doesn't know what I'm talking about, and I'm not sure  
how it all gets wired together so I can learn its vocabulary, and  
that scares me. :)

Succinctly, Maven looks like an astoundingly powerful tool that does  
70% of the legwork I'm confronted with in setting up a new source  
tree and development cycle for my team. That's far more than I  
expected of any single product. But I'm simply lost in it.

I'm on a truncated schedule with a lot of new technologies, so  
forgive me a little bit if I'm asking a lot here, but I just want to  
get pointed in the right direction on the items which I view as the  
major requirements for my build and release management toolset. I'm  
reviewing the mailing list, I'm looking at all the docu I can find,  
but I haven't gotten the traction to make everything click in my head  
yet (or even to confirm that Maven's going to be the magic bullet it  
seems to be for so many problems). I should probably break this out  
into several threads so that it's more digestible. C'est la vie.


1. ECLIPSE -
Where do I look for integration with the IDE? Refactoring and code  
completion tools are simply too important to ignore, but Eclipse  
doesn't seem nearly smart enough to pick up the entire build ball and  
run with it, so it seems the IDE integration game becomes one of  
pushing .classpath and so-forth files from a "real" build engine into  
Eclipse, plus having Eclipse swiftly kick off builds on demand.  
Ideally, automatic builds would really work, but nothing seems to  
integrate tightly enough with Eclipse that this seems practical.  
Also, any ability for junior developers to rely on automatic build is  
very concerning, not only because it's an unofficial build engine  
doing the build, but also because Eclipse isn't likely to kick off  
unit tests. It also concerns me somewhat that Maven takes several  
seconds to build an empty project from the command line; ant is  
painfully slow enough on its own.

2. SMOOTH WEB DEV CYCLE -
I'm looking to make sure that web development is as smooth and  
dynamic as possible. ASP.NET 2 is essentially what I'm looking for;  
the app server has fully automatic compilation of even source files;  
eliminates the need for almost all web server configuration in  
preference to directory-local application configuration; and uses  
fast, reliable dependency analysis and recompilation based on  
filesystem change notifications. I'm very concerned that my coworkers  
would be frustrated by a long build, deploy, and reload cycles,  
coming as they are predominantly from a PHP background, where changes  
are essentially free.

In the source tree I was setting up before discovering Maven, I was  
actually placing my web applications in an "exploded EAR" format that  
my application server happened to grok, then pointing the app server  
directly at that. This got me free compilation of .java files, and  
eliminated any "link" or "deploy" steps, but it left no room in the  
source tree for files that should not contribute to the application  
such as Maven/ant/make configurations, developer documentation, unit  
tests, temp files, or final outputs.

3. EASY SETUP OF SANDBOX -
Maven has this solved for Java programs and libraries, and even for  
single web applications, but I'm looking at web applications back- 
ended by independent web services. So there's a significant potential  
for arduous configuration of the application server (which needs to  
know where the apps are) and web applications (which need to know  
where the services are) that I want to strive to minimize.

While I'm working on killerapp 3.5 and killerservice 3.1, if a bug  
crops up in killerapp 3.0.2, it's of some help if Maven lets me  
swiftly check out and build killerapp 3.0.3-SNAPSHOT and its  
dependency on killerservice 3.0, but if I'm still stuck reconfiguring  
Eclipse, and my app server, and killerapp (to talk to the new  
instance of killerservice), then I still have a major impediment.  
That same impediment applies equally to: setting coworkers, and: the  
addition of new services or applications, and: when performing  
integration testing (be they manual or automatic).

That said, I'm not sure this is something I'm going to be able to  
eliminate, but I'd love to hear any suggestions people might have.

4. UNIT TESTING -
Great, the skeleton adds this to .jar files and runs them  
automatically and everything. Can I add it to a web app, too? (Note  
conflict with earlier requests for fully dynamic web application  
development. Realistically, it's one or the other, but I'm not sure I  
can get either at this point, so I'm researching both.)

5. CONTINUOUS INTEGRATION -
Is there a product that gets along with Maven? I'd like on-demand  
builds. Not really so picky, here, so long as it can check my source  
code out from scratch, run the build script, build automatically on  
some schedule, build on demand, and archive outputs.

I've heard lots of hype around it, but I came to the conclusion that  
CruiseControl was a sad joke after actually examining it. Great, you  
can turn on a lamp via X10 when the build breaks. But CC seems like a  
simple solution to set up for an individual open source project, but  
simply unrealistic for enterprise software. It completely omits  
elements such as build promotion and subsequent integration testing.  
Which leads me to…

6. BUILD PROMOTION & INTEGRATION TESTING -
Ultimately, we're writing web applications back-ended by web  
services. We do not expect to redeploy the whole stable of web  
services every time; each application or service will potentially be  
up for independent release. So therefore, a build of an application  
or service implies new integration testing against the versions it  
would be *deployed* against, *not* the versions that happen to be on  
trunk. My intuitive concept of this would be promoting builds into a  
series of tiers:

     just a build, passes developer testing
     bronze build, passes QA functional & integration testing
     silver build, passes systems group testing
     golden build, gets released

Each promoted build would coexist with a stable of others at each  
tier. Integration testing would occur across an entire tier. There  
would be artifacts and limitations to that approach; basically, only  
one release candidate could be under promotion at a time, but I don't  
see another manageable and comprehensible model that deals with the  
dependency inversion when a service is updated and integration  
testing needs to be performed for all its clients. Plus, it lends  
itself to corresponding test databases.

Anyhow, this doesn't seem something that Maven would get along with  
directly, because of those limitations (which are fine for even a  
midsize development team, but not okay for an universe of projects).  
Is there any support extant for this type of testing, or is this an  
area where we need to roll our own? I'd like to have continuous  
integration tests run subsequent to successful builds, or to build  
promotion (i.e., by the integration server, even though an  
integration test is rather different from a typical project), and be  
accessible to developers.


That's a lot that I'm curious about, and I realize it's counter to  
standard practices for effective pleading on a mailing list to put  
out so much unfocused content. So thank you to anybody who bothered  
to plow through all of that and still has any suggestions to share.

TIA,

Gordon "Call me Warnock!" Henriksen
gordonhenriksen@mac.com

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

Re: Potential Maven user overwhelmed - seeks voices of experience

[Wayne Fay <wa...@gmail.com>]

> I'm on a truncated schedule with a lot of new technologies, so

This is a bad recipe for a successful first-time use of any new
technology, and Maven in particular since it is an open-source tool
and many users complain about the documentation lately.

If you have an existing build process that handles all of your
requirements, you might want to look into a parallel process with M2
so you can see how much of your build etc is possible in Maven without
actually committing to it for the entire team.

I'm just not a fan of trying something for the first time on a big
important project involving lots of people!

> 4. UNIT TESTING -
> Great, the skeleton adds this to .jar files and runs them
> automatically and everything. Can I add it to a web app, too? (Note

There's nothing stopping you from using JUnit with web apps. But I
imagine you're going to want to use something like HttpUnit or JUnitEE
or Canoo to actually test the webpages themselves (perhaps after
deploying them via Cargo), and I haven't gotten there myself yet. Nor
have I succeeded with deploying EJBs using OpenEJB or similar for ejb
testing, but I'm sure I'll get there eventually. (I have spent less
time on these issues than others.)

> 5. CONTINUOUS INTEGRATION -
> Is there a product that gets along with Maven? I'd like on-demand

Take a look at Maven's sister project, Continuum [1]. But I don't
think it will help you with promoted builds etc.

[1] http://maven.apache.org/continuum

HTH.
Wayne

Re: Potential Maven user overwhelmed - seeks voices of experience

[Milos Kleint <mk...@gmail.com>]

On 3/19/06, Gordon Henriksen <go...@mac.com> wrote:
> 1. ECLIPSE -
> Where do I look for integration with the IDE? Refactoring and code
> completion tools are simply too important to ignore, but Eclipse
> doesn't seem nearly smart enough to pick up the entire build ball and
> run with it, so it seems the IDE integration game becomes one of
> pushing .classpath and so-forth files from a "real" build engine into
> Eclipse, plus having Eclipse swiftly kick off builds on demand.
> Ideally, automatic builds would really work, but nothing seems to
> integrate tightly enough with Eclipse that this seems practical.
> Also, any ability for junior developers to rely on automatic build is
> very concerning, not only because it's an unofficial build engine
> doing the build, but also because Eclipse isn't likely to kick off
> unit tests. It also concerns me somewhat that Maven takes several
> seconds to build an empty project from the command line; ant is
> painfully slow enough on its own.

it's probably only the first build that is slow. it download the
various plugins, their dependencies etc. Next build should be fairly
fast.  I have cca 10 projects, with unit test (few) and a clean build
takes under 30 seconds.

milos

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