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
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 d
>
>
>
> 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 n
>>
>> 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.
On 29 June 2011 12:20, Benson Margulies 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.
>
> L
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 alternati
On Wed, Jun 29, 2011 at 1:02 AM, Benson Margulies 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, S
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
wrote:
> maven 2.0.10 is still widely used. and convincing enterprises to upgrade is
> tricky... even our own model
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 dire
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 n
>> So can we make changes to the model in 2.1, or do we have to work
>> with the existing model?
>>
>Provide we retain the behavior of old with a flag if the user desires
>with 2.1 the door is wide open to correct anything we see fit.
It's more than that, the poms deployed to central should c
On 22-May-08, at 7:28 AM, Paul Gier wrote:
Improved dependency version conflict resolution, and a lot of other
important issues either require or would benefit from changing the
pom model. As far as I can tell, there have not yet been any
changes to this model in the 2.1 branch. So I was
Improved dependency version conflict resolution, and a lot of other important
issues either require or would benefit from changing the pom model. As far as I
can tell, there have not yet been any changes to this model in the 2.1 branch.
So I was wondering what should be the strategy for changes
[ http://jira.codehaus.org/browse/MEV-21?page=all ]
Carlos Sanchez closed MEV-21:
-
Resolution: Fixed
> pom changes for basic hibernate project
> ---
>
> Key: MEV-21
> URL: http://ji
should be
"1.0RC2" (note capitalization difference).
That's the only difference I had to make to use the hibernate pom present in
the M2 repository as of right now.
> pom changes for basic hibernate project
> ---
>
>
: Maven Evangelism (was: Maven 2)
> pom changes for basic hibernate project
> ---
>
> Key: MEV-21
> URL: http://jira.codehaus.org/browse/MEV-21
> Project: Maven Evangelism
> Type: Task
> Components: Dependenc
ehcache
ehcache
1.1
runtime
cglib
cglib
2.0.2
asm
asm
1.4.3
geronimo-spec
geronimo-spec-jta
1.0-M1
> pom changes for basic hibernate proj
On Fri, 2005-05-13 at 13:23 -0500, Ryan Sonnek (JIRA) wrote:
> pom changes for basic hibernate project
> ---
>
> Key: MNG-387
> URL: http://jira.codehaus.org/browse/MNG-387
> Project: m2
> Type: Bug
>
pom changes for basic hibernate project
---
Key: MNG-387
URL: http://jira.codehaus.org/browse/MNG-387
Project: m2
Type: Bug
Components: repository-tools
Reporter: Ryan Sonnek
it seems as if the current m2 repository has
19 matches
Mail list logo
