Benjamin Bentmann wrote:
The status report has a user-accessible parameter taking model.Resource
which is a further source of relative paths and needs manual
resolving (like
in MRESOURCES-32).
I'm not sure that this really needs to be accessible to the user. If
it doesn't need to, we can make it read-only.
Although the Maven Resources Plugin allows to customize its
corresponding parameter via its plugin config, too, I agree its best to
make this list read-only. The POM already provides a central means to
specify resources and given the plugin's support to specify
includes/excludes, I see no need for the resources parameter.
Done
Besides, hiding this parameter from the user would allow us to
transparently switch l10n:report to use "target/classes" like
l10n:pseudo does already.
That would solve the problem, right?
Yes. The background: The resources a plugin retrieves via
${project.build.resources} are properly resolved thanks to the
DefaultPathTranslator.alignToBaseDirectory(), i.e.
Resource.getDirectory() will always deliver absolute paths here.
However, path translation does not kick in if a user manually specifies
Resource in the plugin config because the directory field is for some
unlucky reason only a String and not a File such that it doesn't get
aligned automatically.
It seems odd that the l10n:pseudo operates on "target/classes" (hence
taking
generated/filtered resources into account) while l10n:report by
default only
operates on the static resources in "src/main/resources" etc.
Not sure why it is like that.
Switching to "target/classes" is also a good preparation if (someday)
the plugin wanted to analyze all derivates of ResourceBundle, i.e.
include class-based bundles like subclasses of ListResourceBundle, too.
Would that mean throwing out the resources parameter and replacing it
with an inputDirectory parameter, similar to the pseudo mojo?
Milos, what do you think about that?
Report added. Now I'm waiting for translations ;-)
German translation is up.
Thanks!
I don't dare chop that up.
That's how the maintenance nightmare starts... :(
Right, perhaps Milos can have a look at it?
A final note: The plugin's report cannot be run by direct invocation
from the command line for the same reason MCHANGES-88 hit.
I fixed this by downgrading to doxia 1.0-alpha-7.
Benjamin
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
