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
