Tool chains don't help at runtime... But for system scope you likely need a
level above to inject the deps into the ext folder (or use a system
property for the JVM startup options)... But point us these are deps
required but required outside of the scope that is reasonably managed by
maven. They fit mire as platform "extensions" to my mind
On Sunday, 24 November 2013, Hervé BOUTEMY wrote:
> don't we have toolchains for such a case?
>
> Regards,
>
> Hervé
>
> Le dimanche 24 novembre 2013 20:13:38 Stephen Connolly a écrit :
> > On 24 November 2013 19:42, Robert Patrick <robert.patr...@oracle.com>
> wrote:
> > > > Additionally, I think we should refine scopes... there are some that
> are
> > >
> > > likely missing and some, such as `system` that should be removed.
> > >
> > > Pardon my ignorance but while I understand the negative implications of
> > > using system-scoped dependencies, I believe there are cases at least a
> few
> > > use cases where they are required. For example, we have a plugin that
> > > depends on tools.jar from the JDK. We currently use a system-scoped
> > > dependency for this. If you were to remove system-scoped dependencies,
> > > how
> > > would you propose that people handle use cases such as this?
> >
> > I think that we need a less Java centric concept for this... or at least
> to
> > rework it...
> >
> > Perhaps it is part of the platform specification, since the ext directory
> > is really a function of the platform in some senses. The current design
> is
> > really supposed to only work with ${java.home} paths... and didn't even
> > work with those for OSX at least until Oracle took over JDK on OSX... too
> > much abuse of this as a hack leads me to think that its current
> incarnation
> > is just bad design... and I would rather strip out bad design if we have
> > the chance... of course I am but one voice... if others make compelling
> > arguments against then we can let the project committers vote and decide
> in
> > the absence of consensus... but until we get to that point I think we
> need
> > a healthy debate... this is a subject we have ignored to our peril for
> far
> > far too long
> >
> > > -----Original Message-----
> > > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> > > Sent: Sunday, November 24, 2013 1:34 PM
> > > To: Maven Developers List
> > > Subject: Re: Model Version 5.0.0
> > >
> > > On 24 November 2013 17:44, Jason van Zyl <ja...@tesla.io> wrote:
> > > > On Nov 24, 2013, at 10:28 AM, Benson Margulies <
> bimargul...@gmail.com>
> > > >
> > > > wrote:
> > > > > It seems to me that this thread is mixing two topics.
> > > > >
> > > > > Topic #1: How to we move to pom 5.0, given a giant ecosystem of
> > > > > crappy XML-parsing POM consumers?
> > > > >
> > > > > Topic #2: To what extent does the pom mix a 'description of
> contract'
> > > > > (dependencies, etc) with a 'specification of build'?
> > > > >
> > > > > On the first topic, there was a wiki page months ago that explored
> a
> > > > > scheme for writing both a v4 pom and a v5 pom when deploying from a
> > > > > v5 project, so that old tools could see and consume what they
> > >
> > > understand.
> > >
> > > > > To the extent that this scheme made sense, it can be adopted
> without
> > > > > (necessarily) touching the second.
> > > >
> > > > If you are referring to this:
> > > >
> > > >
> > > >
> https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+
> > > > the+POM+data+model
> > > >
> > > > Then I think what this document lacks are the use cases that drive
> > > > anything. Without actually having some target features you cannot
> > > > understand what you require technically.
> > > >
> > > > I think from the discussion thus far we have the following features:
> > > >
> > > > - API provides (from Stephen)
> > > > - Runtime requirements (from Manfred)
> > > > - Global excludes (much asked for feature)
> > > > - Global swaps (much asked for feature)
> > >
> > > Additionally, I think we should refine scopes... there are some that
> are
> > > likely missing and some, such as `system` that should be removed.
> > >
> > > Platform dependency *could* be handled by dependency, e.g.
> > >
> > > <dependency gav="java:java:1.8:platform"/>
> > >
> > > could indicate that you need java 8 to run.
--
Sent from my phone
