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 <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 <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?
>> > > >
>> > > >
>> > > > 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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
