Kenney Westerhof wrote:
On Fri, 31 Mar 2006, Jason van Zyl wrote:
Some thoughts/ideas:
I didn't realize checking was on! You can specify multiple <dependencies>
sections etc, and it still works.
Whoops.
Also the namespace in the pom is not used.
The presence of the schema location tag is also ignored, but this is
usually the responsibility of the parser - I did not know that the
XmlPullParser supported schema's. But you're probably referring to
the generated parser being strict or not.
Yup.
That said: if you still want strict checking AND allow the pom to be
extendable, support one of the following to options:
1) a <custom> tag, defined in schema as
<xs:complexType>
<xs:any/> (i think - all content allowed).
</xs:complexType>
I.e. a specific tag that allows for extensions.
2) Allow foreign namespaces. Currently the pom has a namespace defined
but it is not used:
xmlns="http://maven.apache.org/POM/4.0.0";
Either the 'default' namespace, or this namespace, is allowed (i think ANY
namespace is allowed).
The drawback of 1) is that there's just 1 place you can add extensions;
maybe some people like to add extra metadata to <dependency> tags.
True, but not sure if we want to allow things all over the place. But I
think tags/properties should come back to dependencies btw.
Solution 2 allows for that: as long as they declare the tags with
a different namespace (NOT the default namespace and NOT the POM v4
namespace), it's allowed.
But Xpp3 probably doesn't support schema's and namespaces.
No, but we could use something like StAX. We could just use the the
Xpp3Dom as our internal representation and adapt the use of something
else. Unfortunately I used Xpp3Dom directly in lots of places in Plexus
and so it spread.
:)
-- Kenney
John Casey wrote:
so, how do you gain access to the custom section? Would you have to
re-parse the whole pom? Also, would <custom/> be subject to any sort of
inheritance, or would it simply be invisible to the project builder?
Think the most convenient would to put the Xpp3DOM object in the
MavenProject so that you could gain raw access to anything in the
document. That would probably require a change to modello so that you
didn't have to parse it twice
I think some simple attributes for indicating whether you want an
element aggregated or overridden would do the trick for inheritance. So
each MavenProject gets the built up custom Xpp3Dom and then, at first,
plug-ins do whatever they want with the information. Even if we were to
use something like RDF (as some are suggesting on IRC) you would need a
general way to get at the XML to process it. We could probably have an
abstract plug-in or tool that did our standard Xpp3Dom -> object model
mapping to make it easier. But I think that would pretty much do it.
Maybe for 2.1 (or 2.2) we could do RDF but I think this allows some
flexibility in the meantime allows us to get some extensions in without
having to formalize the model. If we stick with the one <custom/>
element we could probably think now about how this could map to RDF or
namespace use if we go that way. So it works now and can be mapped to
whatever we might use in the future if we decide to go RDF/namespaces.
-john
Jason van Zyl wrote:
Jason van Zyl wrote:
Hi,
For some reason I thought that the strictness in model parsing had
been turned off. I was playing around trying to add a <custom/>
element and noticed it is still on.
Can we enable the lax parsing in order to make the POM extensible?
The POM will will still be validated at the object model level so
this shouldn't cause any grief. I just want to put this on the trunk
and maybe push out in the next point release.
I turned off strict parsing and could bootstrap no problem with this
in the Maven top-level POM:
<project>
...
<custom>
<categories>
<category>Build Tools<category>
</categories>
<tags>
<tag>Project Management</tag>
<tag>Build Management</tag>
</tags>
<downloadSite>http://maven.apache.org/download.html</downloadSite>
</custom>
...
</project>
This these little blurbs I'm trying to make a baby CodeZoo
(http://www.codezoo.org) and a DOAP file generator plugin. We have
most of the bits needed for DOAP but we're missing a couple things.
All sorts of cool stuff we could do!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
jason at maven.org
http://maven.apache.org
Three people can keep a secret provided two of them are dead.
-- Unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
jason at maven.org
http://maven.apache.org
A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.
-- Jakob Burckhardt
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
