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