Message-ID: <2064787091.2301.1419062570602.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_2300_917278188.1419062570601" ------=_Part_2300_917278188.1419062570601 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Many applications of Maven require the use of artifact variants = (i.e. the same version of an artifact built in different ways). Examples ar= e the Native Mojo discussionSupport for other languages= , which requires different variants for architecture/operating system/s= ystem (AOS), etc. Another example is a debug, release or obfuscated build o= f a jar. I don't think these variants can be defined in advance, because Ma= ven cannot anticipate the possible variants people will want to produce. Al= so, in native land, a mere AOS will not suffice, since a library can be bui= lt with or without zlib/png/jpeg/whatever support. In addition, it should b= e possible to define alternatives if a variant is missing: If there's no de= bug 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 sho= uld automatically use the i686 version.=20
Therefor this proposal is for Maven to support a generic and flexible va= riant system, inspired by Gentoo's USE variables. A project would declare a variant section= in its pom, specifying what variants are available, e.g.=20 =20
Option names and values should be unique within a project (no option val= ue "debug" can be used in other options than "build" in= the example). A project would also specify (e.g. via profiles) which varia= nt is active, on a global and on a per-dependency scale:=20 =20
When resolving artifacts, Maven checks if all required options are speci= fied, 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 t= he classifier should be used for this, or if an additional field should be = introduced, though. If an optional option is missing, it is omitted fr= om the specifier (i.e. if "build" were unspecified in the example= , the variant specifier would be "i686"). Also, if the artifact c= annot be found with the variant specifier, maven tries omitting optional op= tions. In the example, if the "i686-debug" variant is not present= , we try the "i686" variant. It also tries to use alternatives, s= o in the example, we would also try "i386-debug" and "i386&q= uot;. There should be a well defined order, of course, in which the variant= s are tried.