gemmellr commented on code in PR #158:
URL: https://github.com/apache/artemis-console/pull/158#discussion_r2712573980
##########
pom.xml:
##########
@@ -126,6 +127,23 @@
</execution>
</executions>
</plugin>
+ <plugin>
+ <groupId>org.commonjava.maven.plugins</groupId>
+ <artifactId>directory-maven-plugin</artifactId>
+ <version>1.0</version>
+ <executions>
+ <execution>
+ <id>directories</id>
+ <goals>
+ <goal>highest-basedir</goal>
+ </goals>
+ <phase>initialize</phase>
+ <configuration>
+ <property>root.basedir</property>
+ </configuration>
+ </execution>
+ </executions>
+ </plugin>
Review Comment:
Looking at the plugin repo it seems to be dead, with issues and PR reported
3 years ago and either not merged or not release, and people noting they have
forked it. I dont think we need a plugin execution just for what this is doing
(we could use a path relative to other known props like the builddir or pom
root dir), but I'd be reluctant to start using this one either way. I believe
Maven 4 has some new props around this kind of thing too, so if goign for a
simple prop I expect we can tidy it up more when we start using that.
(Would have otherwise said, plugin version should be managed or at least a
property)
##########
artemis-console-website/pom.xml:
##########
@@ -0,0 +1,103 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<project xmlns="http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
+ <modelVersion>4.0.0</modelVersion>
+
+ <parent>
+ <groupId>org.apache.artemis</groupId>
+ <artifactId>artemis-console-project</artifactId>
+ <version>1.6.0-SNAPSHOT</version>
+ </parent>
+
+ <artifactId>artemis-console-website</artifactId>
+ <packaging>jar</packaging>
+ <name>Apache Artemis Console Website</name>
+
+ <properties>
+ <!-- we need a "scratch" directory because we dynamically generate a few
docs -->
+
<scratch-dir-user-manual>${project.build.directory}/scratch/user-manual</scratch-dir-user-manual>
Review Comment:
Is this being used?
##########
Releasing.md:
##########
@@ -179,20 +178,21 @@ Once the CDN and Maven Central are up-to-date then update
the site as follows:
1. Run the release addition script to generate/perform most of the updates by
running command of form:
```
-./scripts/release/add-artemis-console-release.sh <new-version>
+./scripts/release/add-artemis-console-release.sh <path.to>/artemis-console
<previous-version> <new-version>
```
This does the following:
- Creates the new release collection file at
`src/_artemis_console_releases/artemis-console-<padded-version-string>.md`.
- Creates the new release notes file at
`src/components/artemis-console/download/release-notes-<new-version>.md`.
+- Creates a new directory for the documentation at
`src/components/artemis-console/documentation/<new-version>` and copies the
documentation into it from the build directory.
+- Updates `.htaccess` file in `src/components/artemis-console/documentation`
to properly reference the "latest" docs.
Review Comment:
One of the main reasons the main artemis docs dont do 'latest' this way is
that it means you cant test the site (assuming it will link to 'latest' since
thats what we want people to use) without deploying it as the htaccess rules
arent in force in the local Jekyll serve. (The artemis docs also dont use a
symlink to similar effect, because the watcher cant discern this and then
complains a lot about the duplicate-watching of the same files for changes).
There is also the thing of it needing to be a 'temporary' redirect since it
will be updated every release so browsers need to forget the redirect.
Another consequence of this approach is that you cant easily see the changes
applied to the docs on the site between versions because the entire set is
always new files. I think the history of change is useful, and have previously
noticed unexpected issues from that. I think its a benefit worth retaining.
A middle ground rather than the htaccess magic would be to retain the
actual-directory for 'latest' docs and update it as we go, but also create the
versioned directory at the same time during release, rather than at the next
release like with the main artemis docs. Though the downside of that is it
means any post-release tweaks should be applied in 2 places. Probably not as
much of a concern for the console as the broker etc as it changes less. Though
that said, I do think we should make these changes post-release for 1.5.0 on
the site.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
