RE: How to put a dependency in the classpath BEFORE jre.jar?
Strub, thank you for your comments. Unfortunately (as I already wrote two times before) this thread started by the exact problem of overloading a JRE class (Resource annotation) by javaee6.jar... so it just don't work (otherwise I wouldn't have started this thread). Anyway, thanks for chiming in! :-) Regards Markus -Original Message- From: Mark Struberg [mailto:strub...@yahoo.de] Sent: Dienstag, 25. September 2012 21:48 To: Maven Users List Subject: Re: How to put a dependency in the classpath BEFORE jre.jar? I did not read through the whole thread, so maybe I missed (sorry for that). Afaik maven plugins use a different ClassLoader hierarchy than you might expect. Most frameworks use ParentClassLoaderFirst, but maven afaik uses ClientClassLoaderFirst. Which means it's perfectly fine to to put a javax.* dependency in your plugin classpath. The only thing which is not allowed is to overwrite native SE stuff. LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Users List users@maven.apache.org Cc: Sent: Tuesday, September 25, 2012 8:08 PM Subject: Re: How to put a dependency in the classpath BEFORE jre.jar? Markus, If you want to join in on the fun of the development community, please join us on the dev list. As you've heard on this thread, your particular concern smacks into a messy conundrum about our desire to avoid breaking other people's tools that read poms -- no matter how poorly coded. However, there is a design in progress, it needs more refinement, and mostly it will need people to actually code it. --benson - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: How to put a dependency in the classpath BEFORE jre.jar?
If there is a real interest in my participation I would be glad to join. But to tell it frankly, I enjoyed lots of forums and lists where people talked and talked and talked (I am an EG member and know how long companies can talk just to not being forced to change one code line) and did never come to a consensus. So do you actually see any chances of a solution for the described problem? See, if not, it makes no sense that I add another thread on the dev list. -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Dienstag, 25. September 2012 20:09 To: Maven Users List Subject: Re: How to put a dependency in the classpath BEFORE jre.jar? Markus, If you want to join in on the fun of the development community, please join us on the dev list. As you've heard on this thread, your particular concern smacks into a messy conundrum about our desire to avoid breaking other people's tools that read poms -- no matter how poorly coded. However, there is a design in progress, it needs more refinement, and mostly it will need people to actually code it. --benson - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to put a dependency in the classpath BEFORE jre.jar?
If there is a real interest in my participation I would be glad to join. But ... a consensus. So do you actually see any chances of a solution for the described problem? See, if not, it makes no sense that I add another thread on the dev list. I think there is genuine interest in pursuing POM5 which would help to solve this issue you're talking about (and perhaps add the notion of Platforms etc) but it is going to be a while before it becomes a reality. Right now Maven Dev is working to move from SVN to Git but once that is done, I think the POM5 conversation can be entertained more seriously. Did you ever try the configuration in that blog post you were linked to earlier in this thread? I think it would solve your problem in the short term. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: How to put a dependency in the classpath BEFORE jre.jar?
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? Yes, I mean *build*. My source code needs the @Resource(lookup = ...) field, which comes with Java EE 6, while Java SE 6 only has @Resource without the field lookup. So my code simply does not build, as long as javaee6.jar ist a simple dependency in the user classpath. I need to have it in the bootstrap classpath. This is why this thread is called How to put a dependency in the classpath BEFORE jre.jar? and the original problem that started it. It still sounds like an installation issue and Package is what an installer builder creates. If you follow the thread to the start you will see that it has nothing to do with packaging. Maven will build the modules that you need to create the package of jars that gets installed. ...and how does that solve the case described by me now for the second time...? ;-) Regards Markus - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to put a dependency in the classpath BEFORE jre.jar?
Markus, If you want to join in on the fun of the development community, please join us on the dev list. As you've heard on this thread, your particular concern smacks into a messy conundrum about our desire to avoid breaking other people's tools that read poms -- no matter how poorly coded. However, there is a design in progress, it needs more refinement, and mostly it will need people to actually code it. --benson - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to put a dependency in the classpath BEFORE jre.jar?
I did not read through the whole thread, so maybe I missed (sorry for that). Afaik maven plugins use a different ClassLoader hierarchy than you might expect. Most frameworks use ParentClassLoaderFirst, but maven afaik uses ClientClassLoaderFirst. Which means it's perfectly fine to to put a javax.* dependency in your plugin classpath. The only thing which is not allowed is to overwrite native SE stuff. LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Users List users@maven.apache.org Cc: Sent: Tuesday, September 25, 2012 8:08 PM Subject: Re: How to put a dependency in the classpath BEFORE jre.jar? Markus, If you want to join in on the fun of the development community, please join us on the dev list. As you've heard on this thread, your particular concern smacks into a messy conundrum about our desire to avoid breaking other people's tools that read poms -- no matter how poorly coded. However, there is a design in progress, it needs more refinement, and mostly it will need people to actually code it. --benson - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to put a dependency in the classpath BEFORE jre.jar?
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 scopeprovides/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 mar...@headcrashing.eu wrote:
Stephen,
if we would never
Re: How to put a dependency in the classpath BEFORE jre.jar?
Folks,
Much electronic ink was spilt on the subject of POM5. One of the pools
of ink was created by my attempt, some months ago, to move the design
along.
I wish someone would propose a concrete next step.
--benson
On Mon, Sep 24, 2012 at 4:41 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
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 scopeprovides/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,
Re: How to put a dependency in the classpath BEFORE jre.jar?
On 24 September 2012 12:58, Benson Margulies bimargul...@gmail.com wrote:
Folks,
Much electronic ink was spilt on the subject of POM5. One of the pools
of ink was created by my attempt, some months ago, to move the design
along.
I wish someone would propose a concrete next step.
Done, on dev@ list
--benson
On Mon, Sep 24, 2012 at 4:41 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
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 scopeprovides/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
Re: How to put a dependency in the classpath BEFORE jre.jar?
I am a bit concerned that this discussion seems to trying to integrate a
System Administration concern into a Software Development environment.
It seems that the original issue was raised to try to solve an
installation problem through software development.
It seems that what is needed is an installation script that lets the
System Administrator select from a list of supported servlet engines and
drop a few files into the folder that contains endorsed libraries for
the selected engine and put the war files where they belong.
IMHO, this is not a Maven problem except as it prepares the installer's
configuration files, jars, wars, etc.
It is not up to the software developer to know the configuration of the
servlet engine on a particular server. That is the System
Administrator's concern.
The installer package should be smart enough to ask the right questions
and do the right thing with the answers but it should not be assuming
the answers.
Making Maven more complex and obscure to turn it into an installation
tool is not a good idea.
There are already good tools out there. Perhaps someone might want to
build another one but I am not sure why.
Writing a plug-in to run an existing installer's creation process, would
be a good addition but it should be run as a separate Maven project
under the guideline of 1 project = 1 artifact. It would be nice if it
was an open source installer.
IMHO, software developers should not be trying to be system
administrators or try to outguess them.
Artifacts produced by Maven should not say anything about URLs,
hostnames, service endpoints, IP addresses or servlet engines.
If JNDI is not used then the installation script should ask the System
Administrator for this information and put it in the properties files or
Spring configurations or whatever.
Some of you are old enough to remember Tomcat 5 upgrade to Tomcat 6
where they moved the endorsed directory.
If we had put the location of the provided files in our poms, we would
have had a heck of a problem making the transition.
As it was, we just put the provided files in the right folder for the
version that the code was running on and could use the same war files on
a tester's workstation in 6 and in production on 5, with no problem.
My 2 cents.
Ron
On 24/09/2012 7:58 AM, Benson Margulies wrote:
Folks,
Much electronic ink was spilt on the subject of POM5. One of the pools
of ink was created by my attempt, some months ago, to move the design
along.
I wish someone would propose a concrete next step.
--benson
On Mon, Sep 24, 2012 at 4:41 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
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
RE: How to put a dependency in the classpath BEFORE jre.jar?
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. 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? 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? 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 scopeprovides/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. [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. -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
Re: How to put a dependency in the classpath BEFORE jre.jar?
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 scopeprovides/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
RE: How to put a dependency in the classpath BEFORE jre.jar?
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
RE: How to put a dependency in the classpath BEFORE jre.jar?
a few quick comments who decides what goes into endorsed ...JCP or the soldier on the front lines..the soldier should *always* have the ability to bend the tool to accomplish his specific task the concept of 'ClassLoader Reordering' is accomodated in every decent AppServer...(i know that Websphere and JBoss have ClassLoader preference reordering directives) .NET was the guiding force to enforce version specific 'assemblies' which forced the Maven community to incorporate version (and go head to head with .NET GAC attribute-set) maven-flex-plugin contains Java-based Mojos which 'wrap' mxmlc compiler to package swf from 1)mxml forms as well as 2)ActionScript JS components..and is thus part of 'Java' Binaries are another matter altogether as I have not seen a means to pull version-specific .DLL/.SO..perhaps there is a way to extract the version from header and avoid DLLHell ? file a RFE Thanks to all for this wonderfully well thought out discussion Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. From: mar...@headcrashing.eu To: users@maven.apache.org Subject: RE: How to put a dependency in the classpath BEFORE jre.jar? Date: Sat, 22 Sep 2012 11:19:44 +0200 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
RE: How to put a dependency in the classpath BEFORE jre.jar?
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 endorsedtrue/endorsed. -Original Message- From: Claves Do Amaral [mailto:claves.doama...@igmarkets.com] 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] Sent: 20 September 2012 09:22 To: users@maven.apache.org 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 For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
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 scopeendorsed/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 endorsedtrue/endorsed. -Original Message- From: Claves Do Amaral [mailto:claves.doama...@igmarkets.comjavascript:; ] 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.orgjavascript:; For additional commands, e-mail: users-h...@maven.apache.orgjavascript:; - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: users-h...@maven.apache.orgjavascript:;
Re: How to put a dependency in the classpath BEFORE jre.jar?
I *think* you should be able to do this by specifying an endorsed directory to be used. This would be standard Java procedure, nothing Maven specific. Something like the following in the config of (for example) the compiler plugin config: compilerargument-Djava.endorsed.dirs=blabla/compilerargument Should be possible to do something similar for test executions with surefire as well. /Anders On Thu, Sep 20, 2012 at 10:21 AM, Markus Karg k...@quipsy.de wrote: 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? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: How to put a dependency in the classpath BEFORE jre.jar?
So there is no pure Maven support for this? -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: Donnerstag, 20. September 2012 11:46 To: Maven Users List Subject: Re: How to put a dependency in the classpath BEFORE jre.jar? I *think* you should be able to do this by specifying an endorsed directory to be used. This would be standard Java procedure, nothing Maven specific. Something like the following in the config of (for example) the compiler plugin config: compilerargument-Djava.endorsed.dirs=blabla/compilerargument Should be possible to do something similar for test executions with surefire as well. /Anders On Thu, Sep 20, 2012 at 10:21 AM, Markus Karg k...@quipsy.de wrote: 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? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
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] Sent: 20 September 2012 09:22 To: users@maven.apache.org 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 For additional commands, e-mail: users-h...@maven.apache.org
