On 19/10/2015 1:51 PM, Patrick Sansoucy wrote:
Re,
The installer concept *could* fit the bill with some adjustments, it's just
that the build process is tweaked dependending on the target web
server/deployement type.
Wouldn't the installer get rid of the tweaks?
Are there any in the actual software or are they in configuration files
and library inclusion/exclusion
If it was up to me, I would stop building a jar that included all the
shared libraries (use scope "provided") and use the installer to add the
shared libraries at installation time if the system administrator wanted
them.
- reduces build time
- makes jars really small
- allows more flexibility in presenting the system administrator with
choices about which libraries are loaded onto the server with your
software.
This would require changes which I don't have much
weight to throw at.
Benefits should get developers and customer support on your side.
It is sometimes hard to get developers who have no experience in system
admin to understand the "real world" of deployment.
I am really old so I have done a lot of both.
Has for the multi pom solution, it's actually the thing that the group
which is pushing the profile solution want to avoid, because this would
require them to build multiple archetype based on the wanted target
deployement.
That's the reason I was pushing to build it directly into the archetype,
thus, having the question asked during the archetype invocation. One
archetype could be built to support all the permutations if bonified with
some additionnal questions (target container and deploiement type) aside
version/groups/artifacts ...
Since I went throught profile hell in another life, I want to avoid their
abuse and am just trying to build a solid, documented argument and solution
that would fit the bill while minimizing the overhead cost. It's a knowned
fact from the community to avoid abusing profiles, there is just not a lot
of 'official documentation' to ggo with it.
Patrick Sansoucy
In theory, there is no difference between theory and practice, but in
practice, there is ...
On Mon, Oct 19, 2015 at 1:12 PM, Ben Podgursky <[email protected]> wrote:
What if your profiles lived in a couple of parent POMs, and the child POMs
inherited from the appropriate parent POMs? We use this setup for many of
our projects. It avoids child POM bloat and lets us update the shared
logic without pushing changes to every project.
Only limitation is that maven has no multi-inheritance / mixins so you have
to be careful setting up inheritance trees.
On Mon, Oct 19, 2015 at 9:58 AM, Benson Margulies <[email protected]>
wrote:
If each project picks a style and sticks to it, then archetypes are
appropriate.
On Mon, Oct 19, 2015 at 11:26 AM, Patrick Sansoucy
<[email protected]> wrote:
Re,
Basically, the end result would be to support multiple teams with
multiple
web application servers and setup (shared libs vs non shared libs).
Thus
each internal team does not go back and forth between setups/server.
For
a
vast majority of cases, the decision is done once, at the start of the
project, and you live with it.
As for the question, like I said previously, the release drives a
single
artifact 'type', not a portfolio. The profile idea is basically used
only
to support the initial branching for the teams.
Never thought about the Invoker plugin that way. I had suggested of
using
it to test the templating of the archetypes themselves, but not more.
Since
using profiles means that you have to execute the build itself to
validate,
while using the archetype, you test the structure and content of the
created project, which I find easier.
Patrick Sansoucy
In theory, there is no difference between theory and practice, but in
practice, there is ...
On Mon, Oct 19, 2015 at 11:07 AM, Benson Margulies <
[email protected]>
wrote:
Once you've run an archetype, you have a new project. And you're stuck
with it, in the sense that you have to keep it maintained.
An important question is this: what artifacts do you want to make as
part of a release? If you want a portfolio of artifacts, each for one
of your scenarios, then profiles aren't very useful, but the invoker
plugin might be.
On the other hand, if you never make releases, and you just want to
run various build with various results, then profiles can be
convenient.
The invoker is generally used for testing, and I've never tried it as
a solution to DRY-ing up a build that has to produce multiple small
variations.
---------------------------------------------------------------------
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]
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
