You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by ao...@bellsouth.net on 2003/11/07 02:36:12 UTC

[part due] What is an ArtifactDatabase?

Time for some more.  Trying to send out bite sized chunks ;-)

> ANSWER: I don't know yet but time will tell.

I really know the answer since its all part of a hidden agenda (out in the open now) - just trying to fake humility ;-)

Ok lets talk about some initial content for the time being that can be generated during the build process.  BTW I really think we should factor this into the merlin plugin for maven eventually.  Steve you think this is a good idea?

For the time being I shall keep the content minimal.  We'll just add a multi-valued attribute to represent the dependencies the jar has on other artifacts.  This will help us build the appropriate classloaders.  Here are two attributes for this:

NOTE: multi-valued properties are expressed using an enumeration convention.  Basically we append a number component to the dotted property name (i.e. buildtime.dependency.3).

* buildtime.dependency
  An enumerated (multi-valued) property whose value is an artifact
  descriptor/specification representing a buildtime dependency.

* runtime.dependency
  An enumerated (multi-valued) property whose value is an artifact
  descriptor/specification representing a runtime dependency.

How to differentiate this in the POM so we can autogenerate - I don't know.  If we can't we'll just use one property 'dependency' for both runtime and buildtime attributes.  Steve I'll leave this one upto you since you know more about how Maven and the POM works.

Now you may ask how do I determine the api, spi and implementation nature of the artifact if it is a jar to have the Repository build the right ClassLoader?  Let's use a convention where the api, spi, impl usage tag is embedded into the artifact name.  So let's presume the name ends with this tag as Steve has been doing to date.

Comments? Thoughts?

Alex



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: [part due] What is an ArtifactDatabase?

Posted by Stephen McConnell <mc...@apache.org>.

aok123@bellsouth.net wrote:

>Time for some more.  Trying to send out bite sized chunks ;-)
>
>  
>
>>ANSWER: I don't know yet but time will tell.
>>    
>>
>
>I really know the answer since its all part of a hidden agenda (out in the open now) - just trying to fake humility ;-)
>

ROTFLOL
Yuor doing a terribly bad job of hidding the agenda!
LOL

Stephen.

(still ROTFL)

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: [part due] What is an ArtifactDatabase?

Posted by Stephen McConnell <mc...@apache.org>.

aok123@bellsouth.net wrote:

>Time for some more.  Trying to send out bite sized chunks ;-)
>
>>ANSWER: I don't know yet but time will tell.
>>    
>>
>
>I really know the answer since its all part of a hidden agenda (out in the open now) - just trying to fake humility ;-)
>
>Ok lets talk about some initial content for the time being that can be generated during the build process.  BTW I really think we should factor this into the merlin plugin for maven eventually.  Steve you think this is a good idea?
>
>For the time being I shall keep the content minimal.  We'll just add a multi-valued attribute to represent the dependencies the jar has on other artifacts.  This will help us build the appropriate classloaders.  Here are two attributes for this:
>
>NOTE: multi-valued properties are expressed using an enumeration convention.  Basically we append a number component to the dotted property name (i.e. buildtime.dependency.3).
>
>* buildtime.dependency
>  An enumerated (multi-valued) property whose value is an artifact
>  descriptor/specification representing a buildtime dependency.
>
>* runtime.dependency
>  An enumerated (multi-valued) property whose value is an artifact
>  descriptor/specification representing a runtime dependency.
>
>How to differentiate this in the POM so we can autogenerate - I don't know.  If we can't we'll just use one property 'dependency' for both runtime and buildtime attributes.  Steve I'll leave this one upto you since you know more about how Maven and the POM works.
>


OK - looking at this from the point of view of POM --> 
ArtifactDescriptor property file generation.  We can generate basic info 
about an artifact - name, version, organization, etc. That's easy enough 
(and already done).  For the dependencies - what I suggest is that we 
take the pure Maven dependencies and write these out with all 
attributes.  This means that the actual determination of attribute 
meaning is handled by the repository cache, not by the jelly script.  
This means that the actual logic is focussed in a single location - the 
java sources in the repository package. 

This would translate to something like:

#
# generic project properties
# (artifact name, version, organization, build signature, etc.)
#
avalon.artifact.[feature-name]=[value]

#
# dependencies
#
avalon.dependency.[i] = [group]:[artifact-name];[version]
avalon.dependency.[i]?[property-name] = [value]

>Now you may ask how do I determine the api, spi and implementation nature of the artifact if it is a jar to have the Repository build the right ClassLoader?  Let's use a convention where the api, spi, impl usage tag is embedded into the artifact name.  So let's presume the name ends with this tag as Steve has been doing to date.
>

Yep. But keep the code in java over in the repository package.

Some other points - I've been thinking about the actual artifact 
descriptor and I think this should not be a .properties file.  Instead I 
think this should a .artifact file held in the following location:

    [group]/artifacts/[artifact-name]-[version].artifact

I don't think we should be including a reference to remote repository 
locations - in fact I think that it is important that we don't include 
this bacause artifact description (all of the avalon.artifact stuff) is 
in effect defining a contract signature.  Seconly, repository locations 
must be under the complete control of the client using the repository.

Thoughts?

Stephen.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: [part due] What is an ArtifactDatabase?

Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 07 November 2003 09:36, aok123@bellsouth.net wrote:
> How to differentiate this in the POM so we can autogenerate - I don't know.

More hidden agenda ???

LOL.

Niclas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org