On Mon, 2008-09-01 at 13:40 +0300, Sjur Moshagen wrote: > Ross Gardler wrote: > > Thorsten Scherler wrote: > >>... > >>> Either we accept this fact, but leave the functionality as a > >>> (required) plugin, or we move the functionality of the > >>> o.a.f.p.output.inputModule into the Forrest core. Then we would > >>> have no dependency anymore, since core is allways there. > >> The problem I have to drop this functionality as plugin and move it > >> directly into the core is that cannot build it anymore by itself and > >> use the resulting jar. However I agree that this plugin represents > >> core > >> functionality (that is why I called it infrastructure code). > > > > I don't get it? Why is this a problem? Forrest needs the code to go > > into core. If it builds as a plugin it will build as part of the core.
Yeah! Best solution would be to define it as core plugin and build it when forrest get build. > > > > If you mean that you, as an individual, need to use the code > > independently of Forrest then I don't think that is a problem for us > > as a community. No that is not the problem. > > > > On the other hand, if you are saying that this code is useful to > > many other projects as a standalone peice of code then it should be > > a project (or more likely a Cocoon block) in its own right. Forrest > > can then include the block (or jar) from there. Actually many of our plugins can be used in cocoon directly. Having the code in a plugin allows everyone to go the "ant local-deploy" route and use the jar. > > > > I'm +1 for the code going into core if it resolves the plugin > > dependencies in dispatcher and the new PDF work quickly and easily. > > > > One day we will need a plugin dependency mechanism (as we always > > say), but I don't think this is it. > > Thorsten has not commented upon this, which means that his problems > with the plugin code going into core is still unclarified. > > I agree with Ross that the easiest solution would be to just move the > code to core. Yeah, it is just one generator. It is fine with me to move this class directly to the core, best solution IMO is to leave it in the plugin structure but build it by default with the core. Meaning we can drop the dependency in the required plugin section. However ATM I cannot look into the needed changes for that. I am fine with either move the class directly to the core or generate the jar once and add it to the lib dir. In both cases we need the one match that the plugin offers in the main sitemap. salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
