You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jochen Kuhnle <jo...@kuhnle.net> on 2007/07/03 18:48:42 UTC

Proposal: Artifact variant resolution

I don't know if this has been discussed before, so please forgive me if 
this is the case.

Many applications of Maven require the use of artifact variants (i.e. 
the same version of an artifact built in different ways). Examples are 
the native Mojo discussion from [1], which require different variants 
for architecture/operating system/system (AOS), etc. Another example is 
a debug, release or obfuscated build of a jar. I don't think these 
variants can be defined in advance, because Maven cannot anticipate the 
possible variants people will want to produce. Also, in native land, a 
mere AOS will not suffice, since a library can be built with or without 
zlib/png/jpeg/whatever support. In addition, it should be possible to 
define alternatives if a variant is missing: If there's no debug build 
in the repo, Maven should be able to automatically use the normal one, 
or if there's no library optimized for the core2 processor, Maven 
should automatically use the i686 version.

Therefor this proposal is for Maven to support a generic and flexible 
variant system, inspired by Gentoo's USE variables [2]. A project would 
declare a variant section in its pom, specifying what variants are 
available, e.g.

<variant>
	<atom>
		<name>arch</name>
		<description>System architecture</description>
		<default>i386</default>
		<options>
			<option>
				<value>i386</value>
				<description>Generic i386 processor</description>
			</option>
			<option>
				<value>i686</value>
				<description>Generic i686 processor</description>
				<alternatives>i386</alternatives>
			</option>
		</options>
	</atom>
	<atom>
		<name>build</name>
		<description>Build type</description>
		<optional>true</optional>
		<options>
			<option>
				<value>debug</value>
				<description>Include debug information</description>
			</option>
			<option>
				<value>obfuscated</value>
				<description>Obfuscate the code</description>
			</option>
		</options>
	</atom>
</variant>

Option names and values should be unique within a project (no option 
value "debug" can be used in other options than "build" in the 
example). A project would also specify (e.g. via profiles) which 
variant is active, on a global and on a per-dependency scale:

<use>
	<option>
		<name>arch</name>
		<value>i686</value>
	</option>
	<option>
		<name>build</name>
		<value>debug</value>
	</option>
</use>

When resolving artifacts, Maven checks if all required ooptions are 
specified, and their values are valid. It then builds a variant 
specifier ("i686-debug") and uses this to resolve the artifact. I'm not 
sure if the classifier should be used for this, or if an additional 
field should be introduced, though. If an optional option :) is 
missing, it is ommited from the specifier (i.e. if "build" were 
unspecified in the example, the variant specifier would be "i686"). 
Also, if the artifact cannot be found with the variant specifier, maven 
tries omitting optional options. In the example, if the "i686-debug" 
variant is not present, we try the "i686" variant. It also tries to use 
alternatives, so in the example, we would also try "i386-debug" and 
"i386". There should be a well defined order, of course, in which the 
variants are tried.

Regards,
Jochen

[1] http://docs.codehaus.org/display/MAVEN/Support+for+other+languages
[2] http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=2



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org