You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Georg Kallidis <ge...@cedis.fu-berlin.de> on 2021/08/06 11:20:37 UTC
[DISCUSS] Migrate SVN Repos to Git, How to Migrate Site Building + Publishing
Hi Turbine Dev community,
We have to decide a couple of infrastructure changes, find more
information here
https://issues.apache.org/jira/browse/INFRA-22176?focusedCommentId=17394620&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17394620
where a put some questions, which we my have to answer.
After the discussion is at some point, I (or volunteer) would summarize it
and write it out in votable question(s).
1) Move Turbine /Fulcrum to Git (native) as already
https://github.com/apache/turbine-archetypes)
This step seems to be entirely independent from the main question of how
to publish our site. We very well could postpone it, but would be more
consistent of course and more welcoming (i.e. allow pull requests, but no
low level issue discussion, as this is disabled for apache projects, but
instead forwarding to mailing list should be done).
We already have this in read only (git mirror of svn):
https://github.com/apache/turbine-fulcrum
https://github.com/apache/turbine-core
We could just inform INFRA we want them as writeable and ask for help to
achieve this.
More detailed discussion: What's missing is
- turbine/maven with parent/assembly/archetype. Archetype is already
migrated to a git repo.
- turbine/site (wrapper site). Like fulcrum/fulcrum-site this is the
wrapper site for Turbine, as the latter is for Fulcrum components.
- fulcrum/site may bebetter a separate repo, as a sobproject of the
published web site could be declared in .asf.yaml (see below), but we have
to populate a branch asf-site with just the output of fulcrum-site - might
be possible, but probably without having done this yet (no template).
Should we get a git-repo for each of those? This is not required for
changing our site-building (except turbine/site and fulcrum/site).
Proposal: Migrate first turbine/site and then in parallel with site
migration (help of INFRA needed) migrate svn-repositories turbine-fulcrum
and turbine-core to read-write Git-repos (may be without fulcrum-site (see
below) and migrate svn-repo turbine/maven without turbine-archetype to a
new GIT-repository turbine-maven?
2) How to Build site
2.1) How to structure our project web site content? We currently have a
very delegated site content generation. Each sub project has its own site
and we have two "site-wrappers" for Turbine and Fulcrum.
That is, we have these partials:
- turbine-core (with staging/development and master/trunk)
- turbine-site (wrapper for /turbine)
- fulcrum-site (wrapper /fulcrum)
- 17 active Fulcrum components
- 9 dormant Fulcrum components
- turbine-parent ..
.. ?
Currently we could build all parts separately and the site is updated
accordingly and partially. This is not an easy and very much used feature
in the new project site building process as far as I can see.
We may proceed like Apache James. Keep the project site buildings and
"hide" it all behind a wrapper, in their case a Jekyll SPA like landing
page. But they use a people account for deplyoment not an git repo
(asf-site) and may not be finished with their migration.
This boils down to use at least turbine/site as asf-site and fulcrum/site
the same.
Proposal: Contact Infra, migrate turbine/site to Git (separate repo),
extract fulcrum/site to separate git-repo or keep it, if possible and
declare there the asf-site branches. Then either use one of the solutions
in 3).
2.2) We might keep the xdoc build or change to Jekyll (Hugo ..) - ?
3) How to publish project web site
https://infra.apache.org/project-site.html
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features
If we have a structure for our web content building, there are two
options: 1) asf-site branch + jenkins or 2) .asf.yaml for git repos.
Best regards, Georg
Re: [DISCUSS] Migrate SVN Repos to Git, How to Migrate Site Building + Publishing
Posted by Georg Kallidis <ge...@cedis.fu-berlin.de>.
to complete with some final thoughts:
We may add for each of our partials an asf-site branch and deploy them
like
publish:
whoami: asf-site
subdir: turbine
e.g. for turbine-core and turbine-site. This might be done for all
separate git repositories, but Fulcrum is currently merged into one:
https://github.com/apache/turbine-fulcrum.
Intead of using a Jenkins build we might use the Jekyll CMS to deploy as
mentioned here
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features
because Infra supports Jekyll buildbots
https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS
(.. output the generated files into a _site folder )
(although some information seems to be already outdated or not yet
updated)
and Maven site and Jekyll seems to be mergable (this "plugin" has to be
updated and tested)
https://github.com/salmon-charles/maven-jekyll-skin
As a result we may build it this way, with Github Actions/Workflows
https://docs.github.com/en/actions/quickstart
(instead of Jenkins)..
GitHub workflows seem to be quite powerful, event triggered, e.g. on
release, I found this example with jekyll, which publishes to branch
asf-site
https://github.com/apache/arrow-site/blob/master/.github/workflows/deploy.yml
. The problem is, only a single asf-site branch could exist per
repository.
As a result we may split the tasks and proceed to resolve publishing
Turbine related partials and postpone Fulcrum.
Except we follow Thomas' suggestion, that we split each Fulcrum component
into its own Git repository!
Best regards, Georg
Von: "Georg Kallidis" <ge...@cedis.fu-berlin.de>
An: "Turbine Developers List" <de...@turbine.apache.org>
Datum: 06.08.2021 13:21
Betreff: [DISCUSS] Migrate SVN Repos to Git, How to Migrate Site
Building + Publishing
Hi Turbine Dev community,
We have to decide a couple of infrastructure changes, find more
information here
https://issues.apache.org/jira/browse/INFRA-22176?focusedCommentId=17394620&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17394620
where a put some questions, which we my have to answer.
After the discussion is at some point, I (or volunteer) would summarize it
and write it out in votable question(s).
1) Move Turbine /Fulcrum to Git (native) as already
https://github.com/apache/turbine-archetypes)
This step seems to be entirely independent from the main question of how
to publish our site. We very well could postpone it, but would be more
consistent of course and more welcoming (i.e. allow pull requests, but no
low level issue discussion, as this is disabled for apache projects, but
instead forwarding to mailing list should be done).
We already have this in read only (git mirror of svn):
https://github.com/apache/turbine-fulcrum
https://github.com/apache/turbine-core
We could just inform INFRA we want them as writeable and ask for help to
achieve this.
More detailed discussion: What's missing is
- turbine/maven with parent/assembly/archetype. Archetype is already
migrated to a git repo.
- turbine/site (wrapper site). Like fulcrum/fulcrum-site this is the
wrapper site for Turbine, as the latter is for Fulcrum components.
- fulcrum/site may bebetter a separate repo, as a sobproject of the
published web site could be declared in .asf.yaml (see below), but we have
to populate a branch asf-site with just the output of fulcrum-site - might
be possible, but probably without having done this yet (no template).
Should we get a git-repo for each of those? This is not required for
changing our site-building (except turbine/site and fulcrum/site).
Proposal: Migrate first turbine/site and then in parallel with site
migration (help of INFRA needed) migrate svn-repositories turbine-fulcrum
and turbine-core to read-write Git-repos (may be without fulcrum-site (see
below) and migrate svn-repo turbine/maven without turbine-archetype to a
new GIT-repository turbine-maven?
2) How to Build site
2.1) How to structure our project web site content? We currently have a
very delegated site content generation. Each sub project has its own site
and we have two "site-wrappers" for Turbine and Fulcrum.
That is, we have these partials:
- turbine-core (with staging/development and master/trunk)
- turbine-site (wrapper for /turbine)
- fulcrum-site (wrapper /fulcrum)
- 17 active Fulcrum components
- 9 dormant Fulcrum components
- turbine-parent ..
.. ?
Currently we could build all parts separately and the site is updated
accordingly and partially. This is not an easy and very much used feature
in the new project site building process as far as I can see.
We may proceed like Apache James. Keep the project site buildings and
"hide" it all behind a wrapper, in their case a Jekyll SPA like landing
page. But they use a people account for deplyoment not an git repo
(asf-site) and may not be finished with their migration.
This boils down to use at least turbine/site as asf-site and fulcrum/site
the same.
Proposal: Contact Infra, migrate turbine/site to Git (separate repo),
extract fulcrum/site to separate git-repo or keep it, if possible and
declare there the asf-site branches. Then either use one of the solutions
in 3).
2.2) We might keep the xdoc build or change to Jekyll (Hugo ..) - ?
3) How to publish project web site
https://infra.apache.org/project-site.html
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features
If we have a structure for our web content building, there are two
options: 1) asf-site branch + jenkins or 2) .asf.yaml for git repos.
Best regards, Georg
[RESULT][VOTE] Migrate SVN Repos to Git, How to Migrate Site Building + Publishing
Posted by Georg Kallidis <ge...@cedis.fu-berlin.de>.
Thanks, Jeffery, Thomas!
I would summarize the result as follows:
We
1) move our SVN repos to Git. Turbine SVNs as is (almost), Fulcrum as well
using different repos (I follow Thomas' argument, git is not svn), but
remove some components to the attic / archive or declare it dormant (as
Apache Commons components currently inactive): Check list below *. I would
suggest to clean up this as much as possible, before moving. Currently I
count 20 fulcrum (including site, and excluding all in the list below)
2) release Turbine Core later after this is done ASAP.
3) use whatever is appropriate and supported by INFRA to publish our
website, may it be Github tooling, Jenkins or what else. I am not sure, if
we could follow Github tooling to the end ..
I'll start with the process in INFRA-22176, see below as soon as
possible..
@Thomas, thanks for helping out later with git modules, which may be not
required, if we actually move/set up a separate repo "master build" (eg. a
repo fulcrum-build from trunk/pom.xml +xdocs), as you suggested.
Fulcrum-parent may be also an archive candidate, as I can't find any
usages anywhere (?).
If you think anything's missing here/wrong or have another idea, please
don't hesitate ..
Thanks so far!
Best regards, Georg
* Searching
https://lists.apache.org/list.html?dev@turbine.apache.org:lte=3y:attic I
found this list of candidates to archive:
(
https://lists.apache.org/thread.html/50d1e77fb93dd290803347a5bfff00ccc1709ef31d3e59fb64d361cd%40%3Cdev.turbine.apache.org%3E
:
commonsemail
configuration/impl
hsqldb
pbe
naming
resourcemanager
groovy
script
spring
xmlrpc
xslt
+ jetty has a comment in master pom "needs upgrade to eclipse jetty",
but may be as well archived?
+ bsf, osworkflow, dvsl, parent -
Is this appropriate or should be more/less removed? To archive means IMO:
Keep it in svn and do not migrate it to git; declare it like this.
Von: Thomas Vandahl <tv...@apache.org>
An: Turbine Developers List <de...@turbine.apache.org>
Datum: 15.08.2021 11:52
Betreff: Re: [VOTE] Migrate SVN Repos to Git, How to Migrate Site
Building + Publishing
+1
See comments below.
> Am 12.08.2021 um 10:23 schrieb Georg Kallidis
<ge...@cedis.fu-berlin.de>:
>
> Hi Turbine Devs,
>
> I propose this as a vote, which allows us to get an overview of what we
> want to do or have to do, the workload, and how to communicate with
INFRA.
>
> SVN->Git
>
> (1.1) Move Turbine-core and Turbine-site from SVN to Git as detailed
> below. Turbine-Core is currently mirrored only in GitHub/Gitbox.
>
> (1.2) Move Fulcrum components from SVN to Git. Fulcrum is currently
> mirrored only in GitHub.
> a) try to keep it in one git repo or if not possible split up. b) split
it
> up in any case. Find more information below!
I'm in favour of 1.2b because releases from GIT use signed tags and in the
future it would be difficult to know, which component release is meant by
which tag. My understanding of GIT is, that, if in doubt, use more repos.
> (1.3) Move Turbine Maven from SVN to Git as detailed below.
> Turbine-Archetypes is already a GIT repo.
>
> (2) Performing a Turbine-core release v5.1: As this might take some time
> depending on workload, should we release before the migration?
If the release is not needed urgently by anyone (which I assume), a
release after the migration might help to prove that everything works
again.
> We probably want still use the maven scm plugin to publish releases, but
> for building and publishing web content we have to change more (as it
> seems):
>
> (3) For each Git repo with a maven-site-configuration to build and
publish
> web content, we should define either
> a) a Jenkins Build file(s) and/or b) a build directive within the
> .asf.yaml-file (supports jekyll and pelican) c) an instruction, how to
do
> it locally, similar how it is explained here [2], but with additional
> restrictions (see below .asf.yml file, web root folder). The last
> alternative might be too much effort. It might be possible to do this
> even for mirrored git-repos (we have to ask INFRA).
Whether I like it or not: I see a lot of movement into the direction of
Github tooling. Probably less maintenance, dunno. Shall we follow that
road?
> - Fulcrum components could be kept as currently in a single git repo or
> split up each into a separate git repo. As consistent the latter
approach
> would be I would prefer keeping them together (if possible, see below!).
> Reasons are: The master module pom will be "lost". This could be solved
> with git modules, but requires some additional effort and advanced git
> knowledge + documentation/testing IMO. Who will help? - Maintenance
effort
> increases (e.g. an update of a shared dependency has to be done in x (x=
> number of git repos) commits versus 1 commit, if we keep them as a
> collection also in version control. On the other side publishing has to
be
> discussed with INFRA and is not done out-of-the-box, see below. What do
> you prefer?
As stated above, I'm in favour for the one-component/one-repo solution.
The parent POM is just another module - similar to the Turbine parent POM.
If your concern is about local builds, it's just a matter of building the
parent first.
GIT modules are easy, I can help with that. I propose to create a separate
"master build" repo with a layout suitable for building everything at
once.
I also support Jeffs idea of an attic of Fulcrum components.
Bye, Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: [VOTE] Migrate SVN Repos to Git, How to Migrate Site Building +
Publishing
Posted by Thomas Vandahl <tv...@apache.org>.
+1
See comments below.
> Am 12.08.2021 um 10:23 schrieb Georg Kallidis <ge...@cedis.fu-berlin.de>:
>
> Hi Turbine Devs,
>
> I propose this as a vote, which allows us to get an overview of what we
> want to do or have to do, the workload, and how to communicate with INFRA.
>
> SVN->Git
>
> (1.1) Move Turbine-core and Turbine-site from SVN to Git as detailed
> below. Turbine-Core is currently mirrored only in GitHub/Gitbox.
>
> (1.2) Move Fulcrum components from SVN to Git. Fulcrum is currently
> mirrored only in GitHub.
> a) try to keep it in one git repo or if not possible split up. b) split it
> up in any case. Find more information below!
I'm in favour of 1.2b because releases from GIT use signed tags and in the future it would be difficult to know, which component release is meant by which tag. My understanding of GIT is, that, if in doubt, use more repos.
> (1.3) Move Turbine Maven from SVN to Git as detailed below.
> Turbine-Archetypes is already a GIT repo.
>
> (2) Performing a Turbine-core release v5.1: As this might take some time
> depending on workload, should we release before the migration?
If the release is not needed urgently by anyone (which I assume), a release after the migration might help to prove that everything works again.
> We probably want still use the maven scm plugin to publish releases, but
> for building and publishing web content we have to change more (as it
> seems):
>
> (3) For each Git repo with a maven-site-configuration to build and publish
> web content, we should define either
> a) a Jenkins Build file(s) and/or b) a build directive within the
> .asf.yaml-file (supports jekyll and pelican) c) an instruction, how to do
> it locally, similar how it is explained here [2], but with additional
> restrictions (see below .asf.yml file, web root folder). The last
> alternative might be too much effort. It might be possible to do this
> even for mirrored git-repos (we have to ask INFRA).
Whether I like it or not: I see a lot of movement into the direction of Github tooling. Probably less maintenance, dunno. Shall we follow that road?
> - Fulcrum components could be kept as currently in a single git repo or
> split up each into a separate git repo. As consistent the latter approach
> would be I would prefer keeping them together (if possible, see below!).
> Reasons are: The master module pom will be "lost". This could be solved
> with git modules, but requires some additional effort and advanced git
> knowledge + documentation/testing IMO. Who will help? - Maintenance effort
> increases (e.g. an update of a shared dependency has to be done in x (x=
> number of git repos) commits versus 1 commit, if we keep them as a
> collection also in version control. On the other side publishing has to be
> discussed with INFRA and is not done out-of-the-box, see below. What do
> you prefer?
As stated above, I'm in favour for the one-component/one-repo solution. The parent POM is just another module - similar to the Turbine parent POM.
If your concern is about local builds, it's just a matter of building the parent first.
GIT modules are easy, I can help with that. I propose to create a separate "master build" repo with a layout suitable for building everything at once.
I also support Jeffs idea of an attic of Fulcrum components.
Bye, Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: [VOTE] Migrate SVN Repos to Git, How to Migrate Site Building +
Publishing
Posted by Jeffery Painter <je...@jivecast.com>.
Hi Georg,
I will defer to you, so I will also endorse your recommendation.
[x] +1 support 1,2,3 > . , 1a > 1b
My only additional comment is can we move some of the fulcrum components that are no longer used to the attic at the same time and avoid moving those over to git? Might help avoid confusion down the road.
-
Jeff
On 8/12/21 4:23 AM, Georg Kallidis wrote:
> Hi Turbine Devs,
>
> I propose this as a vote, which allows us to get an overview of what we
> want to do or have to do, the workload, and how to communicate with INFRA.
>
> SVN->Git
>
> (1.1) Move Turbine-core and Turbine-site from SVN to Git as detailed
> below. Turbine-Core is currently mirrored only in GitHub/Gitbox.
>
> (1.2) Move Fulcrum components from SVN to Git. Fulcrum is currently
> mirrored only in GitHub.
> a) try to keep it in one git repo or if not possible split up. b) split it
> up in any case. Find more information below!
>
> (1.3) Move Turbine Maven from SVN to Git as detailed below.
> Turbine-Archetypes is already a GIT repo.
>
> (2) Performing a Turbine-core release v5.1: As this might take some time
> depending on workload, should we release before the migration?
>
> We probably want still use the maven scm plugin to publish releases, but
> for building and publishing web content we have to change more (as it
> seems):
>
> (3) For each Git repo with a maven-site-configuration to build and publish
> web content, we should define either
> a) a Jenkins Build file(s) and/or b) a build directive within the
> .asf.yaml-file (supports jekyll and pelican) c) an instruction, how to do
> it locally, similar how it is explained here [2], but with additional
> restrictions (see below .asf.yml file, web root folder). The last
> alternative might be too much effort. It might be possible to do this
> even for mirrored git-repos (we have to ask INFRA).
>
> We might vote like this:
>
> [ ] +1 support (optional with order): Example: 3,2,1 > 1,2,3 > 2,1,3 / 1a
>> 1b
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not ... , because
>
> Finally to achieve all of this correctly, we have to inform INFRA about
> our mappings and other required changes.
>
> - I expect Turbine-core and Turbine-site be migrated without much hassle
> and map easily to git from the current svn (the svn structure for
> turbine/core and turbine/site is the same).
> - Fulcrum components could be kept as currently in a single git repo or
> split up each into a separate git repo. As consistent the latter approach
> would be I would prefer keeping them together (if possible, see below!).
> Reasons are: The master module pom will be "lost". This could be solved
> with git modules, but requires some additional effort and advanced git
> knowledge + documentation/testing IMO. Who will help? - Maintenance effort
> increases (e.g. an update of a shared dependency has to be done in x (x=
> number of git repos) commits versus 1 commit, if we keep them as a
> collection also in version control. On the other side publishing has to be
> discussed with INFRA and is not done out-of-the-box, see below. What do
> you prefer?
> - Turbine-maven-parent and Parent-assembly might be split up (without
> archetypes) as well..
> The policy of INFRA on how a project should publish their web site seems
> to be now, that by default HTML will be fetched from an branch "asf-site"
> inside a git repository. Additionally an .asf.yml file must be present in
> this branch [1]. As Turbine is structured in such a way, that the website
> is build modularily, we would need then by default a git repo for each
> module. We may use "subdir" command in .asf.yaml and default root URL
> setting for turbine-site and fulcrum-site, if the latter will not destroy
> the tree contents below ;-). The content to be published (in the branch
> asf-site) has to be in the root or in a folder "content" or "output"[1].
> Building may take place using a Jenkins build file updating the asf-site
> branch or a buildbot-definition in .asf.yaml using Jekyll or Pelican hooks
> [1]. To keep Fulcrum components together, we might do it like Apache Jena
> achieved it to do it for their javadoc: Sync a named branch with the help
> of INFRA. Gavin McDonald pointed us to this:
> https://cwiki.apache.org/confluence/display/INFRA/How+Apache+Jena+migrated+from+the+CMS
> . In step 8 (optional) Jena created a branch javadoc, which maps to a
> subfolder in the website, https://github.com/apache/jena-site/tree/javadoc
> . We may proceed in a similar way for Fulcrum having only one git repo
> with multiple site branches?
>
> Nevertheless, be aware, that currently publishing a site could not be done
> and all steps require some effort! Any support is welcome, of course ;-)
>
> Thanks!
>
> Best regards, Georg
>
> [1]
> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features
> [2]
> https://maven.apache.org/plugins/maven-scm-publish-plugin/various-tips.html
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
[VOTE] Migrate SVN Repos to Git, How to Migrate Site Building + Publishing
Posted by Georg Kallidis <ge...@cedis.fu-berlin.de>.
Hi Turbine Devs,
I propose this as a vote, which allows us to get an overview of what we
want to do or have to do, the workload, and how to communicate with INFRA.
SVN->Git
(1.1) Move Turbine-core and Turbine-site from SVN to Git as detailed
below. Turbine-Core is currently mirrored only in GitHub/Gitbox.
(1.2) Move Fulcrum components from SVN to Git. Fulcrum is currently
mirrored only in GitHub.
a) try to keep it in one git repo or if not possible split up. b) split it
up in any case. Find more information below!
(1.3) Move Turbine Maven from SVN to Git as detailed below.
Turbine-Archetypes is already a GIT repo.
(2) Performing a Turbine-core release v5.1: As this might take some time
depending on workload, should we release before the migration?
We probably want still use the maven scm plugin to publish releases, but
for building and publishing web content we have to change more (as it
seems):
(3) For each Git repo with a maven-site-configuration to build and publish
web content, we should define either
a) a Jenkins Build file(s) and/or b) a build directive within the
.asf.yaml-file (supports jekyll and pelican) c) an instruction, how to do
it locally, similar how it is explained here [2], but with additional
restrictions (see below .asf.yml file, web root folder). The last
alternative might be too much effort. It might be possible to do this
even for mirrored git-repos (we have to ask INFRA).
We might vote like this:
[ ] +1 support (optional with order): Example: 3,2,1 > 1,2,3 > 2,1,3 / 1a
> 1b
[ ] +0 go ahead I don't care
[ ] -1 no, do not ... , because
Finally to achieve all of this correctly, we have to inform INFRA about
our mappings and other required changes.
- I expect Turbine-core and Turbine-site be migrated without much hassle
and map easily to git from the current svn (the svn structure for
turbine/core and turbine/site is the same).
- Fulcrum components could be kept as currently in a single git repo or
split up each into a separate git repo. As consistent the latter approach
would be I would prefer keeping them together (if possible, see below!).
Reasons are: The master module pom will be "lost". This could be solved
with git modules, but requires some additional effort and advanced git
knowledge + documentation/testing IMO. Who will help? - Maintenance effort
increases (e.g. an update of a shared dependency has to be done in x (x=
number of git repos) commits versus 1 commit, if we keep them as a
collection also in version control. On the other side publishing has to be
discussed with INFRA and is not done out-of-the-box, see below. What do
you prefer?
- Turbine-maven-parent and Parent-assembly might be split up (without
archetypes) as well..
The policy of INFRA on how a project should publish their web site seems
to be now, that by default HTML will be fetched from an branch "asf-site"
inside a git repository. Additionally an .asf.yml file must be present in
this branch [1]. As Turbine is structured in such a way, that the website
is build modularily, we would need then by default a git repo for each
module. We may use "subdir" command in .asf.yaml and default root URL
setting for turbine-site and fulcrum-site, if the latter will not destroy
the tree contents below ;-). The content to be published (in the branch
asf-site) has to be in the root or in a folder "content" or "output"[1].
Building may take place using a Jenkins build file updating the asf-site
branch or a buildbot-definition in .asf.yaml using Jekyll or Pelican hooks
[1]. To keep Fulcrum components together, we might do it like Apache Jena
achieved it to do it for their javadoc: Sync a named branch with the help
of INFRA. Gavin McDonald pointed us to this:
https://cwiki.apache.org/confluence/display/INFRA/How+Apache+Jena+migrated+from+the+CMS
. In step 8 (optional) Jena created a branch javadoc, which maps to a
subfolder in the website, https://github.com/apache/jena-site/tree/javadoc
. We may proceed in a similar way for Fulcrum having only one git repo
with multiple site branches?
Nevertheless, be aware, that currently publishing a site could not be done
and all steps require some effort! Any support is welcome, of course ;-)
Thanks!
Best regards, Georg
[1]
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features
[2]
https://maven.apache.org/plugins/maven-scm-publish-plugin/various-tips.html
Re: [VOTE] Migrate SVN Repos to Git, How to Migrate Site Building + Publishing
Posted by Georg Kallidis <ge...@cedis.fu-berlin.de>.
[x] +1 support 1,2,3 > . , 1a > 1b
Best regards, Georg
Von: Georg Kallidis/CeDiS/FU-Berlin/DE
An: Turbine <de...@turbine.apache.org>
Datum: 12.08.2021 10:23
Betreff: [VOTE] Migrate SVN Repos to Git, How to Migrate Site
Building + Publishing
Hi Turbine Devs,
I propose this as a vote, which allows us to get an overview of what we
want to do or have to do, the workload, and how to communicate with INFRA.
SVN->Git
(1.1) Move Turbine-core and Turbine-site from SVN to Git as detailed
below. Turbine-Core is currently mirrored only in GitHub/Gitbox.
(1.2) Move Fulcrum components from SVN to Git. Fulcrum is currently
mirrored only in GitHub.
a) try to keep it in one git repo or if not possible split up. b) split it
up in any case. Find more information below!
(1.3) Move Turbine Maven from SVN to Git as detailed below.
Turbine-Archetypes is already a GIT repo.
(2) Performing a Turbine-core release v5.1: As this might take some time
depending on workload, should we release before the migration?
We probably want still use the maven scm plugin to publish releases, but
for building and publishing web content we have to change more (as it
seems):
(3) For each Git repo with a maven-site-configuration to build and publish
web content, we should define either
a) a Jenkins Build file(s) and/or b) a build directive within the
.asf.yaml-file (supports jekyll and pelican) c) an instruction, how to do
it locally, similar how it is explained here [2], but with additional
restrictions (see below .asf.yml file, web root folder). The last
alternative might be too much effort. It might be possible to do this
even for mirrored git-repos (we have to ask INFRA).
We might vote like this:
[ ] +1 support (optional with order): Example: 3,2,1 > 1,2,3 > 2,1,3 / 1a
> 1b
[ ] +0 go ahead I don't care
[ ] -1 no, do not ... , because
Finally to achieve all of this correctly, we have to inform INFRA about
our mappings and other required changes.
- I expect Turbine-core and Turbine-site be migrated without much hassle
and map easily to git from the current svn (the svn structure for
turbine/core and turbine/site is the same).
- Fulcrum components could be kept as currently in a single git repo or
split up each into a separate git repo. As consistent the latter approach
would be I would prefer keeping them together (if possible, see below!).
Reasons are: The master module pom will be "lost". This could be solved
with git modules, but requires some additional effort and advanced git
knowledge + documentation/testing IMO. Who will help? - Maintenance effort
increases (e.g. an update of a shared dependency has to be done in x (x=
number of git repos) commits versus 1 commit, if we keep them as a
collection also in version control. On the other side publishing has to be
discussed with INFRA and is not done out-of-the-box, see below. What do
you prefer?
- Turbine-maven-parent and Parent-assembly might be split up (without
archetypes) as well..
The policy of INFRA on how a project should publish their web site seems
to be now, that by default HTML will be fetched from an branch "asf-site"
inside a git repository. Additionally an .asf.yml file must be present in
this branch [1]. As Turbine is structured in such a way, that the website
is build modularily, we would need then by default a git repo for each
module. We may use "subdir" command in .asf.yaml and default root URL
setting for turbine-site and fulcrum-site, if the latter will not destroy
the tree contents below ;-). The content to be published (in the branch
asf-site) has to be in the root or in a folder "content" or "output"[1].
Building may take place using a Jenkins build file updating the asf-site
branch or a buildbot-definition in .asf.yaml using Jekyll or Pelican hooks
[1]. To keep Fulcrum components together, we might do it like Apache Jena
achieved it to do it for their javadoc: Sync a named branch with the help
of INFRA. Gavin McDonald pointed us to this:
https://cwiki.apache.org/confluence/display/INFRA/How+Apache+Jena+migrated+from+the+CMS
. In step 8 (optional) Jena created a branch javadoc, which maps to a
subfolder in the website, https://github.com/apache/jena-site/tree/javadoc
. We may proceed in a similar way for Fulcrum having only one git repo
with multiple site branches?
Nevertheless, be aware, that currently publishing a site could not be done
and all steps require some effort! Any support is welcome, of course ;-)
Thanks!
Best regards, Georg
[1]
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features
[2]
https://maven.apache.org/plugins/maven-scm-publish-plugin/various-tips.html