> What's the status of changing modulejar/loading system? I can handle it
> if you're busy but not before Monday. The other day we had an online
> conference regarding the problems we have with the class loading system.
> We found a neat way to tackle it. Basically we won't have any
> <modulejar/> or finding xdoclet.jar and stuff like those. Instead we
> rely on the classpath/classpathref of <xdoclet/> and the fact that all
> tasks/modules are in taskdefs classpath, so we're all in one classloader
> and there's nothing more to do in loading modules.
>
I forgot to mention that it's taken care of too. ModuleFinder is rewritten,
and it now looks at the classpath. It gets the classpath from a system
property (xdoclet.class.path) which is set by DocletTask. This classpath is
the same as the one passed into the taskdef. (It doesn't work with
System.getProperty("java.class.path"), because that returns the system
classpath).
-So there is no obscure <modulejar/> or finding xdoclet.jar when looking for
modules. It's a lot better this way. Kudos to Ara for always coming up with
the simplest solution.
> Regarding the message bundle stuff, I've created the first draft of it.
> I introduced a new tag: @i18n:msg id="uniqid" msg="message goes here".
> And of course a new template which generates Messages.proerties file for
> each package. The tricky part is implementing some logic to not generate
> empty files for packages that do not have any @i18n tag, and updating
> all of the sources to use it :-) Now that build process is ok we can
I can't see the i18n dimension in your i18n stuff. I guess we need an
optional locale attribute too:
@i18n:msg id="hello_world" msg="Hello World"
@i18n:msg id="hello_world" msg="Hei Verden" locale="no"
I can also see a potential problem. Say in my package I have several classes
that use the message
with the key "hello_world". There is a risk of duplication of messages. What
if I want to use a message
defined in a class in a different package? Can I?
> start applying it. Probably we should use v1.1.2 of xdoclet.jar for
> generating it (xdoclet is not yet built when this is getting
> generated!). Usual chicken and egg dilemma! I'm busy till next Monday so
> don't count on me. Anyone volunteering to handle it?
>
> Btw, I'm happy that you removed the obscure fork=true code from xjavadoc
> :-)
>
Yeah, so am I. I think it was a baaaad desicion to extend from Ant's Java
task.
> Ara.
>
Aslak
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
