You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2013/11/23 23:44:56 UTC

Model Version 5.0.0

Before I forget, here are some of my thoughts on moving towards Model
Version 5.0.0

    The pom that we build with need not be the pom that gets deployed...
    thus the pom that is built with need not be the same format as the pom
    that gets deployed.

Only with <packaging>pom</packaging> do we actually need things like the
<plugins> section in the deployed pom, because it is a reality that for
noo-pom packaging we just want the transitive dependencies.

Now there is the <extensions> issue where you might be registering a
different file type that has different rules with respect to the
classpath... but I am unsure if we actually consider those when evaluating
the dependency tree... and in any case, once we accept that the deployed
pom is not the same as the pom used to build (for non-pom packaging at
least) we can transform that dependency tree using the exact rules that
have to be known at build time thus closing the extensions issue.

For projects with <packaging>pom</packaging> in fact we are only deploying
smal files so perhaps we can deploy two pom files... the one that exposes
the standard dependency stuff and then a second one that is used for build
inheritance.

My vision is thus that we deploy between 2 and three pom files for every
project.

For jar/war/ear/... we deploy:
* a modelVersion 4.0.0 pom as .pom (only lists dependencies)
* a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but allows
for new scopes)

For pom we deploy
* a modelVersion 4.0.0 pom as .pom (only lists dependencies)
* a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but allows
for new scopes)
* the pom itself

When building a pom, your parent pom must be of a modelVersion <= your
modelVersion.

Re: Model Version 5.0.0

Posted by Paul Benedict <pb...@apache.org>.

I like the idea of deploying multiple POM files. It is very in line with
deploying multiple hash codes.

Another solution is to deploy one POM that contains both the 4 and 5
signature. You can do this using XSD namespaces. The namespace of the root
element can be whatever POM version you want, and then have inner children
that have a different POM versions.


On Sat, Nov 23, 2013 at 6:00 PM, Robert Scholte <rf...@apache.org>wrote:

> A couple of months ago I started with a patch for Modello[1][2] which
> should make it quite easy to generate a single Reader and Writer with
> support for different versions, with respect to all the existing checks.
> This is one of the requirements which must be fixed before we can start
> implementing the changes to the model.
> However, I don't have commit rights on the Modello-project, so I could use
> some help to get these changes merged.
> I will review my work to see if everything is there and if the naming is
> correct.
>
> Robert
>
>
> [1] https://jira.codehaus.org/browse/MODELLO-4
> [2] https://github.com/rfscholte/modello/tree/modello4
>
>
> Op Sat, 23 Nov 2013 23:44:56 +0100 schreef Stephen Connolly <
> stephen.alan.connolly@gmail.com>:
>
>  Before I forget, here are some of my thoughts on moving towards Model
>> Version 5.0.0
>>
>>     The pom that we build with need not be the pom that gets deployed...
>>     thus the pom that is built with need not be the same format as the pom
>>     that gets deployed.
>>
>> Only with <packaging>pom</packaging> do we actually need things like the
>> <plugins> section in the deployed pom, because it is a reality that for
>> noo-pom packaging we just want the transitive dependencies.
>>
>> Now there is the <extensions> issue where you might be registering a
>> different file type that has different rules with respect to the
>> classpath... but I am unsure if we actually consider those when evaluating
>> the dependency tree... and in any case, once we accept that the deployed
>> pom is not the same as the pom used to build (for non-pom packaging at
>> least) we can transform that dependency tree using the exact rules that
>> have to be known at build time thus closing the extensions issue.
>>
>> For projects with <packaging>pom</packaging> in fact we are only deploying
>> smal files so perhaps we can deploy two pom files... the one that exposes
>> the standard dependency stuff and then a second one that is used for build
>> inheritance.
>>
>> My vision is thus that we deploy between 2 and three pom files for every
>> project.
>>
>> For jar/war/ear/... we deploy:
>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but allows
>> for new scopes)
>>
>> For pom we deploy
>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but allows
>> for new scopes)
>> * the pom itself
>>
>> When building a pom, your parent pom must be of a modelVersion <= your
>> modelVersion.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
Cheers,
Paul

Re: Model Version 5.0.0

Posted by Robert Scholte <rf...@apache.org>.

A couple of months ago I started with a patch for Modello[1][2] which  
should make it quite easy to generate a single Reader and Writer with  
support for different versions, with respect to all the existing checks.
This is one of the requirements which must be fixed before we can start  
implementing the changes to the model.
However, I don't have commit rights on the Modello-project, so I could use  
some help to get these changes merged.
I will review my work to see if everything is there and if the naming is  
correct.

Robert


[1] https://jira.codehaus.org/browse/MODELLO-4
[2] https://github.com/rfscholte/modello/tree/modello4


Op Sat, 23 Nov 2013 23:44:56 +0100 schreef Stephen Connolly  
<st...@gmail.com>:

> Before I forget, here are some of my thoughts on moving towards Model
> Version 5.0.0
>
>     The pom that we build with need not be the pom that gets deployed...
>     thus the pom that is built with need not be the same format as the  
> pom
>     that gets deployed.
>
> Only with <packaging>pom</packaging> do we actually need things like the
> <plugins> section in the deployed pom, because it is a reality that for
> noo-pom packaging we just want the transitive dependencies.
>
> Now there is the <extensions> issue where you might be registering a
> different file type that has different rules with respect to the
> classpath... but I am unsure if we actually consider those when  
> evaluating
> the dependency tree... and in any case, once we accept that the deployed
> pom is not the same as the pom used to build (for non-pom packaging at
> least) we can transform that dependency tree using the exact rules that
> have to be known at build time thus closing the extensions issue.
>
> For projects with <packaging>pom</packaging> in fact we are only  
> deploying
> smal files so perhaps we can deploy two pom files... the one that exposes
> the standard dependency stuff and then a second one that is used for  
> build
> inheritance.
>
> My vision is thus that we deploy between 2 and three pom files for every
> project.
>
> For jar/war/ear/... we deploy:
> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but allows
> for new scopes)
>
> For pom we deploy
> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but allows
> for new scopes)
> * the pom itself
>
> When building a pom, your parent pom must be of a modelVersion <= your
> modelVersion.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Model Version 5.0.0

Posted by Hervé BOUTEMY <he...@free.fr>.

[...]
> I think this sounds nice in theory but losing the information about how an
> artifact is produced is not a good idea.
for consumers, plugins information is really bloat

> I also don't think having a bunch
> of different tools to read one format or another is manageable.
we can have multiple tools only is the format is simple: format for consuption 
will probably be simpler than format for build

> I think
> that making readers that are more accepting of different versions and
> accommodating different elements is another approach. Keeping it all
> together forces you to think about the implications of a change.
it keeps consumers tied to the tool used by artifact producer to build: not 
ideal either

> 
> I think general extensibility of the format might be useful but in a general
> reader. Right now specific tools can work around this issue by having a
> plugin define specifics for a type. While not ideal it works but is more
> akin to a general extension mechanism that works with a single type of
> accommodating reader.
> 
> I think splitting building vs consumption will open a huge can of worms.
for sure, this is a big change
but I'm convinced this is worth to try

> Now
> I'm all for being able to aggressively change the format, but I would
> rather have a single document per version of the model. Possibly think
> about a future proof version and publish just continue to publish a model
> version 4.0.0 along side it indefinitely. I'm not sure how build vs
> consumption actually helps us evolve the model.
I didn't try to classify our wishes for evolution between consuption and build
Evolution on consuption format will always be hard, because there is a full 
ecosystem for consuption
Evolution on build will be easier, since you can simply require someone to use 
a neer version of your tool if he wants to build some project instead of 
consuming its pre-built artifacts

Regards,

Hervé

> > --
> > Regards,
> > Igor
> > 
> >>> Only with <packaging>pom</packaging> do we actually need things like the
> >>> <plugins> section in the deployed pom, because it is a reality that for
> >>> noo-pom packaging we just want the transitive dependencies.
> >>> 
> >>> Now there is the <extensions> issue where you might be registering a
> >>> different file type that has different rules with respect to the
> >>> classpath... but I am unsure if we actually consider those when
> >>> evaluating
> >>> the dependency tree... and in any case, once we accept that the deployed
> >>> pom is not the same as the pom used to build (for non-pom packaging at
> >>> least) we can transform that dependency tree using the exact rules that
> >>> have to be known at build time thus closing the extensions issue.
> >>> 
> >>> For projects with <packaging>pom</packaging> in fact we are only
> >>> deploying
> >>> smal files so perhaps we can deploy two pom files... the one that
> >>> exposes
> >>> the standard dependency stuff and then a second one that is used for
> >>> build
> >>> inheritance.
> >>> 
> >>> My vision is thus that we deploy between 2 and three pom files for every
> >>> project.
> >>> 
> >>> For jar/war/ear/... we deploy:
> >>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
> >>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but
> >>> allows
> >>> for new scopes)
> >>> 
> >>> For pom we deploy
> >>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
> >>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but
> >>> allows
> >>> for new scopes)
> >>> * the pom itself
> >>> 
> >>> When building a pom, your parent pom must be of a modelVersion <= your
> >>> modelVersion.
> >> 
> >> Thanks,
> >> 
> >> Jason
> >> 
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder,  Apache Maven
> >> http://twitter.com/jvanzyl
> >> ---------------------------------------------------------
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> 
> Thanks,
> 
> Jason
> 
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Model Version 5.0.0

Posted by Jason van Zyl <ja...@tesla.io>.

On Nov 23, 2013, at 11:47 PM, Igor Fedorenko <ig...@ifedorenko.com> wrote:

> 
> 
> On 11/23/2013, 23:08, Jason van Zyl wrote:
>> 
>> On Nov 23, 2013, at 5:44 PM, Stephen Connolly
>> <st...@gmail.com> wrote:
>> 
>>> Before I forget, here are some of my thoughts on moving towards
>>> Model Version 5.0.0
>>> 
>>> The pom that we build with need not be the pom that gets
>>> deployed... thus the pom that is built with need not be the same
>>> format as the pom that gets deployed.
>>> 
>> 
>> Can you explain why you think this is useful? To me all the
>> information that is carried with the POM after deployment is
>> primarily for the consumption of tools, and there are a lot of tools
>> that expect more than the dependency information. Removing all other
>> elements in the POM is equivalent to being massively backward
>> incompatible for an API. And if the subsequent consumption after
>> deployment is primarily by programs, then why does it matter what
>> gets deployed. I don't really see much benefit, but will create all
>> sorts of technical problems where we need multiple readers and all
>> that entails and the massive number of problems this will cause
>> people who have created tooling, especially IDE integration. >
> 
> The way I see it, what is deployed describes how the artifact needs to
> be consumed. This is artifact's "public API", if you will, it will be
> consumed by wide range of tools that resolve dependencies from Maven
> repositories and descriptor format should be very stable. Mostly likely
> we have no choice but use (a subset of) the current 4.0.0 model version.
> 
> How the artifact is produced, on the other hand, is artifact's
> implementation detail. It is perfectly reasonable for a project to
> require minimal version of Maven, for example. Or use completely
> different format, not related to pom at all.
> 
> By separating "consumption" and "production" metadata formats, we'll be
> able to evolve production format more aggressively. For example, it
> would be nice to have Tycho-specific configuration markup inside <build>
> section. This is not currently possible because all poms must be
> compatible with the same model.
> 

I think this sounds nice in theory but losing the information about how an artifact is produced is not a good idea. I also don't think having a bunch of different tools to read one format or another is manageable. I think that making readers that are more accepting of different versions and accommodating different elements is another approach. Keeping it all together forces you to think about the implications of a change.

I think general extensibility of the format might be useful but in a general reader. Right now specific tools can work around this issue by having a plugin define specifics for a type. While not ideal it works but is more akin to a general extension mechanism that works with a single type of accommodating reader.

I think splitting building vs consumption will open a huge can of worms. Now I'm all for being able to aggressively change the format, but I would rather have a single document per version of the model. Possibly think about a future proof version and publish just continue to publish a model version 4.0.0 along side it indefinitely. I'm not sure how build vs consumption actually helps us evolve the model.

> --
> Regards,
> Igor
> 
> 
> 
>>> Only with <packaging>pom</packaging> do we actually need things like the
>>> <plugins> section in the deployed pom, because it is a reality that for
>>> noo-pom packaging we just want the transitive dependencies.
>>> 
>>> Now there is the <extensions> issue where you might be registering a
>>> different file type that has different rules with respect to the
>>> classpath... but I am unsure if we actually consider those when evaluating
>>> the dependency tree... and in any case, once we accept that the deployed
>>> pom is not the same as the pom used to build (for non-pom packaging at
>>> least) we can transform that dependency tree using the exact rules that
>>> have to be known at build time thus closing the extensions issue.
>>> 
>>> For projects with <packaging>pom</packaging> in fact we are only deploying
>>> smal files so perhaps we can deploy two pom files... the one that exposes
>>> the standard dependency stuff and then a second one that is used for build
>>> inheritance.
>>> 
>>> My vision is thus that we deploy between 2 and three pom files for every
>>> project.
>>> 
>>> For jar/war/ear/... we deploy:
>>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
>>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but allows
>>> for new scopes)
>>> 
>>> For pom we deploy
>>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
>>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but allows
>>> for new scopes)
>>> * the pom itself
>>> 
>>> When building a pom, your parent pom must be of a modelVersion <= your
>>> modelVersion.
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

RE: Model Version 5.0.0

Posted by Martin Gainty <mg...@hotmail.com>.


   > Date: Sat, 23 Nov 2013 23:47:55 -0500
> From: igor@ifedorenko.com
> To: dev@maven.apache.org
> Subject: Re: Model Version 5.0.0
> 
> 
> 
> On 11/23/2013, 23:08, Jason van Zyl wrote:
> >
> > On Nov 23, 2013, at 5:44 PM, Stephen Connolly
> > <st...@gmail.com> wrote:
> >
> >> Before I forget, here are some of my thoughts on moving towards
> >> Model Version 5.0.0
> >>
> >> The pom that we build with need not be the pom that gets
> >> deployed... thus the pom that is built with need not be the same
> >> format as the pom that gets deployed.
> >>
> >
> > Can you explain why you think this is useful? To me all the
>> information that is carried with the POM after deployment is
> > primarily for the consumption of tools, and there are a lot of tools
> > that expect more than the dependency information. Removing all other
> > elements in the POM is equivalent to being massively backward
> > incompatible for an API. And if the subsequent consumption after
> > deployment is primarily by programs, then why does it matter what
> > gets deployed. I don't really see much benefit, but will create all
> > sorts of technical problems where we need multiple readers and all
> > that entails and the massive number of problems this will cause
> > people who have created tooling, especially IDE integration. >

MG>good point!..which reader is default? and which version of reader to use?

MG>the permutations of every reader for both format types produce daunting numbers

MG>Igor ..can i assume your fallback  Model would be 4.0.0?
> 
> The way I see it, what is deployed describes how the artifact needs to
> be consumed. This is artifact's "public API", if you will, it will be
> consumed by wide range of tools that resolve dependencies from Maven
> repositories and descriptor format should be very stable. Mostly likely
> we have no choice but use (a subset of) the current 4.0.0 model version.
MG>Igor..so you agree with previous paragraph?


> How the artifact is produced, on the other hand, is artifact's
> implementation detail. It is perfectly reasonable for a project to
> require minimal version of Maven, for example. Or use completely
> different format, not related to pom at all.
MG>How would new format be described?
MG>How would new format be described in archetypes?

> By separating "consumption" and "production" metadata formats, we'll be
MG>How would op "migrate" from 'consumption metadata format' to 'production metadata format'?

MG>Sans namespace identification (pointing to XSDs) as suggested by Paul
MG>How would the plugin "know" which format to implement (consumption vs production?)


> able to evolve production format more aggressively. For example, it
> would be nice to have Tycho-specific configuration markup inside <build>
> section. This is not currently possible because all poms must be
> compatible with the same model.

MG>Tycho is latest eclipse but dont forget Europa, Ganymede, Helios, Indigo and Juno..once your are done refactoring Eclipse

http://wiki.eclipse.org/Older_Versions_Of_Eclipse
MG>what about MyEclipse which is based on Helios?
http://www.myeclipseide.com/module-htmlpages-display-pid-342.html
MG>Once Eclipse (and MyEclipse) refactorings are completed what about the thousand of users who use Idea or Netbeans?
MG>Unless every IDE and every IDE variants are accomodated you could be spending 40 hours a week for months
MG>at a time to refactor plugin changes to every version of every IDE...are you volunteering to be that refactoring resource?
> --
> Regards,
> Igor

MG>Regards, Martin
> 
> 
> 
> >> Only with <packaging>pom</packaging> do we actually need things like the
> >> <plugins> section in the deployed pom, because it is a reality that for
> >> noo-pom packaging we just want the transitive dependencies.
> >>
> >> Now there is the <extensions> issue where you might be registering a
> >> different file type that has different rules with respect to the
> >> classpath... but I am unsure if we actually consider those when evaluating
> >> the dependency tree... and in any case, once we accept that the deployed
> >> pom is not the same as the pom used to build (for non-pom packaging at
> >> least) we can transform that dependency tree using the exact rules that
> >> have to be known at build time thus closing the extensions issue.
> >>
> >> For projects with <packaging>pom</packaging> in fact we are only deploying
> >> smal files so perhaps we can deploy two pom files... the one that exposes
> >> the standard dependency stuff and then a second one that is used for build
> >> inheritance.
> >>
> >> My vision is thus that we deploy between 2 and three pom files for every
> >> project.
> >>
> >> For jar/war/ear/... we deploy:
> >> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
> >> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but allows
> >> for new scopes)
> >>
> >> For pom we deploy
> >> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
> >> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but allows
> >> for new scopes)
> >> * the pom itself
> >>
> >> When building a pom, your parent pom must be of a modelVersion <= your
> >> modelVersion.
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder, Apache Maven
> > http://twitter.com/jvanzyl
> > ---------------------------------------------------------
> >
> >
> >
> >
> >
> >
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

Re: Model Version 5.0.0

Posted by Hervé BOUTEMY <he...@free.fr>.

ah ok, I better understand your intend with provides: it's not a way to find 
implementers (like expected by Igor and I), but a way to avoid collisions

I didn't think at such an approach for the moment: need to thk=ink more at it

but at a first glance, I find your idea better than what I feared previously :)

Regards,

Hervé

Le dimanche 24 novembre 2013 16:16:33 Stephen Connolly a écrit :
> On Sunday, 24 November 2013, Igor Fedorenko wrote:
> > How do you find all artifacts that provide gav="javax:servlet-api:3.0"?
> 
> You don't need to.
> 
> You just need to treat it as a global excludes on javax:servlet-api
> 
> The difference is that it also excludes any other poms that get pulled in
> transitively and also have the same provides...
> 
> You only need to look at the poms that are resolved via the current pom for
> which we are evaluating the dependency tree
> 
> > One option is to download entire repository index to the client, but
> > Central index will likely be in 100x of megabytes, which makes this
> > approach impractical. The only other option is to keep the index on the
> > server and have server-side helper to answer index queries.
> > 
> > --
> > Regards,
> > Igor
> > 
> > On 11/24/2013, 10:38, Stephen Connolly wrote:
> > 
> > On Sunday, 24 November 2013, Igor Fedorenko wrote:
> >  I think we are saying the same thing -- we evolve project model used
> > 
> > during the build but deploy both the new and backwards compatible models.
> > 
> > One quick note on representing dependencies as provided/required
> > capabilities.
> > 
> > 
> > 
> > I think it needs to be deterministic, which means it should not need an
> > active server-side assist.
> > 
> > A pom could declare
> > 
> > <provides>
> > 
> >    <provide gav="javax:servlet-api:3.0"/>
> > 
> > </provides>
> > 
> > That means if you declare *that* pom as a dependency of yours it will (by
> > being nearer in the graph) replace any servlet-api dependencies in your
> > graph.
> > 
> > You can also do similar with dependencies, eg
> > 
> > <dependency gav="org.slf4j:log4j-over-slf4j:1.7">
> > 
> >    <provides>
> >    
> >      <provide gav="log4j:log4j:1.2"/>
> >    
> >    </provides>
> > 
> > </dependency>
> > 
> > Either form is deterministic and does not introduce dynamic resolution
> > into
> > the model... But they make the things people want to do a lot easier IMHO
> > 
> > Although I like this idea in general, I believe it will
> > 
> > require completely new repository layout to be able to efficiently
> > find capability providers. Single repository-wide metadata index file,
> > the approach implemented in P2 for example, won't scale for repositories
> > of the size of Central, so most likely the new repository layout will
> > require active server-side component to assist dependency resolution.
> > 
> > --
> > Regards,
> > Igor
> > 
> > On 11/24/2013, 4:25, Stephen Connolly wrote:
> > 
> > On Sunday, 24 November 2013, Igor Fedorenko wrote:
> > 
> > 
> > 
> > On 11/23/2013, 23:08, Jason van Zyl wrote:
> > 
> > 
> > On Nov 23, 2013, at 5:44 PM, Stephen Connolly
> > 
> > <st...@gmail.com> wrote:
> >    Before I forget, here are some of my thoughts on moving towards
> > 
> > Model Version 5.0.0
> > 
> > The pom that we build with need not be the pom that gets
> > deployed... thus the pom that is built with need not be the same
> > format as the pom that gets deployed.
> > 
> >   Can you explain why you think this is useful? To me all the
> > 
> > information that is carried with the POM after deployment is
> > primarily for the consumption of tools, and there are a lot of tools
> > that expect more than the dependency information. Removing all other
> > elements in the POM is equivalent to being massively backward
> > incompatible for an API. And if the subsequent consumption after
> > deployment is primarily by programs, then why does it matter what
> > gets deployed. I don't really see much benefit, but will create all
> > sorts of technical problems where we need multiple readers and all
> > that entails and the massive number of problems this will cause
> > people who have created tooling, especially IDE integration. >
> > 
> > 
> > The way I see it, what is deployed describes how the artifact needs to
> > be consumed. This is artifact's "public API", if you will, it will be
> > consumed by wide range of tools that resolve dependencies from Maven
> > repositories and descriptor format should be very stable. Mostly likely
> > we have no choice but use (a subset of) the current 4.0.0 model version.
> > 
> > 
> > 
> > I would be very sad if we are limited to a subset.
> > 
> > There are some critical concepts that in my view are missing from pom
> > files.
> > 
> > Number one on my hit list is a <provides> concept.
> > 
> > Where you declare that an artifact *provides* the same api as another GAV.
> > 
> > Technically you'd need to be able to specify this both at the root of a
> > pom
> > and also flag specific dependencies (because the api they provide was not
> > specified when that pom was deployed)
> > 
> > Thus the Geronimo specs poms could all <provides> the corresponding JavaEE
> > specs and excludes issues or other hacks would no longer be required.
> > 
> > Look at the issues you will have if you use the excludes wildcards in your
> > pom... Namely *anyone* who uses your artifact as a dependency will need to
> > be using Maven 3 or newer... does ivy read those wildcards correctly? Does
> > sbt? Does Buildr?
> > 
> > They are a tempting siren... And from another PoV they will force others
> > to
> > follow... *but* if we are forcing them to follow should we not pick a
> > nicer
> > format to follow... Not one consisting of many layers of hacks?
> > 
> > The modelVersion 4.0.0 pom is deployed to the repo (in my scheme) so that
> > legacy clients can still make some sense... If a modelVersion 5.0.0
> > feature
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Model Version 5.0.0

Posted by Benson Margulies <bi...@gmail.com>.

I have one more remark to contribute to this.

In my view, the first step should be to make a 4.0-beta version of
Maven that has a '5.0.0' pom that is _identical_ to the 4.0.0 pom. The
difference is that we will document, after the fashion of HTML5, our
intent to change it over time. We can then adopt any ideas for a
better POM as small increments. Maybe we don't call it 4.0(no beta)
until we have incremented to the point of serious new value.


