Re: Maven profiles vs Archetypes

[Benson Margulies]

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

Re: Maven profiles vs Archetypes

[Ron Wheeler]

Maven is a great tool but it is not designed to build installation packages.

Would your problem be better solved using one or more installer 
generation projects (in Maven) that gather and package the final set of 
files that are to be used to deploy the app to the run-time environments?


I use IzPack for this.
It has a Maven plug-in that uses dependency management to grab the right 
software from my repos but allows me to specify what I want to deploy to 
the various run-time environments.
If you need to support different OS's or different containers, this 
might be easier than trying to create a bunch of build projects 
controlled with profiles.


Not sure from your description if this is the problem that you are 
trying to solve but it is a recurring theme here.


Ron


On 19/10/2015 11:07 AM, Benson Margulies 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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Maven profiles vs Archetypes

[Patrick Sansoucy]

Hello,

Being a avid Maven user for years, I have been drilled to avoid using or
minimize profiles usage in a Maven build. Even more when it is geared to
adapt for a runtime context. I always managed to find a way to convice
people to do otherwise until now ...

A solution was provided, via Maven profiles, to support different type of
build geared to use or not shared libraries for our web applications and
our different types of web application servers. Since the basic use case
does not require changing the type of build once the archetype is
generated, I suggested to do it via templating in the in house archetypes,
thus avoiding bloated pom.xml files and scoping the profile use to
environment configuration. Other possibilities would be to have completely
seperated achetypes, but I think the templating can cover most of our
usecases.

I got redirected to this link:
http://maven.apache.org/guides/introduction/introduction-to-profiles.html

Which kind of states the use of profiles for something very similar to what
I am trying to prevent. I have looked at the Maven Reference guide, but
have not found other literature that could tip the scale. I don't want to
end up in a philosophical argument either, so I want to keep thing
constructive.

Questions :
Are there other, more elegant solution that I could propose ?
Am I on the right track in my suggestion to use our in-hous archetypes to
do the heavy lifting ?
Is there 'official' documentation that I could use as references or best
practices to try to avoid that kind of profile abuse (or point me in the
proper direction if I am wrong to argue) ?

Thanks in advance for all the help

Patrick
In theory, there is no difference between theory and practice, but in
practice, there is ...

Re: Maven profiles vs Archetypes

[Patrick Sansoucy]

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

Re: Maven profiles vs Archetypes

[Ron Wheeler]

Sounds like my installer idea will solve your problem and be much easier 
to maintain.
Develop the code in a set of projects that don't care about deployment 
and have one or more projects that know about installation requirements 
and build one or more installers that deal with all of the configuration 
files and directory structures required to support all of the delivery 
platforms that you need to support.


- developers do not have to worry about any run-time other than the one 
used for testing.
- new run-time platforms can be supported without screwing with the 
software build processes.
- experts in the supported platforms can play with the Maven installer 
projects without disrupting the developers.
- the final deliverables will be easier to understand and deploy since 
each installer package supports exactly what it is supposed to and does 
not require any detailed knowledge about the structure of the 
application to install it. (The system adnmin can select the right OS, 
select the library configuration, the container, etc. and the installer 
will assemble the right components and install them in the environment.)
- the installer project is easy to set up and once it is done, it is as 
stable as the configuration files are.


Ron


On 19/10/2015 11:26 AM, Patrick Sansoucy 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 
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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven profiles vs Archetypes

[Patrick Sansoucy]

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. This would require changes which I don't have much
weight to throw at.

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

Re: Maven profiles vs Archetypes

[Ron Wheeler]

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  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 
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
 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 <

bimargul...@gmail.com>

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



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





--
Ron Wheeler
President
Artifact Software 

Re: Maven profiles vs Archetypes

[Benson Margulies]

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

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven profiles vs Archetypes

[Ben Podgursky]

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