You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Ch...@emc.com on 2012/03/16 17:51:03 UTC
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: useing profiles to control properties to drive version numbers
in poms
Posted by Ron Wheeler <rw...@artifact-software.com>.
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: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: useing profiles to control properties to drive version numbers
in poms
Posted by Ron Wheeler <rw...@artifact-software.com>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Re: Re: Re: useing profiles to control properties to drive version
numbers in poms
Posted by Thorsten Heit <th...@vkb.de>.
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: Re: Re: useing profiles to control properties to drive version
numbers in poms
Posted by Anders Hammar <an...@hammar.net>.
> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Re: Re: useing profiles to control properties to drive version numbers
in poms
Posted by Thorsten Heit <th...@vkb.de>.
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: useing profiles to control properties to drive version
numbers in poms
Posted by Anders Hammar <an...@hammar.net>.
>> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Re: useing profiles to control properties to drive version numbers in
poms
Posted by Thorsten Heit <th...@vkb.de>.
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: useing profiles to control properties to drive version numbers in poms
Posted by Anders Hammar <an...@hammar.net>.
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
<rw...@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.Davis@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: useing profiles to control properties to drive version numbers
in poms
Posted by Ron Wheeler <rw...@artifact-software.com>.
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.Davis@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: useing profiles to control properties to drive version numbers in poms
Posted by Anders Hammar <an...@hammar.net>.
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, <Ch...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: useing profiles to control properties to drive version numbers
in poms
Posted by Ch...@emc.com.
>
> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: useing profiles to control properties to drive version numbers in poms
Posted by Anders Hammar <an...@hammar.net>.
Not good.
Dependency versions should be deterministic. For the same reason avoid
version ranges.
/Anders (mobile)
Den 16 mar 2012 17.52 skrev <Ch...@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
Posted by Martin Gainty <mg...@hotmail.com>.
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.Davis@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?
>