Re: Is Maven the answer?
I would also recommend gradle for your circumstances. If you were thinking of using ant, all the ant tasks are available for your in gradle but it has maven's style of convention over configuration for the part's like building Java code which have a well-defined lifecycle. Cheers, Paul. On Thu, Mar 1, 2012 at 5:30 PM, Johan Erlands wrote: > On Thursday 01 March 2012 03:57:59 Terence Stephens wrote: > > I know I could do this in a shell script, but I think I would have > > better luck with a Java based tool. This is outside the scope of > > Maven's uses. For my needs, should I look into using Maven or find a > > different tool? > > Maybe gradle is a good alternative. My experience i rather limited but it > has > the dependency management of maven and you can write your own phases in > groovy > and ant (whitout the xml part if you want). > > Best regards > Johan > -- > Sent from kontact > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: using build profiles for WAR plugin
> 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 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using build profiles for WAR plugin
On Fri, Mar 2, 2012 at 7:19 AM, Wayne Fay 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-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: using build profiles for WAR plugin
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 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-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@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.
Surefire + TestNG: Success Percentage not handled correctly
I have a wait test that I expect to fail on occasion because the test threads get too out of sync. So, using TestNG, I'm setting the successPercentage and invocationCount to handle the occasional acceptable failure. If the code's broken, none of the invocations will pass. When I run the test in IntelliJ, everything's fine. But when I try and do a build in maven, I get the following Tests run: 1407, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Looking in restng-results.xml, I see this: And in TEST-TestSuite.xml, I see: java.lang.AssertionError: expected:but was: The rest of the testng generated files seem to think everything passed. But it looks like that surefire is getting confused by SUCCESS_PERCENTAGE_FAILURE or the element into thinking something's gone wrong when in fact nothing unexpected happened. Anyone know if this is a known problem or if there's a solution available? Steve CONFIDENTIALITY NOTICE: This e-mail and the information transmitted within including any attachments is only for the recipient(s) to which it is intended and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of; or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please send the e-mail back by replying to the sender and permanently delete the entire message and its attachments from all computers and network systems involved in its receipt. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
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 src/main src/main/scripts src/test target/classes target/test-classes src/main **/*.java test **/*.java target org.apache.maven.plugins maven-compiler-plugin 2.3.2 UTF-8 1.6 1.6 org.apache.maven.plugins maven-resources-plugin 2.5 UTF-8 org.apache.maven.plugins maven-war-plugin 2.2 WebContent true true org.apache.maven.plugins maven-jar-plugin 2.4 true true org.apache.maven.plugins maven-assembly-plugin 2.3 package single true true jar-with-dependencies 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, Mark
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
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 src/main src/main/scripts src/test target/classes target/test-classes src/main **/*.java test **/*.java target org.apache.maven.plugins maven-compiler-plugin 2.3.2 UTF-8 1.6 1.6 org.apache.maven.plugins maven-resources-plugin 2.5 UTF-8 org.apache.maven.plugins maven-war-plugin 2.2 WebContent true true org.apache.maven.plugins maven-jar-plugin 2.4 true true org.apache.maven.plugins maven-assembly-plugin 2.3 package single true true jar-with-dependencies 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 fil
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
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 t
Re: Is Maven the answer?
If i have to repeatedly doing the same thing every day maven plugin is a way to go since I can run it any where i like as long as maven installed and point to our central maven repo. -D On Thu, Mar 1, 2012 at 7:59 PM, Terence Stephens wrote: > Thanks for all the replies. I'm tempted to use Maven just because I > think it's the more valuable tool to learn, but I'll probably go with > Ant for the first iteration. There have been a lot of other tools > suggested as well. I'll do more research on those and will hopefully > decide next week. > > thank you again for all the ideas and suggestions. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven as an installation tool
Please discard my last comment, wrong topic. -D On Fri, Mar 2, 2012 at 12:17 AM, Dan Tran wrote: > If i have to repeatedly doing the same thing every day maven > plugin is a way to go since I can run it any where i like as long as > maven installed and point to our central maven repo. > > > -D > > On Thu, Mar 1, 2012 at 11:57 PM, Anders Hammar wrote: >>> Sonatype do some black magic for provision developer desktops, check >>> their website. >>> There was a demo I saw that pulled down your Eclipse binaries and >>> installing plugins and did some configuration stuff. >>> I believe that the bundling of the artifacts for provisioning live in >>> Nexus - not sure if its a p2 or maven repository. >> >> You're referring to their Onboarding solution that they've turned open >> source: >> https://github.com/sonatype/onboarding >> >> This is for materializing (and update) an Eclipse IDE installation. It >> pulls artifacts from a P2 repository in Nexus. >> >> /Anders >> >>> >>> As the other thread "Is Maven the Answer" says you may be better off >>> with a pure scripting language or Ant if you want to do non >>> build-lifecycle event handling. >>> >>> Getting Maven to do what you are suggesting is not going to be simply >>> a matter of hooking assembly plugin together with some dependencies. >>> You are probably going to have to develop a plugin - at which point >>> you have to wonder whether it fits into the idea of Maven's lifecycle >>> (and I suggest not). >>> >>> If you are running on Windows tools like SCCM do the installation >>> management for you. >>> Is it worth rolling your own? >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deploy and condition
> We are deploying to artifactory. > > Please suggest. These sound like questions that are better asked on the Artifactory list. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
> 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional comman
Re: using build profiles for WAR plugin
> 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Profiles, classifiers, etc
Just a general musing on some of the recent conversations. A recent discussion included the admonition to "Walk before you run". I just came across a quote from Knuth that relates very well to some of issues raised by new Maven users. "Premature optimization is the root of all evil (or at least most of it) in programming. " Perhaps this should go on each page of the Maven web site. Ron -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using build profiles for WAR plugin
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 mw...@iupui.edu When the only tool you have is a hammer, every problem looks like a nail. -- Maslow pgpVz4vqPnc8W.pgp Description: PGP signature
Re: Maven as an installation tool
Hi, I build a automated setup for an Webapplication including GlassFish configuration, DB setup and configuration and deployment of the application itself. I have choosen Ant as tool for this and I use Maven via the Ant Maven Task to handle all dependency related stuff and it works great. The solution combines the adavantages of Ant and Maven and turned out to be very flexible. But you must know Ant before. Bye Oliver Am 02.03.2012 04:32, schrieb Eric Kolotyluk: Maybe this is too weird, but Has anyone ever used Maven as an installation tool? I've been thinking using Maven as a way to install and update software, and before I actually go and experiment with the idea I was wondering if other people have already thought of this. The idea would be that you have a simple bootstrap installer that installs and/or updates Maven first. Once Maven is installed/verified, you could then use it to pull down the rest of the solution artifacts from the network and then integrate them into the end solution. Over time you use the same mechanism to assist in software upgrades. I suspect some people already do something like this for enterprise web applications, but I was thinking of something like a desktop application. Cheers, Eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven archetype plugin
Hi All I have created a maven archetype using "mvn:create-from-project". I dont wan't the plugin to modify the java file hierarchy but it seems it shortens the java package hierarchy and prefixes the base package with ${package} inside files. I tried adding packaged="false" to the filesets in archetype-metadta.xml but that seems to be completely ignored. How do I make the plugin stop modifying the package of java files both during the "create-from-project" step and when I build the generated archetype with "mvn clean install"? Im using maven 3.0.3 and according to the pom of the generated archetype im using v2.2 of the archetype plugin: maven-archetype-plugin 2.2 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven as an installation tool
If i have to repeatedly doing the same thing every day maven plugin is a way to go since I can run it any where i like as long as maven installed and point to our central maven repo. -D On Thu, Mar 1, 2012 at 11:57 PM, Anders Hammar wrote: >> Sonatype do some black magic for provision developer desktops, check >> their website. >> There was a demo I saw that pulled down your Eclipse binaries and >> installing plugins and did some configuration stuff. >> I believe that the bundling of the artifacts for provisioning live in >> Nexus - not sure if its a p2 or maven repository. > > You're referring to their Onboarding solution that they've turned open source: > https://github.com/sonatype/onboarding > > This is for materializing (and update) an Eclipse IDE installation. It > pulls artifacts from a P2 repository in Nexus. > > /Anders > >> >> As the other thread "Is Maven the Answer" says you may be better off >> with a pure scripting language or Ant if you want to do non >> build-lifecycle event handling. >> >> Getting Maven to do what you are suggesting is not going to be simply >> a matter of hooking assembly plugin together with some dependencies. >> You are probably going to have to develop a plugin - at which point >> you have to wonder whether it fits into the idea of Maven's lifecycle >> (and I suggest not). >> >> If you are running on Windows tools like SCCM do the installation >> management for you. >> Is it worth rolling your own? >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org