While the time of day is perfect for me, the day of week being Wed is
exactly wrong for me... I have a weekly meeting at that exact time.
Some thoughts on evolving the pom.
- We need to deploy the 4.0.0 compatible pom no matter what we do. Full
stop.
- Igor is *mostly* right in that we should not deploy the pom that is used
to build to the repository...
- Where Igor is wrong is that for <packaging>pom</packaging> we should
actually deploy the build time pom to the repository... probably with the
classifier `build`... this is safe as `pom` does cannot have a classifier
in model version 4.0.0.
- You couple that with a simple and obvious restriction... your parent must
be the same or earlier version of Maven. You cannot have as a parent a
newer version of Maven than the child is built with.
- So that leaves the 4.0.0 compatible pom only detailing <dependencies>...
there are some concepts that we need to introduce that cannot be handled in
4.0.0 model:
* "provides" concept, i.e. this artifact is equivalent to another
artifact... so that you can remove artifacts from the dependency tree *of
consumers* sensibly without needing to add excludes everywhere. So for
example org.mortbay.jetty:servlet-api:3.0.20100224 could say it
provides javax.servlet:servlet-api:3.0
and thus if I have a direct dependency on
org.mortbay.jetty:servlet-api:3.0.20100224
then Maven will know that any of my other dependencies that have a
transitive dependency on javax.servlet:servlet-api:3.0 can have that
dependency purged from the tree.
The provides concept can be transitive depending on the scope of
the dependency... probably need a new scope to reflect a dependency being
included in an überjar style. So a "provided" dependency would not add a
provides entry... but a "bundled" dependency would.
* "runtimes" concept, in some ways this can be handled by using
dependencies... in other words we can create a "pseudo" dependency at
"java.lang:specification" with versions 1.1, 1.2, 1.3, 1.4, 5.0, 6.0, 7.0,
8.0, etc and use that dependency to indicate the byte code version that you
require. Similarly a "pseudo" dependency could handle the
"java.lang:runtime" to cover the runtime library requirements... here
provides is a great help as those features that are included in different
versions of the JRE but available via standalone dependencies can be
covered with "provides" in those pseudo poms. The actual jars can be empty.
This should work for android too as the android runtime can be considered
as a snapshot of the java one for a specific version.
The downside with the dependency approach is that we loose out on
enforcement policies... OTOH perhaps we can use the pseudo dependencies as
a way of mapping the information back.
On 19 June 2014 14:50, Jesse McConnell <[email protected]> wrote:
> Thanks Jason, it was fun, we have been thinking about organizing
> something like this for Jetty for a while now, maybe get Greg to go
> through the new http/2 implementation and talk about the latest
> draft...things like that.
>
> anyway, good fun!
> jesse
> --
> jesse mcconnell
> [email protected]
>
>
> On Thu, Jun 19, 2014 at 8:46 AM, Jason van Zyl <[email protected]> wrote:
> > Sorry I use Jekyll locally, the actual link is:
> >
> > http://takari.io/2014/06/19/hangout-pom-format.html
> >
> > On Jun 19, 2014, at 9:43 AM, Paul Benedict <[email protected]> wrote:
> >
> >> Jason, I am sure accessing your localhost is blocked :-)
> >>
> >>
> >> Cheers,
> >> Paul
> >>
> >>
> >> On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl <[email protected]> wrote:
> >>
> >>> We had the hangout yesterday. I pushed the initial bit of information
> >>> about evolving the POM format here in a blog post here:
> >>>
> >>> http://localhost:4000/2014/06/19/hangout-pom-format.html
> >>>
> >>> And created a page in the Wiki to start capturing the information:
> >>>
> >>>
> https://cwiki.apache.org/confluence/display/MAVEN/Evolving+the+POM+Format
> >>>
> >>> Thanks,
> >>>
> >>> Jason
> >>>
> >>> ----------------------------------------------------------
> >>> Jason van Zyl
> >>> Founder, Apache Maven
> >>> http://twitter.com/jvanzyl
> >>> http://twitter.com/takari_io
> >>> ---------------------------------------------------------
> >>>
> >>> the course of true love never did run smooth ...
> >>>
> >>> -- Shakespeare
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder, Apache Maven
> > http://twitter.com/jvanzyl
> > http://twitter.com/takari_io
> > ---------------------------------------------------------
> >
> > the course of true love never did run smooth ...
> >
> > -- Shakespeare
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
