You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by scott hutinger <s-...@wiu.edu> on 2006/03/03 18:07:40 UTC
[doc] future docs
Since bookmarks and TOC (in url form) sort of clash, any good ideas
about where to put links (not bookmarks).
I am thinking it might be wise to jump up to the DITA-2.1 beta (except
for the build). Although my initial investigation into this showed a
difference in the globals that we use, which broke the build. Hopefully
it will fix some of the broken items, as xslt gets a bit messy (to me).
Also the FOP changes coming down the pipeline seem to have a direct
impact on what direction (I take) with fixes (ie TOC (table of contents)).
Currently my build at work is having problems (linux) from a fresh co
yesterday.
Any ideas on the best method to do the switch? I still have some
changes that haven't been incorporated into the build, and are hanging
around somewhere. Possibly a working svn branch? XSLT debugging is
sometimes a pain to setup; depending on the build target...
thanks,
scott
Re: [doc] future docs
Posted by scott hutinger <s-...@wiu.edu>.
Jeff Levitt wrote:
> --- scott hutinger <s-...@wiu.edu> wrote:
>
>
>> Jeff Levitt wrote:
>>
>>> --- scott hutinger <s-...@wiu.edu> wrote:
>>>
>>>
>>>
>>>> Since bookmarks and TOC (in url form) sort of
>>>>
>> clash,
>>
>>>> any good ideas
>>>> about where to put links (not bookmarks).
>>>>
>>>> I am thinking it might be wise to jump up to the
>>>> DITA-2.1 beta (except
>>>> for the build). Although my initial
>>>>
>> investigation
>>
>>>> into this showed a
>>>> difference in the globals that we use, which
>>>>
>> broke
>>
>>>> the build. Hopefully
>>>> it will fix some of the broken items, as xslt
>>>>
>> gets a
>>
>>>> bit messy (to me).
>>>> Also the FOP changes coming down the pipeline
>>>>
>> seem
>>
>>>> to have a direct
>>>> impact on what direction (I take) with fixes (ie
>>>>
>> TOC
>>
>>>> (table of contents)).
>>>>
>>>> Currently my build at work is having problems
>>>> (linux) from a fresh co
>>>> yesterday.
>>>>
>>>> Any ideas on the best method to do the switch? I
>>>> still have some
>>>> changes that haven't been incorporated into the
>>>> build, and are hanging
>>>> around somewhere. Possibly a working svn branch?
>>>>
>>>> XSLT debugging is
>>>> sometimes a pain to setup; depending on the build
>>>> target...
>>>>
>>>> thanks,
>>>> scott
>>>>
>>>>
>>>>
>>> Hi Scott,
>>>
>>> I've played around with the DITA 1.2 (not 2.1, its
>>>
>> the
>>
>>> other way around) :) a little bit these past few
>>> weeks. There are some problems with the java
>>>
>> files in
>>
>>> it that they have submitted patches for, but you
>>>
>> need
>>
>>> to get the dita source files, apply the patch, and
>>> recompile in order to get it working. Otherwise,
>>>
>> the
>>
>>> toolkit doesnt build our Derby project.
>>>
>>> I agree that we should move to 1.2 though, as soon
>>>
>> as
>>
>>> they release a binary distribution that includes
>>>
>> the
>>
>>> patches. 1.2 handles links a lot better, as you
>>> stated, and it moves us closer and closer to not
>>> having to mod the xsl file each time.
>>>
>>>
>>>
>> Hi Jeff,
>> Are those (or that) patch on the DITA-OT public
>> patches? If not, could
>> you send me the patch?
>> Yes, 1.2 (not 2.1). Sometimes I jump too far :-) I
>> don't have a
>> problem with re-building something, as that's the
>> norm isn't it? (just
>> kidding). I'll look at the patches at DITA-OT...
>>
>> thanks,
>> scott
>>
>>
>
> Hey Scott,
>
> Here is the link to the info about the bug and the
> download for the patch they supplied to it. This is
> exactly the bug I get when I try to build derby docs
> using the 1.2 binaries.
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1431229&group_id=132728&atid=725074
>
>
>
>
Ah...that is the exact problem :-) Although ant was saying it was
ignoring the paths, and I wasn't sure why....
thanks,
scott
Re: [doc] future docs
Posted by Jeff Levitt <de...@mylevita.com>.
--- scott hutinger <s-...@wiu.edu> wrote:
> Jeff Levitt wrote:
> > --- scott hutinger <s-...@wiu.edu> wrote:
> >
> >
> >> Since bookmarks and TOC (in url form) sort of
> clash,
> >> any good ideas
> >> about where to put links (not bookmarks).
> >>
> >> I am thinking it might be wise to jump up to the
> >> DITA-2.1 beta (except
> >> for the build). Although my initial
> investigation
> >> into this showed a
> >> difference in the globals that we use, which
> broke
> >> the build. Hopefully
> >> it will fix some of the broken items, as xslt
> gets a
> >> bit messy (to me).
> >> Also the FOP changes coming down the pipeline
> seem
> >> to have a direct
> >> impact on what direction (I take) with fixes (ie
> TOC
> >> (table of contents)).
> >>
> >> Currently my build at work is having problems
> >> (linux) from a fresh co
> >> yesterday.
> >>
> >> Any ideas on the best method to do the switch? I
> >> still have some
> >> changes that haven't been incorporated into the
> >> build, and are hanging
> >> around somewhere. Possibly a working svn branch?
>
> >> XSLT debugging is
> >> sometimes a pain to setup; depending on the build
> >> target...
> >>
> >> thanks,
> >> scott
> >>
> >>
> > Hi Scott,
> >
> > I've played around with the DITA 1.2 (not 2.1, its
> the
> > other way around) :) a little bit these past few
> > weeks. There are some problems with the java
> files in
> > it that they have submitted patches for, but you
> need
> > to get the dita source files, apply the patch, and
> > recompile in order to get it working. Otherwise,
> the
> > toolkit doesnt build our Derby project.
> >
> > I agree that we should move to 1.2 though, as soon
> as
> > they release a binary distribution that includes
> the
> > patches. 1.2 handles links a lot better, as you
> > stated, and it moves us closer and closer to not
> > having to mod the xsl file each time.
> >
> >
>
> Hi Jeff,
> Are those (or that) patch on the DITA-OT public
> patches? If not, could
> you send me the patch?
> Yes, 1.2 (not 2.1). Sometimes I jump too far :-) I
> don't have a
> problem with re-building something, as that's the
> norm isn't it? (just
> kidding). I'll look at the patches at DITA-OT...
>
> thanks,
> scott
>
Hey Scott,
Here is the link to the info about the bug and the
download for the patch they supplied to it. This is
exactly the bug I get when I try to build derby docs
using the 1.2 binaries.
http://sourceforge.net/tracker/index.php?func=detail&aid=1431229&group_id=132728&atid=725074
Re: [doc] future docs
Posted by scott hutinger <s-...@wiu.edu>.
Jeff Levitt wrote:
> --- scott hutinger <s-...@wiu.edu> wrote:
>
>
>> Since bookmarks and TOC (in url form) sort of clash,
>> any good ideas
>> about where to put links (not bookmarks).
>>
>> I am thinking it might be wise to jump up to the
>> DITA-2.1 beta (except
>> for the build). Although my initial investigation
>> into this showed a
>> difference in the globals that we use, which broke
>> the build. Hopefully
>> it will fix some of the broken items, as xslt gets a
>> bit messy (to me).
>> Also the FOP changes coming down the pipeline seem
>> to have a direct
>> impact on what direction (I take) with fixes (ie TOC
>> (table of contents)).
>>
>> Currently my build at work is having problems
>> (linux) from a fresh co
>> yesterday.
>>
>> Any ideas on the best method to do the switch? I
>> still have some
>> changes that haven't been incorporated into the
>> build, and are hanging
>> around somewhere. Possibly a working svn branch?
>> XSLT debugging is
>> sometimes a pain to setup; depending on the build
>> target...
>>
>> thanks,
>> scott
>>
>>
> Hi Scott,
>
> I've played around with the DITA 1.2 (not 2.1, its the
> other way around) :) a little bit these past few
> weeks. There are some problems with the java files in
> it that they have submitted patches for, but you need
> to get the dita source files, apply the patch, and
> recompile in order to get it working. Otherwise, the
> toolkit doesnt build our Derby project.
>
> I agree that we should move to 1.2 though, as soon as
> they release a binary distribution that includes the
> patches. 1.2 handles links a lot better, as you
> stated, and it moves us closer and closer to not
> having to mod the xsl file each time.
>
>
Hi Jeff,
Are those (or that) patch on the DITA-OT public patches? If not, could
you send me the patch?
Yes, 1.2 (not 2.1). Sometimes I jump too far :-) I don't have a
problem with re-building something, as that's the norm isn't it? (just
kidding). I'll look at the patches at DITA-OT...
thanks,
scott
Re: [doc] future docs
Posted by Jeff Levitt <de...@mylevita.com>.
--- scott hutinger <s-...@wiu.edu> wrote:
> Since bookmarks and TOC (in url form) sort of clash,
> any good ideas
> about where to put links (not bookmarks).
>
> I am thinking it might be wise to jump up to the
> DITA-2.1 beta (except
> for the build). Although my initial investigation
> into this showed a
> difference in the globals that we use, which broke
> the build. Hopefully
> it will fix some of the broken items, as xslt gets a
> bit messy (to me).
> Also the FOP changes coming down the pipeline seem
> to have a direct
> impact on what direction (I take) with fixes (ie TOC
> (table of contents)).
>
> Currently my build at work is having problems
> (linux) from a fresh co
> yesterday.
>
> Any ideas on the best method to do the switch? I
> still have some
> changes that haven't been incorporated into the
> build, and are hanging
> around somewhere. Possibly a working svn branch?
> XSLT debugging is
> sometimes a pain to setup; depending on the build
> target...
>
> thanks,
> scott
>
Hi Scott,
I've played around with the DITA 1.2 (not 2.1, its the
other way around) :) a little bit these past few
weeks. There are some problems with the java files in
it that they have submitted patches for, but you need
to get the dita source files, apply the patch, and
recompile in order to get it working. Otherwise, the
toolkit doesnt build our Derby project.
I agree that we should move to 1.2 though, as soon as
they release a binary distribution that includes the
patches. 1.2 handles links a lot better, as you
stated, and it moves us closer and closer to not
having to mod the xsl file each time.