On Feb 11, 2008 6:45 AM, Brett Porter <[EMAIL PROTECTED]> 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
How about the option to specify a "dependency" group for dependencies
that have the same groupId - something like:
<dependencyGroup groupId="org.apache.maven.archiva">
<dependency artifactId="archiva-applet"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-artifact-converter"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-artifact-reports"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-common"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-configuration"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-consumer-api"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-converter"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-dependency-graph"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-core"
version="${pom.version}"/>
<dependency artifactId="archiva-core-consumers"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-database"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-database-consumers"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-indexer"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-lucene-consumers"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-model"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-plexus-application"
version="1.1-SNAPSHOT" type="plexus-application"/>
<dependency artifactId="archiva-policies"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-proxy"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-report-manager"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-repository-layer"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-scheduled"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-security"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-signature-consumers"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-transaction"
version="1.1-SNAPSHOT"/>
<dependency artifactId="archiva-docs"
version="1.1-SNAPSHOT" type="zip" classifier="docs"/>
</dependencyGroup>
Niall
> 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]
