Berin Loritsch wrote:
Stephen McConnell wrote:
With Merlin, it uses the Manifest (another Java standard) and marks certain
classes and interfaces as an Avalon Type or an Avalon Service.
This is incorrect. Merlin usage of manifest is 100% standard. Manifest
Right. I was not addressing standards issues.
Actually - you were when you said:
Both of these approaches try to comply with a standard that is already present
in Java land.
What I'm pointing out is that the Merlin usage of manifest information has nothing to do with the registration of type or service information. It has everything to do with structual dependency management done in a way that is 100% consistent with the java operational extensions specification.
entries describe jar file structural dependencies that the jar file containing the manfest has. This is referred to the optional extensions specification.
For trpe and service entries Merlin colocates <classname>.xtype and classname.xservice resources in a jar file. When a list of jar files if presented for loading (the result of the resolution of a set of target jar files + recusive optional jar dependency resolution, Merloin scanns each jar file for type and service entries, building a type and service repository in the process.
I thought that Merlin had entries like this:
Name: com.mycompany.MyService Service: True
Name: com.mycompany.impl.MyComponent Type: True
Not since Merlin 1.0. (a.k.a. a not since a very long time)
Or something similar. That is what I was referring to. The attributes/ meta-info wasn't part of the packaging discussion.
Both approaches work. The Merlin approach requires you to explicitly parse the
Manifest (which intails looking at the JarFile, getting its Manifest, and using
the Manifest object to parse the contents). Fortress allows you to work with a
set of files that are no more than a list. You to simply use the getResource()
or getResources() methods to get the lists.
This mixes up what is going on. Merlin mani9fest usaage to get establish the physical depndencies that one jar file has on othe jar files, and from that, recusive assemsment of what depednecies thosr new hjars have. There is nothing equivalent to this in Fortress.
Typing with fat fingers?
:-) Here is the corrected version:
Merlin uses manifest information to establish the physical dependencies that one jar file has on another jar files, and from that, recusively builds a tree of dependencies taking into account the dpendencies of the dependent jars, etc. This is at a totally different level of abstraction to the question of where and how services, types or attributes are registeered. Instead - its about the management of the physical dependencies that a jar file has.
I think the content of what we were talking about was getting the list of components/services inside a JAR. Inter-JAR dependencies were not the subject here.
Ok - your references to Merlin usage of manifest information (which are only dealing with inter-jar dependencies) did not make this clear.
Both of these approaches try to comply with a standard that is already present
in Java land.
Which standards are you referring to?
Merlin: Manifest entries Fortress: JAR Services entries
Question remains - which standards are you referring to (URL to spec- etc.)?
Stephen.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