On Sun, Nov 24, 2013 at 10:48 AM, Igor Fedorenko <ig...@ifedorenko.com> wrote:
> How do you find all artifacts that provide gav="javax:servlet-api:3.0"?
> One option is to download entire repository index to the client, but
> Central index will likely be in 100x of megabytes, which makes this
> approach impractical. The only other option is to keep the index on the
> server and have server-side helper to answer index queries.
>
> --
> Regards,
> Igor
>
>
> On 11/24/2013, 10:38, Stephen Connolly wrote:
>>
>> On Sunday, 24 November 2013, Igor Fedorenko wrote:
>>
>>> I think we are saying the same thing -- we evolve project model used
>>> during the build but deploy both the new and backwards compatible models.
>>>
>>> One quick note on representing dependencies as provided/required
>>> capabilities.
>>
>>
>>
>> I think it needs to be deterministic, which means it should not need an
>> active server-side assist.
>>
>> A pom could declare
>>
>> <provides>
>>    <provide gav="javax:servlet-api:3.0"/>
>> </provides>
>>
>> That means if you declare *that* pom as a dependency of yours it will (by
>> being nearer in the graph) replace any servlet-api dependencies in your
>> graph.
>>
>> You can also do similar with dependencies, eg
>>
>> <dependency gav="org.slf4j:log4j-over-slf4j:1.7">
>>    <provides>
>>      <provide gav="log4j:log4j:1.2"/>
>>    </provides>
>> </dependency>
>>
>> Either form is deterministic and does not introduce dynamic resolution
>> into
>> the model... But they make the things people want to do a lot easier IMHO
>>
>> Although I like this idea in general, I believe it will
>>>
>>> require completely new repository layout to be able to efficiently
>>> find capability providers. Single repository-wide metadata index file,
>>> the approach implemented in P2 for example, won't scale for repositories
>>> of the size of Central, so most likely the new repository layout will
>>> require active server-side component to assist dependency resolution.
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>> On 11/24/2013, 4:25, Stephen Connolly wrote:
>>>
>>> On Sunday, 24 November 2013, Igor Fedorenko wrote:
>>>
>>>
>>>
>>> On 11/23/2013, 23:08, Jason van Zyl wrote:
>>>
>>>
>>> On Nov 23, 2013, at 5:44 PM, Stephen Connolly
>>> <st...@gmail.com> wrote:
>>>
>>>    Before I forget, here are some of my thoughts on moving towards
>>>
>>> Model Version 5.0.0
>>>
>>> The pom that we build with need not be the pom that gets
>>> deployed... thus the pom that is built with need not be the same
>>> format as the pom that gets deployed.
>>>
>>>
>>>   Can you explain why you think this is useful? To me all the
>>> information that is carried with the POM after deployment is
>>> primarily for the consumption of tools, and there are a lot of tools
>>> that expect more than the dependency information. Removing all other
>>> elements in the POM is equivalent to being massively backward
>>> incompatible for an API. And if the subsequent consumption after
>>> deployment is primarily by programs, then why does it matter what
>>> gets deployed. I don't really see much benefit, but will create all
>>> sorts of technical problems where we need multiple readers and all
>>> that entails and the massive number of problems this will cause
>>> people who have created tooling, especially IDE integration. >
>>>
>>>
>>> The way I see it, what is deployed describes how the artifact needs to
>>> be consumed. This is artifact's "public API", if you will, it will be
>>> consumed by wide range of tools that resolve dependencies from Maven
>>> repositories and descriptor format should be very stable. Mostly likely
>>> we have no choice but use (a subset of) the current 4.0.0 model version.
>>>
>>>
>>>
>>> I would be very sad if we are limited to a subset.
>>>
>>> There are some critical concepts that in my view are missing from pom
>>> files.
>>>
>>> Number one on my hit list is a <provides> concept.
>>>
>>> Where you declare that an artifact *provides* the same api as another
>>> GAV.
>>>
>>> Technically you'd need to be able to specify this both at the root of a
>>> pom
>>> and also flag specific dependencies (because the api they provide was not
>>> specified when that pom was deployed)
>>>
>>> Thus the Geronimo specs poms could all <provides> the corresponding
>>> JavaEE
>>> specs and excludes issues or other hacks would no longer be required.
>>>
>>> Look at the issues you will have if you use the excludes wildcards in
>>> your
>>> pom... Namely *anyone* who uses your artifact as a dependency will need
>>> to
>>> be using Maven 3 or newer... does ivy read those wildcards correctly?
>>> Does
>>> sbt? Does Buildr?
>>>
>>> They are a tempting siren... And from another PoV they will force others
>>> to
>>> follow... *but* if we are forcing them to follow should we not pick a
>>> nicer
>>> format to follow... Not one consisting of many layers of hacks?
>>>
>>> The modelVersion 4.0.0 pom is deployed to the repo (in my scheme) so that
>>> legacy clients can still make some sense... If a modelVersion 5.0.0
>>> feature
>>> cannot be mapped down to 4.0.0... Well we try our best and that's what
>>> you
>>> get... We should make it sure that people stuck with older clients can
>>> read
>>> something semi-sensible and then layer their hacks as normal to get the
>>> behaviour they need.
>>>
>>> Thus <provides> (which is not a scope but a GAV) can be modelled by
>>> having
>>> the modelVersion 4.0.0 pom list the collapsed dependencies with the
>>> appropriate <excludes> added (without wildcards)
>>>
>>> Other concepts cannot be mapped, so they get dropped.
>>>
>>>
>>>   How the artifact is produced, on the other hand, is artifact's
>>> implementation detail. It is perfectly reasonable for a project to
>>> require minimal version of Maven, for example. Or use completely
>>> different format, not related to pom at all.
>>>
>>>
>>>
>>> Exactly... The pom used to build can be written in JSON or whatever
>>> domain
>>> specific DSL you want... We deploy a modelVersion 5.0.0 pom as XML
>>> because
>>> it will be read my machines.
>>>
>>> Now for the reason I think deploying a pom as xml may be a good thing...
>>> XSLT
>>>
>>> Suppose we specify a XSLT GAV that will down-map the pom to a
>>> modelVersion
>>> 5.0.0 pom... Now we can actually deploy a modelVersion 7.3.5 pom to the
>>> one
>>> GAVCT and a modelVersion 5.0.0 client reads is, sees it is a modelVersion
>>> that is not understood, sees the GAV of the XSLT, pulls it down and
>>> transforms the model into the version it c
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Model Version 5.0.0

Posted by Stephen Connolly <st...@gmail.com>.

On Sunday, 24 November 2013, Igor Fedorenko wrote:

> How do you find all artifacts that provide gav="javax:servlet-api:3.0"?


You don't need to.

You just need to treat it as a global excludes on javax:servlet-api

The difference is that it also excludes any other poms that get pulled in
transitively and also have the same provides...

You only need to look at the poms that are resolved via the current pom for
which we are evaluating the dependency tree


> One option is to download entire repository index to the client, but
> Central index will likely be in 100x of megabytes, which makes this
> approach impractical. The only other option is to keep the index on the
> server and have server-side helper to answer index queries.
>
> --
> Regards,
> Igor
>
> On 11/24/2013, 10:38, Stephen Connolly wrote:
>
> On Sunday, 24 November 2013, Igor Fedorenko wrote:
>
>  I think we are saying the same thing -- we evolve project model used
> during the build but deploy both the new and backwards compatible models.
>
> One quick note on representing dependencies as provided/required
> capabilities.
>
>
>
> I think it needs to be deterministic, which means it should not need an
> active server-side assist.
>
> A pom could declare
>
> <provides>
>    <provide gav="javax:servlet-api:3.0"/>
> </provides>
>
> That means if you declare *that* pom as a dependency of yours it will (by
> being nearer in the graph) replace any servlet-api dependencies in your
> graph.
>
> You can also do similar with dependencies, eg
>
> <dependency gav="org.slf4j:log4j-over-slf4j:1.7">
>    <provides>
>      <provide gav="log4j:log4j:1.2"/>
>    </provides>
> </dependency>
>
> Either form is deterministic and does not introduce dynamic resolution into
> the model... But they make the things people want to do a lot easier IMHO
>
> Although I like this idea in general, I believe it will
>
> require completely new repository layout to be able to efficiently
> find capability providers. Single repository-wide metadata index file,
> the approach implemented in P2 for example, won't scale for repositories
> of the size of Central, so most likely the new repository layout will
> require active server-side component to assist dependency resolution.
>
> --
> Regards,
> Igor
>
> On 11/24/2013, 4:25, Stephen Connolly wrote:
>
> On Sunday, 24 November 2013, Igor Fedorenko wrote:
>
>
>
> On 11/23/2013, 23:08, Jason van Zyl wrote:
>
>
> On Nov 23, 2013, at 5:44 PM, Stephen Connolly
> <st...@gmail.com> wrote:
>
>    Before I forget, here are some of my thoughts on moving towards
>
> Model Version 5.0.0
>
> The pom that we build with need not be the pom that gets
> deployed... thus the pom that is built with need not be the same
> format as the pom that gets deployed.
>
>
>   Can you explain why you think this is useful? To me all the
> information that is carried with the POM after deployment is
> primarily for the consumption of tools, and there are a lot of tools
> that expect more than the dependency information. Removing all other
> elements in the POM is equivalent to being massively backward
> incompatible for an API. And if the subsequent consumption after
> deployment is primarily by programs, then why does it matter what
> gets deployed. I don't really see much benefit, but will create all
> sorts of technical problems where we need multiple readers and all
> that entails and the massive number of problems this will cause
> people who have created tooling, especially IDE integration. >
>
>
> The way I see it, what is deployed describes how the artifact needs to
> be consumed. This is artifact's "public API", if you will, it will be
> consumed by wide range of tools that resolve dependencies from Maven
> repositories and descriptor format should be very stable. Mostly likely
> we have no choice but use (a subset of) the current 4.0.0 model version.
>
>
>
> I would be very sad if we are limited to a subset.
>
> There are some critical concepts that in my view are missing from pom
> files.
>
> Number one on my hit list is a <provides> concept.
>
> Where you declare that an artifact *provides* the same api as another GAV.
>
> Technically you'd need to be able to specify this both at the root of a pom
> and also flag specific dependencies (because the api they provide was not
> specified when that pom was deployed)
>
> Thus the Geronimo specs poms could all <provides> the corresponding JavaEE
> specs and excludes issues or other hacks would no longer be required.
>
> Look at the issues you will have if you use the excludes wildcards in your
> pom... Namely *anyone* who uses your artifact as a dependency will need to
> be using Maven 3 or newer... does ivy read those wildcards correctly? Does
> sbt? Does Buildr?
>
> They are a tempting siren... And from another PoV they will force others to
> follow... *but* if we are forcing them to follow should we not pick a nicer
> format to follow... Not one consisting of many layers of hacks?
>
> The modelVersion 4.0.0 pom is deployed to the repo (in my scheme) so that
> legacy clients can still make some sense... If a modelVersion 5.0.0 feature
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

-- 
Sent from my phone

Re: Model Version 5.0.0

Posted by Igor Fedorenko <ig...@ifedorenko.com>.

How do you find all artifacts that provide gav="javax:servlet-api:3.0"?
One option is to download entire repository index to the client, but
Central index will likely be in 100x of megabytes, which makes this
approach impractical. The only other option is to keep the index on the
server and have server-side helper to answer index queries.

--
Regards,
Igor

On 11/24/2013, 10:38, Stephen Connolly wrote:
> On Sunday, 24 November 2013, Igor Fedorenko wrote:
>
>> I think we are saying the same thing -- we evolve project model used
>> during the build but deploy both the new and backwards compatible models.
>>
>> One quick note on representing dependencies as provided/required
>> capabilities.
>
>
> I think it needs to be deterministic, which means it should not need an
> active server-side assist.
>
> A pom could declare
>
> <provides>
>    <provide gav="javax:servlet-api:3.0"/>
> </provides>
>
> That means if you declare *that* pom as a dependency of yours it will (by
> being nearer in the graph) replace any servlet-api dependencies in your
> graph.
>
> You can also do similar with dependencies, eg
>
> <dependency gav="org.slf4j:log4j-over-slf4j:1.7">
>    <provides>
>      <provide gav="log4j:log4j:1.2"/>
>    </provides>
> </dependency>
>
> Either form is deterministic and does not introduce dynamic resolution into
> the model... But they make the things people want to do a lot easier IMHO
>
> Although I like this idea in general, I believe it will
>> require completely new repository layout to be able to efficiently
>> find capability providers. Single repository-wide metadata index file,
>> the approach implemented in P2 for example, won't scale for repositories
>> of the size of Central, so most likely the new repository layout will
>> require active server-side component to assist dependency resolution.
>>
>> --
>> Regards,
>> Igor
>>
>> On 11/24/2013, 4:25, Stephen Connolly wrote:
>>
>> On Sunday, 24 November 2013, Igor Fedorenko wrote:
>>
>>
>>
>> On 11/23/2013, 23:08, Jason van Zyl wrote:
>>
>>
>> On Nov 23, 2013, at 5:44 PM, Stephen Connolly
>> <st...@gmail.com> wrote:
>>
>>    Before I forget, here are some of my thoughts on moving towards
>>
>> Model Version 5.0.0
>>
>> The pom that we build with need not be the pom that gets
>> deployed... thus the pom that is built with need not be the same
>> format as the pom that gets deployed.
>>
>>
>>   Can you explain why you think this is useful? To me all the
>> information that is carried with the POM after deployment is
>> primarily for the consumption of tools, and there are a lot of tools
>> that expect more than the dependency information. Removing all other
>> elements in the POM is equivalent to being massively backward
>> incompatible for an API. And if the subsequent consumption after
>> deployment is primarily by programs, then why does it matter what
>> gets deployed. I don't really see much benefit, but will create all
>> sorts of technical problems where we need multiple readers and all
>> that entails and the massive number of problems this will cause
>> people who have created tooling, especially IDE integration. >
>>
>>
>> The way I see it, what is deployed describes how the artifact needs to
>> be consumed. This is artifact's "public API", if you will, it will be
>> consumed by wide range of tools that resolve dependencies from Maven
>> repositories and descriptor format should be very stable. Mostly likely
>> we have no choice but use (a subset of) the current 4.0.0 model version.
>>
>>
>>
>> I would be very sad if we are limited to a subset.
>>
>> There are some critical concepts that in my view are missing from pom
>> files.
>>
>> Number one on my hit list is a <provides> concept.
>>
>> Where you declare that an artifact *provides* the same api as another GAV.
>>
>> Technically you'd need to be able to specify this both at the root of a pom
>> and also flag specific dependencies (because the api they provide was not
>> specified when that pom was deployed)
>>
>> Thus the Geronimo specs poms could all <provides> the corresponding JavaEE
>> specs and excludes issues or other hacks would no longer be required.
>>
>> Look at the issues you will have if you use the excludes wildcards in your
>> pom... Namely *anyone* who uses your artifact as a dependency will need to
>> be using Maven 3 or newer... does ivy read those wildcards correctly? Does
>> sbt? Does Buildr?
>>
>> They are a tempting siren... And from another PoV they will force others to
>> follow... *but* if we are forcing them to follow should we not pick a nicer
>> format to follow... Not one consisting of many layers of hacks?
>>
>> The modelVersion 4.0.0 pom is deployed to the repo (in my scheme) so that
>> legacy clients can still make some sense... If a modelVersion 5.0.0 feature
>> cannot be mapped down to 4.0.0... Well we try our best and that's what you
>> get... We should make it sure that people stuck with older clients can read
>> something semi-sensible and then layer their hacks as normal to get the
>> behaviour they need.
>>
>> Thus <provides> (which is not a scope but a GAV) can be modelled by having
>> the modelVersion 4.0.0 pom list the collapsed dependencies with the
>> appropriate <excludes> added (without wildcards)
>>
>> Other concepts cannot be mapped, so they get dropped.
>>
>>
>>   How the artifact is produced, on the other hand, is artifact's
>> implementation detail. It is perfectly reasonable for a project to
>> require minimal version of Maven, for example. Or use completely
>> different format, not related to pom at all.
>>
>>
>>
>> Exactly... The pom used to build can be written in JSON or whatever domain
>> specific DSL you want... We deploy a modelVersion 5.0.0 pom as XML because
>> it will be read my machines.
>>
>> Now for the reason I think deploying a pom as xml may be a good thing...
>> XSLT
>>
>> Suppose we specify a XSLT GAV that will down-map the pom to a modelVersion
>> 5.0.0 pom... Now we can actually deploy a modelVersion 7.3.5 pom to the one
>> GAVCT and a modelVersion 5.0.0 client reads is, sees it is a modelVersion
>> that is not understood, sees the GAV of the XSLT, pulls it down and
>> transforms the model into the version it c
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Model Version 5.0.0

Posted by Stephen Connolly <st...@gmail.com>.

On Sunday, 24 November 2013, Igor Fedorenko wrote:

> I think we are saying the same thing -- we evolve project model used
> during the build but deploy both the new and backwards compatible models.
>
> One quick note on representing dependencies as provided/required
> capabilities.


I think it needs to be deterministic, which means it should not need an
active server-side assist.

A pom could declare

<provides>
  <provide gav="javax:servlet-api:3.0"/>
</provides>

That means if you declare *that* pom as a dependency of yours it will (by
being nearer in the graph) replace any servlet-api dependencies in your
graph.

You can also do similar with dependencies, eg

<dependency gav="org.slf4j:log4j-over-slf4j:1.7">
  <provides>
    <provide gav="log4j:log4j:1.2"/>
  </provides>
</dependency>

Either form is deterministic and does not introduce dynamic resolution into
the model... But they make the things people want to do a lot easier IMHO

Although I like this idea in general, I believe it will
> require completely new repository layout to be able to efficiently
> find capability providers. Single repository-wide metadata index file,
> the approach implemented in P2 for example, won't scale for repositories
> of the size of Central, so most likely the new repository layout will
> require active server-side component to assist dependency resolution.
>
> --
> Regards,
> Igor
>
> On 11/24/2013, 4:25, Stephen Connolly wrote:
>
> On Sunday, 24 November 2013, Igor Fedorenko wrote:
>
>
>
> On 11/23/2013, 23:08, Jason van Zyl wrote:
>
>
> On Nov 23, 2013, at 5:44 PM, Stephen Connolly
> <st...@gmail.com> wrote:
>
>   Before I forget, here are some of my thoughts on moving towards
>
> Model Version 5.0.0
>
> The pom that we build with need not be the pom that gets
> deployed... thus the pom that is built with need not be the same
> format as the pom that gets deployed.
>
>
>  Can you explain why you think this is useful? To me all the
> information that is carried with the POM after deployment is
> primarily for the consumption of tools, and there are a lot of tools
> that expect more than the dependency information. Removing all other
> elements in the POM is equivalent to being massively backward
> incompatible for an API. And if the subsequent consumption after
> deployment is primarily by programs, then why does it matter what
> gets deployed. I don't really see much benefit, but will create all
> sorts of technical problems where we need multiple readers and all
> that entails and the massive number of problems this will cause
> people who have created tooling, especially IDE integration. >
>
>
> The way I see it, what is deployed describes how the artifact needs to
> be consumed. This is artifact's "public API", if you will, it will be
> consumed by wide range of tools that resolve dependencies from Maven
> repositories and descriptor format should be very stable. Mostly likely
> we have no choice but use (a subset of) the current 4.0.0 model version.
>
>
>
> I would be very sad if we are limited to a subset.
>
> There are some critical concepts that in my view are missing from pom
> files.
>
> Number one on my hit list is a <provides> concept.
>
> Where you declare that an artifact *provides* the same api as another GAV.
>
> Technically you'd need to be able to specify this both at the root of a pom
> and also flag specific dependencies (because the api they provide was not
> specified when that pom was deployed)
>
> Thus the Geronimo specs poms could all <provides> the corresponding JavaEE
> specs and excludes issues or other hacks would no longer be required.
>
> Look at the issues you will have if you use the excludes wildcards in your
> pom... Namely *anyone* who uses your artifact as a dependency will need to
> be using Maven 3 or newer... does ivy read those wildcards correctly? Does
> sbt? Does Buildr?
>
> They are a tempting siren... And from another PoV they will force others to
> follow... *but* if we are forcing them to follow should we not pick a nicer
> format to follow... Not one consisting of many layers of hacks?
>
> The modelVersion 4.0.0 pom is deployed to the repo (in my scheme) so that
> legacy clients can still make some sense... If a modelVersion 5.0.0 feature
> cannot be mapped down to 4.0.0... Well we try our best and that's what you
> get... We should make it sure that people stuck with older clients can read
> something semi-sensible and then layer their hacks as normal to get the
> behaviour they need.
>
> Thus <provides> (which is not a scope but a GAV) can be modelled by having
> the modelVersion 4.0.0 pom list the collapsed dependencies with the
> appropriate <excludes> added (without wildcards)
>
> Other concepts cannot be mapped, so they get dropped.
>
>
>  How the artifact is produced, on the other hand, is artifact's
> implementation detail. It is perfectly reasonable for a project to
> require minimal version of Maven, for example. Or use completely
> different format, not related to pom at all.
>
>
>
> Exactly... The pom used to build can be written in JSON or whatever domain
> specific DSL you want... We deploy a modelVersion 5.0.0 pom as XML because
> it will be read my machines.
>
> Now for the reason I think deploying a pom as xml may be a good thing...
> XSLT
>
> Suppose we specify a XSLT GAV that will down-map the pom to a modelVersion
> 5.0.0 pom... Now we can actually deploy a modelVersion 7.3.5 pom to the one
> GAVCT and a modelVersion 5.0.0 client reads is, sees it is a modelVersion
> that is not understood, sees the GAV of the XSLT, pulls it down and
> transforms the model into the version it c
>
>

-- 
Sent from my phone

Re: Model Version 5.0.0

Posted by Stephen Connolly <st...@gmail.com>.

Tool chains don't help at runtime... But for system scope you likely need a
level above to inject the deps into the ext folder (or use a system
property for the JVM startup options)... But point us these are deps
required but required outside of the scope that is reasonably managed by
maven. They fit mire as platform "extensions" to my mind


On Sunday, 24 November 2013, Hervé BOUTEMY wrote:

> don't we have toolchains for such a case?
>
> Regards,
>
> Hervé
>
> Le dimanche 24 novembre 2013 20:13:38 Stephen Connolly a écrit :
> > On 24 November 2013 19:42, Robert Patrick <ro...@oracle.com>
> wrote:
> > > > Additionally, I think we should refine scopes... there are some that
> are
> > >
> > > likely missing and some, such as `system` that should be removed.
> > >
> > > Pardon my ignorance but while I understand the negative implications of
> > > using system-scoped dependencies, I believe there are cases at least a
> few
> > > use cases where they are required.  For example, we have a plugin that
> > > depends on tools.jar from the JDK.  We currently use a system-scoped
> > > dependency for this.  If you were to remove system-scoped dependencies,
> > > how
> > > would you propose that people handle use cases such as this?
> >
> > I think that we need a less Java centric concept for this... or at least
> to
> > rework it...
> >
> > Perhaps it is part of the platform specification, since the ext directory
> > is really a function of the platform in some senses. The current design
> is
> > really supposed to only work with ${java.home} paths... and didn't even
> > work with those for OSX at least until Oracle took over JDK on OSX... too
> > much abuse of this as a hack leads me to think that its current
> incarnation
> > is just bad design... and I would rather strip out bad design if we have
> > the chance... of course I am but one voice... if others make compelling
> > arguments against then we can let the project committers vote and decide
> in
> > the absence of consensus... but until we get to that point I think we
> need
> > a healthy debate... this is a subject we have ignored to our peril for
> far
> > far too long
> >
> > > -----Original Message-----
> > > From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> > > Sent: Sunday, November 24, 2013 1:34 PM
> > > To: Maven Developers List
> > > Subject: Re: Model Version 5.0.0
> > >
> > > On 24 November 2013 17:44, Jason van Zyl <ja...@tesla.io> wrote:
> > > > On Nov 24, 2013, at 10:28 AM, Benson Margulies <
> bimargulies@gmail.com>
> > > >
> > > > wrote:
> > > > > It seems to me that this thread is mixing two topics.
> > > > >
> > > > > Topic #1: How to we move to pom 5.0, given a giant ecosystem of
> > > > > crappy XML-parsing POM consumers?
> > > > >
> > > > > Topic #2: To what extent does the pom mix a 'description of
> contract'
> > > > > (dependencies, etc) with a 'specification of build'?
> > > > >
> > > > > On the first topic, there was a wiki page months ago that explored
> a
> > > > > scheme for writing both a v4 pom and a v5 pom when deploying from a
> > > > > v5 project, so that old tools could see and consume what they
> > >
> > > understand.
> > >
> > > > > To the extent that this scheme made sense, it can be adopted
> without
> > > > > (necessarily) touching the second.
> > > >
> > > > If you are referring to this:
> > > >
> > > >
> > > >
> https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+
> > > > the+POM+data+model
> > > >
> > > > Then I think what this document lacks are the use cases that drive
> > > > anything. Without actually having some target features you cannot
> > > > understand what you require technically.
> > > >
> > > > I think from the discussion thus far we have the following features:
> > > >
> > > > - API provides (from Stephen)
> > > > - Runtime requirements (from Manfred)
> > > > - Global excludes (much asked for feature)
> > > > - Global swaps (much asked for feature)
> > >
> > > Additionally, I think we should refine scopes... there are some that
> are
> > > likely missing and some, such as `system` that should be removed.
> > >
> > > Platform dependency *could* be handled by dependency, e.g.
> > >
> > > <dependency gav="java:java:1.8:platform"/>
> > >
> > > could indicate that you need java 8 to run.



-- 
Sent from my phone

Re: Model Version 5.0.0

Posted by Hervé BOUTEMY <he...@free.fr>.

don't we have toolchains for such a case?

Regards,

Hervé

