Why not further steps towards terseness?
1. Get rid of collection container elements.
Why this:
<execution id="generate">
<goals>
<goal>descriptor</goal>
</goals>
</execution>
When this wold suffice:
<execution id="generate">
<goal>descriptor</goal>
</execution>
This seems like a trivial issue, but when you look at all of the
container elements, dependencies, plugins, exclusions, profiles.
Doing this would require...
2. Getting away from xs:all and defining an order for child elements
throughout the XSD.
On Feb 11, 2008, at 12:45 AM, Brett Porter wrote:
Hi,
I've always wanted to see an attribute based POM, so based on
Nicolas' suggestion I killed some time after waking up early this
morning to do it.
JIRA: http://jira.codehaus.org/browse/MNG-3397
Here is a build to try:
http://people.apache.org/~brett/apache-maven-2.0.9-SNAPSHOT-terse-bin.tar.gz
and svn branch:
http://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x-terse
Here are two different files for comparison (it halved the size):
http://svn.apache.org/viewvc/maven/archiva/trunk/pom.xml?content-type=text%2Fplain&view=co
http://svn.apache.org/viewvc/maven/archiva/trunk/pom-4.1.0.xml?content-type=text%2Fplain&view=co
What I did is basically convert all the primitive types in the model
to attributes. I think more could be done (flattening lists, doing
the same for plugin configuration elements), but this gets a big win
at least in the dependencies section for minimal work.
It should be completely backwards compatible. It detects v4.0.0 and
reads it like it used to (then internally converts to the 4.1.0 Java
model).
Here's some notes on the implementation so far (again, go easy, I
just whipped this up today and it's not production ready):
- I see this as a stepping stone to the final solution. I've said
this before, but I think the POM should separate the build
information from the project metadata (particularly that stored in
the repository). I think we need to take baby steps towards that
though.
- this could feasibly be applied to the settings and profile files
too.
- I switched to StAX in the process. This is likely going to
introduce some small quirks we need to iron out (like the hack I
added to parse Trygve's name - why did we ever allow that!) I think
ideally we'd use the Xpp3Reader for 4.0.0 and the StaxReader for
4.1.0 for best compatibility. This would also fix the problem in
that I've just removed the Xpp3Reader and so some plugins may choke.
I'm sure the release plugin won't be happy, for example.
- There is probably a slight performance overhead in reading v4 POMs
since it repopulates the model twice. I haven't measured it but if
it's an issue we could optimise the reader/converter. It also adds
about 200k to the maven-model JAR.
- It is very close to detecting based on namespace so we could
enforce the use of that instead.
Enjoy!
Cheers,
Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
