I think this would be better served by just having dependencyGroup,
and inheriting something from that, and allowing them to be nested.
<dependencyGroup groupId="org.apache.maven.archiva" version="1.1-
SNAPSHOT">
<dependency artifactId="archiva-applet" />
...
<dependencyGroup version="1.0">
<dependency artifactId="old-archiva-dependency" />
</dependencyGroup>
</dependencyGroup>
I think the second use case across versions is uncommon and makes it
harder to read.
I'm collecting these up to put back into the wiki later on - though
this initial attempt is intended not to change the model just yet
(though it's very feasible with the current codebase as it has model
conversion built in).
Cheers,
Brett
On 11/02/2008, at 11:05 PM, Stephen Connolly wrote:
Also what about a <dependencyVersion>
<dependencies>
<dependencyGroup groupId="org.apache.maven.archiva">
<dependency artifactId="archiva-core" version="${pom.version}"/>
<dependencyVersion version="1.1-SNAPSHOT">
<dependency artifactId="archiva-applet"/>
<dependency artifactId="archiva-artifact-converter"/>
<dependency artifactId="archiva-artifact-reports"/>
<dependency artifactId="archiva-common"/>
<dependency artifactId="archiva-configuration"/>
<dependency artifactId="archiva-consumer-api"/>
<dependency artifactId="archiva-converter"/>
<dependency artifactId="archiva-dependency-graph"/>
<dependency artifactId="archiva-core-consumers"/>
<dependency artifactId="archiva-database"/>
<dependency artifactId="archiva-database-consumers"/>
<dependency artifactId="archiva-indexer"/>
<dependency artifactId="archiva-lucene-consumers"/>
<dependency artifactId="archiva-model"/>
<dependency artifactId="archiva-plexus-application"
type="plexus-application"/>
<dependency artifactId="archiva-policies"/>
<dependency artifactId="archiva-proxy"/>
<dependency artifactId="archiva-report-manager"/>
<dependency artifactId="archiva-repository-layer"/>
<dependency artifactId="archiva-scheduled"/>
<dependency artifactId="archiva-security"/>
<dependency artifactId="archiva-signature-consumers"/>
<dependency artifactId="archiva-transaction"/>
<dependency artifactId="archiva-docs" type="zip"
classifier="docs"/>
</dependencyVersion>
</dependencyGroup>
<dependencyVersion version="4.5">
<dependency groupId="com.mycompany.common" artifactId="common"/>
<dependencyGroup groupId="com.mycompany.core">
<dependency artifactId="core-framework"/>
<dependency artifactId="core-logging"/>
</dependencyGroup>
</dependencyVersion>
</dependencies>
On Feb 11, 2008 11:40 AM, Niall Pemberton
<[EMAIL PROTECTED]> wrote:
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
<http://people.apache.org/%7Ebrett/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]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
