Re: don't execute submodules for specific goals
The '-N' option avoids recursing into sub-projects: $ mvn -N plugin:goal See 'mvn -h' for other options ciao, PC Johannes Zillmann-3 wrote: Hi there, i have a multi module project and run into following problmem. In the root pom i defined a plugin. build plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.0-alpha-4/version inheritedfalse/inherited /plugin ... i set inherited to false, because when i execute a goal of the plugin ($ mvn dependency:unpack) i want not that the plugin gets executed in every sub-module. But it get executed and the inherited flag only leads to an exception because i want to execute a plugin-goal on an project where the plugin is not defined. So is there a way to only execute the plugin-goal for the root project ? best regards Johannes ~~~ 101tec GmbH Halle (Saale), Saxony-Anhalt, Germany http://www.101tec.com -- View this message in context: http://www.nabble.com/don%27t-execute-submodules-for-specific-goals-tp17752677p17754781.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: classpath fileseparator problem in generated manifest file under winxp
Using the classpathPrefix.\/classpathPrefix tag, you're telling the Jar plugin to put that prefix - and it seems to behave correctly. always visit the plugin's doc pages for details: http://maven.apache.org/plugins/maven-jar-plugin/ Maven Jar Plugin http://maven.apache.org/shared/maven-archiver/examples/classpath.html Maven Archiver Regards, PC Thalmeiner Zsolt wrote: Hello, I'm building a Java project using Maven 2.0.9 and JVM 1.5.0_14 on Windows XP. My project depends on runtime from some jar files that are resides in the same directory with my jar so I put this configuration to my pom.xml: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId version2.2/version configuration archive manifest addClasspathtrue/addClasspath classpathPrefix.\/classpathPrefix /manifest /archive /configuration /plugin After build the manifest file in my jar file contains all dependencies with prefix ./ Is this a bug or I missed something? Regards, th - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/classpath-fileseparator-problem-in-generated-manifest-file-under-winxp-tp17312374p17313594.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: classpath fileseparator problem in generated manifest file under winxp
This is not a Maven problem. The classpath entry in the manifest file is platform independent, and all paths are relative to the containing jar - you shouldn't even need the ./ prefix. see http://mindprod.com/jgloss/jar.html#CLASSPATH Regards, PC Thalmeiner Zsolt wrote: Using the classpathPrefix.\/classpathPrefix tag I want to get .\ (backslash) as prefix but the manifest file contains ./ (slash) prefixes. Unfortunatelly running the jar under WinXP doesn't recognizes paths with slashes :( I wrote to the list because I didn't found any information in doc pages to handle this problem. Regards, th - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/classpath-fileseparator-problem-in-generated-manifest-file-under-winxp-tp17312374p17314180.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Default Value for File Encoding
Hi all, +1 [a] with a few considerations (please, correct me if i'm wrong): - backward compatibility is not a must, but a cost if not assured; runtime charset errors (other than build-breaking ones) may be hard to detect - most companies have uniform OS platforms; teams with non-uniform developing environments have already faced this problem: editing a file with a different encoding requires some thought.. far before building - most editors allow you select a proper charset, but they (usually) automatically detect the default (file.encoding); it'd be not comfortable changing every time the charset to a different one only because maven said this is the standard; i.e., i wouldn't exchange platform-dependence with implicit charset-dependence (potential drawbacks on all other kinds of editor - java/sql/xml/properties/..) - big trans-national companies (should!) have centralized and well-configured building-machine to be asked for deliverables; those deliverables are surely reproducible and should be deployed to official/uniform testing and production environments regards, Paolo Benjamin Bentmann wrote: Dear community, the Maven team is currently discussing a proposal about the future handling of source file encoding by the various plugins, please see our wiki article [0] for all details. A controversial aspect of this proposal is which file encoding should be assumed in case the user did not specify this in the POM. This poll should help us to come to a well-founded decision. These are the two possible directions to go: a) Use the current platform encoding, aka the system property file.encoding. b) Use a static/fixed value that is defined by convention, i.e. is not platform-dependent. Approach a) matches the current behavior of most plugins and is as such backwards-compatible. Approach b) on the other hand can potentially break builds when users update to a newer version of an affected plugin if: - the build relies on an encoding other than ASCII/Latin-1 and - this encoding is not explicitly stated in the plugin configuration The reason why b) was suggested is its positive effect on build reproducibility: Unlike approach a), a build will out-of-the-box deliver the same output for all team members regardless of their OS or locale. It is now to balance if this improvement is worth the potential breaks as illustrated above. So, please let us know: [a] Use platform default encoding, keep backward-compat [b] Use fixed default encoding, be platform-independent Regards, Benjamin Bentmann [0] http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-POLL--Default-Value-for-File-Encoding-tp16958386s177p16963039.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: metrics report-plugin (for cyclomatic complexity + loc)
Hi, give a try to these 2 plugins (insert the following snippet in your pom.xml): reporting plugins [...] plugin !-- JavaNCSS - A Source Measurement Suite for Java http://www.kclee.de/clemens/java/javancss/ -- groupIdorg.codehaus.mojo/groupId artifactIdjavancss-maven-plugin/artifactId /plugin plugin !-- A Java package dependency analyzer that generates design quality metrics http://clarkware.com/software/JDepend.html -- groupIdorg.codehaus.mojo/groupId artifactIdjdepend-maven-plugin/artifactId /plugin plugin [...] /plugins /reporting Both will run during the site generation phase, creating reports to link in the project's site. Take a look at their home pages for more details and options. Maybe you'll be interested in these 2, as well: plugin !-- PMD code analysis tool + Copy/Paste Detector tool http://maven.apache.org/plugins/maven-pmd-plugin/usage.html -- groupIdorg.apache.maven.plugins/groupId artifactIdmaven-pmd-plugin/artifactId configuration targetjdk1.4.2/targetjdk formatxml/format linkXreftrue/linkXref sourceEncodingutf-8/sourceEncoding /configuration /plugin plugin !-- FindBugs uses static analysis to inspect Java bytecode for occurrences of bug patterns http://mojo.codehaus.org/findbugs-maven-plugin/introduction.html -- groupIdorg.codehaus.mojo/groupId artifactIdfindbugs-maven-plugin/artifactId configuration thresholdNormal/threshold effortMin/effort /configuration /plugin All of them greatly integrate with the source xref plugin, linking each problem to the source code: plugin !-- JXR is a source cross referencing tool http://maven.apache.org/plugins/maven-jxr-plugin/howto.html -- groupIdorg.codehaus.mojo/groupId artifactIdjxr-maven-plugin/artifactId /plugin Cheers, Paolo aldana wrote: hi, to make code smells more visible and to better find out refactoring targets amongst others i want to introduce some metrics. for that i miss a plugin which measures the cyclomatic complexity and loc (for classes, methods). surprisingly i did not find any maven plugin which offers this... maybe somebody can point me out to one? thanks. -- View this message in context: http://www.nabble.com/metrics-report-plugin-%28for-cyclomatic-complexity-%2B-loc%29-tp16823833s177p16823846.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
