You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Ryan Wexler <ry...@iridiumsuite.com> on 2012/02/29 21:10:34 UTC
using build profiles for WAR plugin
I am trying to create different WAR builds using profiles for my different
production sites. Each site requires different configuration files. I
think I am confused on how to use build profiles.
My plan was this:
1)Create a base configuration for the war plugin that includes my basic
configuration:
<build>
.
.
.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.2</version>
<configuration>
<webResources>
<resource>
<directory>${basedir}/src/main/conf/server</directory>
<includes>
<include>log4j.xml</include>
</includes>
<targetPath>WEB-INF/classes</targetPath>
</resource>
<resource>
<directory>${basedir}/src/main/reports</directory>
<targetPath>WEB-INF/reports</targetPath>
</resource>
<resource>
<directory>${basedir}/src/main/baseconf</directory>
<targetPath>WEB-INF</targetPath>
</resource>
</webResources>
</configuration>
</plugin>
2)Now I need to add the special configuration for each production site so I
create a profile with each with additional configuration files:
<profiles>
<profile>
<id>site1</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.2</version>
<configuration>
<webResources>
<resource>
<directory>${basedir}/src/main/conf/server/production-site-1</directory>
<targetPath>WEB-INF</targetPath>
</resource>
</webResources>
</configuration>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>site2</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.2</version>
<configuration>
<webResources>
<resource>
<directory>${basedir}/src/main/conf/server/production-site-2</directory>
<targetPath>WEB-INF</targetPath>
</resource>
</webResources>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>
3)mvn clean install war:war -o -Psite1
This doesn't work. The war file gets built with the base configuratio
files but the special configuration items in the profile don't get moved
over.
The output actually says it is copying those files over but I dont' see
them. I wonder if they then get deleted?
My understanding was that the profile would add additional resources to
those already configured in the base build. Is that behavior incorrect?
Do I need to redo the entire webResources section in the profile?
thanks
-ryan
Re: using build profiles for WAR plugin
Posted by Ron Wheeler <rw...@artifact-software.com>.
Do not touch profiles until you have your build working without them.
As near as I can tell from the traffic here, they are intrinsically evil
and should only be used in very specific situations.
They are not used for "normal" software projects.
They are not suitable for new Maven users.
They will lead you down the path to Maven hell and cause you no end of
heartache.
Ron
On 01/03/2012 1:30 PM, offbyone wrote:
> I appreciate the feedback, but I am struggling to follow, clearly I don't
> understand "the maven way".
>
> I am new to maven, based on the documentation and the specification it seems
> like profiles are used to create different versions of a deployment package.
> Why would profiles be there if not for that purpose?
>
> More importantly, why would maven have such a rich properties and resource
> filtering feature set if the maven way is to externalize all this
> information?
>
> Maven is suppose to be a build tool, but you are telling me I shouldn't put
> build configuration data in it. It seems like you guys are saying only to
> use the dependency management/repository aspect of it.
>
> Would love some clarification.
> thanks
>
>
>
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5528742.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> 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: using build profiles for WAR plugin
Posted by Ron Wheeler <rw...@artifact-software.com>.
I am happy to contribute in the forum and I have some blog items at
blog.artifact-software.com/tech that might help but you would be much
better served by Wayne or Stephen as they are true experts.
At http://maven.apache.org/team-list.html you get a list of the team
members who work on Maven and they are both in the list.
In our use of Spring, we used JNDI to separate deployment from
development and used the Jetspeed portal framework which separated the
look and feel customization from our code which gave us a different
problem in generating our WAR files.
We broke our application into about 70 projects with code that made JARs
or WARs and 10-12 JAR projects with just dependencies (Apache utilities,
Spring-MySQL-Hibernate-Tomcat, JasperReports, CXF, etc...) that we
loaded into Tomcat's shared library to get them out of the WARs. Our WAR
files only had our code in them with the Spring and JSF configuration files.
We were building for an SaaS so we had more permanent servers for
production and test so the JNDI solution worked well.
Thanks for the offer. I am pleased that we are able to help.
Ron
On 01/03/2012 7:40 PM, offbyone wrote:
> Ron- You interested in a couple hours of contract work. I would happily
> pay you to help me through this?
>
> -ryan
>
> On Thu, Mar 1, 2012 at 12:56 PM, Ron Wheeler [via Maven]<
> ml-node+s40175n5529204h7@n5.nabble.com> wrote:
>
>> On 01/03/2012 2:43 PM, offbyone wrote:
>>
>>> Ok so I should create a base pom with a war configuration and then a
>> separate
>>> pom for each site that depends on this with overlays to add the extra
>>> configuration file.
>>> I will try.
>>>
>>> If I am interpreting your comments correctly, profiles allow for a user
>> to
>>> flaten a maven build deployment, but this is a bad practice and it is
>> better
>>> to make your maven structure deep.
>>>
>>> So are profiles going to be deprecated? I would think I am not alone
>> in
>>> getting turned down the wrong path because most of the
>> documentation/howtos
>>> I have found point to using profiles.
>> There are some uses for profiles that seem harmless so it is a
>> documentation issue.
>>
>> It is fairly common in Apache documentation for the programmers to make
>> a big deal about all the wonderful things that the package can do.
>> They are not particularly concerned about "Best Practices".
>>
>> The most common usage is often left out of the documentation since it is
>> "dull" or not very impressive.
>> This sometimes means that obscure usage of features or seldom used
>> features are heavily documented while the main use case is not described.
>>
>> New Maven users often fall into the trap that you were headed into.
>>
>> A really simple "Best Practice" that most people use, is hard to find in
>> the documentation while an obscure "Worst Practice" is described because
>> it shows how clever the software developers are and how powerful the
>> product is.
>>
>> There should be a "Best Practice" section on the Maven site describing
>> the best way to implement the common software development patterns.
>>
>> There are not really a lot of cases to consider but every new Maven user
>> has to sort out their own case.
>>
>> Ron
>>
>>
>>> --
>>> View this message in context:
>> http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5528994.html
>>
>>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5529204&i=0>
>>> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5529204&i=1>
>>>
>>>
>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: [hidden email]<http://user/SendEmail.jtp?type=node&node=5529204&i=2>
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5529204&i=3>
>> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5529204&i=4>
>>
>> ------------------------------
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5529204.html
>> To unsubscribe from using build profiles for WAR plugin, click here<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5525954&code=cnlhbkBpcmlkaXVtc3VpdGUuY29tfDU1MjU5NTR8NzI4MTgyOTE0>
>> .
>> NAML<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5529755.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: using build profiles for WAR plugin
Posted by offbyone <ry...@iridiumsuite.com>.
Ron- You interested in a couple hours of contract work. I would happily
pay you to help me through this?
-ryan
On Thu, Mar 1, 2012 at 12:56 PM, Ron Wheeler [via Maven] <
ml-node+s40175n5529204h7@n5.nabble.com> wrote:
> On 01/03/2012 2:43 PM, offbyone wrote:
>
> > Ok so I should create a base pom with a war configuration and then a
> separate
> > pom for each site that depends on this with overlays to add the extra
> > configuration file.
> > I will try.
> >
> > If I am interpreting your comments correctly, profiles allow for a user
> to
> > flaten a maven build deployment, but this is a bad practice and it is
> better
> > to make your maven structure deep.
> >
> > So are profiles going to be deprecated? I would think I am not alone
> in
> > getting turned down the wrong path because most of the
> documentation/howtos
> > I have found point to using profiles.
> There are some uses for profiles that seem harmless so it is a
> documentation issue.
>
> It is fairly common in Apache documentation for the programmers to make
> a big deal about all the wonderful things that the package can do.
> They are not particularly concerned about "Best Practices".
>
> The most common usage is often left out of the documentation since it is
> "dull" or not very impressive.
> This sometimes means that obscure usage of features or seldom used
> features are heavily documented while the main use case is not described.
>
> New Maven users often fall into the trap that you were headed into.
>
> A really simple "Best Practice" that most people use, is hard to find in
> the documentation while an obscure "Worst Practice" is described because
> it shows how clever the software developers are and how powerful the
> product is.
>
> There should be a "Best Practice" section on the Maven site describing
> the best way to implement the common software development patterns.
>
> There are not really a lot of cases to consider but every new Maven user
> has to sort out their own case.
>
> Ron
>
>
> > --
> > View this message in context:
> http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5528994.html
>
> > Sent from the Maven - Users mailing list archive at Nabble.com.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5529204&i=0>
> > For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5529204&i=1>
> >
> >
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: [hidden email]<http://user/SendEmail.jtp?type=node&node=5529204&i=2>
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5529204&i=3>
> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5529204&i=4>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5529204.html
> To unsubscribe from using build profiles for WAR plugin, click here<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5525954&code=cnlhbkBpcmlkaXVtc3VpdGUuY29tfDU1MjU5NTR8NzI4MTgyOTE0>
> .
> NAML<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5529755.html
Sent from the Maven - Users mailing list archive at Nabble.com.
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
Posted by Ivalo <iv...@iki.fi>.
My day job company is assosiate member of Eclipse so of course Eclipse
is tool to use.
Markku
On 2.3.2012 18:14, Wayne Fay wrote:
>> You don't understand how Eclipse IDE works. Eclipse does not have different
>> classpaths for testing and actual runtime. So Eclipse basic design is
>> faulty. There is bug open since 2008 to provide means to tell Eclipse that
> ...
>> Of course NetBeans and IntelliJ has correct way to do things but they are
>> not an option.
> Help me understand this line of thinking...
>
> Product A is demonstrably broken for what we need and has been since 2008.
> Products B and C support our needs perfectly well. One is free, one is not.
> And yet B and C are "not an option."
>
> This doesn't sound rational to me. Why are they not an option for you?
> I would challenge that assertion with whoever is making the decision.
>
> Wayne
>
> ---------------------------------------------------------------------
> 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: using build profiles for WAR plugin [maven-eclipse-plugin]
Posted by Ivalo <iv...@iki.fi>.
My day job company is associate member of Eclipse so of course Eclipse
is tool to use.
Markku
On 2.3.2012 18:14, Wayne Fay wrote:
>> You don't understand how Eclipse IDE works. Eclipse does not have different
>> classpaths for testing and actual runtime. So Eclipse basic design is
>> faulty. There is bug open since 2008 to provide means to tell Eclipse that
> ...
>> Of course NetBeans and IntelliJ has correct way to do things but they are
>> not an option.
> Help me understand this line of thinking...
>
> Product A is demonstrably broken for what we need and has been since 2008.
> Products B and C support our needs perfectly well. One is free, one is not.
> And yet B and C are "not an option."
>
> This doesn't sound rational to me. Why are they not an option for you?
> I would challenge that assertion with whoever is making the decision.
>
> Wayne
>
> ---------------------------------------------------------------------
> 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: using build profiles for WAR plugin [maven-eclipse-plugin]
Posted by Wayne Fay <wa...@gmail.com>.
> You don't understand how Eclipse IDE works. Eclipse does not have different
> classpaths for testing and actual runtime. So Eclipse basic design is
> faulty. There is bug open since 2008 to provide means to tell Eclipse that
...
> Of course NetBeans and IntelliJ has correct way to do things but they are
> not an option.
Help me understand this line of thinking...
Product A is demonstrably broken for what we need and has been since 2008.
Products B and C support our needs perfectly well. One is free, one is not.
And yet B and C are "not an option."
This doesn't sound rational to me. Why are they not an option for you?
I would challenge that assertion with whoever is making the decision.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
Posted by Barrie Treloar <ba...@gmail.com>.
On Sat, Mar 3, 2012 at 6:28 AM, Markku Saarela <ma...@iki.fi> wrote:
> Our releases do not have any configuration files in artifact's, instead
> manifest classpaths has directory name to point directory that has those
> files. We use separate build to assembly different configurations into
> different environments putting configurations in place.
>
> I like to use Eclipse ability to hot deploy modifications of code into
> server while debugging development trunk code.
>
> So what you say and my experience it is impossible to use multi-module
> project imported with project references for developing software with hot
> deployment and also unit testing without having profiles to set resource
> directories for Eclipse unit testing and deploying into server.
There is nothing stopping you creating an extra level of abstraction,
i.e. "<mymodule>-unittests"
You move all your unit tests out of the original module "<mymodule>"
and into "<mymodule>-unittests".
Obviously "<mymodule>-unittests" would depend on "<mymodule>"
That way you can run unit tests, but you would only ever deploy
"<mymodule>", with no way to pollute with unit tests.
p.s. Given Eclipse is open source, if this was a defect that you
*really* cared about, you should provide a patch.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
Posted by Markku Saarela <ma...@iki.fi>.
Our releases do not have any configuration files in artifact's, instead
manifest classpaths has directory name to point directory that has those
files. We use separate build to assembly different configurations into
different environments putting configurations in place.
I like to use Eclipse ability to hot deploy modifications of code into
server while debugging development trunk code.
So what you say and my experience it is impossible to use multi-module
project imported with project references for developing software with
hot deployment and also unit testing without having profiles to set
resource directories for Eclipse unit testing and deploying into server.
It's not so convenient to go outside IDE to deploy artifact into server
in order to debug / test modifications made.
Markku
On 2.3.2012 21:29, Ron Wheeler wrote:
> I am not sure if this directly answers your question but perhaps a bit
> of background helps.
>
> We use Eclipse STS which comes with Maven support built in. We used to
> waste so much time upgrading Eclipse and getting everyone configured
> in the same way.
> Now it is a single download (BIG) to get everything that you need
> except Subversion.
>
> We have individual projects since the project is divided up on
> functional lines with core modules for the database access and some
> modules that can best be described as utilities (messaging for example).
> This means that for any maintenance activity almost all of the modules
> are not affected.
> In addition, modules are worked on by different people.
> No one would have all of modules checked out at once. Certainly you
> would not have them open in Eclipse.
>
> We use SNAPSHOTs during development and maintenance.
> We do not make all of the 70 modules carry the same release version.
> It is possible to see a version 1.10.3 of the overall application
> running with most of the WAR files as version 1.10 if they were bug
> free up to the 1.10.3 release.
>
> We do some unit testing and do most of our testing on the developer's
> workstation.
> We have at least 1 test server where developers can test in an
> environment that is almost identical to production and can be tested
> by the client(s). More than 1 if we have a big maintenance issue while
> we are trying to get a major development tested. We are starting to
> use the cloud for this so the actual number of test servers
> potentially available is close to infinite.
>
> We deploy the WAR files by hand to the appropriate server.
>
> We use JNDI to support our Spring configurations so we do not have any
> variation in the WARs between test and different production servers.
>
> This is certainly not the only way to do things but I have never heard
> of any problems with test classes or test configurations leaking into
> production.
>
> The build is described in the master POM for the project. The master
> POM is the key to every project and contains everything that is common
> between modules so the module poms are pretty small.
>
> Below is the build description from the master POM for a project.
> I hope that this helps a bit.
>
> Ron
>
> <build>
> <sourceDirectory>src/main</sourceDirectory>
> <scriptSourceDirectory>src/main/scripts</scriptSourceDirectory>
> <testSourceDirectory>src/test</testSourceDirectory>
> <outputDirectory>target/classes</outputDirectory>
> <testOutputDirectory>target/test-classes</testOutputDirectory>
> <resources>
> <resource>
> <directory>src/main</directory>
> <excludes>
> <exclude>**/*.java</exclude>
> </excludes>
> </resource>
> </resources>
> <testResources>
> <testResource>
> <directory>test</directory>
> <excludes>
> <exclude>**/*.java</exclude>
> </excludes>
> </testResource>
> </testResources>
> <directory>target</directory>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-compiler-plugin</artifactId>
> <version>2.3.2</version>
> <configuration>
> <encoding>UTF-8</encoding>
> <source>1.6</source>
> <target>1.6</target>
> </configuration>
> </plugin>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-resources-plugin</artifactId>
> <version>2.5</version>
> <configuration>
> <encoding>UTF-8</encoding>
> </configuration>
> </plugin>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-war-plugin</artifactId>
> <version>2.2</version>
> <configuration>
> <warSourceDirectory>WebContent</warSourceDirectory>
> <archive>
> <manifest>
> <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
> <addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
> </manifest>
> </archive>
> </configuration>
> </plugin>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-jar-plugin</artifactId>
> <version>2.4</version>
> <configuration>
> <archive>
> <manifest>
> <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
> <addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
> </manifest>
> </archive>
> </configuration>
> </plugin>
>
> </plugins>
> <pluginManagement>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-assembly-plugin</artifactId>
> <version>2.3</version>
> <executions>
> <execution>
> <phase>package</phase>
> <goals>
> <goal>single</goal>
> </goals>
> <configuration>
> <archive>
> <manifest>
> <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
> <addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
> </manifest>
> </archive>
> <descriptorRefs>
> <descriptorRef>
> jar-with-dependencies
> </descriptorRef>
> </descriptorRefs>
>
> </configuration>
> </execution>
> </executions>
> </plugin>
>
> </plugins>
> </pluginManagement>
> </build>
>
> Ron
>
>
> On 02/03/2012 2:00 PM, Markku Saarela wrote:
>> In multi-module project i hit the same problem with m2e and
>> maven-eclipse-plugin. Are you saying not to import multi-module
>> projects into Eclipse, instead every module separately? Or you don't
>> use server plugins to deploy application instead you deploy outside
>> Eclipse and use remote application debugging? But still this does not
>> prevent unit tests failing with multi-module configuration because of
>> this dependent project classpath has those artifacts in it's
>> classpath before it's own ones.
>>
>> So if you have solution to this i am more than happy to hear it.
>>
>> Markku
>>
>> On 2.3.2012 17:50, Ron Wheeler wrote:
>>> We have been developing and maintaining a large portal application
>>> with over 70 WAR files in Eclipse with Maven since 2007 and several
>>> smaller portals and standalone applications. We have not had this
>>> problem.
>>>
>>> That is not to say that I am an expert in Eclipse but we know enough
>>> to make it work.
>>>
>>> We do not use maven-eclipse-plug-in. We use the assembly plug-in to
>>> build our war files.
>>> Perhaps that is the difference.
>>>
>>> We also deploy to Tomcat which might be a better servlet engine than
>>> Glassfish.
>>>
>>> I am not sure how relevant our experience is to your problem but if
>>> I can provide any additional information that you think might help,
>>> let me know.
>>>
>>> Ron
>>>
>>>
>>> On 02/03/2012 10:19 AM, Markku Saarela wrote:
>>>> Hi,
>>>>
>>>> You don't understand how Eclipse IDE works. Eclipse does not have
>>>> different classpaths for testing and actual runtime. So Eclipse
>>>> basic design is faulty. There is bug open since 2008 to provide
>>>> means to tell Eclipse that which are test sources and not include
>>>> them to runtime classpath.
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=224708
>>>>
>>>> So everything under src/test goes also into GlassFish server if you
>>>> deploy application in Eclipse. That causes that those unit test
>>>> properties and configuration and classes are picked first and they
>>>> are effective and application does not work.
>>>>
>>>> Even worst if you have multi-module project and B module is
>>>> dependent from A and A project defines SPI interface and has in
>>>> src/test/java test implementation for that and of course in
>>>> src/test/resources/META-INF/services SPI file for exposing that
>>>> test SPI implementation then if B implements also that SPI
>>>> interface and put SPI file in src/main/resources/META-INF/services,
>>>> you cannot test you implementation via ServiceLoader because it
>>>> pick's that module A test implementation. Same goes for properties
>>>> and everything else.
>>>>
>>>> Of course NetBeans and IntelliJ has correct way to do things but
>>>> they are not an option.
>>>>
>>>> Markku
>>>>
>>>>
>>>> On 2.3.2012 15:15, Ron Wheeler wrote:
>>>>> On 02/03/2012 1:32 AM, Markku Saarela wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Developing with Eclipse IDE and JavaEE server using
>>>>>> maven-eclipse-plugin you have to use profiles, because Eclipse
>>>>>> does not isolate test code and test resources.
>>>>> Eclipse does
>>>>> /src/main/.... code
>>>>> /src/test ... test code and resources
>>>>>
>>>>> You need to set your maven properly but it works fine unless I
>>>>> don't understand your issue.
>>>>>
>>>>>>
>>>>>> Only way to do it what i have figured out is to have two profiles
>>>>>> one for running application in app server and another for unit
>>>>>> testing same code. Those profiles has only resources and
>>>>>> testResources definitions.
>>>>>>
>>>>>> Separating test code for separate code is not an option, because
>>>>>> then Sonar reports 0 % coverage.
>>>>>>
>>>>>> rgds,
>>>>>>
>>>>>> Markku
>>>>>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
Posted by Ron Wheeler <rw...@artifact-software.com>.
I am not sure if this directly answers your question but perhaps a bit
of background helps.
We use Eclipse STS which comes with Maven support built in. We used to
waste so much time upgrading Eclipse and getting everyone configured in
the same way.
Now it is a single download (BIG) to get everything that you need except
Subversion.
We have individual projects since the project is divided up on
functional lines with core modules for the database access and some
modules that can best be described as utilities (messaging for example).
This means that for any maintenance activity almost all of the modules
are not affected.
In addition, modules are worked on by different people.
No one would have all of modules checked out at once. Certainly you
would not have them open in Eclipse.
We use SNAPSHOTs during development and maintenance.
We do not make all of the 70 modules carry the same release version. It
is possible to see a version 1.10.3 of the overall application running
with most of the WAR files as version 1.10 if they were bug free up to
the 1.10.3 release.
We do some unit testing and do most of our testing on the developer's
workstation.
We have at least 1 test server where developers can test in an
environment that is almost identical to production and can be tested by
the client(s). More than 1 if we have a big maintenance issue while we
are trying to get a major development tested. We are starting to use the
cloud for this so the actual number of test servers potentially
available is close to infinite.
We deploy the WAR files by hand to the appropriate server.
We use JNDI to support our Spring configurations so we do not have any
variation in the WARs between test and different production servers.
This is certainly not the only way to do things but I have never heard
of any problems with test classes or test configurations leaking into
production.
The build is described in the master POM for the project. The master POM
is the key to every project and contains everything that is common
between modules so the module poms are pretty small.
Below is the build description from the master POM for a project.
I hope that this helps a bit.
Ron
<build>
<sourceDirectory>src/main</sourceDirectory>
<scriptSourceDirectory>src/main/scripts</scriptSourceDirectory>
<testSourceDirectory>src/test</testSourceDirectory>
<outputDirectory>target/classes</outputDirectory>
<testOutputDirectory>target/test-classes</testOutputDirectory>
<resources>
<resource>
<directory>src/main</directory>
<excludes>
<exclude>**/*.java</exclude>
</excludes>
</resource>
</resources>
<testResources>
<testResource>
<directory>test</directory>
<excludes>
<exclude>**/*.java</exclude>
</excludes>
</testResource>
</testResources>
<directory>target</directory>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<encoding>UTF-8</encoding>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.5</version>
<configuration>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.2</version>
<configuration>
<warSourceDirectory>WebContent</warSourceDirectory>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
<addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
</manifest>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<configuration>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
<addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
</manifest>
</archive>
</configuration>
</plugin>
</plugins>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.3</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
<addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
</manifest>
</archive>
<descriptorRefs>
<descriptorRef>
jar-with-dependencies
</descriptorRef>
</descriptorRefs>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
Ron
On 02/03/2012 2:00 PM, Markku Saarela wrote:
> In multi-module project i hit the same problem with m2e and
> maven-eclipse-plugin. Are you saying not to import multi-module
> projects into Eclipse, instead every module separately? Or you don't
> use server plugins to deploy application instead you deploy outside
> Eclipse and use remote application debugging? But still this does not
> prevent unit tests failing with multi-module configuration because of
> this dependent project classpath has those artifacts in it's classpath
> before it's own ones.
>
> So if you have solution to this i am more than happy to hear it.
>
> Markku
>
> On 2.3.2012 17:50, Ron Wheeler wrote:
>> We have been developing and maintaining a large portal application
>> with over 70 WAR files in Eclipse with Maven since 2007 and several
>> smaller portals and standalone applications. We have not had this
>> problem.
>>
>> That is not to say that I am an expert in Eclipse but we know enough
>> to make it work.
>>
>> We do not use maven-eclipse-plug-in. We use the assembly plug-in to
>> build our war files.
>> Perhaps that is the difference.
>>
>> We also deploy to Tomcat which might be a better servlet engine than
>> Glassfish.
>>
>> I am not sure how relevant our experience is to your problem but if I
>> can provide any additional information that you think might help, let
>> me know.
>>
>> Ron
>>
>>
>> On 02/03/2012 10:19 AM, Markku Saarela wrote:
>>> Hi,
>>>
>>> You don't understand how Eclipse IDE works. Eclipse does not have
>>> different classpaths for testing and actual runtime. So Eclipse
>>> basic design is faulty. There is bug open since 2008 to provide
>>> means to tell Eclipse that which are test sources and not include
>>> them to runtime classpath.
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=224708
>>>
>>> So everything under src/test goes also into GlassFish server if you
>>> deploy application in Eclipse. That causes that those unit test
>>> properties and configuration and classes are picked first and they
>>> are effective and application does not work.
>>>
>>> Even worst if you have multi-module project and B module is
>>> dependent from A and A project defines SPI interface and has in
>>> src/test/java test implementation for that and of course in
>>> src/test/resources/META-INF/services SPI file for exposing that test
>>> SPI implementation then if B implements also that SPI interface and
>>> put SPI file in src/main/resources/META-INF/services, you cannot
>>> test you implementation via ServiceLoader because it pick's that
>>> module A test implementation. Same goes for properties and
>>> everything else.
>>>
>>> Of course NetBeans and IntelliJ has correct way to do things but
>>> they are not an option.
>>>
>>> Markku
>>>
>>>
>>> On 2.3.2012 15:15, Ron Wheeler wrote:
>>>> On 02/03/2012 1:32 AM, Markku Saarela wrote:
>>>>> Hi,
>>>>>
>>>>> Developing with Eclipse IDE and JavaEE server using
>>>>> maven-eclipse-plugin you have to use profiles, because Eclipse
>>>>> does not isolate test code and test resources.
>>>> Eclipse does
>>>> /src/main/.... code
>>>> /src/test ... test code and resources
>>>>
>>>> You need to set your maven properly but it works fine unless I
>>>> don't understand your issue.
>>>>
>>>>>
>>>>> Only way to do it what i have figured out is to have two profiles
>>>>> one for running application in app server and another for unit
>>>>> testing same code. Those profiles has only resources and
>>>>> testResources definitions.
>>>>>
>>>>> Separating test code for separate code is not an option, because
>>>>> then Sonar reports 0 % coverage.
>>>>>
>>>>> rgds,
>>>>>
>>>>> Markku
>>>>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
Posted by Markku Saarela <ma...@iki.fi>.
In multi-module project i hit the same problem with m2e and
maven-eclipse-plugin. Are you saying not to import multi-module projects
into Eclipse, instead every module separately? Or you don't use server
plugins to deploy application instead you deploy outside Eclipse and use
remote application debugging? But still this does not prevent unit tests
failing with multi-module configuration because of this dependent
project classpath has those artifacts in it's classpath before it's own
ones.
So if you have solution to this i am more than happy to hear it.
Markku
On 2.3.2012 17:50, Ron Wheeler wrote:
> We have been developing and maintaining a large portal application
> with over 70 WAR files in Eclipse with Maven since 2007 and several
> smaller portals and standalone applications. We have not had this
> problem.
>
> That is not to say that I am an expert in Eclipse but we know enough
> to make it work.
>
> We do not use maven-eclipse-plug-in. We use the assembly plug-in to
> build our war files.
> Perhaps that is the difference.
>
> We also deploy to Tomcat which might be a better servlet engine than
> Glassfish.
>
> I am not sure how relevant our experience is to your problem but if I
> can provide any additional information that you think might help, let
> me know.
>
> Ron
>
>
> On 02/03/2012 10:19 AM, Markku Saarela wrote:
>> Hi,
>>
>> You don't understand how Eclipse IDE works. Eclipse does not have
>> different classpaths for testing and actual runtime. So Eclipse basic
>> design is faulty. There is bug open since 2008 to provide means to
>> tell Eclipse that which are test sources and not include them to
>> runtime classpath. https://bugs.eclipse.org/bugs/show_bug.cgi?id=224708
>>
>> So everything under src/test goes also into GlassFish server if you
>> deploy application in Eclipse. That causes that those unit test
>> properties and configuration and classes are picked first and they
>> are effective and application does not work.
>>
>> Even worst if you have multi-module project and B module is dependent
>> from A and A project defines SPI interface and has in src/test/java
>> test implementation for that and of course in
>> src/test/resources/META-INF/services SPI file for exposing that test
>> SPI implementation then if B implements also that SPI interface and
>> put SPI file in src/main/resources/META-INF/services, you cannot test
>> you implementation via ServiceLoader because it pick's that module A
>> test implementation. Same goes for properties and everything else.
>>
>> Of course NetBeans and IntelliJ has correct way to do things but they
>> are not an option.
>>
>> Markku
>>
>>
>> On 2.3.2012 15:15, Ron Wheeler wrote:
>>> On 02/03/2012 1:32 AM, Markku Saarela wrote:
>>>> Hi,
>>>>
>>>> Developing with Eclipse IDE and JavaEE server using
>>>> maven-eclipse-plugin you have to use profiles, because Eclipse does
>>>> not isolate test code and test resources.
>>> Eclipse does
>>> /src/main/.... code
>>> /src/test ... test code and resources
>>>
>>> You need to set your maven properly but it works fine unless I don't
>>> understand your issue.
>>>
>>>>
>>>> Only way to do it what i have figured out is to have two profiles
>>>> one for running application in app server and another for unit
>>>> testing same code. Those profiles has only resources and
>>>> testResources definitions.
>>>>
>>>> Separating test code for separate code is not an option, because
>>>> then Sonar reports 0 % coverage.
>>>>
>>>> rgds,
>>>>
>>>> Markku
>>>>
>>>> On 1.3.2012 22:55, Ron Wheeler wrote:
>>>>> On 01/03/2012 2:43 PM, offbyone wrote:
>>>>>> Ok so I should create a base pom with a war configuration and
>>>>>> then a separate
>>>>>> pom for each site that depends on this with overlays to add the
>>>>>> extra
>>>>>> configuration file.
>>>>>> I will try.
>>>>>>
>>>>>> If I am interpreting your comments correctly, profiles allow for
>>>>>> a user to
>>>>>> flaten a maven build deployment, but this is a bad practice and
>>>>>> it is better
>>>>>> to make your maven structure deep.
>>>>>>
>>>>>> So are profiles going to be deprecated? I would think I am not
>>>>>> alone in
>>>>>> getting turned down the wrong path because most of the
>>>>>> documentation/howtos
>>>>>> I have found point to using profiles.
>>>>> There are some uses for profiles that seem harmless so it is a
>>>>> documentation issue.
>>>>>
>>>>> It is fairly common in Apache documentation for the programmers to
>>>>> make a big deal about all the wonderful things that the package
>>>>> can do.
>>>>> They are not particularly concerned about "Best Practices".
>>>>>
>>>>> The most common usage is often left out of the documentation since
>>>>> it is "dull" or not very impressive.
>>>>> This sometimes means that obscure usage of features or seldom used
>>>>> features are heavily documented while the main use case is not
>>>>> described.
>>>>>
>>>>> New Maven users often fall into the trap that you were headed into.
>>>>>
>>>>> A really simple "Best Practice" that most people use, is hard to
>>>>> find in the documentation while an obscure "Worst Practice" is
>>>>> described because it shows how clever the software developers are
>>>>> and how powerful the product is.
>>>>>
>>>>> There should be a "Best Practice" section on the Maven site
>>>>> describing the best way to implement the common software
>>>>> development patterns.
>>>>>
>>>>> There are not really a lot of cases to consider but every new
>>>>> Maven user has to sort out their own case.
>>>>>
>>>>> Ron
>>>>>
>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5528994.html
>>>>>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> 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
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: using build profiles for WAR plugin [maven-eclipse-plugin]
Posted by Ron Wheeler <rw...@artifact-software.com>.
We have been developing and maintaining a large portal application with
over 70 WAR files in Eclipse with Maven since 2007 and several smaller
portals and standalone applications. We have not had this problem.
That is not to say that I am an expert in Eclipse but we know enough to
make it work.
We do not use maven-eclipse-plug-in. We use the assembly plug-in to
build our war files.
Perhaps that is the difference.
We also deploy to Tomcat which might be a better servlet engine than
Glassfish.
I am not sure how relevant our experience is to your problem but if I
can provide any additional information that you think might help, let me
know.
Ron
On 02/03/2012 10:19 AM, Markku Saarela wrote:
> Hi,
>
> You don't understand how Eclipse IDE works. Eclipse does not have
> different classpaths for testing and actual runtime. So Eclipse basic
> design is faulty. There is bug open since 2008 to provide means to
> tell Eclipse that which are test sources and not include them to
> runtime classpath. https://bugs.eclipse.org/bugs/show_bug.cgi?id=224708
>
> So everything under src/test goes also into GlassFish server if you
> deploy application in Eclipse. That causes that those unit test
> properties and configuration and classes are picked first and they are
> effective and application does not work.
>
> Even worst if you have multi-module project and B module is dependent
> from A and A project defines SPI interface and has in src/test/java
> test implementation for that and of course in
> src/test/resources/META-INF/services SPI file for exposing that test
> SPI implementation then if B implements also that SPI interface and
> put SPI file in src/main/resources/META-INF/services, you cannot test
> you implementation via ServiceLoader because it pick's that module A
> test implementation. Same goes for properties and everything else.
>
> Of course NetBeans and IntelliJ has correct way to do things but they
> are not an option.
>
> Markku
>
>
> On 2.3.2012 15:15, Ron Wheeler wrote:
>> On 02/03/2012 1:32 AM, Markku Saarela wrote:
>>> Hi,
>>>
>>> Developing with Eclipse IDE and JavaEE server using
>>> maven-eclipse-plugin you have to use profiles, because Eclipse does
>>> not isolate test code and test resources.
>> Eclipse does
>> /src/main/.... code
>> /src/test ... test code and resources
>>
>> You need to set your maven properly but it works fine unless I don't
>> understand your issue.
>>
>>>
>>> Only way to do it what i have figured out is to have two profiles
>>> one for running application in app server and another for unit
>>> testing same code. Those profiles has only resources and
>>> testResources definitions.
>>>
>>> Separating test code for separate code is not an option, because
>>> then Sonar reports 0 % coverage.
>>>
>>> rgds,
>>>
>>> Markku
>>>
>>> On 1.3.2012 22:55, Ron Wheeler wrote:
>>>> On 01/03/2012 2:43 PM, offbyone wrote:
>>>>> Ok so I should create a base pom with a war configuration and then
>>>>> a separate
>>>>> pom for each site that depends on this with overlays to add the extra
>>>>> configuration file.
>>>>> I will try.
>>>>>
>>>>> If I am interpreting your comments correctly, profiles allow for a
>>>>> user to
>>>>> flaten a maven build deployment, but this is a bad practice and it
>>>>> is better
>>>>> to make your maven structure deep.
>>>>>
>>>>> So are profiles going to be deprecated? I would think I am not
>>>>> alone in
>>>>> getting turned down the wrong path because most of the
>>>>> documentation/howtos
>>>>> I have found point to using profiles.
>>>> There are some uses for profiles that seem harmless so it is a
>>>> documentation issue.
>>>>
>>>> It is fairly common in Apache documentation for the programmers to
>>>> make a big deal about all the wonderful things that the package can
>>>> do.
>>>> They are not particularly concerned about "Best Practices".
>>>>
>>>> The most common usage is often left out of the documentation since
>>>> it is "dull" or not very impressive.
>>>> This sometimes means that obscure usage of features or seldom used
>>>> features are heavily documented while the main use case is not
>>>> described.
>>>>
>>>> New Maven users often fall into the trap that you were headed into.
>>>>
>>>> A really simple "Best Practice" that most people use, is hard to
>>>> find in the documentation while an obscure "Worst Practice" is
>>>> described because it shows how clever the software developers are
>>>> and how powerful the product is.
>>>>
>>>> There should be a "Best Practice" section on the Maven site
>>>> describing the best way to implement the common software
>>>> development patterns.
>>>>
>>>> There are not really a lot of cases to consider but every new Maven
>>>> user has to sort out their own case.
>>>>
>>>> Ron
>>>>
>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5528994.html
>>>>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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: using build profiles for WAR plugin [maven-eclipse-plugin]
Posted by Markku Saarela <ma...@pp6.inet.fi>.
Hi,
You don't understand how Eclipse IDE works. Eclipse does not have
different classpaths for testing and actual runtime. So Eclipse basic
design is faulty. There is bug open since 2008 to provide means to tell
Eclipse that which are test sources and not include them to runtime
classpath. https://bugs.eclipse.org/bugs/show_bug.cgi?id=224708
So everything under src/test goes also into GlassFish server if you
deploy application in Eclipse. That causes that those unit test
properties and configuration and classes are picked first and they are
effective and application does not work.
Even worst if you have multi-module project and B module is dependent
from A and A project defines SPI interface and has in src/test/java test
implementation for that and of course in
src/test/resources/META-INF/services SPI file for exposing that test SPI
implementation then if B implements also that SPI interface and put SPI
file in src/main/resources/META-INF/services, you cannot test you
implementation via ServiceLoader because it pick's that module A test
implementation. Same goes for properties and everything else.
Of course NetBeans and IntelliJ has correct way to do things but they
are not an option.
Markku
On 2.3.2012 15:15, Ron Wheeler wrote:
> On 02/03/2012 1:32 AM, Markku Saarela wrote:
>> Hi,
>>
>> Developing with Eclipse IDE and JavaEE server using
>> maven-eclipse-plugin you have to use profiles, because Eclipse does
>> not isolate test code and test resources.
> Eclipse does
> /src/main/.... code
> /src/test ... test code and resources
>
> You need to set your maven properly but it works fine unless I don't
> understand your issue.
>
>>
>> Only way to do it what i have figured out is to have two profiles one
>> for running application in app server and another for unit testing
>> same code. Those profiles has only resources and testResources
>> definitions.
>>
>> Separating test code for separate code is not an option, because then
>> Sonar reports 0 % coverage.
>>
>> rgds,
>>
>> Markku
>>
>> On 1.3.2012 22:55, Ron Wheeler wrote:
>>> On 01/03/2012 2:43 PM, offbyone wrote:
>>>> Ok so I should create a base pom with a war configuration and then
>>>> a separate
>>>> pom for each site that depends on this with overlays to add the extra
>>>> configuration file.
>>>> I will try.
>>>>
>>>> If I am interpreting your comments correctly, profiles allow for a
>>>> user to
>>>> flaten a maven build deployment, but this is a bad practice and it
>>>> is better
>>>> to make your maven structure deep.
>>>>
>>>> So are profiles going to be deprecated? I would think I am not
>>>> alone in
>>>> getting turned down the wrong path because most of the
>>>> documentation/howtos
>>>> I have found point to using profiles.
>>> There are some uses for profiles that seem harmless so it is a
>>> documentation issue.
>>>
>>> It is fairly common in Apache documentation for the programmers to
>>> make a big deal about all the wonderful things that the package can do.
>>> They are not particularly concerned about "Best Practices".
>>>
>>> The most common usage is often left out of the documentation since
>>> it is "dull" or not very impressive.
>>> This sometimes means that obscure usage of features or seldom used
>>> features are heavily documented while the main use case is not
>>> described.
>>>
>>> New Maven users often fall into the trap that you were headed into.
>>>
>>> A really simple "Best Practice" that most people use, is hard to
>>> find in the documentation while an obscure "Worst Practice" is
>>> described because it shows how clever the software developers are
>>> and how powerful the product is.
>>>
>>> There should be a "Best Practice" section on the Maven site
>>> describing the best way to implement the common software development
>>> patterns.
>>>
>>> There are not really a lot of cases to consider but every new Maven
>>> user has to sort out their own case.
>>>
>>> Ron
>>>
>>>
>>>> --
>>>> View this message in context:
>>>> http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5528994.html
>>>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 02/03/2012 1:32 AM, Markku Saarela wrote:
> Hi,
>
> Developing with Eclipse IDE and JavaEE server using
> maven-eclipse-plugin you have to use profiles, because Eclipse does
> not isolate test code and test resources.
Eclipse does
/src/main/.... code
/src/test ... test code and resources
You need to set your maven properly but it works fine unless I don't
understand your issue.
>
> Only way to do it what i have figured out is to have two profiles one
> for running application in app server and another for unit testing
> same code. Those profiles has only resources and testResources
> definitions.
>
> Separating test code for separate code is not an option, because then
> Sonar reports 0 % coverage.
>
> rgds,
>
> Markku
>
> On 1.3.2012 22:55, Ron Wheeler wrote:
>> On 01/03/2012 2:43 PM, offbyone wrote:
>>> Ok so I should create a base pom with a war configuration and then a
>>> separate
>>> pom for each site that depends on this with overlays to add the extra
>>> configuration file.
>>> I will try.
>>>
>>> If I am interpreting your comments correctly, profiles allow for a
>>> user to
>>> flaten a maven build deployment, but this is a bad practice and it
>>> is better
>>> to make your maven structure deep.
>>>
>>> So are profiles going to be deprecated? I would think I am not
>>> alone in
>>> getting turned down the wrong path because most of the
>>> documentation/howtos
>>> I have found point to using profiles.
>> There are some uses for profiles that seem harmless so it is a
>> documentation issue.
>>
>> It is fairly common in Apache documentation for the programmers to
>> make a big deal about all the wonderful things that the package can do.
>> They are not particularly concerned about "Best Practices".
>>
>> The most common usage is often left out of the documentation since it
>> is "dull" or not very impressive.
>> This sometimes means that obscure usage of features or seldom used
>> features are heavily documented while the main use case is not
>> described.
>>
>> New Maven users often fall into the trap that you were headed into.
>>
>> A really simple "Best Practice" that most people use, is hard to find
>> in the documentation while an obscure "Worst Practice" is described
>> because it shows how clever the software developers are and how
>> powerful the product is.
>>
>> There should be a "Best Practice" section on the Maven site
>> describing the best way to implement the common software development
>> patterns.
>>
>> There are not really a lot of cases to consider but every new Maven
>> user has to sort out their own case.
>>
>> Ron
>>
>>
>>> --
>>> View this message in context:
>>> http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5528994.html
>>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
Posted by Markku Saarela <ma...@pp6.inet.fi>.
Hi,
Developing with Eclipse IDE and JavaEE server using maven-eclipse-plugin
you have to use profiles, because Eclipse does not isolate test code and
test resources.
Only way to do it what i have figured out is to have two profiles one
for running application in app server and another for unit testing same
code. Those profiles has only resources and testResources definitions.
Separating test code for separate code is not an option, because then
Sonar reports 0 % coverage.
rgds,
Markku
On 1.3.2012 22:55, Ron Wheeler wrote:
> On 01/03/2012 2:43 PM, offbyone wrote:
>> Ok so I should create a base pom with a war configuration and then a
>> separate
>> pom for each site that depends on this with overlays to add the extra
>> configuration file.
>> I will try.
>>
>> If I am interpreting your comments correctly, profiles allow for a
>> user to
>> flaten a maven build deployment, but this is a bad practice and it is
>> better
>> to make your maven structure deep.
>>
>> So are profiles going to be deprecated? I would think I am not
>> alone in
>> getting turned down the wrong path because most of the
>> documentation/howtos
>> I have found point to using profiles.
> There are some uses for profiles that seem harmless so it is a
> documentation issue.
>
> It is fairly common in Apache documentation for the programmers to
> make a big deal about all the wonderful things that the package can do.
> They are not particularly concerned about "Best Practices".
>
> The most common usage is often left out of the documentation since it
> is "dull" or not very impressive.
> This sometimes means that obscure usage of features or seldom used
> features are heavily documented while the main use case is not
> described.
>
> New Maven users often fall into the trap that you were headed into.
>
> A really simple "Best Practice" that most people use, is hard to find
> in the documentation while an obscure "Worst Practice" is described
> because it shows how clever the software developers are and how
> powerful the product is.
>
> There should be a "Best Practice" section on the Maven site describing
> the best way to implement the common software development patterns.
>
> There are not really a lot of cases to consider but every new Maven
> user has to sort out their own case.
>
> Ron
>
>
>> --
>> View this message in context:
>> http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5528994.html
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> 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: using build profiles for WAR plugin
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 01/03/2012 2:43 PM, offbyone wrote:
> Ok so I should create a base pom with a war configuration and then a separate
> pom for each site that depends on this with overlays to add the extra
> configuration file.
> I will try.
>
> If I am interpreting your comments correctly, profiles allow for a user to
> flaten a maven build deployment, but this is a bad practice and it is better
> to make your maven structure deep.
>
> So are profiles going to be deprecated? I would think I am not alone in
> getting turned down the wrong path because most of the documentation/howtos
> I have found point to using profiles.
There are some uses for profiles that seem harmless so it is a
documentation issue.
It is fairly common in Apache documentation for the programmers to make
a big deal about all the wonderful things that the package can do.
They are not particularly concerned about "Best Practices".
The most common usage is often left out of the documentation since it is
"dull" or not very impressive.
This sometimes means that obscure usage of features or seldom used
features are heavily documented while the main use case is not described.
New Maven users often fall into the trap that you were headed into.
A really simple "Best Practice" that most people use, is hard to find in
the documentation while an obscure "Worst Practice" is described because
it shows how clever the software developers are and how powerful the
product is.
There should be a "Best Practice" section on the Maven site describing
the best way to implement the common software development patterns.
There are not really a lot of cases to consider but every new Maven user
has to sort out their own case.
Ron
> --
> View this message in context: http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5528994.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> 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: using build profiles for WAR plugin
Posted by offbyone <ry...@iridiumsuite.com>.
Ok so I should create a base pom with a war configuration and then a separate
pom for each site that depends on this with overlays to add the extra
configuration file.
I will try.
If I am interpreting your comments correctly, profiles allow for a user to
flaten a maven build deployment, but this is a bad practice and it is better
to make your maven structure deep.
So are profiles going to be deprecated? I would think I am not alone in
getting turned down the wrong path because most of the documentation/howtos
I have found point to using profiles.
--
View this message in context: http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5528994.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: using build profiles for WAR plugin
Posted by Wayne Fay <wa...@gmail.com>.
> One thing that also caught me off guard is it appears that I have to
> reference the clienta-war and clientb-war as modules in my main project
> pom. Is that correct?
Yes, that is correct. If a project is not a module (directly as
children or as grandchildren etc) of the project you are executing
Maven from, then Maven does not "see" it as far as this specific build
is concerned and will not build it.
> Well this data is essentially a directory of jasper files. The same group
> of files is used in several modules. How do you install a directory of
> files as an artifact?
It sounds like they are essentially static resources that simply must
be bundled into one or more war files. First I would make sure there
is no possibility to just include them in your war in a jar file and
tell JasperReports to find them in my classpath, then use a regular
<dependency> to include them in my wars where I need to use them.
Otherwise I would probably just stick them into their own project (a
"jar" type alongside the "lib" module I suggested before) and then use
dependency:unpack to put them where I need them in the various wars.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: using build profiles for WAR plugin
Posted by Ryan Wexler <ry...@iridiumsuite.com>.
On Fri, Mar 2, 2012 at 7:19 AM, Wayne Fay <wa...@gmail.com> wrote:
> > 1)I keep getting this error in reference to the generic-war project:
> > 'packaging' with value 'war' is invalid. Aggregator projects
> > require 'pom' as packaging.
> > I tried to changing it to pom but that doesn't seem right. Is an
> > Aggregator any project with sub modules?
>
> Read my post again. You should have a top parent of type pom that has
> modules. Those modules are subdirectories under the parent (with the
> same directory name as the module) and those modules are typed jar,
> war, etc.
>
Now it seems to work! Still got a long way to go but that is a big step
forward. thx.
I think the problem was that I was referencing clienta-war and clientb-war
as modules from generic-war. Another problem I had was that I wasn't using
the "type" property in the dependency tag so it was looking for
generic-war.jar.
One thing that also caught me off guard is it appears that I have to
reference the clienta-war and clientb-war as modules in my main project
pom. Is that correct?
>
> > 2)In my war configuration, I try to access a resource that is already
> > declared in the "lib" module.
>
> What do you mean by "access a resource"? What are you going to do with it?
>
> > I assume the issue is that ${basedir} now refers to my current location.
> > How do I access this resource that is two layers up?
>
> You don't. Each project is an independent project. If you need to use
> a resource from another project, you need to reference that artifact
> in this project and unpack the file you need to use. This quickly
> leads you to a solutions where shared resources are in their own
> project and you depend on this across various other artifacts.
>
> Well this data is essentially a directory of jasper files. The same group
of files is used in several modules. How do you install a directory of
files as an artifact?
> > Do I manually reference the directory?
> > Or should I be making this resource an artifact somehow?
>
> Depends on what you want to do with it. What do you need to use it for?
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: using build profiles for WAR plugin
Posted by Wayne Fay <wa...@gmail.com>.
> 1)I keep getting this error in reference to the generic-war project:
> 'packaging' with value 'war' is invalid. Aggregator projects
> require 'pom' as packaging.
> I tried to changing it to pom but that doesn't seem right. Is an
> Aggregator any project with sub modules?
Read my post again. You should have a top parent of type pom that has
modules. Those modules are subdirectories under the parent (with the
same directory name as the module) and those modules are typed jar,
war, etc.
> 2)In my war configuration, I try to access a resource that is already
> declared in the "lib" module.
What do you mean by "access a resource"? What are you going to do with it?
> I assume the issue is that ${basedir} now refers to my current location.
> How do I access this resource that is two layers up?
You don't. Each project is an independent project. If you need to use
a resource from another project, you need to reference that artifact
in this project and unpack the file you need to use. This quickly
leads you to a solutions where shared resources are in their own
project and you depend on this across various other artifacts.
> Do I manually reference the directory?
> Or should I be making this resource an artifact somehow?
Depends on what you want to do with it. What do you need to use it for?
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: using build profiles for WAR plugin
Posted by offbyone <ry...@iridiumsuite.com>.
I am working on implementing your recommended layout. I am experiencing
some problems.
1)I keep getting this error in reference to the generic-war project:
'packaging' with value 'war' is invalid. Aggregator projects
require 'pom' as packaging.
I tried to changing it to pom but that doesn't seem right. Is an
Aggregator any project with sub modules?
If I do change it to a pom then I get this error:
[ERROR] Failed to execute goal on project clienta-war: Could not resolve
dependencies for project myproject:clienta-war:war:8.1.1: Failure to find
com.myproject:generic-war:jar:8.1.1 in http://repo1.maven.org/maven2
Now it seems to be looking for a jar file.
2)In my war configuration, I try to access a resource that is already
declared in the "lib" module.
<resource>
<directory>${basedir}/src/main/reports</directory>
<targetPath>WEB-INF/reports</targetPath>
</resource>
I assume the issue is that ${basedir} now refers to my current location.
How do I access this resource that is two layers up?
Do I manually reference the directory?
Or should I be making this resource an artifact somehow?
On Thu, Mar 1, 2012 at 6:25 PM, Wayne Fay [via Maven] <
ml-node+s40175n5529884h87@n5.nabble.com> wrote:
> > I have my main project which is a package pom type. It has
> dependencies, a
> > compiler plugin and a war plugin. Essentially:
>
> This is most likely wrong. Your war projects should use package 'war".
>
> Here is how I would structure this:
> top-parent project, packaging pom
> module lib with its own pom, packaging jar
> module generic-war with its own pom, packaging war, depends on lib
> module clienta-war with its own pom, packaging war, depends on generic-war
> module clientb-war with its own pom, packaging war, depends on generic-war
>
> Generally you should put all your source code in a module with
> packaging jar. You probably want to put code in your War module but
> this is not a best practice. I suggested a "lib" jar module above, but
> feel free to add more as needed and set up dependencies between them.
> These jars are dependencies for your wars.
>
> Then you have a generic-war module with packaging war. This is your
> "overlay base".
>
> Then you have client- or environment-specific modules with packaging
> war that depend on your generic-war base. By simply specifying the
> generic-war as a dependency of these war artifacts, your wars will
> automatically get overlaid.
>
> Here's more info and examples that I won't get into here:
> http://maven.apache.org/plugins/maven-war-plugin/examples/war-overlay.html
>
> All of these modules should have their own unique artifactIds but they
> can share one groupId if that is your preference.
>
> > I can compile and execute the war task to create the war. It of course
> is
> > missing my per server files. I presume this is correct so far, but
> please
> > let me know if I am already blowing it.
>
> You are already blowing it. ;-)
>
> You should just be able to type "mvn package" and if the project is a
> packaging war, it will automatically pull in the war plugin and create
> a war file as output. You should not be specifying "mvn war:war" or
> other such commands. The war plugin "knows" when it should execute for
> packaging war projects.
>
> > <parent> //??? Am I suppose to be referencing the main project as a
> > parent?
>
> Generally yes you should have 1 top parent and optionally multiple
> levels of parents on down to the leaf projects which are jar, war,
> ear, and other packaging types.
>
> > <dependency> //???Am I suppose to be referencing the main project as
> a
> > dependency here?
>
> This is discussed in depth above.
>
> > <configuration>
> > <overlays>
> > <overlay>
> > <groupId>com.myproject</groupId>
> > <artifactId>myartifact</artifactId>
>
> This is should only be necessary if the war module does not list the
> overlaid war as a dependency, as I suggested above. You should remove
> this.
>
> > I get some dependency error that I don't understand. I am unclear as to
> the
> > relationship of the two projects.
> > Does the main project reference the overlay or vice versa?
>
> Draw up your project on a piece of paper. Sort out the dependencies
> topographically. The leaf nodes are where overlays should be
> happening.
>
> > Also, what are the steps I am suppose to go through to get this built?
> > I am presuming that I install the first project, then package the second
> > project? This is a lot more work than when I used the profiles which
> was a
> > one command process, am I missing something?
>
> You should be able to execute a single "mvn package" command from the
> top parent and it should build all of the modules in the proper order
> resulting in one or more overlaid war files as you expect.
>
> Honestly you need to slow down, read more documentation, and build
> some basic sample projects to have a better handle on the "basics" you
> are missing before trying to make this work -- you're dealing with
> some advanced concepts and techniques. Here are some suggested
> resources:
> http://maven.apache.org/articles.html
>
> You are trying to just jump into Maven 201 without doing Maven 101
> first. Slow down, do it right, and everything will make more sense to
> you.
>
> Wayne
>
> PS- Your note to Ron was not private, if that was your intention.
> PPS- Nabble is crap. Please just subscribe to the list via email.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5529884&i=0>
> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5529884&i=1>
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5529884.html
> To unsubscribe from using build profiles for WAR plugin, click here<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5525954&code=cnlhbkBpcmlkaXVtc3VpdGUuY29tfDU1MjU5NTR8NzI4MTgyOTE0>
> .
> NAML<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5530154.html
Sent from the Maven - Users mailing list archive at Nabble.com.
Re: using build profiles for WAR plugin
Posted by Wayne Fay <wa...@gmail.com>.
> I have my main project which is a package pom type. It has dependencies, a
> compiler plugin and a war plugin. Essentially:
This is most likely wrong. Your war projects should use package 'war".
Here is how I would structure this:
top-parent project, packaging pom
module lib with its own pom, packaging jar
module generic-war with its own pom, packaging war, depends on lib
module clienta-war with its own pom, packaging war, depends on generic-war
module clientb-war with its own pom, packaging war, depends on generic-war
Generally you should put all your source code in a module with
packaging jar. You probably want to put code in your War module but
this is not a best practice. I suggested a "lib" jar module above, but
feel free to add more as needed and set up dependencies between them.
These jars are dependencies for your wars.
Then you have a generic-war module with packaging war. This is your
"overlay base".
Then you have client- or environment-specific modules with packaging
war that depend on your generic-war base. By simply specifying the
generic-war as a dependency of these war artifacts, your wars will
automatically get overlaid.
Here's more info and examples that I won't get into here:
http://maven.apache.org/plugins/maven-war-plugin/examples/war-overlay.html
All of these modules should have their own unique artifactIds but they
can share one groupId if that is your preference.
> I can compile and execute the war task to create the war. It of course is
> missing my per server files. I presume this is correct so far, but please
> let me know if I am already blowing it.
You are already blowing it. ;-)
You should just be able to type "mvn package" and if the project is a
packaging war, it will automatically pull in the war plugin and create
a war file as output. You should not be specifying "mvn war:war" or
other such commands. The war plugin "knows" when it should execute for
packaging war projects.
> <parent> //??? Am I suppose to be referencing the main project as a
> parent?
Generally yes you should have 1 top parent and optionally multiple
levels of parents on down to the leaf projects which are jar, war,
ear, and other packaging types.
> <dependency> //???Am I suppose to be referencing the main project as a
> dependency here?
This is discussed in depth above.
> <configuration>
> <overlays>
> <overlay>
> <groupId>com.myproject</groupId>
> <artifactId>myartifact</artifactId>
This is should only be necessary if the war module does not list the
overlaid war as a dependency, as I suggested above. You should remove
this.
> I get some dependency error that I don't understand. I am unclear as to the
> relationship of the two projects.
> Does the main project reference the overlay or vice versa?
Draw up your project on a piece of paper. Sort out the dependencies
topographically. The leaf nodes are where overlays should be
happening.
> Also, what are the steps I am suppose to go through to get this built?
> I am presuming that I install the first project, then package the second
> project? This is a lot more work than when I used the profiles which was a
> one command process, am I missing something?
You should be able to execute a single "mvn package" command from the
top parent and it should build all of the modules in the proper order
resulting in one or more overlaid war files as you expect.
Honestly you need to slow down, read more documentation, and build
some basic sample projects to have a better handle on the "basics" you
are missing before trying to make this work -- you're dealing with
some advanced concepts and techniques. Here are some suggested
resources:
http://maven.apache.org/articles.html
You are trying to just jump into Maven 201 without doing Maven 101
first. Slow down, do it right, and everything will make more sense to
you.
Wayne
PS- Your note to Ron was not private, if that was your intention.
PPS- Nabble is crap. Please just subscribe to the list via email.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: using build profiles for WAR plugin
Posted by offbyone <ry...@iridiumsuite.com>.
Really struggling here and could use some help with these overlays. I seem
to be missing basic concepts or maybe I am just slow, sorry if these
questions are pedestrian.
So I am trying to produce an overlay to add the extra configuration for each
of my server deployments.
I have my main project which is a package pom type. It has dependencies, a
compiler plugin and a war plugin. Essentially:
project directory layout
/pom.xml
..src/main/java
..src/main/webapp
..src/main/reports
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.myproject</groupId>
<artifactId>myartifact</artifactId>
<version>8.1.1</version>
<name>my project</name>
<packaging>pom</packaging>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.2</version>
<configuration>
<webResources>
<resource>
<directory>${basedir}/src/main/reports</directory>
<targetPath>WEB-INF/reports</targetPath>
</resource>
</webResources>
</configuration>
</plugin>
</build>
<dependencies>
.
.
.
</dependencies>
</project>
I can compile and execute the war task to create the war. It of course is
missing my per server files. I presume this is correct so far, but please
let me know if I am already blowing it.
Then I have my other projects for each server:
project directory layout
/pom.xml
..src/main/java
..src/main/webapp
..src/main/reports
..server/server1
..server/server1/pom.xml
..server/server1/src/main/webapp
..server/server2
..server/server2/pom.xml
..server/server3/src/main/webapp
..server/server3
..server/server3/pom.xml
..server/server3/src/main/webapp
Each of these poms looks like this(clearly something is wrong):
<project>
<modelVersion>4.0.0</modelVersion>
<parent> //??? Am I suppose to be referencing the main project as a
parent?
<groupId>com.myproject</groupId>
<artifactId>myartifact</artifactId>
<version>8.1.1</version>
</parent>
<groupId>com.myproject</groupId>
<artifactId>server1</artifactId>
<version>8.1.1</version>
<packaging>war</packaging>
<dependencies>
<dependency> //???Am I suppose to be referencing the main project as a
dependency here?
<groupId>com.myproject</groupId>
<artifactId>myartifact</artifactId>
<version>8.1.1</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.2</version>
<configuration>
<overlays>
<overlay>
<groupId>com.myproject</groupId>
<artifactId>myartifact</artifactId>
</overlay>
</overlays>
</configuration>
</plugin>
</plugins>
</build>
</project>
I get some dependency error that I don't understand. I am unclear as to the
relationship of the two projects.
Does the main project reference the overlay or vice versa?
Do I need to set a dependency in the overlay to the other project or vice
versa?
Also, what are the steps I am suppose to go through to get this built?
I am presuming that I install the first project, then package the second
project? This is a lot more work than when I used the profiles which was a
one command process, am I missing something?
--
View this message in context: http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5529716.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: using build profiles for WAR plugin
Posted by Ron Wheeler <rw...@artifact-software.com>.
This is not a unique situation.
Many people here use Spring and most people have to generate different
WAR files.
One way is to have a set of maven JAR projects that contain all the code
and a set of WAR projects that depend on your JARS and contain the
Spring configuration files that are specific to each customer.
Each WAR file will have all of the right code with the right
configuration files and will build nicely with very simple pom files
that are easy to maintain.
Once you get this working, you can automate the maintenance of the WAR
projects to handle new releases.
This will work and you will have your setup done and working in an hour
or less.
It will also work for each new release of Maven and you will be able to
get support here easily since this is the Maven way and we all know how
to do this.
Ron
On 01/03/2012 2:16 PM, offbyone wrote:
> Ok, I hear you, profiles are evil. BUT I still don't understand the
> alternative so let me give a specific and tangible example and maybe you can
> explain a specific alternative.
>
> I am currently deploying my product in a tomcat/linux environment as a war
> file. My webapp is driven by a set of spring configuration files using the
> Spring context loader. For example, one of those spring configuration files
> is called LookAndFeel.xml. It sets attributes like colors of the user
> interface. I love using this type of configuration driven design because it
> lets me swap out the entire look and feel just by changing a config file.
>
> There are many deployments of my application on different systems and each
> one has a different look and feel configuration file. So, I was planning to
> have a different maven profile for each deployment and have the profile
> automatically push the correct LookAndFeel.xml into the war archive.
>
> So specifically how do I accomplish this this in maven without using
> profiles?
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5528917.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> 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: using build profiles for WAR plugin
Posted by Manfred Moser <ma...@mosabuam.com>.
On Thu, March 1, 2012 11:19 am, Wayne Fay wrote:
>> There are many deployments of my application on different systems and
>> each
>> one has a different look and feel configuration file. Â So, I was
>> planning to
>> have a different maven profile for each deployment and have the profile
>> automatically push the correct LookAndFeel.xml into the war archive.
>>
>> So specifically how do I accomplish this this in maven without using
>> profiles?
>
> Multimodules + WAR overlays = each will have its own GAV and no profiles
Completely agree. You can even do that with externally provided war files
that you customize..
manfred
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: using build profiles for WAR plugin
Posted by Wayne Fay <wa...@gmail.com>.
> There are many deployments of my application on different systems and each
> one has a different look and feel configuration file. So, I was planning to
> have a different maven profile for each deployment and have the profile
> automatically push the correct LookAndFeel.xml into the war archive.
>
> So specifically how do I accomplish this this in maven without using
> profiles?
Multimodules + WAR overlays = each will have its own GAV and no profiles
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: using build profiles for WAR plugin
Posted by Sebastian Otaegui <fe...@gmail.com>.
I think a much better solution than relying on the build tool (maven
profiles or on war overlays) is to use environment variables and bundle all
the LookAndFeel.xml in your war
I would use spring 3.1 and use the environment profiles feature.
http://blog.springsource.com/2011/02/11/spring-framework-3-1-m1-released/
http://blog.wookets.com/2011/11/spring-31-environment-profile.html
Regards
On Thu, Mar 1, 2012 at 1:16 PM, offbyone <ry...@iridiumsuite.com> wrote:
> Ok, I hear you, profiles are evil. BUT I still don't understand the
> alternative so let me give a specific and tangible example and maybe you
> can
> explain a specific alternative.
>
> I am currently deploying my product in a tomcat/linux environment as a war
> file. My webapp is driven by a set of spring configuration files using the
> Spring context loader. For example, one of those spring configuration
> files
> is called LookAndFeel.xml. It sets attributes like colors of the user
> interface. I love using this type of configuration driven design because
> it
> lets me swap out the entire look and feel just by changing a config file.
>
> There are many deployments of my application on different systems and each
> one has a different look and feel configuration file. So, I was planning
> to
> have a different maven profile for each deployment and have the profile
> automatically push the correct LookAndFeel.xml into the war archive.
>
> So specifically how do I accomplish this this in maven without using
> profiles?
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5528917.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Those who do not understand Unix are condemned to reinvent it, poorly.
Any sufficiently recent Microsoft OS contains an ad hoc,
informally-specified, bug-ridden, slow implementation of half of Unix.
Re: using build profiles for WAR plugin
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
On Thu, Mar 01, 2012 at 11:16:34AM -0800, offbyone wrote:
> Ok, I hear you, profiles are evil. BUT I still don't understand the
> alternative so let me give a specific and tangible example and maybe you can
> explain a specific alternative.
>
> I am currently deploying my product in a tomcat/linux environment as a war
> file. My webapp is driven by a set of spring configuration files using the
> Spring context loader. For example, one of those spring configuration files
> is called LookAndFeel.xml. It sets attributes like colors of the user
> interface. I love using this type of configuration driven design because it
> lets me swap out the entire look and feel just by changing a config file.
>
> There are many deployments of my application on different systems and each
> one has a different look and feel configuration file. So, I was planning to
> have a different maven profile for each deployment and have the profile
> automatically push the correct LookAndFeel.xml into the war archive.
>
> So specifically how do I accomplish this this in maven without using
> profiles?
Better you don't.
Should I assume that LookAndFeel.xml is something that you design for
the customer, rather than (as I first thought) something the customer
is supposed to customize on-site? Then the problem is that you are
using Maven as a packaging tool. That's not what it is; it's a build
tool. Packaging is a different stage.
You could keep a copy of deployment X's LookAndFeel with your other
records for deployment X, or keep them all in one directory. Yank
the custom values out of a database, or write a wizard to step someone
through the customization process, and create a LookAndFeel on the fly
with e.g. XSL-T when you are packaging your generic Maven-built
artifacts for deployment X.
The point is that customization is not part of the product; it's part
of the deployment. Maven builds your product. You need something
else for deployment.
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
When the only tool you have is a hammer, every problem looks like a nail.
-- Maslow
Re: using build profiles for WAR plugin
Posted by offbyone <ry...@iridiumsuite.com>.
Ok, I hear you, profiles are evil. BUT I still don't understand the
alternative so let me give a specific and tangible example and maybe you can
explain a specific alternative.
I am currently deploying my product in a tomcat/linux environment as a war
file. My webapp is driven by a set of spring configuration files using the
Spring context loader. For example, one of those spring configuration files
is called LookAndFeel.xml. It sets attributes like colors of the user
interface. I love using this type of configuration driven design because it
lets me swap out the entire look and feel just by changing a config file.
There are many deployments of my application on different systems and each
one has a different look and feel configuration file. So, I was planning to
have a different maven profile for each deployment and have the profile
automatically push the correct LookAndFeel.xml into the war archive.
So specifically how do I accomplish this this in maven without using
profiles?
--
View this message in context: http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5528917.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: using build profiles for WAR plugin
Posted by Wayne Fay <wa...@gmail.com>.
> I am new to maven, based on the documentation and the specification it seems
> like profiles are used to create different versions of a deployment package.
> Why would profiles be there if not for that purpose?
Opinions have changed on this point through the years. Maven is
opinionated software.
Modern QA best practices demand that the development team deliver an
artifact to QA and that same unchanged artifact is then delivered to
UAT and Production.
By creating environment- or server-specific artifacts, you are
introducing the possibility of errors into this process. There is a
chance that Maven did something wrong (javac failed, bits got flipped
in your ram since you're not using ECC, etc) when constructing the
PROD artifact but built DEV and QA just fine. You would have no idea
that you are about to deploy a horribly corrupted artifact to PROD
until it was done and your "five nines SLA" is suddenly in trouble.
This defeats the entire purpose of QA.
> Maven is suppose to be a build tool, but you are telling me I shouldn't put
> build configuration data in it. It seems like you guys are saying only to
> use the dependency management/repository aspect of it.
Build configuration -- yes.
Server-specific runtime configuration which locks a particular
artifact so it only runs without modifications in one environment --
no.
Some people include "all" runtime configurations in one package and
then use a variety of techniques to tell their code which
configuration to load at runtime. There are other ways of doing the
same general thing, you are free to pick one which seems the most
reasonable to you.
Profiles for this purpose are nearly always the WRONG answer. Make
your build work WITHOUT profiles.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: using build profiles for WAR plugin
Posted by offbyone <ry...@iridiumsuite.com>.
I appreciate the feedback, but I am struggling to follow, clearly I don't
understand "the maven way".
I am new to maven, based on the documentation and the specification it seems
like profiles are used to create different versions of a deployment package.
Why would profiles be there if not for that purpose?
More importantly, why would maven have such a rich properties and resource
filtering feature set if the maven way is to externalize all this
information?
Maven is suppose to be a build tool, but you are telling me I shouldn't put
build configuration data in it. It seems like you guys are saying only to
use the dependency management/repository aspect of it.
Would love some clarification.
thanks
--
View this message in context: http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5528742.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: using build profiles for WAR plugin
Posted by Sebastian Otaegui <fe...@gmail.com>.
One of the uses of profiles is to have different maven runtime
configurations for running different plugin configurations based on them.
See these examples
https://github.com/jbossas/jboss-as/blob/master/pom.xml
https://github.com/jboss/jboss-parent-pom/blob/master/pom.xml
If you still insist on doing what you are saying one option is to do a
multimodule project.
like this:
- top level (parent pom where you define your modules)
--------- your "vanilla" war (your "real" webapp)
--------- your "qa" war
--------- your "prod" war
both the "qa" and "prod" war are built using the maven-war-plugin with the
overlay feature.
http://maven.apache.org/plugins/maven-war-plugin/examples/war-overlay.html
The people that maintains CAS (JASIG) are using that methodology.
On Wed, Feb 29, 2012 at 10:10 PM, Ron Wheeler <
rwheeler@artifact-software.com> wrote:
> Everyone else has to deal with this situation.
> Your concerns are not unique.
> Everyone has production, development and maintenance to deal with.
> A lot of applications of each type standalone, web, etc., have been built
> by many companies and development teams.
>
> You have been told the correct way to handle this.
>
> If you want to do it in the wrong way and misuse the features of maven,
> you can.
> No one will stop you.
> You have been warned that it will not work but you can try as long as you
> like.
>
> It should be clear that the best minds in the Maven world (the guys who
> wrote it and maintain it) have given you their best advice.
>
> Why not try it the "right" way once and see if you like it. At least you
> will get help.
> Some of the suggestions are very easy to try. A few minutes of editing a
> few POMs.
>
> Ron
>
>
> On 29/02/2012 6:04 PM, offbyone wrote:
>
>> Thanks for the reply.
>>
>> Unfortunately all the documentation I have seen point to profiles for this
>> tool. If profiles are not used to differentiate runtime configuration
>> changes, then what are? Can you point me to some documentation?
>>
>>
>>
>> --
>> View this message in context: http://maven.40175.n5.nabble.**
>> com/using-build-profiles-for-**WAR-plugin-tp5525954p5526330.**html<http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5526330.html>
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@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
>
--
Those who do not understand Unix are condemned to reinvent it, poorly.
Any sufficiently recent Microsoft OS contains an ad hoc,
informally-specified, bug-ridden, slow implementation of half of Unix.
Re: using build profiles for WAR plugin
Posted by Ron Wheeler <rw...@artifact-software.com>.
Everyone else has to deal with this situation.
Your concerns are not unique.
Everyone has production, development and maintenance to deal with.
A lot of applications of each type standalone, web, etc., have been
built by many companies and development teams.
You have been told the correct way to handle this.
If you want to do it in the wrong way and misuse the features of maven,
you can.
No one will stop you.
You have been warned that it will not work but you can try as long as
you like.
It should be clear that the best minds in the Maven world (the guys who
wrote it and maintain it) have given you their best advice.
Why not try it the "right" way once and see if you like it. At least you
will get help.
Some of the suggestions are very easy to try. A few minutes of editing a
few POMs.
Ron
On 29/02/2012 6:04 PM, offbyone wrote:
> Thanks for the reply.
>
> Unfortunately all the documentation I have seen point to profiles for this
> tool. If profiles are not used to differentiate runtime configuration
> changes, then what are? Can you point me to some documentation?
>
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5526330.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> 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: using build profiles for WAR plugin
Posted by offbyone <ry...@iridiumsuite.com>.
Thanks for the reply.
Unfortunately all the documentation I have seen point to profiles for this
tool. If profiles are not used to differentiate runtime configuration
changes, then what are? Can you point me to some documentation?
--
View this message in context: http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5526330.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: using build profiles for WAR plugin
Posted by Ansgar Konermann <an...@googlemail.com>.
Am 29.02.2012 22:33 schrieb "offbyone" <ry...@iridiumsuite.com>:
>
> I have no interest in using JNDI.
You certainly don't need to. Pick any mechanism you like to configure your
application according to the needs of your runtime environment, as long as
you do it by configuration at *runtime* (not compile time).
Would Microsoft sell a " Windows 7 for networks having their DNS server at
192.168.1.1" and bake this information into win32.sys on their product
DVDs? Certainly not. They sell "Windows 7" and let you configure the DNS
server address at runtime.
If you really want to create stage specific rollout artifacts using maven,
that's also okay, but it's best handled as different modules. Each module
would include the common artifacts like jars etc. and put it into a zip
file or rpm or whatever you like, and ultimately add the stage-specific
configuration *data* which is later used by the application.
> Could someone please address my question
> regarding profiles?
Maven profiles are intended to be used to make your build working in
different *build* contexts. Examples: use host xy as repository manager
when building at work, use abc when at home.
Don't use them to differentiate between different *runtime* environments of
the application you are building. Keep your artifacts independent of
application configuration as far as possible.
Just my 0.02€
Best
Ansgar
>
> --
> View this message in context:
http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5526140.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Re: using build profiles for WAR plugin
Posted by offbyone <ry...@iridiumsuite.com>.
I am trying to understand how profiles work. I don't want to use classifiers
for this as this has nothing to do with my environment which is identical
but rather my deployment needs.
Could someone please explain what I am missing about profiles?
--
View this message in context: http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5526321.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: using build profiles for WAR plugin
Posted by Stephen Connolly <st...@gmail.com>.
Read the thread I posted... JNDI is not the only solution. Profiles is
*NOT* the solution
On 29 February 2012 21:32, offbyone <ry...@iridiumsuite.com> wrote:
> I have no interest in using JNDI. Could someone please address my question
> regarding profiles?
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5526140.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> 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: using build profiles for WAR plugin
Posted by offbyone <ry...@iridiumsuite.com>.
I have no interest in using JNDI. Could someone please address my question
regarding profiles?
--
View this message in context: http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5526140.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: using build profiles for WAR plugin
Posted by Wayne Fay <wa...@gmail.com>.
> I am trying to create different WAR builds using profiles for my different
> production sites. Each site requires different configuration files. I
> think I am confused on how to use build profiles.
Don't do this. Build a WAR file that can be deployed on any server and
will run properly with no changes. Use JNDI, System properties, WAR
App server parameters/configuration, or another system to externalize
those system configuration differences.
Read Stephen Connolly's post from about 10hrs ago in this recent
thread on this mailing list for more options and discussion -- How to
deploy with 'classifier'
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org