You might look at apache commons, it has a number of sub projects that are not on the same version. They have probably solved this problem.
If we have a VM then we can use rsync, or some other process to build the site and push the site. The VM gives us a fuller control over the hosting configuration. On Thu, Apr 27, 2023 at 1:50 PM Johannes Rudolph <[email protected]> wrote: > I removed the static docs/api/japi folder from the staging branch > here: > https://github.com/apache/incubator-pekko-site/tree/asf-staging/content > > The redirection still seems to work. > > Johannes > > On Wed, Apr 26, 2023 at 7:07 PM PJ Fanning <[email protected]> wrote: > > > > I'm happy if we can get a .htaccess setup working. pekko.apache.org > > can have just the home page and some pages like the download page > > while all other pages are redirected to nightlies.apache.org. > > > > Would it be possible to remove all the pekko core docs (and api/japi) > > for pekko.staged.apache.org to see how this all works? > > > > On Wed, 26 Apr 2023 at 15:19, Johannes Rudolph > > <[email protected]> wrote: > > > > > > For testing purposes I added an .htaccess file to the staging version > > > of the website to transparently proxy requests to the documentation > > > and javadoc/scaladoc direclty to nightlies. Seems to work well enough > > > for now so we might be able to postpone setting up more website > > > infrastructure to a later point if necessary. > > > > > > E.g. > > > > > > > https://pekko.staged.apache.org/docs/pekko-http/snapshot/common/marshalling.html > > > > https://pekko.staged.apache.org/docs/pekko/snapshot/typed/guide/tutorial_2.html > > > > > > > https://pekko.staged.apache.org/api/pekko/snapshot/org/apache/pekko/persistence/DeleteSnapshotsFailure.html > > > > https://pekko.staged.apache.org/japi/pekko-http/snapshot/org/apache/pekko/http/scaladsl/model/headers/Access$minusControl$minusExpose$minusHeaders$.html > > > > > > See https://github.com/apache/incubator-pekko-site/issues/6. > > > > > > Johannes > > > > > > On Mon, Apr 24, 2023 at 12:10 PM Johannes Rudolph > > > <[email protected]> wrote: > > > > > > > > Hi PJ, > > > > > > > > it's not completely clear to me why we need a VM to implement either > a > > > > push or pull based solution to host the website. > > > > > > > > For a potential push based solution to the standard git-based setup I > > > > already posted a script somewhere that would do the necessary steps. > > > > > > > > For a pull based solution (i.e. have some form of definition which > > > > versions of documentation we want to show at some place), we could > > > > also write a script which pulls together all parts (e.g. from the > > > > nightlies server) and commits them to the git repository. > > > > > > > > A VM to host a static or documentation is not super advanced, but > it's > > > > also much more complicated than uploading files to git and having all > > > > the hosting infrastructure maintained from someone else. > > > > > > > > Having the VM build all the documentation does not seem the right > > > > solution for me for various reasons: > > > > * when should the VM start building anything? > > > > * documentation building (Scaladoc, in particular) is the slowest > > > > part of the whole build process, so we will have to optimize to avoid > > > > rebuilding documentation we already have covered > > > > > > > > The only reason I can see why a VM could be useful would be to setup > > > > proper proxying (instead of redirecting) of documentation from > > > > nightlies to the main page if that's what we are looking for. > > > > > > > > Johannes > > > > > > > > > > > > On Sun, Apr 23, 2023 at 6:08 PM Matthew Benedict de Detrich > > > > <[email protected]> wrote: > > > > > > > > > > > I raised an INFRA JIRA [1] in the hope that we could get a rsync > server > > > > > that we could use to deploy the pekko.apache.org web site. They > have > > > > > suggested instead that many ASF teams have their own VMs that they > use to > > > > > host their web sites. > > > > > > > > > > I think this answer reflects the fact that most Apache projects > act as a > > > > > mono repo whereas Pekko is quite unique in that we have a multi > repo setup. > > > > > If you have a mono repo setup then a VM can definitely make sense > but the > > > > > reason why I was suggesting rsync is that it greatly trivializes > our setup > > > > > when it comes to docs, i.e. every for every pekko git repo > > > > > > > > > > * For merge on PR we can rsync the docs onto nightlies > > > > > * For actual release we just rsync the docs onto the main central > location > > > > > that hosts the site > > > > > > > > > > One of the other reasons behind the trivialization is that its > granular, > > > > > i.e. we can have different release cycles with the different pekko > git > > > > > repos and they can each rsync to the VM on their own accord when a > release > > > > > is made. > > > > > > > > > > > If we have a VM, we could git pull on all our repos and have a > script > > > > > that builds all the paradox docs, scaladoc and javadoc and copies > the > > > > > results to a dir structure that Apache HTTP Server or some similar > app > > > > > serves as a web site. We could get the INFRA team to set up a > CNAME mapping > > > > > for this. > > > > > > > > > > > Is this approach ok? If anyone has any alternative suggestions, > please > > > > > keep in mind that we need to work with ASF INFRA and other ASF > teams and > > > > > need solutions that work with what those other teams can > facilitate. > > > > > > > > > > Unless I am missing something, if we have setup our own VM what is > actually > > > > > preventing us from rsyncing to that VM as part of our process > rather than > > > > > having to deal with making a custom setup of pulling every > necessary git > > > > > repo? If this kind of flow is is a hardline, sbt has a less well > known but > > > > > incredibly useful feature in that it supports dynamic projects > based on git > > > > > uri, i.e. > > > > > > https://alvinalexander.com/scala/using-github-projects-scala-library-dependencies-sbt-sbteclipse/ > > > > > . In other words, we can create a master sbt build that references > every > > > > > other pekko git repo by its actual git uri as well as handling > pulling, i.e. > > > > > > > > > > lazy val core = ProjectRef(uri("[email protected]: > apache/incubator-pekko.git"), > > > > > "pekko") > > > > > lazy val http = > > > > > ProjectRef(uri("[email protected]:apache/incubator-pekko-http.git"), > > > > > "pekko-http") > > > > > ... > > > > > > > > > > And then since you can represent each project as a value > referenced by its > > > > > git repo you can just do http/docs/paradox and it will generate > the docs > > > > > from that git [email protected]:apache/incubator-pekko-http.git > repo. We still > > > > > have the issue that we need to make sure we clone the projects at > the > > > > > correct hash that points to the release (which is yet another > reason why I > > > > > like the rsync setup because it can be done at the same time an > actual > > > > > release is being made). > > > > > > > > > > I still do however take the point you made earlier in that we > shouldn't > > > > > over engineer the docs setup because it's strictly not necessarily > needed > > > > > for release and we have a lot of other pressing issues but the main > > > > > takeaway that I want to drive home is that our setup with Pekko is > not like > > > > > other Apache projects and this is why I am trying to encourage > processes > > > > > that work best with the setup we have at hand (which is multi > module git > > > > > setup). For that reason I am perfectly happy with having a more > manual > > > > > solution and we can suspend doing a more proper solution when > timing is > > > > > more appropriate > > > > > > > > > > On Fri, Apr 21, 2023 at 4:54 PM PJ Fanning <[email protected]> > wrote: > > > > > > > > > > > Hi everyone. > > > > > > > > > > > > I raised an INFRA JIRA [1] in the hope that we could get a rsync > server > > > > > > that we could use to deploy the pekko.apache.org web site. They > have > > > > > > suggested instead that many ASF teams have their own VMs that > they use to > > > > > > host their web sites. > > > > > > > > > > > > If we have a VM, we could git pull on all our repos and have a > script that > > > > > > builds all the paradox docs, scaladoc and javadoc and copies the > results to > > > > > > a dir structure that Apache HTTP Server or some similar app > serves as a web > > > > > > site. We could get the INFRA team to set up a CNAME mapping for > this. > > > > > > > > > > > > We could keep the script(s) that build the web site in git for > safety - > > > > > > allowing us to rebuild the VM easily if we lose the pre-existing > VM. > > > > > > > > > > > > Is this approach ok? If anyone has any alternative suggestions, > please > > > > > > keep in mind that we need to work with ASF INFRA and other ASF > teams and > > > > > > need solutions that work with what those other teams can > facilitate. > > > > > > > > > > > > Regards, > > > > > > PJ > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/INFRA-24453 > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Matthew de Detrich > > > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > > > *m:* +491603708037 > > > > > > > > > > *w:* aiven.io *e:* [email protected] > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
