On 05/02/2008, at 6:35 AM, Christian Edward Gruber wrote:
The point is that neither futzing with modues, or hacking
classifiers is sufficient. But associative metadata might just be
the trick.
This is the approach we took with Eclipse Kepler as we mapped out the
repository. We actually keep the project coordinate as a single
identifier, and attach multiple artifacts to it (which would be the
derivatives listed here). Each artifact can have multi-faceted
information on it (so in Maven's case it's the classifier, but it
could be extended to track different types of derivative and multiple
attributes).
The relationships still sit with the project rather than the artifact
- and I believe that is still valid. Rather than recreating a
basically identical POM for each artifact, I feel it's better to
filter the information out via additional metadata.
- Brett
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
