You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ron Blaschke <ma...@rblasch.org> on 2005/01/21 21:23:48 UTC
[plugins] pod-input auto install
> Saturday, December 11, 2004, 4:21:00 PM, Ross Gardler wrote:
>> Do you intend to make this plugin available via the auto-install
>> features of Forrest? We just need to add the information to our
>> published plugins.xml and have the plugin zip avialable from a download
>> site.
>
> I'd first like to continue working on the plugin. There's still an
> awful lot of things missing. Actually, all that is working are
> headings and plain text paragraphs.
>
> Once most of the basic things are working, I'd like to start
> distributing it, in whatever form you consider best.
Since most of the important things of pod-input are working, I'd like
to ask to have it added to the plugins list. The plugin is available
from
http://www.rblasch.org/projects/pod-input/org.rblasch.forrest.plugin.pod-input.zip
Any feedback is highly appreciated, especially if you consider
anything missing.
Thanks,
Ron
Re: [plugins] pod-input auto install
Posted by Ron Blaschke <ma...@rblasch.org>.
Saturday, January 22, 2005, 6:31:00 PM, Ross Gardler wrote:
>> Since most of the important things of pod-input are working, I'd like
>> to ask to have it added to the plugins list. The plugin is available
>> from
>> http://www.rblasch.org/projects/pod-input/org.rblasch.forrest.plugin.pod-input.zip
>>
>> Any feedback is highly appreciated, especially if you consider
>> anything missing.
> I've still not had the time to look at this (don't have any pod input
> files anyway), however, if you provide a patch for
> FORREST_HOME/plugins/plugins.xml on the issue tracker and assign it to
> me I'll apply it for you.
Thanks a lot, Ross. I have added the patch to issue
http://issues.cocoondev.org/browse/FOR-426
but I don't have permissions to assign it to you.
Ron
Re: [plugins] pod-input auto install
Posted by Ross Gardler <rg...@apache.org>.
Ron Blaschke wrote:
>>Saturday, December 11, 2004, 4:21:00 PM, Ross Gardler wrote:
>>
>>>Do you intend to make this plugin available via the auto-install
>>>features of Forrest? We just need to add the information to our
>>>published plugins.xml and have the plugin zip avialable from a download
>>>site.
>>
>>I'd first like to continue working on the plugin. There's still an
>>awful lot of things missing. Actually, all that is working are
>>headings and plain text paragraphs.
>>
>>Once most of the basic things are working, I'd like to start
>>distributing it, in whatever form you consider best.
>
>
> Since most of the important things of pod-input are working, I'd like
> to ask to have it added to the plugins list. The plugin is available
> from
> http://www.rblasch.org/projects/pod-input/org.rblasch.forrest.plugin.pod-input.zip
>
> Any feedback is highly appreciated, especially if you consider
> anything missing.
I've still not had the time to look at this (don't have any pod input
files anyway), however, if you provide a patch for
FORREST_HOME/plugins/plugins.xml on the issue tracker and assign it to
me I'll apply it for you.
Ross
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.0 - Release Date: 17/01/2005
Re: entity resolution with POD input
Posted by Ron Blaschke <ma...@rblasch.org>.
David Crossley wrote:
> Ron Blaschke wrote:
>> David Crossley wrote:
>> > Ron Blaschke wrote:
>> Sorry, guess I am too deep into the code, not spelling things out.
>> Pod supports entities as E<entity>, akin to &entity; in XML. But
>> instead of just passing them on (E<uuml> -> ü), I thought it
>> would be good to resolve them locally.
> This sounds like a lot of extra work to me. Cocoon's machinery
> handles the entities later in the process. So why try to circumvent
> that. Wouldn't it better just to do the E<uuml> -> ü in your
> input generation?
I kept the parser as generic as possible, to keep it useful for
others. Say, if someone wants to create a Pod-to-text formatter, or
display a Pod in a Java GUI. I guess I treat entities here just as
Java would Unicode escapes ("\u0000") in a source file.
OTOH, I might create a pass-through for entities (which can be turned
on with a switch in the parser), which would avoid the dependency on
the DTD parser, yielding a smaller distribution, require less
memory and CPU cycles during translation.
Ron
entity resolution with POD input
Posted by David Crossley <cr...@apache.org>.
Ron Blaschke wrote:
> David Crossley wrote:
> > Ron Blaschke wrote:
> >> If not, can anybody recommend a DTD parser that is available under the
> >> Apache License? jpod uses it to resolve E<entity> formatting codes,
> >> which are akin to &entity; in XML.
>
> > Forrest has its internal Catalog Entity Resolver to handle that.
>
> > Anyway, i am not sure what you mean by "DTD parser".
> > Forrest includes NekoDTD if that task is what you mean.
>
> Sorry, guess I am too deep into the code, not spelling things out.
> Pod supports entities as E<entity>, akin to &entity; in XML. But
> instead of just passing them on (E<uuml> -> ü), I thought it
> would be good to resolve them locally.
>
> So, what I am actually needing
> is a library that would return "?" when I'd ask for "uuml".
>
> Since the entities are already available as DTDs (ISOlat1.pen, ...) I
> reckoned I might as well just use them. Therefore, I parse the DTDs,
> grab the entity and ask for its "literal value".
>
> In other words:
> final DTDParser parser = new DTDParser();
> parser.parse(...);
> final Entity entity = parser.getDocType().getEntity(entityName);
> if (entity != null) {
> return entity.getLiteralValue();
> }
>
> Ron
This sounds like a lot of extra work to me. Cocoon's machinery
handles the entities later in the process. So why try to circumvent
that. Wouldn't it better just to do the E<uuml> -> ü in your
input generation?
--David
Re: License & Copyright concerns Re: [plugins] pod-input auto install
Posted by Ron Blaschke <ma...@rblasch.org>.
David Crossley wrote:
> Ron Blaschke wrote:
>> Rick Tessner wrote:
[snip]
>> If not, can anybody recommend a DTD parser that is available under the
>> Apache License? jpod uses it to resolve E<entity> formatting codes,
>> which are akin to &entity; in XML.
> Forrest has its internal Catalog Entity Resolver to handle that.
> Anyway, i am not sure what you mean by "DTD parser".
> Forrest includes NekoDTD if that task is what you mean.
Sorry, guess I am too deep into the code, not spelling things out.
Pod supports entities as E<entity>, akin to &entity; in XML. But
instead of just passing them on (E<uuml> -> ü), I thought it
would be good to resolve them locally. So, what I am actually needing
is a library that would return "ΓΌ" when I'd ask for "uuml".
Since the entities are already available as DTDs (ISOlat1.pen, ...) I
reckoned I might as well just use them. Therefore, I parse the DTDs,
grab the entity and ask for its "literal value".
In other words:
final DTDParser parser = new DTDParser();
parser.parse(...);
final Entity entity = parser.getDocType().getEntity(entityName);
if (entity != null) {
return entity.getLiteralValue();
}
Ron
Re: License & Copyright concerns Re: [plugins] pod-input auto install
Posted by David Crossley <cr...@apache.org>.
Ron Blaschke wrote:
> Rick Tessner wrote:
[snip]
> > I've been going through the zip you provided and I have a few concerns
> > however.
>
> > Java Class and Plugin Naming
> > Copyright Notices
>
> Should be ok, as it's not part of the Forrest distribution.
Correct.
In another thread i would like to explore why one would want
to have a separate distribution.
> > Included JAR files and License
> > -------------------------------
> > There are two jars included in this zip file as well, but I didn't see
> > any corresponding license files.
> > jpod.jar
> > matra.jar
> > For the above, there should be license files named
> > jpod.jar.license.txt
> > matra.jar.license.txt
> > The licenses would obviously need to be compatible with Apache License
> > 2.0.
>
> Thanks for pointing this out. I'll add the license files.
>
> jpod is the beast that does the real work. pod-input just contains
> the Cocoon Generator adapter. I am the author, and will distribute it
> under the Apache License as well. It is, or better will be, available
> separately, just in case someone wants to write another formatter
> (HTML, etc).
You can contribute generators to Forrest or Cocoon if you would rather.
> matra, on the other hand, is available from
> http://matra.sourceforge.net/ and ist distributed under the Mozilla
> Public License 1.1 or GPL.
> Is the MPL 1.1 compatible with the Apache License 2.0?
Perhaps. Other MPL are. If we have a specific case where
code is coming into our repository then we will make sure.
> If not, can anybody recommend a DTD parser that is available under the
> Apache License? jpod uses it to resolve E<entity> formatting codes,
> which are akin to &entity; in XML.
Forrest has its internal Catalog Entity Resolver to handle that.
Anyway, i am not sure what you mean by "DTD parser".
Forrest includes NekoDTD if that task is what you mean.
--David
> > Inclusion of Perl Documentation
> > -------------------------------
> > The directory src/documentation/content/xdocs/Pod contains what appear
> > to be official Perl documentation which I'm guessing would fall under
> > the "Perl Artistic License". Again, I'm not sure whether we would be
> > able to distribute this as part of an Apache Project.
>
> Uups, these should probaly not be distributed. You are right, it's
> the official perl distribution (taken from lib/pod), and I am using it
> to check if the formatter is working right, by visually comparing the
> result with http://www.perldoc.com/perl5.8.4/pod/perl.html
> It's commented out in site.xml in the distribution.
>
> Ron
Re: License & Copyright concerns Re: [plugins] pod-input auto install
Posted by Ron Blaschke <ma...@rblasch.org>.
Saturday, January 22, 2005, 8:50:30 PM, Rick Tessner wrote:
> On Fri, 2005-01-21 at 21:23 +0100, Ron Blaschke wrote:
>> Since most of the important things of pod-input are working, I'd like
>> to ask to have it added to the plugins list. The plugin is available
>> from
>> http://www.rblasch.org/projects/pod-input/org.rblasch.forrest.plugin.pod-input.zip
>>
>> Any feedback is highly appreciated, especially if you consider
>> anything missing.
> Thanks for this Ron! Tested it out and looks like it works well. :)
Thanks a bunch. :)
> I've been going through the zip you provided and I have a few concerns
> however.
> Java Class and Plugin Naming
> Copyright Notices
Should be ok, as it's not part of the Forrest distribution.
> Included JAR files and License
> -------------------------------
> There are two jars included in this zip file as well, but I didn't see
> any corresponding license files.
> jpod.jar
> matra.jar
> For the above, there should be license files named
> jpod.jar.license.txt
> matra.jar.license.txt
> The licenses would obviously need to be compatible with Apache License
> 2.0.
Thanks for pointing this out. I'll add the license files.
jpod is the beast that does the real work. pod-input just contains
the Cocoon Generator adapter. I am the author, and will distribute it
under the Apache License as well. It is, or better will be, available
separately, just in case someone wants to write another formatter
(HTML, etc).
matra, on the other hand, is available from
http://matra.sourceforge.net/ and ist distributed under the Mozilla
Public License 1.1 or GPL.
Is the MPL 1.1 compatible with the Apache License 2.0?
If not, can anybody recommend a DTD parser that is available under the
Apache License? jpod uses it to resolve E<entity> formatting codes,
which are akin to &entity; in XML.
> Inclusion of Perl Documentation
> -------------------------------
> The directory src/documentation/content/xdocs/Pod contains what appear
> to be official Perl documentation which I'm guessing would fall under
> the "Perl Artistic License". Again, I'm not sure whether we would be
> able to distribute this as part of an Apache Project.
Uups, these should probaly not be distributed. You are right, it's
the official perl distribution (taken from lib/pod), and I am using it
to check if the formatter is working right, by visually comparing the
result with http://www.perldoc.com/perl5.8.4/pod/perl.html
It's commented out in site.xml in the distribution.
Ron