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.
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.
Report added. Now I'm waiting for translations ;-)
German translation is up.
I don't dare chop that up.
That's how the maintenance nightmare starts... :(
A final note: The plugin's report cannot be run by direct invocation from
the command line for the same reason MCHANGES-88 hit.
Benjamin
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
