Re: Maven profiles vs Archetypes
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 Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-9
Re: Maven profiles vs Archetypes
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
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
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
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
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
Re: Maven profiles vs Archetypes
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
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
Maven profiles vs Archetypes
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 ...