Le dimanche 24 novembre 2013 20:13:38 Stephen Connolly a écrit :
> On 24 November 2013 19:42, Robert Patrick <ro...@oracle.com> wrote:
> > > Additionally, I think we should refine scopes... there are some that are
> > 
> > likely missing and some, such as `system` that should be removed.
> > 
> > Pardon my ignorance but while I understand the negative implications of
> > using system-scoped dependencies, I believe there are cases at least a few
> > use cases where they are required.  For example, we have a plugin that
> > depends on tools.jar from the JDK.  We currently use a system-scoped
> > dependency for this.  If you were to remove system-scoped dependencies,
> > how
> > would you propose that people handle use cases such as this?
> 
> I think that we need a less Java centric concept for this... or at least to
> rework it...
> 
> Perhaps it is part of the platform specification, since the ext directory
> is really a function of the platform in some senses. The current design is
> really supposed to only work with ${java.home} paths... and didn't even
> work with those for OSX at least until Oracle took over JDK on OSX... too
> much abuse of this as a hack leads me to think that its current incarnation
> is just bad design... and I would rather strip out bad design if we have
> the chance... of course I am but one voice... if others make compelling
> arguments against then we can let the project committers vote and decide in
> the absence of consensus... but until we get to that point I think we need
> a healthy debate... this is a subject we have ignored to our peril for far
> far too long
> 
> > -----Original Message-----
> > From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> > Sent: Sunday, November 24, 2013 1:34 PM
> > To: Maven Developers List
> > Subject: Re: Model Version 5.0.0
> > 
> > On 24 November 2013 17:44, Jason van Zyl <ja...@tesla.io> wrote:
> > > On Nov 24, 2013, at 10:28 AM, Benson Margulies <bi...@gmail.com>
> > > 
> > > wrote:
> > > > It seems to me that this thread is mixing two topics.
> > > > 
> > > > Topic #1: How to we move to pom 5.0, given a giant ecosystem of
> > > > crappy XML-parsing POM consumers?
> > > > 
> > > > Topic #2: To what extent does the pom mix a 'description of contract'
> > > > (dependencies, etc) with a 'specification of build'?
> > > > 
> > > > On the first topic, there was a wiki page months ago that explored a
> > > > scheme for writing both a v4 pom and a v5 pom when deploying from a
> > > > v5 project, so that old tools could see and consume what they
> > 
> > understand.
> > 
> > > > To the extent that this scheme made sense, it can be adopted without
> > > > (necessarily) touching the second.
> > > 
> > > If you are referring to this:
> > > 
> > > 
> > > https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+
> > > the+POM+data+model
> > > 
> > > Then I think what this document lacks are the use cases that drive
> > > anything. Without actually having some target features you cannot
> > > understand what you require technically.
> > > 
> > > I think from the discussion thus far we have the following features:
> > > 
> > > - API provides (from Stephen)
> > > - Runtime requirements (from Manfred)
> > > - Global excludes (much asked for feature)
> > > - Global swaps (much asked for feature)
> > 
> > Additionally, I think we should refine scopes... there are some that are
> > likely missing and some, such as `system` that should be removed.
> > 
> > Platform dependency *could* be handled by dependency, e.g.
> > 
> > <dependency gav="java:java:1.8:platform"/>
> > 
> > could indicate that you need java 8 to run...
> > 
> > The question though is how you handle multiple potential platforms, e.g.
> > works on java 1.6 or android...
> > 
> > That may require a change to the dependency model... some sort of
> > dependency group... whereby any one of the deps in the group can satisfy
> > the need...
> > 
> > A potentially better solution would be a specific platform section... but
> > is the more generic <dep> based solution perhaps better?
> > 
> > > Additionally by requirements:
> > > - Are we going to allow for extensibility?
> > > - Are we going to be future proof?
> > > - Are we going to provide backward compatibility?
> > > 
> > > I believe this is where we start. Many of the answers about how the
> > > implementation will look will be driven by specific features and
> > > answers to requirements questions.
> > 
> > Another point is that if we don't ack that we need to rev the spec and
> > this may be the only chance to rev the spec for a while, we won't see the
> > features we need.
> > 
> > Hacking the 4.0.0 pom will only make baby steps and lead to hacky
> > solutions... opening up the chance to rev the pom spec and schema opens up
> > the potential for other ideas
> > 
> > > > On the second topic, I'm in agreement that there should be a clear
> > > > separation between describing a contract and other things. For
> > > > example, why is it a good idea for deployed poms to reference
> > > > parents, rather than being self-contained? Why is it a good idea for
> > > > deployed poms to include profiles? Why is it a good thing for
> > > > deployed poms to include parameter references, thereby in some cases
> > > > accidently changing their semantics due to collisions with the
> > > > consuming application's pom? The full 'here's how to build' pom, in
> > > > my view, is part of the source, and should be deployed with the
> > > > source, and any tool that can usefully analyze the details (plugins,
> > > > pluginManagement,
> > > > etc) is welcome to do so. Having written this, it also seems to me
> > > > that one compromise could be that v5 deployed poms could be
> > > > self-contained, complete, but organized so as be clear as to the two
> > > > categories of contents.
> > > > 
> > > > 
> > > > 
> > > > On Sun, Nov 24, 2013 at 9:29 AM, Igor Fedorenko
> > > > <ig...@ifedorenko.com>
> > > 
> > > wrote:
> > > >> I think we are saying the same thing -- we evolve project model
> > > >> used during the build but deploy both the new and backwards
> > > >> compatible
> > > 
> > > models.
> > > 
> > > >> One quick note on representing dependencies as provided/required
> > > >> capabilities. Although I like this idea in general, I believe it
> > > >> will require completely new repository layout to be able to
> > > >> efficiently find capability providers. Single repository-wide
> > > >> metadata index file, the approach implemented in P2 for example,
> > > >> won't scale for repositories of the size of Central, so most likely
> > > >> the new repository layout will require active server-side component
> > 
> > to assist dependency resolution.
> > 
> > > >> --
> > > >> Regards,
> > > >> Igor
> > > >> 
> > > >> On 11/24/2013, 4:25, Stephen Connolly wrote:
> > > >>> On Sunday, 24 November 2013, Igor Fedorenko wrote:
> > > >>>> On 11/23/2013, 23:08, Jason van Zyl wrote:
> > > >>>>> On Nov 23, 2013, at 5:44 PM, Stephen Connolly
> > > >>>>> 
> > > >>>>> <st...@gmail.com> wrote:
> > > >>>>>  Before I forget, here are some of my thoughts on moving towards
> > > >>>>>  
> > > >>>>>> Model Version 5.0.0
> > > >>>>>> 
> > > >>>>>> The pom that we build with need not be the pom that gets
> > > >>>>>> deployed... thus the pom that is built with need not be the
> > > >>>>>> same format as the pom that gets deployed.
> > > >>>>> 
> > > >>>>> Can you explain why you think this is useful? To me all the
> > > >>>>> information that is carried with the POM after deployment is
> > > >>>>> primarily for the consumption of tools, and there are a lot of
> > > >>>>> tools that expect more than the dependency information. Removing
> > > >>>>> all other elements in the POM is equivalent to being massively
> > > >>>>> backward incompatible for an API. And if the subsequent
> > > >>>>> consumption after deployment is primarily by programs, then why
> > > >>>>> does it matter what gets deployed. I don't really see much
> > > >>>>> benefit, but will create all sorts of technical problems where
> > > >>>>> we need multiple readers and all that entails and the massive
> > > >>>>> number of problems this will cause people who have created
> > > >>>>> tooling, especially IDE integration. >
> > > >>>> 
> > > >>>> The way I see it, what is deployed describes how the artifact
> > > >>>> needs to be consumed. This is artifact's "public API", if you
> > > >>>> will, it will be consumed by wide range of tools that resolve
> > > >>>> dependencies from Maven repositories and descriptor format should
> > > >>>> be very stable. Mostly
> > > 
> > > likely
> > > 
> > > >>>> we have no choice but use (a subset of) the current 4.0.0 model
> > > 
> > > version.
> > > 
> > > >>> I would be very sad if we are limited to a subset.
> > > >>> 
> > > >>> There are some critical concepts that in my view are missing from
> > > >>> pom files.
> > > >>> 
> > > >>> Number one on my hit list is a <provides> concept.
> > > >>> 
> > > >>> Where you declare that an artifact *provides* the same api as
> > > >>> another
> > > 
> > > GAV.
> > > 
> > > >>> Technically you'd need to be able to specify this both at the root
> > > >>> of a pom and also flag specific dependencies (because the api they
> > > >>> provide was
> > > 
> > > not
> > > 
> > > >>> specified when that pom was deployed)
> > > >>> 
> > > >>> Thus the Geronimo specs poms could all <provides> the
> > > >>> corresponding
> > > 
> > > JavaEE
> > > 
> > > >>> specs and excludes issues or other hacks would no longer be
> > > >>> required.
> > > >>> 
> > > >>> Look at the issues you will have if you use the excludes wildcards
> > > >>> in
> > > 
> > > your
> > > 
> > > >>> pom... Namely *anyone* who uses your artifact as a dependency will
> > > 
> > > need to
> > > 
> > > >>> be using Maven 3 or newer... does ivy read those wildcards
> > > >>> correctly?
> > > 
> > > Does
> > > 
> > > >>> sbt? Does Buildr?
> > > >>> 
> > > >>> They are a tempting siren... And from another PoV they will force
> > > 
> > > others
> > > 
> > > >>> to
> > > >>> follow... *but* if we are forcing them to follow should we not
> > > >>> pick a nicer format to follow... Not one consisting of many layers
> > > >>> of hacks?
> > > >>> 
> > > >>> The modelVersion 4.0.0 pom is deployed to the repo (in my scheme)
> > > >>> so
> > > 
> > > that
> > > 
> > > >>> legacy clients can still make some sense... If a modelVersion
> > > >>> 5.0.0 feature cannot be mapped down to 4.0.0... Well we try our
> > > >>> best and that's what
> > > 
> > > you
> > > 
> > > >>> get... We should make it sure that people stuck with older clients
> > > >>> can read something semi-sensible and then layer their hacks as
> > > >>> normal to get the behaviour they need.
> > > >>> 
> > > >>> Thus <provides> (which is not a scope but a GAV) can be modelled
> > > >>> by
> > > 
> > > having
> > > 
> > > >>> the modelVersion 4.0.0 pom list the collapsed dependencies with
> > > >>> the appropriate <excludes> added (without wildcards)
> > > >>> 
> > > >>> Other concepts cannot be mapped, so they get dropped.
> > > >>> 
> > > >>>> How the artifact is produced, on the other hand, is artifact's
> > > >>>> implementation detail. It is perfectly reasonable for a project
> > > >>>> to require minimal version of Maven, for example. Or use
> > > >>>> completely different format, not related to pom at all.
> > > >>> 
> > > >>> Exactly... The pom used to build can be written in JSON or
> > > >>> whatever
> > > 
> > > domain
> > > 
> > > >>> specific DSL you want... We deploy a modelVersion 5.0.0 pom as XML
> > > 
> > > because
> > > 
> > > >>> it will be read my machines.
> > > >>> 
> > > >>> Now for the reason I think deploying a pom as xml may be a good
> > > 
> > > thing...
> > > 
> > > >>> XSLT
> > > >>> 
> > > >>> Suppose we specify a XSLT GAV that will down-map the pom to a
> > > 
> > > modelVersion
> > > 
> > > >>> 5.0.0 pom... Now we can actually deploy a modelVersion 7.3.5 pom
> > > >>> to the one GAVCT and a modelVersion 5.0.0 client reads is, sees it
> > > >>> is a
> > > 
> > > modelVersion
> > > 
> > > >>> that is not understood, sees the GAV of the XSLT, pulls it down
> > > >>> and transforms the model into the version it can parse
> > > >>> 
> > > >>> Will it be able to parse all the info in the original pom? Nope...
> > > 
> > > It's an
> > > 
> > > >>> older client... Older clients should not expect to grok all the
> > > 
> > > subtleties
> > > 
> > > >>> of newer poms... But it should get the general shape
> > > >>> 
> > > >>> In all of the above, <packaging>pom</packaging> is special... We
> > > >>> just deploy that as is in whatever format
> > > >>> (JSON/DSL/XML/groovy/etc) as the -build.pom
> > > >>> 
> > > >>> So 4.0.0 => .pom
> > > >>> 5.0.0 onward (XSLT down versioning) => -dep.pom And as a parent =<
> > > >>> -build.pom
> > > >>> 
> > > >>> Modern clients can ask for the -dep.pom first... And fall back to
> > > >>> the
> > > 
> > > .pom
> > > 
> > > >>> It's not perfect, but it should not be the hell of 3.0.0->4.0.0
> > > >>> the
> > > 
> > > fear
> > > 
> > > >>> of
> > > >>> which has prevented forward progress since
> > > >>> 
> > > >>>> By separating "consumption" and "production" metadata formats,
> > > >>>> we'll
> > > 
> > > be
> > > 
> > > >>>> able to evolve production format more aggressively. For example,
> > > >>>> it would be nice to have Tycho-specific configuration markup
> > > >>>> inside
> > > 
> > > <build>
> > > 
> > > >>>> section. This is not currently possible because all poms must be
> > > >>>> compatible with the same model.
> > > >>>> 
> > > >>>> --
> > > >>>> Regards,
> > > >>>> Igor
> > > >>>> 
> > > >>>>  Only with <packaging>pom</packaging> do we actually need things
> > > >>>> 
> > > >>>> like the
> > > >>>> 
> > > >>>>>> <plugins> section in the deployed pom, because it is a reality
> > > >>>>>> that
> > > 
> > > for
> > > 
> > > >>>>>> noo-pom packaging we just want the transitive dependencies.
> > > >>>>>> 
> > > >>>>>> Now there is the <extensions> issue where you might be
> > > >>>>>> registering a different file type that has different rules with
> > > >>>>>> respect to the classpath... but I am unsure if we actually
> > > >>>>>> consider those when evaluating the dependency tree... and in
> > > >>>>>> any case, once we accept that the deployed pom is not the same
> > > >>>>>> as the pom used to build (for non-pom packaging
> > > 
> > > at
> > > 
> > > >>>>>> least) we can transform that dependency tree using the exact
> > > >>>>>> rules
> > > 
> > > that
> > > 
> > > >>>>>> have to be known at build time thus closing the extensions issue.
> > > >>>>>> 
> > > >>>>>> For projects with <packaging>pom</packaging> in fact we are
> > > >>>>>> only deploying smal files so perhaps we can deploy two pom
> > > >>>>>> files... the one that exposes the standard dependency stuff and
> > > >>>>>> then a second one that is used for build inheritance.
> > > >>>>>> 
> > > >>>>>> My vision is thus that we deploy between 2 and three pom files
> > > >>>>>> for every project.
> > > >>>>>> 
> > > >>>>>> For jar/war/ear/... we deploy:
> > > >>>>>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
> > > >>>>>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies
> > > >>>>>> but allows for new scopes)
> > > >>>>>> 
> > > >>>>>> For pom we deploy
> > > >>>>>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
> > > >>>>>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies
> > > >>>>>> but allows for new scopes)
> > > >>>>>> * the pom itself
> > > >>>>>> 
> > > >>>>>> When building a pom, your parent pom must be of a modelVersion
> > > >>>>>> <=
> > > 
> > > your
> > > 
> > > >>>>>> modelVersion.
> > > >>>>> 
> > > >>>>> Thanks,
> > > >>>>> 
> > > >>>>> Jason
> > > >>>>> 
> > > >>>>> ----------------------------------------------------------
> > > >>>>> Jason van Zyl
> > > >>>>> Founder,  Apache Maven
> > > >>>>> http://twitter.com/jvanzyl
> > > >>>>> ---------------------------------------------------------
> > > >>>> 
> > > >>>> -----------------------------------------------------------------
> > > >>>> ---- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> > > >>>> additional commands, e-mail: dev-help@maven.apache.org
> > > >> 
> > > >> -------------------------------------------------------------------
> > > >> -- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> > > >> additional commands, e-mail: dev-help@maven.apache.org
> > > > 
> > > > --------------------------------------------------------------------
> > > > - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> > > > additional commands, e-mail: dev-help@maven.apache.org
> > > 
> > > Thanks,
> > > 
> > > Jason
> > > 
> > > ----------------------------------------------------------
> > > Jason van Zyl
> > > Founder,  Apache Maven
> > > http://twitter.com/jvanzyl
> > > ---------------------------------------------------------
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Model Version 5.0.0

Posted by Stephen Connolly <st...@gmail.com>.

On 24 November 2013 19:42, Robert Patrick <ro...@oracle.com> wrote:

> > Additionally, I think we should refine scopes... there are some that are
> likely missing and some, such as `system` that should be removed.
>
> Pardon my ignorance but while I understand the negative implications of
> using system-scoped dependencies, I believe there are cases at least a few
> use cases where they are required.  For example, we have a plugin that
> depends on tools.jar from the JDK.  We currently use a system-scoped
> dependency for this.  If you were to remove system-scoped dependencies, how
> would you propose that people handle use cases such as this?
>
>
I think that we need a less Java centric concept for this... or at least to
rework it...

Perhaps it is part of the platform specification, since the ext directory
is really a function of the platform in some senses. The current design is
really supposed to only work with ${java.home} paths... and didn't even
work with those for OSX at least until Oracle took over JDK on OSX... too
much abuse of this as a hack leads me to think that its current incarnation
is just bad design... and I would rather strip out bad design if we have
the chance... of course I am but one voice... if others make compelling
arguments against then we can let the project committers vote and decide in
the absence of consensus... but until we get to that point I think we need
a healthy debate... this is a subject we have ignored to our peril for far
far too long


>
> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> Sent: Sunday, November 24, 2013 1:34 PM
> To: Maven Developers List
> Subject: Re: Model Version 5.0.0
>
> On 24 November 2013 17:44, Jason van Zyl <ja...@tesla.io> wrote:
>
> >
> > On Nov 24, 2013, at 10:28 AM, Benson Margulies <bi...@gmail.com>
> > wrote:
> >
> > > It seems to me that this thread is mixing two topics.
> > >
> > > Topic #1: How to we move to pom 5.0, given a giant ecosystem of
> > > crappy XML-parsing POM consumers?
> > >
> > > Topic #2: To what extent does the pom mix a 'description of contract'
> > > (dependencies, etc) with a 'specification of build'?
> > >
> > > On the first topic, there was a wiki page months ago that explored a
> > > scheme for writing both a v4 pom and a v5 pom when deploying from a
> > > v5 project, so that old tools could see and consume what they
> understand.
> > > To the extent that this scheme made sense, it can be adopted without
> > > (necessarily) touching the second.
> > >
> >
> > If you are referring to this:
> >
> >
> > https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+
> > the+POM+data+model
> >
> > Then I think what this document lacks are the use cases that drive
> > anything. Without actually having some target features you cannot
> > understand what you require technically.
> >
> > I think from the discussion thus far we have the following features:
> >
> > - API provides (from Stephen)
> > - Runtime requirements (from Manfred)
> > - Global excludes (much asked for feature)
> > - Global swaps (much asked for feature)
> >
>
> Additionally, I think we should refine scopes... there are some that are
> likely missing and some, such as `system` that should be removed.
>
> Platform dependency *could* be handled by dependency, e.g.
>
> <dependency gav="java:java:1.8:platform"/>
>
> could indicate that you need java 8 to run...
>
> The question though is how you handle multiple potential platforms, e.g.
> works on java 1.6 or android...
>
> That may require a change to the dependency model... some sort of
> dependency group... whereby any one of the deps in the group can satisfy
> the need...
>
> A potentially better solution would be a specific platform section... but
> is the more generic <dep> based solution perhaps better?
>
>
>
> > Additionally by requirements:
> > - Are we going to allow for extensibility?
> > - Are we going to be future proof?
> > - Are we going to provide backward compatibility?
> >
> > I believe this is where we start. Many of the answers about how the
> > implementation will look will be driven by specific features and
> > answers to requirements questions.
> >
>
> Another point is that if we don't ack that we need to rev the spec and
> this may be the only chance to rev the spec for a while, we won't see the
> features we need.
>
> Hacking the 4.0.0 pom will only make baby steps and lead to hacky
> solutions... opening up the chance to rev the pom spec and schema opens up
> the potential for other ideas
>
>
> >
> > > On the second topic, I'm in agreement that there should be a clear
> > > separation between describing a contract and other things. For
> > > example, why is it a good idea for deployed poms to reference
> > > parents, rather than being self-contained? Why is it a good idea for
> > > deployed poms to include profiles? Why is it a good thing for
> > > deployed poms to include parameter references, thereby in some cases
> > > accidently changing their semantics due to collisions with the
> > > consuming application's pom? The full 'here's how to build' pom, in
> > > my view, is part of the source, and should be deployed with the
> > > source, and any tool that can usefully analyze the details (plugins,
> > > pluginManagement,
> > > etc) is welcome to do so. Having written this, it also seems to me
> > > that one compromise could be that v5 deployed poms could be
> > > self-contained, complete, but organized so as be clear as to the two
> > > categories of contents.
> > >
> > >
> > >
> > > On Sun, Nov 24, 2013 at 9:29 AM, Igor Fedorenko
> > > <ig...@ifedorenko.com>
> > wrote:
> > >> I think we are saying the same thing -- we evolve project model
> > >> used during the build but deploy both the new and backwards
> > >> compatible
> > models.
> > >>
> > >> One quick note on representing dependencies as provided/required
> > >> capabilities. Although I like this idea in general, I believe it
> > >> will require completely new repository layout to be able to
> > >> efficiently find capability providers. Single repository-wide
> > >> metadata index file, the approach implemented in P2 for example,
> > >> won't scale for repositories of the size of Central, so most likely
> > >> the new repository layout will require active server-side component
> to assist dependency resolution.
> > >>
> > >> --
> > >> Regards,
> > >> Igor
> > >>
> > >>
> > >> On 11/24/2013, 4:25, Stephen Connolly wrote:
> > >>>
> > >>> On Sunday, 24 November 2013, Igor Fedorenko wrote:
> > >>>
> > >>>>
> > >>>>
> > >>>> On 11/23/2013, 23:08, Jason van Zyl wrote:
> > >>>>
> > >>>>>
> > >>>>> On Nov 23, 2013, at 5:44 PM, Stephen Connolly
> > >>>>> <st...@gmail.com> wrote:
> > >>>>>
> > >>>>>  Before I forget, here are some of my thoughts on moving towards
> > >>>>>>
> > >>>>>> Model Version 5.0.0
> > >>>>>>
> > >>>>>> The pom that we build with need not be the pom that gets
> > >>>>>> deployed... thus the pom that is built with need not be the
> > >>>>>> same format as the pom that gets deployed.
> > >>>>>>
> > >>>>>>
> > >>>>> Can you explain why you think this is useful? To me all the
> > >>>>> information that is carried with the POM after deployment is
> > >>>>> primarily for the consumption of tools, and there are a lot of
> > >>>>> tools that expect more than the dependency information. Removing
> > >>>>> all other elements in the POM is equivalent to being massively
> > >>>>> backward incompatible for an API. And if the subsequent
> > >>>>> consumption after deployment is primarily by programs, then why
> > >>>>> does it matter what gets deployed. I don't really see much
> > >>>>> benefit, but will create all sorts of technical problems where
> > >>>>> we need multiple readers and all that entails and the massive
> > >>>>> number of problems this will cause people who have created
> > >>>>> tooling, especially IDE integration. >
> > >>>>>
> > >>>>
> > >>>> The way I see it, what is deployed describes how the artifact
> > >>>> needs to be consumed. This is artifact's "public API", if you
> > >>>> will, it will be consumed by wide range of tools that resolve
> > >>>> dependencies from Maven repositories and descriptor format should
> > >>>> be very stable. Mostly
> > likely
> > >>>> we have no choice but use (a subset of) the current 4.0.0 model
> > version.
> > >>>
> > >>>
> > >>>
> > >>> I would be very sad if we are limited to a subset.
> > >>>
> > >>> There are some critical concepts that in my view are missing from
> > >>> pom files.
> > >>>
> > >>> Number one on my hit list is a <provides> concept.
> > >>>
> > >>> Where you declare that an artifact *provides* the same api as
> > >>> another
> > GAV.
> > >>>
> > >>> Technically you'd need to be able to specify this both at the root
> > >>> of a pom and also flag specific dependencies (because the api they
> > >>> provide was
> > not
> > >>> specified when that pom was deployed)
> > >>>
> > >>> Thus the Geronimo specs poms could all <provides> the
> > >>> corresponding
> > JavaEE
> > >>> specs and excludes issues or other hacks would no longer be required.
> > >>>
> > >>> Look at the issues you will have if you use the excludes wildcards
> > >>> in
> > your
> > >>> pom... Namely *anyone* who uses your artifact as a dependency will
> > need to
> > >>> be using Maven 3 or newer... does ivy read those wildcards correctly?
> > Does
> > >>> sbt? Does Buildr?
> > >>>
> > >>> They are a tempting siren... And from another PoV they will force
> > others
> > >>> to
> > >>> follow... *but* if we are forcing them to follow should we not
> > >>> pick a nicer format to follow... Not one consisting of many layers
> > >>> of hacks?
> > >>>
> > >>> The modelVersion 4.0.0 pom is deployed to the repo (in my scheme)
> > >>> so
> > that
> > >>> legacy clients can still make some sense... If a modelVersion
> > >>> 5.0.0 feature cannot be mapped down to 4.0.0... Well we try our
> > >>> best and that's what
> > you
> > >>> get... We should make it sure that people stuck with older clients
> > >>> can read something semi-sensible and then layer their hacks as
> > >>> normal to get the behaviour they need.
> > >>>
> > >>> Thus <provides> (which is not a scope but a GAV) can be modelled
> > >>> by
> > having
> > >>> the modelVersion 4.0.0 pom list the collapsed dependencies with
> > >>> the appropriate <excludes> added (without wildcards)
> > >>>
> > >>> Other concepts cannot be mapped, so they get dropped.
> > >>>
> > >>>
> > >>>> How the artifact is produced, on the other hand, is artifact's
> > >>>> implementation detail. It is perfectly reasonable for a project
> > >>>> to require minimal version of Maven, for example. Or use
> > >>>> completely different format, not related to pom at all.
> > >>>
> > >>>
> > >>>
> > >>> Exactly... The pom used to build can be written in JSON or
> > >>> whatever
> > domain
> > >>> specific DSL you want... We deploy a modelVersion 5.0.0 pom as XML
> > because
> > >>> it will be read my machines.
> > >>>
> > >>> Now for the reason I think deploying a pom as xml may be a good
> > thing...
> > >>> XSLT
> > >>>
> > >>> Suppose we specify a XSLT GAV that will down-map the pom to a
> > modelVersion
> > >>> 5.0.0 pom... Now we can actually deploy a modelVersion 7.3.5 pom
> > >>> to the one GAVCT and a modelVersion 5.0.0 client reads is, sees it
> > >>> is a
> > modelVersion
> > >>> that is not understood, sees the GAV of the XSLT, pulls it down
> > >>> and transforms the model into the version it can parse
> > >>>
> > >>> Will it be able to parse all the info in the original pom? Nope...
> > It's an
> > >>> older client... Older clients should not expect to grok all the
> > subtleties
> > >>> of newer poms... But it should get the general shape
> > >>>
> > >>> In all of the above, <packaging>pom</packaging> is special... We
> > >>> just deploy that as is in whatever format
> > >>> (JSON/DSL/XML/groovy/etc) as the -build.pom
> > >>>
> > >>> So 4.0.0 => .pom
> > >>> 5.0.0 onward (XSLT down versioning) => -dep.pom And as a parent =<
> > >>> -build.pom
> > >>>
> > >>> Modern clients can ask for the -dep.pom first... And fall back to
> > >>> the
> > .pom
> > >>>
> > >>> It's not perfect, but it should not be the hell of 3.0.0->4.0.0
> > >>> the
> > fear
> > >>> of
> > >>> which has prevented forward progress since
> > >>>
> > >>>
> > >>>> By separating "consumption" and "production" metadata formats,
> > >>>> we'll
> > be
> > >>>> able to evolve production format more aggressively. For example,
> > >>>> it would be nice to have Tycho-specific configuration markup
> > >>>> inside
> > <build>
> > >>>> section. This is not currently possible because all poms must be
> > >>>> compatible with the same model.
> > >>>>
> > >>>> --
> > >>>> Regards,
> > >>>> Igor
> > >>>>
> > >>>>
> > >>>>
> > >>>>  Only with <packaging>pom</packaging> do we actually need things
> > >>>> like the
> > >>>>>>
> > >>>>>> <plugins> section in the deployed pom, because it is a reality
> > >>>>>> that
> > for
> > >>>>>> noo-pom packaging we just want the transitive dependencies.
> > >>>>>>
> > >>>>>> Now there is the <extensions> issue where you might be
> > >>>>>> registering a different file type that has different rules with
> > >>>>>> respect to the classpath... but I am unsure if we actually
> > >>>>>> consider those when evaluating the dependency tree... and in
> > >>>>>> any case, once we accept that the deployed pom is not the same
> > >>>>>> as the pom used to build (for non-pom packaging
> > at
> > >>>>>> least) we can transform that dependency tree using the exact
> > >>>>>> rules
> > that
> > >>>>>> have to be known at build time thus closing the extensions issue.
> > >>>>>>
> > >>>>>> For projects with <packaging>pom</packaging> in fact we are
> > >>>>>> only deploying smal files so perhaps we can deploy two pom
> > >>>>>> files... the one that exposes the standard dependency stuff and
> > >>>>>> then a second one that is used for build inheritance.
> > >>>>>>
> > >>>>>> My vision is thus that we deploy between 2 and three pom files
> > >>>>>> for every project.
> > >>>>>>
> > >>>>>> For jar/war/ear/... we deploy:
> > >>>>>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
> > >>>>>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies
> > >>>>>> but allows for new scopes)
> > >>>>>>
> > >>>>>> For pom we deploy
> > >>>>>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
> > >>>>>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies
> > >>>>>> but allows for new scopes)
> > >>>>>> * the pom itself
> > >>>>>>
> > >>>>>> When building a pom, your parent pom must be of a modelVersion
> > >>>>>> <=
> > your
> > >>>>>> modelVersion.
> > >>>>>>
> > >>>>>
> > >>>>> Thanks,
> > >>>>>
> > >>>>> Jason
> > >>>>>
> > >>>>> ----------------------------------------------------------
> > >>>>> Jason van Zyl
> > >>>>> Founder,  Apache Maven
> > >>>>> http://twitter.com/jvanzyl
> > >>>>> ---------------------------------------------------------
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>> -----------------------------------------------------------------
> > >>>> ---- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> > >>>> additional commands, e-mail: dev-help@maven.apache.org
> > >>>>
> > >>>>
> > >>>
> > >>
> > >> -------------------------------------------------------------------
> > >> -- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> > >> additional commands, e-mail: dev-help@maven.apache.org
> > >>
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> > > additional commands, e-mail: dev-help@maven.apache.org
> > >
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder,  Apache Maven
> > http://twitter.com/jvanzyl
> > ---------------------------------------------------------
> >
> >
> >
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

