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 <patrick.sanso...@gmail.com> 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
