You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Niranjan Rao <nh...@gmail.com> on 2012/12/21 21:21:40 UTC
Maven profiles and resource filtering
Greetings,
We have bunch of profiles and corresponding resource filtering which all
works great. One frequent problem that we encounter team members often
forget to add new values in profile/filter property file of other
profiles than the one they are currently using. Naturally results are
disastrous. Normally we can find quickly which property is not filtered
correctly and fix it but this is tedious.
I am wondering if there is any way to catch missing properties at build
time. That is when maven sees a property definition during filtering
phase which has variable declaration and could not locate the value, can
it raise the error and let the build fail?
Thanks,
Niranjan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven profiles and resource filtering
Posted by Wayne Fay <wa...@gmail.com>.
> I am wondering if there is any way to catch missing properties at build
> time. That is when maven sees a property definition during filtering phase
> which has variable declaration and could not locate the value, can it raise
> the error and let the build fail?
Perhaps there is some enforcer rule that can help? Or you can write
your own rule for this purpose.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven profiles and resource filtering
Posted by Stephen Connolly <st...@gmail.com>.
Take a look at the ship maven plugin for one way of doing this
On Thursday, 27 December 2012, Scott Klein wrote:
> > Don't repackage per env!!!!
>
> Could you expand on that concept a little bit for me.
>
> My question is whether you should run a "mvn deploy -P Test" to get your
> artifact(s) up to your Test environment, because that will re-package
> right? Or do you use some other way to take existing artifact(s) from your
> repo and push them out to the test server (or any server)?
>
> Based on your comment, I am assuming the latter but not sure how one could
> go about doing that...I guess I just assumed that the proper thing to do
> was use deploy for this, as I didn't see another option.
>
> Should I always deploy to my repo and then perform some separate task
> which takes artifacts from my repo and pushes them over to one of my app
> servers? If so, how the heck do I do that within Maven or, upon reflection,
> outside of Maven?
>
> Based on what I have read:
> "Maven's responsibility for building your artifact ends when it has
> delivered an environment independent artifact into the Maven Repository."
>
> ...and...
>
> "deploy - done in an integration or release environment, copies the final
> package to the remote repository for sharing with other developers and
> projects."
>
> It sounds like if you use Cargo (or similar) you would almost create a new
> Phase (or goal, or something) which would bypass all parent phases (so you
> don't repackage) and simply grab your artifact(s) from your repo and push
> them over. That seems a bit dramatic.
>
> I found this old article as an example of what I was considering:
>
> http://dpillay.wordpress.com/2009/04/12/maven-cargo-tomcat-auto-deployment/
>
> However, here he is making it part of the "install" phase which I don't
> think strictly adheres to the Maven lifecycle (install - install the
> package into the local repository, for use as a dependency in other
> projects locally) nor to your admonition. It sounds to me like Maven washes
> it hands of you once you place an artifact in the repo and everyone using
> Cargo to perform artifact pushes to their dev/test/prod environments is
> breaking the spirit of Maven. Therefore, I would have to rely on tools
> other than Maven to do this.
>
> Well, now I think I talked myself into the "external tool" camp ... argh!
>
>
> Thanks
> scott
>
> -----Original Message-----
> From: Maven User [mailto:maven.2.user@gmail.com]
> Sent: Thursday, December 27, 2012 7:47 AM
> To: Maven Users List
> Subject: Re: Maven profiles and resource filtering
>
> AHHHH - yes, all your "configuration" should be OUTSIDE your war/ear/jar
> files!
>
> Don't repackage per env!!!! Also, don't force someone to unfurl your
> artifact, alter config, then re-roll it....
>
>
>
>
> On Wed, Dec 26, 2012 at 3:05 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > When artifacts get installed into the remote repository or local
> > repository cache, you do not have information about what profiles were
> > active when the artifact was built. as a result, in multi-module
> > builds, if you are working in a sub-module, you can end up with mixed
> artifacts, etc.
> >
> > Plus when you do your release you need to ask what profiles were
> > active when the release was cut.
> >
> > It is a seductive idea... until you dig deep enough. The real way to
> > work is to have the configuration externalized so that you don't need
> > to rebuild to deploy to a different environment.
> >
> > -Stephen
> >
> >
> > On 26 December 2012 18:54, Niranjan Rao <nh...@gmail.com> wrote:
> >
> > > I read the blog entry and still confused about why we should not be
> > > using profiles. Perhaps I am just being dumb.
> > >
> > > As for our particular case, maven and resource filtering actually
> > > has
> > been
> > > very helpful to us. We have multiple locations where development
> > > happens, each location has its own setup of database/message queue
> > > and other external resources application needs. With the help of
> > > resource
> > filtering,
> > > we are able to set right options in the configuration files so that
> > > developers don't step on each other shoes. Each one gets his own
> > > "namespace" as far external resources are concerned. Every developer
> > > is required to execute the complete test suite in their own
> > > environment
> > before
> > > pushing their changes.
> > >
> > > There are couple profiles we use during hudson builds - one meant
> > > for CI, almost same as developer's profile, does run destructive
> > > unit tests on
> > DB -
> > > same tests developers are required to run. Other for actually
> > > creating
> > the
> > > build, which "skips" the unit tests and does a build with proper
> > properties
> > > so that build can work on QA servers and not destroy the data QA
> > > team has built.
> > >
> > > As far as I can see its just properties file and values get replaced
> > > in maven way. Except for QA build, same unit tests get executed,
> > > only difference being names/locations of external resources changed
> > > based on profile. Only "hack" I can think of is bit of dependency
> > > injection that sets db name slightly differently during unit tests.
> > > The reason behind
> > this
> > > is developers not loosing the "working" data when the destructive
> > > units tests run. But again, its transparent to application and
> > > application just works with the interface, concrete implementation
> > > changes based on
> > whether
> > > its running as part of main app or as unit test.
> > >
> > > Am I missing something?
> > >
> > > Regards,
> > >
> > > Niranjan
> > >
> > >
> > > On 12/21/2012 12:32 PM, Stephen Connolly wrote:
> > >
> > >> http://developer-blog.**cloudbees.com/2012/11/maven-**
> > >> profiles-and-maven-way.html<
> > http://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-w
> > ay.html
> > >
> > >>
> > >> Please don't do maven the way you are doing it
> > >>
> > >> On Friday, 21 December 2012, Niranjan Rao wrote:
> > >>
> > >> Greetings,
> > >>>
> > >>> > ----- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org
> <
> > users-unsubscribe@maven.apache.org <javascript:;>>
> > > For additional commands, e-mail: users-help@maven.apache.org<javascript:;>
> > >
> > >
> >
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 7838 (20121227) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 7839 (20121227) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: users-help@maven.apache.org<javascript:;>
>
>
Re: Maven profiles and resource filtering
Posted by Maven User <ma...@gmail.com>.
Hi Scott -
I'll start with "it depends".
I'll also point out that Stephen has pointed out an interesting plugin
below, but I didn't dig deeply into it.
You could also build your "shipping" system around the maven release plugin
that exists for jenkins (granting anyone who can click a button the ability
to run the release - that's likely possible regardless of route).
I'm personally in the camp where I firmly believe jenkins/maven shouldn't
be your orchestration tool. Another glimpse into my world, I use embedded
jetty and when maven builds, there are two options -
1 - An exploded "dir" type assembly (done via an assembly descriptor) - you
end up with a structure in your target directory where <appname>-<version>
has a bin/conf/war directory. Inside the "conf" dir, we have any
configuration files, bin has our init/start/stop script and war has our
war. The conf is placed in the target dir after being filtered (we use the
<properties> and settings.xml to override per dev machine - I'm not
enforcing where or what dev installs - just facilitating HOW the specify
these locations).
2 - A "bin" zip file (easiest way to share across platforms) - this is a
zip file with all the config and script files in a "templates" directory
instead. Any ${foo} values are replaced with their ERB equivalents because
we use chef to deploy. When chef deploys, it pulls this "bin" zip from
nexus, unpacks it, then bulk copies the config files just up one directory,
expanding any templates along the way. This is good because if dev adds a
new property file or script or some other thing, it's automagically
included in the "bin" zip and automagically managed by chef. This "bin"
zip is "attached" per the SOP maven way so at t end of any build or
release, it ends up in nexus. Additionally, for any job in jenkins, we
have a shared (shared between jenkins jobs) maven config which activates
the "prod" profile (there's slightly more to this, but that's beyond the
scope of this email). This allows us to build once and deploy anywhere.
Our build(s) are per-service - so we don't have some massive repo that has
all artifacts in it. All of our service builds take about 1 to 2 minutes,
so it's pretty cheap to roll out a new release (release small portions
frequently).
I've glossed over several details - not because of skeletons, but because
they could be several paragraphs and hours of conversation :-)
Again - if you need any details - feel free to reach out directly.
On Thu, Dec 27, 2012 at 6:05 PM, Scott Klein <Sc...@goldenhour.com>wrote:
> > Don't repackage per env!!!!
>
> Could you expand on that concept a little bit for me.
>
> My question is whether you should run a "mvn deploy -P Test" to get your
> artifact(s) up to your Test environment, because that will re-package
> right? Or do you use some other way to take existing artifact(s) from your
> repo and push them out to the test server (or any server)?
>
> Based on your comment, I am assuming the latter but not sure how one could
> go about doing that...I guess I just assumed that the proper thing to do
> was use deploy for this, as I didn't see another option.
>
> Should I always deploy to my repo and then perform some separate task
> which takes artifacts from my repo and pushes them over to one of my app
> servers? If so, how the heck do I do that within Maven or, upon reflection,
> outside of Maven?
>
> Based on what I have read:
> "Maven's responsibility for building your artifact ends when it has
> delivered an environment independent artifact into the Maven Repository."
>
> ...and...
>
> "deploy - done in an integration or release environment, copies the final
> package to the remote repository for sharing with other developers and
> projects."
>
> It sounds like if you use Cargo (or similar) you would almost create a new
> Phase (or goal, or something) which would bypass all parent phases (so you
> don't repackage) and simply grab your artifact(s) from your repo and push
> them over. That seems a bit dramatic.
>
> I found this old article as an example of what I was considering:
>
> http://dpillay.wordpress.com/2009/04/12/maven-cargo-tomcat-auto-deployment/
>
> However, here he is making it part of the "install" phase which I don't
> think strictly adheres to the Maven lifecycle (install - install the
> package into the local repository, for use as a dependency in other
> projects locally) nor to your admonition. It sounds to me like Maven washes
> it hands of you once you place an artifact in the repo and everyone using
> Cargo to perform artifact pushes to their dev/test/prod environments is
> breaking the spirit of Maven. Therefore, I would have to rely on tools
> other than Maven to do this.
>
> Well, now I think I talked myself into the "external tool" camp ... argh!
>
>
> Thanks
> scott
>
> -----Original Message-----
> From: Maven User [mailto:maven.2.user@gmail.com]
> Sent: Thursday, December 27, 2012 7:47 AM
> To: Maven Users List
> Subject: Re: Maven profiles and resource filtering
>
> AHHHH - yes, all your "configuration" should be OUTSIDE your war/ear/jar
> files!
>
> Don't repackage per env!!!! Also, don't force someone to unfurl your
> artifact, alter config, then re-roll it....
>
>
>
>
> On Wed, Dec 26, 2012 at 3:05 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > When artifacts get installed into the remote repository or local
> > repository cache, you do not have information about what profiles were
> > active when the artifact was built. as a result, in multi-module
> > builds, if you are working in a sub-module, you can end up with mixed
> artifacts, etc.
> >
> > Plus when you do your release you need to ask what profiles were
> > active when the release was cut.
> >
> > It is a seductive idea... until you dig deep enough. The real way to
> > work is to have the configuration externalized so that you don't need
> > to rebuild to deploy to a different environment.
> >
> > -Stephen
> >
> >
> > On 26 December 2012 18:54, Niranjan Rao <nh...@gmail.com> wrote:
> >
> > > I read the blog entry and still confused about why we should not be
> > > using profiles. Perhaps I am just being dumb.
> > >
> > > As for our particular case, maven and resource filtering actually
> > > has
> > been
> > > very helpful to us. We have multiple locations where development
> > > happens, each location has its own setup of database/message queue
> > > and other external resources application needs. With the help of
> > > resource
> > filtering,
> > > we are able to set right options in the configuration files so that
> > > developers don't step on each other shoes. Each one gets his own
> > > "namespace" as far external resources are concerned. Every developer
> > > is required to execute the complete test suite in their own
> > > environment
> > before
> > > pushing their changes.
> > >
> > > There are couple profiles we use during hudson builds - one meant
> > > for CI, almost same as developer's profile, does run destructive
> > > unit tests on
> > DB -
> > > same tests developers are required to run. Other for actually
> > > creating
> > the
> > > build, which "skips" the unit tests and does a build with proper
> > properties
> > > so that build can work on QA servers and not destroy the data QA
> > > team has built.
> > >
> > > As far as I can see its just properties file and values get replaced
> > > in maven way. Except for QA build, same unit tests get executed,
> > > only difference being names/locations of external resources changed
> > > based on profile. Only "hack" I can think of is bit of dependency
> > > injection that sets db name slightly differently during unit tests.
> > > The reason behind
> > this
> > > is developers not loosing the "working" data when the destructive
> > > units tests run. But again, its transparent to application and
> > > application just works with the interface, concrete implementation
> > > changes based on
> > whether
> > > its running as part of main app or as unit test.
> > >
> > > Am I missing something?
> > >
> > > Regards,
> > >
> > > Niranjan
> > >
> > >
> > > On 12/21/2012 12:32 PM, Stephen Connolly wrote:
> > >
> > >> http://developer-blog.**cloudbees.com/2012/11/maven-**
> > >> profiles-and-maven-way.html<
> > http://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-w
> > ay.html
> > >
> > >>
> > >> Please don't do maven the way you are doing it
> > >>
> > >> On Friday, 21 December 2012, Niranjan Rao wrote:
> > >>
> > >> Greetings,
> > >>>
> > >>> We have bunch of profiles and corresponding resource filtering
> > >>> which
> > all
> > >>> works great. One frequent problem that we encounter team members
> > >>> often forget to add new values in profile/filter property file of
> > >>> other profiles than the one they are currently using. Naturally
> > >>> results are
> > disastrous.
> > >>> Normally we can find quickly which property is not filtered
> > >>> correctly and fix it but this is tedious.
> > >>>
> > >>> I am wondering if there is any way to catch missing properties at
> > >>> build time. That is when maven sees a property definition during
> > >>> filtering phase which has variable declaration and could not
> > >>> locate the value, can it raise the error and let the build fail?
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Niranjan
> > >>>
> > >>> ------------------------------****----------------------------**
> > >>> --**---------
> > >>>
> > >>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> > users-unsubscribe@maven.apache.org>
> > >>> For additional commands, e-mail: users-help@maven.apache.org
> > >>>
> > >>>
> > >>>
> > >
> > > ------------------------------**------------------------------**----
> > > ----- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> > users-unsubscribe@maven.apache.org>
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 7838 (20121227) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 7839 (20121227) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: Maven profiles and resource filtering
Posted by Scott Klein <Sc...@goldenhour.com>.
> Don't repackage per env!!!!
Could you expand on that concept a little bit for me.
My question is whether you should run a "mvn deploy -P Test" to get your artifact(s) up to your Test environment, because that will re-package right? Or do you use some other way to take existing artifact(s) from your repo and push them out to the test server (or any server)?
Based on your comment, I am assuming the latter but not sure how one could go about doing that...I guess I just assumed that the proper thing to do was use deploy for this, as I didn't see another option.
Should I always deploy to my repo and then perform some separate task which takes artifacts from my repo and pushes them over to one of my app servers? If so, how the heck do I do that within Maven or, upon reflection, outside of Maven?
Based on what I have read:
"Maven's responsibility for building your artifact ends when it has delivered an environment independent artifact into the Maven Repository."
...and...
"deploy - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects."
It sounds like if you use Cargo (or similar) you would almost create a new Phase (or goal, or something) which would bypass all parent phases (so you don't repackage) and simply grab your artifact(s) from your repo and push them over. That seems a bit dramatic.
I found this old article as an example of what I was considering:
http://dpillay.wordpress.com/2009/04/12/maven-cargo-tomcat-auto-deployment/
However, here he is making it part of the "install" phase which I don't think strictly adheres to the Maven lifecycle (install - install the package into the local repository, for use as a dependency in other projects locally) nor to your admonition. It sounds to me like Maven washes it hands of you once you place an artifact in the repo and everyone using Cargo to perform artifact pushes to their dev/test/prod environments is breaking the spirit of Maven. Therefore, I would have to rely on tools other than Maven to do this.
Well, now I think I talked myself into the "external tool" camp ... argh!
Thanks
scott
-----Original Message-----
From: Maven User [mailto:maven.2.user@gmail.com]
Sent: Thursday, December 27, 2012 7:47 AM
To: Maven Users List
Subject: Re: Maven profiles and resource filtering
AHHHH - yes, all your "configuration" should be OUTSIDE your war/ear/jar files!
Don't repackage per env!!!! Also, don't force someone to unfurl your artifact, alter config, then re-roll it....
On Wed, Dec 26, 2012 at 3:05 PM, Stephen Connolly < stephen.alan.connolly@gmail.com> wrote:
> When artifacts get installed into the remote repository or local
> repository cache, you do not have information about what profiles were
> active when the artifact was built. as a result, in multi-module
> builds, if you are working in a sub-module, you can end up with mixed artifacts, etc.
>
> Plus when you do your release you need to ask what profiles were
> active when the release was cut.
>
> It is a seductive idea... until you dig deep enough. The real way to
> work is to have the configuration externalized so that you don't need
> to rebuild to deploy to a different environment.
>
> -Stephen
>
>
> On 26 December 2012 18:54, Niranjan Rao <nh...@gmail.com> wrote:
>
> > I read the blog entry and still confused about why we should not be
> > using profiles. Perhaps I am just being dumb.
> >
> > As for our particular case, maven and resource filtering actually
> > has
> been
> > very helpful to us. We have multiple locations where development
> > happens, each location has its own setup of database/message queue
> > and other external resources application needs. With the help of
> > resource
> filtering,
> > we are able to set right options in the configuration files so that
> > developers don't step on each other shoes. Each one gets his own
> > "namespace" as far external resources are concerned. Every developer
> > is required to execute the complete test suite in their own
> > environment
> before
> > pushing their changes.
> >
> > There are couple profiles we use during hudson builds - one meant
> > for CI, almost same as developer's profile, does run destructive
> > unit tests on
> DB -
> > same tests developers are required to run. Other for actually
> > creating
> the
> > build, which "skips" the unit tests and does a build with proper
> properties
> > so that build can work on QA servers and not destroy the data QA
> > team has built.
> >
> > As far as I can see its just properties file and values get replaced
> > in maven way. Except for QA build, same unit tests get executed,
> > only difference being names/locations of external resources changed
> > based on profile. Only "hack" I can think of is bit of dependency
> > injection that sets db name slightly differently during unit tests.
> > The reason behind
> this
> > is developers not loosing the "working" data when the destructive
> > units tests run. But again, its transparent to application and
> > application just works with the interface, concrete implementation
> > changes based on
> whether
> > its running as part of main app or as unit test.
> >
> > Am I missing something?
> >
> > Regards,
> >
> > Niranjan
> >
> >
> > On 12/21/2012 12:32 PM, Stephen Connolly wrote:
> >
> >> http://developer-blog.**cloudbees.com/2012/11/maven-**
> >> profiles-and-maven-way.html<
> http://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-w
> ay.html
> >
> >>
> >> Please don't do maven the way you are doing it
> >>
> >> On Friday, 21 December 2012, Niranjan Rao wrote:
> >>
> >> Greetings,
> >>>
> >>> We have bunch of profiles and corresponding resource filtering
> >>> which
> all
> >>> works great. One frequent problem that we encounter team members
> >>> often forget to add new values in profile/filter property file of
> >>> other profiles than the one they are currently using. Naturally
> >>> results are
> disastrous.
> >>> Normally we can find quickly which property is not filtered
> >>> correctly and fix it but this is tedious.
> >>>
> >>> I am wondering if there is any way to catch missing properties at
> >>> build time. That is when maven sees a property definition during
> >>> filtering phase which has variable declaration and could not
> >>> locate the value, can it raise the error and let the build fail?
> >>>
> >>> Thanks,
> >>>
> >>> Niranjan
> >>>
> >>> ------------------------------****----------------------------**
> >>> --**---------
> >>>
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> users-unsubscribe@maven.apache.org>
> >>> For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>>
> >>>
> >
> > ------------------------------**------------------------------**----
> > ----- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> users-unsubscribe@maven.apache.org>
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
__________ Information from ESET NOD32 Antivirus, version of virus signature database 7838 (20121227) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__________ Information from ESET NOD32 Antivirus, version of virus signature database 7839 (20121227) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven profiles and resource filtering
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 27/12/2012 2:02 PM, Laird Nelson wrote:
> On Thu, Dec 27, 2012 at 7:46 AM, Maven User <ma...@gmail.com> wrote:
>
>> AHHHH - yes, all your "configuration" should be OUTSIDE your war/ear/jar
>> files!
>>
>> Don't repackage per env!!!! Also, don't force someone to unfurl your
>> artifact, alter config, then re-roll it....
>>
> Right, unless of course you happen to be producing Java EE-compliant
> artifacts such as .war and .ear files, in which case you have no choice, as
> locating the configuration inside the artifact is mandated by the
> specifications. However, even in such cases it's better to build separate
> projects or war overlays or approaches like that than to abuse profiles.
>
> Best,
> Laird
>
You can move the configuration to JNDI or other methods that get
configuration out of the war file but still accessible to the application.
http://blog.artifact-software.com/tech/?p=150
http://blog.artifact-software.com/tech/?p=58
Ron
--
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
Re: Maven profiles and resource filtering
Posted by Laird Nelson <lj...@gmail.com>.
On Thu, Dec 27, 2012 at 11:27 AM, Maven User <ma...@gmail.com> wrote:
> Are you saying "unless of course you happen to work for a company that is
> forced to produce to the exacting standard <artifacts>"?
>
Yes.
> I don't know anyone following the rules 100% - including any of the
> containers available today....
>
I'm not passing judgment; just pointing out that the spec requires
configuration to be inside the artifacts, that's all. (Portions of the EJB
specification also prohibit filesystem I/O, although that looks to be
relaxed in the next revision.) Whatever works for you!
Best,
Laird
--
http://about.me/lairdnelson
Re: Maven profiles and resource filtering
Posted by Maven User <ma...@gmail.com>.
We build wars - but keep the config outside. We use a startup class to
reference them and load them accordingly.
Are you saying "unless of course you happen to work for a company that is
forced to produce to the exacting standard <artifacts>"?
I don't know anyone following the rules 100% - including any of the
containers available today....
On Thu, Dec 27, 2012 at 2:02 PM, Laird Nelson <lj...@gmail.com> wrote:
> On Thu, Dec 27, 2012 at 7:46 AM, Maven User <ma...@gmail.com>
> wrote:
>
> > AHHHH - yes, all your "configuration" should be OUTSIDE your war/ear/jar
> > files!
> >
> > Don't repackage per env!!!! Also, don't force someone to unfurl your
> > artifact, alter config, then re-roll it....
> >
>
> Right, unless of course you happen to be producing Java EE-compliant
> artifacts such as .war and .ear files, in which case you have no choice, as
> locating the configuration inside the artifact is mandated by the
> specifications. However, even in such cases it's better to build separate
> projects or war overlays or approaches like that than to abuse profiles.
>
> Best,
> Laird
>
> --
> http://about.me/lairdnelson
>
Re: Maven profiles and resource filtering
Posted by Laird Nelson <lj...@gmail.com>.
On Thu, Dec 27, 2012 at 7:46 AM, Maven User <ma...@gmail.com> wrote:
> AHHHH - yes, all your "configuration" should be OUTSIDE your war/ear/jar
> files!
>
> Don't repackage per env!!!! Also, don't force someone to unfurl your
> artifact, alter config, then re-roll it....
>
Right, unless of course you happen to be producing Java EE-compliant
artifacts such as .war and .ear files, in which case you have no choice, as
locating the configuration inside the artifact is mandated by the
specifications. However, even in such cases it's better to build separate
projects or war overlays or approaches like that than to abuse profiles.
Best,
Laird
--
http://about.me/lairdnelson
Re: Maven profiles and resource filtering
Posted by Maven User <ma...@gmail.com>.
AHHHH - yes, all your "configuration" should be OUTSIDE your war/ear/jar
files!
Don't repackage per env!!!! Also, don't force someone to unfurl your
artifact, alter config, then re-roll it....
On Wed, Dec 26, 2012 at 3:05 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> When artifacts get installed into the remote repository or local repository
> cache, you do not have information about what profiles were active when the
> artifact was built. as a result, in multi-module builds, if you are working
> in a sub-module, you can end up with mixed artifacts, etc.
>
> Plus when you do your release you need to ask what profiles were active
> when the release was cut.
>
> It is a seductive idea... until you dig deep enough. The real way to work
> is to have the configuration externalized so that you don't need to rebuild
> to deploy to a different environment.
>
> -Stephen
>
>
> On 26 December 2012 18:54, Niranjan Rao <nh...@gmail.com> wrote:
>
> > I read the blog entry and still confused about why we should not be using
> > profiles. Perhaps I am just being dumb.
> >
> > As for our particular case, maven and resource filtering actually has
> been
> > very helpful to us. We have multiple locations where development happens,
> > each location has its own setup of database/message queue and other
> > external resources application needs. With the help of resource
> filtering,
> > we are able to set right options in the configuration files so that
> > developers don't step on each other shoes. Each one gets his own
> > "namespace" as far external resources are concerned. Every developer is
> > required to execute the complete test suite in their own environment
> before
> > pushing their changes.
> >
> > There are couple profiles we use during hudson builds - one meant for CI,
> > almost same as developer's profile, does run destructive unit tests on
> DB -
> > same tests developers are required to run. Other for actually creating
> the
> > build, which "skips" the unit tests and does a build with proper
> properties
> > so that build can work on QA servers and not destroy the data QA team has
> > built.
> >
> > As far as I can see its just properties file and values get replaced in
> > maven way. Except for QA build, same unit tests get executed, only
> > difference being names/locations of external resources changed based on
> > profile. Only "hack" I can think of is bit of dependency injection that
> > sets db name slightly differently during unit tests. The reason behind
> this
> > is developers not loosing the "working" data when the destructive units
> > tests run. But again, its transparent to application and application just
> > works with the interface, concrete implementation changes based on
> whether
> > its running as part of main app or as unit test.
> >
> > Am I missing something?
> >
> > Regards,
> >
> > Niranjan
> >
> >
> > On 12/21/2012 12:32 PM, Stephen Connolly wrote:
> >
> >> http://developer-blog.**cloudbees.com/2012/11/maven-**
> >> profiles-and-maven-way.html<
> http://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-way.html
> >
> >>
> >> Please don't do maven the way you are doing it
> >>
> >> On Friday, 21 December 2012, Niranjan Rao wrote:
> >>
> >> Greetings,
> >>>
> >>> We have bunch of profiles and corresponding resource filtering which
> all
> >>> works great. One frequent problem that we encounter team members often
> >>> forget to add new values in profile/filter property file of other
> >>> profiles
> >>> than the one they are currently using. Naturally results are
> disastrous.
> >>> Normally we can find quickly which property is not filtered correctly
> >>> and
> >>> fix it but this is tedious.
> >>>
> >>> I am wondering if there is any way to catch missing properties at build
> >>> time. That is when maven sees a property definition during filtering
> >>> phase
> >>> which has variable declaration and could not locate the value, can it
> >>> raise
> >>> the error and let the build fail?
> >>>
> >>> Thanks,
> >>>
> >>> Niranjan
> >>>
> >>> ------------------------------****----------------------------**
> >>> --**---------
> >>>
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> users-unsubscribe@maven.apache.org>
> >>> For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>>
> >>>
> >
> > ------------------------------**------------------------------**---------
> > To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> users-unsubscribe@maven.apache.org>
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: Maven profiles and resource filtering
Posted by Stephen Connolly <st...@gmail.com>.
When artifacts get installed into the remote repository or local repository
cache, you do not have information about what profiles were active when the
artifact was built. as a result, in multi-module builds, if you are working
in a sub-module, you can end up with mixed artifacts, etc.
Plus when you do your release you need to ask what profiles were active
when the release was cut.
It is a seductive idea... until you dig deep enough. The real way to work
is to have the configuration externalized so that you don't need to rebuild
to deploy to a different environment.
-Stephen
On 26 December 2012 18:54, Niranjan Rao <nh...@gmail.com> wrote:
> I read the blog entry and still confused about why we should not be using
> profiles. Perhaps I am just being dumb.
>
> As for our particular case, maven and resource filtering actually has been
> very helpful to us. We have multiple locations where development happens,
> each location has its own setup of database/message queue and other
> external resources application needs. With the help of resource filtering,
> we are able to set right options in the configuration files so that
> developers don't step on each other shoes. Each one gets his own
> "namespace" as far external resources are concerned. Every developer is
> required to execute the complete test suite in their own environment before
> pushing their changes.
>
> There are couple profiles we use during hudson builds - one meant for CI,
> almost same as developer's profile, does run destructive unit tests on DB -
> same tests developers are required to run. Other for actually creating the
> build, which "skips" the unit tests and does a build with proper properties
> so that build can work on QA servers and not destroy the data QA team has
> built.
>
> As far as I can see its just properties file and values get replaced in
> maven way. Except for QA build, same unit tests get executed, only
> difference being names/locations of external resources changed based on
> profile. Only "hack" I can think of is bit of dependency injection that
> sets db name slightly differently during unit tests. The reason behind this
> is developers not loosing the "working" data when the destructive units
> tests run. But again, its transparent to application and application just
> works with the interface, concrete implementation changes based on whether
> its running as part of main app or as unit test.
>
> Am I missing something?
>
> Regards,
>
> Niranjan
>
>
> On 12/21/2012 12:32 PM, Stephen Connolly wrote:
>
>> http://developer-blog.**cloudbees.com/2012/11/maven-**
>> profiles-and-maven-way.html<http://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-way.html>
>>
>> Please don't do maven the way you are doing it
>>
>> On Friday, 21 December 2012, Niranjan Rao wrote:
>>
>> Greetings,
>>>
>>> We have bunch of profiles and corresponding resource filtering which all
>>> works great. One frequent problem that we encounter team members often
>>> forget to add new values in profile/filter property file of other
>>> profiles
>>> than the one they are currently using. Naturally results are disastrous.
>>> Normally we can find quickly which property is not filtered correctly
>>> and
>>> fix it but this is tedious.
>>>
>>> I am wondering if there is any way to catch missing properties at build
>>> time. That is when maven sees a property definition during filtering
>>> phase
>>> which has variable declaration and could not locate the value, can it
>>> raise
>>> the error and let the build fail?
>>>
>>> Thanks,
>>>
>>> Niranjan
>>>
>>> ------------------------------****----------------------------**
>>> --**---------
>>>
>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Maven profiles and resource filtering
Posted by Laird Nelson <lj...@gmail.com>.
On Wed, Dec 26, 2012 at 10:54 AM, Niranjan Rao <nh...@gmail.com> wrote:
> I read the blog entry and still confused about why we should not be using
> profiles. Perhaps I am just being dumb.
>
No, it's just not explained very well.
Maven wants your build to be repeatable. That means when you build version
21, and I build version 21, we get exactly the same version 21. There
shouldn't even BE a discussion about "which" version 21 we're talking
about. There should be only one version 21, period, end of story, amen.
There are a few facilities within Maven that make it possible to alter the
output of a build. Profiles are one of those facilities. Profiles let you
alter things about the way that Maven goes about its business producing
artifacts, and so it is possible that if I build version 21 with a profile,
and you build version 21 without one (or with a default one), then we end
up with different version 21s. Oops.
Now, if you use profiles properly, they can be powerful, and the things
that they change may not--in your world, in your company, according to the
rules by which you are forced to "live" professionally--contribute to
variances in "your" version 21 and "my" version 21. For example, "your"
version 21 may--by use of an activated profile--include an extra header in
a MANIFEST.MF file somewhere that may make "your" version 21 different from
"my" version 21 (if we ran your version 21 through a hash function and mine
through the same hash function the outputs would be different). This is
technically, ruthlessly speaking a bad thing, since "version 21" now does
not denote anything (you have to add "with the special MANIFEST.MF header"
or "without the special MANIFEST.MF header" to further indicate what you're
talking about). But maybe no one cares in your world/company. That's fine.
When you start doing resource filtering using profiles, you're
probably--but not necessarily--heading into murky waters. Maybe those
resources are important and semantically significant to your artifacts. In
that case, you probably don't want to do it (so you don't have to have
discussions about which version 21 you and your coworkers are talking
about). On the other hand, maybe resource filtering via a profile in your
world is simply adding a property somewhere that has no real value except
to, say, identify the build machine--yeah, the two version 21s are
different, but not in any meaningful way, and it doesn't really matter in
some fashion which one of them you get). Repeatable? No, not
intrinsically. Bad? Not necessarily.
Profiles can also alter dependencies, which is almost--almost--always a
disaster unless you have the means to control when such builds are produced
and released into the world.
In your case, the real Maven people will bark and howl--justifiably, as
they have--because if you build your version 21 and I build your version
21, our version 21s are going to have different requirements and
configurations. We now have to specify to each other which version 21
we're talking about--the one with the message queue hosted on machine A or
the one referencing a message queue on machine B (the presence of machine A
or B is now an effective prerequisite of the build, but not reflected in
the version number).
My view is that if you have control of your ecosystem and consumers (i.e.
you can say with certainty who all will be producing artifacts and builds,
and who all will be consuming them, and you can further control how they do
those builds), then you are pretty much OK within that ecosystem using
profiles of almost any kind. Leak anything outside of that ecosystem and
things will go bad in a hurry.
Hope that helps.
Best,
Laird
--
http://about.me/lairdnelson
Re: Maven profiles and resource filtering
Posted by Ron Wheeler <rw...@artifact-software.com>.
Aside from Stephen's point which is, in itself, a reason not to use
profiles for this purpose, I would also suggest that there should be a
separation of church and state.
Programmers/developers should not be in charge of runtime environment
configurations and should produce artifacts that will run unchanged in
the environment configured by the system administrator or by an
automated installation tool.
There are well accepted solutions that make this possible. JNDI is one.
Installers are another.
Maven is development tool. Use it to develop code. Use something else to
configure run-time environments.
It should be possible to build your maven artifacts in way so that they
are tested on a programmers workstation, a CI environment, a test
environment and all the production environments without changing the
artifact.
This is a well established Best Practice.
Ignore it if you like but you have been made aware of a better way.
Ron
On 26/12/2012 1:54 PM, Niranjan Rao wrote:
> I read the blog entry and still confused about why we should not be
> using profiles. Perhaps I am just being dumb.
>
> As for our particular case, maven and resource filtering actually has
> been very helpful to us. We have multiple locations where development
> happens, each location has its own setup of database/message queue and
> other external resources application needs. With the help of resource
> filtering, we are able to set right options in the configuration files
> so that developers don't step on each other shoes. Each one gets his
> own "namespace" as far external resources are concerned. Every
> developer is required to execute the complete test suite in their own
> environment before pushing their changes.
>
> There are couple profiles we use during hudson builds - one meant for
> CI, almost same as developer's profile, does run destructive unit
> tests on DB - same tests developers are required to run. Other for
> actually creating the build, which "skips" the unit tests and does a
> build with proper properties so that build can work on QA servers and
> not destroy the data QA team has built.
>
> As far as I can see its just properties file and values get replaced
> in maven way. Except for QA build, same unit tests get executed, only
> difference being names/locations of external resources changed based
> on profile. Only "hack" I can think of is bit of dependency injection
> that sets db name slightly differently during unit tests. The reason
> behind this is developers not loosing the "working" data when the
> destructive units tests run. But again, its transparent to application
> and application just works with the interface, concrete implementation
> changes based on whether its running as part of main app or as unit test.
>
> Am I missing something?
>
> Regards,
>
> Niranjan
>
> On 12/21/2012 12:32 PM, Stephen Connolly wrote:
>> http://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-way.html
>>
>>
>> Please don't do maven the way you are doing it
>>
>> On Friday, 21 December 2012, Niranjan Rao wrote:
>>
>>> Greetings,
>>>
>>> We have bunch of profiles and corresponding resource filtering which
>>> all
>>> works great. One frequent problem that we encounter team members often
>>> forget to add new values in profile/filter property file of other
>>> profiles
>>> than the one they are currently using. Naturally results are
>>> disastrous.
>>> Normally we can find quickly which property is not filtered
>>> correctly and
>>> fix it but this is tedious.
>>>
>>> I am wondering if there is any way to catch missing properties at build
>>> time. That is when maven sees a property definition during filtering
>>> phase
>>> which has variable declaration and could not locate the value, can
>>> it raise
>>> the error and let the build fail?
>>>
>>> Thanks,
>>>
>>> Niranjan
>>>
>>> ------------------------------**------------------------------**---------
>>>
>>> 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
>
>
--
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
Re: Maven profiles and resource filtering
Posted by Niranjan Rao <nh...@gmail.com>.
I read the blog entry and still confused about why we should not be
using profiles. Perhaps I am just being dumb.
As for our particular case, maven and resource filtering actually has
been very helpful to us. We have multiple locations where development
happens, each location has its own setup of database/message queue and
other external resources application needs. With the help of resource
filtering, we are able to set right options in the configuration files
so that developers don't step on each other shoes. Each one gets his own
"namespace" as far external resources are concerned. Every developer is
required to execute the complete test suite in their own environment
before pushing their changes.
There are couple profiles we use during hudson builds - one meant for
CI, almost same as developer's profile, does run destructive unit tests
on DB - same tests developers are required to run. Other for actually
creating the build, which "skips" the unit tests and does a build with
proper properties so that build can work on QA servers and not destroy
the data QA team has built.
As far as I can see its just properties file and values get replaced in
maven way. Except for QA build, same unit tests get executed, only
difference being names/locations of external resources changed based on
profile. Only "hack" I can think of is bit of dependency injection that
sets db name slightly differently during unit tests. The reason behind
this is developers not loosing the "working" data when the destructive
units tests run. But again, its transparent to application and
application just works with the interface, concrete implementation
changes based on whether its running as part of main app or as unit test.
Am I missing something?
Regards,
Niranjan
On 12/21/2012 12:32 PM, Stephen Connolly wrote:
> http://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-way.html
>
> Please don't do maven the way you are doing it
>
> On Friday, 21 December 2012, Niranjan Rao wrote:
>
>> Greetings,
>>
>> We have bunch of profiles and corresponding resource filtering which all
>> works great. One frequent problem that we encounter team members often
>> forget to add new values in profile/filter property file of other profiles
>> than the one they are currently using. Naturally results are disastrous.
>> Normally we can find quickly which property is not filtered correctly and
>> fix it but this is tedious.
>>
>> I am wondering if there is any way to catch missing properties at build
>> time. That is when maven sees a property definition during filtering phase
>> which has variable declaration and could not locate the value, can it raise
>> the error and let the build fail?
>>
>> Thanks,
>>
>> Niranjan
>>
>> ------------------------------**------------------------------**---------
>> 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: Maven profiles and resource filtering
Posted by Maven User <ma...@gmail.com>.
Our pattern is anything in nexus comes from jenkins. All jobs have a
"prod" profile activated.
ALL this profile does is uses assembly descriptors that produce zips
instead of directories, includes stuff from src/main/resources in a
"templates" directory and inserts ERB style templating syntax so chef can
deploy.
If anything is missing, the absent property is caught during our nightly
"phoenix" build (and fix fast). No one is introducing properties moments
before going to production (and they'd not be incorporated anyway due to
our branch management strategy.
If you have profiles that you use for building a release - and those make
the output is RADICALLY different - then yeah, that's a terrible idea!!!
On Wed, Dec 26, 2012 at 1:23 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> Which profile was version 1.2.1 built with?
>
> 1 hour later... Oh that was built with dev and should have been built with
> prod... There was one hour of my life wasted
>
> You are following an anti-pattern. Please don't. You are free to ignore my
> advice, just don't come cribbing and moaning to me later when it all blows
> up in your face ;-)
>
> On Wednesday, 26 December 2012, Maven User wrote:
>
> > Stephen - can you clarify which points you're against?
> >
> > If there are profiles (and filter files) for every environment they
> deploy
> > to - then yeah, don't do that.
> >
> > BUT - for example, if there are exactly two (one for dev, defaults in
> poms,
> > overrides in each person's settings.xml) and one for prod (which inserts
> > OTHER templates to be use by an orchestration system against these "new"
> > templates), then I see no harm - but they'll have to make sure each
> > property is defined (somewhere).
> >
> >
> >
> >
> > On Fri, Dec 21, 2012 at 3:32 PM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com <javascript:;>> wrote:
> >
> > >
> > >
> >
> http://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-way.html
> > >
> > > Please don't do maven the way you are doing it
> > >
> > > On Friday, 21 December 2012, Niranjan Rao wrote:
> > >
> > > > Greetings,
> > > >
> > > > We have bunch of profiles and corresponding resource filtering which
> > all
> > > > works great. One frequent problem that we encounter team members
> often
> > > > forget to add new values in profile/filter property file of other
> > > profiles
> > > > than the one they are currently using. Naturally results are
> > disastrous.
> > > > Normally we can find quickly which property is not filtered
> correctly
> > > and
> > > > fix it but this is tedious.
> > > >
> > > > I am wondering if there is any way to catch missing properties at
> build
> > > > time. That is when maven sees a property definition during filtering
> > > phase
> > > > which has variable declaration and could not locate the value, can it
> > > raise
> > > > the error and let the build fail?
> > > >
> > > > Thanks,
> > > >
> > > > Niranjan
> > > >
> > > >
> > ------------------------------**------------------------------**---------
> > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> <javascript:;>
> > > > For additional commands, e-mail: users-help@maven.apache.org
> <javascript:;>
> > > >
> > > >
> > >
> >
>
Re: Maven profiles and resource filtering
Posted by Stephen Connolly <st...@gmail.com>.
Which profile was version 1.2.1 built with?
1 hour later... Oh that was built with dev and should have been built with
prod... There was one hour of my life wasted
You are following an anti-pattern. Please don't. You are free to ignore my
advice, just don't come cribbing and moaning to me later when it all blows
up in your face ;-)
On Wednesday, 26 December 2012, Maven User wrote:
> Stephen - can you clarify which points you're against?
>
> If there are profiles (and filter files) for every environment they deploy
> to - then yeah, don't do that.
>
> BUT - for example, if there are exactly two (one for dev, defaults in poms,
> overrides in each person's settings.xml) and one for prod (which inserts
> OTHER templates to be use by an orchestration system against these "new"
> templates), then I see no harm - but they'll have to make sure each
> property is defined (somewhere).
>
>
>
>
> On Fri, Dec 21, 2012 at 3:32 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>
> >
> >
> http://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-way.html
> >
> > Please don't do maven the way you are doing it
> >
> > On Friday, 21 December 2012, Niranjan Rao wrote:
> >
> > > Greetings,
> > >
> > > We have bunch of profiles and corresponding resource filtering which
> all
> > > works great. One frequent problem that we encounter team members often
> > > forget to add new values in profile/filter property file of other
> > profiles
> > > than the one they are currently using. Naturally results are
> disastrous.
> > > Normally we can find quickly which property is not filtered correctly
> > and
> > > fix it but this is tedious.
> > >
> > > I am wondering if there is any way to catch missing properties at build
> > > time. That is when maven sees a property definition during filtering
> > phase
> > > which has variable declaration and could not locate the value, can it
> > raise
> > > the error and let the build fail?
> > >
> > > Thanks,
> > >
> > > Niranjan
> > >
> > >
> ------------------------------**------------------------------**---------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org<javascript:;>
> > > For additional commands, e-mail: users-help@maven.apache.org<javascript:;>
> > >
> > >
> >
>
Re: Maven profiles and resource filtering
Posted by Maven User <ma...@gmail.com>.
Stephen - can you clarify which points you're against?
If there are profiles (and filter files) for every environment they deploy
to - then yeah, don't do that.
BUT - for example, if there are exactly two (one for dev, defaults in poms,
overrides in each person's settings.xml) and one for prod (which inserts
OTHER templates to be use by an orchestration system against these "new"
templates), then I see no harm - but they'll have to make sure each
property is defined (somewhere).
On Fri, Dec 21, 2012 at 3:32 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
>
> http://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-way.html
>
> Please don't do maven the way you are doing it
>
> On Friday, 21 December 2012, Niranjan Rao wrote:
>
> > Greetings,
> >
> > We have bunch of profiles and corresponding resource filtering which all
> > works great. One frequent problem that we encounter team members often
> > forget to add new values in profile/filter property file of other
> profiles
> > than the one they are currently using. Naturally results are disastrous.
> > Normally we can find quickly which property is not filtered correctly
> and
> > fix it but this is tedious.
> >
> > I am wondering if there is any way to catch missing properties at build
> > time. That is when maven sees a property definition during filtering
> phase
> > which has variable declaration and could not locate the value, can it
> raise
> > the error and let the build fail?
> >
> > Thanks,
> >
> > Niranjan
> >
> > ------------------------------**------------------------------**---------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: Maven profiles and resource filtering
Posted by Stephen Connolly <st...@gmail.com>.
http://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-way.html
Please don't do maven the way you are doing it
On Friday, 21 December 2012, Niranjan Rao wrote:
> Greetings,
>
> We have bunch of profiles and corresponding resource filtering which all
> works great. One frequent problem that we encounter team members often
> forget to add new values in profile/filter property file of other profiles
> than the one they are currently using. Naturally results are disastrous.
> Normally we can find quickly which property is not filtered correctly and
> fix it but this is tedious.
>
> I am wondering if there is any way to catch missing properties at build
> time. That is when maven sees a property definition during filtering phase
> which has variable declaration and could not locate the value, can it raise
> the error and let the build fail?
>
> Thanks,
>
> Niranjan
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>