RE: Model Version 5.0.0

Posted by Robert Patrick <ro...@oracle.com>.

> Additionally, I think we should refine scopes... there are some that are likely missing and some, such as `system` that should be removed.

Pardon my ignorance but while I understand the negative implications of using system-scoped dependencies, I believe there are cases at least a few use cases where they are required.  For example, we have a plugin that depends on tools.jar from the JDK.  We currently use a system-scoped dependency for this.  If you were to remove system-scoped dependencies, how would you propose that people handle use cases such as this?

 
-----Original Message-----
From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com] 
Sent: Sunday, November 24, 2013 1:34 PM
To: Maven Developers List
Subject: Re: Model Version 5.0.0

On 24 November 2013 17:44, Jason van Zyl <ja...@tesla.io> wrote:

>
> On Nov 24, 2013, at 10:28 AM, Benson Margulies <bi...@gmail.com>
> wrote:
>
> > It seems to me that this thread is mixing two topics.
> >
> > Topic #1: How to we move to pom 5.0, given a giant ecosystem of 
> > crappy XML-parsing POM consumers?
> >
> > Topic #2: To what extent does the pom mix a 'description of contract'
> > (dependencies, etc) with a 'specification of build'?
> >
> > On the first topic, there was a wiki page months ago that explored a 
> > scheme for writing both a v4 pom and a v5 pom when deploying from a 
> > v5 project, so that old tools could see and consume what they understand.
> > To the extent that this scheme made sense, it can be adopted without
> > (necessarily) touching the second.
> >
>
> If you are referring to this:
>
>
> https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+
> the+POM+data+model
>
> Then I think what this document lacks are the use cases that drive 
> anything. Without actually having some target features you cannot 
> understand what you require technically.
>
> I think from the discussion thus far we have the following features:
>
> - API provides (from Stephen)
> - Runtime requirements (from Manfred)
> - Global excludes (much asked for feature)
> - Global swaps (much asked for feature)
>

Additionally, I think we should refine scopes... there are some that are likely missing and some, such as `system` that should be removed.

Platform dependency *could* be handled by dependency, e.g.

<dependency gav="java:java:1.8:platform"/>

could indicate that you need java 8 to run...

The question though is how you handle multiple potential platforms, e.g.
works on java 1.6 or android...

That may require a change to the dependency model... some sort of dependency group... whereby any one of the deps in the group can satisfy the need...

A potentially better solution would be a specific platform section... but is the more generic <dep> based solution perhaps better?



> Additionally by requirements:
> - Are we going to allow for extensibility?
> - Are we going to be future proof?
> - Are we going to provide backward compatibility?
>
> I believe this is where we start. Many of the answers about how the 
> implementation will look will be driven by specific features and 
> answers to requirements questions.
>

Another point is that if we don't ack that we need to rev the spec and this may be the only chance to rev the spec for a while, we won't see the features we need.

Hacking the 4.0.0 pom will only make baby steps and lead to hacky solutions... opening up the chance to rev the pom spec and schema opens up the potential for other ideas


>
> > On the second topic, I'm in agreement that there should be a clear 
> > separation between describing a contract and other things. For 
> > example, why is it a good idea for deployed poms to reference 
> > parents, rather than being self-contained? Why is it a good idea for 
> > deployed poms to include profiles? Why is it a good thing for 
> > deployed poms to include parameter references, thereby in some cases 
> > accidently changing their semantics due to collisions with the 
> > consuming application's pom? The full 'here's how to build' pom, in 
> > my view, is part of the source, and should be deployed with the 
> > source, and any tool that can usefully analyze the details (plugins, 
> > pluginManagement,
> > etc) is welcome to do so. Having written this, it also seems to me 
> > that one compromise could be that v5 deployed poms could be 
> > self-contained, complete, but organized so as be clear as to the two 
> > categories of contents.
> >
> >
> >
> > On Sun, Nov 24, 2013 at 9:29 AM, Igor Fedorenko 
> > <ig...@ifedorenko.com>
> wrote:
> >> I think we are saying the same thing -- we evolve project model 
> >> used during the build but deploy both the new and backwards 
> >> compatible
> models.
> >>
> >> One quick note on representing dependencies as provided/required 
> >> capabilities. Although I like this idea in general, I believe it 
> >> will require completely new repository layout to be able to 
> >> efficiently find capability providers. Single repository-wide 
> >> metadata index file, the approach implemented in P2 for example, 
> >> won't scale for repositories of the size of Central, so most likely 
> >> the new repository layout will require active server-side component to assist dependency resolution.
> >>
> >> --
> >> Regards,
> >> Igor
> >>
> >>
> >> On 11/24/2013, 4:25, Stephen Connolly wrote:
> >>>
> >>> On Sunday, 24 November 2013, Igor Fedorenko wrote:
> >>>
> >>>>
> >>>>
> >>>> On 11/23/2013, 23:08, Jason van Zyl wrote:
> >>>>
> >>>>>
> >>>>> On Nov 23, 2013, at 5:44 PM, Stephen Connolly 
> >>>>> <st...@gmail.com> wrote:
> >>>>>
> >>>>>  Before I forget, here are some of my thoughts on moving towards
> >>>>>>
> >>>>>> Model Version 5.0.0
> >>>>>>
> >>>>>> The pom that we build with need not be the pom that gets 
> >>>>>> deployed... thus the pom that is built with need not be the 
> >>>>>> same format as the pom that gets deployed.
> >>>>>>
> >>>>>>
> >>>>> Can you explain why you think this is useful? To me all the 
> >>>>> information that is carried with the POM after deployment is 
> >>>>> primarily for the consumption of tools, and there are a lot of 
> >>>>> tools that expect more than the dependency information. Removing 
> >>>>> all other elements in the POM is equivalent to being massively 
> >>>>> backward incompatible for an API. And if the subsequent 
> >>>>> consumption after deployment is primarily by programs, then why 
> >>>>> does it matter what gets deployed. I don't really see much 
> >>>>> benefit, but will create all sorts of technical problems where 
> >>>>> we need multiple readers and all that entails and the massive 
> >>>>> number of problems this will cause people who have created 
> >>>>> tooling, especially IDE integration. >
> >>>>>
> >>>>
> >>>> The way I see it, what is deployed describes how the artifact 
> >>>> needs to be consumed. This is artifact's "public API", if you 
> >>>> will, it will be consumed by wide range of tools that resolve 
> >>>> dependencies from Maven repositories and descriptor format should 
> >>>> be very stable. Mostly
> likely
> >>>> we have no choice but use (a subset of) the current 4.0.0 model
> version.
> >>>
> >>>
> >>>
> >>> I would be very sad if we are limited to a subset.
> >>>
> >>> There are some critical concepts that in my view are missing from 
> >>> pom files.
> >>>
> >>> Number one on my hit list is a <provides> concept.
> >>>
> >>> Where you declare that an artifact *provides* the same api as 
> >>> another
> GAV.
> >>>
> >>> Technically you'd need to be able to specify this both at the root 
> >>> of a pom and also flag specific dependencies (because the api they 
> >>> provide was
> not
> >>> specified when that pom was deployed)
> >>>
> >>> Thus the Geronimo specs poms could all <provides> the 
> >>> corresponding
> JavaEE
> >>> specs and excludes issues or other hacks would no longer be required.
> >>>
> >>> Look at the issues you will have if you use the excludes wildcards 
> >>> in
> your
> >>> pom... Namely *anyone* who uses your artifact as a dependency will
> need to
> >>> be using Maven 3 or newer... does ivy read those wildcards correctly?
> Does
> >>> sbt? Does Buildr?
> >>>
> >>> They are a tempting siren... And from another PoV they will force
> others
> >>> to
> >>> follow... *but* if we are forcing them to follow should we not 
> >>> pick a nicer format to follow... Not one consisting of many layers 
> >>> of hacks?
> >>>
> >>> The modelVersion 4.0.0 pom is deployed to the repo (in my scheme) 
> >>> so
> that
> >>> legacy clients can still make some sense... If a modelVersion 
> >>> 5.0.0 feature cannot be mapped down to 4.0.0... Well we try our 
> >>> best and that's what
> you
> >>> get... We should make it sure that people stuck with older clients 
> >>> can read something semi-sensible and then layer their hacks as 
> >>> normal to get the behaviour they need.
> >>>
> >>> Thus <provides> (which is not a scope but a GAV) can be modelled 
> >>> by
> having
> >>> the modelVersion 4.0.0 pom list the collapsed dependencies with 
> >>> the appropriate <excludes> added (without wildcards)
> >>>
> >>> Other concepts cannot be mapped, so they get dropped.
> >>>
> >>>
> >>>> How the artifact is produced, on the other hand, is artifact's 
> >>>> implementation detail. It is perfectly reasonable for a project 
> >>>> to require minimal version of Maven, for example. Or use 
> >>>> completely different format, not related to pom at all.
> >>>
> >>>
> >>>
> >>> Exactly... The pom used to build can be written in JSON or 
> >>> whatever
> domain
> >>> specific DSL you want... We deploy a modelVersion 5.0.0 pom as XML
> because
> >>> it will be read my machines.
> >>>
> >>> Now for the reason I think deploying a pom as xml may be a good
> thing...
> >>> XSLT
> >>>
> >>> Suppose we specify a XSLT GAV that will down-map the pom to a
> modelVersion
> >>> 5.0.0 pom... Now we can actually deploy a modelVersion 7.3.5 pom 
> >>> to the one GAVCT and a modelVersion 5.0.0 client reads is, sees it 
> >>> is a
> modelVersion
> >>> that is not understood, sees the GAV of the XSLT, pulls it down 
> >>> and transforms the model into the version it can parse
> >>>
> >>> Will it be able to parse all the info in the original pom? Nope...
> It's an
> >>> older client... Older clients should not expect to grok all the
> subtleties
> >>> of newer poms... But it should get the general shape
> >>>
> >>> In all of the above, <packaging>pom</packaging> is special... We 
> >>> just deploy that as is in whatever format 
> >>> (JSON/DSL/XML/groovy/etc) as the -build.pom
> >>>
> >>> So 4.0.0 => .pom
> >>> 5.0.0 onward (XSLT down versioning) => -dep.pom And as a parent =< 
> >>> -build.pom
> >>>
> >>> Modern clients can ask for the -dep.pom first... And fall back to 
> >>> the
> .pom
> >>>
> >>> It's not perfect, but it should not be the hell of 3.0.0->4.0.0 
> >>> the
> fear
> >>> of
> >>> which has prevented forward progress since
> >>>
> >>>
> >>>> By separating "consumption" and "production" metadata formats, 
> >>>> we'll
> be
> >>>> able to evolve production format more aggressively. For example, 
> >>>> it would be nice to have Tycho-specific configuration markup 
> >>>> inside
> <build>
> >>>> section. This is not currently possible because all poms must be 
> >>>> compatible with the same model.
> >>>>
> >>>> --
> >>>> Regards,
> >>>> Igor
> >>>>
> >>>>
> >>>>
> >>>>  Only with <packaging>pom</packaging> do we actually need things 
> >>>> like the
> >>>>>>
> >>>>>> <plugins> section in the deployed pom, because it is a reality 
> >>>>>> that
> for
> >>>>>> noo-pom packaging we just want the transitive dependencies.
> >>>>>>
> >>>>>> Now there is the <extensions> issue where you might be 
> >>>>>> registering a different file type that has different rules with 
> >>>>>> respect to the classpath... but I am unsure if we actually 
> >>>>>> consider those when evaluating the dependency tree... and in 
> >>>>>> any case, once we accept that the deployed pom is not the same 
> >>>>>> as the pom used to build (for non-pom packaging
> at
> >>>>>> least) we can transform that dependency tree using the exact 
> >>>>>> rules
> that
> >>>>>> have to be known at build time thus closing the extensions issue.
> >>>>>>
> >>>>>> For projects with <packaging>pom</packaging> in fact we are 
> >>>>>> only deploying smal files so perhaps we can deploy two pom 
> >>>>>> files... the one that exposes the standard dependency stuff and 
> >>>>>> then a second one that is used for build inheritance.
> >>>>>>
> >>>>>> My vision is thus that we deploy between 2 and three pom files 
> >>>>>> for every project.
> >>>>>>
> >>>>>> For jar/war/ear/... we deploy:
> >>>>>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
> >>>>>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies 
> >>>>>> but allows for new scopes)
> >>>>>>
> >>>>>> For pom we deploy
> >>>>>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
> >>>>>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies 
> >>>>>> but allows for new scopes)
> >>>>>> * the pom itself
> >>>>>>
> >>>>>> When building a pom, your parent pom must be of a modelVersion 
> >>>>>> <=
> your
> >>>>>> modelVersion.
> >>>>>>
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Jason
> >>>>>
> >>>>> ----------------------------------------------------------
> >>>>> Jason van Zyl
> >>>>> Founder,  Apache Maven
> >>>>> http://twitter.com/jvanzyl
> >>>>> ---------------------------------------------------------
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> -----------------------------------------------------------------
> >>>> ---- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For 
> >>>> additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >>>
> >>
> >> -------------------------------------------------------------------
> >> -- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For 
> >> additional commands, e-mail: dev-help@maven.apache.org
> >>
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For 
> > additional commands, e-mail: dev-help@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
>
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Model Version 5.0.0

Posted by Stephen Connolly <st...@gmail.com>.

On 24 November 2013 17:44, Jason van Zyl <ja...@tesla.io> wrote:

>
> On Nov 24, 2013, at 10:28 AM, Benson Margulies <bi...@gmail.com>
> wrote:
>
> > It seems to me that this thread is mixing two topics.
> >
> > Topic #1: How to we move to pom 5.0, given a giant ecosystem of crappy
> > XML-parsing POM consumers?
> >
> > Topic #2: To what extent does the pom mix a 'description of contract'
> > (dependencies, etc) with a 'specification of build'?
> >
> > On the first topic, there was a wiki page months ago that explored a
> > scheme for writing both a v4 pom and a v5 pom when deploying from a v5
> > project, so that old tools could see and consume what they understand.
> > To the extent that this scheme made sense, it can be adopted without
> > (necessarily) touching the second.
> >
>
> If you are referring to this:
>
>
> https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+the+POM+data+model
>
> Then I think what this document lacks are the use cases that drive
> anything. Without actually having some target features you cannot
> understand what you require technically.
>
> I think from the discussion thus far we have the following features:
>
> - API provides (from Stephen)
> - Runtime requirements (from Manfred)
> - Global excludes (much asked for feature)
> - Global swaps (much asked for feature)
>

Additionally, I think we should refine scopes... there are some that are
likely missing and some, such as `system` that should be removed.

Platform dependency *could* be handled by dependency, e.g.

<dependency gav="java:java:1.8:platform"/>

could indicate that you need java 8 to run...

The question though is how you handle multiple potential platforms, e.g.
works on java 1.6 or android...

That may require a change to the dependency model... some sort of
dependency group... whereby any one of the deps in the group can satisfy
the need...

A potentially better solution would be a specific platform section... but
is the more generic <dep> based solution perhaps better?



> Additionally by requirements:
> - Are we going to allow for extensibility?
> - Are we going to be future proof?
> - Are we going to provide backward compatibility?
>
> I believe this is where we start. Many of the answers about how the
> implementation will look will be driven by specific features and answers to
> requirements questions.
>

Another point is that if we don't ack that we need to rev the spec and this
may be the only chance to rev the spec for a while, we won't see the
features we need.

Hacking the 4.0.0 pom will only make baby steps and lead to hacky
solutions... opening up the chance to rev the pom spec and schema opens up
the potential for other ideas


>
> > On the second topic, I'm in agreement that there should be a clear
> > separation between describing a contract and other things. For
> > example, why is it a good idea for deployed poms to reference parents,
> > rather than being self-contained? Why is it a good idea for deployed
> > poms to include profiles? Why is it a good thing for deployed poms to
> > include parameter references, thereby in some cases accidently
> > changing their semantics due to collisions with the consuming
> > application's pom? The full 'here's how to build' pom, in my view, is
> > part of the source, and should be deployed with the source, and any
> > tool that can usefully analyze the details (plugins, pluginManagement,
> > etc) is welcome to do so. Having written this, it also seems to me
> > that one compromise could be that v5 deployed poms could be
> > self-contained, complete, but organized so as be clear as to the two
> > categories of contents.
> >
> >
> >
> > On Sun, Nov 24, 2013 at 9:29 AM, Igor Fedorenko <ig...@ifedorenko.com>
> wrote:
> >> I think we are saying the same thing -- we evolve project model used
> >> during the build but deploy both the new and backwards compatible
> models.
> >>
> >> One quick note on representing dependencies as provided/required
> >> capabilities. Although I like this idea in general, I believe it will
> >> require completely new repository layout to be able to efficiently
> >> find capability providers. Single repository-wide metadata index file,
> >> the approach implemented in P2 for example, won't scale for repositories
> >> of the size of Central, so most likely the new repository layout will
> >> require active server-side component to assist dependency resolution.
> >>
> >> --
> >> Regards,
> >> Igor
> >>
> >>
> >> On 11/24/2013, 4:25, Stephen Connolly wrote:
> >>>
> >>> On Sunday, 24 November 2013, Igor Fedorenko wrote:
> >>>
> >>>>
> >>>>
> >>>> On 11/23/2013, 23:08, Jason van Zyl wrote:
> >>>>
> >>>>>
> >>>>> On Nov 23, 2013, at 5:44 PM, Stephen Connolly
> >>>>> <st...@gmail.com> wrote:
> >>>>>
> >>>>>  Before I forget, here are some of my thoughts on moving towards
> >>>>>>
> >>>>>> Model Version 5.0.0
> >>>>>>
> >>>>>> The pom that we build with need not be the pom that gets
> >>>>>> deployed... thus the pom that is built with need not be the same
> >>>>>> format as the pom that gets deployed.
> >>>>>>
> >>>>>>
> >>>>> Can you explain why you think this is useful? To me all the
> >>>>> information that is carried with the POM after deployment is
> >>>>> primarily for the consumption of tools, and there are a lot of tools
> >>>>> that expect more than the dependency information. Removing all other
> >>>>> elements in the POM is equivalent to being massively backward
> >>>>> incompatible for an API. And if the subsequent consumption after
> >>>>> deployment is primarily by programs, then why does it matter what
> >>>>> gets deployed. I don't really see much benefit, but will create all
> >>>>> sorts of technical problems where we need multiple readers and all
> >>>>> that entails and the massive number of problems this will cause
> >>>>> people who have created tooling, especially IDE integration. >
> >>>>>
> >>>>
> >>>> The way I see it, what is deployed describes how the artifact needs to
> >>>> be consumed. This is artifact's "public API", if you will, it will be
> >>>> consumed by wide range of tools that resolve dependencies from Maven
> >>>> repositories and descriptor format should be very stable. Mostly
> likely
> >>>> we have no choice but use (a subset of) the current 4.0.0 model
> version.
> >>>
> >>>
> >>>
> >>> I would be very sad if we are limited to a subset.
> >>>
> >>> There are some critical concepts that in my view are missing from pom
> >>> files.
> >>>
> >>> Number one on my hit list is a <provides> concept.
> >>>
> >>> Where you declare that an artifact *provides* the same api as another
> GAV.
> >>>
> >>> Technically you'd need to be able to specify this both at the root of a
> >>> pom
> >>> and also flag specific dependencies (because the api they provide was
> not
> >>> specified when that pom was deployed)
> >>>
> >>> Thus the Geronimo specs poms could all <provides> the corresponding
> JavaEE
> >>> specs and excludes issues or other hacks would no longer be required.
> >>>
> >>> Look at the issues you will have if you use the excludes wildcards in
> your
> >>> pom... Namely *anyone* who uses your artifact as a dependency will
> need to
> >>> be using Maven 3 or newer... does ivy read those wildcards correctly?
> Does
> >>> sbt? Does Buildr?
> >>>
> >>> They are a tempting siren... And from another PoV they will force
> others
> >>> to
> >>> follow... *but* if we are forcing them to follow should we not pick a
> >>> nicer
> >>> format to follow... Not one consisting of many layers of hacks?
> >>>
> >>> The modelVersion 4.0.0 pom is deployed to the repo (in my scheme) so
> that
> >>> legacy clients can still make some sense... If a modelVersion 5.0.0
> >>> feature
> >>> cannot be mapped down to 4.0.0... Well we try our best and that's what
> you
> >>> get... We should make it sure that people stuck with older clients can
> >>> read
> >>> something semi-sensible and then layer their hacks as normal to get the
> >>> behaviour they need.
> >>>
> >>> Thus <provides> (which is not a scope but a GAV) can be modelled by
> having
> >>> the modelVersion 4.0.0 pom list the collapsed dependencies with the
> >>> appropriate <excludes> added (without wildcards)
> >>>
> >>> Other concepts cannot be mapped, so they get dropped.
> >>>
> >>>
> >>>> How the artifact is produced, on the other hand, is artifact's
> >>>> implementation detail. It is perfectly reasonable for a project to
> >>>> require minimal version of Maven, for example. Or use completely
> >>>> different format, not related to pom at all.
> >>>
> >>>
> >>>
> >>> Exactly... The pom used to build can be written in JSON or whatever
> domain
> >>> specific DSL you want... We deploy a modelVersion 5.0.0 pom as XML
> because
> >>> it will be read my machines.
> >>>
> >>> Now for the reason I think deploying a pom as xml may be a good
> thing...
> >>> XSLT
> >>>
> >>> Suppose we specify a XSLT GAV that will down-map the pom to a
> modelVersion
> >>> 5.0.0 pom... Now we can actually deploy a modelVersion 7.3.5 pom to the
> >>> one
> >>> GAVCT and a modelVersion 5.0.0 client reads is, sees it is a
> modelVersion
> >>> that is not understood, sees the GAV of the XSLT, pulls it down and
> >>> transforms the model into the version it can parse
> >>>
> >>> Will it be able to parse all the info in the original pom? Nope...
> It's an
> >>> older client... Older clients should not expect to grok all the
> subtleties
> >>> of newer poms... But it should get the general shape
> >>>
> >>> In all of the above, <packaging>pom</packaging> is special... We just
> >>> deploy that as is in whatever format (JSON/DSL/XML/groovy/etc) as the
> >>> -build.pom
> >>>
> >>> So 4.0.0 => .pom
> >>> 5.0.0 onward (XSLT down versioning) => -dep.pom
> >>> And as a parent =< -build.pom
> >>>
> >>> Modern clients can ask for the -dep.pom first... And fall back to the
> .pom
> >>>
> >>> It's not perfect, but it should not be the hell of 3.0.0->4.0.0 the
> fear
> >>> of
> >>> which has prevented forward progress since
> >>>
> >>>
> >>>> By separating "consumption" and "production" metadata formats, we'll
> be
> >>>> able to evolve production format more aggressively. For example, it
> >>>> would be nice to have Tycho-specific configuration markup inside
> <build>
> >>>> section. This is not currently possible because all poms must be
> >>>> compatible with the same model.
> >>>>
> >>>> --
> >>>> Regards,
> >>>> Igor
> >>>>
> >>>>
> >>>>
> >>>>  Only with <packaging>pom</packaging> do we actually need things like
> >>>> the
> >>>>>>
> >>>>>> <plugins> section in the deployed pom, because it is a reality that
> for
> >>>>>> noo-pom packaging we just want the transitive dependencies.
> >>>>>>
> >>>>>> Now there is the <extensions> issue where you might be registering a
> >>>>>> different file type that has different rules with respect to the
> >>>>>> classpath... but I am unsure if we actually consider those when
> >>>>>> evaluating
> >>>>>> the dependency tree... and in any case, once we accept that the
> >>>>>> deployed
> >>>>>> pom is not the same as the pom used to build (for non-pom packaging
> at
> >>>>>> least) we can transform that dependency tree using the exact rules
> that
> >>>>>> have to be known at build time thus closing the extensions issue.
> >>>>>>
> >>>>>> For projects with <packaging>pom</packaging> in fact we are only
> >>>>>> deploying
> >>>>>> smal files so perhaps we can deploy two pom files... the one that
> >>>>>> exposes
> >>>>>> the standard dependency stuff and then a second one that is used for
> >>>>>> build
> >>>>>> inheritance.
> >>>>>>
> >>>>>> My vision is thus that we deploy between 2 and three pom files for
> >>>>>> every
> >>>>>> project.
> >>>>>>
> >>>>>> For jar/war/ear/... we deploy:
> >>>>>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
> >>>>>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but
> >>>>>> allows
> >>>>>> for new scopes)
> >>>>>>
> >>>>>> For pom we deploy
> >>>>>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
> >>>>>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but
> >>>>>> allows
> >>>>>> for new scopes)
> >>>>>> * the pom itself
> >>>>>>
> >>>>>> When building a pom, your parent pom must be of a modelVersion <=
> your
> >>>>>> modelVersion.
> >>>>>>
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Jason
> >>>>>
> >>>>> ----------------------------------------------------------
> >>>>> Jason van Zyl
> >>>>> Founder,  Apache Maven
> >>>>> http://twitter.com/jvanzyl
> >>>>> ---------------------------------------------------------
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
>
>
>
>
>
>
>

