hi bob.
Bob Tarling schrieb:
Wouldn't pretty much everything in org.argouml.uml.reveng be a
candidate for a generic reverse engineering module?
don't know :\
from the importer's point of view it has to be able to manipulate the
model, create diagrams, etc, just as it is now.
from the app-side it has to provide gui-elements(awt and/or swt?),
including menu-entries. don't know how "pluggable" this stuff is.
also a language-module has more parts than reveng, there's code
generation for completing rte, there is a notation and probably
language-dependend profiles.
regards,
alexander
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
