Re: Re: Re: useing profiles to control properties to drive version numbers in poms
Hi, I'm using profiles at work for the sole purpose of deciding what to do with the build artifact, i.e. activating different deployment targets (application servers) for an EAR. I see this as a completely different task where you're simply using Maven as a utility tool. When using Maven as a build tool, you will be deploying the artifacts to a repository. What you then do with the artifacts after that (like e.g. publish to an app server) is outside of the build story, and should be handled as a separate task. Ok, but in that case I'm just simplifying life: We're having lots of projects building at least one EAR, and each EAR is deployed to the same application server(s), but in different flavors: developer (snapshot) build, integration build and/or release build. Using a CI server configured with special jobs doing these deployment tasks would result in having to implement the same tasks again and again. IMHO this is more error-prone than having a default job in a parent pom doing that... Regards Thorsten
Re: Re: Re: useing profiles to control properties to drive version numbers in poms
We're having lots of projects building at least one EAR, and each EAR is deployed to the same application server(s), but in different flavors: developer (snapshot) build, integration build and/or release build. Using a CI server configured with special jobs doing these deployment tasks would result in having to implement the same tasks again and again. IMHO this is more error-prone than having a default job in a parent pom doing that... When been over this several times on this list. You have to extract the configuration out of the binary. You mustn't have a Maven build that could generate different flavors of an artifact. Which one would you deploy to the repository? If you can't separate the configuration out of the binary, you should have multiple projects each one generate one of the flavors. /Anders - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Re: Re: useing profiles to control properties to drive version numbers in poms
Hi, When been over this several times on this list. You have to extract the configuration out of the binary. You mustn't have a Maven build that could generate different flavors of an artifact. Which one would you deploy to the repository? Ok, this was a bit misleading by me. With flavors I just meant * mvn clean deploy by command or on a nightly base * mvn release:prepare release:perform final releases / pre-releases meant for an integration build and/or tests by our business department If you can't separate the configuration out of the binary, you should have multiple projects each one generate one of the flavors. +1 Regards Thorsten
RE: useing profiles to control properties to drive version numbers in poms
Chad path of least resistance is to set the version of the project in pom.xml
(at top) and then reference project.version e.g.
version${project.version}/version HTH
Martin
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
From: chad.da...@emc.com
To: users@maven.apache.org
Date: Fri, 16 Mar 2012 12:51:03 -0400
Subject: useing profiles to control properties to drive version numbers in
poms
Does anyone have any experience using a property to control the version
numbers in poms? Like, version${myVersion}/version and the myVersion
property can be set in profiles. . .
Thoughts?
Re: Re: useing profiles to control properties to drive version numbers in poms
Hi, Yes, profiles are evil. If you use them for changing / defining _what_ gets built and/or how, yes. If you think you should be using profiles, think again. If you still think they are the solution, please think it through once more. If you still persist, go use Ant. Profiles are simply very rarely a good solution. I'm using profiles at work for the sole purpose of deciding what to do with the build artifact, i.e. activating different deployment targets (application servers) for an EAR. Regards Thorsten
Re: Re: useing profiles to control properties to drive version numbers in poms
If you think you should be using profiles, think again. If you still think they are the solution, please think it through once more. If you still persist, go use Ant. Profiles are simply very rarely a good solution. I'm using profiles at work for the sole purpose of deciding what to do with the build artifact, i.e. activating different deployment targets (application servers) for an EAR. I see this as a completely different task where you're simply using Maven as a utility tool. When using Maven as a build tool, you will be deploying the artifacts to a repository. What you then do with the artifacts after that (like e.g. publish to an app server) is outside of the build story, and should be handled as a separate task. You could use Maven to do that, and then you could have any number of profiles to alter the behavior. But I want to stress that that's not a build job. This is my repository-focused view of things. /Anders - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: useing profiles to control properties to drive version numbers in poms
On 18/03/2012 5:41 PM, Thorsten Heit wrote: Hi, Yes, profiles are evil. If you use them for changing / defining _what_ gets built and/or how, yes. If you think you should be using profiles, think again. If you still think they are the solution, please think it through once more. If you still persist, go use Ant. Profiles are simply very rarely a good solution. I'm using profiles at work for the sole purpose of deciding what to do with the build artifact, i.e. activating different deployment targets (application servers) for an EAR. Not clear that profiles are the right approach for that. You will probably be unhappy going down this road. I might be off-base but it does not sound like the right way to solve that problem. In any event, good luck. I hope that you are able to prove me wrong. Ron Regards Thorsten -- 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: useing profiles to control properties to drive version numbers in poms
On 18/03/2012 5:53 PM, Anders Hammar wrote: If you think you should be using profiles, think again. If you still think they are the solution, please think it through once more. If you still persist, go use Ant. Profiles are simply very rarely a good solution. I'm using profiles at work for the sole purpose of deciding what to do with the build artifact, i.e. activating different deployment targets (application servers) for an EAR. I see this as a completely different task where you're simply using Maven as a utility tool. When using Maven as a build tool, you will be deploying the artifacts to a repository. What you then do with the artifacts after that (like e.g. publish to an app server) is outside of the build story, and should be handled as a separate task. You could use Maven to do that, and then you could have any number of profiles to alter the behavior. But I want to stress that that's not a build job. This is my repository-focused view of things. And a very sensible view at that! /Anders - 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: useing profiles to control properties to drive version numbers in poms
Not good.
Dependency versions should be deterministic. For the same reason avoid
version ranges.
/Anders (mobile)
Den 16 mar 2012 17.52 skrev chad.da...@emc.com:
Does anyone have any experience using a property to control the version
numbers in poms? Like, version${myVersion}/version and the myVersion
property can be set in profiles. . .
Thoughts?
RE: useing profiles to control properties to drive version numbers in poms
Not good. Dependency versions should be deterministic. For the same reason avoid version ranges. That's pretty definitive, and I think I agree on a gut level. Can you articulate any specific issues? I'd appreciate it if you could. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: useing profiles to control properties to drive version numbers in poms
Search the forum for profile. You will see people in all kinds of difficulty and dead-ends caused by trying to use profiles. There are (apparently) some actual uses for profiles but far more cases of misuse. We have never used profiles but from watching the forum for 4+years, my advice is to get your builds working well without profiles and then see if there is an opportunity for optimization with profiles. Profiles are processed at a certain point in the maven build process so there are things that you can not do with them. Maven supports a certain build philosophy and will defeat anyone who tries to go against this. Try to go down the simplest road and let Maven do its thing. Version ranges are another bad idea. There is no reason not to pick a version of a dependency. You are only going to have 1 version at run-time anyway and it might as well be one that you pick and have tested. If you search the forum, you will find problems and silliness caused by the use of version ranges. I hope that this helps. Ron On 16/03/2012 1:18 PM, chad.da...@emc.com wrote: Not good. Dependency versions should be deterministic. For the same reason avoid version ranges. That's pretty definitive, and I think I agree on a gut level. Can you articulate any specific issues? I'd appreciate it if you could. - 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: useing profiles to control properties to drive version numbers in poms
The thing is that having the possibility of change a dependency version during build time would/could sound as a good thing. BUT, you have to remember that your pom gets deployed to a repo and will be consumed by other people. If the pom does not have pinned downed versions but would change depending on what profiles are specified. Something that will work for someone will not work for someone else. If you would write a new release plugin that would update the pom that gets deployed to specify the exact versions used during build, it would be fine. But that's not the case with the current release plugin. /Anders On Fri, Mar 16, 2012 at 18:18, chad.da...@emc.com wrote: Not good. Dependency versions should be deterministic. For the same reason avoid version ranges. That's pretty definitive, and I think I agree on a gut level. Can you articulate any specific issues? I'd appreciate it if you could. - 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: useing profiles to control properties to drive version numbers in poms
Yes, profiles are evil. If you think you should be using profiles, think again. If you still think they are the solution, please think it through once more. If you still persist, go use Ant. Profiles are simply very rarely a good solution. /Anders On Fri, Mar 16, 2012 at 19:31, Ron Wheeler rwhee...@artifact-software.com wrote: Search the forum for profile. You will see people in all kinds of difficulty and dead-ends caused by trying to use profiles. There are (apparently) some actual uses for profiles but far more cases of misuse. We have never used profiles but from watching the forum for 4+years, my advice is to get your builds working well without profiles and then see if there is an opportunity for optimization with profiles. Profiles are processed at a certain point in the maven build process so there are things that you can not do with them. Maven supports a certain build philosophy and will defeat anyone who tries to go against this. Try to go down the simplest road and let Maven do its thing. Version ranges are another bad idea. There is no reason not to pick a version of a dependency. You are only going to have 1 version at run-time anyway and it might as well be one that you pick and have tested. If you search the forum, you will find problems and silliness caused by the use of version ranges. I hope that this helps. Ron On 16/03/2012 1:18 PM, chad.da...@emc.com wrote: Not good. Dependency versions should be deterministic. For the same reason avoid version ranges. That's pretty definitive, and I think I agree on a gut level. Can you articulate any specific issues? I'd appreciate it if you could. - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
