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
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
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
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é
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
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
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
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
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
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.
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
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
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
13 matches
Mail list logo
