[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
