> 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).Wow! You're so fast :-) I searched for it at commit messages but couldn't find it under the avalanche ;-) > > 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" Not like that. The truth is that you almost always write docs/messages for one main language (English) and then provide translations of it later when there's demand for it. So @i18n:msg only cares about one language. You can use IBM Alphaworks' ResourceBundleManager to do the 'translations' later. And btw, although I know this @i18n:msg stuff is quite generic but at least for xdoclet we don't care much about translations but we want to keep messages close to the code but not lost in the code and @i18n does that. > 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? Very good question! The answer is: - try to give unique ids to msgs (prefixed by package name) - provide a chain-of-responsibility-like api for it. A bad thing about xdoclet's current Translator class is that if you want to use a msg from another package you specifically use the Message.properties of the other package. I believe we should change it to use a chain of responsibility: I want msg x, first try to find it in current package, if not found then the parent package and so on. In fact it should be possible to also provide alternative chain paths. So you setup Translator for package xdoclet.ejb to look at xdoclet/ejb/resources/Messages.proeprties and then at xdoclet/core/resources/Messages.proeprties. Ara. _______________________________________________________________ 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
