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
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
