A classic use-case of this that I think is orthogonal to "javadoc" and
"sources" classifiers would be binary native artifacts per-platform.
Taking libc for a sec, (stupid example, but what the heck... You
might have:
libc-2.0.5-win32-win32.dll.
libc-2.0.5-openbsd-i386.so
libc-2.0.5-darwin-i386-ppc.dynlib (fat binary)
These are all built from the same canonical sources, so how would you
structure them. Above would be the artifact using a quasi-
classifier. If you ended up with crazy projects with "../" throughout
the build path, you might create 3 modules that actually compiler the
artifacts, at which point you have:
libc-win32-win32-2.0.5.dll.
libc-openbsd-i386-2.0.5.so
libc-darwin-i386-ppc-2.0.5.dynlib (fat binary)
(where the artifactId of the parent is "libc", and the modules are
"llibc-win32-win32")
Here you end up with additional craziness on Mac owing to universal
(fat) binaries, since in the underlying structures it's not universal,
but i386+ppc.
The point is that neither futzing with modues, or hacking classifiers
is sufficient. But associative metadata might just be the trick.
Christian.
On 4-Feb-08, at 13:45 , John Casey wrote:
I can accept this, particularly if it leads to having dependency
metadata that is specific to these [formerly attached] artifacts.
Assemblies that contain their dependencies, when used as
dependencies, should affect dependency resolution differently than
the associated "naked" jar...which to me means it needs different
dependency metadata.
I'm fine with defining a superset of the association mechanism that
includes artifacts currently deployed with classifiers, as long as
we can use what's out there now without creating another buggy
metadata deficit like we did when moving from Maven 1.x to 2.0.
-john
On Feb 4, 2008, at 12:38 PM, Jason van Zyl wrote:
On 4-Feb-08, at 8:56 AM, John Casey wrote:
I'd tend to disagree about classifier not being a 'core' part of
the artifact system...it distinguishes a main artifact from one of
its derivatives, and serves as a pretty foundational part of how
we retrieve artifacts from existing remote repositories. Without
it, I doubt that you can reconstruct the path to some existing
artifacts (like sources or javadocs) reliably without bastardizing
the version string.
This is where I think you've already baked in what you think about
Maven. Look at how we deploy our derivative artifacts right now. We
don't track any of it in the metadata when we deploy. We toss it up
there and things hope they are there. Like javadocs, or sources. I
think what's more important is that the coordinate be unique and we
have a way to associate what ever artifacts together in a scalable
way. So you say "I want to associate this artifact with that one,
this is how I would like to record that relationship in the
metadata.". Subsequently you can query the metadata and know these
relationships. We currently don't do this. It generally boils down
to a bunch of coordinates in the repository. How we choose to
relate them via the metadata. We have all sort of problems with
classifiers currently because it was an adhoc method of
association. A general model of association would be a superset of
what we currently do for classifiers. I agree we need an mechanism
for association, I don't think classifiers have worked all that well.
We can see that the artifact system has certain inescapable
identity attributes. Scope is obviously more related to how an
artifact is used, since you can't see any trace of scope in the
artifact as it's been deployed on a remote repository. Classifier,
however, doesn't fit this criteria...it's not a usage marker, but
an identity marker.
The rest I agree with.
-john
On Feb 4, 2008, at 3:00 AM, [EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Mon Feb 4 00:00:21 2008
New Revision: 618196
URL: http://svn.apache.org/viewvc?rev=618196&view=rev
Log:
o notes about the refactoring
Added:
maven/artifact/branches/CAP/notes.txt (with props)
Added: maven/artifact/branches/CAP/notes.txt
URL:
http://svn.apache.org/viewvc/maven/artifact/branches/CAP/notes.txt?rev=618196&view=auto
=
=
=
=
=
=
=
=
=
=
=
===================================================================
--- maven/artifact/branches/CAP/notes.txt (added)
+++ maven/artifact/branches/CAP/notes.txt Mon Feb 4 00:00:21 2008
@@ -0,0 +1,28 @@
+Maven Artifact is supposed to be a general artifact mechanism
for retrieving, installing, and deploying artifacts
+to repositories. Maven Artifact was originally decoupled from
Maven proper and as such carries a lot of baggage
+which prevents it from being used generally and carries many
notions that are very specific to Maven itself. Artifacts
+currently have a notion of scope, classifiers, and behavioral
attributes such as whether scopes should be inherited.
+For any mechanism to work generally these baked in notions need
to be removed, vetted, and then made compatible with
+notions currently in Maven. A list of things that should not be
in the Artifact:
+
+ * scope
+ * classifier
+ * dependency filter
+ * dependency trail
+ * resolved
+ * released
+ * optional
+ * available versions
+
+These are all attributes of the target system
+
+*Removal of the ArtifactFactory
+
+ 3 February 2008 (Sunday)
+
+ I have removed the factory and left only a small set of
constructors (which I would like to reduce to one) so that you
+ have a valid artifact after construction. I have also started
to hide the VersionRange creation. You just pass in
+ a string and the constructor for the DefaultArtifact will do
the right thing. This will ultimately need to be more
+ pluggable as different versioning strategies happen. But
variations of the theme like Maven, OSGi, will have their
+ own subclasses and tools to operate on the graphs of
dependencies.
+
Propchange: maven/artifact/branches/CAP/notes.txt
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: maven/artifact/branches/CAP/notes.txt
------------------------------------------------------------------------------
svn:keywords = "Author Date Id Revision"
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
