Thanks for the links. Do you know if there is a maven task to automatically generate this manifest entries based on the project.xml? If not this might be a first step in order to allow easy adoption for the upcoming assembly-component ;-)
> -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Im Auftrag von Craig McClanahan > Gesendet: Dienstag, 21. Dezember 2004 21:28 > An: Jakarta Commons Developers List > Betreff: Re: AW: AW: AW: AW: [proposal] avoiding jar version nightmares > > Don't forget to do a little light reading first :-) > > Mechanism to declare dependencies in a MANIFEST.MF File: > > http://java.sun.com/j2se/1.4.2/docs/guide/extensions/versioning.html > > ClassLoader implementation for representing an "Assembly": > > http://java.sun.com/j2se/1.4.2/docs/api/java/net/URLClassLoader.html > > Craig > > > > On Tue, 21 Dec 2004 14:34:56 -0500, Matt Sgarlata > <[EMAIL PROTECTED]> wrote: > > Count me in! I'm planning on taking some time off for the holidays, so > > that should give me time to play around with this :) > > > > Matt > > > > Daniel Florey wrote: > > > <snip/> > > > > > >>>an application using 1.x.b will work with component 1.x.a > > >>>Does this sound reasonable? Missed something? > > >> > > >>Have you seen the guidelines in use by the Apache APR project? It > looks > > >>to me like you're basically advocating the same system they have in > > >>place. It might save us hassle to just adopt their version numbering > > >>system whole-sale (as the Spring Acegi Security subs(ystem does) > > >> > > >>http://apr.apache.org/versioning.html > > > > > > > > > Very funny - looks pretty identical to me ;-) So, yes, let's adopt > this. > > > I've not played around with classloading a lot, so I'm very curious if > this > > > will work. I'll try to start working on this if I'll find the time for > it. > > > If you are interested I could setup an account for you at my personal > root > > > server (I've installed Subversion). Or should I create a subproject in > the > > > commons-sandbox? > > > As it's in stage of brainstorming I'd prefer to do it in my personal > space > > > first. > > > Are you interested? > > > > > > Cheers, > > > Daniel > > > > > > > > >>>I'd prefer to keep the "jar" naming as introducing "assembly" would > > >> > > >>cause > > >> > > >>>some confusion. > > >>>If anyone would be interested I could put a simple proposal to the > > >> > > >>sandbox. > > >> > > >>Good point, JAR may be a better name. I see two benefits to using > > >>"assembly" or "assembler" as the name: > > >>- Clearly indicates that you aren't dealing with plain-old-JAR files > > >>anymore > > >>- Parallels name used in .NET so that the analogy is directly obvious > > >> > > >> > > >>>This approach will not address the trouble that may be caused by > > >>>applications not using this package. So finally I think that it is > > >> > > >>required > > >> > > >>>that this feature (or something comparable) will make it into Java > 1.6. > > >>>Up to then I still think it's a very simple but easy way to add the > > >> > > >>version > > >> > > >>>number to the package names to avoid at least the very big problems > > >>>concerning incompatible jars in the same classloader. > > >> > > >>I understand your reasoning behind putting this code in Java 1.6, but > I > > >>think we can do this without a new release of the Java language (see > > >>below). If our ideas are successful, this new Commons component could > > >>always migrate later to a JSR proposal, as Doug Lea's concurrent > package > > >>did. > > >> > > >>With regards to problems caused by components that aren't using this > new > > >>package, I'm thinking that as long as the component does not make any > > >>Class.forName calls, we should be OK. If there are Class.forName > calls, > > >>the component may still be able to work, but we would strongly > encourage > > >>a migration to using Assembly.getType or whatever. This entails the > > >>component introducing a dependency on Assembler, which means the > > >>Assembler API will need to maintain backwards compatability as much as > > >>possible (e.g. - imagine the nightmare that would ensue if > > >>java.util.Vector were to change its semantics!) > > >> > > >> > > >>>Regards, > > >>>Daniel > > >> > > >>Matt > > >> > > >> > > >>>>-----Ursprüngliche Nachricht----- > > >>>>Von: commons-dev-return-64857- > [EMAIL PROTECTED] > > >>>>[mailto:commons-dev-return-64857- > > >> > > >>[EMAIL PROTECTED] > > >> > > >>>>Im Auftrag von Matt Sgarlata > > >>>>Gesendet: Dienstag, 21. Dezember 2004 13:04 > > >>>>An: commons-dev@jakarta.apache.org > > >>>>Betreff: Re: AW: AW: [proposal] avoiding jar version nightmares > > >>>> > > >>>>Chris Lambrou wrote: > > >>>> > > >>>> > > >>>>>Matt Sgarlata wrote: > > >>>>> > > >>>>> > > >>>>> > > >>>>>>Does this mean .NET doesn't have reflection? That's such a killer > > >>>>>>feature of Java; I can't believe they wouldn't have ported it to > .NET. > > >>>>>>Any .NET developers out there that can tell us how .NET deals with > > >>>>>>reflection when you have multiple versions of the same class? > > >>>>> > > >>>>> > > >>>>>Since the class name alone is insufficient to fully identify a > specific > > >>>>>version of a class, to my knowledge there is no equivalent to > > >>>>>Class.forName(String classname) in .NET. Instead, .NET has the > Assembly > > >>>>>class. An Assembly is roughly akin to a java jar file, and is > typically > > >>>>>a single DLL that contains one or more classes. Assembly has a > > >>>>>non-static getType(String typeName) method, that performs the same > job > > >>>>>as the static Class.forName(String classname) method in java, but > for a > > >>>>>specific Assembly instance. There is never any ambiguity over which > > >>>>>version of the named Type that is returned, since an Assembly can > only > > >>>>>contain one version of any given class. Support for multiple > versions > > >> > > >>of > > >> > > >>>>>a class at runtime is achieved by storing those multiple class > versions > > >>>>>in separate Assemblies. > > >>>> > > >>>>Thanks for the info, Chris! This definitely sounds like a good > > >>>>approach. Now my question is, can we simulate this in a new commons > > >>>>component? :) > > >>>> > > >>>>Here are the steps I would imagine to be involved: > > >>>>1) Define our own JAR sub-type to mirror the .NET assembly notion. > > >>>>Include some type of a plain-text file that describes the versions > of > > >>>>the software required to perform certain tasks. It would be nice to > do > > >>>>this in an existing structure like MANIFEST.MF, but I don't know... > are > > >>>>you allowed to add arbitrary information to that file? In any case, > we > > >>>>wouldn't use the existing dependency descriptors because that would > > >>>>prevent multiple versions of the same class from being loaded. > > >>>>2) Call org.apache.commons.assembler.Assembler.getType(String > > >>>>assembledPackage, String className). The Assembler would then go to > the > > >>>>assemblyPackage path on the classpath and search the plain-text file > > >>> > > >>>>from step #1 which would list the versions of classes that are > required > > >>> > > >>>>by the given assembledPackage. For example, if assembledPackage was > the > > >>>>Digester, which required collections 3, the assembledPackage would > be > > >>>>org.apache.commons.digester. A dynamic proxy or generated bytecode > > >>>>would be loaded that fulfilled the given contract and that would be > > >>>>returned to the client. Any existing code that is just calling > > >>>>Class.forName would have classes looked up in the normal way, so we > > >>>>would need to make sure that this dynamic proxy doesn't get loaded > into > > >>>>the JVM in the same way as Class.forName (this is where the dynamic > > >>>>proxy and/or bytecode generation comes in) > > >>>> > > >>>>What do you guys think? Does this sound feasible? I'd rather spin > this > > >>>>as a commons component than a J2SE 1.6 enhancement request, because > the > > >>>>later will take years to come to fruition. > > >>>> > > >>>> > > >>>> > > >>>>>Chris > > >>>> > > >>>>Matt > > >>>> > > >>>> > > >>>>-------------------------------------------------------------------- > - > > >>>>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] > > > > --------------------------------------------------------------------- > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
