Re: SV: Maven, DLLs and repositories...how ?
On Wed, June 6, 2007 8:50 am, Arne Styve wrote: Thanks for your input. I'll give this a try. However, how do you then use the JAR containing all the DLLs and .so's ? As far as I've understood, you cannot access a DLL that is inside a JAR, and hence you have to extract the DLLs from the JAR in order to use the DLL. Is this correct ? In our case, we create a final assembly that either copies or unpacks the various artifacts and places them where they need to be in the assembly. We have Matlab produced artifacts (which aren't unpacked) and DLLs-wrapped-in-jars (which are unpacked) that go into the assembly, which we then give to the production guys for deployment. A second approach which we also use in one or two places is to use the dependency plugin to copy and or unpack jars, and place them in various places where necessary. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SV: Maven, DLLs and repositories...how ?
On Wed, June 6, 2007 8:50 am, Arne Styve wrote: Thanks for your input. I'll give this a try. However, how do you then use the JAR containing all the DLLs and .so's ? As far as I've understood, you cannot access a DLL that is inside a JAR, and hence you have to extract the DLLs from the JAR in order to use the DLL. Is this correct ? In our case, we create a final assembly that either copies or unpacks the various artifacts and places them where they need to be in the assembly. We have Matlab produced artifacts (which aren't unpacked) and DLLs-wrapped-in-jars (which are unpacked) that go into the assembly, which we then give to the production guys for deployment. A second approach which we also use in one or two places is to use the dependency plugin to copy and or unpack jars, and place them in various places where necessary. Great, thanks Graham ! Regards Arne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SV: Maven, DLLs and repositories...how ?
On 6 Jun 07, at 2:50 AM 6 Jun 07, Arne Styve wrote: Hi Jason, Thanks for your input. I'll give this a try. However, how do you then use the JAR containing all the DLLs and .so's ? As far as I've understood, you cannot access a DLL that is inside a JAR, and hence you have to extract the DLLs from the JAR in order to use the DLL. Is this correct ? There is an artifact handler that unpacks them to be used from the local repository. Mark has the full details as he's the one who implemented the solution and is working great at SLAC. Regards Arne On Tue, June 5, 2007 10:07 am, Arne Styve wrote: I have a question related to using DLLs with Maven. We colaborate with a company that develops parts of our system. They deliver their component as a set of DLLs. I've used JNI to create a Java interface to these DLL, so that I can use Java to develop the software that will use the DLLs. How can I set up a Maven2 project that takes these DLLs and deploy them correctly to our company repository, so that I in my project, where I am going to use the DLLs, can add dependencies to the DLLs the usual Maven2 way ? I.e. this project will not have any sourcefiles, only the 4 DLLs. We faced the same problem. Originally we tried to publish the DLL artifact into the repository directly, but this caused problems for us, as our JNI native code had to run on Windows, Linux and Solaris, and maintaining the proper naming conventions and suffixes was a pain. We eventually opted to wrap the JNI DLLs / .so files inside a jar, and publish the jar in the repository, including a classifier to show both the platform (windows / linux / solaris) and architecture (x86, amd64, etc). From that point on we only needed to worry about the name of the jar, which was consistent across platforms. When you have multiple DLLs, putting them in a jar reduces them down from many artifacts to one artifact, which is easier to deal with. This is the pom we use, it should give some clues. The DLLs are built by ant using the antrun plugin, and maven worries about the packaging and deployment: project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion parent artifactIdalchemy-ii-native/artifactId groupIdalchemy/groupId version4.0.30-SNAPSHOT/version /parent artifactIdalchemy-cdo/artifactId packagingjar/packaging nameAlchemy Native CDO/name descriptionPlaceholder for the CDO stuff from London/description build extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-webdav/artifactId version1.0-beta-2/version /extension /extensions sourceDirectorysrc/main/java/sourceDirectory !--testSourceDirectorysrc/testSourceDirectory-- resources resource directorytarget/build/directory includes include*.dll/include /includes /resource resource directorytarget/build/directory includes include*.dylib/include /includes /resource resource directorytarget/build/directory includes include*.so/include /includes /resource resource directorysrc/main/resources/directory filteringtrue/filtering includes includealchemy-cdo-version.properties/include /includes /resource /resources plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdnative-maven-plugin/artifactId extensionstrue/extensions !-- Generate JNI header files based on a list of class name on the classpath -- !-- The generated include directory is automatically added to include path at compile phase -- !-- Ensure to have appropriate denpendency jar file(s) in your pom -- executions execution idjavah/id phasegenerate-sources/phase configuration classNames classNamealchemy.cdo.measure.CDOTranche/className /classNames !-- | Note: |1. Without classNames, javah mojo will search for all JNI classes | in your dependency list. -- /configuration goals goaljavah/goal /goals /execution /executions /plugin !-- trigger the ant build -- plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-antrun-plugin/artifactId executions execution id2antrun/id phaseprocess-sources/phase!-- needs to run BEFORE resources -- configuration tasks ant
Re: SV: Maven, DLLs and repositories...how ?
Hi have a look at http://java.freehep.org/freehep-nar-plugin Regards Mark Donszelmann On Jun 6, 2007, at 8:10 AM, Jason van Zyl wrote: On 6 Jun 07, at 2:50 AM 6 Jun 07, Arne Styve wrote: Hi Jason, Thanks for your input. I'll give this a try. However, how do you then use the JAR containing all the DLLs and .so's ? As far as I've understood, you cannot access a DLL that is inside a JAR, and hence you have to extract the DLLs from the JAR in order to use the DLL. Is this correct ? There is an artifact handler that unpacks them to be used from the local repository. Mark has the full details as he's the one who implemented the solution and is working great at SLAC. Regards Arne On Tue, June 5, 2007 10:07 am, Arne Styve wrote: I have a question related to using DLLs with Maven. We colaborate with a company that develops parts of our system. They deliver their component as a set of DLLs. I've used JNI to create a Java interface to these DLL, so that I can use Java to develop the software that will use the DLLs. How can I set up a Maven2 project that takes these DLLs and deploy them correctly to our company repository, so that I in my project, where I am going to use the DLLs, can add dependencies to the DLLs the usual Maven2 way ? I.e. this project will not have any sourcefiles, only the 4 DLLs. We faced the same problem. Originally we tried to publish the DLL artifact into the repository directly, but this caused problems for us, as our JNI native code had to run on Windows, Linux and Solaris, and maintaining the proper naming conventions and suffixes was a pain. We eventually opted to wrap the JNI DLLs / .so files inside a jar, and publish the jar in the repository, including a classifier to show both the platform (windows / linux / solaris) and architecture (x86, amd64, etc). From that point on we only needed to worry about the name of the jar, which was consistent across platforms. When you have multiple DLLs, putting them in a jar reduces them down from many artifacts to one artifact, which is easier to deal with. This is the pom we use, it should give some clues. The DLLs are built by ant using the antrun plugin, and maven worries about the packaging and deployment: project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion parent artifactIdalchemy-ii-native/artifactId groupIdalchemy/groupId version4.0.30-SNAPSHOT/version /parent artifactIdalchemy-cdo/artifactId packagingjar/packaging nameAlchemy Native CDO/name descriptionPlaceholder for the CDO stuff from London/ description build extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-webdav/artifactId version1.0-beta-2/version /extension /extensions sourceDirectorysrc/main/java/sourceDirectory !--testSourceDirectorysrc/testSourceDirectory-- resources resource directorytarget/build/directory includes include*.dll/include /includes /resource resource directorytarget/build/directory includes include*.dylib/include /includes /resource resource directorytarget/build/directory includes include*.so/include /includes /resource resource directorysrc/main/resources/directory filteringtrue/filtering includes includealchemy-cdo-version.properties/include /includes /resource /resources plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdnative-maven-plugin/artifactId extensionstrue/extensions !-- Generate JNI header files based on a list of class name on the classpath -- !-- The generated include directory is automatically added to include path at compile phase -- !-- Ensure to have appropriate denpendency jar file(s) in your pom -- executions execution idjavah/id phasegenerate-sources/phase configuration classNames classNamealchemy.cdo.measure.CDOTranche/className /classNames !-- | Note: |1. Without classNames, javah mojo will search for all JNI classes | in your dependency list. -- /configuration goals goaljavah/goal /goals /execution /executions /plugin !-- trigger the ant build -- plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-antrun-plugin/artifactId executions execution
