Phil Housley wrote:
On 16 March 2010 03:08, Ron Wheeler <rwhee...@artifact-software.com> wrote:
Phil Housley wrote:
On 15 March 2010 22:29, Ron Wheeler <rwhee...@artifact-software.com>
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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
