You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Shane Isbell <sh...@gmail.com> on 2007/08/09 20:10:50 UTC
Expanding Classifier Support
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
Re: Expanding Classifier Support
Posted by Jason van Zyl <ja...@maven.org>.
We'll never see your proposals being hidden in JIRA. And they are
effectively hidden in JIRA because I never knew you did anything with
respect to qualifiers.
http://docs.codehaus.org/display/MAVENUSER/User+Proposals
Then we know who has proposed what. JIRA (and any issue management
system), turns out to be a crap way to draft proposals disseminate
the information to a group of people.
On 10 Aug 07, at 10:38 AM 10 Aug 07, Cédric Vidal wrote:
> Hi,
>
> I'm actually also very concerned by this Maven limitation.
>
> Vincent Massol already reported this limitation last year here:
> http://jira.codehaus.org/browse/MNG-2596
>
> He mentioned the conflict between the clover and source plugins
> which both
> try to add a qualifier.
>
> I reported a different use case impacted by the same limitation in:
> http://jira.codehaus.org/browse/MNG-2650
>
> I proposed an alternative solution, much less sophisticated than
> yours ;)
> which doesn't addresses as many use cases as yours but simpler here:
> http://jira.codehaus.org/browse/MNG-2649
>
> It encodes the list of qualifiers in the filename. It makes it easy
> to grasp
> the meaning of the qualifiers just by reading the file name of the
> artifact.
> (By the way, I checked that the proposed file naming scheme is
> compatible
> with NTFS and EXT2 file systems)
>
> Hoping your mail will raise interest in the subject ;) Indeed, the
> aforementioned issues didn't get much attention the first time.
>
> Regards,
>
> Cédric
>
> -----Message d'origine-----
> De : Shane Isbell [mailto:shane.isbell@gmail.com]
> Envoyé : jeudi 9 août 2007 22:22
> À : Maven Developers List
> Objet : Re: Expanding Classifier Support
>
> I have put the proposal here:
>
> http://docs.codehaus.org/display/MAVENUSER/Expanded+Classifier+Support
>
> Thanks,
> Shane
>
>
> On 8/9/07, Jason van Zyl <ja...@maven.org> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Expanding Classifier Support
Posted by Cédric Vidal <c....@proxiad.com>.
Hi,
I'm actually also very concerned by this Maven limitation.
Vincent Massol already reported this limitation last year here:
http://jira.codehaus.org/browse/MNG-2596
He mentioned the conflict between the clover and source plugins which both
try to add a qualifier.
I reported a different use case impacted by the same limitation in:
http://jira.codehaus.org/browse/MNG-2650
I proposed an alternative solution, much less sophisticated than yours ;)
which doesn't addresses as many use cases as yours but simpler here:
http://jira.codehaus.org/browse/MNG-2649
It encodes the list of qualifiers in the filename. It makes it easy to grasp
the meaning of the qualifiers just by reading the file name of the artifact.
(By the way, I checked that the proposed file naming scheme is compatible
with NTFS and EXT2 file systems)
Hoping your mail will raise interest in the subject ;) Indeed, the
aforementioned issues didn't get much attention the first time.
Regards,
Cédric
-----Message d'origine-----
De : Shane Isbell [mailto:shane.isbell@gmail.com]
Envoyé : jeudi 9 août 2007 22:22
À : Maven Developers List
Objet : Re: Expanding Classifier Support
I have put the proposal here:
http://docs.codehaus.org/display/MAVENUSER/Expanded+Classifier+Support
Thanks,
Shane
On 8/9/07, Jason van Zyl <ja...@maven.org> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Expanding Classifier Support
Posted by Shane Isbell <sh...@gmail.com>.
I have put the proposal here:
http://docs.codehaus.org/display/MAVENUSER/Expanded+Classifier+Support
Thanks,
Shane
On 8/9/07, Jason van Zyl <ja...@maven.org> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Expanding Classifier Support
Posted by Jason van Zyl <ja...@maven.org>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Expanding Classifier Support
Posted by John Casey <jd...@commonjava.org>.
I think this approach makes a lot of sense. It's a problem I've run
into in the C/C++ world, too, where any number of compiler options
may be supplied during a given build, not to mention target
architecture and operating systems. I had been thinking for the past
year or so that we should go to some sort of dependency-requirements
spec that would enumerate the attributes that a matching dependency
must have in order to qualify...that specification would be specified
in the dependent POM globally. When that project itself was deployed,
it would have an accompanying specification of the dependency
requirements it asserted.
We can talk more about this stuff on the wiki, though.
Thanks for putting this together,
-john
On Aug 9, 2007, at 2:10 PM, 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
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john