[cassandra-website] branch asf-staging updated (541ab1f -> 52df890)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard 541ab1f generate docs for f211daf6 new 52df890 generate docs for f211daf6 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (541ab1f) \ N -- N -- N refs/heads/asf-staging (52df890) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/feed.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (940eed4 -> 541ab1f)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard 940eed4 generate docs for f211daf6 new 541ab1f generate docs for f211daf6 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (940eed4) \ N -- N -- N refs/heads/asf-staging (541ab1f) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/feed.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (3e5320d -> 940eed4)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard 3e5320d generate docs for f211daf6 new 940eed4 generate docs for f211daf6 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (3e5320d) \ N -- N -- N refs/heads/asf-staging (940eed4) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .asf.yaml | 0 .gitignore | 0 Dockerfile | 0 LICENSE.txt| 0 README.md | 0 content/feed.xml | 2 +- doap.rdf | 0 docker-compose.yml | 0 8 files changed, 1 insertion(+), 1 deletion(-) mode change 100755 => 100644 .asf.yaml mode change 100755 => 100644 .gitignore mode change 100755 => 100644 Dockerfile mode change 100755 => 100644 LICENSE.txt mode change 100755 => 100644 README.md mode change 100755 => 100644 doap.rdf mode change 100755 => 100644 docker-compose.yml - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16066) Update and rework cassandra-website material to work with Antora
[ https://issues.apache.org/jira/browse/CASSANDRA-16066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191131#comment-17191131 ] Michael Semb Wever edited comment on CASSANDRA-16066 at 9/5/20, 6:57 PM: - WIth the diagram above, currently we are not generating docs to the asf-site branch. The asf-site branch is just a manual copy (`git reset …`) of asf-staging after it has been manually verified on cassandra.staged.a.o. See the bottom of the [README.md|https://github.com/apache/cassandra-website/blob/master/README.md]. Antora uses the MPL (Mozilla Public License). The Antora UI bundle involves original or modified files from Antora under this license. Such a UI bundle is usually put into the git repository. Having such a bundle in the cassandra-website repository is ok, because we never release or distribute it. Having the bundle in the cassandra repository is in itself not a problem but we would have to change the release process to ensure it does not appear in either the source *-src.tar.gz or binary *-bin.tar.gz release artefacts. Like you say [~xingh], it would just be easier if the UI bundle was kept out of the cassandra repository, and any docs available inside release artefacts not be built with antora. More info on this is [here|https://issues.apache.org/jira/browse/LEGAL-530]. was (Author: michaelsembwever): WIth the diagram above, currently we are not generating docs to the asf-site branch. The asf-site branch is just a manual copy (`git reset …`) of asf-staging after it has been manually verified on cassandra.staged.a.o. See the bottom of the [README.md|https://github.com/apache/cassandra-website/blob/master/README.md]. Antora uses the MPL (Mozilla Public License). The Antora UI bundle involves original or modified files from Antora under this license. Such a UI bundle is usually put into the git repository. Having such a bundle in the cassandra-website repository is ok, because we never release or distribute it. Having the bundle in the cassandra repository is in itself not a problem but we would have to change the release process to ensure it does not appear in either the source *-src.tar.gz or binary *-bin.tar.gz release artefacts. Like you say [~xingh], it would just be easier if the UI bundle was kept out of the cassandra repository, and any docs available inside release artefacts not be built with antora. > Update and rework cassandra-website material to work with Antora > > > Key: CASSANDRA-16066 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16066 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Anthony Grasso >Priority: Normal > Attachments: image-2020-09-05-13-24-13-606.png > > > *We want to modernise the way the website is built* > Rework the cassandra-website repository to generate a UI bundle containing > resources that Antora will use when generating the Cassandra documents and > website. > *The existing method is starting to become dated* > The documentation and website templates are currently in markdown format. > Sphinx is used to generate the Cassandra documentation and Jekyll generates > the website content. One of the major issues with the existing website > tooling is that the live preview server (render site as it is being updated) > is really slow. There is a preview server that is really fast, however it is > unable to detect changes to the content and render automatically. > *We are migrating the docs to be rendered with Antora* > The work in CASSANDRA-16029 is converting the document templates to AsciiDoc > format. Sphinx is being replaced by Antora to generate the documentation > content. This change has two advantages: > * More flexibility if the Apache Cassandra documentation look and feel needs > to be updated or redesigned. > * More modern look and feel to the documentation. > *We can use Antora to generate the website as well* > Antora could also be used to generate the Cassandra website content. As > suggested on the [mailing > list|https://www.mail-archive.com/dev@cassandra.apache.org/msg15577.html] > this would require the existing markdown templates to be converted to > AsciiDoc as well. > *Antora needs a UI bundle to style content* > For Antora to generate the document content and potentially the website > content it requires a UI bundle (ui-bundle.zip). The UI bundle contains the > HTML templates (layouts, partials, and helpers), CSS, JavaScript, fonts, and > (site-wide) images. As such, it provides both the visual theme and user > interactions for the documentation. Effectively the UI bundle is the > templates and styling that are applied to the documentation and website > content. > *The
[jira] [Commented] (CASSANDRA-16066) Update and rework cassandra-website material to work with Antora
[ https://issues.apache.org/jira/browse/CASSANDRA-16066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191131#comment-17191131 ] Michael Semb Wever commented on CASSANDRA-16066: WIth the diagram above, currently we are not generating docs to the asf-site branch. The asf-site branch is just a manual copy (`git reset …`) of asf-staging after it has been manually verified on cassandra.staged.a.o. See the bottom of the [README.md|https://github.com/apache/cassandra-website/blob/master/README.md]. Antora uses the MPL (Mozilla Public License). The Antora UI bundle involves original or modified files from Antora under this license. Such a UI bundle is usually put into the git repository. Having such a bundle in the cassandra-website repository is ok, because we never release or distribute it. Having the bundle in the cassandra repository is in itself not a problem but we would have to change the release process to ensure it does not appear in either the source *-src.tar.gz or binary *-bin.tar.gz release artefacts. Like you say [~xingh], it would just be easier if the UI bundle was kept out of the cassandra repository, and any docs available inside release artefacts not be built with antora. > Update and rework cassandra-website material to work with Antora > > > Key: CASSANDRA-16066 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16066 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Anthony Grasso >Priority: Normal > Attachments: image-2020-09-05-13-24-13-606.png > > > *We want to modernise the way the website is built* > Rework the cassandra-website repository to generate a UI bundle containing > resources that Antora will use when generating the Cassandra documents and > website. > *The existing method is starting to become dated* > The documentation and website templates are currently in markdown format. > Sphinx is used to generate the Cassandra documentation and Jekyll generates > the website content. One of the major issues with the existing website > tooling is that the live preview server (render site as it is being updated) > is really slow. There is a preview server that is really fast, however it is > unable to detect changes to the content and render automatically. > *We are migrating the docs to be rendered with Antora* > The work in CASSANDRA-16029 is converting the document templates to AsciiDoc > format. Sphinx is being replaced by Antora to generate the documentation > content. This change has two advantages: > * More flexibility if the Apache Cassandra documentation look and feel needs > to be updated or redesigned. > * More modern look and feel to the documentation. > *We can use Antora to generate the website as well* > Antora could also be used to generate the Cassandra website content. As > suggested on the [mailing > list|https://www.mail-archive.com/dev@cassandra.apache.org/msg15577.html] > this would require the existing markdown templates to be converted to > AsciiDoc as well. > *Antora needs a UI bundle to style content* > For Antora to generate the document content and potentially the website > content it requires a UI bundle (ui-bundle.zip). The UI bundle contains the > HTML templates (layouts, partials, and helpers), CSS, JavaScript, fonts, and > (site-wide) images. As such, it provides both the visual theme and user > interactions for the documentation. Effectively the UI bundle is the > templates and styling that are applied to the documentation and website > content. > *The [cassandra-website|https://github.com/apache/cassandra-website] > repository can be used to generate the UI bundle* > All the resources associated with templating and styling the documentation > and website can be placed in the > [cassandra-website|https://github.com/apache/cassandra-website] repository. > In this case the repository would serve two purposes; > * Generation of the UI bundle resources. > * Serve the production website content. > *The [cassandra|https://github.com/apache/cassandra] repository would contain > the documentation material, while the rest of the non-versioned pages would > contain that material* > * All other material that is used to generate documentation would live in > the [cassandra|https://github.com/apache/cassandra] repository. In this case > Antora would run on the > [cassandra/doc|https://github.com/apache/cassandra/doc] directory and pull in > a UI bundle released on the GitHub > [cassandra-website|https://github.com/apache/cassandra-website] repository. > The content generated by Antora using the site.yml file located in this repo > can be used to preview the docs for review. > * All other non-versioned material, such as the
[jira] [Commented] (CASSANDRA-16066) Update and rework cassandra-website material to work with Antora
[ https://issues.apache.org/jira/browse/CASSANDRA-16066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191118#comment-17191118 ] Rahul Singh commented on CASSANDRA-16066: - Lorina's proposal above mentions a docker container in the cassandra src to generate documentation as well in the cassandra-website src. If the Antora license constraint prevents us from placing Antora artifacts in the cassandra.git, does it still count if the actual build process is 100% done by a prebuilt docker image ? If so, then what you ask [~mck] based on what you mentioned about Antora license, does this mean it prevents us from even having a Dockerfile that mentions an Antora image + configuration yml which tells which files to convert? *"For the releases, can the in-tree asciidocs be built without antora and solely in-tree?* If we can't have Antora what-so-ever on the cassandra.git, then we can use a much more basic asciidoc to html/pdf generator which doesn't have such constraints. There are plenty out there and some of them may just be a HTML/JS shell that renders Asciidoc to HTML dynamically without the need for a generation step for intree docs. ([https://gist.github.com/briandominick/e5754cc8438dd9503d936ef65fffbb2d,] At the same time, Antora being run in the cassandra-website repo would pull the same asciidoc files and create nice looking site out of it. !image-2020-09-05-13-24-13-606.png! > Update and rework cassandra-website material to work with Antora > > > Key: CASSANDRA-16066 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16066 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Anthony Grasso >Priority: Normal > Attachments: image-2020-09-05-13-24-13-606.png > > > *We want to modernise the way the website is built* > Rework the cassandra-website repository to generate a UI bundle containing > resources that Antora will use when generating the Cassandra documents and > website. > *The existing method is starting to become dated* > The documentation and website templates are currently in markdown format. > Sphinx is used to generate the Cassandra documentation and Jekyll generates > the website content. One of the major issues with the existing website > tooling is that the live preview server (render site as it is being updated) > is really slow. There is a preview server that is really fast, however it is > unable to detect changes to the content and render automatically. > *We are migrating the docs to be rendered with Antora* > The work in CASSANDRA-16029 is converting the document templates to AsciiDoc > format. Sphinx is being replaced by Antora to generate the documentation > content. This change has two advantages: > * More flexibility if the Apache Cassandra documentation look and feel needs > to be updated or redesigned. > * More modern look and feel to the documentation. > *We can use Antora to generate the website as well* > Antora could also be used to generate the Cassandra website content. As > suggested on the [mailing > list|https://www.mail-archive.com/dev@cassandra.apache.org/msg15577.html] > this would require the existing markdown templates to be converted to > AsciiDoc as well. > *Antora needs a UI bundle to style content* > For Antora to generate the document content and potentially the website > content it requires a UI bundle (ui-bundle.zip). The UI bundle contains the > HTML templates (layouts, partials, and helpers), CSS, JavaScript, fonts, and > (site-wide) images. As such, it provides both the visual theme and user > interactions for the documentation. Effectively the UI bundle is the > templates and styling that are applied to the documentation and website > content. > *The [cassandra-website|https://github.com/apache/cassandra-website] > repository can be used to generate the UI bundle* > All the resources associated with templating and styling the documentation > and website can be placed in the > [cassandra-website|https://github.com/apache/cassandra-website] repository. > In this case the repository would serve two purposes; > * Generation of the UI bundle resources. > * Serve the production website content. > *The [cassandra|https://github.com/apache/cassandra] repository would contain > the documentation material, while the rest of the non-versioned pages would > contain that material* > * All other material that is used to generate documentation would live in > the [cassandra|https://github.com/apache/cassandra] repository. In this case > Antora would run on the > [cassandra/doc|https://github.com/apache/cassandra/doc] directory and pull in > a UI bundle released on the GitHub >
[jira] [Updated] (CASSANDRA-16066) Update and rework cassandra-website material to work with Antora
[
https://issues.apache.org/jira/browse/CASSANDRA-16066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rahul Singh updated CASSANDRA-16066:
Attachment: image-2020-09-05-13-24-13-606.png
> Update and rework cassandra-website material to work with Antora
>
>
> Key: CASSANDRA-16066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16066
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Anthony Grasso
>Priority: Normal
> Attachments: image-2020-09-05-13-24-13-606.png
>
>
> *We want to modernise the way the website is built*
> Rework the cassandra-website repository to generate a UI bundle containing
> resources that Antora will use when generating the Cassandra documents and
> website.
> *The existing method is starting to become dated*
> The documentation and website templates are currently in markdown format.
> Sphinx is used to generate the Cassandra documentation and Jekyll generates
> the website content. One of the major issues with the existing website
> tooling is that the live preview server (render site as it is being updated)
> is really slow. There is a preview server that is really fast, however it is
> unable to detect changes to the content and render automatically.
> *We are migrating the docs to be rendered with Antora*
> The work in CASSANDRA-16029 is converting the document templates to AsciiDoc
> format. Sphinx is being replaced by Antora to generate the documentation
> content. This change has two advantages:
> * More flexibility if the Apache Cassandra documentation look and feel needs
> to be updated or redesigned.
> * More modern look and feel to the documentation.
> *We can use Antora to generate the website as well*
> Antora could also be used to generate the Cassandra website content. As
> suggested on the [mailing
> list|https://www.mail-archive.com/dev@cassandra.apache.org/msg15577.html]
> this would require the existing markdown templates to be converted to
> AsciiDoc as well.
> *Antora needs a UI bundle to style content*
> For Antora to generate the document content and potentially the website
> content it requires a UI bundle (ui-bundle.zip). The UI bundle contains the
> HTML templates (layouts, partials, and helpers), CSS, JavaScript, fonts, and
> (site-wide) images. As such, it provides both the visual theme and user
> interactions for the documentation. Effectively the UI bundle is the
> templates and styling that are applied to the documentation and website
> content.
> *The [cassandra-website|https://github.com/apache/cassandra-website]
> repository can be used to generate the UI bundle*
> All the resources associated with templating and styling the documentation
> and website can be placed in the
> [cassandra-website|https://github.com/apache/cassandra-website] repository.
> In this case the repository would serve two purposes;
> * Generation of the UI bundle resources.
> * Serve the production website content.
> *The [cassandra|https://github.com/apache/cassandra] repository would contain
> the documentation material, while the rest of the non-versioned pages would
> contain that material*
> * All other material that is used to generate documentation would live in
> the [cassandra|https://github.com/apache/cassandra] repository. In this case
> Antora would run on the
> [cassandra/doc|https://github.com/apache/cassandra/doc] directory and pull in
> a UI bundle released on the GitHub
> [cassandra-website|https://github.com/apache/cassandra-website] repository.
> The content generated by Antora using the site.yml file located in this repo
> can be used to preview the docs for review.
> * All other non-versioned material, such as the blogs, development
> instructions, and third-party page would live in the GitHub
> [cassandra-website|https://github.com/apache/cassandra-website] repository.
> Antora will generate the full website using the site.yml located in this
> repo, using both as content sources the material located in both the
> [cassandra|https://github.com/apache/cassandra] and
> [cassandra-website|https://github.com/apache/cassandra-website] repositories.
> *Design, content, and layout would remain the same*
> This proposal means the roles of each repository will change. In addition,
> the workflow to publish material will change as well. However, the website
> design, content, and layout will remain the same.
> As an added bonus the tooling would allow for a live preview server that is
> fast and responsive. However, the time to build and generate the {{nodetool}}
> and Cassandra YAML AssciDoc files will still take in the order of minutes to
> complete.
> *The [cassandra-website|https://github.com/apache/cassandra-website]
> repository
[jira] [Assigned] (CASSANDRA-16086) MessageSerializationPropertyTest fails with bytes should not be empty for type org.apache.cassandra.db.marshal.BytesType
[
https://issues.apache.org/jira/browse/CASSANDRA-16086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bon reassigned CASSANDRA-16086:
---
Assignee: Bon (was: David Capwell)
> MessageSerializationPropertyTest fails with bytes should not be empty for
> type org.apache.cassandra.db.marshal.BytesType
>
>
> Key: CASSANDRA-16086
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16086
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Bon
>Priority: Normal
> Fix For: 4.0-beta3
>
>
> {code}
> Cause was :-
> java.lang.AssertionError: bytes should not be empty for type
> org.apache.cassandra.db.marshal.BytesType
> at
> org.apache.cassandra.db.marshal.AbstractType.writtenLength(AbstractType.java:423)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.selectionSerializedSize(SinglePartitionReadCommand.java:1043)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.serializedSize(ReadCommand.java:1038)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.serializedSize(ReadCommand.java:909)
> at
> org.apache.cassandra.net.Message$Serializer.payloadSize(Message.java:1289)
> at org.apache.cassandra.net.Message.payloadSize(Message.java:1333)
> at
> org.apache.cassandra.net.Message$Serializer.serializePre40(Message.java:917)
> at
> org.apache.cassandra.net.Message$Serializer.serialize(Message.java:620)
> at
> org.apache.cassandra.net.MessageSerializationPropertyTest.lambda$serializeSizeProperty$0(MessageSerializationPropertyTest.java:73)
> Seed was 35361441975355
> {code}
> This is caused by the fact the generators allow empty types.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13935) Indexes and UDTs creation should have IF NOT EXISTS on its String representation
[
https://issues.apache.org/jira/browse/CASSANDRA-13935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Server Murat Koçum updated CASSANDRA-13935:
---
Status: In Progress (was: Patch Available)
> Indexes and UDTs creation should have IF NOT EXISTS on its String
> representation
>
>
> Key: CASSANDRA-13935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13935
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index, Legacy/CQL
> Environment: Ubuntu 16.04.2 LTS
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Javier Canillas
>Assignee: Stefan Miklosovic
>Priority: Low
> Fix For: 4.0-beta
>
> Attachments: 13935-3.0.txt, 13935-3.11.txt, 13935-trunk.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I came across something that bothers me a lot. I'm using snapshots to backup
> data from my Cassandra cluster in case something really bad happens (like
> dropping a table or a keyspace).
> Exercising the recovery actions from those backups, I discover that the
> schema put on the file "schema.cql" as a result of the snapshot has the
> "CREATE IF NOT EXISTS" for the table, but not for the indexes.
> When restoring from snapshots, and relying on the execution of these schemas
> to build up the table structure, everything seems fine for tables without
> secondary indexes, but for the ones that make use of them, the execution of
> these statements fail miserably.
> Here I paste a generated schema.cql content for a table with indexes:
> CREATE TABLE IF NOT EXISTS keyspace1.table1 (
> id text PRIMARY KEY,
> content text,
> last_update_date date,
> last_update_date_time timestamp)
> WITH ID = f1045fc0-2f59-11e7-95ec-295c3c064920
> AND bloom_filter_fp_chance = 0.01
> AND dclocal_read_repair_chance = 0.1
> AND crc_check_chance = 1.0
> AND default_time_to_live = 864
> AND gc_grace_seconds = 864000
> AND min_index_interval = 128
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE'
> AND caching = { 'keys': 'NONE', 'rows_per_partition': 'NONE' }
> AND compaction = { 'max_threshold': '32', 'min_threshold': '4',
> 'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' }
> AND compression = { 'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor' }
> AND cdc = false
> AND extensions = { };
> CREATE INDEX table1_last_update_date_idx ON keyspace1.table1
> (last_update_date);
> I think the last part should be:
> CREATE INDEX IF NOT EXISTS table1_last_update_date_idx ON keyspace1.table1
> (last_update_date);
> // edit by Stefan Miklosovic
> PR: https://github.com/apache/cassandra/pull/731
> I have added UDTs as part of this patch as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16066) Update and rework cassandra-website material to work with Antora
[ https://issues.apache.org/jira/browse/CASSANDRA-16066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191037#comment-17191037 ] Rahul Singh commented on CASSANDRA-16066: - Thanks for clarifying the antora license constraint. I like your approach because it achieves the same thing with two build processes that run within the cassandra-website : 1 to update / from contents in the website repo and 2 to update /docs/ from the cassandra repo. I'll review the links again and circle back but I think what you are saying is possible. Antora can do local, remote public or remote private repos. The only change from [~polandll] 's plan is to make sure we only run Antora in the cassandra-website source for both sets of artifacts. > Update and rework cassandra-website material to work with Antora > > > Key: CASSANDRA-16066 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16066 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Anthony Grasso >Priority: Normal > > *We want to modernise the way the website is built* > Rework the cassandra-website repository to generate a UI bundle containing > resources that Antora will use when generating the Cassandra documents and > website. > *The existing method is starting to become dated* > The documentation and website templates are currently in markdown format. > Sphinx is used to generate the Cassandra documentation and Jekyll generates > the website content. One of the major issues with the existing website > tooling is that the live preview server (render site as it is being updated) > is really slow. There is a preview server that is really fast, however it is > unable to detect changes to the content and render automatically. > *We are migrating the docs to be rendered with Antora* > The work in CASSANDRA-16029 is converting the document templates to AsciiDoc > format. Sphinx is being replaced by Antora to generate the documentation > content. This change has two advantages: > * More flexibility if the Apache Cassandra documentation look and feel needs > to be updated or redesigned. > * More modern look and feel to the documentation. > *We can use Antora to generate the website as well* > Antora could also be used to generate the Cassandra website content. As > suggested on the [mailing > list|https://www.mail-archive.com/dev@cassandra.apache.org/msg15577.html] > this would require the existing markdown templates to be converted to > AsciiDoc as well. > *Antora needs a UI bundle to style content* > For Antora to generate the document content and potentially the website > content it requires a UI bundle (ui-bundle.zip). The UI bundle contains the > HTML templates (layouts, partials, and helpers), CSS, JavaScript, fonts, and > (site-wide) images. As such, it provides both the visual theme and user > interactions for the documentation. Effectively the UI bundle is the > templates and styling that are applied to the documentation and website > content. > *The [cassandra-website|https://github.com/apache/cassandra-website] > repository can be used to generate the UI bundle* > All the resources associated with templating and styling the documentation > and website can be placed in the > [cassandra-website|https://github.com/apache/cassandra-website] repository. > In this case the repository would serve two purposes; > * Generation of the UI bundle resources. > * Serve the production website content. > *The [cassandra|https://github.com/apache/cassandra] repository would contain > the documentation material, while the rest of the non-versioned pages would > contain that material* > * All other material that is used to generate documentation would live in > the [cassandra|https://github.com/apache/cassandra] repository. In this case > Antora would run on the > [cassandra/doc|https://github.com/apache/cassandra/doc] directory and pull in > a UI bundle released on the GitHub > [cassandra-website|https://github.com/apache/cassandra-website] repository. > The content generated by Antora using the site.yml file located in this repo > can be used to preview the docs for review. > * All other non-versioned material, such as the blogs, development > instructions, and third-party page would live in the GitHub > [cassandra-website|https://github.com/apache/cassandra-website] repository. > Antora will generate the full website using the site.yml located in this > repo, using both as content sources the material located in both the > [cassandra|https://github.com/apache/cassandra] and > [cassandra-website|https://github.com/apache/cassandra-website] repositories. > *Design, content, and layout would remain the same* > This proposal means the roles of each
[jira] [Comment Edited] (CASSANDRA-16066) Update and rework cassandra-website material to work with Antora
[
https://issues.apache.org/jira/browse/CASSANDRA-16066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191016#comment-17191016
]
Michael Semb Wever edited comment on CASSANDRA-16066 at 9/5/20, 9:10 AM:
-
{quote}*I propose this (or this is what the intention may have been all along)*
* build process for cassandra
** uses docs/dockerfile as needed on releases to include in release
** uses docs/dockerfile as needed on releases to publish only /docs/ section of
the site ( separate public path to push docs content to)
* build process for cassandra-website
** uses /dockerfile as needed on publish blog/ etc. to / section of the site (
separate public path to push site content to)
{quote}
Some questions [~xingh],
bq. uses docs/dockerfile as needed on releases to publish only /docs/
Only one website can serve the contents. A build action in the
cassadra-repository would then have to push commit (on the asf-staging branch)
into the cassandra-website repository. Is that desired, can we come up with a
simpler approach?
bq. uses docs/dockerfile as needed on releases to include in release
It would be nice to have better bundled docs. But keep in mind that the Antora
has an incompatible license and none of its files (original or modified) can be
put into a C* release artefact.
.
It would be nice avoiding cross-repository dependencies.
For the releases, can the in-tree asciidocs be built without antora and solely
in-tree? This would solve bundling the docs into the release and simplify the
release process (by not being dependent on the cassandra-website repository).
If this is not possible I suggest we remove all in-tree doc-building actions
related to release bundles (like it is today).
For the website staging updates…
- when there's an update to cassandra-website, can we have one build command to
update just its contents on the asf-staging branch?
- when there's an update to cassandra, can we have one build command (in
cassandra-website) that updates just the versioned docs (/docs//)
contents on the asf-staging branch? (Currently there's no automated build to
staging when there's a change to in-tree docs. It just has to wait until
there's a change in the cassandra-website repository to trigger a CI build.)
More information on how the docs get published is in
- https://infra.apache.org/project-site.html
-
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-Specifyingasub-directorytopublishto
was (Author: michaelsembwever):
{quote}*I propose this (or this is what the intention may have been all along)*
* build process for cassandra
** uses docs/dockerfile as needed on releases to include in release
** uses docs/dockerfile as needed on releases to publish only /docs/ section of
the site ( separate public path to push docs content to)
* build process for cassandra-website
** uses /dockerfile as needed on publish blog/ etc. to / section of the site (
separate public path to push site content to)
{quote}
Some questions [~xingh],
bq. uses docs/dockerfile as needed on releases to publish only /docs/
Only one website can serve the contents. A build action in the
cassadra-repository would then have to push commit (on the asf-staging branch)
into the cassandra-website repository. Is that desired, can we come up with a
simpler approach?
bq. uses docs/dockerfile as needed on releases to include in release
It would be nice to have better bundled docs. But keep in mind that the Antora
has an incompatible license and none of its files (original or modified) can be
put into a C* release artefact.
.
It would be nice avoiding cross-repository dependencies.
For the releases, can the in-tree asciidocs be built without antora and solely
in-tree? This would solve bundling the docs into the release and simplify the
release process (by not being dependent on the cassandra-website repository).
If this is not possible I suggest we remove all in-tree doc-building actions
related to release bundles (like it is today).
For the website staging updates…
- when there's an update to cassandra-website, can we have one build command to
update just its contents on the asf-staging branch?
- when there's an update to cassandra, can we have one build command (in
cassandra-website) that updates just the versioned docs (/docs//)
contents on the asf-staging branch?
More information on how the docs get published is in
- https://infra.apache.org/project-site.html
-
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-Specifyingasub-directorytopublishto
> Update and rework cassandra-website material to work with Antora
>
>
> Key: CASSANDRA-16066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16066
>
[jira] [Comment Edited] (CASSANDRA-16066) Update and rework cassandra-website material to work with Antora
[
https://issues.apache.org/jira/browse/CASSANDRA-16066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191016#comment-17191016
]
Michael Semb Wever edited comment on CASSANDRA-16066 at 9/5/20, 9:09 AM:
-
{quote}*I propose this (or this is what the intention may have been all along)*
* build process for cassandra
** uses docs/dockerfile as needed on releases to include in release
** uses docs/dockerfile as needed on releases to publish only /docs/ section of
the site ( separate public path to push docs content to)
* build process for cassandra-website
** uses /dockerfile as needed on publish blog/ etc. to / section of the site (
separate public path to push site content to)
{quote}
Some questions [~xingh],
bq. uses docs/dockerfile as needed on releases to publish only /docs/
Only one website can serve the contents. A build action in the
cassadra-repository would then have to push commit (on the asf-staging branch)
into the cassandra-website repository. Is that desired, can we come up with a
simpler approach?
bq. uses docs/dockerfile as needed on releases to include in release
It would be nice to have better bundled docs. But keep in mind that the Antora
has an incompatible license and none of its files (original or modified) can be
put into a C* release artefact.
.
It would be nice avoiding cross-repository dependencies.
For the releases, can the in-tree asciidocs be built without antora and solely
in-tree? This would solve bundling the docs into the release and simplify the
release process (by not being dependent on the cassandra-website repository).
If this is not possible I suggest we remove all in-tree doc-building actions
related to release bundles (like it is today).
For the website staging updates…
- when there's an update to cassandra-website, can we have one build command to
update just its contents on the asf-staging branch?
- when there's an update to cassandra, can we have one build command (in
cassandra-website) that updates just the versioned docs (/docs//)
contents on the asf-staging branch?
More information on how the docs get published is in
- https://infra.apache.org/project-site.html
-
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-Specifyingasub-directorytopublishto
was (Author: michaelsembwever):
{quote}*I propose this (or this is what the intention may have been all along)*
* build process for cassandra
** uses docs/dockerfile as needed on releases to include in release
** uses docs/dockerfile as needed on releases to publish only /docs/ section of
the site ( separate public path to push docs content to)
* build process for cassandra-website
** uses /dockerfile as needed on publish blog/ etc. to / section of the site (
separate public path to push site content to)
{quote}
Some questions [~xingh],
bq. uses docs/dockerfile as needed on releases to publish only /docs/
Only one website can serve the contents. A build action in the
cassadra-repository would then have to push commit (on the asf-staging branch)
into the cassandra-website repository. Is that desired, can we come up with a
simpler approach?
bq. uses docs/dockerfile as needed on releases to include in release
It would be nice to have better bundled docs. But keep in mind that the Antora
has an incompatible license and none of its files (original or modified) can be
put into a C* release artefact.
.
It would be nice avoiding cross-repository dependencies.
For the releases, can the in-tree asciidocs be built without antora and solely
in-tree? This would solve bundling the docs into the release and simplify the
release process (by not being dependent on the cassandra-website repository).
If this is not possible I suggest we remove all docs from the release bundles
(like it is today).
For the website staging updates…
- when there's an update to cassandra-website, can we have one build command to
update just its contents on the asf-staging branch?
- when there's an update to cassandra, can we have one build command (in
cassandra-website) that updates just the versioned docs (/docs//)
contents on the asf-staging branch?
More information on how the docs get published is in
- https://infra.apache.org/project-site.html
-
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-Specifyingasub-directorytopublishto
> Update and rework cassandra-website material to work with Antora
>
>
> Key: CASSANDRA-16066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16066
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Anthony Grasso
>Priority: Normal
>
> *We want to modernise the way the website is
[jira] [Comment Edited] (CASSANDRA-16066) Update and rework cassandra-website material to work with Antora
[
https://issues.apache.org/jira/browse/CASSANDRA-16066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191016#comment-17191016
]
Michael Semb Wever edited comment on CASSANDRA-16066 at 9/5/20, 9:07 AM:
-
{quote}*I propose this (or this is what the intention may have been all along)*
* build process for cassandra
** uses docs/dockerfile as needed on releases to include in release
** uses docs/dockerfile as needed on releases to publish only /docs/ section of
the site ( separate public path to push docs content to)
* build process for cassandra-website
** uses /dockerfile as needed on publish blog/ etc. to / section of the site (
separate public path to push site content to)
{quote}
Some questions [~xingh],
bq. uses docs/dockerfile as needed on releases to publish only /docs/
Only one website can serve the contents. A build action in the
cassadra-repository would then have to push commit (on the asf-staging branch)
into the cassandra-website repository. Is that desired, can we come up with a
simpler approach?
bq. uses docs/dockerfile as needed on releases to include in release
It would be nice to have better bundled docs. But keep in mind that the Antora
has an incompatible license and none of its files (original or modified) can be
put into a C* release artefact.
It would be nice avoiding cross-repository dependencies.
For the releases, can the in-tree asciidocs be built without antora and solely
in-tree? This would solve bundling the docs into the release and simplify the
release process (by not being dependent on the cassandra-website repository).
If this is not possible I suggest we remove all docs from the release bundles
(like it is today).
For the website staging updates…
- when there's an update to cassandra-website, can we have one build command to
update just its contents on the asf-staging branch?
- when there's an update to cassandra, can we have one build command (in
cassandra-website) that updates just the versioned docs (/docs//)
contents on the asf-staging branch?
More information on how the docs get published is in
- https://infra.apache.org/project-site.html
-
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-Specifyingasub-directorytopublishto
was (Author: michaelsembwever):
{quote}*I propose this (or this is what the intention may have been all along)*
* build process for cassandra
** uses docs/dockerfile as needed on releases to include in release
** uses docs/dockerfile as needed on releases to publish only /docs/ section of
the site ( separate public path to push docs content to)
* build process for cassandra-website
** uses /dockerfile as needed on publish blog/ etc. to / section of the site (
separate public path to push site content to)
{quote}
Some questions [~xingh],
bq. uses docs/dockerfile as needed on releases to publish only /docs/
Only one website can serve the contents. A build action in the
cassadra-repository would then have to push commit (on the asf-staging branch)
into the cassandra-website repository?
bq. uses docs/dockerfile as needed on releases to include in release
It would be nice to have better bundled docs. But keep in mind that the Antora
has an incompatible license and none of its files (original or modified) can be
put into a C* release artefact.
It would be nice avoiding cross-repository dependencies.
For the releases, can the in-tree asciidocs be built without antora and solely
in-tree? This would solve bundling the docs into the release and simplify the
release process (by not being dependent on the cassandra-website repository).
If this is not possible I suggest we remove all docs from the release bundles
(like it is today).
For the website staging updates…
- when there's an update to cassandra-website, can we have one build command to
update just its contents on the asf-staging branch?
- when there's an update to cassandra, can we have one build command (in
cassandra-website) that updates just the versioned docs (/docs//)
contents on the asf-staging branch?
More information on how the docs get published is in
- https://infra.apache.org/project-site.html
-
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-Specifyingasub-directorytopublishto
> Update and rework cassandra-website material to work with Antora
>
>
> Key: CASSANDRA-16066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16066
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Anthony Grasso
>Priority: Normal
>
> *We want to modernise the way the website is built*
> Rework the cassandra-website repository to generate a UI bundle containing
>
[jira] [Comment Edited] (CASSANDRA-16066) Update and rework cassandra-website material to work with Antora
[
https://issues.apache.org/jira/browse/CASSANDRA-16066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191016#comment-17191016
]
Michael Semb Wever edited comment on CASSANDRA-16066 at 9/5/20, 9:07 AM:
-
{quote}*I propose this (or this is what the intention may have been all along)*
* build process for cassandra
** uses docs/dockerfile as needed on releases to include in release
** uses docs/dockerfile as needed on releases to publish only /docs/ section of
the site ( separate public path to push docs content to)
* build process for cassandra-website
** uses /dockerfile as needed on publish blog/ etc. to / section of the site (
separate public path to push site content to)
{quote}
Some questions [~xingh],
bq. uses docs/dockerfile as needed on releases to publish only /docs/
Only one website can serve the contents. A build action in the
cassadra-repository would then have to push commit (on the asf-staging branch)
into the cassandra-website repository. Is that desired, can we come up with a
simpler approach?
bq. uses docs/dockerfile as needed on releases to include in release
It would be nice to have better bundled docs. But keep in mind that the Antora
has an incompatible license and none of its files (original or modified) can be
put into a C* release artefact.
.
It would be nice avoiding cross-repository dependencies.
For the releases, can the in-tree asciidocs be built without antora and solely
in-tree? This would solve bundling the docs into the release and simplify the
release process (by not being dependent on the cassandra-website repository).
If this is not possible I suggest we remove all docs from the release bundles
(like it is today).
For the website staging updates…
- when there's an update to cassandra-website, can we have one build command to
update just its contents on the asf-staging branch?
- when there's an update to cassandra, can we have one build command (in
cassandra-website) that updates just the versioned docs (/docs//)
contents on the asf-staging branch?
More information on how the docs get published is in
- https://infra.apache.org/project-site.html
-
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-Specifyingasub-directorytopublishto
was (Author: michaelsembwever):
{quote}*I propose this (or this is what the intention may have been all along)*
* build process for cassandra
** uses docs/dockerfile as needed on releases to include in release
** uses docs/dockerfile as needed on releases to publish only /docs/ section of
the site ( separate public path to push docs content to)
* build process for cassandra-website
** uses /dockerfile as needed on publish blog/ etc. to / section of the site (
separate public path to push site content to)
{quote}
Some questions [~xingh],
bq. uses docs/dockerfile as needed on releases to publish only /docs/
Only one website can serve the contents. A build action in the
cassadra-repository would then have to push commit (on the asf-staging branch)
into the cassandra-website repository. Is that desired, can we come up with a
simpler approach?
bq. uses docs/dockerfile as needed on releases to include in release
It would be nice to have better bundled docs. But keep in mind that the Antora
has an incompatible license and none of its files (original or modified) can be
put into a C* release artefact.
It would be nice avoiding cross-repository dependencies.
For the releases, can the in-tree asciidocs be built without antora and solely
in-tree? This would solve bundling the docs into the release and simplify the
release process (by not being dependent on the cassandra-website repository).
If this is not possible I suggest we remove all docs from the release bundles
(like it is today).
For the website staging updates…
- when there's an update to cassandra-website, can we have one build command to
update just its contents on the asf-staging branch?
- when there's an update to cassandra, can we have one build command (in
cassandra-website) that updates just the versioned docs (/docs//)
contents on the asf-staging branch?
More information on how the docs get published is in
- https://infra.apache.org/project-site.html
-
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-Specifyingasub-directorytopublishto
> Update and rework cassandra-website material to work with Antora
>
>
> Key: CASSANDRA-16066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16066
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Anthony Grasso
>Priority: Normal
>
> *We want to modernise the way the website is built*
> Rework the
[jira] [Comment Edited] (CASSANDRA-16066) Update and rework cassandra-website material to work with Antora
[
https://issues.apache.org/jira/browse/CASSANDRA-16066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191016#comment-17191016
]
Michael Semb Wever edited comment on CASSANDRA-16066 at 9/5/20, 9:06 AM:
-
{quote}*I propose this (or this is what the intention may have been all along)*
* build process for cassandra
** uses docs/dockerfile as needed on releases to include in release
** uses docs/dockerfile as needed on releases to publish only /docs/ section of
the site ( separate public path to push docs content to)
* build process for cassandra-website
** uses /dockerfile as needed on publish blog/ etc. to / section of the site (
separate public path to push site content to)
{quote}
Some questions [~xingh],
bq. uses docs/dockerfile as needed on releases to publish only /docs/
Only one website can serve the contents. A build action in the
cassadra-repository would then have to push commit (on the asf-staging branch)
into the cassandra-website repository?
bq. uses docs/dockerfile as needed on releases to include in release
It would be nice to have better bundled docs. But keep in mind that the Antora
has an incompatible license and none of its files (original or modified) can be
put into a C* release artefact.
It would be nice avoiding cross-repository dependencies.
For the releases, can the in-tree asciidocs be built without antora and solely
in-tree? This would solve bundling the docs into the release and simplify the
release process (by not being dependent on the cassandra-website repository).
If this is not possible I suggest we remove all docs from the release bundles
(like it is today).
For the website staging updates…
- when there's an update to cassandra-website, can we have one build command to
update just its contents on the asf-staging branch?
- when there's an update to cassandra, can we have one build command (in
cassandra-website) that updates just the versioned docs (/docs//)
contents on the asf-staging branch?
More information on how the docs get published is in
- https://infra.apache.org/project-site.html
-
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-Specifyingasub-directorytopublishto
was (Author: michaelsembwever):
{quote}*I propose this (or this is what the intention may have been all along)*
* build process for cassandra
** uses docs/dockerfile as needed on releases to include in release
** uses docs/dockerfile as needed on releases to publish only /docs/ section of
the site ( separate public path to push docs content to)
* build process for cassandra-website
** uses /dockerfile as needed on publish blog/ etc. to / section of the site (
separate public path to push site content to)
{quote}
Some questions.
bq. uses docs/dockerfile as needed on releases to publish only /docs/
Only one website can serve the contents. A build action in the
cassadra-repository would then have to push commit (on the asf-staging branch)
into the cassandra-website repository?
bq. uses docs/dockerfile as needed on releases to include in release
It would be nice to have better bundled docs. But keep in mind that the Antora
has an incompatible license and none of its files (original or modified) can be
put into a C* release artefact.
It would be nice avoiding cross-repository dependencies.
For the releases, can the in-tree asciidocs be built without antora and solely
in-tree? This would solve bundling the docs into the release and simplify the
release process (by not being dependent on the cassandra-website repository).
If this is not possible I suggest we remove all docs from the release bundles
(like it is today).
For the website staging updates…
- when there's an update to cassandra-website, can we have one build command to
update just its contents on the asf-staging branch?
- when there's an update to cassandra, can we have one build command (in
cassandra-website) that updates just the versioned docs (/docs//)
contents on the asf-staging branch?
More information on how the docs get published is in
- https://infra.apache.org/project-site.html
-
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-Specifyingasub-directorytopublishto
> Update and rework cassandra-website material to work with Antora
>
>
> Key: CASSANDRA-16066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16066
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Anthony Grasso
>Priority: Normal
>
> *We want to modernise the way the website is built*
> Rework the cassandra-website repository to generate a UI bundle containing
> resources that Antora will use when generating the Cassandra documents
[jira] [Commented] (CASSANDRA-16066) Update and rework cassandra-website material to work with Antora
[
https://issues.apache.org/jira/browse/CASSANDRA-16066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191016#comment-17191016
]
Michael Semb Wever commented on CASSANDRA-16066:
{quote}*I propose this (or this is what the intention may have been all along)*
* build process for cassandra
** uses docs/dockerfile as needed on releases to include in release
** uses docs/dockerfile as needed on releases to publish only /docs/ section of
the site ( separate public path to push docs content to)
* build process for cassandra-website
** uses /dockerfile as needed on publish blog/ etc. to / section of the site (
separate public path to push site content to)
{quote}
Some questions.
bq. uses docs/dockerfile as needed on releases to publish only /docs/
Only one website can serve the contents. A build action in the
cassadra-repository would then have to push commit (on the asf-staging branch)
into the cassandra-website repository?
bq. uses docs/dockerfile as needed on releases to include in release
It would be nice to have better bundled docs. But keep in mind that the Antora
has an incompatible license and none of its files (original or modified) can be
put into a C* release artefact.
It would be nice avoiding cross-repository dependencies.
For the releases, can the in-tree asciidocs be built without antora and solely
in-tree? This would solve bundling the docs into the release and simplify the
release process (by not being dependent on the cassandra-website repository).
If this is not possible I suggest we remove all docs from the release bundles
(like it is today).
For the website staging updates…
- when there's an update to cassandra-website, can we have one build command to
update just its contents on the asf-staging branch?
- when there's an update to cassandra, can we have one build command (in
cassandra-website) that updates just the versioned docs (/docs//)
contents on the asf-staging branch?
More information on how the docs get published is in
- https://infra.apache.org/project-site.html
-
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-Specifyingasub-directorytopublishto
> Update and rework cassandra-website material to work with Antora
>
>
> Key: CASSANDRA-16066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16066
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Anthony Grasso
>Priority: Normal
>
> *We want to modernise the way the website is built*
> Rework the cassandra-website repository to generate a UI bundle containing
> resources that Antora will use when generating the Cassandra documents and
> website.
> *The existing method is starting to become dated*
> The documentation and website templates are currently in markdown format.
> Sphinx is used to generate the Cassandra documentation and Jekyll generates
> the website content. One of the major issues with the existing website
> tooling is that the live preview server (render site as it is being updated)
> is really slow. There is a preview server that is really fast, however it is
> unable to detect changes to the content and render automatically.
> *We are migrating the docs to be rendered with Antora*
> The work in CASSANDRA-16029 is converting the document templates to AsciiDoc
> format. Sphinx is being replaced by Antora to generate the documentation
> content. This change has two advantages:
> * More flexibility if the Apache Cassandra documentation look and feel needs
> to be updated or redesigned.
> * More modern look and feel to the documentation.
> *We can use Antora to generate the website as well*
> Antora could also be used to generate the Cassandra website content. As
> suggested on the [mailing
> list|https://www.mail-archive.com/dev@cassandra.apache.org/msg15577.html]
> this would require the existing markdown templates to be converted to
> AsciiDoc as well.
> *Antora needs a UI bundle to style content*
> For Antora to generate the document content and potentially the website
> content it requires a UI bundle (ui-bundle.zip). The UI bundle contains the
> HTML templates (layouts, partials, and helpers), CSS, JavaScript, fonts, and
> (site-wide) images. As such, it provides both the visual theme and user
> interactions for the documentation. Effectively the UI bundle is the
> templates and styling that are applied to the documentation and website
> content.
> *The [cassandra-website|https://github.com/apache/cassandra-website]
> repository can be used to generate the UI bundle*
> All the resources associated with templating and styling the documentation
> and website can be placed in the
> [cassandra-website|https://github.com/apache/cassandra-website]
