On Sun, Mar 9, 2008 at 1:10 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
> 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?
>
possibly. I've started out with the pseudolocalization and that one
needs all the resources to end up in the right place for the inclusion
in the jar. And it seemed that processing resources is somewhat
unreliable as the resources can be filtered, can be dumped in
different location than in the sources etc. So I took the actual
output as processed by the resources plugin and did my own tweaks
there.
The report doesn't have this constraint (as it's own output doesn't
end up in the jar and can be aligned with the original sources in
src/main/resources. The processing done by resources-plugin doesn't
matter here..
>
> >> 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?
and what's the problem there?
Milos
>
>
> > 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
>
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