Re: Model Version 5.0.0

Posted by Jason van Zyl <ja...@tesla.io>.

On Nov 24, 2013, at 10:28 AM, Benson Margulies <bi...@gmail.com> wrote:

> It seems to me that this thread is mixing two topics.
> 
> Topic #1: How to we move to pom 5.0, given a giant ecosystem of crappy
> XML-parsing POM consumers?
> 
> Topic #2: To what extent does the pom mix a 'description of contract'
> (dependencies, etc) with a 'specification of build'?
> 
> On the first topic, there was a wiki page months ago that explored a
> scheme for writing both a v4 pom and a v5 pom when deploying from a v5
> project, so that old tools could see and consume what they understand.
> To the extent that this scheme made sense, it can be adopted without
> (necessarily) touching the second.
> 

If you are referring to this:

https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+the+POM+data+model

Then I think what this document lacks are the use cases that drive anything. Without actually having some target features you cannot understand what you require technically. 

I think from the discussion thus far we have the following features:

- API provides (from Stephen)
- Runtime requirements (from Manfred)
- Global excludes (much asked for feature)
- Global swaps (much asked for feature)

Additionally by requirements:
- Are we going to allow for extensibility?
- Are we going to be future proof?
- Are we going to provide backward compatibility?

I believe this is where we start. Many of the answers about how the implementation will look will be driven by specific features and answers to requirements questions.

> On the second topic, I'm in agreement that there should be a clear
> separation between describing a contract and other things. For
> example, why is it a good idea for deployed poms to reference parents,
> rather than being self-contained? Why is it a good idea for deployed
> poms to include profiles? Why is it a good thing for deployed poms to
> include parameter references, thereby in some cases accidently
> changing their semantics due to collisions with the consuming
> application's pom? The full 'here's how to build' pom, in my view, is
> part of the source, and should be deployed with the source, and any
> tool that can usefully analyze the details (plugins, pluginManagement,
> etc) is welcome to do so. Having written this, it also seems to me
> that one compromise could be that v5 deployed poms could be
> self-contained, complete, but organized so as be clear as to the two
> categories of contents.
> 
> 
> 
> On Sun, Nov 24, 2013 at 9:29 AM, Igor Fedorenko <ig...@ifedorenko.com> wrote:
>> I think we are saying the same thing -- we evolve project model used
>> during the build but deploy both the new and backwards compatible models.
>> 
>> One quick note on representing dependencies as provided/required
>> capabilities. Although I like this idea in general, I believe it will
>> require completely new repository layout to be able to efficiently
>> find capability providers. Single repository-wide metadata index file,
>> the approach implemented in P2 for example, won't scale for repositories
>> of the size of Central, so most likely the new repository layout will
>> require active server-side component to assist dependency resolution.
>> 
>> --
>> Regards,
>> Igor
>> 
>> 
>> On 11/24/2013, 4:25, Stephen Connolly wrote:
>>> 
>>> On Sunday, 24 November 2013, Igor Fedorenko wrote:
>>> 
>>>> 
>>>> 
>>>> On 11/23/2013, 23:08, Jason van Zyl wrote:
>>>> 
>>>>> 
>>>>> On Nov 23, 2013, at 5:44 PM, Stephen Connolly
>>>>> <st...@gmail.com> wrote:
>>>>> 
>>>>>  Before I forget, here are some of my thoughts on moving towards
>>>>>> 
>>>>>> Model Version 5.0.0
>>>>>> 
>>>>>> The pom that we build with need not be the pom that gets
>>>>>> deployed... thus the pom that is built with need not be the same
>>>>>> format as the pom that gets deployed.
>>>>>> 
>>>>>> 
>>>>> Can you explain why you think this is useful? To me all the
>>>>> information that is carried with the POM after deployment is
>>>>> primarily for the consumption of tools, and there are a lot of tools
>>>>> that expect more than the dependency information. Removing all other
>>>>> elements in the POM is equivalent to being massively backward
>>>>> incompatible for an API. And if the subsequent consumption after
>>>>> deployment is primarily by programs, then why does it matter what
>>>>> gets deployed. I don't really see much benefit, but will create all
>>>>> sorts of technical problems where we need multiple readers and all
>>>>> that entails and the massive number of problems this will cause
>>>>> people who have created tooling, especially IDE integration. >
>>>>> 
>>>> 
>>>> The way I see it, what is deployed describes how the artifact needs to
>>>> be consumed. This is artifact's "public API", if you will, it will be
>>>> consumed by wide range of tools that resolve dependencies from Maven
>>>> repositories and descriptor format should be very stable. Mostly likely
>>>> we have no choice but use (a subset of) the current 4.0.0 model version.
>>> 
>>> 
>>> 
>>> I would be very sad if we are limited to a subset.
>>> 
>>> There are some critical concepts that in my view are missing from pom
>>> files.
>>> 
>>> Number one on my hit list is a <provides> concept.
>>> 
>>> Where you declare that an artifact *provides* the same api as another GAV.
>>> 
>>> Technically you'd need to be able to specify this both at the root of a
>>> pom
>>> and also flag specific dependencies (because the api they provide was not
>>> specified when that pom was deployed)
>>> 
>>> Thus the Geronimo specs poms could all <provides> the corresponding JavaEE
>>> specs and excludes issues or other hacks would no longer be required.
>>> 
>>> Look at the issues you will have if you use the excludes wildcards in your
>>> pom... Namely *anyone* who uses your artifact as a dependency will need to
>>> be using Maven 3 or newer... does ivy read those wildcards correctly? Does
>>> sbt? Does Buildr?
>>> 
>>> They are a tempting siren... And from another PoV they will force others
>>> to
>>> follow... *but* if we are forcing them to follow should we not pick a
>>> nicer
>>> format to follow... Not one consisting of many layers of hacks?
>>> 
>>> The modelVersion 4.0.0 pom is deployed to the repo (in my scheme) so that
>>> legacy clients can still make some sense... If a modelVersion 5.0.0
>>> feature
>>> cannot be mapped down to 4.0.0... Well we try our best and that's what you
>>> get... We should make it sure that people stuck with older clients can
>>> read
>>> something semi-sensible and then layer their hacks as normal to get the
>>> behaviour they need.
>>> 
>>> Thus <provides> (which is not a scope but a GAV) can be modelled by having
>>> the modelVersion 4.0.0 pom list the collapsed dependencies with the
>>> appropriate <excludes> added (without wildcards)
>>> 
>>> Other concepts cannot be mapped, so they get dropped.
>>> 
>>> 
>>>> How the artifact is produced, on the other hand, is artifact's
>>>> implementation detail. It is perfectly reasonable for a project to
>>>> require minimal version of Maven, for example. Or use completely
>>>> different format, not related to pom at all.
>>> 
>>> 
>>> 
>>> Exactly... The pom used to build can be written in JSON or whatever domain
>>> specific DSL you want... We deploy a modelVersion 5.0.0 pom as XML because
>>> it will be read my machines.
>>> 
>>> Now for the reason I think deploying a pom as xml may be a good thing...
>>> XSLT
>>> 
>>> Suppose we specify a XSLT GAV that will down-map the pom to a modelVersion
>>> 5.0.0 pom... Now we can actually deploy a modelVersion 7.3.5 pom to the
>>> one
>>> GAVCT and a modelVersion 5.0.0 client reads is, sees it is a modelVersion
>>> that is not understood, sees the GAV of the XSLT, pulls it down and
>>> transforms the model into the version it can parse
>>> 
>>> Will it be able to parse all the info in the original pom? Nope... It's an
>>> older client... Older clients should not expect to grok all the subtleties
>>> of newer poms... But it should get the general shape
>>> 
>>> In all of the above, <packaging>pom</packaging> is special... We just
>>> deploy that as is in whatever format (JSON/DSL/XML/groovy/etc) as the
>>> -build.pom
>>> 
>>> So 4.0.0 => .pom
>>> 5.0.0 onward (XSLT down versioning) => -dep.pom
>>> And as a parent =< -build.pom
>>> 
>>> Modern clients can ask for the -dep.pom first... And fall back to the .pom
>>> 
>>> It's not perfect, but it should not be the hell of 3.0.0->4.0.0 the fear
>>> of
>>> which has prevented forward progress since
>>> 
>>> 
>>>> By separating "consumption" and "production" metadata formats, we'll be
>>>> able to evolve production format more aggressively. For example, it
>>>> would be nice to have Tycho-specific configuration markup inside <build>
>>>> section. This is not currently possible because all poms must be
>>>> compatible with the same model.
>>>> 
>>>> --
>>>> Regards,
>>>> Igor
>>>> 
>>>> 
>>>> 
>>>>  Only with <packaging>pom</packaging> do we actually need things like
>>>> the
>>>>>> 
>>>>>> <plugins> section in the deployed pom, because it is a reality that for
>>>>>> noo-pom packaging we just want the transitive dependencies.
>>>>>> 
>>>>>> Now there is the <extensions> issue where you might be registering a
>>>>>> different file type that has different rules with respect to the
>>>>>> classpath... but I am unsure if we actually consider those when
>>>>>> evaluating
>>>>>> the dependency tree... and in any case, once we accept that the
>>>>>> deployed
>>>>>> pom is not the same as the pom used to build (for non-pom packaging at
>>>>>> least) we can transform that dependency tree using the exact rules that
>>>>>> have to be known at build time thus closing the extensions issue.
>>>>>> 
>>>>>> For projects with <packaging>pom</packaging> in fact we are only
>>>>>> deploying
>>>>>> smal files so perhaps we can deploy two pom files... the one that
>>>>>> exposes
>>>>>> the standard dependency stuff and then a second one that is used for
>>>>>> build
>>>>>> inheritance.
>>>>>> 
>>>>>> My vision is thus that we deploy between 2 and three pom files for
>>>>>> every
>>>>>> project.
>>>>>> 
>>>>>> For jar/war/ear/... we deploy:
>>>>>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
>>>>>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but
>>>>>> allows
>>>>>> for new scopes)
>>>>>> 
>>>>>> For pom we deploy
>>>>>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
>>>>>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but
>>>>>> allows
>>>>>> for new scopes)
>>>>>> * the pom itself
>>>>>> 
>>>>>> When building a pom, your parent pom must be of a modelVersion <= your
>>>>>> modelVersion.
>>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Jason
>>>>> 
>>>>> ----------------------------------------------------------
>>>>> Jason van Zyl
>>>>> Founder,  Apache Maven
>>>>> http://twitter.com/jvanzyl
>>>>> ---------------------------------------------------------
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>> 
>>>> 
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

Re: Model Version 5.0.0

Posted by Benson Margulies <bi...@gmail.com>.

It seems to me that this thread is mixing two topics.

Topic #1: How to we move to pom 5.0, given a giant ecosystem of crappy
XML-parsing POM consumers?

Topic #2: To what extent does the pom mix a 'description of contract'
(dependencies, etc) with a 'specification of build'?

On the first topic, there was a wiki page months ago that explored a
scheme for writing both a v4 pom and a v5 pom when deploying from a v5
project, so that old tools could see and consume what they understand.
To the extent that this scheme made sense, it can be adopted without
(necessarily) touching the second.

On the second topic, I'm in agreement that there should be a clear
separation between describing a contract and other things. For
example, why is it a good idea for deployed poms to reference parents,
rather than being self-contained? Why is it a good idea for deployed
poms to include profiles? Why is it a good thing for deployed poms to
include parameter references, thereby in some cases accidently
changing their semantics due to collisions with the consuming
application's pom? The full 'here's how to build' pom, in my view, is
part of the source, and should be deployed with the source, and any
tool that can usefully analyze the details (plugins, pluginManagement,
etc) is welcome to do so. Having written this, it also seems to me
that one compromise could be that v5 deployed poms could be
self-contained, complete, but organized so as be clear as to the two
categories of contents.



On Sun, Nov 24, 2013 at 9:29 AM, Igor Fedorenko <ig...@ifedorenko.com> wrote:
> I think we are saying the same thing -- we evolve project model used
> during the build but deploy both the new and backwards compatible models.
>
> One quick note on representing dependencies as provided/required
> capabilities. Although I like this idea in general, I believe it will
> require completely new repository layout to be able to efficiently
> find capability providers. Single repository-wide metadata index file,
> the approach implemented in P2 for example, won't scale for repositories
> of the size of Central, so most likely the new repository layout will
> require active server-side component to assist dependency resolution.
>
> --
> Regards,
> Igor
>
>
> On 11/24/2013, 4:25, Stephen Connolly wrote:
>>
>> On Sunday, 24 November 2013, Igor Fedorenko wrote:
>>
>>>
>>>
>>> On 11/23/2013, 23:08, Jason van Zyl wrote:
>>>
>>>>
>>>> On Nov 23, 2013, at 5:44 PM, Stephen Connolly
>>>> <st...@gmail.com> wrote:
>>>>
>>>>   Before I forget, here are some of my thoughts on moving towards
>>>>>
>>>>> Model Version 5.0.0
>>>>>
>>>>> The pom that we build with need not be the pom that gets
>>>>> deployed... thus the pom that is built with need not be the same
>>>>> format as the pom that gets deployed.
>>>>>
>>>>>
>>>> Can you explain why you think this is useful? To me all the
>>>> information that is carried with the POM after deployment is
>>>> primarily for the consumption of tools, and there are a lot of tools
>>>> that expect more than the dependency information. Removing all other
>>>> elements in the POM is equivalent to being massively backward
>>>> incompatible for an API. And if the subsequent consumption after
>>>> deployment is primarily by programs, then why does it matter what
>>>> gets deployed. I don't really see much benefit, but will create all
>>>> sorts of technical problems where we need multiple readers and all
>>>> that entails and the massive number of problems this will cause
>>>> people who have created tooling, especially IDE integration. >
>>>>
>>>
>>> The way I see it, what is deployed describes how the artifact needs to
>>> be consumed. This is artifact's "public API", if you will, it will be
>>> consumed by wide range of tools that resolve dependencies from Maven
>>> repositories and descriptor format should be very stable. Mostly likely
>>> we have no choice but use (a subset of) the current 4.0.0 model version.
>>
>>
>>
>> I would be very sad if we are limited to a subset.
>>
>> There are some critical concepts that in my view are missing from pom
>> files.
>>
>> Number one on my hit list is a <provides> concept.
>>
>> Where you declare that an artifact *provides* the same api as another GAV.
>>
>> Technically you'd need to be able to specify this both at the root of a
>> pom
>> and also flag specific dependencies (because the api they provide was not
>> specified when that pom was deployed)
>>
>> Thus the Geronimo specs poms could all <provides> the corresponding JavaEE
>> specs and excludes issues or other hacks would no longer be required.
>>
>> Look at the issues you will have if you use the excludes wildcards in your
>> pom... Namely *anyone* who uses your artifact as a dependency will need to
>> be using Maven 3 or newer... does ivy read those wildcards correctly? Does
>> sbt? Does Buildr?
>>
>> They are a tempting siren... And from another PoV they will force others
>> to
>> follow... *but* if we are forcing them to follow should we not pick a
>> nicer
>> format to follow... Not one consisting of many layers of hacks?
>>
>> The modelVersion 4.0.0 pom is deployed to the repo (in my scheme) so that
>> legacy clients can still make some sense... If a modelVersion 5.0.0
>> feature
>> cannot be mapped down to 4.0.0... Well we try our best and that's what you
>> get... We should make it sure that people stuck with older clients can
>> read
>> something semi-sensible and then layer their hacks as normal to get the
>> behaviour they need.
>>
>> Thus <provides> (which is not a scope but a GAV) can be modelled by having
>> the modelVersion 4.0.0 pom list the collapsed dependencies with the
>> appropriate <excludes> added (without wildcards)
>>
>> Other concepts cannot be mapped, so they get dropped.
>>
>>
>>> How the artifact is produced, on the other hand, is artifact's
>>> implementation detail. It is perfectly reasonable for a project to
>>> require minimal version of Maven, for example. Or use completely
>>> different format, not related to pom at all.
>>
>>
>>
>> Exactly... The pom used to build can be written in JSON or whatever domain
>> specific DSL you want... We deploy a modelVersion 5.0.0 pom as XML because
>> it will be read my machines.
>>
>> Now for the reason I think deploying a pom as xml may be a good thing...
>> XSLT
>>
>> Suppose we specify a XSLT GAV that will down-map the pom to a modelVersion
>> 5.0.0 pom... Now we can actually deploy a modelVersion 7.3.5 pom to the
>> one
>> GAVCT and a modelVersion 5.0.0 client reads is, sees it is a modelVersion
>> that is not understood, sees the GAV of the XSLT, pulls it down and
>> transforms the model into the version it can parse
>>
>> Will it be able to parse all the info in the original pom? Nope... It's an
>> older client... Older clients should not expect to grok all the subtleties
>> of newer poms... But it should get the general shape
>>
>> In all of the above, <packaging>pom</packaging> is special... We just
>> deploy that as is in whatever format (JSON/DSL/XML/groovy/etc) as the
>> -build.pom
>>
>> So 4.0.0 => .pom
>> 5.0.0 onward (XSLT down versioning) => -dep.pom
>> And as a parent =< -build.pom
>>
>> Modern clients can ask for the -dep.pom first... And fall back to the .pom
>>
>> It's not perfect, but it should not be the hell of 3.0.0->4.0.0 the fear
>> of
>> which has prevented forward progress since
>>
>>
>>> By separating "consumption" and "production" metadata formats, we'll be
>>> able to evolve production format more aggressively. For example, it
>>> would be nice to have Tycho-specific configuration markup inside <build>
>>> section. This is not currently possible because all poms must be
>>> compatible with the same model.
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>>
>>>
>>>   Only with <packaging>pom</packaging> do we actually need things like
>>> the
>>>>>
>>>>> <plugins> section in the deployed pom, because it is a reality that for
>>>>> noo-pom packaging we just want the transitive dependencies.
>>>>>
>>>>> Now there is the <extensions> issue where you might be registering a
>>>>> different file type that has different rules with respect to the
>>>>> classpath... but I am unsure if we actually consider those when
>>>>> evaluating
>>>>> the dependency tree... and in any case, once we accept that the
>>>>> deployed
>>>>> pom is not the same as the pom used to build (for non-pom packaging at
>>>>> least) we can transform that dependency tree using the exact rules that
>>>>> have to be known at build time thus closing the extensions issue.
>>>>>
>>>>> For projects with <packaging>pom</packaging> in fact we are only
>>>>> deploying
>>>>> smal files so perhaps we can deploy two pom files... the one that
>>>>> exposes
>>>>> the standard dependency stuff and then a second one that is used for
>>>>> build
>>>>> inheritance.
>>>>>
>>>>> My vision is thus that we deploy between 2 and three pom files for
>>>>> every
>>>>> project.
>>>>>
>>>>> For jar/war/ear/... we deploy:
>>>>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
>>>>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but
>>>>> allows
>>>>> for new scopes)
>>>>>
>>>>> For pom we deploy
>>>>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
>>>>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but
>>>>> allows
>>>>> for new scopes)
>>>>> * the pom itself
>>>>>
>>>>> When building a pom, your parent pom must be of a modelVersion <= your
>>>>> modelVersion.
>>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder,  Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> ---------------------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Model Version 5.0.0

Posted by Igor Fedorenko <ig...@ifedorenko.com>.

I think we are saying the same thing -- we evolve project model used
during the build but deploy both the new and backwards compatible models.

One quick note on representing dependencies as provided/required
capabilities. Although I like this idea in general, I believe it will
require completely new repository layout to be able to efficiently
find capability providers. Single repository-wide metadata index file,
the approach implemented in P2 for example, won't scale for repositories
of the size of Central, so most likely the new repository layout will
require active server-side component to assist dependency resolution.

--
Regards,
Igor

On 11/24/2013, 4:25, Stephen Connolly wrote:
> On Sunday, 24 November 2013, Igor Fedorenko wrote:
>
>>
>>
>> On 11/23/2013, 23:08, Jason van Zyl wrote:
>>
>>>
>>> On Nov 23, 2013, at 5:44 PM, Stephen Connolly
>>> <st...@gmail.com> wrote:
>>>
>>>   Before I forget, here are some of my thoughts on moving towards
>>>> Model Version 5.0.0
>>>>
>>>> The pom that we build with need not be the pom that gets
>>>> deployed... thus the pom that is built with need not be the same
>>>> format as the pom that gets deployed.
>>>>
>>>>
>>> Can you explain why you think this is useful? To me all the
>>> information that is carried with the POM after deployment is
>>> primarily for the consumption of tools, and there are a lot of tools
>>> that expect more than the dependency information. Removing all other
>>> elements in the POM is equivalent to being massively backward
>>> incompatible for an API. And if the subsequent consumption after
>>> deployment is primarily by programs, then why does it matter what
>>> gets deployed. I don't really see much benefit, but will create all
>>> sorts of technical problems where we need multiple readers and all
>>> that entails and the massive number of problems this will cause
>>> people who have created tooling, especially IDE integration. >
>>>
>>
>> The way I see it, what is deployed describes how the artifact needs to
>> be consumed. This is artifact's "public API", if you will, it will be
>> consumed by wide range of tools that resolve dependencies from Maven
>> repositories and descriptor format should be very stable. Mostly likely
>> we have no choice but use (a subset of) the current 4.0.0 model version.
>
>
> I would be very sad if we are limited to a subset.
>
> There are some critical concepts that in my view are missing from pom files.
>
> Number one on my hit list is a <provides> concept.
>
> Where you declare that an artifact *provides* the same api as another GAV.
>
> Technically you'd need to be able to specify this both at the root of a pom
> and also flag specific dependencies (because the api they provide was not
> specified when that pom was deployed)
>
> Thus the Geronimo specs poms could all <provides> the corresponding JavaEE
> specs and excludes issues or other hacks would no longer be required.
>
> Look at the issues you will have if you use the excludes wildcards in your
> pom... Namely *anyone* who uses your artifact as a dependency will need to
> be using Maven 3 or newer... does ivy read those wildcards correctly? Does
> sbt? Does Buildr?
>
> They are a tempting siren... And from another PoV they will force others to
> follow... *but* if we are forcing them to follow should we not pick a nicer
> format to follow... Not one consisting of many layers of hacks?
>
> The modelVersion 4.0.0 pom is deployed to the repo (in my scheme) so that
> legacy clients can still make some sense... If a modelVersion 5.0.0 feature
> cannot be mapped down to 4.0.0... Well we try our best and that's what you
> get... We should make it sure that people stuck with older clients can read
> something semi-sensible and then layer their hacks as normal to get the
> behaviour they need.
>
> Thus <provides> (which is not a scope but a GAV) can be modelled by having
> the modelVersion 4.0.0 pom list the collapsed dependencies with the
> appropriate <excludes> added (without wildcards)
>
> Other concepts cannot be mapped, so they get dropped.
>
>
>> How the artifact is produced, on the other hand, is artifact's
>> implementation detail. It is perfectly reasonable for a project to
>> require minimal version of Maven, for example. Or use completely
>> different format, not related to pom at all.
>
>
> Exactly... The pom used to build can be written in JSON or whatever domain
> specific DSL you want... We deploy a modelVersion 5.0.0 pom as XML because
> it will be read my machines.
>
> Now for the reason I think deploying a pom as xml may be a good thing...
> XSLT
>
> Suppose we specify a XSLT GAV that will down-map the pom to a modelVersion
> 5.0.0 pom... Now we can actually deploy a modelVersion 7.3.5 pom to the one
> GAVCT and a modelVersion 5.0.0 client reads is, sees it is a modelVersion
> that is not understood, sees the GAV of the XSLT, pulls it down and
> transforms the model into the version it can parse
>
> Will it be able to parse all the info in the original pom? Nope... It's an
> older client... Older clients should not expect to grok all the subtleties
> of newer poms... But it should get the general shape
>
> In all of the above, <packaging>pom</packaging> is special... We just
> deploy that as is in whatever format (JSON/DSL/XML/groovy/etc) as the
> -build.pom
>
> So 4.0.0 => .pom
> 5.0.0 onward (XSLT down versioning) => -dep.pom
> And as a parent =< -build.pom
>
> Modern clients can ask for the -dep.pom first... And fall back to the .pom
>
> It's not perfect, but it should not be the hell of 3.0.0->4.0.0 the fear of
> which has prevented forward progress since
>
>
>> By separating "consumption" and "production" metadata formats, we'll be
>> able to evolve production format more aggressively. For example, it
>> would be nice to have Tycho-specific configuration markup inside <build>
>> section. This is not currently possible because all poms must be
>> compatible with the same model.
>>
>> --
>> Regards,
>> Igor
>>
>>
>>
>>   Only with <packaging>pom</packaging> do we actually need things like the
>>>> <plugins> section in the deployed pom, because it is a reality that for
>>>> noo-pom packaging we just want the transitive dependencies.
>>>>
>>>> Now there is the <extensions> issue where you might be registering a
>>>> different file type that has different rules with respect to the
>>>> classpath... but I am unsure if we actually consider those when
>>>> evaluating
>>>> the dependency tree... and in any case, once we accept that the deployed
>>>> pom is not the same as the pom used to build (for non-pom packaging at
>>>> least) we can transform that dependency tree using the exact rules that
>>>> have to be known at build time thus closing the extensions issue.
>>>>
>>>> For projects with <packaging>pom</packaging> in fact we are only
>>>> deploying
>>>> smal files so perhaps we can deploy two pom files... the one that exposes
>>>> the standard dependency stuff and then a second one that is used for
>>>> build
>>>> inheritance.
>>>>
>>>> My vision is thus that we deploy between 2 and three pom files for every
>>>> project.
>>>>
>>>> For jar/war/ear/... we deploy:
>>>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
>>>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but allows
>>>> for new scopes)
>>>>
>>>> For pom we deploy
>>>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
>>>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but allows
>>>> for new scopes)
>>>> * the pom itself
>>>>
>>>> When building a pom, your parent pom must be of a modelVersion <= your
>>>> modelVersion.
>>>>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Model Version 5.0.0

