Fwd: YUI Compressor Maven plugin executed at wrong time and tomcat plugin not using yui-compressor output
By default, the compress goal of the YUI maven plugin is bound to the process-resources phase. So, you need to bind it to another phase after the war plugin has produced the war directory structure the Tomcat plugin will use. I recommand you also customize the outputDirectory parameter of the YUI maven plugin because the default value does not comply with the standard Maven War directory layout. Regards Jeff MAURY -- Forwarded message -- From: fe.character.guide fe.character.gu...@gmail.com Date: Fri, Dec 2, 2011 at 7:17 AM Subject: YUI Compressor Maven plugin executed at wrong time and tomcat plugin not using yui-compressor output To: users@maven.apache.org Hello everyone! I'm trying to get some basic maven build processes configured correctly with my Java project, and beyond Stackoverflow, I'm not sure where else to turn. I'd like to compress all of my javascript files and aggregate them using YUICompressor, and I saw that there was a maven plugin to allow me to do this. I got it working for the most part. I am also using the Mojo tomcat plugin as well. When i go to run the tomcat:run goal, tomcat does not read from the target's output directory (this is where the YUI compressor put my javascript files) - but rather, it reads from the actual source files in my src/main/ webapp/scripts directory. Of course, the aggregated javascript file (all.js) is not there. This makes sense, but is a big problem for me. I have a few questions. 1. How can I get the tomcat plugin to read the target's output folder that the yui compressor plugin created? 2. Do I have to run the yui compressor maven goal every time I want to update my javascript files during development while my tomcat instance is running? 3. How can tell Maven that I want to run the YUI compressor AFTER Maven copies over the `src/main/webapp` directory? Currently, Maven runs the YUI compressor, but then overwrites all of the compressed css and javascript files with the original source files, defeating the purposes of compressing them ;) 4. Is there a better way to achieve my objective rather than using the YUI compressor? Essentially, my end goal is to be able to develop JavaScript code in separate files and test my source files in development mode without having to aggregate them... but I want to compress and aggregate the files and use the `all.js` script when the application is running in production mode. While the Rails people have certainly figured this out, this seems to be a non-trivial thing to do with Maven and Spring. I would appreciate any and all assistance on how I can get this running correctly. Thanks! -- Legacy code often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury
Re: Generate report PDF with Maven PDF Plugin
Thank you! ;) -- View this message in context: http://maven.40175.n5.nabble.com/Generate-report-PDF-with-Maven-PDF-Plugin-tp5035890p5041661.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
Re: Handling Non-Public runtime packages
On 12/02/2011 01:47 AM, Anders Hammar wrote: I recognize your situation and here's what I've done for JBoss EAP (4.3 and 5.0): For all the runtime artifacts of the platform, I've created a tool that analyzes the dependencies between those artifacts. Based on this information I've created poms for all the artifact with this dependency info. The approach has been a best-effort, and might not be absolutely correct. For example, I'm not sure that dependencies due to annotations will be reflected. For the GAVs I've decided to give all artifacts the same groupId (mycompany-jbosseap), the artifactId is the original name of the jar and the version is the version number of the complete platform (5.0.0.GA for example). The reason for the groupId was to make sure that there would never be clash with something that JBoss/Red Hat would release. Using the version number of the platform is because it almost impossible to figure out the original version of some of the artifacts. Also, I've created import poms with dependencyManagement for all the artifacts. I have such an import pom for server side (the production server config) and one for client side. This approach works ok, but there are drawbacks. Also, some of the original decision I would probably do differently today if I started from a clean sheet. One drawback is that you could get the same artifact included twice, if some 3rd party dependency uses it's original GA. For example, servlet-api as it's original groupId is javax.servlet and not mycompany-jbosseap. This is not a problem for a knowledgeable Maven user as you just add exclusions. But for normal developers I find that this is magic and they normally never analyze their dependency tree. If I would do this again, I would spend time figuring out the correct groupId (and artifactId) for the artifactId, at least for the non-jboss ones (many of the jboss ones have changed groupId recently, which make them tricky). The version number could then be some thing like 5.0.0.GA-jbosseap to make sure it would not interfere with any official version. All developers are instructed to use these artifacts instead of any other, if possible. This will ensure that even compilation is done towards what will be the runtime platform. Then unit testing will use the same artifacts as are used in runtime. Any issues will be found as early as possible, which is important IMHO. A (customized) zip of the platform is also available from the repo. Which makes it possible to use Codehaus Cargo to automate ITs where the app server is installed, configured, started, and the application deployed to, as part of a Maven build. Quite nifty if you ask me. If you're in fact using JBoss EAP, I should inform you that Red Hat has created their own EAP 5.0 Maven repo. However, they do not have any dependency information in their poms which make their solution less good than mine IMO. They claim this will be fixed for the EAP 6.0 repo as Maven will then be used to build the platform. If I recall correctly they have the correct groupIds and artifactIds though. Search for Project Wolf to find out more. /Anders On Thu, Dec 1, 2011 at 21:00, Steve Cohenstevec...@comcast.net wrote: I am perplexed by the following situation: I work for a very large corporation with strict bureaucratic rules about what you can use. Nonetheless, they have a maven repository administered by very helpful people. However the maven repository people don't talk so much to the technical standards people (they don't even know each other) and therein lies the problem. The technical standards folks mandate that certain versions of application servers (for example, JBoss) must be used. These are not the publicly available versions commonly found but enterprise versions that are either built by RedHat for specific corporate clients or available to any paying corporate client, I'm not sure which. These come packaged in .zip files that may be downloaded from an internal corporate web site. That would be okay if all I was concerned about was creating a server to develop on. But I also need to develop against the targeted runtime of that server, and I want to use Maven, as I could with the publicly available versions of the server. To do that, I need to have these server runtime jars as Provided dependencies in my project. However, there are no poms included with this zip file. I could load every jar in the package into a team-private third party repo in the central repo, but this would then be just a bunch of jars with no inter-dependency information available. Even if POMs were available, getting them all into the repository is a non-trivial task. How does one cope with this situation? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, as I feared. What a piece of @#$$%. So those who pay for JBoss get
Re: Current state of Maven native plugins
Hi Dan I have a problem with maven native pluging, If my header file contains code like: (I mean any conditional operator in macros) /#if (_MSC_VER 1300)/ then it is giving me error operator '' has no left operand Please help me on this, Thanks In Advance, Satya -- View this message in context: http://maven.40175.n5.nabble.com/Current-state-of-Maven-native-plugins-tp4807747p5041665.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
Re: Handling Non-Public runtime packages
Who decided they're not going to support EAP6.0? Your company or JBoss/Red Hat? I don't think the jboss community version fully support Maven, at least not for jboss.org 5.0 and earlier (which EAP 5 is based on). The thing is that it is hard to do magic when the individual components don't use Maven. For jboss.org 7+ (which EAP 6 is based on) Maven will be used, from what I've heard, so then they will be able to support a EAP repo. But I believe that two of the main Maven guys at Jboss are listening to this list so they could clarify? /Anders On Fri, Dec 2, 2011 at 13:39, Steve Cohen sco...@javactivity.org wrote: On 12/02/2011 01:47 AM, Anders Hammar wrote: I recognize your situation and here's what I've done for JBoss EAP (4.3 and 5.0): For all the runtime artifacts of the platform, I've created a tool that analyzes the dependencies between those artifacts. Based on this information I've created poms for all the artifact with this dependency info. The approach has been a best-effort, and might not be absolutely correct. For example, I'm not sure that dependencies due to annotations will be reflected. For the GAVs I've decided to give all artifacts the same groupId (mycompany-jbosseap), the artifactId is the original name of the jar and the version is the version number of the complete platform (5.0.0.GA for example). The reason for the groupId was to make sure that there would never be clash with something that JBoss/Red Hat would release. Using the version number of the platform is because it almost impossible to figure out the original version of some of the artifacts. Also, I've created import poms with dependencyManagement for all the artifacts. I have such an import pom for server side (the production server config) and one for client side. This approach works ok, but there are drawbacks. Also, some of the original decision I would probably do differently today if I started from a clean sheet. One drawback is that you could get the same artifact included twice, if some 3rd party dependency uses it's original GA. For example, servlet-api as it's original groupId is javax.servlet and not mycompany-jbosseap. This is not a problem for a knowledgeable Maven user as you just add exclusions. But for normal developers I find that this is magic and they normally never analyze their dependency tree. If I would do this again, I would spend time figuring out the correct groupId (and artifactId) for the artifactId, at least for the non-jboss ones (many of the jboss ones have changed groupId recently, which make them tricky). The version number could then be some thing like 5.0.0.GA-jbosseap to make sure it would not interfere with any official version. All developers are instructed to use these artifacts instead of any other, if possible. This will ensure that even compilation is done towards what will be the runtime platform. Then unit testing will use the same artifacts as are used in runtime. Any issues will be found as early as possible, which is important IMHO. A (customized) zip of the platform is also available from the repo. Which makes it possible to use Codehaus Cargo to automate ITs where the app server is installed, configured, started, and the application deployed to, as part of a Maven build. Quite nifty if you ask me. If you're in fact using JBoss EAP, I should inform you that Red Hat has created their own EAP 5.0 Maven repo. However, they do not have any dependency information in their poms which make their solution less good than mine IMO. They claim this will be fixed for the EAP 6.0 repo as Maven will then be used to build the platform. If I recall correctly they have the correct groupIds and artifactIds though. Search for Project Wolf to find out more. /Anders On Thu, Dec 1, 2011 at 21:00, Steve Cohenstevec...@comcast.net wrote: I am perplexed by the following situation: I work for a very large corporation with strict bureaucratic rules about what you can use. Nonetheless, they have a maven repository administered by very helpful people. However the maven repository people don't talk so much to the technical standards people (they don't even know each other) and therein lies the problem. The technical standards folks mandate that certain versions of application servers (for example, JBoss) must be used. These are not the publicly available versions commonly found but enterprise versions that are either built by RedHat for specific corporate clients or available to any paying corporate client, I'm not sure which. These come packaged in .zip files that may be downloaded from an internal corporate web site. That would be okay if all I was concerned about was creating a server to develop on. But I also need to develop against the targeted runtime of that server, and I want to use Maven, as I could with the publicly available versions of the server. To do that, I need to have these server runtime
[ANN] Maven Common Artifact Filters 1.4 Released
The Maven team is pleased to announce the release of the Maven Common Artifact Filters, version 1.4 A collection of ready-made filters to control inclusion/exclusion of artifacts during dependency resolution. http://maven.apache.org/shared/maven-common-artifact-filters You should specify the version in your project's dependency configuration: dependency groupIdorg.apache.maven.shared/groupId artifactIdmaven-common-artifact-filters/artifactId version1.4/version /dependency Release Notes - Maven Common Artifact Filters - Version 1.4 Bug * [MSHARED-205] wildcard in middle of artifact-coordinate segment not recognized in Pattern*ArtifactFilter Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Assembly Plugin 2.2.2 Released
The Maven team is pleased to announce the release of the Maven Assembly Plugin, version 2.2.2 A Maven plugin to create archives of your project's sources, classes, dependencies etc. from flexible assembly descriptors. http://maven.apache.org/plugins/maven-assembly-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId version2.2.2/version /plugin Release Notes - Maven 2.x Assembly Plugin - Version 2.2.2 ** Bug * [MASSEMBLY-175] - MANIFEST entries are not preserved during assemby * [MASSEMBLY-544] - DependencySet includes filter not working in 2.2 * [MASSEMBLY-561] - Encoding is broken when filtering is enabled * [MASSEMBLY-570] - dependency includes filters don't match wildcard (*) in middle of coordinate segment * [MASSEMBLY-581] - Allow formats in configuration to override descriptor ** Improvement * [MASSEMBLY-562] - [documentation] Add links to Maven Shade plugin ** Task * [MASSEMBLY-547] - The class CommandLineUtils doesn't have an Apache license Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Error opening zip file (because it isn't there)
It is mostly a downloading issue when downloaded from the repo. When I checked out opening the jar in the .m2/repository/corresponding dependency folder then found that downloaded jar is corrupted. So one possible solution is to delete the folder and then execute the maven build commands which will again download. When i did that the error error in opening zip file was gone. -- View this message in context: http://maven.40175.n5.nabble.com/Error-opening-zip-file-because-it-isn-t-there-tp87279p5041932.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
Maven Native Pluging Problem when building
Hi I have a problem with maven native pluging, If my header file contains code like: (I mean any conditional operator in macros) #if (_MSC_VER 1300) then it is giving me error *operator '' has no left operand * Please help me on this, Thanks In Advance, Satya -- View this message in context: http://maven.40175.n5.nabble.com/Maven-Native-Pluging-Problem-when-building-tp5042408p5042408.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
RE: YUI Compressor Maven plugin executed at wrong time and tomcat plugin not using yui-compressor output
You could keep the names of the files the same (so without the -min postfix), so modifications are picked up immediately. -Robert From: jeffma...@jeffmaury.com Date: Fri, 2 Dec 2011 11:16:01 +0100 Subject: Fwd: YUI Compressor Maven plugin executed at wrong time and tomcat plugin not using yui-compressor output To: users@maven.apache.org By default, the compress goal of the YUI maven plugin is bound to the process-resources phase. So, you need to bind it to another phase after the war plugin has produced the war directory structure the Tomcat plugin will use. I recommand you also customize the outputDirectory parameter of the YUI maven plugin because the default value does not comply with the standard Maven War directory layout. Regards Jeff MAURY -- Forwarded message -- From: fe.character.guide fe.character.gu...@gmail.com Date: Fri, Dec 2, 2011 at 7:17 AM Subject: YUI Compressor Maven plugin executed at wrong time and tomcat plugin not using yui-compressor output To: users@maven.apache.org Hello everyone! I'm trying to get some basic maven build processes configured correctly with my Java project, and beyond Stackoverflow, I'm not sure where else to turn. I'd like to compress all of my javascript files and aggregate them using YUICompressor, and I saw that there was a maven plugin to allow me to do this. I got it working for the most part. I am also using the Mojo tomcat plugin as well. When i go to run the tomcat:run goal, tomcat does not read from the target's output directory (this is where the YUI compressor put my javascript files) - but rather, it reads from the actual source files in my src/main/ webapp/scripts directory. Of course, the aggregated javascript file (all.js) is not there. This makes sense, but is a big problem for me. I have a few questions. 1. How can I get the tomcat plugin to read the target's output folder that the yui compressor plugin created? 2. Do I have to run the yui compressor maven goal every time I want to update my javascript files during development while my tomcat instance is running? 3. How can tell Maven that I want to run the YUI compressor AFTER Maven copies over the `src/main/webapp` directory? Currently, Maven runs the YUI compressor, but then overwrites all of the compressed css and javascript files with the original source files, defeating the purposes of compressing them ;) 4. Is there a better way to achieve my objective rather than using the YUI compressor? Essentially, my end goal is to be able to develop JavaScript code in separate files and test my source files in development mode without having to aggregate them... but I want to compress and aggregate the files and use the `all.js` script when the application is running in production mode. While the Rails people have certainly figured this out, this seems to be a non-trivial thing to do with Maven and Spring. I would appreciate any and all assistance on how I can get this running correctly. Thanks! -- Legacy code often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANNOUNCE] Apache Maven Scm 1.6
Hello, The Apache Maven team is pleased to announce the release of Apache Maven Scm 1.6. Apache Maven SCM provide a common API for doing SCM operations. Web Site: http://maven.apache.org/scm/ Release Notes - Maven SCM - Version 1.6 ** New Feature * [SCM-619] - [patch] Add revision number in changelog clearcase command. * [SCM-630] - Request to include MKS Integrity SCM Provider along with the rest of the Maven SCM Providers * [SCM-645] - add a command to get various informations (branches, tag) from remote scm server ** Improvement * [SCM-615] - RemoveMojo to allow removing resources from version control * [SCM-631] - Mercurial SCM provider works with repository like centralized SCM's do ** Bug * [SCM-621] - Mercurial provider checkout should not default to tip * [SCM-624] - Revision number parsing can fail with lots of unstaged changes * [SCM-629] - parsing server path starting with digit * [SCM-635] - No space between number and text in scm:add result * [SCM-639] - Git repository starting with a number is not well parsed by GitScmProviderRepository * [SCM-642] - GitSatusConsumer does not report deleted file * [SCM-644] - Correctly remove directory in gitexe provider * [SCM-646] - git parser should fill changeset revision * [SCM-647] - SvnChangeLogConsumer parses filename incorrectly when file is copied from existing one * [SCM-648] - Checkout should return 0 when cloning empty repo, with no master branch ** Task * [SCM-616] - Add the blame command to providers matrix * [SCM-617] - Update documentation Provider Configuration Subversion * [SCM-620] - Publish the XML schema for svn-settings Have Fun -- The Apache Maven Team. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: YUI Compressor Maven plugin executed at wrong time and tomcat plugin not using yui-compressor output
and bind the yui compressor to prepare-package phase. As it js files will be compressed only when you will package your war for deployment on target servlet container. So js files won't be change using tomcat:run (IMHO better to have real js files for debugging purpose). 2011/12/2 Robert Scholte rfscho...@codehaus.org: You could keep the names of the files the same (so without the -min postfix), so modifications are picked up immediately. -Robert From: jeffma...@jeffmaury.com Date: Fri, 2 Dec 2011 11:16:01 +0100 Subject: Fwd: YUI Compressor Maven plugin executed at wrong time and tomcat plugin not using yui-compressor output To: users@maven.apache.org By default, the compress goal of the YUI maven plugin is bound to the process-resources phase. So, you need to bind it to another phase after the war plugin has produced the war directory structure the Tomcat plugin will use. I recommand you also customize the outputDirectory parameter of the YUI maven plugin because the default value does not comply with the standard Maven War directory layout. Regards Jeff MAURY -- Forwarded message -- From: fe.character.guide fe.character.gu...@gmail.com Date: Fri, Dec 2, 2011 at 7:17 AM Subject: YUI Compressor Maven plugin executed at wrong time and tomcat plugin not using yui-compressor output To: users@maven.apache.org Hello everyone! I'm trying to get some basic maven build processes configured correctly with my Java project, and beyond Stackoverflow, I'm not sure where else to turn. I'd like to compress all of my javascript files and aggregate them using YUICompressor, and I saw that there was a maven plugin to allow me to do this. I got it working for the most part. I am also using the Mojo tomcat plugin as well. When i go to run the tomcat:run goal, tomcat does not read from the target's output directory (this is where the YUI compressor put my javascript files) - but rather, it reads from the actual source files in my src/main/ webapp/scripts directory. Of course, the aggregated javascript file (all.js) is not there. This makes sense, but is a big problem for me. I have a few questions. 1. How can I get the tomcat plugin to read the target's output folder that the yui compressor plugin created? 2. Do I have to run the yui compressor maven goal every time I want to update my javascript files during development while my tomcat instance is running? 3. How can tell Maven that I want to run the YUI compressor AFTER Maven copies over the `src/main/webapp` directory? Currently, Maven runs the YUI compressor, but then overwrites all of the compressed css and javascript files with the original source files, defeating the purposes of compressing them ;) 4. Is there a better way to achieve my objective rather than using the YUI compressor? Essentially, my end goal is to be able to develop JavaScript code in separate files and test my source files in development mode without having to aggregate them... but I want to compress and aggregate the files and use the `all.js` script when the application is running in production mode. While the Rails people have certainly figured this out, this seems to be a non-trivial thing to do with Maven and Spring. I would appreciate any and all assistance on how I can get this running correctly. Thanks! -- Legacy code often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Native Pluging Problem when building
can you produce a test case using existing test case? what version of MSC you are using? -D On Fri, Dec 2, 2011 at 8:23 AM, Satya satyarajesh.ravip...@gmail.com wrote: Hi I have a problem with maven native pluging, If my header file contains code like: (I mean any conditional operator in macros) #if (_MSC_VER 1300) then it is giving me error *operator '' has no left operand * Please help me on this, Thanks In Advance, Satya -- View this message in context: http://maven.40175.n5.nabble.com/Maven-Native-Pluging-Problem-when-building-tp5042408p5042408.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
Profile - activeByDefault in Maven 3.0
Hi All, I am currently upgrading to maven 3 from 2. I have a settings.xml that I have been using for a couple of years now. It has a profile in it called dev it looks something like this: profiles profile iddev/id activation activeByDefaulttrue/activeByDefault /activation When I run mvn clean install in 2.0 it used this profile and all was well. Now when I run against Maven 3.0 this profile is not active. I have to run mvn clean install -Pdev to activate it. I have searched online and tried several things, the only thing that seemed to work was activeProfiles. Does this setting no longer work??? Thanks, Todd -- View this message in context: http://maven.40175.n5.nabble.com/Profile-activeByDefault-in-Maven-3-0-tp5043324p5043324.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
Re: Profile - activeByDefault in Maven 3.0
Hi Todd, tpatch wrote: Hi All, I am currently upgrading to maven 3 from 2. I have a settings.xml that I have been using for a couple of years now. It has a profile in it called dev it looks something like this: profiles profile iddev/id activation activeByDefaulttrue/activeByDefault /activation When I run mvn clean install in 2.0 it used this profile and all was well. Now when I run against Maven 3.0 this profile is not active. I have to run mvn clean install -Pdev to activate it. I have searched online and tried several things, the only thing that seemed to work was activeProfiles. Does this setting no longer work??? activeByDefault always meant that this profile is only active if none other is. If you e.g. have added a profile for M3's site plugin to use the POM for M2 or M3, well, then you have now an active one ;-) So, what does this print on console: mvn help:active-profiles Cheers, Jörg BTW: I used therefore activeProfiles even in M2 ... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Error using Maven in Red Hat 5
mvn --version + Error stacktraces are turned on. Maven version: 2.0.9 Java version: 1.6.0_29 You can most likely ignore that error and just move on with life. Basically Maven is saying you didn't tell me what build action you wanted me to take which isn't entirely accurate because you were just asking for the version, which it did provide. You're dealing with an older Maven2 release so there may be issues that were resolved in later M2 builds or even in M3. I would strongly encourage you to run M3 (ideally) or Maven 2.2.1 or 2.0.11. I wouldn't run 2.0.9 unless I had a very specific reason to do so (and its the only one available in my package manager isn't a very good reason for me). Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Where is a dependency coming from?
I have some dependencies that exist in multiple repositories that are in my search order and I want to find out which one the dependency is actually coming from, it doesn't look like the maven-dependency-plugin can do this. What I'm looking for is something like this: mvn dependency:lookup-remote-repository [INFO] The following files have been resolved: [INFO]asm:asm:jar:3.1:compile - http://repo1.maven.org/org/asm/3.1/asm-3.1.jar [INFO]com.cloudera.cdh:hadoop-ant:pom:3.0:compile - http://repository.cloudera.com/com/cloudera/cdh/hadoop-ant/3.0/hadoop-ant.jar [INFO]com.cloudera.cdh:zookeeper-ant:pom:3.0-u1:compile - http://repository.cloudera.com/com/cloudera/cdh/zookeeper/3.0-u1/zookeeper-3.0-u1.jar [INFO] ... Is there any plugin that does something like this? -- View this message in context: http://maven.40175.n5.nabble.com/Where-is-a-dependency-coming-from-tp5043524p5043524.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
Re: Handling Non-Public runtime packages
Sorry, it's our company who will not bless use of EAP 6.0 at all, but will bless it EAP 7.0 soon. Hopefully there will be Maven for that. I didn't mean to imply anything about JBoss's plans. There is a Maven repo for jboss.org 5.1.0.GA. I was groaning about having to go backwards from that. Steve On 12/02/2011 06:51 AM, Anders Hammar wrote: Who decided they're not going to support EAP6.0? Your company or JBoss/Red Hat? I don't think the jboss community version fully support Maven, at least not for jboss.org 5.0 and earlier (which EAP 5 is based on). The thing is that it is hard to do magic when the individual components don't use Maven. For jboss.org 7+ (which EAP 6 is based on) Maven will be used, from what I've heard, so then they will be able to support a EAP repo. But I believe that two of the main Maven guys at Jboss are listening to this list so they could clarify? /Anders On Fri, Dec 2, 2011 at 13:39, Steve Cohensco...@javactivity.org wrote: On 12/02/2011 01:47 AM, Anders Hammar wrote: I recognize your situation and here's what I've done for JBoss EAP (4.3 and 5.0): For all the runtime artifacts of the platform, I've created a tool that analyzes the dependencies between those artifacts. Based on this information I've created poms for all the artifact with this dependency info. The approach has been a best-effort, and might not be absolutely correct. For example, I'm not sure that dependencies due to annotations will be reflected. For the GAVs I've decided to give all artifacts the same groupId (mycompany-jbosseap), the artifactId is the original name of the jar and the version is the version number of the complete platform (5.0.0.GA for example). The reason for the groupId was to make sure that there would never be clash with something that JBoss/Red Hat would release. Using the version number of the platform is because it almost impossible to figure out the original version of some of the artifacts. Also, I've created import poms with dependencyManagement for all the artifacts. I have such an import pom for server side (the production server config) and one for client side. This approach works ok, but there are drawbacks. Also, some of the original decision I would probably do differently today if I started from a clean sheet. One drawback is that you could get the same artifact included twice, if some 3rd party dependency uses it's original GA. For example, servlet-api as it's original groupId is javax.servlet and not mycompany-jbosseap. This is not a problem for a knowledgeable Maven user as you just add exclusions. But for normal developers I find that this is magic and they normally never analyze their dependency tree. If I would do this again, I would spend time figuring out the correct groupId (and artifactId) for the artifactId, at least for the non-jboss ones (many of the jboss ones have changed groupId recently, which make them tricky). The version number could then be some thing like 5.0.0.GA-jbosseap to make sure it would not interfere with any official version. All developers are instructed to use these artifacts instead of any other, if possible. This will ensure that even compilation is done towards what will be the runtime platform. Then unit testing will use the same artifacts as are used in runtime. Any issues will be found as early as possible, which is important IMHO. A (customized) zip of the platform is also available from the repo. Which makes it possible to use Codehaus Cargo to automate ITs where the app server is installed, configured, started, and the application deployed to, as part of a Maven build. Quite nifty if you ask me. If you're in fact using JBoss EAP, I should inform you that Red Hat has created their own EAP 5.0 Maven repo. However, they do not have any dependency information in their poms which make their solution less good than mine IMO. They claim this will be fixed for the EAP 6.0 repo as Maven will then be used to build the platform. If I recall correctly they have the correct groupIds and artifactIds though. Search for Project Wolf to find out more. /Anders On Thu, Dec 1, 2011 at 21:00, Steve Cohenstevec...@comcast.netwrote: I am perplexed by the following situation: I work for a very large corporation with strict bureaucratic rules about what you can use. Nonetheless, they have a maven repository administered by very helpful people. However the maven repository people don't talk so much to the technical standards people (they don't even know each other) and therein lies the problem. The technical standards folks mandate that certain versions of application servers (for example, JBoss) must be used. These are not the publicly available versions commonly found but enterprise versions that are either built by RedHat for specific corporate clients or available to any paying corporate client, I'm not sure which. These come packaged in .zip files that may be downloaded from an internal corporate web site. That would
RE: Where is a dependency coming from?
Look at dependency:analyze-reporthttp://maven.apache.org/plugins/maven-dependency-plugin/ Martin Gainty __ Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Ez az üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet tartalma miatt. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Fri, 2 Dec 2011 16:14:18 -0800 From: deusaqui...@gmail.com To: users@maven.apache.org Subject: Where is a dependency coming from? I have some dependencies that exist in multiple repositories that are in my search order and I want to find out which one the dependency is actually coming from, it doesn't look like the maven-dependency-plugin can do this. What I'm looking for is something like this: mvn dependency:lookup-remote-repository [INFO] The following files have been resolved: [INFO]asm:asm:jar:3.1:compile - http://repo1.maven.org/org/asm/3.1/asm-3.1.jar [INFO]com.cloudera.cdh:hadoop-ant:pom:3.0:compile - http://repository.cloudera.com/com/cloudera/cdh/hadoop-ant/3.0/hadoop-ant.jar [INFO]com.cloudera.cdh:zookeeper-ant:pom:3.0-u1:compile - http://repository.cloudera.com/com/cloudera/cdh/zookeeper/3.0-u1/zookeeper-3.0-u1.jar [INFO] ... Is there any plugin that does something like this? -- View this message in context: http://maven.40175.n5.nabble.com/Where-is-a-dependency-coming-from-tp5043524p5043524.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
[mojo-announce] [ANN] Maven Findbugs plugin version 2.3.3 Released
Hi, The Mojo team is pleased to announce the release of the Maven FindBugs Plugin version 2.3.3. FindBugs uses static analysis to inspect Java bytecode for occurrences of bug patterns. You can see more about the plugin at: http://mojo.codehaus.org/findbugs-maven-plugin/ To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdfindbugs-maven-plugin/artifactId version2.3.3/version /plugin Release Notes are at: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11701version=17239 Release Notes - Maven 2.x FindBugs Plugin - Version 2.3.3 ** Bug * [MFINDBUGS-138] - debug and trace options throw an exception * [MFINDBUGS-140] - Findbugs check fails due to missing findbugsXml.xml file * [MFINDBUGS-142] - Findbugs plugins from the classpath do not work * [MFINDBUGS-146] - Report cannot correctly handle external FindBugs ruleset as exported by Sonar QA Dashboard * [MFINDBUGS-147] - findbugs:gui fails * [MFINDBUGS-149] - FindBugsMojo#executeFindBugs throws NPE * [MFINDBUGS-150] - Generated reports don't include testSourceRoots. * [MFINDBUGS-152] - FileNotFoundException with findbugs-maven-plugin v 2.3.2 and empty source folder Regards, Garvin LeClaire garvin.lecla...@gmail.com
Re: YUI Compressor Maven plugin executed at wrong time and tomcat plugin not using yui-compressor output
I tried to bind this to the prepare-package phase actually, but the copying of the webapp resources directory to the target directory still occurs after the yui:compress goal. Am I missing something? Setting the phase to process-resources actually runs the yui:compress goal before the compilation step. One idea I have to fix this is maybe put the javascript in src/main/scriptsand then compress everything to src/main/webapp/scripts... that way the package goal treats the regular source path as the final product. The real drawback to this though is that I won't be able to test my development javascript code anymore - I'd have to run the yui:compress goal EVERY time I make a change to the css and javascript - that's just too much of hassle for me. I'd also like to get functionality to work with the tomcat:run goal as well. Am I trying to get this to work with too much? Thanks for the assistance! On Fri, Dec 2, 2011 at 12:22 PM, Olivier Lamy ol...@apache.org wrote: and bind the yui compressor to prepare-package phase. As it js files will be compressed only when you will package your war for deployment on target servlet container. So js files won't be change using tomcat:run (IMHO better to have real js files for debugging purpose). 2011/12/2 Robert Scholte rfscho...@codehaus.org: You could keep the names of the files the same (so without the -min postfix), so modifications are picked up immediately. -Robert From: jeffma...@jeffmaury.com Date: Fri, 2 Dec 2011 11:16:01 +0100 Subject: Fwd: YUI Compressor Maven plugin executed at wrong time and tomcat plugin not using yui-compressor output To: users@maven.apache.org By default, the compress goal of the YUI maven plugin is bound to the process-resources phase. So, you need to bind it to another phase after the war plugin has produced the war directory structure the Tomcat plugin will use. I recommand you also customize the outputDirectory parameter of the YUI maven plugin because the default value does not comply with the standard Maven War directory layout. Regards Jeff MAURY -- Forwarded message -- From: fe.character.guide fe.character.gu...@gmail.com Date: Fri, Dec 2, 2011 at 7:17 AM Subject: YUI Compressor Maven plugin executed at wrong time and tomcat plugin not using yui-compressor output To: users@maven.apache.org Hello everyone! I'm trying to get some basic maven build processes configured correctly with my Java project, and beyond Stackoverflow, I'm not sure where else to turn. I'd like to compress all of my javascript files and aggregate them using YUICompressor, and I saw that there was a maven plugin to allow me to do this. I got it working for the most part. I am also using the Mojo tomcat plugin as well. When i go to run the tomcat:run goal, tomcat does not read from the target's output directory (this is where the YUI compressor put my javascript files) - but rather, it reads from the actual source files in my src/main/ webapp/scripts directory. Of course, the aggregated javascript file (all.js) is not there. This makes sense, but is a big problem for me. I have a few questions. 1. How can I get the tomcat plugin to read the target's output folder that the yui compressor plugin created? 2. Do I have to run the yui compressor maven goal every time I want to update my javascript files during development while my tomcat instance is running? 3. How can tell Maven that I want to run the YUI compressor AFTER Maven copies over the `src/main/webapp` directory? Currently, Maven runs the YUI compressor, but then overwrites all of the compressed css and javascript files with the original source files, defeating the purposes of compressing them ;) 4. Is there a better way to achieve my objective rather than using the YUI compressor? Essentially, my end goal is to be able to develop JavaScript code in separate files and test my source files in development mode without having to aggregate them... but I want to compress and aggregate the files and use the `all.js` script when the application is running in production mode. While the Rails people have certainly figured this out, this seems to be a non-trivial thing to do with Maven and Spring. I would appreciate any and all assistance on how I can get this running correctly. Thanks! -- Legacy code often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: YUI Compressor Maven plugin executed at wrong time and tomcat plugin not using yui-compressor output
There's a lot that confuses me too about how to get this to work with tomcat:run. For example, if I am in development mode, I actually want to use the uncompressed javascript files for the same reason you said - it'll be better to debug and reason about the code. But I'd also like to test the production profile I made just to make sure everything continues to work after the files are compressed. I don't want to just trust it ;) At least not until I feel really comfortable with everything and I know it all will just work. Essentially, my goal is to have an easy programming model where I can create and edit javascript files and test them when my application is run via tomcat in development mode, but then I want the application to use the all.js when the application is running in tomcat in production mode. Ken On Fri, Dec 2, 2011 at 11:38 PM, Ken Egervari ken.egerv...@gmail.comwrote: I tried to bind this to the prepare-package phase actually, but the copying of the webapp resources directory to the target directory still occurs after the yui:compress goal. Am I missing something? Setting the phase to process-resources actually runs the yui:compress goal before the compilation step. One idea I have to fix this is maybe put the javascript in src/main/scripts and then compress everything to src/main/webapp/scripts... that way the package goal treats the regular source path as the final product. The real drawback to this though is that I won't be able to test my development javascript code anymore - I'd have to run the yui:compressgoal EVERY time I make a change to the css and javascript - that's just too much of hassle for me. I'd also like to get functionality to work with the tomcat:run goal as well. Am I trying to get this to work with too much? Thanks for the assistance! On Fri, Dec 2, 2011 at 12:22 PM, Olivier Lamy ol...@apache.org wrote: and bind the yui compressor to prepare-package phase. As it js files will be compressed only when you will package your war for deployment on target servlet container. So js files won't be change using tomcat:run (IMHO better to have real js files for debugging purpose). 2011/12/2 Robert Scholte rfscho...@codehaus.org: You could keep the names of the files the same (so without the -min postfix), so modifications are picked up immediately. -Robert From: jeffma...@jeffmaury.com Date: Fri, 2 Dec 2011 11:16:01 +0100 Subject: Fwd: YUI Compressor Maven plugin executed at wrong time and tomcat plugin not using yui-compressor output To: users@maven.apache.org By default, the compress goal of the YUI maven plugin is bound to the process-resources phase. So, you need to bind it to another phase after the war plugin has produced the war directory structure the Tomcat plugin will use. I recommand you also customize the outputDirectory parameter of the YUI maven plugin because the default value does not comply with the standard Maven War directory layout. Regards Jeff MAURY -- Forwarded message -- From: fe.character.guide fe.character.gu...@gmail.com Date: Fri, Dec 2, 2011 at 7:17 AM Subject: YUI Compressor Maven plugin executed at wrong time and tomcat plugin not using yui-compressor output To: users@maven.apache.org Hello everyone! I'm trying to get some basic maven build processes configured correctly with my Java project, and beyond Stackoverflow, I'm not sure where else to turn. I'd like to compress all of my javascript files and aggregate them using YUICompressor, and I saw that there was a maven plugin to allow me to do this. I got it working for the most part. I am also using the Mojo tomcat plugin as well. When i go to run the tomcat:run goal, tomcat does not read from the target's output directory (this is where the YUI compressor put my javascript files) - but rather, it reads from the actual source files in my src/main/ webapp/scripts directory. Of course, the aggregated javascript file (all.js) is not there. This makes sense, but is a big problem for me. I have a few questions. 1. How can I get the tomcat plugin to read the target's output folder that the yui compressor plugin created? 2. Do I have to run the yui compressor maven goal every time I want to update my javascript files during development while my tomcat instance is running? 3. How can tell Maven that I want to run the YUI compressor AFTER Maven copies over the `src/main/webapp` directory? Currently, Maven runs the YUI compressor, but then overwrites all of the compressed css and javascript files with the original source files, defeating the purposes of compressing them ;) 4. Is there a better way to achieve my objective rather than using the YUI compressor? Essentially, my end goal is to be able to develop JavaScript code in separate files and test my source files in development mode without having to aggregate
