Markus,
perhaps you mis-understood my point.
this is a hard problem, that does not mean we should shirk away...
that does mean we have to solve it very close to right
the great pom migration of Maven 1 to Maven 2 left deep scars... because it
got some things wrong.
When we do the next "migration" of Maven 2/3 to Maven 4 (personally I would
prefer to call it Maven 5 so that the pom version and maven version align)
we need to get that right.
The model version 5 pom will likely be with us for quite some time...
And there are going to be very many consumers of the model version 4 pom
for some time...
So we need a reliable way to allow those consumers to continue to consumer
artifacts that were built with a model 5 pom.
A lot of the consumers are not even using Maven... we have IVY, Gradle,
Leinengen, SBT, etc.
Some of the consumers are not even JVM hosted... for example (at work) we
have chef scripts that run on RVM and parse the pom to decide what
artifacts to populate on the server they describe.
Adding a feature that requires a pom change is not something to just "hack"
in.
On top of that, there is the question of do we even want to stick with
XML... at least the XML as we have it...
A lot of people would prefer
<dependencies>
<d g="..." a="..." v="..." s="provided"/>
</dependencies>
as that saves typing.... better yet might even be
<dependencies>
<dependency coord="groupId:artifactId:version[:type[:classifier]]"
scope="provided" optional="true"/>
</dependencies>
and who says we need to stay in xml:
"dependencies":[
{"name":"groupId:artifactId:version[:type[:classifier]]",
"scope":"provided",
"optional":true
}
]
Note: strict JSON would be annoying though... might want to relax the rules
on quoting and allow comments.
These are the questions that vex us while we try to determine how to solve
the "how to get to model 5" problem... and that is even before we start
answering the "what should model 5" look like.
I like some of your idea about the concept of a platform but this is not as
trivial as you think.
There is the issue of building with JDK5 an artifact to be run on JDK5 or
JDK6
There is the issue of somebody building their own patched JAX-RS and
publishing at their own coordinates... how would the "platform" know that
"com.foobar.manchu:jersey-patched-by-bob:0.1.2" is supposed to be
endorsed... other than by scanning the jar file and looking for paths
within....
What do we do when building a .WAR that includes that dependency?
Please file a JIRA so that your platform idea does not get lost in the ML,
but I don't think in its current shape that it is the right solution.
I would be more thinking along the lines of a "platform" packaging type...
coupled with the "provides" (sort of inverse of dependencies) element or
scope...
My reasoning is this... when you need to replace an "endorsed" dependency
what you are really saying is "I *need* to run on a different platform"
The Endorsed mechanism is just a way of modifying the platform that you run
on without having to produce a custom build of that platform...
So to my mind, you create modules for the platforms that you require...
those platforms have their dependencies listed as either <provides>
elements in a model 5 pom, or as <scope>provides</scope> (in a model 5 pom
again... because unfortunately the allowed values of the scope element are
locked in model 4) so we can filter the dependencies appropriately...
It would be nice if we could find a way of building the same module for
multiple platforms at the same time... but the key here is to realize that
it is not the .jar that you build for a platform... but the "executable
.jar" or the ".war" or the ".ear", etc that you build for the platform...
so those would be "thin" modules, and duplication of modules is less of an
issue... IOW one module per platform... though nothing to stop multiple
executions of the maven war plugin with the different platforms
configured... works too because (bar skinny wars in ear) .war files are a
final end of the chain artifact.
[In fact, if we look at this from a better decomposition PoV might make
more sense to have a "webapp" packaging that holds the .war content and
make .war a final end of the line artifact... but getting sidetracked again]
With this model... you would also see platforms for each of the JavaEE
containers, as well as a generic JavaEE specification platform...
[the "webapp" packaging then becomes more needed... think of skinny .wars
being packaged into a .ear for each platform that you want to deploy the
.ear onto... on older platforms you might need the newer version of JSF, on
TomEE you may need additional dependencies because it is implementing one
profile, etc]
IOW I think the concept of a platform is a good idea... but there is a lot
more to it than meets the eye.
-Stephen
P.S.
I am quite sure others will come along and poke holes in my ideas above too!
On 22 September 2012 10:19, Markus KARG <[email protected]> wrote:
> Stephen,
>
> if we would never address problems that seem hard to fix at first sight,
> then the Maven core would never evolve and other system would take over
> some
> day. So a discussion like this one is essential for the future of this
> tool.
> There are too much things left open due to concerns like these (e. g. see
> the long lasting discussion about SNAPSHOTs being included in version
> ranges), so we should start solving them step by step instead of flinching
> due to virtual efforts. :-)
>
> So let me chime in here and start a discussion by throwing a proposal in
> the
> ring: Introduction of the "Platform" interface in Maven 4!
>
> Possibly the best way to resolve the endorsed dependency problem mid-term
> would be to understand how it comes to the endorsed-ness: Obviously this is
> because someone in an official position (like the JCP) decides that
> something that was a "normal" dependency before now is "pre-packaged" with
> the official runtime package (like the JRE). In the end, that means, that
> Maven has to know about that decision to be able to deal with its effects.
>
> Looking it this way I have to contradict in part:
>
> * This is _not_ a Java-only problem, as potentially there could be endorsed
> libraries in other runtime systems, too, like .NET or Flash, or even Win32
> (for example, I can vividly remember that "GDI+" first was a custom DLL
> that
> everyone had to ship with his own application EXE, but later it was part of
> the official Windows SDK, pre-packaged with the operating system; same with
> newer ODBC releases BTW). While I do not say that those named examples in
> fact do have an endorsement facility (obvisouly besides Win32 where I named
> two examples), it could be possible that _some_ other Maven-supported
> platform _will_ have such a facility now or in future. So as it is not a
> Java-only problem, it makes sense to have a _common_ solution.
>
> * It is _not_ a problem of scope, since scope is to be defined solely by
> the
> view of the using dependent project always. If the dependent project needs
> this library for test only, scope still is 'test' (e. g. a Win32 program
> might need a particular release of ODBC for an integration test, while at
> runtime it possibly might never use ODBC at all). The fact that a library
> was in user space in JRE 5 but is in system space in JRE 6 does not have
> any
> influence on this project's use, hence, of the scope. So there is no need
> for another scope.
>
> * Endorsed libraries are _not_ a problem of one particular dependent
> project, but an inherent decision of the platform itself (_every_ dependent
> project on this particular platform (JRE 6 in this example) suffer from the
> _same_ pain, as _the platform_ decides that this is endorsed, but neither
> the dependent project nor the dependency itself). So it is nothing to get
> configured in neither the dependent POM nor in the dependency's POM, but it
> is solely a third place that makes up the endorsed-ness: The POM of the
> "platform" (here: the POM of a hypthetical artifact that makes up what we
> know as "JRE 6"). Which simply does not exist in Maven 3 AFAIK.
>
> * As a result, it is _not_ a particular problem of the compiler, since
> _all_
> compilers (jikes, javac, eclipse) need to support endorsed libraries. As
> all
> compilers might have different configuration switches, and selection of the
> particular compiler might be out of scope of the POM (i. e. defined in
> company pom for example), it simply is no sophisticated solution to provide
> particular javac options inside of each single dependent POM.
>
> * So as AFAIK Maven 3 does not yet know the concept of "Platform" modules,
> the solution obviously is to add this new concept to Maven 4: Strip the
> knowledge about the different platforms (hence, JREs) from the lots of
> plugins (like the compiler-plugin or the jar-plugin) into one single
> artifact which forms the "JRE 6 Platform" (including some general
> "Platform"
> interface common not only for the JREs but for all kinds of "Platforms"
> like
> .NET and Flash etc.). Using this interface, Maven could resolve the
> question
> "Is this dependency to be put in the root classpath, or in the user
> classpath?" automatically. Maven simply needs to ask the platform (using
> the
> new interface) what the right classpath is, and the platform would answer
> with either 'User' or 'System' (interface-defined enum constants for
> example). So the JRE 5 might answer with 'User' while JRE 6 might answer
> with 'System' for the same dependency! No need for _any_ configuration in
> the POM! No need for _any_ POM schema change! Maven could simply set up the
> root classpath fully automatically that way!
>
> Just like one day Eclipse learned the difference between "JRE" and the
> general term "Platform", Maven 4 has to learn this concept, too.
>
> Maybe I should file a RFE for this?
>
> Regards
> Markus
>
> > -----Original Message-----
> > From: Stephen Connolly [mailto:[email protected]]
> > Sent: Samstag, 22. September 2012 00:09
> > To: Maven Users List
> > Subject: Re: How to put a dependency in the classpath BEFORE jre.jar?
> >
> > 1. Maven is not just about java (though very java focused I admit)
> > endorsed does not make sense outside of java 2. Whether a dependency
> > needs to be endorsed or not depends on the jvm version it targets... A
> > dep can be fine until it gets added to the jvm spec.
> > 3. It should probably more correctly be <scope>endorsed</scope> 4.
> > Where would you package an endorsed dependency within a .war or .ear
> > file?
> >
> > And don't get me started on the fact that to change this requires
> > changing the Pom format (which potentially could break ivy, gradle,
> > leinengen, sbt,
> > etc)
> >
> > Not an easy problem to solve, but I feel your pain
> >
> > On Friday, 21 September 2012, Markus KARG wrote:
> >
> > > Thank you for pointing me to this excellent blog entry, but in fact I
> > > wonder why such a great tool like Maven doesn't have built-in support
> > > for endorsed dependencies? I mean, in the end a different compiler
> > > might break the solution, so it would be a good idea if a dependency
> > > could simply marked as <endorsed>true</endorsed>.
> > >
> > > > -----Original Message-----
> > > > From: Claves Do Amaral
> > > > [mailto:[email protected]<javascript:;>
> > > ]
> > > > Sent: Donnerstag, 20. September 2012 10:30
> > > > To: Maven Users List
> > > > Subject: RE: How to put a dependency in the classpath BEFORE
> > jre.jar?
> > > >
> > > > If I understand the problem well, this is equivalent to provide
> > > > endorsed libraries at runtime.
> > > > I have found this resource, that looks a bit dated, but it may
> > work.
> > > > Not sure if Maven 3 offers a better solution
> > > >
> > > > http://www.mindbug.org/2009/02/adding-endorsements-to-mavens-
> > > > plugins.html
> > > >
> > > > Claves
> > > >
> > > > -----Original Message-----
> > > > From: Markus Karg [mailto:[email protected] <javascript:;>]
> > > > Sent: 20 September 2012 09:22
> > > > To: [email protected] <javascript:;>
> > > > Subject: How to put a dependency in the classpath BEFORE jre.jar?
> > > >
> > > > I have a dependency on javaee.jar, which provides newer versions
> > for
> > > > classes found in JRE's jre.jar (particularly the @Resource
> > annotation).
> > > > But javaee.jar is always appended to the classpath, while to be
> > able
> > > > to load the newer version, I need to PREFIX it before jre.jar
> > > > instead. How can I configure this in the POM?
> > > >
> > > >
> > > > The information contained in this email is strictly confidential
> > and
> > > > for the use of the addressee only, unless otherwise indicated. If
> > > > you are not the intended recipient, please do not read, copy, use
> > or
> > > > disclose to others this message or any attachment. Please also
> > > > notify the sender by replying to this email or by telephone (+44
> > > > (0)20 7896
> > > > 0011) and then delete the email and any copies of it. Opinions,
> > > > conclusions (etc.) that do not relate to the official business of
> > > > this company shall be understood as neither given nor endorsed by
> > > > it. IG is a trading name of IG Markets Limited, a company
> > registered
> > > > in England and Wales under number 04008957. VAT registration number
> > 761 2978 07.
> > > > Registered Office: Cannon Bridge House, 25 Dowgate Hill, London
> > EC4R
> > > > 2YA. Authorised and regulated by the Financial Services Authority.
> > > > FSA Register number 195355.
> > > >
> > > > -------------------------------------------------------------------
> > -
> > > > - To unsubscribe, e-mail:
> > > > [email protected]<javascript:;>
> > > > For additional commands, e-mail:
> > > > [email protected]<javascript:;>
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [email protected]
> > > <javascript:;> For additional commands, e-mail:
> > > [email protected]<javascript:;>
> > >
> > >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
