Hi Tom,
> but there are no such guarantees for
> forward compatibility (new module with old ArgoUML). The first thing
> that you need to do is use the same version of ArgoUML for development
> and deployment.
This fact make me feel better as I know that the problem is not in the code I
have developed. I have used older binary version of ArgoUML as it was the newer
stable binary release that is available for download, so I just wanted to try
how it will work when somebody else add my module to the his own ArgoUML. Now,
I know that it is not compatible with older version.
> The argouml.log file which is written by the log4j logger should also
> contain some errors/warnings about what is failing (probably a class
> not found exception for a newly introduced class or something
> similar). It shouldn't fail to start altogether without telling the
> user something, but I think this is a problem that got fixed
> post-0.24.
I have looked that but there are nothing unusual. I have tried to use
full.lcf configuration for logger, but it looks like everything is ok. I
suppose that it is compatibility issue.
Thank you for your help
Zoran
Tom Morris <[EMAIL PROTECTED]> wrote:
On Mon, Apr 14, 2008 at 3:14 AM, Zoran Jeremic wrote:
> That's the thing that confuse me. I'm using Eclipse for development and I
> have source code from SVN (ArgoUML 0.25.5). When I start ArgoUML from
> Eclipse together with my module it works fine.
[...]
> However, when I create module jar file and put it at ArgoUML/ext (binary
> distribution of ArgoUML v 0.24), it stops responding at splash screen.
We try (although don't always succeed) to maintain backward
compatibility with old modules, but there are no such guarantees for
forward compatibility (new module with old ArgoUML). The first thing
that you need to do is use the same version of ArgoUML for development
and deployment.
The argouml.log file which is written by the log4j logger should also
contain some errors/warnings about what is failing (probably a class
not found exception for a newly introduced class or something
similar). It shouldn't fail to start altogether without telling the
user something, but I think this is a problem that got fixed
post-0.24.
This should be enough to get you going, but if for some reason you
need to do additional debugging in the deployed environment, you can
also increase the logging level to get more debugging messages. See
you the examples in org.argouml.resource and the log4j documentation
for information on how to override the defaults at runtime.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
