Hi
in the freehep-nar-plugin (for maven 1, being ported to maven 2)
we have such a solution.
We build a generic jar file (with classes as needed and a special
properties file).
The properties file refers to native jar files (nar files), normally:
the noarch file which has the include directories
and a aol (architecture-os-linker) file which contains
native libraries.
The user in his pom just refers to the generic jar file for his
dependency.
The NAR plugin uses (for maven 2) its own packaging (nar) which
resembles the jar packaging, but adds goals to several phases.
Maven will download the generic jar file.
The nar packing will look in the properties file and download
any referred nar files (some of which are "aol" specific for the
platform you run maven on).
It will then unpack the nar files into a nar directory in the local
repository. And add specific include paths and library settings
to the local compiler/linker setup. This uses cpptasks to get the
job done.
In the end, the generated lib and include files for the project are
wrapped up in a generic jar file and a noarch and aol nar file.
These are installed/deployed as usual. The noarch and aol
files are attached artifacts.
Another project can thus rely on this (native) library.
There is very little to configure by the user, apart from a
reference to the nar plugin, the type (shared, static, ...)
of library to be produced, and the nar packaging.
The nar plugin exists for maven 1 (with a slightly
different approach since there is no packaging in maven1)
http://java.freehep.org/freehep-nar-plugin
and we are porting it currently to maven2.
Regards
Mark Donszelmann
On Jun 16, 2006, at 10:32 AM, Hiram Chirino wrote:
On 5/9/06, Richard van der Hoff <[EMAIL PROTECTED]> wrote:
...
This brings me to my next thought, which is that the maven "artifact"
probably ought to be a zip file (or similar) containing the
correctly-named library. This is good because it means my
artifacts have
the same extension no matter what platform they were built for; I can
distinguish between platforms using the classifier; and I can be sure
that the name of the library itself is just right for the given
platform.
On the other hand, it means I now need to set up my assembly such
that
the zip files are unpacked. Ideally, I'd like for all such
artifacts to
be unpacked automatically, but there doesn't seem to be any way of
doing
so without configuring it in each assembly.xml. It's a property of
the
artifact, rather than the assembly, so it would be nice to somehow
derive this from an ArtifactHandler rather than in the assembly
descriptor. I can probably fudge this with a shared assembly
descriptor,
however.
...
I think your on the right path here. Having the native artifacts in
zip would very handy. But how about instead of the artifact being a
zip, it's a directory? If maven could deploy and retrieve a whole
directory as an artifact, it should make things easier for your use
case correct?
The reason I'm think this way, is that in the native world, if you
want to distribute a native .dll (shared library), the library is more
than just the dll, you also have to distribute the .h files the define
the interfaces into that binary shared library. And if there were
being pushed up into a maven repo, then when it was downloaded, the
c++ compiler would need to add to the include path the directory where
those .h files are at. So those .h files need to be in a directory,
not in a .zip file.
And note, if an artifact is a directory, I don't care is maven zip /
tars that directory when it puts it on the remote repo, a long as when
it puts it on the local repo it back to it's original directory form.
--
Regards,
Hiram
Blog: http://hiramchirino.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
