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.
>> 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 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
--
Phil Housley
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
