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.
>
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 wrote:
> exactly.
>
> by that way, not only simplify pom.
> Also for one maven bu
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
hiera
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
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?
>
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
On Tue, Mar 25, 2014 at 8:55 AM, Baptiste Mathus 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
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 wrote:
> FWIW, I'm aware it's easily feasible to add that checksum validation in a
> plugin
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 w
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 wrote:
> On Mon, Mar 24, 2014 at 8:06 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> I see the checksums then as being
Hello,
it is not yet finished, and I am not sure if it actually would work for
most scenarios. But I was starting a plugin which allows to maintain
and create a "checksum lock file" for dependencies.
The basic idea is, that when I distribute a released maven project
(source) via for example Git,
On Mon, Mar 24, 2014 at 8:06 PM, Stephen Connolly <
stephen.alan.conno...@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'
On Mon, Mar 24, 2014 at 7:29 PM, Robert Scholte 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 spec
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 :
I guess if you manage to lose your repo, there could be either a special
switch to disable it, or maybe better, being abl
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 ki
316b901a348bbcad01d3ce62
>
> Gary
>
> Original message
> From: Baptiste Mathus
> Date:03/24/2014 06:19 (GMT-05:00)
> To: Maven Developers List
> Subject: Re: Model Version 5.0.0
>
> Hi,
>
> Sorry if it's the wrong thread, just let me know.
>
You'd need a checksum for jar, javadoc, sources and so on. Also what about md5
vs sha1?
Gary
Original message
From: Baptiste Mathus
Date:03/24/2014 06:19 (GMT-05:00)
To: Maven Developers List
Subject: Re: Model Version 5.0.0
Hi,
Sorry if it's the wrong th
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 wrote:
> Hi,
>
> Sorry if it's the wrong thread, just let me
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 block already discussed?
So that one can somehow express a tag. I'm posting this here
since this would also require a pom upgrade.
I've re-read the recent
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 r
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 wrote:
> Hi there,
>
> just for the record to this thread:
> I
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 "cons
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
On Sat, Nov 23, 2013 at 11:47 PM, Igor Fedorenko 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 descrip
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
Ar
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 ,
and -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
On Monday, 25 November 2013, Barrie Treloar wrote:
> On 25 November 2013 20:32, Stephen Connolly
> > 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
> > ... but we don't need to maintain such
On 25 November 2013 20:32, Stephen Connolly
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
> ... but we don't need to maintain such guarantees when we
> have a new schema.
If there is a better w
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 he
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
losin
> 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
>>
>> > section. T
s 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
> >
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
On 25 November 2013 03:28, Stephen Connolly
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 is evil... Let's drop that... We've dropped buil
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
[...]
> 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 multipl
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 p
> > -Original Message-
> > From: Stephen Connolly [mailto:stephen.alan.conno...@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 Z
Le dimanche 24 novembre 2013 10:26:13 Jason van Zyl a écrit :
> On Nov 24, 2013, at 12:19 AM, 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-
ignored to our peril for far
far too long
>
> -Original Message-
> From: Stephen Connolly [mailto:stephen.alan.conno...@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
essage-
From: Stephen Connolly [mailto:stephen.alan.conno...@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 wrote:
>
> On Nov 24, 2013, at 10:28 AM, Benson Margulies
> wrote:
&g
On 24 November 2013 17:44, Jason van Zyl wrote:
>
> On Nov 24, 2013, at 10:28 AM, Benson Margulies
> 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:
On Nov 24, 2013, at 10:28 AM, Benson Margulies 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'
> (dep
On Sunday, 24 November 2013, Jason van Zyl wrote:
>
> On Nov 24, 2013, at 3:59 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com > wrote:
>
> > On Sunday, 24 November 2013, Jason van Zyl wrote:
> >
> >>
> >> On Nov 23, 2013, at 5:44 PM, Stephen Connolly <
> >> stephen.alan.conno...@gmail.co
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
transiti
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 ad
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 s
On Nov 24, 2013, at 3:59 AM, Stephen Connolly
wrote:
> On Sunday, 24 November 2013, Jason van Zyl wrote:
>
>>
>> On Nov 23, 2013, at 5:44 PM, Stephen Connolly <
>> stephen.alan.conno...@gmail.com > wrote:
>>
>>> Before I forget, here are some of my thoughts on moving towards Model
>>> Versio
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 ne
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, t
On Nov 24, 2013, at 12:19 AM, 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
>> section. This is not cur
On Nov 23, 2013, at 11:47 PM, Igor Fedorenko wrote:
>
>
> On 11/23/2013, 23:08, Jason van Zyl wrote:
>>
>> On Nov 23, 2013, at 5:44 PM, Stephen Connolly
>> wrote:
>>
>>> Before I forget, here are some of my thoughts on moving towards
>>> Model Version 5.0.0
>>>
>>> The pom that we build wi
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
> Date: Sat, 23 Nov 2013 23:47:55 -0500
> From: i...@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
> > wrote:
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
> > section. This is not cur
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
>> wrote:
>>
>> Before I forget, here are some of my thoughts on moving towards
>>> Model Version 5.0.0
>>>
>>> The pom that we build with nee
On Sunday, 24 November 2013, Jason van Zyl wrote:
>
> On Nov 23, 2013, at 5:44 PM, Stephen Connolly <
> stephen.alan.conno...@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 t
> 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
> section. This is not currently possible because all poms must be
> compatible with t
On 11/23/2013, 23:08, Jason van Zyl wrote:
On Nov 23, 2013, at 5:44 PM, Stephen Connolly
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
On Nov 23, 2013, at 5:44 PM, Stephen Connolly
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
>
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
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
implemen
62 matches
Mail list logo
