You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Benson Margulies <bi...@gmail.com> on 2011/06/29 00:30:49 UTC
Pom changes
This is a new thread for the topic I accidentally started with Steven.
I'm fairly new around here, so please try to forgive me for
(re)stating the obvious.
There is an ecosystem of tools that parse poms. They don't use any
library we give them, they just parse them.
We want old tools to handle new poms without crashing.
We'd like those tools to be able to distinguish legitimate extensions
from goofs, since some of them are trying to support authoring. This
is hard. Retroactively, it may be impossible. However, we do have XML
Schema to help us.
If tools validate against the schema, they know when a POM is, in
fact, valid for its declared model. Thus, any elements that the tool
does not recognize are proved to be 'messengers from the future'.
I personally think that it is madness to start telling people, 'well,
yes, we've extended the expressiveness of the pom, but you have to add
special off-to-the-side files to use the new elements.'
So, one option we could adopt is to start a propaganda campaign now:
"Do you parse poms? Do you tolerate new elements? If not, better fix
your code now, because in a few months they will be arriving."
After all, in theory, some existing tool could barf on new scopes or
any other supposedly compatible change we make.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Pom changes
Posted by Nigel Magnay <ni...@gmail.com>.
I'm not sure the HTML analogy flies (in particular, I'm not convinced that,
say, schema.org isn't just re-invention of namespaces or RDFa via another
mechanism).
I have no argument that XML namespaces are somewhat klunky, but they are at
least standardised and have well understood transformations (e.g: stripping
them entirely is a trival operation). I wouldn't go mad on them, in fact I'd
try hard to avoid them, but the fact I have to maintain - effectively -
cross-reference lists against data in a separate descriptor is one of the
reasons I periodically go sniffing around gradle.org.
I'd also note that the current web attitude is 'if it don't render, upgrade
your browser' - effectively deciding that backwards compatibility is no
longer a design goal.
On Wed, Jun 29, 2011 at 2:19 PM, Benson Margulies <bi...@gmail.com>wrote:
> I'm opposed to namespaces for two reasons. One is a global reason, the
> other applies only to 'core' configuration.
>
> The global reason: read all the very cogent writing from the HTML5
> process as to why they have run screaming away from namespaces.
>
> The more local reason: Consider what started this discussion recently:
> adding a declaration to a POM that indicates that the project serves
> the purpose of multiple artifacts for dependency management. If you
> put that in a namespace, how to do you explain it? "It was invented in
> 2011" is one possible explanation. Pretty soon, we're up our ears in a
> confusing collection of namespaces. Spring, at least, groups things
> functionally into namespaces. But that doesn't work if the criteria is
> 'new feature -> new namespace'. And you've got users cursing us as
> they try to remember which namespace goes with which feature.
>
> On the other hand, if you want to open the door for new information in
> the POM that 'belongs to' particular plugins (e.g. m2e), namespaces
> would at least make logical sense, unless you are persuaded by the
> HTML analogy.
>
>
>
> On Wed, Jun 29, 2011 at 9:07 AM, Nigel Magnay <ni...@gmail.com>
> wrote:
> >>
> >>
> >>
> >> If tools validate against the schema, they know when a POM is, in
> >> fact, valid for its declared model. Thus, any elements that the tool
> >> does not recognize are proved to be 'messengers from the future'.
> >>
> >>
> > It would help enormously if 'messengers from the future' used an
> appropriate
> > XML namespace so that they could be discarded by clients that don't
> > understand them.
> >
> > It always surprised me that the pom files never allowed the plugins to
> > extend the meaning. For example, using some plugins I'm forced to
> maintain a
> > separate config file, referencing much of the same information by
> > coordinate. It'd be nice to be able to do things like
> >
> > <dependency>
> > <groupId>grp<groupId>
> > <artifactId>flex-components>
> > <version>1.0</version>
> > <scope fm:domain="default" fm:url="/components/flex.swf">rsl</scope>
> > <dependency>
> >
> >
> > I guess existing tooling is sadly not namespace aware.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Pom changes
Posted by Benson Margulies <bi...@gmail.com>.
I'm opposed to namespaces for two reasons. One is a global reason, the
other applies only to 'core' configuration.
The global reason: read all the very cogent writing from the HTML5
process as to why they have run screaming away from namespaces.
The more local reason: Consider what started this discussion recently:
adding a declaration to a POM that indicates that the project serves
the purpose of multiple artifacts for dependency management. If you
put that in a namespace, how to do you explain it? "It was invented in
2011" is one possible explanation. Pretty soon, we're up our ears in a
confusing collection of namespaces. Spring, at least, groups things
functionally into namespaces. But that doesn't work if the criteria is
'new feature -> new namespace'. And you've got users cursing us as
they try to remember which namespace goes with which feature.
On the other hand, if you want to open the door for new information in
the POM that 'belongs to' particular plugins (e.g. m2e), namespaces
would at least make logical sense, unless you are persuaded by the
HTML analogy.
On Wed, Jun 29, 2011 at 9:07 AM, Nigel Magnay <ni...@gmail.com> wrote:
>>
>>
>>
>> If tools validate against the schema, they know when a POM is, in
>> fact, valid for its declared model. Thus, any elements that the tool
>> does not recognize are proved to be 'messengers from the future'.
>>
>>
> It would help enormously if 'messengers from the future' used an appropriate
> XML namespace so that they could be discarded by clients that don't
> understand them.
>
> It always surprised me that the pom files never allowed the plugins to
> extend the meaning. For example, using some plugins I'm forced to maintain a
> separate config file, referencing much of the same information by
> coordinate. It'd be nice to be able to do things like
>
> <dependency>
> <groupId>grp<groupId>
> <artifactId>flex-components>
> <version>1.0</version>
> <scope fm:domain="default" fm:url="/components/flex.swf">rsl</scope>
> <dependency>
>
>
> I guess existing tooling is sadly not namespace aware.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Pom changes
Posted by Nigel Magnay <ni...@gmail.com>.
>
>
>
> If tools validate against the schema, they know when a POM is, in
> fact, valid for its declared model. Thus, any elements that the tool
> does not recognize are proved to be 'messengers from the future'.
>
>
It would help enormously if 'messengers from the future' used an appropriate
XML namespace so that they could be discarded by clients that don't
understand them.
It always surprised me that the pom files never allowed the plugins to
extend the meaning. For example, using some plugins I'm forced to maintain a
separate config file, referencing much of the same information by
coordinate. It'd be nice to be able to do things like
<dependency>
<groupId>grp<groupId>
<artifactId>flex-components>
<version>1.0</version>
<scope fm:domain="default" fm:url="/components/flex.swf">rsl</scope>
<dependency>
I guess existing tooling is sadly not namespace aware.
Re: Pom changes
Posted by Benson Margulies <bi...@gmail.com>.
>>
>> Telling people to edit and maintain two poms is also likely to lead to
>> widespread derision.
>>
>> Here's another thought experiment in design. This may merely be me
>> recapitulating Steven's idea. Say that for Maven 3.1 we wanted to fix
>> this issue once and for all. So, we make maven 3.1 default to reading
>> pom5.xml. (5 for the model version). If there isn't one of those, it
>> goes looking for pom.xml. deploy:deploy creates pom.xml from pom5.xml,
>> and deploys that too. (Artifact is 'pom5'.)
>>
>
> That is my idea (that I developed in discussions with brian fox and
> others... so not entirely my idea)
>
Sometimes I don't really understand something until I can rewrite it
coherently. I hope my disclaimer was sufficient.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Pom changes
Posted by Stephen Connolly <st...@gmail.com>.
On 29 June 2011 12:20, Benson Margulies <bi...@gmail.com> wrote:
> If they update to new versions of the thing with the pom. At least for
> polemic purposes, imagining a world in which the decision to make use
> of a new pom feature has the effect of forcing these sticks-in-the-mud
> to stick to old versions.
>
> Let me be more specific about why I don't like the alternative of
> forbidding change.
>
> Coming up with counter-intuitive syntax that happens to sneak past
> (some) old tools will cause maven to become less and less
> understandable. We get see plenty of criticism already that poms are
> hard to edit and maven is hard to understand.
>
> Telling people to edit and maintain two poms is also likely to lead to
> widespread derision.
>
> Here's another thought experiment in design. This may merely be me
> recapitulating Steven's idea. Say that for Maven 3.1 we wanted to fix
> this issue once and for all. So, we make maven 3.1 default to reading
> pom5.xml. (5 for the model version). If there isn't one of those, it
> goes looking for pom.xml. deploy:deploy creates pom.xml from pom5.xml,
> and deploys that too. (Artifact is 'pom5'.)
>
> Now, ancient tools find what they can use in the place they expect to
> use it, and users create and maintain a single file with a
> coherently-designed syntax. Further, in designing that syntax, we
> could adopt the policy I stated at the top of this thread, so we'd
> never have to do this again. I recommend reading the html5 group's
> thoughts on extensions and compatibility.
>
That is my idea (that I developed in discussions with brian fox and
others... so not entirely my idea)
>
>
> On Wed, Jun 29, 2011 at 1:39 AM, Milos Kleint <mk...@gmail.com> wrote:
>> On Wed, Jun 29, 2011 at 1:02 AM, Benson Margulies <bi...@gmail.com> wrote:
>>> But why do 2.0.10 users need to build against brand-spanking-new poms?
>>> And, if they do, could we give them a downconversion tool?
>>>
>>
>> the new poms will arrive to central for everyone to use..
>>
>> Milos
>>
>>>
>>> On Tue, Jun 28, 2011 at 6:47 PM, Stephen Connolly
>>> <st...@gmail.com> wrote:
>>>> maven 2.0.10 is still widely used. and convincing enterprises to upgrade is
>>>> tricky... even our own model parsing is not forgiving if i recall
>>>> correctly... so far as 3.0.x too
>>>>
>>>> - Stephen
>>>>
>>>> ---
>>>> Sent from my Android phone, so random spelling mistakes, random nonsense
>>>> words and other nonsense are a direct result of using swype to type on the
>>>> screen
>>>> On 28 Jun 2011 23:31, "Benson Margulies" <bi...@gmail.com> wrote:
>>>>> This is a new thread for the topic I accidentally started with Steven.
>>>>>
>>>>> I'm fairly new around here, so please try to forgive me for
>>>>> (re)stating the obvious.
>>>>>
>>>>> There is an ecosystem of tools that parse poms. They don't use any
>>>>> library we give them, they just parse them.
>>>>>
>>>>> We want old tools to handle new poms without crashing.
>>>>>
>>>>> We'd like those tools to be able to distinguish legitimate extensions
>>>>> from goofs, since some of them are trying to support authoring. This
>>>>> is hard. Retroactively, it may be impossible. However, we do have XML
>>>>> Schema to help us.
>>>>>
>>>>> If tools validate against the schema, they know when a POM is, in
>>>>> fact, valid for its declared model. Thus, any elements that the tool
>>>>> does not recognize are proved to be 'messengers from the future'.
>>>>>
>>>>> I personally think that it is madness to start telling people, 'well,
>>>>> yes, we've extended the expressiveness of the pom, but you have to add
>>>>> special off-to-the-side files to use the new elements.'
>>>>>
>>>>> So, one option we could adopt is to start a propaganda campaign now:
>>>>> "Do you parse poms? Do you tolerate new elements? If not, better fix
>>>>> your code now, because in a few months they will be arriving."
>>>>>
>>>>> After all, in theory, some existing tool could barf on new scopes or
>>>>> any other supposedly compatible change we make.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> 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 changes
Posted by Benson Margulies <bi...@gmail.com>.
If they update to new versions of the thing with the pom. At least for
polemic purposes, imagining a world in which the decision to make use
of a new pom feature has the effect of forcing these sticks-in-the-mud
to stick to old versions.
Let me be more specific about why I don't like the alternative of
forbidding change.
Coming up with counter-intuitive syntax that happens to sneak past
(some) old tools will cause maven to become less and less
understandable. We get see plenty of criticism already that poms are
hard to edit and maven is hard to understand.
Telling people to edit and maintain two poms is also likely to lead to
widespread derision.
Here's another thought experiment in design. This may merely be me
recapitulating Steven's idea. Say that for Maven 3.1 we wanted to fix
this issue once and for all. So, we make maven 3.1 default to reading
pom5.xml. (5 for the model version). If there isn't one of those, it
goes looking for pom.xml. deploy:deploy creates pom.xml from pom5.xml,
and deploys that too. (Artifact is 'pom5'.)
Now, ancient tools find what they can use in the place they expect to
use it, and users create and maintain a single file with a
coherently-designed syntax. Further, in designing that syntax, we
could adopt the policy I stated at the top of this thread, so we'd
never have to do this again. I recommend reading the html5 group's
thoughts on extensions and compatibility.
On Wed, Jun 29, 2011 at 1:39 AM, Milos Kleint <mk...@gmail.com> wrote:
> On Wed, Jun 29, 2011 at 1:02 AM, Benson Margulies <bi...@gmail.com> wrote:
>> But why do 2.0.10 users need to build against brand-spanking-new poms?
>> And, if they do, could we give them a downconversion tool?
>>
>
> the new poms will arrive to central for everyone to use..
>
> Milos
>
>>
>> On Tue, Jun 28, 2011 at 6:47 PM, Stephen Connolly
>> <st...@gmail.com> wrote:
>>> maven 2.0.10 is still widely used. and convincing enterprises to upgrade is
>>> tricky... even our own model parsing is not forgiving if i recall
>>> correctly... so far as 3.0.x too
>>>
>>> - Stephen
>>>
>>> ---
>>> Sent from my Android phone, so random spelling mistakes, random nonsense
>>> words and other nonsense are a direct result of using swype to type on the
>>> screen
>>> On 28 Jun 2011 23:31, "Benson Margulies" <bi...@gmail.com> wrote:
>>>> This is a new thread for the topic I accidentally started with Steven.
>>>>
>>>> I'm fairly new around here, so please try to forgive me for
>>>> (re)stating the obvious.
>>>>
>>>> There is an ecosystem of tools that parse poms. They don't use any
>>>> library we give them, they just parse them.
>>>>
>>>> We want old tools to handle new poms without crashing.
>>>>
>>>> We'd like those tools to be able to distinguish legitimate extensions
>>>> from goofs, since some of them are trying to support authoring. This
>>>> is hard. Retroactively, it may be impossible. However, we do have XML
>>>> Schema to help us.
>>>>
>>>> If tools validate against the schema, they know when a POM is, in
>>>> fact, valid for its declared model. Thus, any elements that the tool
>>>> does not recognize are proved to be 'messengers from the future'.
>>>>
>>>> I personally think that it is madness to start telling people, 'well,
>>>> yes, we've extended the expressiveness of the pom, but you have to add
>>>> special off-to-the-side files to use the new elements.'
>>>>
>>>> So, one option we could adopt is to start a propaganda campaign now:
>>>> "Do you parse poms? Do you tolerate new elements? If not, better fix
>>>> your code now, because in a few months they will be arriving."
>>>>
>>>> After all, in theory, some existing tool could barf on new scopes or
>>>> any other supposedly compatible change we make.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Pom changes
Posted by Milos Kleint <mk...@gmail.com>.
On Wed, Jun 29, 2011 at 1:02 AM, Benson Margulies <bi...@gmail.com> wrote:
> But why do 2.0.10 users need to build against brand-spanking-new poms?
> And, if they do, could we give them a downconversion tool?
>
the new poms will arrive to central for everyone to use..
Milos
>
> On Tue, Jun 28, 2011 at 6:47 PM, Stephen Connolly
> <st...@gmail.com> wrote:
>> maven 2.0.10 is still widely used. and convincing enterprises to upgrade is
>> tricky... even our own model parsing is not forgiving if i recall
>> correctly... so far as 3.0.x too
>>
>> - Stephen
>>
>> ---
>> Sent from my Android phone, so random spelling mistakes, random nonsense
>> words and other nonsense are a direct result of using swype to type on the
>> screen
>> On 28 Jun 2011 23:31, "Benson Margulies" <bi...@gmail.com> wrote:
>>> This is a new thread for the topic I accidentally started with Steven.
>>>
>>> I'm fairly new around here, so please try to forgive me for
>>> (re)stating the obvious.
>>>
>>> There is an ecosystem of tools that parse poms. They don't use any
>>> library we give them, they just parse them.
>>>
>>> We want old tools to handle new poms without crashing.
>>>
>>> We'd like those tools to be able to distinguish legitimate extensions
>>> from goofs, since some of them are trying to support authoring. This
>>> is hard. Retroactively, it may be impossible. However, we do have XML
>>> Schema to help us.
>>>
>>> If tools validate against the schema, they know when a POM is, in
>>> fact, valid for its declared model. Thus, any elements that the tool
>>> does not recognize are proved to be 'messengers from the future'.
>>>
>>> I personally think that it is madness to start telling people, 'well,
>>> yes, we've extended the expressiveness of the pom, but you have to add
>>> special off-to-the-side files to use the new elements.'
>>>
>>> So, one option we could adopt is to start a propaganda campaign now:
>>> "Do you parse poms? Do you tolerate new elements? If not, better fix
>>> your code now, because in a few months they will be arriving."
>>>
>>> After all, in theory, some existing tool could barf on new scopes or
>>> any other supposedly compatible change we make.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Pom changes
Posted by Benson Margulies <bi...@gmail.com>.
But why do 2.0.10 users need to build against brand-spanking-new poms?
And, if they do, could we give them a downconversion tool?
On Tue, Jun 28, 2011 at 6:47 PM, Stephen Connolly
<st...@gmail.com> wrote:
> maven 2.0.10 is still widely used. and convincing enterprises to upgrade is
> tricky... even our own model parsing is not forgiving if i recall
> correctly... so far as 3.0.x too
>
> - Stephen
>
> ---
> Sent from my Android phone, so random spelling mistakes, random nonsense
> words and other nonsense are a direct result of using swype to type on the
> screen
> On 28 Jun 2011 23:31, "Benson Margulies" <bi...@gmail.com> wrote:
>> This is a new thread for the topic I accidentally started with Steven.
>>
>> I'm fairly new around here, so please try to forgive me for
>> (re)stating the obvious.
>>
>> There is an ecosystem of tools that parse poms. They don't use any
>> library we give them, they just parse them.
>>
>> We want old tools to handle new poms without crashing.
>>
>> We'd like those tools to be able to distinguish legitimate extensions
>> from goofs, since some of them are trying to support authoring. This
>> is hard. Retroactively, it may be impossible. However, we do have XML
>> Schema to help us.
>>
>> If tools validate against the schema, they know when a POM is, in
>> fact, valid for its declared model. Thus, any elements that the tool
>> does not recognize are proved to be 'messengers from the future'.
>>
>> I personally think that it is madness to start telling people, 'well,
>> yes, we've extended the expressiveness of the pom, but you have to add
>> special off-to-the-side files to use the new elements.'
>>
>> So, one option we could adopt is to start a propaganda campaign now:
>> "Do you parse poms? Do you tolerate new elements? If not, better fix
>> your code now, because in a few months they will be arriving."
>>
>> After all, in theory, some existing tool could barf on new scopes or
>> any other supposedly compatible change we make.
>>
>> ---------------------------------------------------------------------
>> 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 changes
Posted by Stephen Connolly <st...@gmail.com>.
maven 2.0.10 is still widely used. and convincing enterprises to upgrade is
tricky... even our own model parsing is not forgiving if i recall
correctly... so far as 3.0.x too
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 28 Jun 2011 23:31, "Benson Margulies" <bi...@gmail.com> wrote:
> This is a new thread for the topic I accidentally started with Steven.
>
> I'm fairly new around here, so please try to forgive me for
> (re)stating the obvious.
>
> There is an ecosystem of tools that parse poms. They don't use any
> library we give them, they just parse them.
>
> We want old tools to handle new poms without crashing.
>
> We'd like those tools to be able to distinguish legitimate extensions
> from goofs, since some of them are trying to support authoring. This
> is hard. Retroactively, it may be impossible. However, we do have XML
> Schema to help us.
>
> If tools validate against the schema, they know when a POM is, in
> fact, valid for its declared model. Thus, any elements that the tool
> does not recognize are proved to be 'messengers from the future'.
>
> I personally think that it is madness to start telling people, 'well,
> yes, we've extended the expressiveness of the pom, but you have to add
> special off-to-the-side files to use the new elements.'
>
> So, one option we could adopt is to start a propaganda campaign now:
> "Do you parse poms? Do you tolerate new elements? If not, better fix
> your code now, because in a few months they will be arriving."
>
> After all, in theory, some existing tool could barf on new scopes or
> any other supposedly compatible change we make.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>