On 24/09/2012 1:42 PM, Markus KARG wrote:
Stephen,
I did never suggest to modify the POM and said no word about any future form
of the POM, so I skip your comments about that and right go on with the idea
of a Platform:
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
The idea of having a Platform interface actually solves exactly that
problem, since the JDK5 platform will tell how to build on JDK5, while the
JDK6 platform will tell how to build on JDK6.
Are you sure that you mean build? What are you building that is different?
It still sounds like an installation issue and "Package" is what an
installer builder creates.
Maven will build the modules that you need to create the package of jars
that gets installed.
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....
For this, there is a Java standard already: The spec and impl information in
the MANIFEST.MF file of the JAR was invented exactly to answer this
question. No need to parse or scan anything, just applying a well-known,
very old and approved standard!
What do we do when building a .WAR that includes that dependency?
I do not see what shall be the problem with a WAR? For compiling it, you
need the dependency. Whether or not it is endorsed or not, is decided by the
Platform. What endorsed specs it implements is to be found in its
MANIFEST.MF.
Can you describe the problem that you see?
At build time you need to specify "provided" or "compile" to specify if
you want the dependency in the jar or not.
If you need both configuration of wars, then you need 2 Maven projects.
They should be both very thin with none of your code in the project.
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.
Do you honestly think it is worth getting filed if it is not the right
solution?
It would get the need onto the official list of enhancements.
I would be more thinking along the lines of a "platform" packaging
type...
...which implies a POM change...
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...
If I understand correctly, then you simply will replace the Platform
interface by a Platform packaging type, hence allowing people to easily
defined their own platform? Well, why not? Do you file a JIRA for this?
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.
I think this is not correct: For example, there might be difference in a
"thin" JAR for Java 5 to Java 6, too. For example, if it is not a complete
library that you depend upon (hence is endorsed), but if it is one or two
single classes that exist in Java 6 but did not in Java 5 so you ship them
*within* the Java 5 release of your "thin" JAR.
You would want to put that difference in the "skinny" war not in your
main code jar.
Your code jar should not care about Java 5 or Java 6 since the only
difference in your example is that the skinny war for 5 will have one or
two extra helper classes that make up for the functionality that you
need that is not included.
[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.
Never said that it will be easy. But we *need* platforms in Maven 4. Either
way.
I still think that you are trying to make a build tool do the job of an
installation tool.
Nothing in this discussion yet makes me believe that maven is the right
way to solve this.
A Maven solution is going to be difficult to configure and is likely to
make Maven even more intimidating than it is already.
Ron
-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 <mar...@headcrashing.eu> 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: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?
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
