I have put the proposal here: http://docs.codehaus.org/display/MAVENUSER/Expanded+Classifier+Support
Thanks, Shane On 8/9/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > Put the proposal in here with the others: > > http://docs.codehaus.org/display/MAVEN/Home > > This one in particular is the pattern I would like to shoot for: > > http://docs.codehaus.org/display/MAVEN/Decoupling+of+Maven+Artifact > > Akin to "The Pattern Language" way of describing problems and solutions. > > I'm interested in the proposal, as I'm sure others are, but it will > get lost in the mailing list. > > If you don't have access to the wiki, just ping me and I'll flip the > necessary bits. > > On 9 Aug 07, at 8:10 PM 9 Aug 07, Shane Isbell wrote: > > > I have a concern, as I am sure other do, that NMaven may drift too > > far apart > > from Maven; I would like to start raising some the issues that may > > impact > > Maven on the general dev list so that solutions can be considered for > > 2.1+versions of Maven. One important issue is classifiers. In a > > typical Maven > > case, the classifier may be used to classify an artifact as JDK-1.3 or > > JDK-1.4 for its target platform. In the case of J2ME, things get more > > complicated and such a single classifier becomes problematic > > because their > > can be many classifiers (which are referred to as requirements > > needed for > > the artifact to be used on the target platform). For example, the > > artifact > > may require libraries for MMS support or certain media support > > (JSR-135) to > > be able to build. To this day, Maven still has not adequately > > addressed this > > part of the Java world. We also have a similar case in the .NET > > world, where > > we are targeting different processors, framework versions, vendor > > implementations and so on. The general problem is taking Maven from > > supporting the J2SE world, which has great cross-platform support, to > > environments that are partially cross-platform. > > > > The way NMaven currently handles this problem, is to use the public > > key > > token ID, from a signed .NET artifact, as the classifier. Then I > > can attach > > requirements (or attributes) to that classifier. For example, say > > that the > > value of my public key token ID is 4b435f4d76e2f0e6. I can > > associate with > > that value the following attributes: vendor=microsoft, > > frameworkVersion=2.0. > > This has the implication that only signed artifacts can have artifact > > requirements. To understand this approach, requires understanding the > > constraints of the system. First there is only one classifier > > within the pom > > (and its associated dependency object within the Maven API). > > Second, the > > Global Assembly Cache - where Microsoft strong-named assemblies are > > stored > > for a global context - uses the public key token ID within the path > > of the > > assembly. Thus if I have a classifier (pom), some associated meta- > > data (RDF) > > tied to that classifier, and the classifier value > > (4b435f4d76e2f0e6) within > > the path of the assembly within the GAC, then I can always tell > > what the > > requirements are for an artifact, regardless of whether they are > > stored in > > the local repository or an external repository such as the GAC. If > > I need > > new requirements, I just sign the assembly with a different key, still > > having both artifacts in the GAC. > > > > Now, I don't expect that this would apply to Java's case, but I > > think that > > it is important to understand at least one context of the problem > > and how it > > is solved. Other contexts could also be drawn from the J2ME world. > > What I am > > convinced of - in the general case - is that using a GUID for the > > classifier > > and then having associated attributes tied to that GUID makes a lot of > > sense. If we take the case of multiple classifiers, then we would > > need more > > sophisticated matching process to tell whether two artifacts are > > indeed > > different. A GUID, as the classifier, allows two artifacts - with > > the same > > groupId, artifactId, version - to differentiate themselves by > > matching a > > single field. Then it is just a matter of associating the > > requirements to > > that classifier value/GUID. > > > > Regards, > > Shane > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder and PMC Chair, Apache Maven > jason at sonatype dot com > ---------------------------------------------------------- > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
