On 22/01/2008, Jörg Schaible <[EMAIL PROTECTED]> wrote: > Mark Proctor wrote: > > Torsten Curdt wrote: > >> > >> On 21.01.2008, at 10:08, Tom Schindl wrote: > >> > >>> Hi Torsten, > >>> > >>> I understand this but we are seeing many J2EE-Servers adopting OSGi > >>> and many applications (I admit most of them in Eclipse-world) also. > >>> It seems strange to me in those envs to use this "artificial" > >>> package to overcome jar-hell (which is the only reason for the > >>> java5-package right?) they are not having > >>> because of OSGi. > >> > >> Hm.... not sure why its such a big deal to have e.g. > >> o.a.commons.lang2 or similar. If you use an IDE that manages imports > >> you will barely notice anyway. > > personally I've always wondered why having a version attached to the > > namespace hasn't taken off more to deal with api breaking > > releases. if > > we had org.antlr1 org.antlr2 org.antlr3 life would be much > > easier. Sure > > you wouldn't get auto drop in jar and release, but I'm > > guessing tooling > > could make up for that in those cases. > > Ironically Java could already support this, there's a reason why a manifest > should specify a Specification-Version. It would have been so simple to use > this information also to separate classes in a class loader. But the Gods of > Java refused to make anything out of it ;-) >
Surely that would not work for java classes without a manifest - e.g. classes which are loaded as individual class files rather than from jars. Not all Java processes use jars. > - Jörg > > --------------------------------------------------------------------- > 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]
