My apologies. I do too much rambling late nights without getting to the
point. Let me clarify. Making a distinction between production resources and
development resources is important even outside of the idea of profiles.
Consider the following:
res
|
conf
| |
| mytemplate.xsl
| JDBC-JNDIconf.xml
|
dev
|
JDBC-JNDIconf.xml
There is a hidden assumption here that everything under res folder is
applicable to both development and production while only the stuff under
res/dev should apply to development. This also puts onus on the build system
to imply a deployment order (extra JDNI configs should only be deployed
after the first jndi config) which is bad practice in any build system. Lets
pretend the xsl file should be used for both while the JNDI stuff should
actually only deploy for production. The distinction should be made in the
project structure to reflect this idea. The resulting layout is:
res
|
conf
| |
| mytemplate.xsl
|
prod
| |
| JDBC-JNDIconf.xml
dev
|
JDBC-JNDIconf.xml
Here the distinction is clear between production files and development files
and global files that apply to all scenarios. You need not concern your
build system with copy-order here because the JDBC-JNDIconf is clearly
defined by the project structure as an either or deployment. It becomes
straight forward to define profiles that simply pick up profiles for either
production or development and push them to the proper location. I hope that
explains a little more.
mljv wrote:
>
> so what is best practice here?
>
> even my exclude statemnt doesn't help as i thought. If i run "production"
> profile after development profile without mvn clean i don't get the right
> version. thats all much too difficult in my opinion.
>
> regards
> Janning
>
> Am Dienstag, 12. Februar 2008 05:03 schrieb Clifton:
>> I'll respond by saying there is no garaunteed order of operations with
>> resource copying (as well as other actions that take place within the
>> same
>> build phase). Your pom states that both resources from development and
>> production should be considered when the env property is set to
>> development. (Incidentally you could more easily take a "-P development"
>> switch on the cmd line to activate the dev profile. I'd only suggest
>> property activation when you have something like an external script that
>> will automatically set the property. Otherwise it's slightly less work to
>> call the profile outright.) When considering resources from two locations
>> there is no garauntee that on set of resources will overwrite the other.
>> Profiles aren't meant to establish/imply fine grained execution order.
>> What
>> you really should do is conditionally include your prod resources for
>> only
>> production profiles. There is a much bigger problem of mixing dev and
>> production resources in a build. If there are common resources between
>> the
>> two then the dir structure should be changed to reflect that.
>>
>> mljv wrote:
>> > sorry, i clicked send to early... so here is my full post:
>> >
>> > Hi,
>> >
>> > i am struggeling with profiles and resources.
>> >
>> > I have
>> > src/main/resources/application.properties
>> > src/main/dev-resources/application.properties
>> >
>> > my profiles in pom.xml
>> >
>> > <profiles>
>> > <profile>
>> > <id>production</id>
>> > <activation>
>> > <activeByDefault>true</activeByDefault>
>> > </activation>
>> > <properties>
>> > <env>production</env>
>> > </properties>
>> > </profile>
>> > <profile>
>> > <id>development</id>
>> > <activation>
>> > <property>
>> > <name>env</name>
>> > <value>development</value>
>> > </property>
>> > </activation>
>> > <build>
>> > <resources>
>> > <resource>
>> >
>> > <directory>src/main/resources</directory>
>> >
>> > <!-- this exclude is needed,
>> > why? -->
>> > <excludes>
>> >
>> > <exclude>application.properties</exclude>
>> > </excludes>
>> >
>> > </resource>
>> > <resource>
>> >
>> > <directory>src/main/development-resources</directory>
>> > </resource>
>> > </resources>
>> > </build>
>> > </profile>
>> > </profiles>
>> >
>> > then i do
>> > $ mvn -Denv=development clean process-resources
>> >
>> > and it shows me that my src/main/dev-resources/application.properties
>> > was
>> > copied to target/classes/
>> >
>> > If i drop exclude i see src/main/resources/application.properties in
>> > target/classes
>> >
>> > Why do i need to exclude it? It should be overwritten, shouldn't it?
>> >
>> > kind regards,
>> > Janning
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
> kind regards,
> janning
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Profiles-and-resources-tp15418940s177p15434255.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
