Thiessen, Todd (Todd) wrote:
Interesting conversation. Let me add my two cents.
We do not yet have an aggregation POM that will build
everything and deploy the whole mess in a shot but that
should not be difficult to construct.
This statement is golden although I disagree with the "build everything" part. Each
artifact, whether it be jar, war, is only built once. Any projects that need to include any of
these artifacts simply reference them as a dependency. It is not built again. Our end goal is that
the "mother" build simply pulls down already built artifacts and packages them up as
appropriate. This mother build is thus very fast as it does little to no compiling.
You are right and that is what I would like to have.
It is not a big issue but is getting bigger every day as we add more WAR
files to our portal.
We have tended to build a lot of single purpose WARs with shared
libraries rather than a small number of multi-purpose WARs.
These are all versioned and deployed to a Nexus repository so I am only
missing an aggregation that build me a giant tar or rar that can be
shipped to the server and dropped into an unsuspecting Tomcat. There is
no need for building the WAR's again. They should be ready to go.
Ron
It works wonderfully.
There was a comment in this conversation that Maven doesn't seem to do well in
this situation and that a custom lifecycle is required (I believe Phil made the
comment). I don't see this myself but perhaps I didn't fully understand the
comment.
-----Original Message-----
From: Ron Wheeler [mailto:[email protected]]
Sent: Tuesday, March 16, 2010 9:04 AM
To: Maven Users List
Subject: Re: Best practices
Phil Housley wrote:
On 16 March 2010 03:08, Ron Wheeler
<[email protected]> wrote:
Phil Housley wrote:
On 15 March 2010 22:29, Ron Wheeler
<[email protected]>
wrote:
Am I missing something?
There seem to be a lot of people who try to incorporate jar
projects into master projects and deploy with the "Big
Bang" Theory
- Get everything "all right" and deploy the whole mess.
They seem to generate a lot of problems for themselves.
Is it not a better idea to build projects for your libraries
separately, test them, deploy them on their own and then
use them
as dependencies in the same way that one uses dependencies from
third parties?
You are generally right about the best practice - modular
development is almost always a good idea, but I doubt you
would find
a way to significantly cut down on the traffic here, as there are
definitely a lot of special cases, as I know only too well.
I would like to know what they are.
Well, my example recently was a multi-module project where there is
simply no concept of deploying a single module - the whole thing is
required be pushed together, but as separate artifacts to the same
place, rather than the standard method of wrapping up
everything into
one output artifact.
Other things I have had to do in the past include
horrible variant
builds for different app servers. Creating self contained
runnables
for different systems is another fairly common but very
varied issue
(scripts/shaded jars/etc.) None of these are about
creating generally
reusable libraries, but they are all software build use cases.
Also, managing lots of completely independent pieces of
code is hard
work. Even Maven itself is several modules combined into
a project,
so that a single command can build/deploy lots of pieces at once.
When synchronizing releases across modules, this is really an
obvious win.
We have to manage about 80 3rd part libraries and we have
started to
accumulate our own libraries into projects that we have to
manage and
synchronize with deliverables.
It requires a bit of brain power(self discipline) but does not
require a special maven plug-in.
We use proper version control with snapshots and releases.
I hope that by now most heavy Maven users think like this, there is
hopefully enough documentation to encourage it. However, building
applications is not the same as creating libraries. We maintain a
pile of libraries, and go through all the mass of branching and
tagging required (with release plugin help) to look after lots of
separate releases, but then there are projects which are always
synchronized, so the pieces are kept together, through
trunk -> branch
-> tag (think like the central parts of Maven, which I notice are
actually built partly with Ant.)
There are some definite patterns that Maven makes work well, and
maybe collecting these together would be help to people. For
example, the pattern of project/{core,web-app,cli-app}, or
project/{ejbs,utils,web-app,ear-app}.
I was hoping to get a comprehensive list of standard
products based
on my initial list.
There can not be too many things that people want to build.
I think there are a lot more things than I would like to
imagine, but
a list of common patterns, or possibly of meta-patterns,
would be no
bad thing.
I think that it would really accelerate the adooption of
Maven by givin people a series of project strategies that
they could use to get started.
And indeed considering these patterns can help with
abstracting out
some other cases, but there will always be some things
that will be
more complicated. My case involves something like one of
the above
patterns, but with custom deployment requirements, and
several new
packaging types, it can't be made to map neatly into a
simple "build
the parts, then assemble" pattern - so I came here and
asked for help.
What sort of custom deployment and package types. Can you
elaborate a
bit further?
I don't want to repeat myself here, as that would drag this
thread off
topic some way, but basically the situation is several
modules which
are logically independent (can be built independently) but must be
deployed as a single unit, i.e. they have no general use
outside the
project. The modules are built with a custom lifecycle, and
deployment is a custom process to upload to a tracker. A
multi-module build would be the logical way to proceed, so that the
entire release can be built and deployed together, but multimodule
means <packaging>pom</packaging>, and so no option of a custom
lifecycle, and so it would be incorrect to invoke "mvn
deploy", even
though that sounds like the right command.
None of this seems that complicated, but it is an edge case that it
turns out Maven can't directly handle.
This is pretty much our state with a JSR-168 portal and its
portlets that are all separate WARs that only make sense when
run as a single deployment.
We do package up libraries that are shared (DAO, Messaging, facades,
etc) into separate maven projects and deploy them to a Nexus
server with what I hope is an appropriate SNAPSHOT and version policy.
Of course, we manage the source control with branches and tags.
We use a parent pom to unify the project a bit and reduce the
complexity of the project poms.
We deploy some of the libraries into the servlet container's
shared library (Tomcat) so those are flagged as provided in
the project poms.
We do not yet have an aggregation POM that will build
everything and deploy the whole mess in a shot but that
should not be difficult to construct.
This is a good place to ask for help since the quality and
depth of
expertise is a very good.
I just have this nagging feeling that a lot of the responses are
direct responses to the question asked rather than
guidance towards
"Best Practices" that might be much better answers in the long run.
Have to agree about the first part, and on the second to
some extent
too, but I think really you would just be getting the all round
benefits that come with increasing user documentation,
rather than a
magic bullet. That doesn't stop it a being a good idea though.
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
