Marcos Aurélio wrote:
On 10/15/07, *Luis Sergio Oliveira* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hello,
* org.argouml.uml.profile package isn't good to be exported, since it
doesn't qualify as a sub-system, because
it contains both the interfaces and the implementation and,
probably
it is better to move the relevant interfaces
and classes to org.argouml.uml, being considered part of the
existing
"UML sub-system API" (?)
a subsystem can't have "subpackages"?
yes, it can, but, my understanding of the sub-system definition in
http://argouml-stats.tigris.org/documentation/defaulthtml/cookbook/ch04.html#subsystems_definition
is that the main package is where the sub-system API resides.
Furthermore, after considering that org.argouml.uml is too much crowded
I decided that
org.argouml.profile is a much better place for the profiles sub-system
to be placed in,
therefore not breaking the good thing it had - it is a nicely congruent
set of classes.
* some parts of it depend on the usage of singletons, like
ProfileManagerImpl.getInstance (), and although convenient
at first glance these are a dependency trap, mainly if part of
an API
how could this be solved? making it an "static class"? as some other
classes at the uml package (like: DocumentationManager,
StereotypeUtility...) ??
Please see the code I committed in org.argouml.profile and the
corresponding unit tests.
But, yes, using a ProfileFacade class similar to the Model which has
static methods and is initialized
by a InitProfileSubsystem, but, explicitly initialized.
* I don't like the duplication of model loading code, therefore, if
nothing else works, we might change the visibility of
StreamModelLoader.loadModel(InputStream is), making it possible for
modules to reuse it by handing-over
the InputStream
i think we should re -design the profile loading api... i makes the
assumption that every one would try to load the model from some "path"...
on the other side we should investigate why doesn't it work....
I already spent some time at it and may commit a failing test in the C++
module where it is visible.
I suspected that it was caused by the ResourceModelLoader receiving a
Class instead of the ClassLoader, but, it
wasn't... I remember in a previous project in Eclipse RCP - which uses
different classloaders for different plug-ins -
I had to use URLs instead of Strings to represent resource paths living
in different jars. But, that isn't working either.
Regards and thanks for the feedback,
Luis
do you have a more detailed description of the problem?
maas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
