AUTO: Warren Cook is out of the office (returning 06/09/2015)
I am out of the office until 06/09/2015. Hello, I'm on vacation Friday. And will be online untl 10:30 am Monday then golfing the rest of the day. thx, Warren Note: This is an automated response to your message Help needed with a strange fixed filename sent on 6/5/2015 6:58:45 AM. This is the only notification you will receive while this person is away.
Help needed with a strange fixed filename
Hi folks'es, I am having some problems, getting an external jar-file into my Maven project. Here is the issue: · the jar file has a fixed name, lets say jarfile3.jar (digit 3 is important!) · it's name cannot be changed because during runtime it is checked and if changed a runtime exception is thrown · if I create an artefact for it in my nexus, the file name is changed to jarfile-3.x.x · adding this to my pom.xml as a dependency everything builds just fine · however, if I run my application now, it falls over with the above runtime exception What would be the best way of incoorporating an external jar into my project without having hard-coded pathnames? We are using Eclipse Kepler as IDE and Maven 3 Thanks, _ SecurIntegration Thomas Klöber Software Engineer Rösrather Str. 702 51107 Köln Fon: +49 (221) 71 99 00-0 Fax: +49 (221) 71 99 00-23 www.SecurIntegration.comhttp://www.SecurIntegration.com Amtsgericht Köln HRB 35063 Geschäftsführer: Guido Schneider Determine your actual SAP license needshttp://www.securintegration.com/slc
Re: Help needed with a strange fixed filename
Hi Thomas, That the file is names in Nexus is the default naming schema within a maven repository so there is no chance to change it. So first question: Why not changing the code which checks the filename and follow the naming convention..? What you can do is to get the appropriate artifact via plugin (like maven-dependency-plugin) and rename it during the packaging of your distribution archive (which i assume you have?) Or are we talking about an EAR file? On 6/5/15 1:58 PM, Thomas Klöber wrote: Hi folks'es, I am having some problems, getting an external jar-file into my Maven project. Here is the issue: · the jar file has a fixed name, lets say jarfile3.jar (digit 3 is important!) · it's name cannot be changed because during runtime it is checked and if changed a runtime exception is thrown · if I create an artefact for it in my nexus, the file name is changed to jarfile-3.x.x · adding this to my pom.xml as a dependency everything builds just fine · however, if I run my application now, it falls over with the above runtime exception What would be the best way of incoorporating an external jar into my project without having hard-coded pathnames? We are using Eclipse Kepler as IDE and Maven 3 Thanks, _ SecurIntegration Thomas Klöber Software Engineer Rösrather Str. 702 51107 Köln Fon: +49 (221) 71 99 00-0 Fax: +49 (221) 71 99 00-23 www.SecurIntegration.comhttp://www.SecurIntegration.com Amtsgericht Köln HRB 35063 Geschäftsführer: Guido Schneider Determine your actual SAP license needshttp://www.securintegration.com/slc Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Javadoc plugin - centralized branding
Apologies. It seems I didn't look into the docs as much as I should have. The trick is to use the maven-javadoc-plugin resourceArtifacts parameter. I've documented a recipe for how an organization may centralize its Javadoc branding in this answer on SO:http://stackoverflow.com/a/30668813/1504556 On Friday, May 29, 2015 6:35 AM, Peter Hansson peterhansson...@yahoo.com.INVALID wrote: Hi all, I would like to be able to centralize our company's branding of Javadoc and cannot figure out how to do that with the Javadoc plugin. All projects in our company inherit from the same POM, known as our company pom. So far, so good. We've managed to centralize the use of our Javadoc *stylesheet* by doing the following in the company pom: plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId version2.9.1/version configuration stylesheetfilecom/acme/javadoc/jdoc-stylesheet.css/stylesheetfile /configuration dependencies dependency groupIdcom.acme.javadoc/groupId artifactIdstylesheet/artifactId version1.0/version typejar/type /dependency /dependencies /plugin /plugins This works well and is also quite well documented by the plugin (thanks!). However a 'branding package' contains other things than just a stylesheet, namely things such as images (logos), js files, etc. While the javadoc plugin has indeed several options to let you include resources (the word for images, etc) there doesn't seem to be a way to do this via a dependency, meaning there doesn't seem to be a way that we can centralize our javadoc 'branding package'. How do people generally solve this issue? Peter - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Assembly Plugin 2.5.5 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Assembly Plugin, version 2.5.5 The Assembly Plugin for Maven is primarily intended to allow users to aggregate the project output along with its dependencies, modules, site documentation, and other files into a single distributable archive. This release fixes a serious problem with 2.5.5 when creating jar files, MASSEMBLY-768. 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.5.5/version /plugin Release Notes - Maven Assembly Plugin - Version 2.5.5 ** Bug * [MASSEMBLY-767] - Schema missing from the web site * [MASSEMBLY-768] - JarInputStream unable to find manifest created by version 2.5.4 * [MASSEMBLY-769] - ZIP fileMode permissions not properly set with dependencySet and unpackOptions Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
