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:stephen.alan.conno...@gmail.com]
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:claves.doama...@igmarkets.com<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:k...@quipsy.de <javascript:;>]
Sent: 20 September 2012 09:22
To: users@maven.apache.org <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:
users-unsubscr...@maven.apache.org<javascript:;>
For additional commands, e-mail:
users-h...@maven.apache.org<javascript:;>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
<javascript:;> For additional commands, e-mail:
users-h...@maven.apache.org<javascript:;>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
