You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <jv...@sonatype.com> on 2008/12/15 21:02:45 UTC
POM construction specification
This is for the general population but I'm nudging you Ralph because I
know that you want to make some changes for not requiring the version
in the parent element.
I don't think I'll be too keen on making substantive changes to how
the POM is constructed until alpha-3/4 (because we need to deal with
the thorny issue of interoperability between versions of the POM and
version of Maven) but have a look at this:
http://svn.apache.org/repos/asf/maven/components/trunk/maven-project-spec.pdf
Shane tried to codify the behavior as much as possible into this spec
and I think it servers as the new location for existing behavior and
changes we want to make in the future. I think we can clearly mark
proposals and then transition them into the document proper as
proposals are accepted.
This is really to get the ball rolling and get your thoughts as you
have the only concrete proposal that's been tested I know of. I am
going to translate that document into Confluence markup as I don't
think Tex is very popular. Once that is done we can also incorporate
proposals that have been made by users and link back to the JIRA. This
should make the behavior more visible and potential changes known.
We'll have something similar for Mercury which will tie the whole
process together but this is a place to start.
(The Tex source is right beside the PDF if you actually want to edit
the Tex content)
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole
-- Christopher Alexander, A Pattern Language
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Mixins (was Re: POM construction specification)
Posted by Shane Isbell <sh...@gmail.com>.
The Nixon is not crooked, it doesn't need processing.
On Thu, Dec 18, 2008 at 10:08 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> 2008/12/18 Brian Fox <br...@reply.infinity.nu>
>
> > filtering or processing of it? I think it's just better to keep
> processing
> > of the Nixon separate.
> >
> > --Brian (mobile)
>
>
> I don't know that you'll ever get to process the Nixon... the best you can
> do is get him to do is resign, but his successor will probably pardon him
> so
> you'll be unable to process him. ;-)
>
Re: Mixins (was Re: POM construction specification)
Posted by Stephen Connolly <st...@gmail.com>.
2008/12/18 Jason van Zyl <jv...@sonatype.com>
> On 18-Dec-08, at 3:02 PM, Stephen Connolly wrote:
>
>> Actually, I'm liking the Nixon name for these mixins
>>
> No chance.
>
So you're saying that chance is not a factor.... hmm sounds like a done deal
so!
Re: Mixins (was Re: POM construction specification)
Posted by Jason van Zyl <jv...@sonatype.com>.
LOL
On 18-Dec-08, at 3:07 PM, Shane Isbell wrote:
> On Thu, Dec 18, 2008 at 12:02 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> Actually, I'm liking the Nixon name for these mixins
>
> Sure, why not? We can just call mavenized mixins, Nixons. Now I just
> need a
> big pen to start blacking out sections of the spec.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more
examples
you look at, the more general your framework will be.
-- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Mixins (was Re: POM construction specification)
Posted by Shane Isbell <sh...@gmail.com>.
On Thu, Dec 18, 2008 at 12:02 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> Actually, I'm liking the Nixon name for these mixins
Sure, why not? We can just call mavenized mixins, Nixons. Now I just need a
big pen to start blacking out sections of the spec.
Re: Mixins (was Re: POM construction specification)
Posted by Jason van Zyl <jv...@sonatype.com>.
On 18-Dec-08, at 3:02 PM, Stephen Connolly wrote:
> Actually, I'm liking the Nixon name for these mixins
>
No chance.
> 2008/12/18 Ralph Goers <ra...@dslextreme.com>
>
>>
>> On Dec 18, 2008, at 9:56 AM, Brian Fox wrote:
>>
>> It's not just about ignorig the ids. What about the distmgt info that
>>> would be needed to deploy... Or filtering or processing of it? I
>>> think it's
>>> just better to keep processing of the Nixon separate.
>>>
>>>
>> Yes, I agree (except with the Nixon name). I just used the
>> coordinates as
>> an example.
>>
>>
>> Ralph
>>
>> ---------------------------------------------------------------------
>> 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
jason at sonatype dot com
----------------------------------------------------------
Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.
-- Eric Hoffer, Reflections on the Human Condition
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Mixins (was Re: POM construction specification)
Posted by Stephen Connolly <st...@gmail.com>.
Actually, I'm liking the Nixon name for these mixins
2008/12/18 Ralph Goers <ra...@dslextreme.com>
>
> On Dec 18, 2008, at 9:56 AM, Brian Fox wrote:
>
> It's not just about ignorig the ids. What about the distmgt info that
>> would be needed to deploy... Or filtering or processing of it? I think it's
>> just better to keep processing of the Nixon separate.
>>
>>
> Yes, I agree (except with the Nixon name). I just used the coordinates as
> an example.
>
>
> Ralph
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: POM construction specification
Posted by Jason van Zyl <jv...@sonatype.com>.
On 18-Dec-08, at 9:17 AM, Brian E. Fox wrote:
> I mentioned an idea in my review that seems to have been overlooked. I
> think a regular .pom in the repository shouldn't be able to be used
> as a
> "mixin".
In my examples it is a normal POM that parses on its own, but I
actually need something now would make it not parse. Anyway I want to
refactor for a while before I attempt to make a branch for this.
> We should keep inheritance and mixins separate. The way I would
> do it is with a new packaging type of mixin that would take another
> xml
> file like mixin.xml and deploy that to the repository, similar to a
> classified artifact. You have the mixin's pom and then the mixin
> itself.
> Only the mixin file can be used for inclusion in a <mixin> element.
> This
> way the mixin can be abstract and only contain the appropriate
> fragments, yet have a separate pom with all the info needed to build
> and
> deploy said mixin to a remote repository. Mixins are useless if they
> can't be put into a repo.
>
> anyone wanna play a drinking game on the thread for each mixin
> mention?
> ;-)
>
> -----Original Message-----
> From: Shane Isbell [mailto:shane.isbell@gmail.com]
> Sent: Thursday, December 18, 2008 2:57 AM
> To: Maven Developers List
> Subject: Re: POM construction specification
>
> On Wed, Dec 17, 2008 at 11:49 PM, Ralph Goers
> <ra...@dslextreme.com>wrote:
>
>>
>> On Dec 17, 2008, at 11:31 PM, Shane Isbell wrote:
>>
>>
>>>> And I've said multiple times that that isn't an adequate
>>>> definition.
>>>> Jason's post provided a better clue but still doesn't define it.
> Your
>>>> definition is about like me telling you that I am heading a JCP
> committee
>>>> to
>>>> define a new Java entity called mixin and in it you will be able to
> use
>>>> all
>>>> the existing java grammar but I tell you nothing more than that.
> Would
>>>> you
>>>> have a clue how that is useful?
>>>>
>>>
>>> No it wouldn't be useful. But if you said a mixin is like an
>>> abstract
>>> class
>>> and all it's elements can be inherited exactly like an abstract
> class,
>>> then
>>> I would have a pretty good clue.
>>>
>>>
>> Yes and no. Yes, that would be understandable but it would also be
>> inaccurate. The problem here is that you are introducing multiple
>> inheritance into the mix so that analogy doesn't fit.
>
> If we are talking about linearized inheritance, then the analogy is
> correct.
>
> Maven doesn't currently support that and I think that is a very good
> thing.
>
> The super pom is a type of multiple (linearized) inheritance.
>
> Shane
>
> ---------------------------------------------------------------------
> 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
jason at sonatype dot com
----------------------------------------------------------
Simplex sigillum veri. (Simplicity is the seal of truth.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Mixins (was Re: POM construction specification)
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Gotta love Iphone autocorrect ;-)
-----Original Message-----
From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
Sent: Thursday, December 18, 2008 1:09 PM
To: Maven Developers List
Subject: Re: Mixins (was Re: POM construction specification)
2008/12/18 Brian Fox <br...@reply.infinity.nu>
> filtering or processing of it? I think it's just better to keep
processing
> of the Nixon separate.
>
> --Brian (mobile)
I don't know that you'll ever get to process the Nixon... the best you
can
do is get him to do is resign, but his successor will probably pardon
him so
you'll be unable to process him. ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Mixins (was Re: POM construction specification)
Posted by Stephen Connolly <st...@gmail.com>.
2008/12/18 Brian Fox <br...@reply.infinity.nu>
> filtering or processing of it? I think it's just better to keep processing
> of the Nixon separate.
>
> --Brian (mobile)
I don't know that you'll ever get to process the Nixon... the best you can
do is get him to do is resign, but his successor will probably pardon him so
you'll be unable to process him. ;-)
Re: Mixins (was Re: POM construction specification)
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 18, 2008, at 9:56 AM, Brian Fox wrote:
> It's not just about ignorig the ids. What about the distmgt info
> that would be needed to deploy... Or filtering or processing of it?
> I think it's just better to keep processing of the Nixon separate.
>
Yes, I agree (except with the Nixon name). I just used the coordinates
as an example.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Mixins (was Re: POM construction specification)
Posted by Brian Fox <br...@reply.infinity.nu>.
It's not just about ignorig the ids. What about the distmgt info that
would be needed to deploy... Or filtering or processing of it? I think
it's just better to keep processing of the Nixon separate.
--Brian (mobile)
On Dec 18, 2008, at 10:15 AM, Ralph Goers <ra...@dslextreme.com>
wrote:
>
> On Dec 18, 2008, at 6:17 AM, Brian E. Fox wrote:
>
>> I mentioned an idea in my review that seems to have been
>> overlooked. I
>> think a regular .pom in the repository shouldn't be able to be used
>> as a
>> "mixin". We should keep inheritance and mixins separate. The way I
>> would
>> do it is with a new packaging type of mixin that would take another
>> xml
>> file like mixin.xml and deploy that to the repository, similar to a
>> classified artifact. You have the mixin's pom and then the mixin
>> itself.
>> Only the mixin file can be used for inclusion in a <mixin> element.
>> This
>> way the mixin can be abstract and only contain the appropriate
>> fragments, yet have a separate pom with all the info needed to
>> build and
>> deploy said mixin to a remote repository. Mixins are useless if they
>> can't be put into a repo.
>
> No, this wasn't overlooked. I hadn't thought of just using a new
> packaging type. I was thinking of a different file extension but
> using a new packaging type makes much more sense. However, I'm not
> sure having a separate file is really necessary. Just requiring the
> mixin to have a version, artifactId and groupId and having those be
> ignored when injecting the mixin should be suficient. And having the
> packaging type of mixin would also prevent the pom from being used
> in any other way - unless, of course, we want to allow mixins to be
> able to have a parent mixin.
>>
>>
>> anyone wanna play a drinking game on the thread for each mixin
>> mention?
>> ;-)
>
> No thanks. Too early in the morning :-)
>
> Ralph
>
>
> ---------------------------------------------------------------------
> 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: Mixins (was Re: POM construction specification)
Posted by Jason van Zyl <jv...@sonatype.com>.
I think mixins are important, but I think in the short term trying to
focus on bring the spec up to what is known to be the behavior right
now is the focus. Once all those tests are done and the spec is
comprehensive with an appendix, has example, and where tests refer to
sections in the POM then I think we can move on to new features and
changes. It's too early right now.
On 18-Dec-08, at 10:15 AM, Ralph Goers wrote:
>
> On Dec 18, 2008, at 6:17 AM, Brian E. Fox wrote:
>
>> I mentioned an idea in my review that seems to have been
>> overlooked. I
>> think a regular .pom in the repository shouldn't be able to be used
>> as a
>> "mixin". We should keep inheritance and mixins separate. The way I
>> would
>> do it is with a new packaging type of mixin that would take another
>> xml
>> file like mixin.xml and deploy that to the repository, similar to a
>> classified artifact. You have the mixin's pom and then the mixin
>> itself.
>> Only the mixin file can be used for inclusion in a <mixin> element.
>> This
>> way the mixin can be abstract and only contain the appropriate
>> fragments, yet have a separate pom with all the info needed to
>> build and
>> deploy said mixin to a remote repository. Mixins are useless if they
>> can't be put into a repo.
>
> No, this wasn't overlooked. I hadn't thought of just using a new
> packaging type. I was thinking of a different file extension but
> using a new packaging type makes much more sense. However, I'm not
> sure having a separate file is really necessary. Just requiring the
> mixin to have a version, artifactId and groupId and having those be
> ignored when injecting the mixin should be suficient. And having the
> packaging type of mixin would also prevent the pom from being used
> in any other way - unless, of course, we want to allow mixins to be
> able to have a parent mixin.
>>
>>
>> anyone wanna play a drinking game on the thread for each mixin
>> mention?
>> ;-)
>
> No thanks. Too early in the morning :-)
>
> Ralph
>
>
> ---------------------------------------------------------------------
> 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
jason at sonatype dot com
----------------------------------------------------------
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Mixins (was Re: POM construction specification)
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 18, 2008, at 6:17 AM, Brian E. Fox wrote:
> I mentioned an idea in my review that seems to have been overlooked. I
> think a regular .pom in the repository shouldn't be able to be used
> as a
> "mixin". We should keep inheritance and mixins separate. The way I
> would
> do it is with a new packaging type of mixin that would take another
> xml
> file like mixin.xml and deploy that to the repository, similar to a
> classified artifact. You have the mixin's pom and then the mixin
> itself.
> Only the mixin file can be used for inclusion in a <mixin> element.
> This
> way the mixin can be abstract and only contain the appropriate
> fragments, yet have a separate pom with all the info needed to build
> and
> deploy said mixin to a remote repository. Mixins are useless if they
> can't be put into a repo.
No, this wasn't overlooked. I hadn't thought of just using a new
packaging type. I was thinking of a different file extension but
using a new packaging type makes much more sense. However, I'm not
sure having a separate file is really necessary. Just requiring the
mixin to have a version, artifactId and groupId and having those be
ignored when injecting the mixin should be suficient. And having the
packaging type of mixin would also prevent the pom from being used in
any other way - unless, of course, we want to allow mixins to be able
to have a parent mixin.
>
>
> anyone wanna play a drinking game on the thread for each mixin
> mention?
> ;-)
No thanks. Too early in the morning :-)
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: POM construction specification
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I mentioned an idea in my review that seems to have been overlooked. I
think a regular .pom in the repository shouldn't be able to be used as a
"mixin". We should keep inheritance and mixins separate. The way I would
do it is with a new packaging type of mixin that would take another xml
file like mixin.xml and deploy that to the repository, similar to a
classified artifact. You have the mixin's pom and then the mixin itself.
Only the mixin file can be used for inclusion in a <mixin> element. This
way the mixin can be abstract and only contain the appropriate
fragments, yet have a separate pom with all the info needed to build and
deploy said mixin to a remote repository. Mixins are useless if they
can't be put into a repo.
anyone wanna play a drinking game on the thread for each mixin mention?
;-)
-----Original Message-----
From: Shane Isbell [mailto:shane.isbell@gmail.com]
Sent: Thursday, December 18, 2008 2:57 AM
To: Maven Developers List
Subject: Re: POM construction specification
On Wed, Dec 17, 2008 at 11:49 PM, Ralph Goers
<ra...@dslextreme.com>wrote:
>
> On Dec 17, 2008, at 11:31 PM, Shane Isbell wrote:
>
>
>>> And I've said multiple times that that isn't an adequate definition.
>>> Jason's post provided a better clue but still doesn't define it.
Your
>>> definition is about like me telling you that I am heading a JCP
committee
>>> to
>>> define a new Java entity called mixin and in it you will be able to
use
>>> all
>>> the existing java grammar but I tell you nothing more than that.
Would
>>> you
>>> have a clue how that is useful?
>>>
>>
>> No it wouldn't be useful. But if you said a mixin is like an abstract
>> class
>> and all it's elements can be inherited exactly like an abstract
class,
>> then
>> I would have a pretty good clue.
>>
>>
> Yes and no. Yes, that would be understandable but it would also be
> inaccurate. The problem here is that you are introducing multiple
> inheritance into the mix so that analogy doesn't fit.
If we are talking about linearized inheritance, then the analogy is
correct.
Maven doesn't currently support that and I think that is a very good
thing.
The super pom is a type of multiple (linearized) inheritance.
Shane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM construction specification
Posted by Shane Isbell <sh...@gmail.com>.
On Wed, Dec 17, 2008 at 11:49 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>
> On Dec 17, 2008, at 11:31 PM, Shane Isbell wrote:
>
>
>>> And I've said multiple times that that isn't an adequate definition.
>>> Jason's post provided a better clue but still doesn't define it. Your
>>> definition is about like me telling you that I am heading a JCP committee
>>> to
>>> define a new Java entity called mixin and in it you will be able to use
>>> all
>>> the existing java grammar but I tell you nothing more than that. Would
>>> you
>>> have a clue how that is useful?
>>>
>>
>> No it wouldn't be useful. But if you said a mixin is like an abstract
>> class
>> and all it's elements can be inherited exactly like an abstract class,
>> then
>> I would have a pretty good clue.
>>
>>
> Yes and no. Yes, that would be understandable but it would also be
> inaccurate. The problem here is that you are introducing multiple
> inheritance into the mix so that analogy doesn't fit.
If we are talking about linearized inheritance, then the analogy is
correct.
Maven doesn't currently support that and I think that is a very good thing.
The super pom is a type of multiple (linearized) inheritance.
Shane
Re: POM construction specification
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 17, 2008, at 11:31 PM, Shane Isbell wrote:
>>
>> And I've said multiple times that that isn't an adequate definition.
>> Jason's post provided a better clue but still doesn't define it.
>> Your
>> definition is about like me telling you that I am heading a JCP
>> committee to
>> define a new Java entity called mixin and in it you will be able to
>> use all
>> the existing java grammar but I tell you nothing more than that.
>> Would you
>> have a clue how that is useful?
>
> No it wouldn't be useful. But if you said a mixin is like an
> abstract class
> and all it's elements can be inherited exactly like an abstract
> class, then
> I would have a pretty good clue.
>
Yes and no. Yes, that would be understandable but it would also be
inaccurate. The problem here is that you are introducing multiple
inheritance into the mix so that analogy doesn't fit. Maven doesn't
currently support that and I think that is a very good thing. Treating
a mixin on an equal footing with the parent pom is just wrong IMO.
Treating it like an aspect or as a way of "importing" things into a
pom is OK as long as the rules are well defined.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM construction specification
Posted by Shane Isbell <sh...@gmail.com>.
On Wed, Dec 17, 2008 at 11:22 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>
> On Dec 17, 2008, at 10:57 PM, Shane Isbell wrote:
>
> On Wed, Dec 17, 2008 at 9:47 PM, Ralph Goers <ralph.goers@dslextreme.com
>> >wrote:
>>
>>
>>> On Dec 17, 2008, at 9:27 AM, Shane Isbell wrote:
>>>
>>>
>>>>
>>>>
>>>>
>>>> I guess I really have no clue what functionality a mixin is supposed to
>>>>> provide or how it would be retrieved without a version or groupid. Is
>>>>> it
>>>>> being suggested they would be stored in the repo without that? I'd need
>>>>> a
>>>>> lot of convincing before I could buy off on that.
>>>>>
>>>>>
>>>> That's more of a specific case of what we would need to resolve a mixin
>>>> remotely. Someone may also choose to add mixins programmatically or have
>>>> them taken from the file system. Neither of these cases would require a
>>>> version or groupId. Narrowing the definition of a mixin for one specific
>>>> case, limits its power.
>>>>
>>>>
>>>> You've totally lost me, primarily because you've still not defined what
>>> a
>>> mixin is.
>>>
>>
>> I've defined mixin within the spec and multiple times in this thread: a
>> mixin is an abstract model, meaning it is not required to have all the
>> required elements of a full pom.
>>
>
> And I've said multiple times that that isn't an adequate definition.
> Jason's post provided a better clue but still doesn't define it. Your
> definition is about like me telling you that I am heading a JCP committee to
> define a new Java entity called mixin and in it you will be able to use all
> the existing java grammar but I tell you nothing more than that. Would you
> have a clue how that is useful?
No it wouldn't be useful. But if you said a mixin is like an abstract class
and all it's elements can be inherited exactly like an abstract class, then
I would have a pretty good clue.
Shane
Re: POM construction specification
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 17, 2008, at 10:57 PM, Shane Isbell wrote:
> On Wed, Dec 17, 2008 at 9:47 PM, Ralph Goers <ralph.goers@dslextreme.com
> >wrote:
>
>>
>> On Dec 17, 2008, at 9:27 AM, Shane Isbell wrote:
>>
>>>
>>>
>>>
>>>
>>>> I guess I really have no clue what functionality a mixin is
>>>> supposed to
>>>> provide or how it would be retrieved without a version or
>>>> groupid. Is it
>>>> being suggested they would be stored in the repo without that?
>>>> I'd need a
>>>> lot of convincing before I could buy off on that.
>>>>
>>>
>>> That's more of a specific case of what we would need to resolve a
>>> mixin
>>> remotely. Someone may also choose to add mixins programmatically
>>> or have
>>> them taken from the file system. Neither of these cases would
>>> require a
>>> version or groupId. Narrowing the definition of a mixin for one
>>> specific
>>> case, limits its power.
>>>
>>>
>> You've totally lost me, primarily because you've still not defined
>> what a
>> mixin is.
>
> I've defined mixin within the spec and multiple times in this
> thread: a
> mixin is an abstract model, meaning it is not required to have all the
> required elements of a full pom.
And I've said multiple times that that isn't an adequate definition.
Jason's post provided a better clue but still doesn't define it. Your
definition is about like me telling you that I am heading a JCP
committee to define a new Java entity called mixin and in it you will
be able to use all the existing java grammar but I tell you nothing
more than that. Would you have a clue how that is useful?
>
>
>
>> I'm also confused as to whether this document is supposed to
>> document Maven
>> as it currently is or with some set of enhancements. I've seen
>> answers that
>> imply that right now it should just document what currently exists.
>
> The model-builder supports the capability to add mixins (as defined
> above).
> We still need to spec out how we want to handle things like resolving.
I assume you mean the model-builder for 3.0? I guess I'll have to look
at the code to figure out what is actually going on.
>
>
>>
>>
>> In the long run I'm probably going to be in favor of only allowing
>> single
>> inheritance from a parent model. I might be inclined to agree with
>> multiple
>> mixins if they were actually defined.
>
> They are defined. See above.
Not in any meaningful way. See above.
>
>
>
>> Adding mixins programatically offhand seems like a horrible idea
>> but that
>> is probably because I'm sure I don't know what you have in mind.
>>
>> In short, I would recommend either removing mention of mixins from
>> the
>> document or actually documenting them.
>
> It is documented.
<sigh>
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM construction specification
Posted by Shane Isbell <sh...@gmail.com>.
On Wed, Dec 17, 2008 at 9:47 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>
> On Dec 17, 2008, at 9:27 AM, Shane Isbell wrote:
>
>>
>>
>>
>>
>>> I guess I really have no clue what functionality a mixin is supposed to
>>> provide or how it would be retrieved without a version or groupid. Is it
>>> being suggested they would be stored in the repo without that? I'd need a
>>> lot of convincing before I could buy off on that.
>>>
>>
>> That's more of a specific case of what we would need to resolve a mixin
>> remotely. Someone may also choose to add mixins programmatically or have
>> them taken from the file system. Neither of these cases would require a
>> version or groupId. Narrowing the definition of a mixin for one specific
>> case, limits its power.
>>
>>
> You've totally lost me, primarily because you've still not defined what a
> mixin is.
I've defined mixin within the spec and multiple times in this thread: a
mixin is an abstract model, meaning it is not required to have all the
required elements of a full pom.
> I'm also confused as to whether this document is supposed to document Maven
> as it currently is or with some set of enhancements. I've seen answers that
> imply that right now it should just document what currently exists.
The model-builder supports the capability to add mixins (as defined above).
We still need to spec out how we want to handle things like resolving.
>
>
> In the long run I'm probably going to be in favor of only allowing single
> inheritance from a parent model. I might be inclined to agree with multiple
> mixins if they were actually defined.
They are defined. See above.
> Adding mixins programatically offhand seems like a horrible idea but that
> is probably because I'm sure I don't know what you have in mind.
>
> In short, I would recommend either removing mention of mixins from the
> document or actually documenting them.
It is documented.
Thanks,
Shane
Re: POM construction specification
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 17, 2008, at 11:15 PM, Shane Isbell wrote:
> On Wed, Dec 17, 2008 at 10:35 PM, Ralph Goers <ralph.goers@dslextreme.com
> >wrote:
>
>> OK - I'm looking forward to seeing this. I understand the
>> programmatic
>> aspect in the use case you describe with the IDE, but not with
>> something
>> like the release capability. IIUC this would allow our organization
>> to
>> create a standard way of doing something and then somehow make it
>> available
>> to everyone. That would be a good thing. But I don't understand
>> how that
>> could work without locating it in a remote repo just as a pom is
>> currently
>> located.
>
> Consider the following case: Someone may decide to put a mixin file
> in their
> build. The mixin then gets applied to the pom. Any deployed or
> installed pom
> from the build has the mixins applied. In this case, mixins are
> never even
> in the remote repo.
I doubt that would be the normal case, except when used for tools as
Jason described. Even then I suspect most of them would still be
deployed. Also, the document shows mixins being retrieved in the
normal fashion by groupId, artifactId and version. If they can be
included in some other way it isn't documented.
>
>
> And while it may not be required to have an artifactId, version and
> groupId
>> in the programmatic case I simply can't think of a good reason not to
>> require it anyway.
>
> One reason may be that the version and groupId would then be mixed
> into a
> pom when you may not want it to be.
That should never happen. The mixin definition should make that clear.
Since version, groupId and artifactId CAN be specified in the mixin
they have to be ignored.
>
>
>>
>>
>> From what you are describing it sounds like a mixin will
>> essentially just
>> be a pom (hopefully with a different extension) that uses somewhat
>> different
>> rules to merge with the pom referencing it. If that indeed is what
>> it is
>> then I like the idea, but the devil is in the details - as it
>> always is
>> around here. Since this isn't inheritance the rules specified in
>> the current
>> document probably don't completely apply to mixins.
>
> A mixin is a type of inheritance so the same rules apply.
Absolutely not. From the way it has been described, a mixin is more
like an aspect in Java. It is injecting behavior or attributes into a
project, the project is not inheriting them.
>
>
>
>> For example, if the mixin defines a plugin and the project
>> referencing it
>> does also what happens? I wouldn't necessarily expect the same
>> behavior as I
>> would with the parent/child relationship.
>
> It's the same behavior. If you place a mixin below a pom in the
> relationship, then the mixin gets priority; it you place the mixin
> above the
> pom in the hierarchy, the child gets the priority.
Huh? I assume you mean in the XML of a pom? Are you saying that
defining a mixin before the parent element causes the mixin to take
precedence over the parent or if it is after then the parent wins?
Frankly, I wasn't even talking about the parent. I was talking about
the mixin and how it relates to the definitions within the same pom
where the mixin is referenced. I'm quite certain there will be cases
where it is not desirable to have the behavior of including a mixin to
be the same as inheriting from a parent.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM construction specification
Posted by Shane Isbell <sh...@gmail.com>.
On Wed, Dec 17, 2008 at 10:35 PM, Ralph Goers <ra...@dslextreme.com>wrote:
> OK - I'm looking forward to seeing this. I understand the programmatic
> aspect in the use case you describe with the IDE, but not with something
> like the release capability. IIUC this would allow our organization to
> create a standard way of doing something and then somehow make it available
> to everyone. That would be a good thing. But I don't understand how that
> could work without locating it in a remote repo just as a pom is currently
> located.
Consider the following case: Someone may decide to put a mixin file in their
build. The mixin then gets applied to the pom. Any deployed or installed pom
from the build has the mixins applied. In this case, mixins are never even
in the remote repo.
And while it may not be required to have an artifactId, version and groupId
> in the programmatic case I simply can't think of a good reason not to
> require it anyway.
One reason may be that the version and groupId would then be mixed into a
pom when you may not want it to be.
>
>
> From what you are describing it sounds like a mixin will essentially just
> be a pom (hopefully with a different extension) that uses somewhat different
> rules to merge with the pom referencing it. If that indeed is what it is
> then I like the idea, but the devil is in the details - as it always is
> around here. Since this isn't inheritance the rules specified in the current
> document probably don't completely apply to mixins.
A mixin is a type of inheritance so the same rules apply.
> For example, if the mixin defines a plugin and the project referencing it
> does also what happens? I wouldn't necessarily expect the same behavior as I
> would with the parent/child relationship.
It's the same behavior. If you place a mixin below a pom in the
relationship, then the mixin gets priority; it you place the mixin above the
pom in the hierarchy, the child gets the priority.
Shane
Re: POM construction specification
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 18, 2008, at 8:34 AM, Jason van Zyl wrote:
>
> On 18-Dec-08, at 1:35 AM, Ralph Goers wrote:
>
>> OK - I'm looking forward to seeing this. I understand the
>> programmatic aspect in the use case you describe with the IDE, but
>> not with something like the release capability. IIUC this would
>> allow our organization to create a standard way of doing something
>> and then somehow make it available to everyone.
>
> Exactly.
>
>> That would be a good thing. But I don't understand how that could
>> work without locating it in a remote repo just as a pom is
>> currently located. And while it may not be required to have an
>> artifactId, version and groupId in the programmatic case I simply
>> can't think of a good reason not to require it anyway.
>
> In this case you definitely need a coordinate to find it. The mixin
> case just can support bits where there isn't a complete coordinate.
> I don't know if in practice that would be useful yet. I need a
> coordinate for my example.
>
>>
>>
>> From what you are describing it sounds like a mixin will
>> essentially just be a pom (hopefully with a different extension)
>> that uses somewhat different rules to merge with the pom
>> referencing it. If that indeed is what it is then I like the idea,
>> but the devil is in the details - as it always is around here.
>> Since this isn't inheritance the rules specified in the current
>> document probably don't completely apply to mixins. For example,
>> if the mixin defines a plugin and the project referencing it does
>> also what happens? I wouldn't necessarily expect the same behavior
>> as I would with the parent/child relationship.
>
> The mixin would be contributed as if you had placed all the elements
> in your POM yourself. So essentially you contribute a set of
> properties to the model, and then the transformation process is run.
> So we need to define what bits go where but then the spec kicks in.
> The behavior probably wouldn't be exactly like parent/child because
> it is a composition model. Trying out the two examples I mentioned
> should be relatively easy but I don't expect I want to try that
> until alpha-3 or 4. I just want to write tests for a while and do
> some refactoring and stamp out regressions.
I am in complete agreement with what you are describing here.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM construction specification
Posted by Jason van Zyl <jv...@sonatype.com>.
On 18-Dec-08, at 1:35 AM, Ralph Goers wrote:
> OK - I'm looking forward to seeing this. I understand the
> programmatic aspect in the use case you describe with the IDE, but
> not with something like the release capability. IIUC this would
> allow our organization to create a standard way of doing something
> and then somehow make it available to everyone.
Exactly.
> That would be a good thing. But I don't understand how that could
> work without locating it in a remote repo just as a pom is currently
> located. And while it may not be required to have an artifactId,
> version and groupId in the programmatic case I simply can't think of
> a good reason not to require it anyway.
In this case you definitely need a coordinate to find it. The mixin
case just can support bits where there isn't a complete coordinate. I
don't know if in practice that would be useful yet. I need a
coordinate for my example.
>
>
> From what you are describing it sounds like a mixin will essentially
> just be a pom (hopefully with a different extension) that uses
> somewhat different rules to merge with the pom referencing it. If
> that indeed is what it is then I like the idea, but the devil is in
> the details - as it always is around here. Since this isn't
> inheritance the rules specified in the current document probably
> don't completely apply to mixins. For example, if the mixin defines
> a plugin and the project referencing it does also what happens? I
> wouldn't necessarily expect the same behavior as I would with the
> parent/child relationship.
The mixin would be contributed as if you had placed all the elements
in your POM yourself. So essentially you contribute a set of
properties to the model, and then the transformation process is run.
So we need to define what bits go where but then the spec kicks in.
The behavior probably wouldn't be exactly like parent/child because it
is a composition model. Trying out the two examples I mentioned should
be relatively easy but I don't expect I want to try that until alpha-3
or 4. I just want to write tests for a while and do some refactoring
and stamp out regressions.
>
>
> Ralph
>
>
> On Dec 17, 2008, at 10:09 PM, Jason van Zyl wrote:
>
>>
>> On 18-Dec-08, at 12:47 AM, Ralph Goers wrote:
>>
>>>
>>> On Dec 17, 2008, at 9:27 AM, Shane Isbell wrote:
>>>>
>>>>
>>>>
>>>>>
>>>>> I guess I really have no clue what functionality a mixin is
>>>>> supposed to
>>>>> provide or how it would be retrieved without a version or
>>>>> groupid. Is it
>>>>> being suggested they would be stored in the repo without that?
>>>>> I'd need a
>>>>> lot of convincing before I could buy off on that.
>>>>
>>>> That's more of a specific case of what we would need to resolve a
>>>> mixin
>>>> remotely. Someone may also choose to add mixins programmatically
>>>> or have
>>>> them taken from the file system. Neither of these cases would
>>>> require a
>>>> version or groupId. Narrowing the definition of a mixin for one
>>>> specific
>>>> case, limits its power.
>>>>
>>>
>>> You've totally lost me, primarily because you've still not defined
>>> what a mixin is.
>>
>> What I'm going to try to implement first is a mixin that would
>> contain a capability, say the capability to release. The mixin
>> would have some plugins, configuration, and contain properties that
>> can be parameterized. So this would allow someone to use
>> composition to add the capability the Maven project currently has
>> to release projects. We do sources, javadocs, have the remote
>> resources plugin kick in, and sign the artifacts. Turning this into
>> a mixin would allow anyone to use it. Another example I would like
>> to try is to have a mixin for Plexus component creation:
>> automatically tie in metadata generation for which I need a couple
>> dependencies and a couple plugins. So a contribution model of
>> sorts, the mixin would not just be inserted into the current model
>> but the parts of the mixin contributed to the appropriate parts of
>> the current model. Maybe call it a smart import or maybe even a
>> sharable profile. It's certainly not limited to this but this is
>> what I wanted to implement first as a way for people to share
>> thought out and well tested capabilities. I'm sure many projects
>> would pick up our release bits if it weren't such a pain in the ass.
>>
>>> I'm also confused as to whether this document is supposed to
>>> document Maven as it currently is or with some set of
>>> enhancements. I've seen answers that imply that right now it
>>> should just document what currently exists.
>>
>> We are definitely trying to capture what exists with no
>> modification until such a time as we can deal with multiple
>> versions of the model.
>>
>>>
>>>
>>> In the long run I'm probably going to be in favor of only allowing
>>> single inheritance from a parent model.
>>
>> I don't think we'll be doing multiple inheritance. Single parents
>> with mixins I think will provide all the flexibility we'll need.
>>
>>> I might be inclined to agree with multiple mixins if they were
>>> actually defined. Adding mixins programatically offhand seems like
>>> a horrible idea but that is probably because I'm sure I don't know
>>> what you have in mind.
>>
>> Here IDE integration might be the target. A user might pick some
>> mixins for some sort of debugging capability and activate this via
>> a UI. I just throwing out a sample idea but it would probably be
>> tool integration. I doubt anyone would do this using the CLI itself.
>>
>>>
>>>
>>> In short, I would recommend either removing mention of mixins from
>>> the document or actually documenting them.
>>>
>>
>> I'm writing tests for the spec at the moment but I'll commit the
>> two that I'm working on. The two I mentioned above.
>>
>>> Ralph
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>> People develop abstractions by generalizing from concrete examples.
>> Every attempt to determine the correct abstraction on paper without
>> actually developing a running system is doomed to failure. No one
>> is that smart. A framework is a resuable design, so you develop it by
>> looking at the things it is supposed to be a design of. The more
>> examples
>> you look at, the more general your framework will be.
>>
>> -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
>>
>>
>> ---------------------------------------------------------------------
>> 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
jason at sonatype dot com
----------------------------------------------------------
To do two things at once is to do neither.
-—Publilius Syrus, Roman slave, first century B.C.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM construction specification
Posted by Ralph Goers <ra...@dslextreme.com>.
OK - I'm looking forward to seeing this. I understand the programmatic
aspect in the use case you describe with the IDE, but not with
something like the release capability. IIUC this would allow our
organization to create a standard way of doing something and then
somehow make it available to everyone. That would be a good thing.
But I don't understand how that could work without locating it in a
remote repo just as a pom is currently located. And while it may not
be required to have an artifactId, version and groupId in the
programmatic case I simply can't think of a good reason not to require
it anyway.
From what you are describing it sounds like a mixin will essentially
just be a pom (hopefully with a different extension) that uses
somewhat different rules to merge with the pom referencing it. If that
indeed is what it is then I like the idea, but the devil is in the
details - as it always is around here. Since this isn't inheritance
the rules specified in the current document probably don't completely
apply to mixins. For example, if the mixin defines a plugin and the
project referencing it does also what happens? I wouldn't necessarily
expect the same behavior as I would with the parent/child relationship.
Ralph
On Dec 17, 2008, at 10:09 PM, Jason van Zyl wrote:
>
> On 18-Dec-08, at 12:47 AM, Ralph Goers wrote:
>
>>
>> On Dec 17, 2008, at 9:27 AM, Shane Isbell wrote:
>>>
>>>
>>>
>>>>
>>>> I guess I really have no clue what functionality a mixin is
>>>> supposed to
>>>> provide or how it would be retrieved without a version or
>>>> groupid. Is it
>>>> being suggested they would be stored in the repo without that?
>>>> I'd need a
>>>> lot of convincing before I could buy off on that.
>>>
>>> That's more of a specific case of what we would need to resolve a
>>> mixin
>>> remotely. Someone may also choose to add mixins programmatically
>>> or have
>>> them taken from the file system. Neither of these cases would
>>> require a
>>> version or groupId. Narrowing the definition of a mixin for one
>>> specific
>>> case, limits its power.
>>>
>>
>> You've totally lost me, primarily because you've still not defined
>> what a mixin is.
>
> What I'm going to try to implement first is a mixin that would
> contain a capability, say the capability to release. The mixin would
> have some plugins, configuration, and contain properties that can be
> parameterized. So this would allow someone to use composition to add
> the capability the Maven project currently has to release projects.
> We do sources, javadocs, have the remote resources plugin kick in,
> and sign the artifacts. Turning this into a mixin would allow anyone
> to use it. Another example I would like to try is to have a mixin
> for Plexus component creation: automatically tie in metadata
> generation for which I need a couple dependencies and a couple
> plugins. So a contribution model of sorts, the mixin would not just
> be inserted into the current model but the parts of the mixin
> contributed to the appropriate parts of the current model. Maybe
> call it a smart import or maybe even a sharable profile. It's
> certainly not limited to this but this is what I wanted to implement
> first as a way for people to share thought out and well tested
> capabilities. I'm sure many projects would pick up our release bits
> if it weren't such a pain in the ass.
>
>> I'm also confused as to whether this document is supposed to
>> document Maven as it currently is or with some set of enhancements.
>> I've seen answers that imply that right now it should just document
>> what currently exists.
>
> We are definitely trying to capture what exists with no modification
> until such a time as we can deal with multiple versions of the model.
>
>>
>>
>> In the long run I'm probably going to be in favor of only allowing
>> single inheritance from a parent model.
>
> I don't think we'll be doing multiple inheritance. Single parents
> with mixins I think will provide all the flexibility we'll need.
>
>> I might be inclined to agree with multiple mixins if they were
>> actually defined. Adding mixins programatically offhand seems like
>> a horrible idea but that is probably because I'm sure I don't know
>> what you have in mind.
>
> Here IDE integration might be the target. A user might pick some
> mixins for some sort of debugging capability and activate this via a
> UI. I just throwing out a sample idea but it would probably be tool
> integration. I doubt anyone would do this using the CLI itself.
>
>>
>>
>> In short, I would recommend either removing mention of mixins from
>> the document or actually documenting them.
>>
>
> I'm writing tests for the spec at the moment but I'll commit the two
> that I'm working on. The two I mentioned above.
>
>> Ralph
>>
>>
>> ---------------------------------------------------------------------
>> 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
> jason at sonatype dot com
> ----------------------------------------------------------
>
> People develop abstractions by generalizing from concrete examples.
> Every attempt to determine the correct abstraction on paper without
> actually developing a running system is doomed to failure. No one
> is that smart. A framework is a resuable design, so you develop it by
> looking at the things it is supposed to be a design of. The more
> examples
> you look at, the more general your framework will be.
>
> -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
>
>
> ---------------------------------------------------------------------
> 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: POM construction specification
Posted by Jason van Zyl <jv...@sonatype.com>.
On 18-Dec-08, at 12:47 AM, Ralph Goers wrote:
>
> On Dec 17, 2008, at 9:27 AM, Shane Isbell wrote:
>>
>>
>>
>>>
>>> I guess I really have no clue what functionality a mixin is
>>> supposed to
>>> provide or how it would be retrieved without a version or groupid.
>>> Is it
>>> being suggested they would be stored in the repo without that? I'd
>>> need a
>>> lot of convincing before I could buy off on that.
>>
>> That's more of a specific case of what we would need to resolve a
>> mixin
>> remotely. Someone may also choose to add mixins programmatically or
>> have
>> them taken from the file system. Neither of these cases would
>> require a
>> version or groupId. Narrowing the definition of a mixin for one
>> specific
>> case, limits its power.
>>
>
> You've totally lost me, primarily because you've still not defined
> what a mixin is.
What I'm going to try to implement first is a mixin that would contain
a capability, say the capability to release. The mixin would have some
plugins, configuration, and contain properties that can be
parameterized. So this would allow someone to use composition to add
the capability the Maven project currently has to release projects. We
do sources, javadocs, have the remote resources plugin kick in, and
sign the artifacts. Turning this into a mixin would allow anyone to
use it. Another example I would like to try is to have a mixin for
Plexus component creation: automatically tie in metadata generation
for which I need a couple dependencies and a couple plugins. So a
contribution model of sorts, the mixin would not just be inserted into
the current model but the parts of the mixin contributed to the
appropriate parts of the current model. Maybe call it a smart import
or maybe even a sharable profile. It's certainly not limited to this
but this is what I wanted to implement first as a way for people to
share thought out and well tested capabilities. I'm sure many projects
would pick up our release bits if it weren't such a pain in the ass.
> I'm also confused as to whether this document is supposed to
> document Maven as it currently is or with some set of enhancements.
> I've seen answers that imply that right now it should just document
> what currently exists.
We are definitely trying to capture what exists with no modification
until such a time as we can deal with multiple versions of the model.
>
>
> In the long run I'm probably going to be in favor of only allowing
> single inheritance from a parent model.
I don't think we'll be doing multiple inheritance. Single parents with
mixins I think will provide all the flexibility we'll need.
> I might be inclined to agree with multiple mixins if they were
> actually defined. Adding mixins programatically offhand seems like a
> horrible idea but that is probably because I'm sure I don't know
> what you have in mind.
Here IDE integration might be the target. A user might pick some
mixins for some sort of debugging capability and activate this via a
UI. I just throwing out a sample idea but it would probably be tool
integration. I doubt anyone would do this using the CLI itself.
>
>
> In short, I would recommend either removing mention of mixins from
> the document or actually documenting them.
>
I'm writing tests for the spec at the moment but I'll commit the two
that I'm working on. The two I mentioned above.
> Ralph
>
>
> ---------------------------------------------------------------------
> 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
jason at sonatype dot com
----------------------------------------------------------
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more
examples
you look at, the more general your framework will be.
-- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM construction specification
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 17, 2008, at 9:27 AM, Shane Isbell wrote:
>
>
>
>>
>> I guess I really have no clue what functionality a mixin is
>> supposed to
>> provide or how it would be retrieved without a version or groupid.
>> Is it
>> being suggested they would be stored in the repo without that? I'd
>> need a
>> lot of convincing before I could buy off on that.
>
> That's more of a specific case of what we would need to resolve a
> mixin
> remotely. Someone may also choose to add mixins programmatically or
> have
> them taken from the file system. Neither of these cases would
> require a
> version or groupId. Narrowing the definition of a mixin for one
> specific
> case, limits its power.
>
You've totally lost me, primarily because you've still not defined
what a mixin is. I'm also confused as to whether this document is
supposed to document Maven as it currently is or with some set of
enhancements. I've seen answers that imply that right now it should
just document what currently exists.
In the long run I'm probably going to be in favor of only allowing
single inheritance from a parent model. I might be inclined to agree
with multiple mixins if they were actually defined. Adding mixins
programatically offhand seems like a horrible idea but that is
probably because I'm sure I don't know what you have in mind.
In short, I would recommend either removing mention of mixins from the
document or actually documenting them.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM construction specification
Posted by Shane Isbell <sh...@gmail.com>.
On Tue, Dec 16, 2008 at 11:25 PM, Ralph Goers <ra...@dslextreme.com>wrote:
> Mine below.
OK. As I read 2.2 it basically only says the first definition wins. 2.1
> talks about a collection of models, but it doesn't say anything about
> dependency resolution, either directly or in its references to section 3. In
> other words, I don't see anything that describes how the version of an
> artifact is determined when that artifact occurs in several places in the
> dependency tree.
This is an issue for Mercury and the resolving rules. It's not covered in
project building.
>
> I guess I really have no clue what functionality a mixin is supposed to
> provide or how it would be retrieved without a version or groupid. Is it
> being suggested they would be stored in the repo without that? I'd need a
> lot of convincing before I could buy off on that.
That's more of a specific case of what we would need to resolve a mixin
remotely. Someone may also choose to add mixins programmatically or have
them taken from the file system. Neither of these cases would require a
version or groupId. Narrowing the definition of a mixin for one specific
case, limits its power.
Personally, I think that including them in this list is just misleading. The
> effect is exactly the same.
The distinction is important. Take your case of not including the version in
the project.parent.version. By removing this property, pom construction
fails as it is defined in the spec. If it is a direct inheritance, it would
not fail.
Shane
Re: POM construction specification
Posted by Ralph Goers <ra...@dslextreme.com>.
Mine below.
On Dec 16, 2008, at 10:36 PM, Shane Isbell wrote:
> Comments in line
>
> On Tue, Dec 16, 2008 at 12:58 AM, Ralph Goers <ralph.goers@dslextreme.com
> >wrote:
>
>>
>> On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote:
>>
>> This is for the general population but I'm nudging you Ralph
>> because I
>>> know that you want to make some changes for not requiring the
>>> version in the
>>> parent element.
>>>
>>>
>>
>> You should have warned me to have a glass of wine before attempting
>> to read
>> all these math notations. :-) Or put a link to
>> http://en.wikipedia.org/wiki/Table_of_mathematical_symbols for
>> those of
>> use who haven't had a math class in the last 25 years. The funny
>> thing is, I
>> have a B.S. in Physics. Man it has been a long time. :-(
>>
>> Comments:
>> 2.1 & 2.2 Is all this simply stating that the closest definition
>> wins and
>> when two or more are equally close then the first one wins?
>
> 2.1 covers the high level processing starting with the
> transformation from
> the original model (XML) to the canonical model and going through
> interpolation and other rules.
> 2.2 does cover which property wins for: singletons, collections and
> sets.
OK. As I read 2.2 it basically only says the first definition wins.
2.1 talks about a collection of models, but it doesn't say anything
about dependency resolution, either directly or in its references to
section 3. In other words, I don't see anything that describes how the
version of an artifact is determined when that artifact occurs in
several places in the dependency tree.
>
>
>> 2.4 The only "definition" of mixin is "The only difference between
>> a parent
>> pro ject and a mixin is that the mixin is
>> abstract (not a complete model)". That sure leaves a lot to the
>> imagination. And what exactly makes a model "incomplete"? Isn't a
>> pom with
>> just a dependencyManagement complete? I also found myself wondering
>> that
>> even though it might be possible to support extending multiple
>> parents,
>> should we? I could see allowing only one parent but multiple mixins.
>
> A mixin wouldn't be required to have things like project.version or
> project.groupId. This makes the model abstract. From the framework's
> perspective, it's all just a linear set of complete or incomplete
> models
> Whether it's considered multiple parents or a chains of inherited
> parents,
> it's all processed the same. My take is that if it's a complete
> model, it's
> actually just another parent. We are really just dealing with
> definitions
> here, it doesn't change processing. We can discuss more on what the
> definitions should be.
I guess I really have no clue what functionality a mixin is supposed
to provide or how it would be retrieved without a version or groupid.
Is it being suggested they would be stored in the repo without that?
I'd need a lot of convincing before I could buy off on that.
>
>
>>
>> 3.4 Why can't the groupId be inherited from its parent (or at least
>> be set
>> from project.parent.groupIdt)?
>
> Technically, it isn't inherited from the parent. If groupId is not
> defined,
> the project.parent.groupId is used (footnote 1).
Personally, I think that including them in this list is just
misleading. The effect is exactly the same.
>
>
>>
>> 3.4 The footnote says the artifactId can be inherited from the
>> parent. That
>> makes no sense to me. Every pom should represent a unique artifact
>> or at
>> least a unique pom.
>
> I'll change the spec doc. But when we throw in mixins, it's not
> exactly
> clear whether things like artifactId shouldn't be inherited. This
> will be
> one area we will need to discuss as we move toward mixins.
I think you should start another thread to explain what the concept of
mixins is. You referenced it once as the "solution" for importing
managed dependencies. Some concrete examples would be nice.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM construction specification
Posted by Shane Isbell <sh...@gmail.com>.
Comments in line
On Tue, Dec 16, 2008 at 12:58 AM, Ralph Goers <ra...@dslextreme.com>wrote:
>
> On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote:
>
> This is for the general population but I'm nudging you Ralph because I
>> know that you want to make some changes for not requiring the version in the
>> parent element.
>>
>>
>
> You should have warned me to have a glass of wine before attempting to read
> all these math notations. :-) Or put a link to
> http://en.wikipedia.org/wiki/Table_of_mathematical_symbols for those of
> use who haven't had a math class in the last 25 years. The funny thing is, I
> have a B.S. in Physics. Man it has been a long time. :-(
>
> Comments:
> 2.1 & 2.2 Is all this simply stating that the closest definition wins and
> when two or more are equally close then the first one wins?
2.1 covers the high level processing starting with the transformation from
the original model (XML) to the canonical model and going through
interpolation and other rules.
2.2 does cover which property wins for: singletons, collections and sets.
> 2.4 The only "definition" of mixin is "The only difference between a parent
> pro ject and a mixin is that the mixin is
> abstract (not a complete model)". That sure leaves a lot to the
> imagination. And what exactly makes a model "incomplete"? Isn't a pom with
> just a dependencyManagement complete? I also found myself wondering that
> even though it might be possible to support extending multiple parents,
> should we? I could see allowing only one parent but multiple mixins.
A mixin wouldn't be required to have things like project.version or
project.groupId. This makes the model abstract. From the framework's
perspective, it's all just a linear set of complete or incomplete models
Whether it's considered multiple parents or a chains of inherited parents,
it's all processed the same. My take is that if it's a complete model, it's
actually just another parent. We are really just dealing with definitions
here, it doesn't change processing. We can discuss more on what the
definitions should be.
>
> 3.4 Why can't the groupId be inherited from its parent (or at least be set
> from project.parent.groupIdt)?
Technically, it isn't inherited from the parent. If groupId is not defined,
the project.parent.groupId is used (footnote 1).
>
> 3.4 The footnote says the artifactId can be inherited from the parent. That
> makes no sense to me. Every pom should represent a unique artifact or at
> least a unique pom.
I'll change the spec doc. But when we throw in mixins, it's not exactly
clear whether things like artifactId shouldn't be inherited. This will be
one area we will need to discuss as we move toward mixins.
>
> 3.5 I found the statement This will mark the container as final, thus
> preventing inheritance:" as misleading. In java terms this would mean a
> child pom attempting to define the same plugin would fail. The setting of
> "inherited" to false in the sample indicates to me the opposite, the plugin
> definition in the parent is invisible to the child. Here is a question
> though. If A overrides a plugin defined in the super pom and has inherited
> true, then B extends A and overrides the plugin and sets inherited to false,
> what will C which extends from B get? It should see the definition in A. Or
> does this whole section mean that the plugin definition in B inherits
> nothing from A?
You raise some good points. I was struggling a bit with the terms here. I'll
give it some more thought.
>
> 3.8 "the element will be inherited." Unless the parent definition has
> <inherited>false</inherited> ?
>
> I don't see anything in here about being able to locate a parent without
> having to know its version. Within the scope of the purpose of this document
> it may not be relevant, but at the very least somewhere in section 3 it
> should state that if a parent is specified than which elements are required.
Locating parents fell a bit outside of this original spec, but I think it's
worth adding something about how this is to be handled. We would need some
rule that says a parent.version is not required. And also how to cover the
situation where project.parent.version and project.version are both missing.
Thanks,
Shane
Re: POM construction specification
Posted by Ralph Goers <ra...@dslextreme.com>.
The way I read 3.4 the parent does not win. The child declaration
simply overrides the parent. Consider project developers. If specified
in a child then only those developers participate in this subproject.
developers specified in the parent are ignored. Whether it makes sense
to do it that way is a different question.
Ralph
On Dec 16, 2008, at 8:32 PM, Brian E. Fox wrote:
> "The only difference between a parent project and a mixin is that
> the mixin is
> abstract (not a complete model)."
>
> Is that really true? A Mixin should be deployed to the repository,
> which essentially means it needs to be complete enough to id and
> thus a complete model. It should be deployed as a classified
> artifact though to avoid mixing in the instructions for building/
> deploying from those that are intended to be mixed in. (ie the
> mixin's pom is separate)
>
> 3.1: what about multiple parents? I assume it's the first one, but
> should be explicit in the spec.
> 3.2: section is blank but contentious based on current behavior and
> the in-ability to use properties and inheritance together.
> 3.3: I don't understand this statement. A child always overrides the
> parent or joins with it. Are you saying that the parent wins here?
> Also pluginRepositories is going away soon. In general why can't the
> things listed here be extended?
> 3.4 shouldn't project.distMgt.relocation be inherited if the
> relocation lists the group? (group/artifact/version ones should be
> skipped, but if you're relocating everything in a group, it would
> make sense to do this at the top of that group tree pom)
> 3.5 I agree with Ralph here that Final is the wrong term. Private is
> more appropriate.
>
> I started this in the morning and didn't finish yet so sending what
> I have.
>
> -----Original Message-----
> From: Ralph Goers [mailto:ralph.goers@dslextreme.com]
> Sent: Tuesday, December 16, 2008 3:59 AM
> To: Maven Developers List
> Subject: Re: POM construction specification
>
>
> On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote:
>
>> This is for the general population but I'm nudging you Ralph because
>> I know that you want to make some changes for not requiring the
>> version in the parent element.
>>
>
>
> You should have warned me to have a glass of wine before attempting to
> read all these math notations. :-) Or put a link to http://en.wikipedia.org/wiki/Table_of_mathematical_symbols
> for those of use who haven't had a math class in the last 25 years.
> The funny thing is, I have a B.S. in Physics. Man it has been a long
> time. :-(
>
> Comments:
> 1.1 Mentions there are 465 model properties. An appendix should list
> them. Specifically, I'd like to see "provides" listed along with the
> project's groupId, artifactId and version and "requires" in the
> dependency declaration - or whatever other way that kind of metadata
> will be added.
> 2.1 & 2.2 Is all this simply stating that the closest definition wins
> and when two or more are equally close then the first one wins?
> 2.4 The only "definition" of mixin is "The only difference between a
> parent pro ject and a mixin is that the mixin is
> abstract (not a complete model)". That sure leaves a lot to the
> imagination. And what exactly makes a model "incomplete"? Isn't a pom
> with just a dependencyManagement complete? I also found myself
> wondering that even though it might be possible to support extending
> multiple parents, should we? I could see allowing only one parent but
> multiple mixins.
> 3.1 Even though may be obvious, it should explicitly state that
> artifactId is always required.
> 3.4 Why can't the groupId be inherited from its parent (or at least be
> set from project.parent.groupIdt)?
> 3.4 The footnote says the artifactId can be inherited from the parent.
> That makes no sense to me. Every pom should represent a unique
> artifact or at least a unique pom.
> 3.5 I found the statement This will mark the container as final, thus
> preventing inheritance:" as misleading. In java terms this would mean
> a child pom attempting to define the same plugin would fail. The
> setting of "inherited" to false in the sample indicates to me the
> opposite, the plugin definition in the parent is invisible to the
> child. Here is a question though. If A overrides a plugin defined in
> the super pom and has inherited true, then B extends A and overrides
> the plugin and sets inherited to false, what will C which extends from
> B get? It should see the definition in A. Or does this whole section
> mean that the plugin definition in B inherits nothing from A?
> 3.8 "the element will be inherited." Unless the parent definition has
> <inherited>false</inherited> ?
>
> I don't see anything in here about being able to locate a parent
> without having to know its version. Within the scope of the purpose of
> this document it may not be relevant, but at the very least somewhere
> in section 3 it should state that if a parent is specified than which
> elements are required.
>
> I hope this was the kind of feedback you were looking for.
> Ralph
>
>
>
>
> ---------------------------------------------------------------------
> 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: POM construction specification
Posted by Brett Porter <br...@apache.org>.
On 18/12/2008, at 1:51 PM, Shane Isbell wrote:
> Comments below:
>
> On Tue, Dec 16, 2008 at 10:27 PM, Brett Porter <br...@apache.org>
> wrote:
>
>> I fixed some typos - is it ok to regenerate the PDF? (mine comes out
>> slightly different on the Mac but it's all there AFAICT).
>>
>> Just to add to what Brian and Ralph have already said:
>>
>> 3.1 - I think we have to knock multiple inheritance out at this
>> stage, even
>> if it is noted as a possibility for general model building, I don't
>> think
>> it's appropriate for the Maven rules.
>
> I know we are playing with definitions here; but if someone chooses to
> define a complete pom as a mixin, then it's the same as multiple
> inheritance.
Exactly :) I think that makes a separate parent unnecessary, and
possibly confusing (like which group/version to inherit).
>
>
>>
>> 3.2 - We should just define this by the current behaviour IMO, then
>> look at
>> how we fix it going forward (See below on versioning)
>> 3.3 - I had the same confusion as Brian. Why are collections not
>> joined?
>
> I'm just defining current behavior in regards to these collections.
> If the
> spec doesn't match current behavior, then we need to modify the spec.
Yep, I think I just got a bit confused... I thought 3.2 was waiting
for a "new" definition, not the current one.
>
>
>>
>> 2.2 - I think map handling needs to be defined for the same reason
>> so that
>> duplicate keys can be merged
>
> I need more information about what you are thinking here.
Am wondering how this is handled:
<configuration>
<systemProperties>
<property>
<key>key1</key>
<value>value1</value>
</property>
<property>
<key>key1</key>
<value>value2</value>
</property>
</systemProperties>
</configuration>
Will this be represented as a collection and all kept, with the
eventual translation back to a map sorting out the key handling?
Thanks,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM construction specification
Posted by Shane Isbell <sh...@gmail.com>.
Comments below:
On Tue, Dec 16, 2008 at 10:27 PM, Brett Porter <br...@apache.org> wrote:
> I fixed some typos - is it ok to regenerate the PDF? (mine comes out
> slightly different on the Mac but it's all there AFAICT).
>
> Just to add to what Brian and Ralph have already said:
>
> 3.1 - I think we have to knock multiple inheritance out at this stage, even
> if it is noted as a possibility for general model building, I don't think
> it's appropriate for the Maven rules.
I know we are playing with definitions here; but if someone chooses to
define a complete pom as a mixin, then it's the same as multiple
inheritance.
>
> 3.2 - We should just define this by the current behaviour IMO, then look at
> how we fix it going forward (See below on versioning)
> 3.3 - I had the same confusion as Brian. Why are collections not joined?
I'm just defining current behavior in regards to these collections. If the
spec doesn't match current behavior, then we need to modify the spec.
>
>
> Some more things:
>
> 1.1 - mentioned this before, but should be use a valid URI that perhaps
> matches the POM namespace? http://maven.apache.org/POM/...
I don't care either way. If people want a different base URI, it's fine with
me.
>
> 2.2 - I didn't see anything that says that in a set, a property should
> overwrite a previous one if it already exists (and define how equality is
> measured)?
The first unique element of the set takes priority, which means most
specialized pom (least child). It can't be overridden.
>
> 2.2 - I think map handling needs to be defined for the same reason so that
> duplicate keys can be merged
I need more information about what you are thinking here.
>
> 3.6.2 - why is the parent artifact ID listed in the (1-3) section?
This needs to be removed from the spec.
>
> 3.6.2 - are join, nop and delete in a different order to the following
> bullets?
The ordering is correct. Initially all elements of the child and parent
(with the exception of duplicate singletons) are placed into one set. A NOP
means that no operation is done, leaving B set Union alpha.
>
> 3.8 - how are properties represented by XML elements in the current schema
> handled in the URI? the "combine" technique is listed as a property, but is
> the attribute actually recognised as something different?
There is a #property element defined in the URI. In the case of XML, the
model would unmarshal that model property as an XML property. The
combine.children property is handled as a general rule in model-builder.
>
> 4.1 - refers to 3.4, but I think it means 3.6
> 4.1 - how is plugin configuration handled? it only details the combination
> of the artifact portion. Should executions be explicitly forbidden in the
> management just for clarity?
> 5.1.1 - timestamp format should be described?
> 5.1.1 - is the basedir absolute?
> 5.1.2 - this seems too "implementation specific"
> 5.1.4 - this is a self-referential definition. I don't think the difference
> between types of properties is clear enough - maybe defining system as
> dominant and environment as recessive is more descriptive
> 5.2.2 - need to list what the build directory elements are
> 5.3 - profiles are not addressed elsewhere - should their processing as an
> additional form of inheritance be described?
Yes, it should be but the profile implementation in maven-project-builder
has not yet been integrated with the rest of trunk, so I'm holding of on
trying to define that part of the spec.
>
>
> Versioning...
>
> I really would like to understand how this is going to work. My impression
> is the following:
> - this document would be locked down to current behaviour as 4.0.0 (warts
> and all)
As close as possible.
>
> - a new version of the document would make addition and changes, and would
> be a completely new rule set
There a lot of general rules of inhertance (sets, collections, sorting), but
anything dealing with maven specific processing could change.
>
> - the URIs would be the same, not including a version.
Yes, but there may be additional elements added to newer versions.
>
> - to operate on two versions of the model, the older would be upgraded to
> the new one first by a mapping of properties from one to the other. If the
> mapping was complicated it might need to be handled by an external converter
> - but the inheritance should always operate on two models of the same
> version. The problem here is that you can no longer honour some of the older
> rules from inherited POMs - but that may not be a serious consequence.
If there are two different versions of the model, then you would likely use
the version of the PomTransformer for that model version. Transforming
between models is a different case, where you have a completely different
project format that you want to put into the canonical data format and have
it processed as though it were a pom.
>
>
> Is this what you expect?
>
> BTW, should we now delete the wiki page that held basically the same info?
>
> Cheers,
> Brett
>
>
> On 17/12/2008, at 3:32 PM, Brian E. Fox wrote:
>
> "The only difference between a parent project and a mixin is that the
>> mixin is
>> abstract (not a complete model)."
>>
>> Is that really true? A Mixin should be deployed to the repository, which
>> essentially means it needs to be complete enough to id and thus a complete
>> model. It should be deployed as a classified artifact though to avoid mixing
>> in the instructions for building/deploying from those that are intended to
>> be mixed in. (ie the mixin's pom is separate)
>>
>> 3.1: what about multiple parents? I assume it's the first one, but should
>> be explicit in the spec.
>> 3.2: section is blank but contentious based on current behavior and the
>> in-ability to use properties and inheritance together.
>> 3.3: I don't understand this statement. A child always overrides the
>> parent or joins with it. Are you saying that the parent wins here? Also
>> pluginRepositories is going away soon. In general why can't the things
>> listed here be extended?
>> 3.4 shouldn't project.distMgt.relocation be inherited if the relocation
>> lists the group? (group/artifact/version ones should be skipped, but if
>> you're relocating everything in a group, it would make sense to do this at
>> the top of that group tree pom)
>> 3.5 I agree with Ralph here that Final is the wrong term. Private is more
>> appropriate.
>>
>> I started this in the morning and didn't finish yet so sending what I
>> have.
>>
>> -----Original Message-----
>> From: Ralph Goers [mailto:ralph.goers@dslextreme.com]
>> Sent: Tuesday, December 16, 2008 3:59 AM
>> To: Maven Developers List
>> Subject: Re: POM construction specification
>>
>>
>> On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote:
>>
>> This is for the general population but I'm nudging you Ralph because
>>> I know that you want to make some changes for not requiring the
>>> version in the parent element.
>>>
>>>
>>
>> You should have warned me to have a glass of wine before attempting to
>> read all these math notations. :-) Or put a link to
>> http://en.wikipedia.org/wiki/Table_of_mathematical_symbols
>> for those of use who haven't had a math class in the last 25 years.
>> The funny thing is, I have a B.S. in Physics. Man it has been a long
>> time. :-(
>>
>> Comments:
>> 1.1 Mentions there are 465 model properties. An appendix should list
>> them. Specifically, I'd like to see "provides" listed along with the
>> project's groupId, artifactId and version and "requires" in the
>> dependency declaration - or whatever other way that kind of metadata
>> will be added.
>> 2.1 & 2.2 Is all this simply stating that the closest definition wins
>> and when two or more are equally close then the first one wins?
>> 2.4 The only "definition" of mixin is "The only difference between a
>> parent pro ject and a mixin is that the mixin is
>> abstract (not a complete model)". That sure leaves a lot to the
>> imagination. And what exactly makes a model "incomplete"? Isn't a pom
>> with just a dependencyManagement complete? I also found myself
>> wondering that even though it might be possible to support extending
>> multiple parents, should we? I could see allowing only one parent but
>> multiple mixins.
>> 3.1 Even though may be obvious, it should explicitly state that
>> artifactId is always required.
>> 3.4 Why can't the groupId be inherited from its parent (or at least be
>> set from project.parent.groupIdt)?
>> 3.4 The footnote says the artifactId can be inherited from the parent.
>> That makes no sense to me. Every pom should represent a unique
>> artifact or at least a unique pom.
>> 3.5 I found the statement This will mark the container as final, thus
>> preventing inheritance:" as misleading. In java terms this would mean
>> a child pom attempting to define the same plugin would fail. The
>> setting of "inherited" to false in the sample indicates to me the
>> opposite, the plugin definition in the parent is invisible to the
>> child. Here is a question though. If A overrides a plugin defined in
>> the super pom and has inherited true, then B extends A and overrides
>> the plugin and sets inherited to false, what will C which extends from
>> B get? It should see the definition in A. Or does this whole section
>> mean that the plugin definition in B inherits nothing from A?
>> 3.8 "the element will be inherited." Unless the parent definition has
>> <inherited>false</inherited> ?
>>
>> I don't see anything in here about being able to locate a parent
>> without having to know its version. Within the scope of the purpose of
>> this document it may not be relevant, but at the very least somewhere
>> in section 3 it should state that if a parent is specified than which
>> elements are required.
>>
>> I hope this was the kind of feedback you were looking for.
>> Ralph
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: POM construction specification
Posted by Jason van Zyl <jv...@sonatype.com>.
On 17-Dec-08, at 1:27 AM, Brett Porter wrote:
> I fixed some typos - is it ok to regenerate the PDF? (mine comes out
> slightly different on the Mac but it's all there AFAICT).
>
> Just to add to what Brian and Ralph have already said:
>
> 3.1 - I think we have to knock multiple inheritance out at this
> stage, even if it is noted as a possibility for general model
> building, I don't think it's appropriate for the Maven rules.
> 3.2 - We should just define this by the current behaviour IMO, then
> look at how we fix it going forward (See below on versioning)
That' s all we're doing. The general mechanism is built into the
builder for multiple inheritance the our constrained use only uses the
super pom, but mixins are also inherited models. It was hard enough to
sift backward and try and capture what it does and as I mentioned
before I don't see any real changes being made to behavior until at
least alpha-3.
>
> 3.3 - I had the same confusion as Brian. Why are collections not
> joined?
>
> Some more things:
>
> 1.1 - mentioned this before, but should be use a valid URI that
> perhaps matches the POM namespace? http://maven.apache.org/POM/...
> 2.2 - I didn't see anything that says that in a set, a property
> should overwrite a previous one if it already exists (and define how
> equality is measured)?
> 2.2 - I think map handling needs to be defined for the same reason
> so that duplicate keys can be merged
> 3.6.2 - why is the parent artifact ID listed in the (1-3) section?
> 3.6.2 - are join, nop and delete in a different order to the
> following bullets?
> 3.8 - how are properties represented by XML elements in the current
> schema handled in the URI? the "combine" technique is listed as a
> property, but is the attribute actually recognised as something
> different?
> 4.1 - refers to 3.4, but I think it means 3.6
> 4.1 - how is plugin configuration handled? it only details the
> combination of the artifact portion. Should executions be explicitly
> forbidden in the management just for clarity?
> 5.1.1 - timestamp format should be described?
> 5.1.1 - is the basedir absolute?
> 5.1.2 - this seems too "implementation specific"
> 5.1.4 - this is a self-referential definition. I don't think the
> difference between types of properties is clear enough - maybe
> defining system as dominant and environment as recessive is more
> descriptive
> 5.2.2 - need to list what the build directory elements are
> 5.3 - profiles are not addressed elsewhere - should their processing
> as an additional form of inheritance be described?
>
> Versioning...
>
> I really would like to understand how this is going to work. My
> impression is the following:
> - this document would be locked down to current behaviour as 4.0.0
> (warts and all)
> - a new version of the document would make addition and changes, and
> would be a completely new rule set
> - the URIs would be the same, not including a version.
> - to operate on two versions of the model, the older would be
> upgraded to the new one first by a mapping of properties from one to
> the other. If the mapping was complicated it might need to be
> handled by an external converter - but the inheritance should always
> operate on two models of the same version. The problem here is that
> you can no longer honour some of the older rules from inherited POMs
> - but that may not be a serious consequence.
>
> Is this what you expect?
>
> BTW, should we now delete the wiki page that held basically the same
> info?
>
> Cheers,
> Brett
>
> On 17/12/2008, at 3:32 PM, Brian E. Fox wrote:
>
>> "The only difference between a parent project and a mixin is that
>> the mixin is
>> abstract (not a complete model)."
>>
>> Is that really true? A Mixin should be deployed to the repository,
>> which essentially means it needs to be complete enough to id and
>> thus a complete model. It should be deployed as a classified
>> artifact though to avoid mixing in the instructions for building/
>> deploying from those that are intended to be mixed in. (ie the
>> mixin's pom is separate)
>>
>> 3.1: what about multiple parents? I assume it's the first one, but
>> should be explicit in the spec.
>> 3.2: section is blank but contentious based on current behavior and
>> the in-ability to use properties and inheritance together.
>> 3.3: I don't understand this statement. A child always overrides
>> the parent or joins with it. Are you saying that the parent wins
>> here? Also pluginRepositories is going away soon. In general why
>> can't the things listed here be extended?
>> 3.4 shouldn't project.distMgt.relocation be inherited if the
>> relocation lists the group? (group/artifact/version ones should be
>> skipped, but if you're relocating everything in a group, it would
>> make sense to do this at the top of that group tree pom)
>> 3.5 I agree with Ralph here that Final is the wrong term. Private
>> is more appropriate.
>>
>> I started this in the morning and didn't finish yet so sending what
>> I have.
>>
>> -----Original Message-----
>> From: Ralph Goers [mailto:ralph.goers@dslextreme.com]
>> Sent: Tuesday, December 16, 2008 3:59 AM
>> To: Maven Developers List
>> Subject: Re: POM construction specification
>>
>>
>> On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote:
>>
>>> This is for the general population but I'm nudging you Ralph because
>>> I know that you want to make some changes for not requiring the
>>> version in the parent element.
>>>
>>
>>
>> You should have warned me to have a glass of wine before attempting
>> to
>> read all these math notations. :-) Or put a link to http://en.wikipedia.org/wiki/Table_of_mathematical_symbols
>> for those of use who haven't had a math class in the last 25 years.
>> The funny thing is, I have a B.S. in Physics. Man it has been a long
>> time. :-(
>>
>> Comments:
>> 1.1 Mentions there are 465 model properties. An appendix should list
>> them. Specifically, I'd like to see "provides" listed along with the
>> project's groupId, artifactId and version and "requires" in the
>> dependency declaration - or whatever other way that kind of metadata
>> will be added.
>> 2.1 & 2.2 Is all this simply stating that the closest definition wins
>> and when two or more are equally close then the first one wins?
>> 2.4 The only "definition" of mixin is "The only difference between a
>> parent pro ject and a mixin is that the mixin is
>> abstract (not a complete model)". That sure leaves a lot to the
>> imagination. And what exactly makes a model "incomplete"? Isn't a pom
>> with just a dependencyManagement complete? I also found myself
>> wondering that even though it might be possible to support extending
>> multiple parents, should we? I could see allowing only one parent but
>> multiple mixins.
>> 3.1 Even though may be obvious, it should explicitly state that
>> artifactId is always required.
>> 3.4 Why can't the groupId be inherited from its parent (or at least
>> be
>> set from project.parent.groupIdt)?
>> 3.4 The footnote says the artifactId can be inherited from the
>> parent.
>> That makes no sense to me. Every pom should represent a unique
>> artifact or at least a unique pom.
>> 3.5 I found the statement This will mark the container as final,
>> thus
>> preventing inheritance:" as misleading. In java terms this would mean
>> a child pom attempting to define the same plugin would fail. The
>> setting of "inherited" to false in the sample indicates to me the
>> opposite, the plugin definition in the parent is invisible to the
>> child. Here is a question though. If A overrides a plugin defined in
>> the super pom and has inherited true, then B extends A and overrides
>> the plugin and sets inherited to false, what will C which extends
>> from
>> B get? It should see the definition in A. Or does this whole section
>> mean that the plugin definition in B inherits nothing from A?
>> 3.8 "the element will be inherited." Unless the parent definition has
>> <inherited>false</inherited> ?
>>
>> I don't see anything in here about being able to locate a parent
>> without having to know its version. Within the scope of the purpose
>> of
>> this document it may not be relevant, but at the very least somewhere
>> in section 3 it should state that if a parent is specified than which
>> elements are required.
>>
>> I hope this was the kind of feedback you were looking for.
>> Ralph
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> 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
jason at sonatype dot com
----------------------------------------------------------
We know what we are, but know not what we may be.
-- Shakespeare
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM construction specification
Posted by Brett Porter <br...@apache.org>.
I fixed some typos - is it ok to regenerate the PDF? (mine comes out
slightly different on the Mac but it's all there AFAICT).
Just to add to what Brian and Ralph have already said:
3.1 - I think we have to knock multiple inheritance out at this stage,
even if it is noted as a possibility for general model building, I
don't think it's appropriate for the Maven rules.
3.2 - We should just define this by the current behaviour IMO, then
look at how we fix it going forward (See below on versioning)
3.3 - I had the same confusion as Brian. Why are collections not joined?
Some more things:
1.1 - mentioned this before, but should be use a valid URI that
perhaps matches the POM namespace? http://maven.apache.org/POM/...
2.2 - I didn't see anything that says that in a set, a property should
overwrite a previous one if it already exists (and define how equality
is measured)?
2.2 - I think map handling needs to be defined for the same reason so
that duplicate keys can be merged
3.6.2 - why is the parent artifact ID listed in the (1-3) section?
3.6.2 - are join, nop and delete in a different order to the following
bullets?
3.8 - how are properties represented by XML elements in the current
schema handled in the URI? the "combine" technique is listed as a
property, but is the attribute actually recognised as something
different?
4.1 - refers to 3.4, but I think it means 3.6
4.1 - how is plugin configuration handled? it only details the
combination of the artifact portion. Should executions be explicitly
forbidden in the management just for clarity?
5.1.1 - timestamp format should be described?
5.1.1 - is the basedir absolute?
5.1.2 - this seems too "implementation specific"
5.1.4 - this is a self-referential definition. I don't think the
difference between types of properties is clear enough - maybe
defining system as dominant and environment as recessive is more
descriptive
5.2.2 - need to list what the build directory elements are
5.3 - profiles are not addressed elsewhere - should their processing
as an additional form of inheritance be described?
Versioning...
I really would like to understand how this is going to work. My
impression is the following:
- this document would be locked down to current behaviour as 4.0.0
(warts and all)
- a new version of the document would make addition and changes, and
would be a completely new rule set
- the URIs would be the same, not including a version.
- to operate on two versions of the model, the older would be upgraded
to the new one first by a mapping of properties from one to the other.
If the mapping was complicated it might need to be handled by an
external converter - but the inheritance should always operate on two
models of the same version. The problem here is that you can no longer
honour some of the older rules from inherited POMs - but that may not
be a serious consequence.
Is this what you expect?
BTW, should we now delete the wiki page that held basically the same
info?
Cheers,
Brett
On 17/12/2008, at 3:32 PM, Brian E. Fox wrote:
> "The only difference between a parent project and a mixin is that
> the mixin is
> abstract (not a complete model)."
>
> Is that really true? A Mixin should be deployed to the repository,
> which essentially means it needs to be complete enough to id and
> thus a complete model. It should be deployed as a classified
> artifact though to avoid mixing in the instructions for building/
> deploying from those that are intended to be mixed in. (ie the
> mixin's pom is separate)
>
> 3.1: what about multiple parents? I assume it's the first one, but
> should be explicit in the spec.
> 3.2: section is blank but contentious based on current behavior and
> the in-ability to use properties and inheritance together.
> 3.3: I don't understand this statement. A child always overrides the
> parent or joins with it. Are you saying that the parent wins here?
> Also pluginRepositories is going away soon. In general why can't the
> things listed here be extended?
> 3.4 shouldn't project.distMgt.relocation be inherited if the
> relocation lists the group? (group/artifact/version ones should be
> skipped, but if you're relocating everything in a group, it would
> make sense to do this at the top of that group tree pom)
> 3.5 I agree with Ralph here that Final is the wrong term. Private is
> more appropriate.
>
> I started this in the morning and didn't finish yet so sending what
> I have.
>
> -----Original Message-----
> From: Ralph Goers [mailto:ralph.goers@dslextreme.com]
> Sent: Tuesday, December 16, 2008 3:59 AM
> To: Maven Developers List
> Subject: Re: POM construction specification
>
>
> On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote:
>
>> This is for the general population but I'm nudging you Ralph because
>> I know that you want to make some changes for not requiring the
>> version in the parent element.
>>
>
>
> You should have warned me to have a glass of wine before attempting to
> read all these math notations. :-) Or put a link to http://en.wikipedia.org/wiki/Table_of_mathematical_symbols
> for those of use who haven't had a math class in the last 25 years.
> The funny thing is, I have a B.S. in Physics. Man it has been a long
> time. :-(
>
> Comments:
> 1.1 Mentions there are 465 model properties. An appendix should list
> them. Specifically, I'd like to see "provides" listed along with the
> project's groupId, artifactId and version and "requires" in the
> dependency declaration - or whatever other way that kind of metadata
> will be added.
> 2.1 & 2.2 Is all this simply stating that the closest definition wins
> and when two or more are equally close then the first one wins?
> 2.4 The only "definition" of mixin is "The only difference between a
> parent pro ject and a mixin is that the mixin is
> abstract (not a complete model)". That sure leaves a lot to the
> imagination. And what exactly makes a model "incomplete"? Isn't a pom
> with just a dependencyManagement complete? I also found myself
> wondering that even though it might be possible to support extending
> multiple parents, should we? I could see allowing only one parent but
> multiple mixins.
> 3.1 Even though may be obvious, it should explicitly state that
> artifactId is always required.
> 3.4 Why can't the groupId be inherited from its parent (or at least be
> set from project.parent.groupIdt)?
> 3.4 The footnote says the artifactId can be inherited from the parent.
> That makes no sense to me. Every pom should represent a unique
> artifact or at least a unique pom.
> 3.5 I found the statement This will mark the container as final, thus
> preventing inheritance:" as misleading. In java terms this would mean
> a child pom attempting to define the same plugin would fail. The
> setting of "inherited" to false in the sample indicates to me the
> opposite, the plugin definition in the parent is invisible to the
> child. Here is a question though. If A overrides a plugin defined in
> the super pom and has inherited true, then B extends A and overrides
> the plugin and sets inherited to false, what will C which extends from
> B get? It should see the definition in A. Or does this whole section
> mean that the plugin definition in B inherits nothing from A?
> 3.8 "the element will be inherited." Unless the parent definition has
> <inherited>false</inherited> ?
>
> I don't see anything in here about being able to locate a parent
> without having to know its version. Within the scope of the purpose of
> this document it may not be relevant, but at the very least somewhere
> in section 3 it should state that if a parent is specified than which
> elements are required.
>
> I hope this was the kind of feedback you were looking for.
> Ralph
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: POM construction specification
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
"The only difference between a parent project and a mixin is that the mixin is
abstract (not a complete model)."
Is that really true? A Mixin should be deployed to the repository, which essentially means it needs to be complete enough to id and thus a complete model. It should be deployed as a classified artifact though to avoid mixing in the instructions for building/deploying from those that are intended to be mixed in. (ie the mixin's pom is separate)
3.1: what about multiple parents? I assume it's the first one, but should be explicit in the spec.
3.2: section is blank but contentious based on current behavior and the in-ability to use properties and inheritance together.
3.3: I don't understand this statement. A child always overrides the parent or joins with it. Are you saying that the parent wins here? Also pluginRepositories is going away soon. In general why can't the things listed here be extended?
3.4 shouldn't project.distMgt.relocation be inherited if the relocation lists the group? (group/artifact/version ones should be skipped, but if you're relocating everything in a group, it would make sense to do this at the top of that group tree pom)
3.5 I agree with Ralph here that Final is the wrong term. Private is more appropriate.
I started this in the morning and didn't finish yet so sending what I have.
-----Original Message-----
From: Ralph Goers [mailto:ralph.goers@dslextreme.com]
Sent: Tuesday, December 16, 2008 3:59 AM
To: Maven Developers List
Subject: Re: POM construction specification
On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote:
> This is for the general population but I'm nudging you Ralph because
> I know that you want to make some changes for not requiring the
> version in the parent element.
>
You should have warned me to have a glass of wine before attempting to
read all these math notations. :-) Or put a link to http://en.wikipedia.org/wiki/Table_of_mathematical_symbols
for those of use who haven't had a math class in the last 25 years.
The funny thing is, I have a B.S. in Physics. Man it has been a long
time. :-(
Comments:
1.1 Mentions there are 465 model properties. An appendix should list
them. Specifically, I'd like to see "provides" listed along with the
project's groupId, artifactId and version and "requires" in the
dependency declaration - or whatever other way that kind of metadata
will be added.
2.1 & 2.2 Is all this simply stating that the closest definition wins
and when two or more are equally close then the first one wins?
2.4 The only "definition" of mixin is "The only difference between a
parent pro ject and a mixin is that the mixin is
abstract (not a complete model)". That sure leaves a lot to the
imagination. And what exactly makes a model "incomplete"? Isn't a pom
with just a dependencyManagement complete? I also found myself
wondering that even though it might be possible to support extending
multiple parents, should we? I could see allowing only one parent but
multiple mixins.
3.1 Even though may be obvious, it should explicitly state that
artifactId is always required.
3.4 Why can't the groupId be inherited from its parent (or at least be
set from project.parent.groupIdt)?
3.4 The footnote says the artifactId can be inherited from the parent.
That makes no sense to me. Every pom should represent a unique
artifact or at least a unique pom.
3.5 I found the statement This will mark the container as final, thus
preventing inheritance:" as misleading. In java terms this would mean
a child pom attempting to define the same plugin would fail. The
setting of "inherited" to false in the sample indicates to me the
opposite, the plugin definition in the parent is invisible to the
child. Here is a question though. If A overrides a plugin defined in
the super pom and has inherited true, then B extends A and overrides
the plugin and sets inherited to false, what will C which extends from
B get? It should see the definition in A. Or does this whole section
mean that the plugin definition in B inherits nothing from A?
3.8 "the element will be inherited." Unless the parent definition has
<inherited>false</inherited> ?
I don't see anything in here about being able to locate a parent
without having to know its version. Within the scope of the purpose of
this document it may not be relevant, but at the very least somewhere
in section 3 it should state that if a parent is specified than which
elements are required.
I hope this was the kind of feedback you were looking for.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM construction specification
Posted by Jason van Zyl <jv...@sonatype.com>.
On 16-Dec-08, at 3:58 AM, Ralph Goers wrote:
>
> On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote:
>
>> This is for the general population but I'm nudging you Ralph
>> because I know that you want to make some changes for not requiring
>> the version in the parent element.
>>
>
>
> You should have warned me to have a glass of wine before attempting
> to read all these math notations. :-) Or put a link to http://en.wikipedia.org/wiki/Table_of_mathematical_symbols
> for those of use who haven't had a math class in the last 25 years.
> The funny thing is, I have a B.S. in Physics. Man it has been a long
> time. :-(
>
> Comments:
> 1.1 Mentions there are 465 model properties. An appendix should list
> them. Specifically, I'd like to see "provides" listed along with the
> project's groupId, artifactId and version and "requires" in the
> dependency declaration - or whatever other way that kind of metadata
> will be added.
We should definitely add them to the appendix. If you actually look at
the implementation the parsers are domain specific and they produce
the set of model properties. I think Shane did what was correct in
that he focused on a concrete implementation and got it working. So
right now the domain specific parser is hand-written. There is no
reason that this parser cannot be generated with modello and when we
do that we can use the descriptions in the modello model to generate
an appendix with a description of each property.
>
> 2.1 & 2.2 Is all this simply stating that the closest definition
> wins and when two or more are equally close then the first one wins?
Let me add actual examples with POMs and I think it will be more clear.
>
> 2.4 The only "definition" of mixin is "The only difference between a
> parent pro ject and a mixin is that the mixin is
> abstract (not a complete model)". That sure leaves a lot to the
> imagination. And what exactly makes a model "incomplete"? Isn't a
> pom with just a dependencyManagement complete? I also found myself
> wondering that even though it might be possible to support extending
> multiple parents, should we? I could see allowing only one parent
> but multiple mixins.
> 3.1 Even though may be obvious, it should explicitly state that
> artifactId is always required.
> 3.4 Why can't the groupId be inherited from its parent (or at least
> be set from project.parent.groupIdt)?
It can be. The Maven POMs exhibit this property and it works fine so
I'll fix that.
>
> 3.4 The footnote says the artifactId can be inherited from the
> parent. That makes no sense to me. Every pom should represent a
> unique artifact or at least a unique pom.
Yup.
>
> 3.5 I found the statement This will mark the container as final,
> thus preventing inheritance:" as misleading. In java terms this
> would mean a child pom attempting to define the same plugin would
> fail. The setting of "inherited" to false in the sample indicates to
> me the opposite, the plugin definition in the parent is invisible to
> the child. Here is a question though. If A overrides a plugin
> defined in the super pom and has inherited true, then B extends A
> and overrides the plugin and sets inherited to false, what will C
> which extends from B get? It should see the definition in A. Or
> does this whole section mean that the plugin definition in B
> inherits nothing from A?
> 3.8 "the element will be inherited." Unless the parent definition
> has <inherited>false</inherited> ?
>
> I don't see anything in here about being able to locate a parent
> without having to know its version. Within the scope of the purpose
> of this document it may not be relevant, but at the very least
> somewhere in section 3 it should state that if a parent is specified
> than which elements are required.
I think if it has anything to do with POM construction then we need to
include it in this document.
>
>
> I hope this was the kind of feedback you were looking for.
This is great feedback. I'll get this converted into Confluence by the
end of the week and then it will be easier to collaborate. Shane also
reversed engineered the rules because nothing was ever documented as
it grew organically. I think a few rounds of doing this where we
clarify and the rules and we'll be in a lot better shape. I have
started a POM construction test suite which will act as a validation
for the specification which will be complete by alpha-2. For alpha-1 I
had the goal of some specific builds working to get the ball rolling.
The rigor will start after alpha-2 which combined with some of the
integration testing tools we have I think will ensure we go forward
and never backward again.
>
> Ralph
>
>
>
>
> ---------------------------------------------------------------------
> 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
jason at sonatype dot com
----------------------------------------------------------
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM construction specification
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote:
> This is for the general population but I'm nudging you Ralph because
> I know that you want to make some changes for not requiring the
> version in the parent element.
>
You should have warned me to have a glass of wine before attempting to
read all these math notations. :-) Or put a link to http://en.wikipedia.org/wiki/Table_of_mathematical_symbols
for those of use who haven't had a math class in the last 25 years.
The funny thing is, I have a B.S. in Physics. Man it has been a long
time. :-(
Comments:
1.1 Mentions there are 465 model properties. An appendix should list
them. Specifically, I'd like to see "provides" listed along with the
project's groupId, artifactId and version and "requires" in the
dependency declaration - or whatever other way that kind of metadata
will be added.
2.1 & 2.2 Is all this simply stating that the closest definition wins
and when two or more are equally close then the first one wins?
2.4 The only "definition" of mixin is "The only difference between a
parent pro ject and a mixin is that the mixin is
abstract (not a complete model)". That sure leaves a lot to the
imagination. And what exactly makes a model "incomplete"? Isn't a pom
with just a dependencyManagement complete? I also found myself
wondering that even though it might be possible to support extending
multiple parents, should we? I could see allowing only one parent but
multiple mixins.
3.1 Even though may be obvious, it should explicitly state that
artifactId is always required.
3.4 Why can't the groupId be inherited from its parent (or at least be
set from project.parent.groupIdt)?
3.4 The footnote says the artifactId can be inherited from the parent.
That makes no sense to me. Every pom should represent a unique
artifact or at least a unique pom.
3.5 I found the statement This will mark the container as final, thus
preventing inheritance:" as misleading. In java terms this would mean
a child pom attempting to define the same plugin would fail. The
setting of "inherited" to false in the sample indicates to me the
opposite, the plugin definition in the parent is invisible to the
child. Here is a question though. If A overrides a plugin defined in
the super pom and has inherited true, then B extends A and overrides
the plugin and sets inherited to false, what will C which extends from
B get? It should see the definition in A. Or does this whole section
mean that the plugin definition in B inherits nothing from A?
3.8 "the element will be inherited." Unless the parent definition has
<inherited>false</inherited> ?
I don't see anything in here about being able to locate a parent
without having to know its version. Within the scope of the purpose of
this document it may not be relevant, but at the very least somewhere
in section 3 it should state that if a parent is specified than which
elements are required.
I hope this was the kind of feedback you were looking for.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM construction specification
Posted by Brett Porter <br...@apache.org>.
Thanks, I'll take a look. I'm interested in finally continuing the
work I started on a terse POM syntax earlier in the year and can start
by spec'ing out the interoperability needs.
On 16/12/2008, at 7:02 AM, Jason van Zyl wrote:
> This is for the general population but I'm nudging you Ralph because
> I know that you want to make some changes for not requiring the
> version in the parent element.
>
> I don't think I'll be too keen on making substantive changes to how
> the POM is constructed until alpha-3/4 (because we need to deal with
> the thorny issue of interoperability between versions of the POM and
> version of Maven) but have a look at this:
>
> http://svn.apache.org/repos/asf/maven/components/trunk/maven-project-spec.pdf
>
> Shane tried to codify the behavior as much as possible into this
> spec and I think it servers as the new location for existing
> behavior and changes we want to make in the future. I think we can
> clearly mark proposals and then transition them into the document
> proper as proposals are accepted.
>
> This is really to get the ball rolling and get your thoughts as you
> have the only concrete proposal that's been tested I know of. I am
> going to translate that document into Confluence markup as I don't
> think Tex is very popular. Once that is done we can also incorporate
> proposals that have been made by users and link back to the JIRA.
> This should make the behavior more visible and potential changes
> known. We'll have something similar for Mercury which will tie the
> whole process together but this is a place to start.
>
> (The Tex source is right beside the PDF if you actually want to edit
> the Tex content)
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> A man enjoys his work when he understands the whole and when he
> is responsible for the quality of the whole
>
> -- Christopher Alexander, A Pattern Language
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org