dependency and parent tags for being DRY (Dont Repeat Yourself).
Thanks
Jörg
Am 19.06.2014 um 15:40 schrieb Jason van Zyl:
> We had the hangout yesterday. I pushed the initial bit of information about
> evolving the POM format here in a blog post here:
>
> http://localhost:4000/2014/06
In the case of a multi module build - or any reactor build I think a valid
rule would be all poms should be compatible with the maven version being
used.
Maybe even as far as to say the same version.
Mind you - I'm also largely of the opinion that support for multi module
should be deprecated/rem
I'm not sure I like the idea deploying a resolved/effective parent POM -
simply because a parent is essentially the same as an abstract class or a
template: it can't be used on its own.
It's only non-parents that get build, get profiles activated on etc.
... Sent on android
On 20/06/2014 2:48 am,
-)
>>>
>>>
>>> Cheers,
>>> Paul
>>>
>>>
>>> On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl wrote:
>>>
>>>> We had the hangout yesterday. I pushed the initial bit of information
>>>> about evol
Because users need to learn the new format.
The version number is not just for machines but for people too
On 20 June 2014 14:04, Igor Fedorenko wrote:
>
>
> On 2014-06-20, 7:59, Stephen Connolly wrote:
>
>> +1 on semver.
>>
>> Also if we change the schema or even the format (eg elements ->
>>
On 2014-06-20, 7:59, Stephen Connolly wrote:
+1 on semver.
Also if we change the schema or even the format (eg elements -> attributes,
xml -> DSL, etc) then we also bump the major even if there is a 1:1
bijection
If newer Maven versions can fully interpret new format without any loss
of con
+1 on semver.
Also if we change the schema or even the format (eg elements -> attributes,
xml -> DSL, etc) then we also bump the major even if there is a 1:1
bijection
On Friday, 20 June 2014, Igor Fedorenko wrote:
> I think ad-hoc aggregators are an interesting use case and I need to
> think a
I think ad-hoc aggregators are an interesting use case and I need to
think about it some more before I decide how I'd like to support it.
Anyways, all changes I currently have in mind are additions to the model
and reading older formats will not be a problem. Lets decide what to do
with truly inc
OK, when you have been referring to the build pom I thought you just meant
the pom in the project source. You actually mean that source pom (perhaps
flattened) deployed to the repository.
I don't see any need for the build pom to be deployed except where the
project has type="pom". Ie we intend fo
On Friday, 20 June 2014, William Ferguson
wrote:
> Stephen, I'm a little confused by the 3 POMs you have outlined.
>
> 1. The 4.0.0 flattened consumer pom
This is the pom for any consumers who only understand modelVersion 4.0.0 ie
Maven [2.0,4.0) and Gradle and Ivy and Buildr and ...
> 2. The
On Friday, 20 June 2014, Igor Fedorenko wrote:
> I am not sure I follow.
>
> Do you want to allow multi-module projects where different modules
> require different versions of maven?
No I want to allow multi-module projects where the maximum modelVersion
defines the minimum required version of
Stephen, I'm a little confused by the 3 POMs you have outlined.
1. The 4.0.0 flattened consumer pom
2. The post 4.0.0 flattened consumer pom
3. The build pom
Maybe it's just a naming issue, I also see 3 POMs but they are these:
A) Consumer POM for non POM projects. Essentially an effective POM s
I am not sure I follow.
Do you want to allow multi-module projects where different modules
require different versions of maven?
If required version of maven is the same, why not require the same pom
format version for the entire build too? Are you concerned about changes
to pom.xml files when mo
On Thursday, 19 June 2014, Robert Scholte wrote:
> Op Thu, 19 Jun 2014 18:07:33 +0200 schreef Stephen Connolly <
> stephen.alan.conno...@gmail.com>:
>
> Yeah I thought about that... and I don't like it.
>>
>> First off pom reading is not a pure java world. The ship has sailed. There
>> are peopl
Op Thu, 19 Jun 2014 18:07:33 +0200 schreef Stephen Connolly
:
Yeah I thought about that... and I don't like it.
First off pom reading is not a pure java world. The ship has sailed.
There
are people parsing the pom using Ruby, people parsing the pom using other
languages that don't even run
On Jun 19, 2014, at 11:49 AM, Paul Benedict wrote:
> I definitely agree that there should be two kinds of POMs: building and
> consuming. Those are two separate concerns and there's no reason to pollute
> dependency consumption with build information (or site information!). I am
> on board with
Yeah I thought about that... and I don't like it.
First off pom reading is not a pure java world. The ship has sailed. There
are people parsing the pom using Ruby, people parsing the pom using other
languages that don't even run on the JVM. Thus the only common denominator
is to provide an XSLT tr
If backwards compatible interoperability is not a requirement then:
If I upgrade one module in my multi-module build to Maven 5.1 then I am
forced right then and there to either:
* upgrade all of them to Maven 5.1; or
* remove the module from my multi-module build
Neither of these are a
I definitely agree that there should be two kinds of POMs: building and
consuming. Those are two separate concerns and there's no reason to pollute
dependency consumption with build information (or site information!). I am
on board with separating the two out. When it comes to evolving the
building
On Jun 19, 2014, at 11:24 AM, Paul Benedict wrote:
> I am curious why you interoperability as a requirement? Perhaps questioning
> that may seem outrageous, but I see no problem with saying that you need to
> upgrade to Maven X.Y to read newer POM formats.
To build a project that is certainly f
I am curious why you interoperability as a requirement? Perhaps questioning
that may seem outrageous, but I see no problem with saying that you need to
upgrade to Maven X.Y to read newer POM formats. If a vendor wants to
backport their project into older POM formats, that should be the vendor's
sho
On 19 June 2014 15:48, Igor Fedorenko wrote:
>
>
> On 2014-06-19, 10:30, Stephen Connolly wrote:
>
>> - Igor is*mostly* right in that we should not deploy the pom that is used
>>
>> to build to the repository...
>> - Where Igor is wrong is that for pom we should
>> actually deploy the build time
On 2014-06-19, 10:30, Stephen Connolly wrote:
- Igor is*mostly* right in that we should not deploy the pom that is used
to build to the repository...
- Where Igor is wrong is that for pom we should
actually deploy the build time pom to the repository... probably with the
classifier `build`...
gt;> Cheers,
> >> Paul
> >>
> >>
> >> On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl wrote:
> >>
> >>> We had the hangout yesterday. I pushed the initial bit of information
> >>> about evolving the POM format here in a
>>
>>
>> Cheers,
>> Paul
>>
>>
>> On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl wrote:
>>
>>> We had the hangout yesterday. I pushed the initial bit of information
>>> about evolving the POM format here in a blog post here:
>>
AM, Jason van Zyl wrote:
>
>> We had the hangout yesterday. I pushed the initial bit of information
>> about evolving the POM format here in a blog post here:
>>
>> http://localhost:4000/2014/06/19/hangout-pom-format.html
>>
>> And created a pa
is a link of the recording, if any?
>
>
> Thanks,
> ~t~
>
>
> On Thu, Jun 19, 2014 at 3:40 PM, Jason van Zyl wrote:
>
>> We had the hangout yesterday. I pushed the initial bit of information
>> about evolving the POM format here in a blog post here:
>>
>&
ng the POM format here in a blog post here:
>
> http://localhost:4000/2014/06/19/hangout-pom-format.html
>
> And created a page in the Wiki to start capturing the information:
>
> https://cwiki.apache.org/confluence/display/MAVEN/Evolving+the+POM+Form
The links are broken due to use of "localhost".
Gary
On Thu, Jun 19, 2014 at 9:40 AM, Jason van Zyl wrote:
> We had the hangout yesterday. I pushed the initial bit of information
> about evolving the POM format here in a blog post here:
>
> http://localhost:4000/
Jason, I am sure accessing your localhost is blocked :-)
Cheers,
Paul
On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl wrote:
> We had the hangout yesterday. I pushed the initial bit of information
> about evolving the POM format here in a blog post here:
>
> http://localhost:400
We had the hangout yesterday. I pushed the initial bit of information about
evolving the POM format here in a blog post here:
http://localhost:4000/2014/06/19/hangout-pom-format.html
And created a page in the Wiki to start capturing the information:
https://cwiki.apache.org/confluence/display
31 matches
Mail list logo
