Hi, as long as [4] is not available (I agree that this is the best option), I vote for: 5.) put the Antlr jar into the two modules and don't care about classloader.
Currently, both modules use exaclty the same Antlr version, there will be no problem to not exactly know which Antlr classes of which module is used when both are in use. Also, there's no collision with the old Antlr 2 inside the core. Thomas -------- Original-Nachricht -------- > Datum: Mon, 16 Jun 2008 03:08:59 +0100 > Von: Luis Sergio Oliveira <[EMAIL PROTECTED]> > An: [email protected] > Betreff: Re: [argouml-dev] antlr v3 > Hi, > > alexander krohn wrote: > > (...) > > so we have 3 different ways: > > 1.) adding jars to core-lib where they don't belong > > 2.) create a common-lib directory for modules maybe seperated in > > "necessary for build/necessary at runtime" > > 3.) create a delegating classloader > > > 4.) [the eclipse way] ANTLR 3.0x should be wrapped in its own > argouml-antlr module that modules that depend on it would require. We're > not an eclipse RCP application yet, but, that's the way they do it there > and I think that it is the cleanest way. > > So, I vote for 4) for ArgoUML 0.28. For ArgoUML 0.26 we should fix the > module in the fastest way possible. That if we meant to distribute it. > > Regards, > > Luis > > my vote for 1.) because of my infinite lazyness ;) > > > > regards, > > > > alexander > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
