Thorsten Scherler wrote:
> Gavin wrote:
> ...
> >
> > Thanks, it also happens to be a (not necessarily the) fix for getting trunk
> > working again for Windows Devs. We need to look a bit higher up in the chain
> > as to what makes this work and if we can find a solution without having to
> > have this fallback permanently in all plugins, current and future.
>
> Actually it maybe our bug after all. Looking at my commit you pointed
> out it feels right to have a non relative match as fallback. I mean the
> relative match in the lm is for the rare case that one is requesting the
> plugin directly or one needs a custom implementation of the match.
> However relative path for plugins means: one cannot reuse the lm match
> from a project or plugin without implementing the match.
>
> ...and that does not feel right and more like a bug.
>
> > I don't know why, I just have the niggling feeling that because it works
> > without this fix for Linux/MAC then applying the above fix for Windows feels
> > to me like a hack.
>
> The above discussed is not a hack but a clear enhancement. Well e.g.
> {forrest:forrest.plugins}/org.apache.forrest.plugin.output.Text/ should
> be replaced by something shorter. Awesome would be {this} but not sure
> whether that is easily to implement.
Don't forget that this would need to be handled by the
Ant target that creates a new plugin from the template:
http://forrest.apache.org/docs/dev/howto/howto-buildPlugin.html#seed
-David