Posted by Stephen Connolly <st...@gmail.com>.

On Sunday, 24 November 2013, Igor Fedorenko wrote:

>
>
> On 11/23/2013, 23:08, Jason van Zyl wrote:
>
>>
>> On Nov 23, 2013, at 5:44 PM, Stephen Connolly
>> <st...@gmail.com> wrote:
>>
>>  Before I forget, here are some of my thoughts on moving towards
>>> Model Version 5.0.0
>>>
>>> The pom that we build with need not be the pom that gets
>>> deployed... thus the pom that is built with need not be the same
>>> format as the pom that gets deployed.
>>>
>>>
>> Can you explain why you think this is useful? To me all the
>> information that is carried with the POM after deployment is
>> primarily for the consumption of tools, and there are a lot of tools
>> that expect more than the dependency information. Removing all other
>> elements in the POM is equivalent to being massively backward
>> incompatible for an API. And if the subsequent consumption after
>> deployment is primarily by programs, then why does it matter what
>> gets deployed. I don't really see much benefit, but will create all
>> sorts of technical problems where we need multiple readers and all
>> that entails and the massive number of problems this will cause
>> people who have created tooling, especially IDE integration. >
>>
>
> The way I see it, what is deployed describes how the artifact needs to
> be consumed. This is artifact's "public API", if you will, it will be
> consumed by wide range of tools that resolve dependencies from Maven
> repositories and descriptor format should be very stable. Mostly likely
> we have no choice but use (a subset of) the current 4.0.0 model version.

I would be very sad if we are limited to a subset.

There are some critical concepts that in my view are missing from pom files.

Number one on my hit list is a <provides> concept.

Where you declare that an artifact *provides* the same api as another GAV.

Technically you'd need to be able to specify this both at the root of a pom
and also flag specific dependencies (because the api they provide was not
specified when that pom was deployed)

Thus the Geronimo specs poms could all <provides> the corresponding JavaEE
specs and excludes issues or other hacks would no longer be required.

Look at the issues you will have if you use the excludes wildcards in your
pom... Namely *anyone* who uses your artifact as a dependency will need to
be using Maven 3 or newer... does ivy read those wildcards correctly? Does
sbt? Does Buildr?

They are a tempting siren... And from another PoV they will force others to
follow... *but* if we are forcing them to follow should we not pick a nicer
format to follow... Not one consisting of many layers of hacks?

The modelVersion 4.0.0 pom is deployed to the repo (in my scheme) so that
legacy clients can still make some sense... If a modelVersion 5.0.0 feature
cannot be mapped down to 4.0.0... Well we try our best and that's what you
get... We should make it sure that people stuck with older clients can read
something semi-sensible and then layer their hacks as normal to get the
behaviour they need.

Thus <provides> (which is not a scope but a GAV) can be modelled by having
the modelVersion 4.0.0 pom list the collapsed dependencies with the
appropriate <excludes> added (without wildcards)

Other concepts cannot be mapped, so they get dropped.

> How the artifact is produced, on the other hand, is artifact's
> implementation detail. It is perfectly reasonable for a project to
> require minimal version of Maven, for example. Or use completely
> different format, not related to pom at all.

Exactly... The pom used to build can be written in JSON or whatever domain
specific DSL you want... We deploy a modelVersion 5.0.0 pom as XML because
it will be read my machines.

Now for the reason I think deploying a pom as xml may be a good thing...
XSLT

Suppose we specify a XSLT GAV that will down-map the pom to a modelVersion
5.0.0 pom... Now we can actually deploy a modelVersion 7.3.5 pom to the one
GAVCT and a modelVersion 5.0.0 client reads is, sees it is a modelVersion
that is not understood, sees the GAV of the XSLT, pulls it down and
transforms the model into the version it can parse

Will it be able to parse all the info in the original pom? Nope... It's an
older client... Older clients should not expect to grok all the subtleties
of newer poms... But it should get the general shape

In all of the above, <packaging>pom</packaging> is special... We just
deploy that as is in whatever format (JSON/DSL/XML/groovy/etc) as the
-build.pom

So 4.0.0 => .pom
5.0.0 onward (XSLT down versioning) => -dep.pom
And as a parent =< -build.pom

Modern clients can ask for the -dep.pom first... And fall back to the .pom

It's not perfect, but it should not be the hell of 3.0.0->4.0.0 the fear of
which has prevented forward progress since

> By separating "consumption" and "production" metadata formats, we'll be
> able to evolve production format more aggressively. For example, it
> would be nice to have Tycho-specific configuration markup inside <build>
> section. This is not currently possible because all poms must be
> compatible with the same model.
>
> --
> Regards,
> Igor
>
>
>
>  Only with <packaging>pom</packaging> do we actually need things like the
>>> <plugins> section in the deployed pom, because it is a reality that for
>>> noo-pom packaging we just want the transitive dependencies.
>>>
>>> Now there is the <extensions> issue where you might be registering a
>>> different file type that has different rules with respect to the
>>> classpath... but I am unsure if we actually consider those when
>>> evaluating
>>> the dependency tree... and in any case, once we accept that the deployed
>>> pom is not the same as the pom used to build (for non-pom packaging at
>>> least) we can transform that dependency tree using the exact rules that
>>> have to be known at build time thus closing the extensions issue.
>>>
>>> For projects with <packaging>pom</packaging> in fact we are only
>>> deploying
>>> smal files so perhaps we can deploy two pom files... the one that exposes
>>> the standard dependency stuff and then a second one that is used for
>>> build
>>> inheritance.
>>>
>>> My vision is thus that we deploy between 2 and three pom files for every
>>> project.
>>>
>>> For jar/war/ear/... we deploy:
>>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
>>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but allows
>>> for new scopes)
>>>
>>> For pom we deploy
>>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
>>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but allows
>>> for new scopes)
>>> * the pom itself
>>>
>>> When building a pom, your parent pom must be of a modelVersion <= your
>>> modelVersion.
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

-- 
Sent from my phone

Re: Model Version 5.0.0

Posted by Mark Derricutt <ma...@talios.com>.

This may be throwing gasoline onto an already burning fire but a thought occurred to me over the weekend, if we're going to go to the extend of changing the POM formats, this quite majorly affects repository browsers/servers/indexers etc.

I was wondering if this doesn't also require a change in the repository type as well ( I need to read thru all the threads to see whats been suggested or not ), are we planning to mix/match the new poms with the old?

I was also thinking it might be timely to rematch various videos about problems with maven, sbt, gradle and even maybe totally rethink the repository layout, servers etc. etc. of course, thats a much more epic set of changes ;p

On 2 Dec 2013, at 6:07, Brian Fox wrote:

> It means we can more easily make changes to the production side, where most
> features are desired, without worrying about the impacts on consumption via
> older tools. That is to say specifically that a team can decide to move to
> a new version of Maven and adjust their pom accordingly without affecting
> downstream users. I think this is the very reason we are still locked on
> 4.0.0 all these years later.

Re: Model Version 5.0.0

Posted by Brian Fox <br...@infinity.nu>.

On Sat, Nov 23, 2013 at 11:47 PM, Igor Fedorenko <ig...@ifedorenko.com>wrote:

> The way I see it, what is deployed describes how the artifact needs to
> be consumed. This is artifact's "public API", if you will, it will be
> consumed by wide range of tools that resolve dependencies from Maven
> repositories and descriptor format should be very stable. Mostly likely
> we have no choice but use (a subset of) the current 4.0.0 model version.
>
> How the artifact is produced, on the other hand, is artifact's
> implementation detail. It is perfectly reasonable for a project to
> require minimal version of Maven, for example. Or use completely
> different format, not related to pom at all.
>
> By separating "consumption" and "production" metadata formats, we'll be
> able to evolve production format more aggressively. For example, it
> would be nice to have Tycho-specific configuration markup inside <build>
> section. This is not currently possible because all poms must be
> compatible with the same model.
>

+1.

It means we can more easily make changes to the production side, where most
features are desired, without worrying about the impacts on consumption via
older tools. That is to say specifically that a team can decide to move to
a new version of Maven and adjust their pom accordingly without affecting
downstream users. I think this is the very reason we are still locked on
4.0.0 all these years later.

Obviously things like dependency resolution and properties would need to be
in the consumer side.

Re: Model Version 5.0.0

Posted by Jason van Zyl <ja...@tesla.io>.

If we were to have the separation we would need another implementation of an ArtifactDescriptorReader which turns our representation, the POM, into Aether's internal representation for the abbreviated format. I need to check as I'm not sure without looking what happens when you have multiple ArtifactDescriptorReaders. Probably not hard to change it to support multiple if it doesn't already.

On Nov 29, 2013, at 11:31 AM, Robert Scholte <rf...@apache.org> wrote:

> Correct me if I'm wrong, but IIUC in the end it is Aether which collects all the dependencies.
> Aether is probably only interested in the <dependency>, <dependencyManagement> and <parent>-tags.
> What if we move the responsibility of the consumer-model to Aether as well?
> Do we want this? What are the thoughts of the Aether-team?
> 
> Robert
> 
> Op Sun, 24 Nov 2013 22:31:54 +0100 schreef Hervé BOUTEMY <he...@free.fr>:
> 
>> Le dimanche 24 novembre 2013 10:26:13 Jason van Zyl a écrit :
>>> On Nov 24, 2013, at 12:19 AM, Manfred Moser <ma...@mosabuam.com> wrote:
>>> >> By separating "consumption" and "production" metadata formats, we'll be
>>> >> able to evolve production format more aggressively. For example, it
>>> >> would be nice to have Tycho-specific configuration markup inside <build>
>>> >> section. This is not currently possible because all poms must be
>>> >> compatible with the same model.
>>> >
>>> > I like the idea of consumptions specifics. It would be great if we could
>>> > agree/define some sort of standard on how to declare suitability for
>>> > artifacts for certain deployment scenarios ..
>>> 
>>> I don't believe this requires separate documents to support this.
>> 
>> true, this does not require separate documents
>> 
>> but having separate documents helps separating concerns: building a project vs
>> consuming its artifacts
>> 
>> and descriptor for consuption will be:
>> - a lot shorter than descriptor for building: not any plugin, for example
>> - build-agnostic
>> 
>> I'm pretty sure that separating descriptors will help us move forward and even
>> better design things
>> 
>> Regards,
>> 
>> Hervé
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

Re: Model Version 5.0.0

Posted by Robert Scholte <rf...@apache.org>.

Correct me if I'm wrong, but IIUC in the end it is Aether which collects  
all the dependencies.
Aether is probably only interested in the <dependency>,  
<dependencyManagement> and <parent>-tags.
What if we move the responsibility of the consumer-model to Aether as well?
Do we want this? What are the thoughts of the Aether-team?

Robert

Op Sun, 24 Nov 2013 22:31:54 +0100 schreef Hervé BOUTEMY  
<he...@free.fr>:

> Le dimanche 24 novembre 2013 10:26:13 Jason van Zyl a écrit :
>> On Nov 24, 2013, at 12:19 AM, Manfred Moser <ma...@mosabuam.com>  
>> wrote:
>> >> By separating "consumption" and "production" metadata formats, we'll  
>> be
>> >> able to evolve production format more aggressively. For example, it
>> >> would be nice to have Tycho-specific configuration markup inside  
>> <build>
>> >> section. This is not currently possible because all poms must be
>> >> compatible with the same model.
>> >
>> > I like the idea of consumptions specifics. It would be great if we  
>> could
>> > agree/define some sort of standard on how to declare suitability for
>> > artifacts for certain deployment scenarios ..
>>
>> I don't believe this requires separate documents to support this.
>
> true, this does not require separate documents
>
> but having separate documents helps separating concerns: building a  
> project vs
> consuming its artifacts
>
> and descriptor for consuption will be:
> - a lot shorter than descriptor for building: not any plugin, for example
> - build-agnostic
>
> I'm pretty sure that separating descriptors will help us move forward  
> and even
> better design things
>
> Regards,
>
> Hervé
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Model Version 5.0.0

Posted by Hervé BOUTEMY <he...@free.fr>.

Le dimanche 24 novembre 2013 10:26:13 Jason van Zyl a écrit :
> On Nov 24, 2013, at 12:19 AM, Manfred Moser <ma...@mosabuam.com> wrote:
> >> By separating "consumption" and "production" metadata formats, we'll be
> >> able to evolve production format more aggressively. For example, it
> >> would be nice to have Tycho-specific configuration markup inside <build>
> >> section. This is not currently possible because all poms must be
> >> compatible with the same model.
> > 
> > I like the idea of consumptions specifics. It would be great if we could
> > agree/define some sort of standard on how to declare suitability for
> > artifacts for certain deployment scenarios ..
> 
> I don't believe this requires separate documents to support this.

true, this does not require separate documents

but having separate documents helps separating concerns: building a project vs 
consuming its artifacts

and descriptor for consuption will be:
- a lot shorter than descriptor for building: not any plugin, for example
- build-agnostic

I'm pretty sure that separating descriptors will help us move forward and even 
better design things

Regards,

Hervé


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Model Version 5.0.0

Posted by Stephen Connolly <st...@gmail.com>.

On Monday, 25 November 2013, Barrie Treloar wrote:

> On 25 November 2013 20:32, Stephen Connolly
> <stephen.alan.connolly@gmail.com <javascript:;>> wrote:
> > be able to generate a pom for 4.0.0 clients that contains some of the
> > bug/features that some people seem to rely on, e.g. ${} expansion in
> > <dependencies>... but we don't need to maintain such guarantees when we
> > have a new schema.
>
> If there is a better way, then we should promote that and stop the broken
> way.

I was just addressing an issue with an example.... Perhaps I should have
been more explicit in the stating of the problem class

One of the points raised when evolution is considered is that there is a
bulk of projects that use hack A in order to achieve result X.

With a modelVersion 5.0.0 pom you will no longer be able to express hack A
but we will give a better way to achieve X (or we stick to our opinionated
flag and declare X as being a bad plan anyway and Y is actually what you
want)

In this class of problems, use if EL expansion in the <dependencies>
section is a common type of hack...

When experiments were made deploying resolved poms before (eg 2.1.0 or
2.2.0 I cannot recall which) it was found that the EL hacks were actually
being used for their side-effects... When the GPG signing problem was added
on top, the decision was to step back.

The point I am baking is that with modelVersion 5.0.0 we can revisit as we
can assume Maven 4.0.0+ for parsers only and thus maintain the *new*
contract.

If Maven 4.0.0 is building a modelVersion 4.0.0 pom then it will have to
deploy, bugs and all, the old pom in its entirety to keep backwards
compat... But we can retrofit .dml deployment onto the install and deploy
plugins so that a .dml gets deployed also (since that is an up-convert)

> > * There are valid cases where a parent pom can include a set of
> > dependencies that are common to all child projects. It may not be a style
> > that I like, but just as I am not going to give out if somebody writes
> > their *project* and has the idiotic idea of using TABs to indent (I'll
> moan
> > if I have to make a contribution to their project though) I do not think
> we
> > should prevent such a use case. Additionally, and perhaps more
> importantly,
> > there can be side artifacts for a pom packaging. Thus we really should be
> > publishing a .dml file for the parent. Most likely it will be empty (we
> > don't need <dependencyManagement> because .dml files *never* include a
> > parent reference) but the file is needed for any side-artifacts
>
> I think this is an area of confusion.
> There is a difference between a parent pom and a dependency inheritance
> pom.
> Too many times I've seen the parent pom have something "common" only
> to find out its not common in this grand-child over here.
> As above, If there is a better way we should be promoting that and
> stopping the broken way.

Well that is a different story... Mixins may be a different case also...
Schema change allows for Mixins too though ;-)

>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>

-- 
Sent from my phone

Re: Model Version 5.0.0

Posted by Barrie Treloar <ba...@gmail.com>.

On 25 November 2013 20:32, Stephen Connolly
<st...@gmail.com> wrote:
> be able to generate a pom for 4.0.0 clients that contains some of the
> bug/features that some people seem to rely on, e.g. ${} expansion in
> <dependencies>... but we don't need to maintain such guarantees when we
> have a new schema.

If there is a better way, then we should promote that and stop the broken way.

> * There are valid cases where a parent pom can include a set of
> dependencies that are common to all child projects. It may not be a style
> that I like, but just as I am not going to give out if somebody writes
> their *project* and has the idiotic idea of using TABs to indent (I'll moan
> if I have to make a contribution to their project though) I do not think we
> should prevent such a use case. Additionally, and perhaps more importantly,
> there can be side artifacts for a pom packaging. Thus we really should be
> publishing a .dml file for the parent. Most likely it will be empty (we
> don't need <dependencyManagement> because .dml files *never* include a
> parent reference) but the file is needed for any side-artifacts

I think this is an area of confusion.
There is a difference between a parent pom and a dependency inheritance pom.
Too many times I've seen the parent pom have something "common" only
to find out its not common in this grand-child over here.
As above, If there is a better way we should be promoting that and
stopping the broken way.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Model Version 5.0.0

Posted by Stephen Connolly <st...@gmail.com>.

First off, and this is addressed at drive-by readers, most everyone else
knows me well enough to know this anyway. I may be the PMC chair, but
99.99% of the things I say are not said as the PMC chair, instead they are
said as a committer to the project who is interested in the current and
future health. I do not have any extra special influence. (If I *were*
stating something as PMC chair it would be sent from my apache account and
I would put on the hat with a phrase such as "as PMC chair"... and it would
probably only be to resolve a stalemate in a technical choice that had
stalemated both the committers and the PMC and was threatening the
reputation of the ASF... i.e. the board would likely be watching closely...
)

On 25 November 2013 07:46, Kristian Rosenvold
<kr...@gmail.com>wrote:

> IMO publishing to central/acrhiva would involve publishing the "richest"
> format available. Based on use-agent identification (or lack of a given
> request param indicating old-style client) the repository should be able to
> down-transform a v5 pom to a v4 pom "on the fly" ?

How would that handle GPG signatures of the pom file? If you allow for
on-the-fly transformation then you loose the GPG signature immediately. The
dependency information of a pom is critical to maintaining the integrity of
the actual file. For example if you can modify the pom file you can replace
one dependency with another that you control and gives you a hook with
which to inject malicious code.

I see that as a credible risk. For sure we have been less than awesome at
providing users with the tools to verify the GPG signatures of resolved
artifacts and pom files... but that does not mean we should mandate that
the repository adopt technologies that render such tooling impossible to
achieve.

> We're not going to be
> losing semantic
> backward compatibility on any of the changes I've seen suggested yet ?
>

I think every change has a mapping back to modelVersion 4.0.0... not every
change will have a complete mapping back to modelVersion 4.0.0... or to put
it another way, we can transform 5.0.0 to 4.0.0... and similarly as the
5.0.0 model would be an extension of 4.0.0 we can extend it up... but 5.0.0
-> 4.0.0 -> 5.0.0 would loose information on the down transform... 5.0.0 is
a double and 4.0.0 is a float (3.0.0 is an unsigned long ;-) )

>
> Also, did I miss the bit where someone explained why the whole "how to
> build" section cannot be stripped away upon publication ? I don't
> understand why that means we need multuiple files.
>

Lets say, for sake of argument, that we decide to go with the build vs
dependency-consumer split.

When you checkout your source tree you will see something like

pom.xml (or pom.json or whatever format we decide for *building*)

So what do we deploy to the repo... well for org.machu.foo:foobar:1.0

* We have to publish a file that is parsable by 4.0.0 readers... otherwise
we limit consumers of our artifact to those using a client that understands
the new format... that would be bad... so foobar-1.0.pom gets published...
it's a modelVersion 4.0.0 pom. *Because* we are publishing this for
*consumers of the artifact* it does not need any build information. We can
strip all that cruft out and just provide the <dependencies>. Further we
can resolve *all* versions to pinned explicit versions and strip out scopes
that do not make sense for consumers, e.g. `test`. We can even add
exclusions based on the complete tree (which would allow removing
`provided` scope dependencies as well as being necessary for the `provides`
extra semantic information I want to see added). None of these changes will
break existing clients. It does mean that a modelVersion 5.0.0 pom will not
be able to generate a pom for 4.0.0 clients that contains some of the
bug/features that some people seem to rely on, e.g. ${} expansion in
<dependencies>... but we don't need to maintain such guarantees when we
have a new schema.

* We want to be able to expose the new dependency model information to
consumers that can understand such information... so lets publish that
information as a (briefly searches for relatively unused file extensions...
Dependency ModeL... ok) .dml file. This file will contain the dependencies,
extra semantic information such as provides, etc. Again it would be fully
resolved and not contain a reference to a parent .dml file. In other words,
once you get that file you have everything needed to parse that file (well
except perhaps for a transformation mapping to down-map the file into a
format you *can* parse... my XSLT idea)

* Finally we have the artifact itself, foobar-1.0.jar and all the gpg
signature and the .md5 hashes and .sha1 hashes... (we could argue only the
gpg signatures are needed... but older clients rely on the hashes, so we
cannot really break them... though a good repository manager could
certainly generate them if the gpg signatures verify)

So the complete list in this scheme

foobar-1.0.pom
foobar-1.0.pom.gpg
foobar-1.0.pom.md5
foobar-1.0.pom.sha1
foobar-1.0.pom.gpg.sha1
foobar-1.0.pom.gpg.md5
foobar-1.0.dml
foobar-1.0.dml.gpg
foobar-1.0.dml.md5 (could perhaps omit as only new clients will read this)
foobar-1.0.dml.sha1 (could perhaps omit as only new clients will read this)
foobar-1.0.dml.gpg.sha1 (could perhaps omit as only new clients will read
this)
foobar-1.0.dml.gpg.md5 (could perhaps omit as only new clients will read
this)
foobar-1.0.jar
foobar-1.0.jar.gpg
foobar-1.0.jar.md5
foobar-1.0.jar.sha1
foobar-1.0.jar.gpg.sha1
foobar-1.0.jar.gpg.md5

So that is all fine and dandy...

Now we refactor the build, introducing a common parent pom,
foobar-parent... what do we need to publish for that?

* Well my first "get out of jail" card is to mandate that when building,
you cannot use a parent pom that has a *newer* modelVersion than the child
pom. Thus we do not have to worry about people using Maven 3.2 and trying
to use foobar-parent:1.0 as their parent pom. We set the <prerequisites> in
the deployed modelVersion 4.0.0 pom to the required version of Maven and we
inject an enforcer rule bound to the `validate` phase that immediately
fails the build with a message stating that you cannot use it as a parent.

  Thus even if you use Maven 4.0.0 to build a modelVersion 4.0.0 pom, you
still will not be able to have a modelVersion 5.0.0 parent. I think this is
reasonable, as we cannot expect to fully down-map the dependency features
let alone the build features.

  So we are deploying a *generated* modelVersion 4.0.0 pom as
foobar-parent-1.0.pom which is stripped to just effective dependencies (etc
as for the jar) and has a <build> section that causes anyone who tries to
use it as a parent pom from a pre-maven 4.0.0 format pom to get an
immediate build failure.

* There are valid cases where a parent pom can include a set of
dependencies that are common to all child projects. It may not be a style
that I like, but just as I am not going to give out if somebody writes
their *project* and has the idiotic idea of using TABs to indent (I'll moan
if I have to make a contribution to their project though) I do not think we
should prevent such a use case. Additionally, and perhaps more importantly,
there can be side artifacts for a pom packaging. Thus we really should be
publishing a .dml file for the parent. Most likely it will be empty (we
don't need <dependencyManagement> because .dml files *never* include a
parent reference) but the file is needed for any side-artifacts

* What about people using this project *as a parent*... we need to deploy
something for them... we can assume they will be able to understand our
modelVersion and format (because we have used that get out of jail card
already to prevent the modelVersion 4.0.0 children), so lets just deploy
the pom with a classifier of build

