Wouldn't pretty much everything in org.argouml.uml.reveng be a candidate for a generic reverse engineering module?
Bob. 2008/6/16 alexander krohn <[EMAIL PROTECTED]>: > hi bob. > > Bob Tarling schrieb: >> >> Is there any usefulness in a generic reverse engineering module where >> any jars needed for all all specific reverse engineering modules are >> needed? >> >> I wouldn't suggest that just for jars but if there is also any common >> functionality for all reverse engineering modules then it may be a >> reasonable solution to add the jars at that level. >> > > i thought about this for a long time and actually i'm comparing the stuff > i'm doing for python with other languages like c++ and java in my thesis. > > although these languages provide similar concepts like namespaces, classes, > methods, etc, in practice the unveil many differences, starting from what a > compilation unit is, packages/modules in relation with directories in the > filesystem, etc. > > i'll have to finish my thesis in about 4 weeks, until then the python-module > should have a good base for exploring the possibilites to apply it's > concepts to other languages. > > since this stuff hardly depends on the grammar/parser which is used, the > only way for generic stuff would be a layer between the parser and > uml-model-elements, but the differences between the languages might demand > too much flexibilty from it. > > regards, > > alexander > >> Bob. >> >> >> 2008/6/15 alexander krohn <[EMAIL PROTECTED]>: >> >>> >>> hi. >>> >>> Tom Morris schrieb: >>> >>>> >>>> On Sun, Jun 15, 2008 at 5:39 PM, alexander krohn <[EMAIL PROTECTED]> >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> i don't think that a vm that runs argo would load different versions of >>>>> the >>>>> jars, since the modules won't run in different vm's with different >>>>> classpaths. i think there's only one org.antlr.* namespace in the >>>>> running >>>>> vm, from the first or the last loaded jar that contains it, but that's >>>>> pure >>>>> speculation. >>>>> >>>>> >>>> >>>> This can definitely be made to work because all the Java containers >>>> (JBoss, etc) do it. It's possible it will take more classloader >>>> wizardry than we currently use. What we'd need to do, if we're not >>>> already is create a new delegating classloader for the module which >>>> delegates back to the main ArgoUML classloader for anything that it >>>> can't find. This will isolate anything that the module loads to just >>>> that module. >>>> >>>> Enforcing (or trying to enforce) lock step synchronization of version >>>> dependencies among all plugin modules just isn't practical. We need >>>> all the modules to be independent of each other. >>>> >>>> Tom >>>> >>>> >>>> >>> >>> 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 >>> >>> my vote for 1.) because of my infinite lazyness ;) >>> >>> regards, >>> >>> alexander >>> >>> --------------------------------------------------------------------- >>> 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]
