On 24 September 2012 12:58, Benson Margulies <[email protected]> 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 > <[email protected]> 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 <[email protected]> wrote: > > > >> Stephen, > >> > >> if we would never address problems that seem hard to fix at first sight, > >> then the Maven core would never evolve and other system would take over > >> some > >> day. So a discussion like this one is essential for the future of this > >> tool. > >> There are too much things left open due to concerns like these (e. g. > see > >> the long lasting discussion about SNAPSHOTs being included in version > >> ranges), so we should start solving them step by step instead of > flinching > >> due to virtual efforts. :-) > >> > >> So let me chime in here and start a discussion by throwing a proposal in > >> the > >> ring: Introduction of the "Platform" interface in Maven 4! > >> > >> Possibly the best way to resolve the endorsed dependency problem > mid-term > >> would be to understand how it comes to the endorsed-ness: Obviously > this is > >> because someone in an official position (like the JCP) decides that > >> something that was a "normal" dependency before now is "pre-packaged" > with > >> the official runtime package (like the JRE). In the end, that means, > that > >> Maven has to know about that decision to be able to deal with its > effects. > >> > >> Looking it this way I have to contradict in part: > >> > >> * This is _not_ a Java-only problem, as potentially there could be > endorsed > >> libraries in other runtime systems, too, like .NET or Flash, or even > Win32 > >> (for example, I can vividly remember that "GDI+" first was a custom DLL > >> that > >> everyone had to ship with his own application EXE, but later it was > part of > >> the official Windows SDK, pre-packaged with the operating system; same > with > >> newer ODBC releases BTW). While I do not say that those named examples > in > >> fact do have an endorsement facility (obvisouly besides Win32 where I > named > >> two examples), it could be possible that _some_ other Maven-supported > >> platform _will_ have such a facility now or in future. So as it is not a > >> Java-only problem, it makes sense to have a _common_ solution. > >> > >> * It is _not_ a problem of scope, since scope is to be defined solely by > >> the > >> view of the using dependent project always. If the dependent project > needs > >> this library for test only, scope still is 'test' (e. g. a Win32 program > >> might need a particular release of ODBC for an integration test, while > at > >> runtime it possibly might never use ODBC at all). The fact that a > library > >> was in user space in JRE 5 but is in system space in JRE 6 does not have > >> any > >> influence on this project's use, hence, of the scope. So there is no > need > >> for another scope. > >> > >> * Endorsed libraries are _not_ a problem of one particular dependent > >> project, but an inherent decision of the platform itself (_every_ > dependent > >> project on this particular platform (JRE 6 in this example) suffer from > the > >> _same_ pain, as _the platform_ decides that this is endorsed, but > neither > >> the dependent project nor the dependency itself). So it is nothing to > get > >> configured in neither the dependent POM nor in the dependency's POM, > but it > >> is solely a third place that makes up the endorsed-ness: The POM of the > >> "platform" (here: the POM of a hypthetical artifact that makes up what > we > >> know as "JRE 6"). Which simply does not exist in Maven 3 AFAIK. > >> > >> * As a result, it is _not_ a particular problem of the compiler, since > >> _all_ > >> compilers (jikes, javac, eclipse) need to support endorsed libraries. As > >> all > >> compilers might have different configuration switches, and selection of > the > >> particular compiler might be out of scope of the POM (i. e. defined in > >> company pom for example), it simply is no sophisticated solution to > provide > >> particular javac options inside of each single dependent POM. > >> > >> * So as AFAIK Maven 3 does not yet know the concept of "Platform" > modules, > >> the solution obviously is to add this new concept to Maven 4: Strip the > >> knowledge about the different platforms (hence, JREs) from the lots of > >> plugins (like the compiler-plugin or the jar-plugin) into one single > >> artifact which forms the "JRE 6 Platform" (including some general > >> "Platform" > >> interface common not only for the JREs but for all kinds of "Platforms" > >> like > >> .NET and Flash etc.). Using this interface, Maven could resolve the > >> question > >> "Is this dependency to be put in the root classpath, or in the user > >> classpath?" automatically. Maven simply needs to ask the platform (using > >> the > >> new interface) what the right classpath is, and the platform would > answer > >> with either 'User' or 'System' (interface-defined enum constants for > >> example). So the JRE 5 might answer with 'User' while JRE 6 might answer > >> with 'System' for the same dependency! No need for _any_ configuration > in > >> the POM! No need for _any_ POM schema change! Maven could simply set up > the > >> root classpath fully automatically that way! > >> > >> Just like one day Eclipse learned the difference between "JRE" and the > >> general term "Platform", Maven 4 has to learn this concept, too. > >> > >> Maybe I should file a RFE for this? > >> > >> Regards > >> Markus > >> > >> > -----Original Message----- > >> > From: Stephen Connolly [mailto:[email protected]] > >> > Sent: Samstag, 22. September 2012 00:09 > >> > To: Maven Users List > >> > Subject: Re: How to put a dependency in the classpath BEFORE jre.jar? > >> > > >> > 1. Maven is not just about java (though very java focused I admit) > >> > endorsed does not make sense outside of java 2. Whether a dependency > >> > needs to be endorsed or not depends on the jvm version it targets... A > >> > dep can be fine until it gets added to the jvm spec. > >> > 3. It should probably more correctly be <scope>endorsed</scope> 4. > >> > Where would you package an endorsed dependency within a .war or .ear > >> > file? > >> > > >> > And don't get me started on the fact that to change this requires > >> > changing the Pom format (which potentially could break ivy, gradle, > >> > leinengen, sbt, > >> > etc) > >> > > >> > Not an easy problem to solve, but I feel your pain > >> > > >> > On Friday, 21 September 2012, Markus KARG wrote: > >> > > >> > > Thank you for pointing me to this excellent blog entry, but in fact > I > >> > > wonder why such a great tool like Maven doesn't have built-in > support > >> > > for endorsed dependencies? I mean, in the end a different compiler > >> > > might break the solution, so it would be a good idea if a dependency > >> > > could simply marked as <endorsed>true</endorsed>. > >> > > > >> > > > -----Original Message----- > >> > > > From: Claves Do Amaral > >> > > > [mailto:[email protected]<javascript:;> > >> > > ] > >> > > > Sent: Donnerstag, 20. September 2012 10:30 > >> > > > To: Maven Users List > >> > > > Subject: RE: How to put a dependency in the classpath BEFORE > >> > jre.jar? > >> > > > > >> > > > If I understand the problem well, this is equivalent to provide > >> > > > endorsed libraries at runtime. > >> > > > I have found this resource, that looks a bit dated, but it may > >> > work. > >> > > > Not sure if Maven 3 offers a better solution > >> > > > > >> > > > http://www.mindbug.org/2009/02/adding-endorsements-to-mavens- > >> > > > plugins.html > >> > > > > >> > > > Claves > >> > > > > >> > > > -----Original Message----- > >> > > > From: Markus Karg [mailto:[email protected] <javascript:;>] > >> > > > Sent: 20 September 2012 09:22 > >> > > > To: [email protected] <javascript:;> > >> > > > Subject: How to put a dependency in the classpath BEFORE jre.jar? > >> > > > > >> > > > I have a dependency on javaee.jar, which provides newer versions > >> > for > >> > > > classes found in JRE's jre.jar (particularly the @Resource > >> > annotation). > >> > > > But javaee.jar is always appended to the classpath, while to be > >> > able > >> > > > to load the newer version, I need to PREFIX it before jre.jar > >> > > > instead. How can I configure this in the POM? > >> > > > > >> > > > > >> > > > The information contained in this email is strictly confidential > >> > and > >> > > > for the use of the addressee only, unless otherwise indicated. If > >> > > > you are not the intended recipient, please do not read, copy, use > >> > or > >> > > > disclose to others this message or any attachment. Please also > >> > > > notify the sender by replying to this email or by telephone (+44 > >> > > > (0)20 7896 > >> > > > 0011) and then delete the email and any copies of it. Opinions, > >> > > > conclusions (etc.) that do not relate to the official business of > >> > > > this company shall be understood as neither given nor endorsed by > >> > > > it. IG is a trading name of IG Markets Limited, a company > >> > registered > >> > > > in England and Wales under number 04008957. VAT registration > number > >> > 761 2978 07. > >> > > > Registered Office: Cannon Bridge House, 25 Dowgate Hill, London > >> > EC4R > >> > > > 2YA. Authorised and regulated by the Financial Services Authority. > >> > > > FSA Register number 195355. > >> > > > > >> > > > > ------------------------------------------------------------------- > >> > - > >> > > > - To unsubscribe, e-mail: > >> > > > [email protected]<javascript:;> > >> > > > For additional commands, e-mail: > >> > > > [email protected]<javascript:;> > >> > > > >> > > > >> > > > >> > > > --------------------------------------------------------------------- > >> > > To unsubscribe, e-mail: [email protected] > >> > > <javascript:;> For additional commands, e-mail: > >> > > [email protected]<javascript:;> > >> > > > >> > > > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
