You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Marshall Schor (JIRA)" <de...@uima.apache.org> on 2010/10/31 17:30:50 UTC

[jira] Created: (UIMA-1920) Binary Assemblies need updating for fetching docbook artifacts from their new spots under ../d/.. and putting them in the right hierarchies

Binary Assemblies need updating for fetching docbook artifacts from their new spots under ../d/.. and putting them in the right hierarchies
-------------------------------------------------------------------------------------------------------------------------------------------

                 Key: UIMA-1920
                 URL: https://issues.apache.org/jira/browse/UIMA-1920
             Project: UIMA
          Issue Type: Bug
          Components: Build, Packaging and Test
            Reporter: Marshall Schor
            Assignee: Marshall Schor
            Priority: Minor
             Fix For: build-parent-pom-1


The binary assemblies need to fetch the documentation built with the docbook toolchain from the spot where that toolchain is configured to put the output - now under .../target/site/d/:
{noformat}
  ../target/site/d
       css
           stylesheet-html.css
       images
           [bookname]/[bookpartname]/...    <-- image files
      [bookname].html
      [bookname].pdf
 {noformat}

In the assemblies, change the source (where these files come from) to reflect this layout in the target/site/d directory.
Change the layout in the assemblies to preserve the relative position of the
html, images, and css files and directories, because the html has relative refs to these.

Both the html and PDF files support links between the various "books".  These links
are setup to be "relative", and assume a relative layout that looks like this:

{noformat}
  some-top-level-dir
      d
          [bookname].html
          [bookname].pdf
{noformat}

Currently, the PDF layout is presuming an extra directory above the "d",
which is inconsistent with how the html is specified.  Fix this to correspond
to how the html is arranged, by updating the build/uima-docbook-olink project,
which is where these default layouts are specified.

Change the assemblies to copy the information under site/d to the assembly
docs directory, (including the "d").



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Closed: (UIMA-1920) Binary Assemblies need updating for fetching docbook artifacts from their new spots under ../d/.. and putting them in the right hierarchies

Posted by "Marshall Schor (JIRA)" <de...@uima.apache.org>.
     [ https://issues.apache.org/jira/browse/UIMA-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marshall Schor closed UIMA-1920.
--------------------------------

    Resolution: Fixed

> Binary Assemblies need updating for fetching docbook artifacts from their new spots under ../d/.. and putting them in the right hierarchies
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: UIMA-1920
>                 URL: https://issues.apache.org/jira/browse/UIMA-1920
>             Project: UIMA
>          Issue Type: Bug
>          Components: Build, Packaging and Test
>            Reporter: Marshall Schor
>            Assignee: Marshall Schor
>            Priority: Minor
>             Fix For: build-parent-pom-1
>
>
> The binary assemblies need to fetch the documentation built with the docbook toolchain from the spot where that toolchain is configured to put the output - now under .../target/site/d/:
> {noformat}
>   ../target/site/d
>        css
>            stylesheet-html.css
>        images
>            [bookname]/[bookpartname]/...    <-- image files
>       [bookname].html
>       [bookname].pdf
>  {noformat}
> In the assemblies, change the source (where these files come from) to reflect this layout in the target/site/d directory.
> Change the layout in the assemblies to preserve the relative position of the
> html, images, and css files and directories, because the html has relative refs to these.
> Both the html and PDF files support links between the various "books".  These links
> are setup to be "relative", and assume a relative layout that looks like this:
> {noformat}
>   some-top-level-dir
>       d
>           [bookname].html
>           [bookname].pdf
> {noformat}
> Currently, the PDF layout is presuming an extra directory above the "d",
> which is inconsistent with how the html is specified.  Fix this to correspond
> to how the html is arranged, by updating the build/uima-docbook-olink project,
> which is where these default layouts are specified.
> Change the assemblies to copy the information under site/d to the assembly
> docs directory, (including the "d").

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (UIMA-1920) Binary Assemblies need updating for fetching docbook artifacts from their new spots under ../d/.. and putting them in the right hierarchies

Posted by "Marshall Schor (JIRA)" <de...@uima.apache.org>.
    [ https://issues.apache.org/jira/browse/UIMA-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12926741#action_12926741 ] 

Marshall Schor commented on UIMA-1920:
--------------------------------------

I remember now why there was an extra directory at the front, with the artifact name, so it looked like:
{noformat}
  some-top-level-dir
      artifact-name        <-- additional directory
          d
              [bookname].html
              [bookname].pdf
{noformat}
This was to support the convention in Maven site deployment that puts an individual project's site by default in a directory which includes the artifactId as a prefix.

If this turns out to really be needed for these docbook "libraries", we'll have to revisit this, I think.  But for now, I'll go with the simpler layout.

> Binary Assemblies need updating for fetching docbook artifacts from their new spots under ../d/.. and putting them in the right hierarchies
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: UIMA-1920
>                 URL: https://issues.apache.org/jira/browse/UIMA-1920
>             Project: UIMA
>          Issue Type: Bug
>          Components: Build, Packaging and Test
>            Reporter: Marshall Schor
>            Assignee: Marshall Schor
>            Priority: Minor
>             Fix For: build-parent-pom-1
>
>
> The binary assemblies need to fetch the documentation built with the docbook toolchain from the spot where that toolchain is configured to put the output - now under .../target/site/d/:
> {noformat}
>   ../target/site/d
>        css
>            stylesheet-html.css
>        images
>            [bookname]/[bookpartname]/...    <-- image files
>       [bookname].html
>       [bookname].pdf
>  {noformat}
> In the assemblies, change the source (where these files come from) to reflect this layout in the target/site/d directory.
> Change the layout in the assemblies to preserve the relative position of the
> html, images, and css files and directories, because the html has relative refs to these.
> Both the html and PDF files support links between the various "books".  These links
> are setup to be "relative", and assume a relative layout that looks like this:
> {noformat}
>   some-top-level-dir
>       d
>           [bookname].html
>           [bookname].pdf
> {noformat}
> Currently, the PDF layout is presuming an extra directory above the "d",
> which is inconsistent with how the html is specified.  Fix this to correspond
> to how the html is arranged, by updating the build/uima-docbook-olink project,
> which is where these default layouts are specified.
> Change the assemblies to copy the information under site/d to the assembly
> docs directory, (including the "d").

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.