foobar-parent-1.0.pom
foobar-parent-1.0.pom.gpg
foobar-parent-1.0.pom.md5
foobar-parent-1.0.pom.sha1
foobar-parent-1.0.pom.gpg.sha1
foobar-parent-1.0.pom.gpg.md5
foobar-parent-1.0-build.pom
foobar-parent-1.0-build.pom.gpg
foobar-parent-1.0-build.pom.md5 (could perhaps omit as only new clients
will read this)
foobar-parent-1.0-build.pom.sha1 (could perhaps omit as only new clients
will read this)
foobar-parent-1.0-build.pom.gpg.sha1 (could perhaps omit as only new
clients will read this)
foobar-parent-1.0-build.pom.gpg.md5 (could perhaps omit as only new clients
will read this)
foobar-parent-1.0.dml
foobar-parent-1.0.dml.gpg
foobar-parent-1.0.dml.md5 (could perhaps omit as only new clients will read
this)
foobar-parent-1.0.dml.sha1 (could perhaps omit as only new clients will
read this)
foobar-parent-1.0.dml.gpg.sha1 (could perhaps omit as only new clients will
read this)
foobar-parent-1.0.dml.gpg.md5 (could perhaps omit as only new clients will
read this)
foobar-1.0-src.tar.gz (illustrating the most common side-artifact for pom
projects)
foobar-1.0-src.tar.gz.gpg
foobar-1.0-src.tar.gz.md5
foobar-1.0-src.tar.gz.sha1
foobar-1.0-src.tar.gz.gpg.sha1
foobar-1.0-src.tar.gz.gpg.md5

That is my view of *one way* to get to modelVersion 5.0.0. I think that
*technically* the above could work. There are issues:

* Newer clients will go looking for the .dml file and then fall back to the
.pom if the .dml is missing... that makes 5 requests (.dml, .pom, .pom.gpg,
.jar, .jar.gpg - or replace .gpg with whatever hash you want) to get a .jar
file rather than 4, in other words a 20% increase in requests for older
artifacts... or 33% increase if you don't want integrity checks)... we
could do a bulk generation of the .dml files... but then we have to
generate gpg signatures for those files which would break the trust that
gpg is supposed to inject.

  Given that older clients currently go hunting for two hashes I think we
can ignore this issue, e.g. it's actually better than .pom, .pom.md5,
.pom.sha1, .jar, .jar.md5, .jar.sha1

  This would therefore be using the .gpg file as a download integrity check
and then optionally an additional check that users can choose to turn on
would be to check that the key used to sign is trusted.

* I am not sure how down-model versioning would work in reality. So the
idea here is that we say that the .dml file is a machine generated format.
It makes sense, to me, that this would be XML (because XSLT is cross
platform-ish). We would mandate that the first element be the
modelVersion.. could be via a namespace or an element... does not matter
too much for this.

  A parser thus reads the modelVersion easily. If it is a known
modelVersion... fine, proceed with the parse. If it is a newer modelVersion
then you go download org.apache.maven:model-mapping:${modelVersion}:xsl and
run the .dml through that transformation... lather rinse repeat until you
have a modelVersion that you understand...

  We would need to EITHER be very careful when publishing the XSLT files OR
relax the rules on re-downloading non-SNAPSHOTs for
org.apache.maven:model-mapping only (the later could produce irreproducible
builds though)

  In any case I think that is how we can allow for future evolution of the
.dml modelVersion (NOTE: this need not be the pom modelVersion...)... but
where we have the greater need for schema change is on the build side not
on the dependency list side... so I think it should not be too much of a
concern... we just have to be very careful with .dml schema changes.

What does this get us?

* It lets us change the build schema

* It lets us change the build format... the pom need not be XML any more

In short, it frees us up to change.

Is this the only way? Nope... it is the best way I can think of... I hope
that somebody has a better suggestion and I fear that this is the best...
but there certainly are a lot worse ways of evolving our schema

-Stephen

>
> I'm exposed to "the competition" at @dayjob these days, and I must say I
> think reducing verobosity and duplication is /the/ most important feture of
>  a v5 pom for me.
>
> Kristian
>
>

Re: Model Version 5.0.0

Posted by Kristian Rosenvold <kr...@gmail.com>.

IMO publishing to central/acrhiva would involve publishing the "richest"
format available. Based on use-agent identification (or lack of a given
request param indicating old-style client) the repository should be able to
down-transform a v5 pom to a v4 pom "on the fly" ? We're not going to be
losing semantic
backward compatibility on any of the changes I've seen suggested yet ?

Also, did I miss the bit where someone explained why the whole "how to
build" section cannot be stripped away upon publication ? I don't
understand why that means we need multuiple files.

I'm exposed to "the competition" at @dayjob these days, and I must say I
think reducing verobosity and duplication is /the/ most important feture of
 a v5 pom for me.

Kristian



2013/11/25 Manfred Moser <ma...@mosabuam.com>

> > On Sunday, 24 November 2013, Manfred Moser wrote:
> >
> >>
> >> > By separating "consumption" and "production" metadata formats, we'll
> >> be
> >> > able to evolve production format more aggressively. For example, it
> >> > would be nice to have Tycho-specific configuration markup inside
> >> <build>
> >> > section. This is not currently possible because all poms must be
> >> > compatible with the same model.
> >>
> >> I like the idea of consumptions specifics. It would be great if we could
> >> agree/define some sort of standard on how to declare suitability for
> >> artifacts for certain deployment scenarios ..
> >> e.g. it is jar suitable for Java 6, 7, 8, 9 or what, what about running
> >> on
> >> Android, or on some embedded Java version profile.
> >>
> >> I dont believe that the previous approaches of using classifiers is just
> >> not powerful enough. And I also agree that we should potentially just
> >> stick to the existing format.
> >>
> >> E.g. nothing stops us from declaring a standard for e.g. for a bunch of
> >> properties like
> >>
> >> <properties>
> >>  <runtime.android>true</runtime.android>
> >>  <runtime.java6>true</runtime.java6>
> >> </properties>
> >>
> >> or
> >> <properties>
> >>  <runtime.android>false</runtime.android>
> >>  <runtime.java6>false</runtime.java6>
> >>  <runtime.java7>true</runtime.java7>
> >> </properties>
> >>
> >>
> > How is that any different from having a modelVersion 5.0.0? (Other than
> > not
> > giving the benefit of a schema change)
>
>
> It probably isnt different ;-)
>
> manfred
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Model Version 5.0.0

Posted by Manfred Moser <ma...@mosabuam.com>.

> On Sunday, 24 November 2013, Manfred Moser wrote:
>
>>
>> > By separating "consumption" and "production" metadata formats, we'll
>> be
>> > able to evolve production format more aggressively. For example, it
>> > would be nice to have Tycho-specific configuration markup inside
>> <build>
>> > section. This is not currently possible because all poms must be
>> > compatible with the same model.
>>
>> I like the idea of consumptions specifics. It would be great if we could
>> agree/define some sort of standard on how to declare suitability for
>> artifacts for certain deployment scenarios ..
>> e.g. it is jar suitable for Java 6, 7, 8, 9 or what, what about running
>> on
>> Android, or on some embedded Java version profile.
>>
>> I dont believe that the previous approaches of using classifiers is just
>> not powerful enough. And I also agree that we should potentially just
>> stick to the existing format.
>>
>> E.g. nothing stops us from declaring a standard for e.g. for a bunch of
>> properties like
>>
>> <properties>
>>  <runtime.android>true</runtime.android>
>>  <runtime.java6>true</runtime.java6>
>> </properties>
>>
>> or
>> <properties>
>>  <runtime.android>false</runtime.android>
>>  <runtime.java6>false</runtime.java6>
>>  <runtime.java7>true</runtime.java7>
>> </properties>
>>
>>
> How is that any different from having a modelVersion 5.0.0? (Other than
> not
> giving the benefit of a schema change)


It probably isnt different ;-)

manfred

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Model Version 5.0.0

Posted by Stephen Connolly <st...@gmail.com>.

On Sunday, 24 November 2013, Manfred Moser wrote:

>
> > By separating "consumption" and "production" metadata formats, we'll be
> > able to evolve production format more aggressively. For example, it
> > would be nice to have Tycho-specific configuration markup inside <build>
> > section. This is not currently possible because all poms must be
> > compatible with the same model.
>
> I like the idea of consumptions specifics. It would be great if we could
> agree/define some sort of standard on how to declare suitability for
> artifacts for certain deployment scenarios ..
> e.g. it is jar suitable for Java 6, 7, 8, 9 or what, what about running on
> Android, or on some embedded Java version profile.
>
> I dont believe that the previous approaches of using classifiers is just
> not powerful enough. And I also agree that we should potentially just
> stick to the existing format.
>
> E.g. nothing stops us from declaring a standard for e.g. for a bunch of
> properties like
>
> <properties>
>  <runtime.android>true</runtime.android>
>  <runtime.java6>true</runtime.java6>
> </properties>
>
> or
> <properties>
>  <runtime.android>false</runtime.android>
>  <runtime.java6>false</runtime.java6>
>  <runtime.java7>true</runtime.java7>
> </properties>
>
>
How is that any different from having a modelVersion 5.0.0? (Other than not
giving the benefit of a schema change)

We still have to get the hoard of non-maven pom parsers to become aware of
these "conventions" and no xml schema to assist their correct
implementation... Plus we'd need to be sure we are not accidentally
introducing a keyword of "enum" that loads of people have used as a
variable name for their Enumerators...


> Of course we should put more thought into this but declaring a standard
> sooner rather than later could help a lot with the oncoming wave of
> libraries that will not work for Java 6 anymore and others going forward
> with e.g. Java 8 only and so on.
>
> Manfred
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>

-- 
Sent from my phone

Re: Model Version 5.0.0

Posted by Jason van Zyl <ja...@tesla.io>.

On Nov 24, 2013, at 12:19 AM, Manfred Moser <ma...@mosabuam.com> wrote:

> 
>> By separating "consumption" and "production" metadata formats, we'll be
>> able to evolve production format more aggressively. For example, it
>> would be nice to have Tycho-specific configuration markup inside <build>
>> section. This is not currently possible because all poms must be
>> compatible with the same model.
> 
> I like the idea of consumptions specifics. It would be great if we could
> agree/define some sort of standard on how to declare suitability for
> artifacts for certain deployment scenarios ..

I don't believe this requires separate documents to support this.

> e.g. it is jar suitable for Java 6, 7, 8, 9 or what, what about running on
> Android, or on some embedded Java version profile.
> 
> I dont believe that the previous approaches of using classifiers is just
> not powerful enough. And I also agree that we should potentially just
> stick to the existing format.
> 
> E.g. nothing stops us from declaring a standard for e.g. for a bunch of
> properties like
> 
> <properties>
> <runtime.android>true</runtime.android>
> <runtime.java6>true</runtime.java6>
> </properties>
> 
> or
> <properties>
> <runtime.android>false</runtime.android>
> <runtime.java6>false</runtime.java6>
> <runtime.java7>true</runtime.java7>
> </properties>
> 
> Of course we should put more thought into this but declaring a standard
> sooner rather than later could help a lot with the oncoming wave of
> libraries that will not work for Java 6 anymore and others going forward
> with e.g. Java 8 only and so on.
> 
> Manfred
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

Re: Model Version 5.0.0

Posted by Manfred Moser <ma...@mosabuam.com>.

> By separating "consumption" and "production" metadata formats, we'll be
> able to evolve production format more aggressively. For example, it
> would be nice to have Tycho-specific configuration markup inside <build>
> section. This is not currently possible because all poms must be
> compatible with the same model.

I like the idea of consumptions specifics. It would be great if we could
agree/define some sort of standard on how to declare suitability for
artifacts for certain deployment scenarios ..
e.g. it is jar suitable for Java 6, 7, 8, 9 or what, what about running on
Android, or on some embedded Java version profile.

I dont believe that the previous approaches of using classifiers is just
not powerful enough. And I also agree that we should potentially just
stick to the existing format.

E.g. nothing stops us from declaring a standard for e.g. for a bunch of
properties like

<properties>
 <runtime.android>true</runtime.android>
 <runtime.java6>true</runtime.java6>
</properties>

or
<properties>
 <runtime.android>false</runtime.android>
 <runtime.java6>false</runtime.java6>
 <runtime.java7>true</runtime.java7>
</properties>

Of course we should put more thought into this but declaring a standard
sooner rather than later could help a lot with the oncoming wave of
libraries that will not work for Java 6 anymore and others going forward
with e.g. Java 8 only and so on.

Manfred


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Model Version 5.0.0

Posted by Igor Fedorenko <ig...@ifedorenko.com>.


On 11/23/2013, 23:08, Jason van Zyl wrote:
>
> On Nov 23, 2013, at 5:44 PM, Stephen Connolly
> <st...@gmail.com> wrote:
>
>> Before I forget, here are some of my thoughts on moving towards
>> Model Version 5.0.0
>>
>> The pom that we build with need not be the pom that gets
>> deployed... thus the pom that is built with need not be the same
>> format as the pom that gets deployed.
>>
>
> Can you explain why you think this is useful? To me all the
> information that is carried with the POM after deployment is
> primarily for the consumption of tools, and there are a lot of tools
> that expect more than the dependency information. Removing all other
> elements in the POM is equivalent to being massively backward
> incompatible for an API. And if the subsequent consumption after
> deployment is primarily by programs, then why does it matter what
> gets deployed. I don't really see much benefit, but will create all
> sorts of technical problems where we need multiple readers and all
> that entails and the massive number of problems this will cause
> people who have created tooling, especially IDE integration. >

The way I see it, what is deployed describes how the artifact needs to
be consumed. This is artifact's "public API", if you will, it will be
consumed by wide range of tools that resolve dependencies from Maven
repositories and descriptor format should be very stable. Mostly likely
we have no choice but use (a subset of) the current 4.0.0 model version.

How the artifact is produced, on the other hand, is artifact's
implementation detail. It is perfectly reasonable for a project to
require minimal version of Maven, for example. Or use completely
different format, not related to pom at all.

By separating "consumption" and "production" metadata formats, we'll be
able to evolve production format more aggressively. For example, it
would be nice to have Tycho-specific configuration markup inside <build>
section. This is not currently possible because all poms must be
compatible with the same model.

--
Regards,
Igor



>> Only with <packaging>pom</packaging> do we actually need things like the
>> <plugins> section in the deployed pom, because it is a reality that for
>> noo-pom packaging we just want the transitive dependencies.
>>
>> Now there is the <extensions> issue where you might be registering a
>> different file type that has different rules with respect to the
>> classpath... but I am unsure if we actually consider those when evaluating
>> the dependency tree... and in any case, once we accept that the deployed
>> pom is not the same as the pom used to build (for non-pom packaging at
>> least) we can transform that dependency tree using the exact rules that
>> have to be known at build time thus closing the extensions issue.
>>
>> For projects with <packaging>pom</packaging> in fact we are only deploying
>> smal files so perhaps we can deploy two pom files... the one that exposes
>> the standard dependency stuff and then a second one that is used for build
>> inheritance.
>>
>> My vision is thus that we deploy between 2 and three pom files for every
>> project.
>>
>> For jar/war/ear/... we deploy:
>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but allows
>> for new scopes)
>>
>> For pom we deploy
>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but allows
>> for new scopes)
>> * the pom itself
>>
>> When building a pom, your parent pom must be of a modelVersion <= your
>> modelVersion.
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
>
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Model Version 5.0.0

Posted by Stephen Connolly <st...@gmail.com>.

That's why I say parent poms are deployed in three formats: 4.0.0, 5.0.0+
and build. And you specify that your parent Pom must be <= modelVersion of
child pom so that it can evolve as needed

On Sunday, 24 November 2013, Hervé BOUTEMY wrote:

> Le dimanche 24 novembre 2013 16:58:33 Stephen Connolly a écrit :
> > Given that deployed poms can be generated by Gradle, Buildr, etc... It
> > makes no sense to include build information in the pom (unless it is a
> > parent pom)
> if you think at it, a parent pom is a pure build configuration for sharing
> between multiple modules
>
> it's not used by pure artifact consumers
> it's used by builders for sharing
>
> Regards,
>
> Hervé
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>

-- 
Sent from my phone

Re: Model Version 5.0.0

Posted by Hervé BOUTEMY <he...@free.fr>.

Le dimanche 24 novembre 2013 16:58:33 Stephen Connolly a écrit :
> Given that deployed poms can be generated by Gradle, Buildr, etc... It
> makes no sense to include build information in the pom (unless it is a
> parent pom)
if you think at it, a parent pom is a pure build configuration for sharing 
between multiple modules

it's not used by pure artifact consumers
it's used by builders for sharing

Regards,

Hervé

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Model Version 5.0.0

Posted by Martijn Dashorst <ma...@gmail.com>.

On Mon, Mar 24, 2014 at 7:29 PM, Robert Scholte <rf...@apache.org>wrote:

> I have to admit I have never used it, but aren't the -c / -C Maven
> commandline options meant for this?
>

Only if you trust the repository where you get the checksums from. The idea
advocated by Baptiste is that as a project owner you specify not only which
GAV you require but also the checksum of a dependency: this way you can
retrieve the checksum from the original project and make sure everybody
gets the 'official' version. This also ensures that nobody can tamper with
uploading a new version to a repository under the same GAV.

Now probably this will not be very practical to introduce on a large
project (try to find the correct signatures for each dependency in for
example a standard Maven build for a hello world application), but for some
venues this might actually make sense-where security and accountability is
paramount.

Martijn

Re: Model Version 5.0.0

Posted by Robert Scholte <rf...@apache.org>.

I have to admit I have never used it, but aren't the -c / -C Maven  
commandline options meant for this?

Robert

Op Mon, 24 Mar 2014 13:33:11 +0100 schreef Baptiste Mathus <ml...@batmat.net>:

> I guess if you manage to lose your repo, there could be either a special
> switch to disable it, or maybe better, being able to fix selectively  
> those
> exceptions in *your* pom like you currently do for versions of a
> transitively retrieved artifact.
>
>> Why
>
> I'd say because you'd like to prevent some kind or AIDM attack (Artifact  
> In
> The Middle ;-)), which you're currently unable to detect if the upstream
> repo has been hacked?
>
> Not saying this is something that *must* be there in M4 or so, but I  
> guess
> this would be cool for Maven to be able to support that kind of use-case.
>
> I'm not paranoid myself, but I guess there's a lot of companies that  
> would
> like this feature (when you see how much Sonatype invested in
> security/blabla detection for nexus, I guess that's because it's somehow
> been asked by some customers. Note I don't count myself in them.).
>
> But maybe this isn't something that should go in the <dependency> block,
> but in a dedicated plugin. The thing is, you then fall back again on the
> problem of DRY having to somehow repeat GAV coordinates somewhere to
> describe that additional metadata.
>
> Anyway, I find it at least interesting to have that debate.
>
> 2014-03-24 12:23 GMT+01:00 Stephen Connolly  
> <stephen.alan.connolly@gmail.com
>> :
>
>> Why? Sounds like just one more thing that could go wrong, plus if you  
>> lost
>> your repo and are rebuilding all from source because the timestamps will
>> differ, so the .zip checksums will differ too
>>
>> On Monday, 24 March 2014, Baptiste Mathus <bm...@batmat.net> wrote:
>>
>> > Hi,
>> >
>> > Sorry if it's the wrong thread, just let me know.
>> >
>> > I thought I'd dump that thought I've had for some time here: was
>> enriching
>> > a bit the <dependency> block already discussed?
>> >
>> > So that one can somehow express a <checksum> tag. I'm posting this  
>> here
>> > since this would also require a pom upgrade.
>> > I've re-read the recent threads but didn't find anything about it.  
>> Also
>> > crawled JIRA without luck (though I guess this has already been  
>> reported
>> > somewhere).
>> >
>> > Something like
>> >
>> > *<dependency>*
>> > *  <groupId>...*
>> > *  <artifactId>...*
>> > *  <version>...*
>> > *  <checksum>sha1:2cfc5458ff56d559316b901a348bbcad01d3ce62</checksum>*
>> > *</dependency>*
>> >
>> > WDYT?
>> >
>> > Cheers
>> >
>> >
>> > 2014-02-26 21:50 GMT+01:00 Robert Scholte <rfscholte@apache.org
>> <javascript:;>
>> > >:
>> >
>> > > Hi,
>> > >
>> > > I think this is good start and I would expect that the planned  
>> consumer
>> > > pom.xml would still validate against the model 4.0.0 xsd, since now  
>> it
>> is
>> > > the standard file being uploaded and used by a lot of build  
>> management
>> > > tools.
>> > > If there are some flaws in the current XML, this could be the right
>> > moment
>> > > to design a new consumer specific XML, maybe together with the  
>> Aether
>> > team
>> > > for example.
>> > >
>> > > Robert
>> > >
>> > > Op Wed, 26 Feb 2014 01:59:29 +0100 schreef Stephen Connolly <
>> > > stephen.alan.connolly@gmail.com <javascript:;>>:
>> > >
>> > >
>> > >  That is a modelVersion 4.0.0 consumer pom unless I am mistaken.  
>> What
>> > we/I
>> > >> want from a consumer pom is more than modelVersion 4.0.0 pom with
>> > >> inheritance interpolated and properties resolved
>> > >>
>> > >> On Tuesday, 25 February 2014, Jörg Hohwiller <joerg@j-hohwiller.de
>> <javascript:;>
>> > >
>> > >> wrote:
>> > >>
>> > >>  Hi there,
>> > >>>
>> > >>> just for the record to this thread:
>> > >>> I wrote consumer-maven-plugin and added it to MOJOs sandbox.
>> > >>> The plugin allows to generate a consumer POM and apply it to the
>> > current
>> > >>> MavenProject (via setFile).
>> > >>> So we can already test various impacts of what can, will and  
>> should
>> > >>> happen
>> > >>> when a "consumer POM" is installed, signed, deployed instead of  
>> the
>> > >>> original pom.xml file that can later on be in future model  
>> formats.
>> > >>>
>> > >>> See thread on dev mojo with subject "consumer-maven-plugin added  
>> to
>> > >>> sandbox".
>> > >>> Hope to hear from you.
>> > >>>
>> > >>> Kind regards
>> > >>>   Jörg
>> > >>>
>> > >>> Am 24.11.2013 23:04, schrieb Barrie Treloar:
>> > >>>
>> > >>>  On 25 November 2013 03:28, Stephen Connolly
>> > >>>> <stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>> > >>>> [del]
>> > >>>>
>> > >>>>  Given that we have decided that the reporting stuff possibly  
>> was a
>> > >>>>> mistake... Well let's drop that
>> > >>>>>
>> > >>>>> Given that profiles do not make sense in deployed poms... Drop  
>> them
>> > too
>> > >>>>>
>> > >>>>> We think <repositories> is evil... Let's drop that... We've  
>> dropped
>> > >>>>> build
>> > >>>>> and reporting=> no need for pluginRepositories at all so.
>> > >>>>>
>> > >>>>>  I'm in favour of cleaning out elements that cause problems when
>> they
>> > >>>> are tweaked in a the non-Maven Way.
>> > >>>> The emails to the users list would be reduce and there is less
>> chance
>> > >>>> of causing confusion.
>> > >>>>
>> > >>>> Applying the "current" best practises and baking them into the  
>> poms
>> is
>> > >>>> a good thing.
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>
>> > >>>
>> > >  
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail:  
>> dev-unsubscribe@maven.apache.org<javascript:;>
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> <javascript:;>
>> > >
>> > >
>> >
>> >
>> > --
>> > Baptiste <Batmat> MATHUS - http://batmat.net
>> > Sauvez un arbre,
>> > Mangez un castor !
>> >
>>
>>
>> --
>> Sent from my phone
>>
>> --
>> Baptiste <Batmat> MATHUS - http://batmat.net
>> Sauvez un arbre,
>> Mangez un castor ! nbsp;!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Model Version 5.0.0

Posted by Hervé BOUTEMY <he...@free.fr>.

Le vendredi 13 juin 2014 10:51:35 Simon Wang a écrit :
> exactly.
> 
> by that way, not only simplify pom.
> Also for one maven build, could identify project dependency hierarchy
> easier.
> 
> base on that, could do further things:
> 1. to ensure whether could parallel build for module projects.
> 2. provide analysis report for developers to show their dependency
> hierarchy to help them improve their structure.
> ...
we already have that without such feature: plugins can easily know what is in 
the reactor

from what I understand, it will just simplify poms a little bit: ok, why not

and since old maven version cannot understand a pom without missing info, this 
will require the 5.0.0 POM, even if no new element was added

Regards,

Hervé


> 
> Regards
> Simon
> 
> 2014-06-12 21:02 GMT+08:00 Arnaud Héritier <ah...@gmail.com>:
> > http://www.gradle.org/docs/current/userguide/dependency_management.html#su
> > b:project_dependencies ???
> > The idea behind it may be that by default we can declare in a
> > multi-projects build some dependencies without groupId and version. In
> > that
> > case they are using automatically the module groupId and and version
> > asking
> > for the dep (2 lines less in your pom for each dep like this).
> > 
> > 
> > 
> > On Thu, Jun 12, 2014 at 8:21 AM, Hervé BOUTEMY <he...@free.fr>
> > 
> > wrote:
> > > any reference to what you call "project dependency"?
> > > how is it different from a classic dependency? a dependency in a
> > > reactor?
> > > 
> > > Regards,
> > > 
> > > Hervé
> > > 
> > > Le mercredi 11 juin 2014 17:18:05 Simon Wang a écrit :
> > > > Since we're thinking about model-5.0.
> > > > 
> > > > Is it possible to support project dependency in 5.0?
> > > > Project dependency could benefit users a lot.
> > > > They needn't care about whether others dependent projects(might
> > 
> > changed)
> > 
> > > > are installed or not.
> > > > And users needn't always run maven build with parent pom.
> > > > 
> > > > Regards
> > > > Simon
> > > > 
> > > > 2014-03-25 18:41 GMT+08:00 Nigel Magnay <ni...@gmail.com>:
> > > > > On Tue, Mar 25, 2014 at 8:55 AM, Baptiste Mathus <bmathus@batmat.net
> > > > > 
> > > > > wrote:
> > > > > > FWIW, I'm aware it's easily feasible to add that checksum
> > 
> > validation
> > 
> > > in
> > > 
> > > > > > a
> > > > > > plugin, but you'll still have to repeat the coordinates.
> > > > > > And that very thing was my point: I don't think having to repeat
> > > 
> > > those
> > > 
> > > > > > coordinates to add metadata is great.
> > > > > > 
> > > > > > Not even saying this *must* go in modelVersion 5, I just wanted
> > 
> > that
> > 
> > > > > debate
> > > > > 
> > > > > > to happen at least for future reference if people wonder why maven
> > > 
> > > pom
> > > 
> > > > > > can't store that dependency metadata (DRY'ly alongside its data, I
> > > > > > mean).
> > > > > 
> > > > > There's all sorts of other per-dependency information that would be
> > > > > useful, for example - flex applications needing to store RSL
> > 
> > deployment
> > 
> > > > > paths and policy file urls.
> > > > > 
> > > > > The 'maven way' seems to be sentenced to perennially repeat
> > > > > yourself,
> > > 
> > > and
> > > 
> > > > > live with the fact your plugin config and your dependency list can
> > > 
> > > drift
> > > 
> > > > > out of sync. Or to suffer some kind of excuse of 'just specify the
> > > > > dependencies you want to apply this metadata to with some kind of
> > > 
> > > regular
> > > 
> > > > > expression (!)'.
> > > > > 
> > > > > XML even has a well-understood extension mechanism for this kind of
> > > 
> > > thing.
> > > 
> > > > > ...
> > > > > <dependency security:sha1="1234567890abcdef" >
> > > > > 
> > > > >   <groupId>com.woo</groupId>
> > > > >   <artifactId>yay</artifactId>
> > > > >   <version>1.0</version>
> > > > >   <flex:rslInfo>
> > > > >   
> > > > >       <flex:deployment-path>/blah/blah</flex:deployment-path>
> > > > >       <flex:policy-file>/woo/policy.xml</flex:policy-file>
> > > > >   
> > > > >   </flex:rslInfo>
> > > > > 
> > > > > </dependency>
> > > > > 
> > > > > ....
> > > > > <plugins>
> > > > > 
> > > > >   <plugin>
> > > > >   
> > > > >      /// some plugin that enforces security:sha1
> > > > > 
> > > > > .... etc etc etc
> > > > > 
> > > > > 
> > > > > 
> > > > > If your tooling doesn't understand namespaced nodes, it's trivial to
> > > 
> > > strip
> > > 
> > > > > them.
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > 
> > --
> > -----
> > Arnaud Héritier
> > http://aheritier.net
> > Mail/GTalk: aheritier AT gmail DOT com
> > Twitter/Skype : aheritier


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Model Version 5.0.0

