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
On 29 June 2011 12:20, Benson Margulies bimargul...@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
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
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
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
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
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
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
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
stephen.alan.conno...@gmail.com wrote:
maven 2.0.10 is still widely used. and convincing enterprises to upgrade is
On Wed, Jun 29, 2011 at 1:02 AM, Benson Margulies bimargul...@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,
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
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
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 conform
[ 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://jira.codehaus.org/browse
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
---
Key: MEV-21
URL: http
: 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: Dependencies
Reporter: Ryan Sonnek
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
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
18 matches
Mail list logo
