maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff MAURY <jeffma...@jeffmaury.com>
Subject Re: JNI jars dependencies
Date Mon, 17 Sep 2012 12:50:34 GMT
Simone,

You're right, this is a limitation of artifact produced by profiles. Unless
you can live with classifier computed from the running platform.

Jeff


On Mon, Sep 17, 2012 at 9:09 AM, Simone Tripodi <simonetripodi@apache.org>wrote:

> Salut Jeff,
>
> profiling sounds a good idea but I didn't understand how mvn is able
> to resolve profiled dependencies, I mean, in my project X I need to
> import the c.jar dependency with mac-x86_64 as classifier - how to
> guarantee transitive dependencies are imported for the same platform
> (same classifier)?
>
> TIA!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
> On Fri, Sep 14, 2012 at 7:52 PM, Jeff MAURY <jeffmaury@gmail.com> wrote:
> > Can't you define the platform classifier in the parent POM (through
> > profiles) as a property and this property in the child POMs ?
> >
> > Jeff
> > Le 14 sept. 2012 16:21, "Simone Tripodi" <simonetripodi@apache.org> a
> > écrit :
> >
> >> Hi David,
> >>
> >> thanks a lot - my issue anyway is NOT compiling the code, rather than
> >> managing the dependencies, the software has been provided by a 3rd
> >> party and is closed source, I just have the jars.
> >>
> >> So, let's suppose I need the c.jar for mac-x86_64, when specifying
> >> that classifier I aim that a.jar and b.jar, that are transitive
> >> dependencies, are brought for the same platform...
> >>
> >> Any suggestion?
> >> TIA!!!
> >> -Simo
> >>
> >> http://people.apache.org/~simonetripodi/
> >> http://simonetripodi.livejournal.com/
> >> http://twitter.com/simonetripodi
> >> http://www.99soft.org/
> >>
> >>
> >> On Fri, Sep 14, 2012 at 3:40 PM, David Hoffer <dhoffer6@gmail.com>
> wrote:
> >> > There is also the native-maven-plugin.  I'm not sure which is
> best/most
> >> > current as it's been years since I have used either one, but they both
> >> set
> >> > out to help manage builds with native code.
> >> >
> >> > -Dave
> >> >
> >> > On Fri, Sep 14, 2012 at 7:31 AM, Simone Tripodi <
> >> simonetripodi@apache.org>wrote:
> >> >
> >> >> Hi Martin,
> >> >>
> >> >> very good news, thanks a lot, I am going to have a look at that
> plugin!
> >> >>
> >> >> All the best,
> >> >> -Simo
> >> >>
> >> >> http://people.apache.org/~simonetripodi/
> >> >> http://simonetripodi.livejournal.com/
> >> >> http://twitter.com/simonetripodi
> >> >> http://www.99soft.org/
> >> >>
> >> >>
> >> >> On Fri, Sep 14, 2012 at 3:26 PM, Martin Eisengardt
> >> >> <martin.eisengardt@gmail.com> wrote:
> >> >> > Ask google about maven-nar-plugin.
> >> >> >
> >> >> > It introduces nar dependencies (<type>nar</type>)
and internally
> >> tries to
> >> >> > find out the correct qualifier depending on the current
> >> >> > machine/architecture.
> >> >> >
> >> >> > I am playing around with it because I have a similar situation.
> There
> >> is
> >> >> a
> >> >> > problem with the project because there are tens of orks on github.
> If
> >> you
> >> >> > have any questions about it please ask. I have contact to one
of
> the
> >> >> ative
> >> >> > authors and we try to merge all the forks.
> >> >> >
> >> >> > On Fri, Sep 14, 2012 at 3:13 PM, Simone Tripodi <
> >> >> simonetripodi@apache.org>wrote:
> >> >> >
> >> >> >> Hi all guys,
> >> >> >>
> >> >> >> I have the task of managing a 3rd party forest of dependencies
> which
> >> >> >> contain JNI code, so let's immagine that the provided library
> >> >> >> directory tree is as shown below:
> >> >> >>
> >> >> >> linux-i386
> >> >> >> ├── a.jar
> >> >> >> ├── b.jar (depends from a.jar)
> >> >> >> └── c.jar (depends from a.jar and b.jar)
> >> >> >>
> >> >> >> linux-x86_64
> >> >> >> ├── a.jar
> >> >> >> ├── b.jar (depends from a.jar)
> >> >> >> └── c.jar (depends from a.jar and b.jar)
> >> >> >>
> >> >> >> mac-x86_64
> >> >> >> ├── a.jar
> >> >> >> ├── b.jar (depends from a.jar)
> >> >> >> └── c.jar (depends from a.jar and b.jar)
> >> >> >>
> >> >> >> I was going to put all that jar in my Nexus installation,
when I
> just
> >> >> >> realized I need classifiers to manage each platform... While
> manage a
> >> >> >> single dependency would be really easy, managing transitive
> >> >> >> dependencies per platform is not trivial, should be profiled...
> >> >> >>
> >> >> >> Do you have any suggestion on how that situation could be
handled?
> >> >> >>
> >> >> >> Many thanks in advance, all the best!
> >> >> >> -Simo
> >> >> >>
> >> >> >> http://people.apache.org/~simonetripodi/
> >> >> >> http://simonetripodi.livejournal.com/
> >> >> >> http://twitter.com/simonetripodi
> >> >> >> http://www.99soft.org/
> >> >> >>
> >> >> >>
> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> >> >> For additional commands, e-mail: users-help@maven.apache.org
> >> >> >>
> >> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: users-help@maven.apache.org
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
>



-- 
Jeff MAURY


"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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message