Posted by Paul Benedict <pb...@apache.org>.

Is there any value in letting the 5.0.0 be like HTML in that new elements
may continuously introduced but older clients must allow "graceful
degradation"?


Cheers,
Paul


On Thu, Jun 12, 2014 at 9:51 PM, Simon Wang <wa...@gmail.com> wrote:

> exactly.
>
> by that way, not only simplify pom.
> Also for one maven build, could identify project dependency hierarchy
> easier.
>
> base on that, could do further things:
> 1. to ensure whether could parallel build for module projects.
> 2. provide analysis report for developers to show their dependency
> hierarchy to help them improve their structure.
> ...
>
> Regards
> Simon
>
>
> 2014-06-12 21:02 GMT+08:00 Arnaud Héritier <ah...@gmail.com>:
>
> >
> >
> http://www.gradle.org/docs/current/userguide/dependency_management.html#sub:project_dependencies
> > ???
> > The idea behind it may be that by default we can declare in a
> > multi-projects build some dependencies without groupId and version. In
> that
> > case they are using automatically the module groupId and and version
> asking
> > for the dep (2 lines less in your pom for each dep like this).
> >
> >
> >
> > On Thu, Jun 12, 2014 at 8:21 AM, Hervé BOUTEMY <he...@free.fr>
> > wrote:
> >
> > > any reference to what you call "project dependency"?
> > > how is it different from a classic dependency? a dependency in a
> reactor?
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le mercredi 11 juin 2014 17:18:05 Simon Wang a écrit :
> > > > Since we're thinking about model-5.0.
> > > >
> > > > Is it possible to support project dependency in 5.0?
> > > > Project dependency could benefit users a lot.
> > > > They needn't care about whether others dependent projects(might
> > changed)
> > > > are installed or not.
> > > > And users needn't always run maven build with parent pom.
> > > >
> > > > Regards
> > > > Simon
> > > >
> > > > 2014-03-25 18:41 GMT+08:00 Nigel Magnay <ni...@gmail.com>:
> > > > > On Tue, Mar 25, 2014 at 8:55 AM, Baptiste Mathus <
> bmathus@batmat.net
> > >
> > > > >
> > > > > wrote:
> > > > > > FWIW, I'm aware it's easily feasible to add that checksum
> > validation
> > > in
> > > > > > a
> > > > > > plugin, but you'll still have to repeat the coordinates.
> > > > > > And that very thing was my point: I don't think having to repeat
> > > those
> > > > > > coordinates to add metadata is great.
> > > > > >
> > > > > > Not even saying this *must* go in modelVersion 5, I just wanted
> > that
> > > > >
> > > > > debate
> > > > >
> > > > > > to happen at least for future reference if people wonder why
> maven
> > > pom
> > > > > > can't store that dependency metadata (DRY'ly alongside its data,
> I
> > > > > > mean).
> > > > >
> > > > > There's all sorts of other per-dependency information that would be
> > > > > useful, for example - flex applications needing to store RSL
> > deployment
> > > > > paths and policy file urls.
> > > > >
> > > > > The 'maven way' seems to be sentenced to perennially repeat
> yourself,
> > > and
> > > > > live with the fact your plugin config and your dependency list can
> > > drift
> > > > > out of sync. Or to suffer some kind of excuse of 'just specify the
> > > > > dependencies you want to apply this metadata to with some kind of
> > > regular
> > > > > expression (!)'.
> > > > >
> > > > > XML even has a well-understood extension mechanism for this kind of
> > > thing.
> > > > >
> > > > >
> > > > > ...
> > > > > <dependency security:sha1="1234567890abcdef" >
> > > > >
> > > > >   <groupId>com.woo</groupId>
> > > > >   <artifactId>yay</artifactId>
> > > > >   <version>1.0</version>
> > > > >   <flex:rslInfo>
> > > > >
> > > > >       <flex:deployment-path>/blah/blah</flex:deployment-path>
> > > > >       <flex:policy-file>/woo/policy.xml</flex:policy-file>
> > > > >
> > > > >   </flex:rslInfo>
> > > > >
> > > > > </dependency>
> > > > >
> > > > > ....
> > > > > <plugins>
> > > > >
> > > > >   <plugin>
> > > > >
> > > > >      /// some plugin that enforces security:sha1
> > > > >
> > > > > .... etc etc etc
> > > > >
> > > > >
> > > > >
> > > > > If your tooling doesn't understand namespaced nodes, it's trivial
> to
> > > strip
> > > > > them.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> >
> > --
> > -----
> > Arnaud Héritier
> > http://aheritier.net
> > Mail/GTalk: aheritier AT gmail DOT com
> > Twitter/Skype : aheritier
> >
>

Re: Model Version 5.0.0

Posted by Simon Wang <wa...@gmail.com>.

exactly.

by that way, not only simplify pom.
Also for one maven build, could identify project dependency hierarchy
easier.

base on that, could do further things:
1. to ensure whether could parallel build for module projects.
2. provide analysis report for developers to show their dependency
hierarchy to help them improve their structure.
...

Regards
Simon


2014-06-12 21:02 GMT+08:00 Arnaud Héritier <ah...@gmail.com>:

>
> http://www.gradle.org/docs/current/userguide/dependency_management.html#sub:project_dependencies
> ???
> The idea behind it may be that by default we can declare in a
> multi-projects build some dependencies without groupId and version. In that
> case they are using automatically the module groupId and and version asking
> for the dep (2 lines less in your pom for each dep like this).
>
>
>
> On Thu, Jun 12, 2014 at 8:21 AM, Hervé BOUTEMY <he...@free.fr>
> wrote:
>
> > any reference to what you call "project dependency"?
> > how is it different from a classic dependency? a dependency in a reactor?
> >
> > Regards,
> >
> > Hervé
> >
> > Le mercredi 11 juin 2014 17:18:05 Simon Wang a écrit :
> > > Since we're thinking about model-5.0.
> > >
> > > Is it possible to support project dependency in 5.0?
> > > Project dependency could benefit users a lot.
> > > They needn't care about whether others dependent projects(might
> changed)
> > > are installed or not.
> > > And users needn't always run maven build with parent pom.
> > >
> > > Regards
> > > Simon
> > >
> > > 2014-03-25 18:41 GMT+08:00 Nigel Magnay <ni...@gmail.com>:
> > > > On Tue, Mar 25, 2014 at 8:55 AM, Baptiste Mathus <bmathus@batmat.net
> >
> > > >
> > > > wrote:
> > > > > FWIW, I'm aware it's easily feasible to add that checksum
> validation
> > in
> > > > > a
> > > > > plugin, but you'll still have to repeat the coordinates.
> > > > > And that very thing was my point: I don't think having to repeat
> > those
> > > > > coordinates to add metadata is great.
> > > > >
> > > > > Not even saying this *must* go in modelVersion 5, I just wanted
> that
> > > >
> > > > debate
> > > >
> > > > > to happen at least for future reference if people wonder why maven
> > pom
> > > > > can't store that dependency metadata (DRY'ly alongside its data, I
> > > > > mean).
> > > >
> > > > There's all sorts of other per-dependency information that would be
> > > > useful, for example - flex applications needing to store RSL
> deployment
> > > > paths and policy file urls.
> > > >
> > > > The 'maven way' seems to be sentenced to perennially repeat yourself,
> > and
> > > > live with the fact your plugin config and your dependency list can
> > drift
> > > > out of sync. Or to suffer some kind of excuse of 'just specify the
> > > > dependencies you want to apply this metadata to with some kind of
> > regular
> > > > expression (!)'.
> > > >
> > > > XML even has a well-understood extension mechanism for this kind of
> > thing.
> > > >
> > > >
> > > > ...
> > > > <dependency security:sha1="1234567890abcdef" >
> > > >
> > > >   <groupId>com.woo</groupId>
> > > >   <artifactId>yay</artifactId>
> > > >   <version>1.0</version>
> > > >   <flex:rslInfo>
> > > >
> > > >       <flex:deployment-path>/blah/blah</flex:deployment-path>
> > > >       <flex:policy-file>/woo/policy.xml</flex:policy-file>
> > > >
> > > >   </flex:rslInfo>
> > > >
> > > > </dependency>
> > > >
> > > > ....
> > > > <plugins>
> > > >
> > > >   <plugin>
> > > >
> > > >      /// some plugin that enforces security:sha1
> > > >
> > > > .... etc etc etc
> > > >
> > > >
> > > >
> > > > If your tooling doesn't understand namespaced nodes, it's trivial to
> > strip
> > > > them.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
> -----
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>

Re: Model Version 5.0.0

Posted by Arnaud Héritier <ah...@gmail.com>.

http://www.gradle.org/docs/current/userguide/dependency_management.html#sub:project_dependencies
???
The idea behind it may be that by default we can declare in a
multi-projects build some dependencies without groupId and version. In that
case they are using automatically the module groupId and and version asking
for the dep (2 lines less in your pom for each dep like this).



On Thu, Jun 12, 2014 at 8:21 AM, Hervé BOUTEMY <he...@free.fr>
wrote:

> any reference to what you call "project dependency"?
> how is it different from a classic dependency? a dependency in a reactor?
>
> Regards,
>
> Hervé
>
> Le mercredi 11 juin 2014 17:18:05 Simon Wang a écrit :
> > Since we're thinking about model-5.0.
> >
> > Is it possible to support project dependency in 5.0?
> > Project dependency could benefit users a lot.
> > They needn't care about whether others dependent projects(might changed)
> > are installed or not.
> > And users needn't always run maven build with parent pom.
> >
> > Regards
> > Simon
> >
> > 2014-03-25 18:41 GMT+08:00 Nigel Magnay <ni...@gmail.com>:
> > > On Tue, Mar 25, 2014 at 8:55 AM, Baptiste Mathus <bm...@batmat.net>
> > >
> > > wrote:
> > > > FWIW, I'm aware it's easily feasible to add that checksum validation
> in
> > > > a
> > > > plugin, but you'll still have to repeat the coordinates.
> > > > And that very thing was my point: I don't think having to repeat
> those
> > > > coordinates to add metadata is great.
> > > >
> > > > Not even saying this *must* go in modelVersion 5, I just wanted that
> > >
> > > debate
> > >
> > > > to happen at least for future reference if people wonder why maven
> pom
> > > > can't store that dependency metadata (DRY'ly alongside its data, I
> > > > mean).
> > >
> > > There's all sorts of other per-dependency information that would be
> > > useful, for example - flex applications needing to store RSL deployment
> > > paths and policy file urls.
> > >
> > > The 'maven way' seems to be sentenced to perennially repeat yourself,
> and
> > > live with the fact your plugin config and your dependency list can
> drift
> > > out of sync. Or to suffer some kind of excuse of 'just specify the
> > > dependencies you want to apply this metadata to with some kind of
> regular
> > > expression (!)'.
> > >
> > > XML even has a well-understood extension mechanism for this kind of
> thing.
> > >
> > >
> > > ...
> > > <dependency security:sha1="1234567890abcdef" >
> > >
> > >   <groupId>com.woo</groupId>
> > >   <artifactId>yay</artifactId>
> > >   <version>1.0</version>
> > >   <flex:rslInfo>
> > >
> > >       <flex:deployment-path>/blah/blah</flex:deployment-path>
> > >       <flex:policy-file>/woo/policy.xml</flex:policy-file>
> > >
> > >   </flex:rslInfo>
> > >
> > > </dependency>
> > >
> > > ....
> > > <plugins>
> > >
> > >   <plugin>
> > >
> > >      /// some plugin that enforces security:sha1
> > >
> > > .... etc etc etc
> > >
> > >
> > >
> > > If your tooling doesn't understand namespaced nodes, it's trivial to
> strip
> > > them.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: Model Version 5.0.0

Posted by Hervé BOUTEMY <he...@free.fr>.

any reference to what you call "project dependency"?
how is it different from a classic dependency? a dependency in a reactor?

Regards,

Hervé

Le mercredi 11 juin 2014 17:18:05 Simon Wang a écrit :
> Since we're thinking about model-5.0.
> 
> Is it possible to support project dependency in 5.0?
> Project dependency could benefit users a lot.
> They needn't care about whether others dependent projects(might changed)
> are installed or not.
> And users needn't always run maven build with parent pom.
> 
> Regards
> Simon
> 
> 2014-03-25 18:41 GMT+08:00 Nigel Magnay <ni...@gmail.com>:
> > On Tue, Mar 25, 2014 at 8:55 AM, Baptiste Mathus <bm...@batmat.net>
> > 
> > wrote:
> > > FWIW, I'm aware it's easily feasible to add that checksum validation in
> > > a
> > > plugin, but you'll still have to repeat the coordinates.
> > > And that very thing was my point: I don't think having to repeat those
> > > coordinates to add metadata is great.
> > > 
> > > Not even saying this *must* go in modelVersion 5, I just wanted that
> > 
> > debate
> > 
> > > to happen at least for future reference if people wonder why maven pom
> > > can't store that dependency metadata (DRY'ly alongside its data, I
> > > mean).
> > 
> > There's all sorts of other per-dependency information that would be
> > useful, for example - flex applications needing to store RSL deployment
> > paths and policy file urls.
> > 
> > The 'maven way' seems to be sentenced to perennially repeat yourself, and
> > live with the fact your plugin config and your dependency list can drift
> > out of sync. Or to suffer some kind of excuse of 'just specify the
> > dependencies you want to apply this metadata to with some kind of regular
> > expression (!)'.
> > 
> > XML even has a well-understood extension mechanism for this kind of thing.
> > 
> > 
> > ...
> > <dependency security:sha1="1234567890abcdef" >
> > 
> >   <groupId>com.woo</groupId>
> >   <artifactId>yay</artifactId>
> >   <version>1.0</version>
> >   <flex:rslInfo>
> >   
> >       <flex:deployment-path>/blah/blah</flex:deployment-path>
> >       <flex:policy-file>/woo/policy.xml</flex:policy-file>
> >   
> >   </flex:rslInfo>
> > 
> > </dependency>
> > 
> > ....
> > <plugins>
> > 
> >   <plugin>
> >   
> >      /// some plugin that enforces security:sha1
> > 
> > .... etc etc etc
> > 
> > 
> > 
> > If your tooling doesn't understand namespaced nodes, it's trivial to strip
> > them.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Model Version 5.0.0

Posted by Simon Wang <wa...@gmail.com>.

Since we're thinking about model-5.0.

Is it possible to support project dependency in 5.0?
Project dependency could benefit users a lot.
They needn't care about whether others dependent projects(might changed)
are installed or not.
And users needn't always run maven build with parent pom.

Regards
Simon


2014-03-25 18:41 GMT+08:00 Nigel Magnay <ni...@gmail.com>:

> On Tue, Mar 25, 2014 at 8:55 AM, Baptiste Mathus <bm...@batmat.net>
> wrote:
>
> > FWIW, I'm aware it's easily feasible to add that checksum validation in a
> > plugin, but you'll still have to repeat the coordinates.
> > And that very thing was my point: I don't think having to repeat those
> > coordinates to add metadata is great.
> >
> > Not even saying this *must* go in modelVersion 5, I just wanted that
> debate
> > to happen at least for future reference if people wonder why maven pom
> > can't store that dependency metadata (DRY'ly alongside its data, I mean).
> >
> >
> There's all sorts of other per-dependency information that would be
> useful, for example - flex applications needing to store RSL deployment
> paths and policy file urls.
>
> The 'maven way' seems to be sentenced to perennially repeat yourself, and
> live with the fact your plugin config and your dependency list can drift
> out of sync. Or to suffer some kind of excuse of 'just specify the
> dependencies you want to apply this metadata to with some kind of regular
> expression (!)'.
>
> XML even has a well-understood extension mechanism for this kind of thing.
>
>
> ...
> <dependency security:sha1="1234567890abcdef" >
>   <groupId>com.woo</groupId>
>   <artifactId>yay</artifactId>
>   <version>1.0</version>
>   <flex:rslInfo>
>       <flex:deployment-path>/blah/blah</flex:deployment-path>
>       <flex:policy-file>/woo/policy.xml</flex:policy-file>
>   </flex:rslInfo>
> </dependency>
>
> ....
> <plugins>
>   <plugin>
>      /// some plugin that enforces security:sha1
> .... etc etc etc
>
>
>
> If your tooling doesn't understand namespaced nodes, it's trivial to strip
> them.
>

Re: Model Version 5.0.0

Posted by Nigel Magnay <ni...@gmail.com>.

On Tue, Mar 25, 2014 at 8:55 AM, Baptiste Mathus <bm...@batmat.net> wrote:

> FWIW, I'm aware it's easily feasible to add that checksum validation in a
> plugin, but you'll still have to repeat the coordinates.
> And that very thing was my point: I don't think having to repeat those
> coordinates to add metadata is great.
>
> Not even saying this *must* go in modelVersion 5, I just wanted that debate
> to happen at least for future reference if people wonder why maven pom
> can't store that dependency metadata (DRY'ly alongside its data, I mean).
>
>
There's all sorts of other per-dependency information that would be
useful, for example - flex applications needing to store RSL deployment
paths and policy file urls.

The 'maven way' seems to be sentenced to perennially repeat yourself, and
live with the fact your plugin config and your dependency list can drift
out of sync. Or to suffer some kind of excuse of 'just specify the
dependencies you want to apply this metadata to with some kind of regular
expression (!)'.

XML even has a well-understood extension mechanism for this kind of thing.

...
<dependency security:sha1="1234567890abcdef" >
  <groupId>com.woo</groupId>
  <artifactId>yay</artifactId>
  <version>1.0</version>
  <flex:rslInfo>
      <flex:deployment-path>/blah/blah</flex:deployment-path>
      <flex:policy-file>/woo/policy.xml</flex:policy-file>
  </flex:rslInfo>
</dependency>

....
<plugins>
  <plugin>
     /// some plugin that enforces security:sha1
.... etc etc etc

If your tooling doesn't understand namespaced nodes, it's trivial to strip
them.

Re: Model Version 5.0.0

Posted by Stephen Connolly <st...@gmail.com>.

Nahh.. you misinterpret what I am saying (probably a fault of my
communication)... when it is not a day I have taken as vacation time I will
explain in more detail


On 25 March 2014 08:55, Baptiste Mathus <bm...@batmat.net> wrote:

> FWIW, I'm aware it's easily feasible to add that checksum validation in a
> plugin, but you'll still have to repeat the coordinates.
> And that very thing was my point: I don't think having to repeat those
> coordinates to add metadata is great.
>
> Not even saying this *must* go in modelVersion 5, I just wanted that debate
> to happen at least for future reference if people wonder why maven pom
> can't store that dependency metadata (DRY'ly alongside its data, I mean).
>
> Cheers
>
>
> 2014-03-25 6:36 GMT+01:00 Dominik Bartholdi <do...@fortysix.ch>:
>
> >
> > For this, there is already an enforcer rule available:
> > https://github.com/gary-rowe/BitcoinjEnforcerRules
> > Domi
> >
> > On 24.03.2014, at 20:31, Martijn Dashorst <ma...@gmail.com>
> > wrote:
> >
> > > On Mon, Mar 24, 2014 at 8:06 PM, Stephen Connolly <
> > > stephen.alan.connolly@gmail.com> wrote:
> > >
> > >> I see the checksums then as being another potential side artifact...
> No
> > >> need for modelVersion 5.0.0
> > >>
> > >
> > > I see it differently: the checksum validates the GAV coordinates. "I
> mean
> > > 'com.example.foo:foo:1.0', specifically verify that it matches this
> > > signature 'sha1:1234567890abcdef'.
> > >
> > > For example, this enables me to check if a different version of an
> > artefact
> > > was uploaded to the same GAV than I expected (and reportedly the
> original
> > > author too).
> > >
> > > A plugin right now could capture them and deploy to repo, and you could
> > >> have same plugin verify the resolved dependencies against the same
> file.
> > >>
> > >
> > > This assumes the whole chain of parties is to be trusted. That nobody
> > will
> > > try to side-load a version from a different repository.
> > >
> > > I find the idea of adding a checksum to a dependency interesting.
> While I
> > > don't care for the extra fields in the POM, it opens a better venue of
> > > vetting the dependencies.
> > >
> > > Martijn
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>

Re: Model Version 5.0.0

Posted by Baptiste Mathus <bm...@batmat.net>.

FWIW, I'm aware it's easily feasible to add that checksum validation in a
plugin, but you'll still have to repeat the coordinates.
And that very thing was my point: I don't think having to repeat those
coordinates to add metadata is great.

Not even saying this *must* go in modelVersion 5, I just wanted that debate
to happen at least for future reference if people wonder why maven pom
can't store that dependency metadata (DRY'ly alongside its data, I mean).

Cheers


2014-03-25 6:36 GMT+01:00 Dominik Bartholdi <do...@fortysix.ch>:

>
> For this, there is already an enforcer rule available:
> https://github.com/gary-rowe/BitcoinjEnforcerRules
> Domi
>
> On 24.03.2014, at 20:31, Martijn Dashorst <ma...@gmail.com>
> wrote:
>
> > On Mon, Mar 24, 2014 at 8:06 PM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> >> I see the checksums then as being another potential side artifact... No
> >> need for modelVersion 5.0.0
> >>
> >
> > I see it differently: the checksum validates the GAV coordinates. "I mean
> > 'com.example.foo:foo:1.0', specifically verify that it matches this
> > signature 'sha1:1234567890abcdef'.
> >
> > For example, this enables me to check if a different version of an
> artefact
> > was uploaded to the same GAV than I expected (and reportedly the original
> > author too).
> >
> > A plugin right now could capture them and deploy to repo, and you could
> >> have same plugin verify the resolved dependencies against the same file.
> >>
> >
> > This assumes the whole chain of parties is to be trusted. That nobody
> will
> > try to side-load a version from a different repository.
> >
> > I find the idea of adding a checksum to a dependency interesting. While I
> > don't care for the extra fields in the POM, it opens a better venue of
> > vetting the dependencies.
> >
> > Martijn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: Model Version 5.0.0

Posted by Dominik Bartholdi <do...@fortysix.ch>.

For this, there is already an enforcer rule available: https://github.com/gary-rowe/BitcoinjEnforcerRules
Domi

On 24.03.2014, at 20:31, Martijn Dashorst <ma...@gmail.com> wrote:

> On Mon, Mar 24, 2014 at 8:06 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
> 
>> I see the checksums then as being another potential side artifact... No
>> need for modelVersion 5.0.0
>> 
> 
> I see it differently: the checksum validates the GAV coordinates. "I mean
> 'com.example.foo:foo:1.0', specifically verify that it matches this
> signature 'sha1:1234567890abcdef'.
> 
> For example, this enables me to check if a different version of an artefact
> was uploaded to the same GAV than I expected (and reportedly the original
> author too).
> 
> A plugin right now could capture them and deploy to repo, and you could
>> have same plugin verify the resolved dependencies against the same file.
>> 
> 
> This assumes the whole chain of parties is to be trusted. That nobody will
> try to side-load a version from a different repository.
> 
> I find the idea of adding a checksum to a dependency interesting. While I
> don't care for the extra fields in the POM, it opens a better venue of
> vetting the dependencies.
> 
> Martijn


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Model Version 5.0.0

Posted by Martijn Dashorst <ma...@gmail.com>.

On Mon, Mar 24, 2014 at 8:06 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> I see the checksums then as being another potential side artifact... No
> need for modelVersion 5.0.0
>

I see it differently: the checksum validates the GAV coordinates. "I mean
'com.example.foo:foo:1.0', specifically verify that it matches this
signature 'sha1:1234567890abcdef'.

For example, this enables me to check if a different version of an artefact
was uploaded to the same GAV than I expected (and reportedly the original
author too).

A plugin right now could capture them and deploy to repo, and you could
> have same plugin verify the resolved dependencies against the same file.
>

This assumes the whole chain of parties is to be trusted. That nobody will
try to side-load a version from a different repository.

I find the idea of adding a checksum to a dependency interesting. While I
don't care for the extra fields in the POM, it opens a better venue of
vetting the dependencies.

Martijn