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 wangyf2...@gmail.com wrote:
exactly.
by that way, not only simplify pom.
Also
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.
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?
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
It would be convenient to have nested property support for advanced
inheritance configuration. An example might be best:
project
properties
foo
barbaz/bar
/foo
/properties
/project
Where ${project.foo.bar} interpolates as baz. I find that I often want
to group configuration
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
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.
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
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 bmat...@batmat.net wrote:
FWIW, I'm aware it's easily feasible to add that checksum
On Tue, Mar 25, 2014 at 8:55 AM, Baptiste Mathus bmat...@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
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
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 bmat...@batmat.net wrote:
Hi,
Sorry if it's the wrong
You'd need a checksum for jar, javadoc, sources and so on. Also what about md5
vs sha1?
Gary
Original message
From: Baptiste Mathus bmat...@batmat.net
Date:03/24/2014 06:19 (GMT-05:00)
To: Maven Developers List dev@maven.apache.org
Subject: Re: Model Version 5.0.0
Hi
:2cfc5458ff56d559316b901a348bbcad01d3ce62/checksum
Gary
Original message
From: Baptiste Mathus bmat...@batmat.net
Date:03/24/2014 06:19 (GMT-05:00)
To: Maven Developers List dev@maven.apache.org
Subject: Re: Model Version 5.0.0
Hi,
Sorry if it's the wrong thread, just let me know.
I
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
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 m...@batmat.net:
I guess if you manage to lose your repo, there could be either a special
switch to disable it, or maybe
On Mon, Mar 24, 2014 at 7:29 PM, Robert Scholte rfscho...@apache.orgwrote:
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
I see the checksums then as being another potential side artifact... No
need for modelVersion 5.0.0
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.
On Monday, 24 March 2014, Baptiste Mathus
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',
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, I
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 martijn.dasho...@gmail.com wrote:
On Mon, Mar 24, 2014 at 8:06 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
I see the
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
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
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 jo...@j-hohwiller.de wrote:
Hi there,
just for the record
On Sat, Nov 23, 2013 at 11:47 PM, Igor Fedorenko i...@ifedorenko.comwrote:
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
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
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
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
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
On 25 November 2013 20:32, Stephen Connolly
stephen.alan.conno...@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
On Monday, 25 November 2013, Barrie Treloar wrote:
On 25 November 2013 20:32, Stephen Connolly
stephen.alan.conno...@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
On Sunday, 24 November 2013, Jason van Zyl wrote:
On Nov 23, 2013, at 5:44 PM, Stephen Connolly
stephen.alan.conno...@gmail.com javascript:; 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
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
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
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
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
stephen.alan.conno...@gmail.com wrote:
Before I forget, here
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
On Nov 23, 2013, at 11:47 PM, Igor Fedorenko i...@ifedorenko.com wrote:
On 11/23/2013, 23:08, 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
On Nov 24, 2013, at 12:19 AM, Manfred Moser manf...@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.
: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 that gets
deployed... thus the pom that is built with need not be the same
format as the pom
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 that gets
deployed... thus the pom that is built with need
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
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
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
2013, Igor Fedorenko wrote:
On 11/23/2013, 23:08, 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
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 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
javascript:; javascript:; 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
:
On 11/23/2013, 23:08, 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 that gets
deployed
, 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 that gets
deployed... thus the pom that is built with need not be the same
-
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 ja...@tesla.io wrote:
On Nov 24, 2013, at 10:28 AM, Benson Margulies bimargul
-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 ja...@tesla.io wrote:
On Nov 24, 2013, at 10:28 AM
Le dimanche 24 novembre 2013 10:26:13 Jason van Zyl a écrit :
On Nov 24, 2013, at 12:19 AM, Manfred Moser manf...@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
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 bimargul...@gmail.com
wrote:
It seems to me that this thread is mixing two topics.
Topic #1: How to we move
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
[...]
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
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
On 25 November 2013 03:28, Stephen Connolly
stephen.alan.conno...@gmail.com 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...
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
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 ja...@tesla.io wrote:
On Nov 24, 2013, at 10:28 AM, Benson
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
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
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 packagingpom/packaging do we
://github.com/rfscholte/modello/tree/modello4
Op Sat, 23 Nov 2013 23:44:56 +0100 schreef Stephen Connolly
stephen.alan.conno...@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
, 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 packagingpom/packaging do we actually need
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 that gets deployed...
thus the pom that is built with need
On 11/23/2013, 23:08, 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 that gets
deployed... thus
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
65 matches
Mail list logo
