On 21 Dec 2004, at 21:10, Craig McClanahan wrote:
On Tue, 21 Dec 2004 21:51:56 +0100, Daniel Florey
<[EMAIL PROTECTED]> wrote:
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
Hihi, good point, I actually never have. What phenomena are to be
expected? Just like you have compiled something with say 1.4 and let
it run on a 1.3 platform?
Anyway, I was thinking of this with respect to class loading issues...
Oliver
On Wed, 22 Dec 2004 13:37:44 +1300, Sharples, Colin
<[E
> I do not think you can compare JDK APIs to commons APIs as you hardly
> have more than one version of JDK API in your classpath ;)
You mean you've never written an RMI app where the client and server were
running different JVM levels? ;-)
Colin Sharples
IBM Advisory IT Specialist
Email: [EMAIL
On Wed, 22 Dec 2004 08:58:13 +1300, Sharples, Colin
<[EMAIL PROTECTED]> wrote:
> > And, in my experience watching work done with tools like
> > Gump, any time
> > people do weird trickery with package names, like Sun
> > renaming some packages
> > from x.y.z to com.sun.x.y.z, this inevitably seems
On Tue, 21 Dec 2004 21:51:56 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
> 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
> upcomin
[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 rea
e 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 (
> And, in my experience watching work done with tools like
> Gump, any time
> people do weird trickery with package names, like Sun
> renaming some packages
> from x.y.z to com.sun.x.y.z, this inevitably seems to cause
> lots of problems
> somewhere down the line.
Exactly. Remember the howls of
ECTED]
[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&
Craig McClanahan wrote:
Don't you get to this same result by creating your own URLClassLoader
for each "assembly", with its own set of JARs and/or directories
making up its "class path"?
Haha, yes you probably do get the same result! I for one just didn't
understand what this type of a solution w
d ensue if
> java.util.Vector were to change its semantics!)
>
> > Regards,
> > Daniel
>
> Matt
>
> >>-Ursprüngliche Nachricht-
> >>Von: [EMAIL PROTECTED]
> >>[mailto:commons-dev-return-64857-
> [EMAIL PROTECTED]
> >>Im Au
Don't you get to this same result by creating your own URLClassLoader
for each "assembly", with its own set of JARs and/or directories
making up its "class path"?
Craig
On Tue, 21 Dec 2004 07:03:50 -0500, Matt Sgarlata
<[EMAIL PROTECTED]> wrote:
> Chris Lambrou wrote:
> > Matt Sgarlata wrote:
> >
Daniel Florey wrote:
In order to find an appropriate solution to this issue, I'd like to identify
the different problems that we need to address.
Version: What does a version number mean?
I'll make a proposal for how to use minor/major version number to have a
basis on which we can identify the iss
December 19, 2004 5:28 PM
> To: Jakarta Commons Developers List; [EMAIL PROTECTED]
> Subject: Re: AW: AW: AW: [proposal] avoiding jar version nightmares
>
>
> On Sun, 19 Dec 2004 23:25:30 +0100, Oliver Zeigermann
> <[EMAIL PROTECTED]> wrote:
> > On Sun, 19 Dec 20
On Tue, 21 Dec 2004 09:11:55 -0500, Matt Sgarlata
<[EMAIL PROTECTED]> wrote:
> Daniel Florey wrote:
> > 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
--- Matt Sgarlata <[EMAIL PROTECTED]> wrote:
> David Graham wrote:
> > --- Daniel Florey <[EMAIL PROTECTED]> wrote:
> >
> >>BTW: Another advantage of this approach would be that imports would
> >>indicate
> >>which version of the component is in use. I had a lot of trouble to
> find
> >>out, whi
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'
very big problems
concerning incompatible jars in the same classloader.
Regards,
Daniel
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Im Auftrag von Matt Sgarlata
> Gesendet: Dienstag, 21. Dezember 2004 13:04
> An: commons-dev@jakarta.
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
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 th
.Net does have reflection. Some even say it's somewhat more elegant
than Java... I ain't goin' there :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Matt Sgarlata wrote:
Daniel Florey wrote:
I think handling different versions of classes/j
Daniel Florey wrote:
I think handling different versions of classes/jars at VM level would be a nice feature, but it would be very hard to implement nd to understand when it comes to reflection.
Does this mean .NET doesn't have reflection? That's such a killer
feature of Java; I can't believe the
David Graham wrote:
--- Daniel Florey <[EMAIL PROTECTED]> wrote:
BTW: Another advantage of this approach would be that imports would
indicate
which version of the component is in use. I had a lot of trouble to find
out, which version of jdom was in use by some libraries as this was not
indicated by
I think handling different versions of classes/jars at VM level would be a nice
feature, but it would be very hard to implement nd to understand when it comes
to reflection.
Another proposal would be to do it the j2se-way:
When introducing new features to a package (e.g. java.io) don't include th
--- Daniel Florey <[EMAIL PROTECTED]> wrote:
> BTW: Another advantage of this approach would be that imports would
> indicate
> which version of the component is in use. I had a lot of trouble to find
> out, which version of jdom was in use by some libraries as this was not
> indicated by the name
The ability to declare your own versioning information, and that of
your dependencies, in a MANIFEST.MF file already exists:
http://java.sun.com/j2se/1.4.2/docs/guide/extensions/versioning.html
Two existing use cases for this information are applets and servlet
containers, where the container s
Craig McClanahan wrote:
On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata
<[EMAIL PROTECTED]> wrote:
How do we go about petitioning Sun for something like this?
A while back now (while the details for Tiger were being planned), I
happened to be in a meeting with Graham Hamilton (who basically owns
From: "Daniel Florey" <[EMAIL PROTECTED]>
So the collections way to handle this issue if to move all classes to a
new
subpackage and leave the old ones where they've been before.
To be honest: Is this not very close to my proposal?
Certainly, there is some similarity. Were I to change the semantic
On Sun, 19 Dec 2004 23:17:55 -, Stephen Colebourne
<[EMAIL PROTECTED]> wrote:
> The incompatabilities that usually hurt the most are the unplanned ones,
> like with collections. Your proposal is to change package with each
> incompatible new release. Well, applying that 'rule' to collections, I
You might be irritated, but I think this is the cost to pay for working
around this obvious java lack of managing versioned libraries.
I think it's just a matter of getting used to this package naming
convention.
But it doesn't solve the problem.
The incompatabilities that usually hurt the most are
On Sun, 19 Dec 2004 23:51:06 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
>
> Simple example:
> If you have two libraries:
> Library A using component-1.x
> Library B using component-2.x
> Both libraries provide some servlets that need to live in the same webapp
> and get initialized at startup
ermann
> Gesendet: Sonntag, 19. Dezember 2004 23:51
> An: Stephen Colebourne
> Cc: Jakarta Commons Developers List
> Betreff: Re: AW: AW: AW: [proposal] avoiding jar version nightmares
>
> On Sun, 19 Dec 2004 22:46:26 -, Stephen Colebourne
> <[EMAIL PROTECTED]> wrote:
>
et: Sonntag, 19. Dezember 2004 23:46
> An: Jakarta Commons Developers List; [EMAIL PROTECTED]
> Betreff: Re: AW: AW: AW: [proposal] avoiding jar version nightmares
>
> > Major releases, i.e. e.g. from 1.x to 2.x are there not to be backward
> > compatible. Especially, I would even cons
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Im Auftrag von Craig McClanahan
> Gesendet: Sonntag, 19. Dezember 2004 23:34
> An: [EMAIL PROTECTED]
> Cc: Jakarta Commons Developers List
> Betreff: Re: AW: AW: AW: [propos
On Sun, 19 Dec 2004 22:46:26 -, Stephen Colebourne
<[EMAIL PROTECTED]> wrote:
> > Major releases, i.e. e.g. from 1.x to 2.x are there not to be backward
> > compatible. Especially, I would even consider it dangerous to replace
> > a 1.x version with 2.x without checks just to have a newer versi
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Im Auftrag von Craig McClanahan
> Gesendet: Sonntag, 19. Dezember 2004 23:28
> An: Jakarta Commons Developers List; [EMAIL PROTECTED]
> Betreff: Re: AW: AW: AW: [proposal] avoiding j
Major releases, i.e. e.g. from 1.x to 2.x are there not to be backward
compatible. Especially, I would even consider it dangerous to replace
a 1.x version with 2.x without checks just to have a newer version.
Semantics could have chages. Consider collections from 2. to 3. What
was done there was pe
On Sun, 19 Dec 2004 23:24:52 +0100, Oliver Zeigermann
<[EMAIL PROTECTED]> wrote:
>
> Major releases, i.e. e.g. from 1.x to 2.x are there not to be backward
> compatible. Especially, I would even consider it dangerous to replace
> a 1.x version with 2.x without checks just to have a newer version.
On Sun, 19 Dec 2004 23:25:30 +0100, Oliver Zeigermann
<[EMAIL PROTECTED]> wrote:
> On Sun, 19 Dec 2004 22:17:10 -, Stephen Colebourne
> <[EMAIL PROTECTED]> wrote:
> > I would also -1. Versioned packages is not an acceptable solution.
>
> What is an acceptable solution then?
Do what I said alr
On Sun, 19 Dec 2004 22:17:10 -, Stephen Colebourne
<[EMAIL PROTECTED]> wrote:
> I would also -1. Versioned packages is not an acceptable solution.
What is an acceptable solution then?
Oliver
-
To unsubscribe, e-mail: [EMAIL
On Sun, 19 Dec 2004 14:06:40 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On Sun, 19 Dec 2004 22:52:48 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
> > The solution you proposed will not solve the issue as you cannot replace the
> > classloader of the application server.
>
> That's not
Finally I think that my proposal is not that bad. If it's not possible to
address this issue in future versions of the java language, this seems to
be
the only solution.
So my vote is +1 to add at least the major version number to the
components
package name.
That would have unacceptable impacts
On Sun, 19 Dec 2004 22:52:48 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
> The solution you proposed will not solve the issue as you cannot replace the
> classloader of the application server.
That's not what I proposed. If you're inside a webapp, what I
proposed is that you create your own c
Commons Developers List
> Betreff: Re: AW: AW: [proposal] avoiding jar version nightmares
>
> On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata
> <[EMAIL PROTECTED]> wrote:
> > This may work, but does BCEL require the use of its own custom
> > classloader also?
> &g
On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata
<[EMAIL PROTECTED]> wrote:
> This may work, but does BCEL require the use of its own custom
> classloader also?
>
> This seems to me that this isn't just a problem with commons; it is a
> problem with Java itself that .NET already has a very nice s
On Fri, 17 Dec 2004 22:16:49 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
> This would be really a funny thing, but how could we replace the classloader
> of a given application with a custom one?
> But what about a tool that decompiles all the product jars, changes the
> package structure and
Emmanuel Bourg wrote:
Matt Sgarlata wrote:
This seems to me that this isn't just a problem with commons; it is a
problem with Java itself that .NET already has a very nice solution
for. I'm wondering if this isn't something that should be taken care
of at the JVM level i.e. - in Java 1.6. The
Matt Sgarlata wrote:
This seems to me that this isn't just a problem with commons; it is a
problem with Java itself that .NET already has a very nice solution for.
I'm wondering if this isn't something that should be taken care of at
the JVM level i.e. - in Java 1.6. The obvious solution seems
On Sat, 18 Dec 2004 00:15:28 +0100, Oliver Zeigermann
<[EMAIL PROTECTED]> wrote:
> On Fri, 17 Dec 2004 22:16:49 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
> > This would be really a funny thing, but how could we replace the classloader
> > of a given application with a custom one?
>
> Right.
This may work, but does BCEL require the use of its own custom
classloader also?
This seems to me that this isn't just a problem with commons; it is a
problem with Java itself that .NET already has a very nice solution for.
I'm wondering if this isn't something that should be taken care of at
Sounds pretty good. However, I guess the problem is you can not change
the class loader implementation of WebSphere or other commercial stuff
:(
Oliver
On Fri, 17 Dec 2004 23:16:42 +, Chris Lambrou <[EMAIL PROTECTED]> wrote:
>
> > Correct me if I'm wrong, but didn't Microsoft come up with s
Correct me if I'm wrong, but didn't Microsoft come up with some type
of solution to DLL hell in Windows 2000 or XP? I seem to recall
reading that a long time ago, but I'm not a Windows programmer, so I
have no idea. Does anyone else know?
The .NET equivalent of a jar file is called an assemb
On Fri, 17 Dec 2004 22:16:49 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
> This would be really a funny thing, but how could we replace the classloader
> of a given application with a custom one?
Right. Impossible :(
> But what about a tool that decompiles all the product jars, changes the
>
PROTECTED]
> > Im Auftrag von David Graham
> > Gesendet: Freitag, 17. Dezember 2004 21:33
> > An: Jakarta Commons Developers List
> > Betreff: Re: AW: [proposal] avoiding jar version nightmares
> >
> > What happens if you merge the jars for each product? For examp
...
Daniel
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Im Auftrag von Oliver Zeigermann
> Gesendet: Donnerstag, 16. Dezember 2004 22:44
> An: Jakarta Commons Developers List
> Betreff: Re: AW: [proposal] avoiding jar version nightmare
[mailto:[EMAIL PROTECTED]
> Im Auftrag von David Graham
> Gesendet: Freitag, 17. Dezember 2004 21:33
> An: Jakarta Commons Developers List
> Betreff: Re: AW: [proposal] avoiding jar version nightmares
>
> What happens if you merge the jars for each product? For example, put
>
> > -Ursprüngliche Nachricht-
> > Von: [EMAIL PROTECTED]
> >
>
[mailto:[EMAIL PROTECTED]
> > Im Auftrag von David Graham
> > Gesendet: Freitag, 17. Dezember 2004 02:26
> > An: Jakarta Commons Developers List
> > Betreff: Re: [proposal] avoiding jar v
Daniel Florey wrote:
> Any proposals how to solve this issue in another way?
Correct me if I'm wrong, but didn't Microsoft come up with some type of
solution to DLL hell in Windows 2000 or XP? I seem to recall reading
that a long time ago, but I'm not a Windows programmer, so I have no
idea. D
aniel
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Im Auftrag von David Graham
> Gesendet: Freitag, 17. Dezember 2004 02:26
> An: Jakarta Commons Developers List
> Betreff: Re: [proposal] avoiding jar version nightmares
>
> Struts uses t
On Fri, 17 Dec 2004 00:43:55 -, Stephen Colebourne
<[EMAIL PROTECTED]> wrote:
> Basically, I believe there is no simple solution to this. The best we can do
> is to encourage tools like clirr which check a library for binary
> compatability. This should become part of each components standard t
Struts uses the deprecation cycle I described and so did the commons
components spawned from Struts the last I knew (validator certainly still
uses the described cycle). A 1.x series is backwards compatible but
deprecated methods may be removed after they have been deprecated for at
least one poi
Commons has always followed a longer deprecation cycle than described below.
A method deprecated in 1.1, 1.2, 1.3 cannot be removed until 2.0.
1.1 -> 1.2 -> 1.3 should all be easy compatible changes.
1.1/1.2 -> 2.0 may cause issues.
In collections we faced a peculiar compatability problem in that
Packages look like
com.some_domain.org.apache.xerces...
gg
-Original Message-
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 16, 2004 1:44 PM
To: Jakarta Commons Developers List
Subject: Re: AW: [proposal] avoiding jar version nightmares
On Thu, 16 Dec 2004
On Thu, 16 Dec 2004 19:09:54 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
> So I think we need a solution for this problem. My proposal would be to
> allow different major versions of commons components to coexist. If the
> class and package names are equal, this is not possible. My package-vers
On Thu, 16 Dec 2004 14:20:41 -0500, Gary Gregory
<[EMAIL PROTECTED]> wrote:
> Having a different jar name does not solve anything it is just
> informative.
Agreed!
> I suppose this is why we see more and more large apps shipping with
> repackaged versions of components like Xerces and Xalan.
Ho
nts like Xerces and Xalan.
Gary
-Original Message-
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 16, 2004 9:27 AM
To: Jakarta Commons Developers List
Subject: Re: [proposal] avoiding jar version nightmares
On Thu, 16 Dec 2004 09:09:11 -0800 (PST), David
> [mailto:[EMAIL PROTECTED]
> Im Auftrag von David Graham
> Gesendet: Donnerstag, 16. Dezember 2004 18:41
> An: Jakarta Commons Developers List; [EMAIL PROTECTED]
> Betreff: Re: [proposal] avoiding jar version nightmares
>
> I'm still wondering what commons components caused
I'm still wondering what commons components caused you guys problems in
your project? Why should all projects change to renaming packages and
causing confusion if it's just a few projects that are causing problems?
My guess is that it's commons collections that is giving you headaches but
I would
On Thu, 16 Dec 2004 09:09:11 -0800 (PST), David Graham
<[EMAIL PROTECTED]> wrote:
> The only time I've seen versioning problems is when commons components
> depend on each other and one of them breaks backwards compatibility like
> commons collections did recectly. This is why it's so important fo
All the jakarta projects I've worked on have a deprecation cycle of one
minor point release. For example, you deprecate a method for the 1.1
release and can remove it for the 1.2 release. This gives users time to
see the deprecation warning and update their code appropriately. IMO,
requiring a p
Hi all,
As commons components gain more and more attention you'll find a lot
components in larger java based projects. This can cause much trouble when
subprojects use different incompatible versions of the same component.
I was faced with this problem in the project I'm currently working on and
th
71 matches
Mail list logo