You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maven.apache.org by jv...@apache.org on 2008/02/04 09:00:22 UTC
svn commit: r618196 - /maven/artifact/branches/CAP/notes.txt
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"
Re: svn commit: r618196 - /maven/artifact/branches/CAP/notes.txt
Posted by Brett Porter <br...@apache.org>.
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, jvanzyl@apache.org 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---
>> 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: 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: svn commit: r618196 - /maven/artifact/branches/CAP/notes.txt
Posted by Christian Edward Gruber <ch...@gmail.com>.
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, jvanzyl@apache.org 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r618196 - /maven/artifact/branches/CAP/notes.txt
Posted by John Casey <jd...@commonjava.org>.
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, jvanzyl@apache.org 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
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
Re: svn commit: r618196 - /maven/artifact/branches/CAP/notes.txt
Posted by Jason van Zyl <ja...@maven.org>.
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, jvanzyl@apache.org 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r618196 - /maven/artifact/branches/CAP/notes.txt
Posted by John Casey <jd...@commonjava.org>.
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.
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, jvanzyl@apache.org 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