Re: [VOTE] Release Apache Commons Codec 1.15 based on RC1

[Bruno P. Kinoshita]

  [x] +1 Release these artifacts

Building OK from git commit with `mvn clean test install site` with

Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 
2018-06-18T06:33:14+12:00)
Maven home: /opt/apache-maven-3.5.4
Java version: 1.8.0_265, vendor: Private Build, runtime: 
/usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_NZ, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-112-generic", arch: "amd64", family: "unix"

and

Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 
2018-06-18T06:33:14+12:00)
Maven home: /opt/apache-maven-3.5.4
Java version: 11.0.2, vendor: Oracle Corporation, runtime: 
/home/kinow/Development/java/jdk-11.0.2
Default locale: en_NZ, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-112-generic", arch: "amd64", family: "unix"

Reports look OK, checked signatures of Maven/dist artefacts, and a couple files 
from the dist area. Everything looks OK.

Thanks!
Bruno







On Saturday, 29 August 2020, 12:33:49 am NZST, Alex Herbert 
 wrote: 





We have fixed quite a few bugs and added some significant enhancements
since Apache Commons Codec 1.14 was released, so I would like to release
Apache Commons Codec 1.15.

Apache Commons Codec 1.15 RC1 is available for review here:
    https://dist.apache.org/repos/dist/dev/commons/codec/1.15-RC1 (svn
revision 41154    )

The Git tag commons-codec-1.15-RC1 commit for this RC is
c89d2af770f05457fbefa5fb4713c888bf177fb2 which you can browse here:

https://git-wip-us.apache.org/repos/asf?p=commons-codec.git;a=tag;h=refs/tags/commons-codec-1.15-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1523/commons-codec/commons-codec/1.15/

These are the Maven artifacts and their hashes in Nexus:

#Release SHA-512s
#Fri Aug 28 13:02:53 BST 2020
commons-codec-1.15-bin.tar.gz=b6d517db15aedc424d112b8f3282c63f56aae66adaf317baf9853da65e291eb03fb5da51792aa437c7fdce63f6685c75373265e2a035b51e7525048716d7bfe3
commons-codec-1.15-bin.zip=2495a5dcc2e57280882e8bb13972c1881b074e3e06ae13f45025c63e96cdc77c3af2a19f8417dce538172738eee31a3a8ce73227427b4f5db2214f18b71efc7d
commons-codec-1.15-javadoc.jar=0aac697eb0d11b39013b458aa4ba24e5408b9f1435cbc12ebde9cabe39f8fb8fb37a84737a25b31f88f148cbf69a27c34e65952118cc7356511a1eefeb0a9497
commons-codec-1.15-sources.jar=4c451f148d4c4c4f09e93aa12345dcf39e17ccba3c30f638a75a5df3af622e12595946619cb4553dffcc6f77d7ad43b1e216a637942e02da955a376150393804
commons-codec-1.15-src.tar.gz=dcf0b86f269a96362dca5b36b9e764a07e390634804b359d4dbd1a0c50bfcc9f778e3797f196e1f553d76dd25b3c6fd016f0ffbbca856fa6c88d3d55791889ce
commons-codec-1.15-src.zip=41f380634710cc5523426587de0cca7d06ba3b7933f8e1b488c85cbb58fb9e97e0ff48c09f2ae5f09b95f4f4994621d5bf9e60e3c08412b545b4bb6969dfcd95
commons-codec-1.15-test-sources.jar=a77c00eb1a9d976b8f53536248a0c08d1e068b1634cf5ae232728ff01fd553ff9aa5832538fe99ae0017a0a71e11df86156fb6a576ef88a9c11571129094
commons-codec-1.15-tests.jar=3c338b6f4e95d2cec4d16f140f5f4cf4de1ffac6128038bce3058266b7555f037566b6553729d1067caf42770ae1d35726f20837787366014bca5ae86e7f3ba9


I have tested this with 'mvn clean test package site -Pjapicmp' using:

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/apache-maven-3.6.3
Java version: 1.8.0_265, vendor: Private Build, runtime:
/usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-186-generic", arch: "amd64", family:
"unix"

Details of changes since 1.14 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/codec/1.15-RC1/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/codec/1.15-RC1/site/changes-report.html

Site:

https://dist.apache.org/repos/dist/dev/commons/codec/1.15-RC1/site/index.html
    (note some *relative* links are broken and the 1.15 directories are not
yet created - these will be OK once the site is deployed.)

JApiCmp Report (compared to 1.14):

https://dist.apache.org/repos/dist/dev/commons/codec/1.15-RC1/site/japicmp.html

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/codec/1.15-RC1/site/rat-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Alex Herbert,
Release Manager (using key BC87A3FD0A54480F0BADBEBD21939FF0CA2A6567)

For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-codec.git --branch
commons-codec-1.15-RC1 commons-codec-1.15-RC1
cd commons-codec-1.15-RC1

2) 

Re: [VOTE] Release Apache Commons Crypto 1.1.0 based on RC1

[Bruno P. Kinoshita]

  [x] +1 Release these artifacts

Building OK from git commit with `mvn clean test install site` with

Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 
2018-06-18T06:33:14+12:00)
Maven home: /opt/apache-maven-3.5.4
Java version: 1.8.0_265, vendor: Private Build, runtime: 
/usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_NZ, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-112-generic", arch: "amd64", family: "unix"


if failed with Java 11, but I think it might not be a blocker.

make:
 [exec] "/home/kinow/Development/java/jdk-11.0.2//bin/javah" -force 
-classpath target/classes -o 
target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h 
org.apache.commons.crypto.random.OpenSslCryptoRandomNative
 [exec] Makefile:44: recipe for target 
'target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h'
 failed
 [exec] /bin/sh: 1: /home/kinow/Development/java/jdk-11.0.2//bin/javah: not 
found
 [exec] make: *** 
[target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h]
 Error 127


No blocker issues in the site reports.

Checked signatures of Maven and dist area archives, no issues found. Also 
inspected a couple files from the dist area, LICENSE/RELEASENOTES/NOTICE/etc 
all look OK.

Thanks!
Bruno






On Saturday, 29 August 2020, 8:35:40 am NZST, Gary Gregory 
 wrote: 





We have fixed quite a few bugs and added some significant enhancements
since Apache Commons Crypto 1.0.0 was released, so I would like to release
Apache Commons Crypto 1.1.0.

Apache Commons Crypto 1.1.0 RC1 is available for review here:
    https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1 (svn
revision 41177)

The Git tag commons-crypto-1.1.0-RC1 commit for this RC is
3b2561bcdd9a428d01235a3d646cd08fbb6e597a which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-crypto.git;a=commit;h=3b2561bcdd9a428d01235a3d646cd08fbb6e597a
You may checkout this tag using:
    git clone https://gitbox.apache.org/repos/asf/commons-crypto.git
--branch commons-crypto-1.1.0-RC1 commons-crypto-1.1.0-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1524/org/apache/commons/commons-crypto/1.1.0/

These are the artifacts and their hashes:

#Release SHA-512s
#Fri Aug 28 16:20:02 EDT 2020
commons-crypto-1.1.0-bin.tar.gz=a7c65d04bce6f6e415de5f818b9d13953bf819884e343ea47465a67ac8caaeb017dd54a1a7b3b47aab4a71f94fe9a2b8af7ba505b9d2d4786e90d095c3befa48
commons-crypto-1.1.0-bin.zip=5493b9b7967695efcb0c804fa3f3d27f66c3964b4a867c4e0ac3b92d116b71bce655254965092c8252882dd039e52b4386e42b8d306941811a839873a4c1e66a
commons-crypto-1.1.0-javadoc.jar=f37c1cadda93e87a5447cc6458d87441f03c0a4667ac2b647685b405b4b84f99bfbd6802741836a526303240671fcc0f89daabc851a6b31ecbf883f78b4bceed
commons-crypto-1.1.0-sources.jar=ed487f0100ca65ca6d5d0a7998a2ae86b2ed47f67040f3e5d60b0c27e145d9c64e79c51c3c179f4d7e06babd0c4fd1ed571ce58bf1190dd86a1c04d5cdc7a7f9
commons-crypto-1.1.0-src.tar.gz=f5ad97c8fdc722ff633b62e1653fb094bd95a7c0629fd7d203c3760ff4d99d665d415ea4180ed522021835f27ac0b4a17e2cd547e52705a8e3b99c1272a56436
commons-crypto-1.1.0-src.zip=3d877f5417d5446a79defa5c7575f903f37d8fcb19746a474f87ae6c39250cea8b2865238512892cc6f9394a590cbe4aa2cb80dde071e6731666c14625b9
commons-crypto-1.1.0-test-sources.jar=7d120012f27caa98362a2d871edec226a3910f17265ae0c8d8f889370c096e5413c43dc0a106aa163aaf0809ca1d90ee1af81641c21a1f3f8556f1d1b1979e41
commons-crypto-1.1.0-tests.jar=35d769a1a7f0a8163e3bbb16880476cf0fc33d80c56da280901fe2c9e0e31162e7b8d39a8c7973b0b72295defb9bd13be9c2e2d2e225572b209fa8c70e5dddbc

I have tested this with 'mvn -V -Duser.name=$my_apache_id
-Dcommons_release_plugin_version=$commons_release_plugin_version -Prelease
-Ptest-deploy -P jacoco -P japicmp package site deploy' plus building in
Docker to produce the various native binaries using:

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /opt/apache-maven-3.6.3
Java version: 1.8.0_265, vendor: AdoptOpenJDK, runtime:
/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.15.6", arch: "x86_64", family: "mac"

Details of changes since 1.0.0 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/changes-report.html

Site:

https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/index.html
    (note some *relative* links are broken and the 1.1.0 directories are
not yet created - these will be OK once the site is deployed.)

*** JApiCmp Report (compared to 1.0.0):

https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/japicmp.html

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/rat-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please 

Re: [VOTE] Release Apache Commons Crypto 1.1.0 based on RC1

[Gary Gregory]

May I have PMC reviews please?

Gary

On Fri, Aug 28, 2020 at 4:35 PM Gary Gregory  wrote:

> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Crypto 1.0.0 was released, so I would like to release
> Apache Commons Crypto 1.1.0.
>
> Apache Commons Crypto 1.1.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1 (svn
> revision 41177)
>
> The Git tag commons-crypto-1.1.0-RC1 commit for this RC is
> 3b2561bcdd9a428d01235a3d646cd08fbb6e597a which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-crypto.git;a=commit;h=3b2561bcdd9a428d01235a3d646cd08fbb6e597a
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-crypto.git
> --branch commons-crypto-1.1.0-RC1 commons-crypto-1.1.0-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1524/org/apache/commons/commons-crypto/1.1.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Fri Aug 28 16:20:02 EDT 2020
>
> commons-crypto-1.1.0-bin.tar.gz=a7c65d04bce6f6e415de5f818b9d13953bf819884e343ea47465a67ac8caaeb017dd54a1a7b3b47aab4a71f94fe9a2b8af7ba505b9d2d4786e90d095c3befa48
>
> commons-crypto-1.1.0-bin.zip=5493b9b7967695efcb0c804fa3f3d27f66c3964b4a867c4e0ac3b92d116b71bce655254965092c8252882dd039e52b4386e42b8d306941811a839873a4c1e66a
>
> commons-crypto-1.1.0-javadoc.jar=f37c1cadda93e87a5447cc6458d87441f03c0a4667ac2b647685b405b4b84f99bfbd6802741836a526303240671fcc0f89daabc851a6b31ecbf883f78b4bceed
>
> commons-crypto-1.1.0-sources.jar=ed487f0100ca65ca6d5d0a7998a2ae86b2ed47f67040f3e5d60b0c27e145d9c64e79c51c3c179f4d7e06babd0c4fd1ed571ce58bf1190dd86a1c04d5cdc7a7f9
>
> commons-crypto-1.1.0-src.tar.gz=f5ad97c8fdc722ff633b62e1653fb094bd95a7c0629fd7d203c3760ff4d99d665d415ea4180ed522021835f27ac0b4a17e2cd547e52705a8e3b99c1272a56436
>
> commons-crypto-1.1.0-src.zip=3d877f5417d5446a79defa5c7575f903f37d8fcb19746a474f87ae6c39250cea8b2865238512892cc6f9394a590cbe4aa2cb80dde071e6731666c14625b9
>
> commons-crypto-1.1.0-test-sources.jar=7d120012f27caa98362a2d871edec226a3910f17265ae0c8d8f889370c096e5413c43dc0a106aa163aaf0809ca1d90ee1af81641c21a1f3f8556f1d1b1979e41
>
> commons-crypto-1.1.0-tests.jar=35d769a1a7f0a8163e3bbb16880476cf0fc33d80c56da280901fe2c9e0e31162e7b8d39a8c7973b0b72295defb9bd13be9c2e2d2e225572b209fa8c70e5dddbc
>
> I have tested this with 'mvn -V -Duser.name=$my_apache_id
> -Dcommons_release_plugin_version=$commons_release_plugin_version -Prelease
> -Ptest-deploy -P jacoco -P japicmp package site deploy' plus building in
> Docker to produce the various native binaries using:
>
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /opt/apache-maven-3.6.3
> Java version: 1.8.0_265, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.15.6", arch: "x86_64", family: "mac"
>
> Details of changes since 1.0.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/index.html
> (note some *relative* links are broken and the 1.1.0 directories are
> not yet created - these will be OK once the site is deployed.)
>
> *** JApiCmp Report (compared to 1.0.0):
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/japicmp.html
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/rat-report.html
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you,
>
> Gary Gregory,
> Release Manager (using key 86fdc7e2a11262cb)
>
> For following is intended as a helper and refresher for reviewers.
>
> Validating a release candidate
> ==
>
> These guidelines are NOT complete.
>
> Requirements: Git, Java, Maven.
>
> You can validate a release from a release candidate (RC) tag as follows.
>
> 1) Clone and checkout the RC tag
>
> git clone https://gitbox.apache.org/repos/asf/commons-crypto.git --branch
> commons-crypto-1.1.0-RC1 commons-crypto-1.1.0-RC1
> cd commons-crypto-1.1.0-RC1
>
> 2) Check Apache licenses
>
> This step is not required if the site includes a RAT report page which you
> then must check.
>
> mvn apache-rat:check
>
> 3) Check binary compatibility
>
> Older components still use Apache Clirr:
>
> This step is not required if the site includes a Clirr report page which
> you then must check.
>
> mvn clirr:check
>
> Newer components use 

Re: [All] Jenkins going haywire ?

[Gilles Sadowski]

Le jeu. 27 août 2020 à 13:22, Gilles Sadowski  a écrit :
>
> Le jeu. 27 août 2020 à 10:06, Mark Thomas  a écrit :
> >
> > On 27/08/2020 00:21, Gilles Sadowski wrote:
> > > Hi.
> > >
> > > Something happening recently (apparently unrelated to changes
> > > in the repository):
> > >   
> > > https://ci-builds.apache.org/job/Commons/job/commons-statistics/3/console
> > >   https://ci-builds.apache.org/job/Commons/job/commons-numbers/2/console
> > >   https://ci-builds.apache.org/job/Commons/job/commons-rng/3/console
> > >
> > > Any idea about the cause?
> >
> > Probably a question best asked at bui...@apache.org
>
> Posted there.

https://issues.apache.org/jira/browse/INFRA-20796

>
> Thanks,
> Gilles
>
> > Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [All] New repo for all proper components as submodules?

[sebb]

I have a script which downloads
https://gitbox.apache.org/repositories.json and picks out the commons
repositories.
For each one, there is another script that can check out the component repos.

It's then pretty easy to quickly scan files in all the subdirectories,
e.g. to check on pom settings.

It's not as convenient as it used to be with SVN, but it is workable.

On Mon, 31 Aug 2020 at 17:10, Xeno Amess  wrote:
>
> @Gary Gregory 
> Hi gary.
> Please see https://github.com/XenoAmess/commons-proper
> Especially see the github-actions log.
> Is this the exact function what you are looking for?
> :)
> Right now I only added 3 commons repos into this toolchain, means
> bcel,beanutils,bsf
> And the ci will fail only because bsf will fail build.
> Sorry for the formal wrong reply mailing chain, that is a mistake.
>
> Ralph Goers  于2020年8月31日周一 下午11:29写道：
>
> >
> > > On Aug 31, 2020, at 8:24 AM, Ralph Goers 
> > wrote:
> > >
> > >
> > >
> > >> On Aug 31, 2020, at 7:01 AM, Gary Gregory 
> > wrote:
> > >>
> > >> My target use case here is: I want an easy way to work on all of
> > Commons in
> > >> a new VM or a new machine, so I'd like to be able to check out all of
> > >> Commons in one go from any level for example here is an imaginary git
> > >> submodule tree:
> > >> - Apache Commons, a git repo with submodules:
> > >> - -  Apache Commons Proper, a git repo with submodules:
> > >> - - - Apache Commons Lang
> > >> - - - etc
> > >> - -  Apache Commons Sandbox, a git repo with submodules:
> > >> - - - etc
> > >>
> > >> Right now I am checking out each and every repo one at a time. Yes, we
> > >> could stash OS-specific scripts some place.
> > >>
> > >> I was hoping to start at the Apache Commons Proper level. If I need a
> > >> script to update each submodule to the latest HEAD, then this is less
> > >> elegant but understandable from a git POV.
> > >>
> > >> Maybe there is a git shorthand for this…
> > >>
> > >
> > > I do this at work but we use BitBucket. It has the concept of projects
> > and repos live under projects. So I wrote scripts that use the REST API to
> > determine all the repos under and project and then use the git command to
> > clone them all. Once you have them under a single directory it is easy to
> > write a script to do git pull on all of them to keep them updated. IntelliJ
> > also supports loading them all into a single window.
> > >
> > > I believe Git supports labels or something. I know that the ASF knows
> > that each repo belongs to a specific project so I would be surprised if you
> > couldn’t accomplish something similar to what I have done using that
> > information.
> >
> > The .asf.yaml file that can be placed in every repo allows you to specify
> > repository metadata. See
> > https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-Repositorymetadata
> > <
> > https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-Repositorymetadata
> > >
> >
> > Ralph
> >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [All] New repo for all proper components as submodules?

[Xeno Amess]

@Gary Gregory 
Hi gary.
Please see https://github.com/XenoAmess/commons-proper
Especially see the github-actions log.
Is this the exact function what you are looking for?
:)
Right now I only added 3 commons repos into this toolchain, means
bcel,beanutils,bsf
And the ci will fail only because bsf will fail build.
Sorry for the formal wrong reply mailing chain, that is a mistake.

Ralph Goers  于2020年8月31日周一 下午11:29写道：

>
> > On Aug 31, 2020, at 8:24 AM, Ralph Goers 
> wrote:
> >
> >
> >
> >> On Aug 31, 2020, at 7:01 AM, Gary Gregory 
> wrote:
> >>
> >> My target use case here is: I want an easy way to work on all of
> Commons in
> >> a new VM or a new machine, so I'd like to be able to check out all of
> >> Commons in one go from any level for example here is an imaginary git
> >> submodule tree:
> >> - Apache Commons, a git repo with submodules:
> >> - -  Apache Commons Proper, a git repo with submodules:
> >> - - - Apache Commons Lang
> >> - - - etc
> >> - -  Apache Commons Sandbox, a git repo with submodules:
> >> - - - etc
> >>
> >> Right now I am checking out each and every repo one at a time. Yes, we
> >> could stash OS-specific scripts some place.
> >>
> >> I was hoping to start at the Apache Commons Proper level. If I need a
> >> script to update each submodule to the latest HEAD, then this is less
> >> elegant but understandable from a git POV.
> >>
> >> Maybe there is a git shorthand for this…
> >>
> >
> > I do this at work but we use BitBucket. It has the concept of projects
> and repos live under projects. So I wrote scripts that use the REST API to
> determine all the repos under and project and then use the git command to
> clone them all. Once you have them under a single directory it is easy to
> write a script to do git pull on all of them to keep them updated. IntelliJ
> also supports loading them all into a single window.
> >
> > I believe Git supports labels or something. I know that the ASF knows
> that each repo belongs to a specific project so I would be surprised if you
> couldn’t accomplish something similar to what I have done using that
> information.
>
> The .asf.yaml file that can be placed in every repo allows you to specify
> repository metadata. See
> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-Repositorymetadata
> <
> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-Repositorymetadata
> >
>
> Ralph
>
>

Re: [VOTE] Release Apache Commons Crypto 1.1.0 based on RC1

[Geoffrey Blake]

+1

mvn -V clean package
Apache Maven 3.6.3
Maven home: /usr/share/maven
Java version: 1.8.0_265, vendor: Private Build, runtime:
/usr/lib/jvm/java-8-openjdk-arm64/jre
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-1021-aws", arch: "aarch64", family: "unix"



On Sun, Aug 30, 2020 at 2:35 PM Gary Gregory  wrote:

> Ping.
>
> On Fri, Aug 28, 2020, 16:35 Gary Gregory  wrote:
>
>> We have fixed quite a few bugs and added some significant enhancements
>> since Apache Commons Crypto 1.0.0 was released, so I would like to release
>> Apache Commons Crypto 1.1.0.
>>
>> Apache Commons Crypto 1.1.0 RC1 is available for review here:
>> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1 (svn
>> revision 41177)
>>
>> The Git tag commons-crypto-1.1.0-RC1 commit for this RC is
>> 3b2561bcdd9a428d01235a3d646cd08fbb6e597a which you can browse here:
>>
>> https://gitbox.apache.org/repos/asf?p=commons-crypto.git;a=commit;h=3b2561bcdd9a428d01235a3d646cd08fbb6e597a
>> You may checkout this tag using:
>> git clone https://gitbox.apache.org/repos/asf/commons-crypto.git
>> --branch commons-crypto-1.1.0-RC1 commons-crypto-1.1.0-RC1
>>
>> Maven artifacts are here:
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1524/org/apache/commons/commons-crypto/1.1.0/
>>
>> These are the artifacts and their hashes:
>>
>> #Release SHA-512s
>> #Fri Aug 28 16:20:02 EDT 2020
>>
>> commons-crypto-1.1.0-bin.tar.gz=a7c65d04bce6f6e415de5f818b9d13953bf819884e343ea47465a67ac8caaeb017dd54a1a7b3b47aab4a71f94fe9a2b8af7ba505b9d2d4786e90d095c3befa48
>>
>> commons-crypto-1.1.0-bin.zip=5493b9b7967695efcb0c804fa3f3d27f66c3964b4a867c4e0ac3b92d116b71bce655254965092c8252882dd039e52b4386e42b8d306941811a839873a4c1e66a
>>
>> commons-crypto-1.1.0-javadoc.jar=f37c1cadda93e87a5447cc6458d87441f03c0a4667ac2b647685b405b4b84f99bfbd6802741836a526303240671fcc0f89daabc851a6b31ecbf883f78b4bceed
>>
>> commons-crypto-1.1.0-sources.jar=ed487f0100ca65ca6d5d0a7998a2ae86b2ed47f67040f3e5d60b0c27e145d9c64e79c51c3c179f4d7e06babd0c4fd1ed571ce58bf1190dd86a1c04d5cdc7a7f9
>>
>> commons-crypto-1.1.0-src.tar.gz=f5ad97c8fdc722ff633b62e1653fb094bd95a7c0629fd7d203c3760ff4d99d665d415ea4180ed522021835f27ac0b4a17e2cd547e52705a8e3b99c1272a56436
>>
>> commons-crypto-1.1.0-src.zip=3d877f5417d5446a79defa5c7575f903f37d8fcb19746a474f87ae6c39250cea8b2865238512892cc6f9394a590cbe4aa2cb80dde071e6731666c14625b9
>>
>> commons-crypto-1.1.0-test-sources.jar=7d120012f27caa98362a2d871edec226a3910f17265ae0c8d8f889370c096e5413c43dc0a106aa163aaf0809ca1d90ee1af81641c21a1f3f8556f1d1b1979e41
>>
>> commons-crypto-1.1.0-tests.jar=35d769a1a7f0a8163e3bbb16880476cf0fc33d80c56da280901fe2c9e0e31162e7b8d39a8c7973b0b72295defb9bd13be9c2e2d2e225572b209fa8c70e5dddbc
>>
>> I have tested this with 'mvn -V -Duser.name=$my_apache_id
>> -Dcommons_release_plugin_version=$commons_release_plugin_version -Prelease
>> -Ptest-deploy -P jacoco -P japicmp package site deploy' plus building in
>> Docker to produce the various native binaries using:
>>
>> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
>> Maven home: /opt/apache-maven-3.6.3
>> Java version: 1.8.0_265, vendor: AdoptOpenJDK, runtime:
>> /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
>> Default locale: en_US, platform encoding: UTF-8
>> OS name: "mac os x", version: "10.15.6", arch: "x86_64", family: "mac"
>>
>> Details of changes since 1.0.0 are in the release notes:
>>
>> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/RELEASE-NOTES.txt
>>
>> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/changes-report.html
>>
>> Site:
>>
>> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/index.html
>> (note some *relative* links are broken and the 1.1.0 directories are
>> not yet created - these will be OK once the site is deployed.)
>>
>> *** JApiCmp Report (compared to 1.0.0):
>>
>> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/japicmp.html
>>
>> RAT Report:
>>
>> https://dist.apache.org/repos/dist/dev/commons/crypto/1.1.0-RC1/site/rat-report.html
>>
>> KEYS:
>>   https://www.apache.org/dist/commons/KEYS
>>
>> Please review the release candidate and vote.
>> This vote will close no sooner than 72 hours from now.
>>
>>   [ ] +1 Release these artifacts
>>   [ ] +0 OK, but...
>>   [ ] -0 OK, but really should fix...
>>   [ ] -1 I oppose this release because...
>>
>> Thank you,
>>
>> Gary Gregory,
>> Release Manager (using key 86fdc7e2a11262cb)
>>
>> For following is intended as a helper and refresher for reviewers.
>>
>> Validating a release candidate
>> ==
>>
>> These guidelines are NOT complete.
>>
>> Requirements: Git, Java, Maven.
>>
>> You can validate a release from a release candidate (RC) tag as follows.
>>
>> 1) Clone and checkout the RC tag
>>
>> git clone https://gitbox.apache.org/repos/asf/commons-crypto.git
>> --branch commons-crypto-1.1.0-RC1 

Re: [All] New repo for all proper components as submodules?

[Ralph Goers]

> On Aug 31, 2020, at 8:24 AM, Ralph Goers  wrote:
> 
> 
> 
>> On Aug 31, 2020, at 7:01 AM, Gary Gregory  wrote:
>> 
>> My target use case here is: I want an easy way to work on all of Commons in
>> a new VM or a new machine, so I'd like to be able to check out all of
>> Commons in one go from any level for example here is an imaginary git
>> submodule tree:
>> - Apache Commons, a git repo with submodules:
>> - -  Apache Commons Proper, a git repo with submodules:
>> - - - Apache Commons Lang
>> - - - etc
>> - -  Apache Commons Sandbox, a git repo with submodules:
>> - - - etc
>> 
>> Right now I am checking out each and every repo one at a time. Yes, we
>> could stash OS-specific scripts some place.
>> 
>> I was hoping to start at the Apache Commons Proper level. If I need a
>> script to update each submodule to the latest HEAD, then this is less
>> elegant but understandable from a git POV.
>> 
>> Maybe there is a git shorthand for this…
>> 
> 
> I do this at work but we use BitBucket. It has the concept of projects and 
> repos live under projects. So I wrote scripts that use the REST API to 
> determine all the repos under and project and then use the git command to 
> clone them all. Once you have them under a single directory it is easy to 
> write a script to do git pull on all of them to keep them updated. IntelliJ 
> also supports loading them all into a single window.
> 
> I believe Git supports labels or something. I know that the ASF knows that 
> each repo belongs to a specific project so I would be surprised if you 
> couldn’t accomplish something similar to what I have done using that 
> information.

The .asf.yaml file that can be placed in every repo allows you to specify 
repository metadata. See 
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-Repositorymetadata
 


Ralph

Re: [All] New repo for all proper components as submodules?

[Ralph Goers]

> On Aug 31, 2020, at 7:01 AM, Gary Gregory  wrote:
> 
> My target use case here is: I want an easy way to work on all of Commons in
> a new VM or a new machine, so I'd like to be able to check out all of
> Commons in one go from any level for example here is an imaginary git
> submodule tree:
> - Apache Commons, a git repo with submodules:
> - -  Apache Commons Proper, a git repo with submodules:
> - - - Apache Commons Lang
> - - - etc
> - -  Apache Commons Sandbox, a git repo with submodules:
> - - - etc
> 
> Right now I am checking out each and every repo one at a time. Yes, we
> could stash OS-specific scripts some place.
> 
> I was hoping to start at the Apache Commons Proper level. If I need a
> script to update each submodule to the latest HEAD, then this is less
> elegant but understandable from a git POV.
> 
> Maybe there is a git shorthand for this…
> 

I do this at work but we use BitBucket. It has the concept of projects and 
repos live under projects. So I wrote scripts that use the REST API to 
determine all the repos under and project and then use the git command to clone 
them all. Once you have them under a single directory it is easy to write a 
script to do git pull on all of them to keep them updated. IntelliJ also 
supports loading them all into a single window.

I believe Git supports labels or something. I know that the ASF knows that each 
repo belongs to a specific project so I would be surprised if you couldn’t 
accomplish something similar to what I have done using that information.

Ralph

Re: [All] New repo for all proper components as submodules?

[Matt Sicker]

The use case you're describing is fairly well handled by the git
subtree command. There are some git plugins that add more complex
workflows on top of that, but the base command is what you're looking
for. Git submodules, in my experience, are far more useful when
pointing to release commits and treating submodule updates like
dependency updates. If you want the equivalent of how Subversion lets
you link to another repo as a directory, that would be git-subtree,
not git-submodule.

On Mon, 31 Aug 2020 at 09:16, Gary Gregory  wrote:
>
> On Mon, Aug 31, 2020 at 10:15 AM Gary Gregory 
> wrote:
>
> > On Sun, Aug 30, 2020 at 9:24 AM Gary Gregory 
> > wrote:
> >
> >> I'm talking about girl's own submodules:
> >>
> >> https://git-scm.com/book/en/v2/Git-Tools-Submodules
> >>
> >
> > I think the on-line book above has been updated since 2014 (as seen on the
> > front page https://git-scm.com/book/en/v2) so the reference page
> > https://git-scm.com/docs/git-submodule should be more accurate.
> >
> ARG: "I think the on-line book above has been updated" ->  "I think the
> on-line book above has *NOT *been updated"
>
> G
>
>
> >
> > Gary
> >
> >
> >>
> >> https://git-scm.com/docs/git-submodule
> >>
> >> Gary
> >>
> >> On Sun, Aug 30, 2020, 09:09 Rob Tompkins  wrote:
> >>
> >>> By git submodules, are you talking about a symlink to another git
> >>> repository inside one of our repositories?
> >>>
> >>> -Rob
> >>>
> >>> > On Aug 29, 2020, at 6:52 PM, Gary Gregory 
> >>> wrote:
> >>> >
> >>> > Hi All,
> >>> >
> >>> > Any thoughts for or against creating a new git repository which would
> >>> > contain all 'proper' Commons components as git submodules?
> >>> >
> >>> > The idea is to be able to checkout all of Commons 'proper' in one go
> >>> in one
> >>> > place.
> >>> >
> >>> > Gary
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>>



-- 
Matt Sicker 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [All] New repo for all proper components as submodules?

[Gary Gregory]

On Mon, Aug 31, 2020 at 10:15 AM Gary Gregory 
wrote:

> On Sun, Aug 30, 2020 at 9:24 AM Gary Gregory 
> wrote:
>
>> I'm talking about girl's own submodules:
>>
>> https://git-scm.com/book/en/v2/Git-Tools-Submodules
>>
>
> I think the on-line book above has been updated since 2014 (as seen on the
> front page https://git-scm.com/book/en/v2) so the reference page
> https://git-scm.com/docs/git-submodule should be more accurate.
>
ARG: "I think the on-line book above has been updated" ->  "I think the
on-line book above has *NOT *been updated"

G


>
> Gary
>
>
>>
>> https://git-scm.com/docs/git-submodule
>>
>> Gary
>>
>> On Sun, Aug 30, 2020, 09:09 Rob Tompkins  wrote:
>>
>>> By git submodules, are you talking about a symlink to another git
>>> repository inside one of our repositories?
>>>
>>> -Rob
>>>
>>> > On Aug 29, 2020, at 6:52 PM, Gary Gregory 
>>> wrote:
>>> >
>>> > Hi All,
>>> >
>>> > Any thoughts for or against creating a new git repository which would
>>> > contain all 'proper' Commons components as git submodules?
>>> >
>>> > The idea is to be able to checkout all of Commons 'proper' in one go
>>> in one
>>> > place.
>>> >
>>> > Gary
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>

Re: [All] New repo for all proper components as submodules?

[Gary Gregory]

On Sun, Aug 30, 2020 at 9:24 AM Gary Gregory  wrote:

> I'm talking about girl's own submodules:
>
> https://git-scm.com/book/en/v2/Git-Tools-Submodules
>

I think the on-line book above has been updated since 2014 (as seen on the
front page https://git-scm.com/book/en/v2) so the reference page
https://git-scm.com/docs/git-submodule should be more accurate.

Gary


>
> https://git-scm.com/docs/git-submodule
>
> Gary
>
> On Sun, Aug 30, 2020, 09:09 Rob Tompkins  wrote:
>
>> By git submodules, are you talking about a symlink to another git
>> repository inside one of our repositories?
>>
>> -Rob
>>
>> > On Aug 29, 2020, at 6:52 PM, Gary Gregory 
>> wrote:
>> >
>> > Hi All,
>> >
>> > Any thoughts for or against creating a new git repository which would
>> > contain all 'proper' Commons components as git submodules?
>> >
>> > The idea is to be able to checkout all of Commons 'proper' in one go in
>> one
>> > place.
>> >
>> > Gary
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

Re: [All] New repo for all proper components as submodules?

[Xeno Amess]

I'll try if I can solve your goal using maven-plugin tonight.
If I succeed I will let you know :)

Xeno Amess  于2020年8月31日周一 下午10:06写道：

> > Right now I am checking out each and every repo one at a time. Yes, we
> > could stash OS-specific scripts some place.
> >
> > I was hoping to start at the Apache Commons Proper level. If I need a
> > script to update each submodule to the latest HEAD, then this is less
> > elegant but understandable from a git POV.
> >
> > Maybe there is a git shorthand for this...
>
> Sounds like a maven-plugin is better for doing this...
>
>
> Gary Gregory  于2020年8月31日周一 下午10:03写道：
>
>> On Mon, Aug 31, 2020 at 9:59 AM Xeno Amess  wrote:
>>
>> > BTW.
>> > From my own view, we might need a testing maven project (or a github
>> repo),
>> > for ensuring all commons repos can be used together, free of dependency
>> > hell, or other internal errors about using different versions of a same
>> > dependency.
>> >
>>
>> This is not my goal at all here. If that's a goal for you, please see
>> https://gump.apache.org/
>>
>> Gary
>>
>>
>> > But I admit that will really be a time-costing work, and be really hard.
>> > I don't know if we can achieve it by adding the "proper" repo and add a
>> > module pom at base folder, and adding some tests...
>> > Just, I think it useful.
>> >
>> >
>> > John Patrick  于2020年8月31日周一 下午9:51写道：
>> >
>> > > On Mon, 31 Aug 2020 at 14:16, Gary Gregory 
>> > wrote:
>> > > >
>> > > > On Mon, Aug 31, 2020 at 9:11 AM Matt Sicker 
>> wrote:
>> > > >
>> > > > > Git submodules are pointers to other git commits. Therefore, any
>> > > component
>> > > > > changes made don’t affect the mono repo until you update said mono
>> > > repo to
>> > > > > point to the new commit. If you do this to point at the latest
>> > release
>> > > > > tags, this makes for less updates. Otherwise, you’ll want to
>> figure
>> > > out a
>> > > > > CI system for automatically updating submodules to the latest
>> master
>> > > > > commits as they pass CI.
>> > > > >
>> > > >
>> > > > Can that commit be HEAD?
>> > >
>> > > Used git submodules loads 2010-2015, and not much since. But from
>> > > memory it can't be HEAD it has to be a specific commit hash.
>> > >
>> > > We had loads of issues when people worked on the sub modules
>> > > independently, it was easier when every worked with the parent git
>> > > module. But that was early 2010's so it might now allow HEAD or a
>> > > named branch say develop or master/main.
>> > >
>> > > We also had loads of maven warnings because we had a wrapper project
>> > > so from the git parent module it saw the submodules as maven modules.
>> > > But the git parent module maven pom wasn't the parent pom of the git
>> > > submodules maven pom. As parent automatically is
>> > > ../pom.xml
>> > >
>> > > Our setup was;
>> > >
>> > > git-module
>> > > -> pom.xml (GAV project:maven-wrapper:1)
>> > > -> git-submodule-parent
>> > > --> pom.xml (GAV project:parent:1)
>> > > -> git-submodule-core
>> > > --> pom.xml (GAV project:core:1, parent GAV project:parent:1) So
>> > > correct relative path is ../git-submodule-parent/poml.xml
>> > >
>> > > They had ~35 git submodules, not sure if they are still using
>> submodules.
>> > >
>> > > So it can be useful if you want to have component based git repo's but
>> > > it does add an extra overhead layer of maintenance and everyone needs
>> > > to be onboard from experience.
>> > >
>> > > John
>> > >
>> > > >
>> > > > Gary
>> > > >
>> > > >
>> > > > >
>> > > > > On Mon, Aug 31, 2020 at 05:17 sebb  wrote:
>> > > > >
>> > > > > > On Sun, 30 Aug 2020 at 15:01, Gary Gregory <
>> garydgreg...@gmail.com
>> > >
>> > > > > wrote:
>> > > > > >
>> > > > > > >
>> > > > > >
>> > > > > > > On Sun, Aug 30, 2020 at 9:47 AM Rob Tompkins <
>> chtom...@gmail.com
>> > >
>> > > > > wrote:
>> > > > > >
>> > > > > > >
>> > > > > >
>> > > > > > > >
>> > > > > >
>> > > > > > > >
>> > > > > >
>> > > > > > > > > On Aug 30, 2020, at 9:44 AM, sebb 
>> wrote:
>> > > > > >
>> > > > > > > > >
>> > > > > >
>> > > > > > > > > Some questions:
>> > > > > >
>> > > > > > > > >
>> > > > > >
>> > > > > > > > > - does it affect any existing usage?
>> > > > > >
>> > > > > > > > >  i.e. can people continue to use the individual repos
>> exactly
>> > > as
>> > > > > > before
>> > > > > >
>> > > > > > > >
>> > > > > >
>> > > > > > > > no they can’t
>> > > > > >
>> > > > > > > >
>> > > > > >
>> > > > > > >
>> > > > > >
>> > > > > > > Yes they can... this would be a new repo, and changes nothing
>> for
>> > > > > current
>> > > > > >
>> > > > > > > usage. This does not affect existing repos.
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > What about my other queries?
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > - changes to commit messages:
>> > > > > >
>> > > > > >  can people commit to components directly from the new repo?
>> > > > > >
>> > > > > > If so, does that change the commit messages?
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > - maintenance of the 

Re: [All] New repo for all proper components as submodules?

[Xeno Amess]

> Right now I am checking out each and every repo one at a time. Yes, we
> could stash OS-specific scripts some place.
>
> I was hoping to start at the Apache Commons Proper level. If I need a
> script to update each submodule to the latest HEAD, then this is less
> elegant but understandable from a git POV.
>
> Maybe there is a git shorthand for this...

Sounds like a maven-plugin is better for doing this...


Gary Gregory  于2020年8月31日周一 下午10:03写道：

> On Mon, Aug 31, 2020 at 9:59 AM Xeno Amess  wrote:
>
> > BTW.
> > From my own view, we might need a testing maven project (or a github
> repo),
> > for ensuring all commons repos can be used together, free of dependency
> > hell, or other internal errors about using different versions of a same
> > dependency.
> >
>
> This is not my goal at all here. If that's a goal for you, please see
> https://gump.apache.org/
>
> Gary
>
>
> > But I admit that will really be a time-costing work, and be really hard.
> > I don't know if we can achieve it by adding the "proper" repo and add a
> > module pom at base folder, and adding some tests...
> > Just, I think it useful.
> >
> >
> > John Patrick  于2020年8月31日周一 下午9:51写道：
> >
> > > On Mon, 31 Aug 2020 at 14:16, Gary Gregory 
> > wrote:
> > > >
> > > > On Mon, Aug 31, 2020 at 9:11 AM Matt Sicker 
> wrote:
> > > >
> > > > > Git submodules are pointers to other git commits. Therefore, any
> > > component
> > > > > changes made don’t affect the mono repo until you update said mono
> > > repo to
> > > > > point to the new commit. If you do this to point at the latest
> > release
> > > > > tags, this makes for less updates. Otherwise, you’ll want to figure
> > > out a
> > > > > CI system for automatically updating submodules to the latest
> master
> > > > > commits as they pass CI.
> > > > >
> > > >
> > > > Can that commit be HEAD?
> > >
> > > Used git submodules loads 2010-2015, and not much since. But from
> > > memory it can't be HEAD it has to be a specific commit hash.
> > >
> > > We had loads of issues when people worked on the sub modules
> > > independently, it was easier when every worked with the parent git
> > > module. But that was early 2010's so it might now allow HEAD or a
> > > named branch say develop or master/main.
> > >
> > > We also had loads of maven warnings because we had a wrapper project
> > > so from the git parent module it saw the submodules as maven modules.
> > > But the git parent module maven pom wasn't the parent pom of the git
> > > submodules maven pom. As parent automatically is
> > > ../pom.xml
> > >
> > > Our setup was;
> > >
> > > git-module
> > > -> pom.xml (GAV project:maven-wrapper:1)
> > > -> git-submodule-parent
> > > --> pom.xml (GAV project:parent:1)
> > > -> git-submodule-core
> > > --> pom.xml (GAV project:core:1, parent GAV project:parent:1) So
> > > correct relative path is ../git-submodule-parent/poml.xml
> > >
> > > They had ~35 git submodules, not sure if they are still using
> submodules.
> > >
> > > So it can be useful if you want to have component based git repo's but
> > > it does add an extra overhead layer of maintenance and everyone needs
> > > to be onboard from experience.
> > >
> > > John
> > >
> > > >
> > > > Gary
> > > >
> > > >
> > > > >
> > > > > On Mon, Aug 31, 2020 at 05:17 sebb  wrote:
> > > > >
> > > > > > On Sun, 30 Aug 2020 at 15:01, Gary Gregory <
> garydgreg...@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > > >
> > > > > >
> > > > > > > On Sun, Aug 30, 2020 at 9:47 AM Rob Tompkins <
> chtom...@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > > >
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > > On Aug 30, 2020, at 9:44 AM, sebb 
> wrote:
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > Some questions:
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > - does it affect any existing usage?
> > > > > >
> > > > > > > > >  i.e. can people continue to use the individual repos
> exactly
> > > as
> > > > > > before
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > no they can’t
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > >
> > > > > >
> > > > > > > Yes they can... this would be a new repo, and changes nothing
> for
> > > > > current
> > > > > >
> > > > > > > usage. This does not affect existing repos.
> > > > > >
> > > > > >
> > > > > >
> > > > > > What about my other queries?
> > > > > >
> > > > > >
> > > > > >
> > > > > > - changes to commit messages:
> > > > > >
> > > > > >  can people commit to components directly from the new repo?
> > > > > >
> > > > > > If so, does that change the commit messages?
> > > > > >
> > > > > >
> > > > > >
> > > > > > - maintenance of the new repo:
> > > > > >
> > > > > > what is involved, and how will the project know when updates are
> > > needed?
> > > > > >
> > > > > >
> > > > > >
> > > > > > > Gary
> > > > > >
> > > > > > >
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > - does it affect Git emails 

Re: [All] New repo for all proper components as submodules?

[Gary Gregory]

On Mon, Aug 31, 2020 at 9:59 AM Xeno Amess  wrote:

> BTW.
> From my own view, we might need a testing maven project (or a github repo),
> for ensuring all commons repos can be used together, free of dependency
> hell, or other internal errors about using different versions of a same
> dependency.
>

This is not my goal at all here. If that's a goal for you, please see
https://gump.apache.org/

Gary


> But I admit that will really be a time-costing work, and be really hard.
> I don't know if we can achieve it by adding the "proper" repo and add a
> module pom at base folder, and adding some tests...
> Just, I think it useful.
>
>
> John Patrick  于2020年8月31日周一 下午9:51写道：
>
> > On Mon, 31 Aug 2020 at 14:16, Gary Gregory 
> wrote:
> > >
> > > On Mon, Aug 31, 2020 at 9:11 AM Matt Sicker  wrote:
> > >
> > > > Git submodules are pointers to other git commits. Therefore, any
> > component
> > > > changes made don’t affect the mono repo until you update said mono
> > repo to
> > > > point to the new commit. If you do this to point at the latest
> release
> > > > tags, this makes for less updates. Otherwise, you’ll want to figure
> > out a
> > > > CI system for automatically updating submodules to the latest master
> > > > commits as they pass CI.
> > > >
> > >
> > > Can that commit be HEAD?
> >
> > Used git submodules loads 2010-2015, and not much since. But from
> > memory it can't be HEAD it has to be a specific commit hash.
> >
> > We had loads of issues when people worked on the sub modules
> > independently, it was easier when every worked with the parent git
> > module. But that was early 2010's so it might now allow HEAD or a
> > named branch say develop or master/main.
> >
> > We also had loads of maven warnings because we had a wrapper project
> > so from the git parent module it saw the submodules as maven modules.
> > But the git parent module maven pom wasn't the parent pom of the git
> > submodules maven pom. As parent automatically is
> > ../pom.xml
> >
> > Our setup was;
> >
> > git-module
> > -> pom.xml (GAV project:maven-wrapper:1)
> > -> git-submodule-parent
> > --> pom.xml (GAV project:parent:1)
> > -> git-submodule-core
> > --> pom.xml (GAV project:core:1, parent GAV project:parent:1) So
> > correct relative path is ../git-submodule-parent/poml.xml
> >
> > They had ~35 git submodules, not sure if they are still using submodules.
> >
> > So it can be useful if you want to have component based git repo's but
> > it does add an extra overhead layer of maintenance and everyone needs
> > to be onboard from experience.
> >
> > John
> >
> > >
> > > Gary
> > >
> > >
> > > >
> > > > On Mon, Aug 31, 2020 at 05:17 sebb  wrote:
> > > >
> > > > > On Sun, 30 Aug 2020 at 15:01, Gary Gregory  >
> > > > wrote:
> > > > >
> > > > > >
> > > > >
> > > > > > On Sun, Aug 30, 2020 at 9:47 AM Rob Tompkins  >
> > > > wrote:
> > > > >
> > > > > >
> > > > >
> > > > > > >
> > > > >
> > > > > > >
> > > > >
> > > > > > > > On Aug 30, 2020, at 9:44 AM, sebb  wrote:
> > > > >
> > > > > > > >
> > > > >
> > > > > > > > Some questions:
> > > > >
> > > > > > > >
> > > > >
> > > > > > > > - does it affect any existing usage?
> > > > >
> > > > > > > >  i.e. can people continue to use the individual repos exactly
> > as
> > > > > before
> > > > >
> > > > > > >
> > > > >
> > > > > > > no they can’t
> > > > >
> > > > > > >
> > > > >
> > > > > >
> > > > >
> > > > > > Yes they can... this would be a new repo, and changes nothing for
> > > > current
> > > > >
> > > > > > usage. This does not affect existing repos.
> > > > >
> > > > >
> > > > >
> > > > > What about my other queries?
> > > > >
> > > > >
> > > > >
> > > > > - changes to commit messages:
> > > > >
> > > > >  can people commit to components directly from the new repo?
> > > > >
> > > > > If so, does that change the commit messages?
> > > > >
> > > > >
> > > > >
> > > > > - maintenance of the new repo:
> > > > >
> > > > > what is involved, and how will the project know when updates are
> > needed?
> > > > >
> > > > >
> > > > >
> > > > > > Gary
> > > > >
> > > > > >
> > > > >
> > > > > > >
> > > > >
> > > > > > > >
> > > > >
> > > > > > > > - does it affect Git emails in any way?
> > > > >
> > > > > > > >  e.g. do they have different text?
> > > > >
> > > > > > >
> > > > >
> > > > > > > same emails
> > > > >
> > > > > > >
> > > > >
> > > > > > > >
> > > > >
> > > > > > > > - will it need much maintenance?
> > > > >
> > > > > > > > If so, how do we know when it needs updating?
> > > > >
> > > > > > >
> > > > >
> > > > > > > more maintainance, have to maintain a git hash at a symlink
> > pointing
> > > > > to an
> > > > >
> > > > > > > external repository
> > > > >
> > > > > > >
> > > > >
> > > > > > > -Rob
> > > > >
> > > > > > >
> > > > >
> > > > > > > >
> > > > >
> > > > > > > > On Sun, 30 Aug 2020 at 14:26, Gary Gregory <
> > garydgreg...@gmail.com
> > > > >
> > > > >
> > > > > > > wrote:
> > > > >
> > > > > > > >>
> > > > >
> > > > > > > >> Yes yes "girl" -> "git"
> > > > >

Re: [All] New repo for all proper components as submodules?

[Gary Gregory]

On Mon, Aug 31, 2020 at 9:51 AM John Patrick  wrote:

> On Mon, 31 Aug 2020 at 14:16, Gary Gregory  wrote:
> >
> > On Mon, Aug 31, 2020 at 9:11 AM Matt Sicker  wrote:
> >
> > > Git submodules are pointers to other git commits. Therefore, any
> component
> > > changes made don’t affect the mono repo until you update said mono
> repo to
> > > point to the new commit. If you do this to point at the latest release
> > > tags, this makes for less updates. Otherwise, you’ll want to figure
> out a
> > > CI system for automatically updating submodules to the latest master
> > > commits as they pass CI.
> > >
> >
> > Can that commit be HEAD?
>
> Used git submodules loads 2010-2015, and not much since. But from
> memory it can't be HEAD it has to be a specific commit hash.


> We had loads of issues when people worked on the sub modules
> independently, it was easier when every worked with the parent git
> module. But that was early 2010's so it might now allow HEAD or a
> named branch say develop or master/main.
>
> We also had loads of maven warnings because we had a wrapper project
> so from the git parent module it saw the submodules as maven modules.
> But the git parent module maven pom wasn't the parent pom of the git
> submodules maven pom. As parent automatically is
> ../pom.xml
>
> Our setup was;
>
> git-module
> -> pom.xml (GAV project:maven-wrapper:1)
> -> git-submodule-parent
> --> pom.xml (GAV project:parent:1)
> -> git-submodule-core
> --> pom.xml (GAV project:core:1, parent GAV project:parent:1) So
> correct relative path is ../git-submodule-parent/poml.xml
>
> They had ~35 git submodules, not sure if they are still using submodules.
>
> So it can be useful if you want to have component based git repo's but
> it does add an extra overhead layer of maintenance and everyone needs
> to be onboard from experience.
>

My target use case here is: I want an easy way to work on all of Commons in
a new VM or a new machine, so I'd like to be able to check out all of
Commons in one go from any level for example here is an imaginary git
submodule tree:
- Apache Commons, a git repo with submodules:
- -  Apache Commons Proper, a git repo with submodules:
- - - Apache Commons Lang
- - - etc
- -  Apache Commons Sandbox, a git repo with submodules:
- - - etc

Right now I am checking out each and every repo one at a time. Yes, we
could stash OS-specific scripts some place.

I was hoping to start at the Apache Commons Proper level. If I need a
script to update each submodule to the latest HEAD, then this is less
elegant but understandable from a git POV.

Maybe there is a git shorthand for this...

Gary



>
> John
>
> >
> > Gary
> >
> >
> > >
> > > On Mon, Aug 31, 2020 at 05:17 sebb  wrote:
> > >
> > > > On Sun, 30 Aug 2020 at 15:01, Gary Gregory 
> > > wrote:
> > > >
> > > > >
> > > >
> > > > > On Sun, Aug 30, 2020 at 9:47 AM Rob Tompkins 
> > > wrote:
> > > >
> > > > >
> > > >
> > > > > >
> > > >
> > > > > >
> > > >
> > > > > > > On Aug 30, 2020, at 9:44 AM, sebb  wrote:
> > > >
> > > > > > >
> > > >
> > > > > > > Some questions:
> > > >
> > > > > > >
> > > >
> > > > > > > - does it affect any existing usage?
> > > >
> > > > > > >  i.e. can people continue to use the individual repos exactly
> as
> > > > before
> > > >
> > > > > >
> > > >
> > > > > > no they can’t
> > > >
> > > > > >
> > > >
> > > > >
> > > >
> > > > > Yes they can... this would be a new repo, and changes nothing for
> > > current
> > > >
> > > > > usage. This does not affect existing repos.
> > > >
> > > >
> > > >
> > > > What about my other queries?
> > > >
> > > >
> > > >
> > > > - changes to commit messages:
> > > >
> > > >  can people commit to components directly from the new repo?
> > > >
> > > > If so, does that change the commit messages?
> > > >
> > > >
> > > >
> > > > - maintenance of the new repo:
> > > >
> > > > what is involved, and how will the project know when updates are
> needed?
> > > >
> > > >
> > > >
> > > > > Gary
> > > >
> > > > >
> > > >
> > > > > >
> > > >
> > > > > > >
> > > >
> > > > > > > - does it affect Git emails in any way?
> > > >
> > > > > > >  e.g. do they have different text?
> > > >
> > > > > >
> > > >
> > > > > > same emails
> > > >
> > > > > >
> > > >
> > > > > > >
> > > >
> > > > > > > - will it need much maintenance?
> > > >
> > > > > > > If so, how do we know when it needs updating?
> > > >
> > > > > >
> > > >
> > > > > > more maintainance, have to maintain a git hash at a symlink
> pointing
> > > > to an
> > > >
> > > > > > external repository
> > > >
> > > > > >
> > > >
> > > > > > -Rob
> > > >
> > > > > >
> > > >
> > > > > > >
> > > >
> > > > > > > On Sun, 30 Aug 2020 at 14:26, Gary Gregory <
> garydgreg...@gmail.com
> > > >
> > > >
> > > > > > wrote:
> > > >
> > > > > > >>
> > > >
> > > > > > >> Yes yes "girl" -> "git"
> > > >
> > > > > > >>
> > > >
> > > > > > >> On Sun, Aug 30, 2020, 09:24 Gary Gregory <
> garydgreg...@gmail.com>
> > > >
> > > > > > wrote:
> > > >
> > > > > > >>
> > > >
> > > > > > 

Re: [All] New repo for all proper components as submodules?

[Xeno Amess]

As example for dependency-hell, slf4j 1 and 2 use same namespace, means if
some dependency use slf4j1 and another use slf4j2, some really disgusting
thing will happen.
I suffered from that, once.

Xeno Amess  于2020年8月31日周一 下午9:59写道：

> BTW.
> From my own view, we might need a testing maven project (or a github
> repo), for ensuring all commons repos can be used together, free of
> dependency hell, or other internal errors about using different versions of
> a same dependency.
> But I admit that will really be a time-costing work, and be really hard.
> I don't know if we can achieve it by adding the "proper" repo and add a
> module pom at base folder, and adding some tests...
> Just, I think it useful.
>
>
> John Patrick  于2020年8月31日周一 下午9:51写道：
>
>> On Mon, 31 Aug 2020 at 14:16, Gary Gregory 
>> wrote:
>> >
>> > On Mon, Aug 31, 2020 at 9:11 AM Matt Sicker  wrote:
>> >
>> > > Git submodules are pointers to other git commits. Therefore, any
>> component
>> > > changes made don’t affect the mono repo until you update said mono
>> repo to
>> > > point to the new commit. If you do this to point at the latest release
>> > > tags, this makes for less updates. Otherwise, you’ll want to figure
>> out a
>> > > CI system for automatically updating submodules to the latest master
>> > > commits as they pass CI.
>> > >
>> >
>> > Can that commit be HEAD?
>>
>> Used git submodules loads 2010-2015, and not much since. But from
>> memory it can't be HEAD it has to be a specific commit hash.
>>
>> We had loads of issues when people worked on the sub modules
>> independently, it was easier when every worked with the parent git
>> module. But that was early 2010's so it might now allow HEAD or a
>> named branch say develop or master/main.
>>
>> We also had loads of maven warnings because we had a wrapper project
>> so from the git parent module it saw the submodules as maven modules.
>> But the git parent module maven pom wasn't the parent pom of the git
>> submodules maven pom. As parent automatically is
>> ../pom.xml
>>
>> Our setup was;
>>
>> git-module
>> -> pom.xml (GAV project:maven-wrapper:1)
>> -> git-submodule-parent
>> --> pom.xml (GAV project:parent:1)
>> -> git-submodule-core
>> --> pom.xml (GAV project:core:1, parent GAV project:parent:1) So
>> correct relative path is ../git-submodule-parent/poml.xml
>>
>> They had ~35 git submodules, not sure if they are still using submodules.
>>
>> So it can be useful if you want to have component based git repo's but
>> it does add an extra overhead layer of maintenance and everyone needs
>> to be onboard from experience.
>>
>> John
>>
>> >
>> > Gary
>> >
>> >
>> > >
>> > > On Mon, Aug 31, 2020 at 05:17 sebb  wrote:
>> > >
>> > > > On Sun, 30 Aug 2020 at 15:01, Gary Gregory 
>> > > wrote:
>> > > >
>> > > > >
>> > > >
>> > > > > On Sun, Aug 30, 2020 at 9:47 AM Rob Tompkins 
>> > > wrote:
>> > > >
>> > > > >
>> > > >
>> > > > > >
>> > > >
>> > > > > >
>> > > >
>> > > > > > > On Aug 30, 2020, at 9:44 AM, sebb  wrote:
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > Some questions:
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > - does it affect any existing usage?
>> > > >
>> > > > > > >  i.e. can people continue to use the individual repos exactly
>> as
>> > > > before
>> > > >
>> > > > > >
>> > > >
>> > > > > > no they can’t
>> > > >
>> > > > > >
>> > > >
>> > > > >
>> > > >
>> > > > > Yes they can... this would be a new repo, and changes nothing for
>> > > current
>> > > >
>> > > > > usage. This does not affect existing repos.
>> > > >
>> > > >
>> > > >
>> > > > What about my other queries?
>> > > >
>> > > >
>> > > >
>> > > > - changes to commit messages:
>> > > >
>> > > >  can people commit to components directly from the new repo?
>> > > >
>> > > > If so, does that change the commit messages?
>> > > >
>> > > >
>> > > >
>> > > > - maintenance of the new repo:
>> > > >
>> > > > what is involved, and how will the project know when updates are
>> needed?
>> > > >
>> > > >
>> > > >
>> > > > > Gary
>> > > >
>> > > > >
>> > > >
>> > > > > >
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > - does it affect Git emails in any way?
>> > > >
>> > > > > > >  e.g. do they have different text?
>> > > >
>> > > > > >
>> > > >
>> > > > > > same emails
>> > > >
>> > > > > >
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > - will it need much maintenance?
>> > > >
>> > > > > > > If so, how do we know when it needs updating?
>> > > >
>> > > > > >
>> > > >
>> > > > > > more maintainance, have to maintain a git hash at a symlink
>> pointing
>> > > > to an
>> > > >
>> > > > > > external repository
>> > > >
>> > > > > >
>> > > >
>> > > > > > -Rob
>> > > >
>> > > > > >
>> > > >
>> > > > > > >
>> > > >
>> > > > > > > On Sun, 30 Aug 2020 at 14:26, Gary Gregory <
>> garydgreg...@gmail.com
>> > > >
>> > > >
>> > > > > > wrote:
>> > > >
>> > > > > > >>
>> > > >
>> > > > > > >> Yes yes "girl" -> "git"
>> > > >
>> > > > > > >>
>> > > >
>> > > > > > >> On Sun, Aug 30, 2020, 09:24 Gary Gregory <
>> 

Re: [All] New repo for all proper components as submodules?

[Xeno Amess]

BTW.
>From my own view, we might need a testing maven project (or a github repo),
for ensuring all commons repos can be used together, free of dependency
hell, or other internal errors about using different versions of a same
dependency.
But I admit that will really be a time-costing work, and be really hard.
I don't know if we can achieve it by adding the "proper" repo and add a
module pom at base folder, and adding some tests...
Just, I think it useful.


John Patrick  于2020年8月31日周一 下午9:51写道：

> On Mon, 31 Aug 2020 at 14:16, Gary Gregory  wrote:
> >
> > On Mon, Aug 31, 2020 at 9:11 AM Matt Sicker  wrote:
> >
> > > Git submodules are pointers to other git commits. Therefore, any
> component
> > > changes made don’t affect the mono repo until you update said mono
> repo to
> > > point to the new commit. If you do this to point at the latest release
> > > tags, this makes for less updates. Otherwise, you’ll want to figure
> out a
> > > CI system for automatically updating submodules to the latest master
> > > commits as they pass CI.
> > >
> >
> > Can that commit be HEAD?
>
> Used git submodules loads 2010-2015, and not much since. But from
> memory it can't be HEAD it has to be a specific commit hash.
>
> We had loads of issues when people worked on the sub modules
> independently, it was easier when every worked with the parent git
> module. But that was early 2010's so it might now allow HEAD or a
> named branch say develop or master/main.
>
> We also had loads of maven warnings because we had a wrapper project
> so from the git parent module it saw the submodules as maven modules.
> But the git parent module maven pom wasn't the parent pom of the git
> submodules maven pom. As parent automatically is
> ../pom.xml
>
> Our setup was;
>
> git-module
> -> pom.xml (GAV project:maven-wrapper:1)
> -> git-submodule-parent
> --> pom.xml (GAV project:parent:1)
> -> git-submodule-core
> --> pom.xml (GAV project:core:1, parent GAV project:parent:1) So
> correct relative path is ../git-submodule-parent/poml.xml
>
> They had ~35 git submodules, not sure if they are still using submodules.
>
> So it can be useful if you want to have component based git repo's but
> it does add an extra overhead layer of maintenance and everyone needs
> to be onboard from experience.
>
> John
>
> >
> > Gary
> >
> >
> > >
> > > On Mon, Aug 31, 2020 at 05:17 sebb  wrote:
> > >
> > > > On Sun, 30 Aug 2020 at 15:01, Gary Gregory 
> > > wrote:
> > > >
> > > > >
> > > >
> > > > > On Sun, Aug 30, 2020 at 9:47 AM Rob Tompkins 
> > > wrote:
> > > >
> > > > >
> > > >
> > > > > >
> > > >
> > > > > >
> > > >
> > > > > > > On Aug 30, 2020, at 9:44 AM, sebb  wrote:
> > > >
> > > > > > >
> > > >
> > > > > > > Some questions:
> > > >
> > > > > > >
> > > >
> > > > > > > - does it affect any existing usage?
> > > >
> > > > > > >  i.e. can people continue to use the individual repos exactly
> as
> > > > before
> > > >
> > > > > >
> > > >
> > > > > > no they can’t
> > > >
> > > > > >
> > > >
> > > > >
> > > >
> > > > > Yes they can... this would be a new repo, and changes nothing for
> > > current
> > > >
> > > > > usage. This does not affect existing repos.
> > > >
> > > >
> > > >
> > > > What about my other queries?
> > > >
> > > >
> > > >
> > > > - changes to commit messages:
> > > >
> > > >  can people commit to components directly from the new repo?
> > > >
> > > > If so, does that change the commit messages?
> > > >
> > > >
> > > >
> > > > - maintenance of the new repo:
> > > >
> > > > what is involved, and how will the project know when updates are
> needed?
> > > >
> > > >
> > > >
> > > > > Gary
> > > >
> > > > >
> > > >
> > > > > >
> > > >
> > > > > > >
> > > >
> > > > > > > - does it affect Git emails in any way?
> > > >
> > > > > > >  e.g. do they have different text?
> > > >
> > > > > >
> > > >
> > > > > > same emails
> > > >
> > > > > >
> > > >
> > > > > > >
> > > >
> > > > > > > - will it need much maintenance?
> > > >
> > > > > > > If so, how do we know when it needs updating?
> > > >
> > > > > >
> > > >
> > > > > > more maintainance, have to maintain a git hash at a symlink
> pointing
> > > > to an
> > > >
> > > > > > external repository
> > > >
> > > > > >
> > > >
> > > > > > -Rob
> > > >
> > > > > >
> > > >
> > > > > > >
> > > >
> > > > > > > On Sun, 30 Aug 2020 at 14:26, Gary Gregory <
> garydgreg...@gmail.com
> > > >
> > > >
> > > > > > wrote:
> > > >
> > > > > > >>
> > > >
> > > > > > >> Yes yes "girl" -> "git"
> > > >
> > > > > > >>
> > > >
> > > > > > >> On Sun, Aug 30, 2020, 09:24 Gary Gregory <
> garydgreg...@gmail.com>
> > > >
> > > > > > wrote:
> > > >
> > > > > > >>
> > > >
> > > > > > >>> I'm talking about girl's own submodules:
> > > >
> > > > > > >>>
> > > >
> > > > > > >>> https://git-scm.com/book/en/v2/Git-Tools-Submodules
> > > >
> > > > > > >>>
> > > >
> > > > > > >>> https://git-scm.com/docs/git-submodule
> > > >
> > > > > > >>>
> > > >
> > > > > > >>> Gary
> > > >
> > > > > > >>>
> > > >
> > > > > > >>> On Sun, Aug 

Re: [All] New repo for all proper components as submodules?

[Matt Sicker]

If you want to point to something less specific than a commit, take a
look at git subtree instead:
https://www.atlassian.com/git/tutorials/git-subtree

On Mon, 31 Aug 2020 at 08:51, John Patrick  wrote:
>
> On Mon, 31 Aug 2020 at 14:16, Gary Gregory  wrote:
> >
> > On Mon, Aug 31, 2020 at 9:11 AM Matt Sicker  wrote:
> >
> > > Git submodules are pointers to other git commits. Therefore, any component
> > > changes made don’t affect the mono repo until you update said mono repo to
> > > point to the new commit. If you do this to point at the latest release
> > > tags, this makes for less updates. Otherwise, you’ll want to figure out a
> > > CI system for automatically updating submodules to the latest master
> > > commits as they pass CI.
> > >
> >
> > Can that commit be HEAD?
>
> Used git submodules loads 2010-2015, and not much since. But from
> memory it can't be HEAD it has to be a specific commit hash.
>
> We had loads of issues when people worked on the sub modules
> independently, it was easier when every worked with the parent git
> module. But that was early 2010's so it might now allow HEAD or a
> named branch say develop or master/main.
>
> We also had loads of maven warnings because we had a wrapper project
> so from the git parent module it saw the submodules as maven modules.
> But the git parent module maven pom wasn't the parent pom of the git
> submodules maven pom. As parent automatically is
> ../pom.xml
>
> Our setup was;
>
> git-module
> -> pom.xml (GAV project:maven-wrapper:1)
> -> git-submodule-parent
> --> pom.xml (GAV project:parent:1)
> -> git-submodule-core
> --> pom.xml (GAV project:core:1, parent GAV project:parent:1) So
> correct relative path is ../git-submodule-parent/poml.xml
>
> They had ~35 git submodules, not sure if they are still using submodules.
>
> So it can be useful if you want to have component based git repo's but
> it does add an extra overhead layer of maintenance and everyone needs
> to be onboard from experience.
>
> John
>
> >
> > Gary
> >
> >
> > >
> > > On Mon, Aug 31, 2020 at 05:17 sebb  wrote:
> > >
> > > > On Sun, 30 Aug 2020 at 15:01, Gary Gregory 
> > > wrote:
> > > >
> > > > >
> > > >
> > > > > On Sun, Aug 30, 2020 at 9:47 AM Rob Tompkins 
> > > wrote:
> > > >
> > > > >
> > > >
> > > > > >
> > > >
> > > > > >
> > > >
> > > > > > > On Aug 30, 2020, at 9:44 AM, sebb  wrote:
> > > >
> > > > > > >
> > > >
> > > > > > > Some questions:
> > > >
> > > > > > >
> > > >
> > > > > > > - does it affect any existing usage?
> > > >
> > > > > > >  i.e. can people continue to use the individual repos exactly as
> > > > before
> > > >
> > > > > >
> > > >
> > > > > > no they can’t
> > > >
> > > > > >
> > > >
> > > > >
> > > >
> > > > > Yes they can... this would be a new repo, and changes nothing for
> > > current
> > > >
> > > > > usage. This does not affect existing repos.
> > > >
> > > >
> > > >
> > > > What about my other queries?
> > > >
> > > >
> > > >
> > > > - changes to commit messages:
> > > >
> > > >  can people commit to components directly from the new repo?
> > > >
> > > > If so, does that change the commit messages?
> > > >
> > > >
> > > >
> > > > - maintenance of the new repo:
> > > >
> > > > what is involved, and how will the project know when updates are needed?
> > > >
> > > >
> > > >
> > > > > Gary
> > > >
> > > > >
> > > >
> > > > > >
> > > >
> > > > > > >
> > > >
> > > > > > > - does it affect Git emails in any way?
> > > >
> > > > > > >  e.g. do they have different text?
> > > >
> > > > > >
> > > >
> > > > > > same emails
> > > >
> > > > > >
> > > >
> > > > > > >
> > > >
> > > > > > > - will it need much maintenance?
> > > >
> > > > > > > If so, how do we know when it needs updating?
> > > >
> > > > > >
> > > >
> > > > > > more maintainance, have to maintain a git hash at a symlink pointing
> > > > to an
> > > >
> > > > > > external repository
> > > >
> > > > > >
> > > >
> > > > > > -Rob
> > > >
> > > > > >
> > > >
> > > > > > >
> > > >
> > > > > > > On Sun, 30 Aug 2020 at 14:26, Gary Gregory  > > >
> > > >
> > > > > > wrote:
> > > >
> > > > > > >>
> > > >
> > > > > > >> Yes yes "girl" -> "git"
> > > >
> > > > > > >>
> > > >
> > > > > > >> On Sun, Aug 30, 2020, 09:24 Gary Gregory 
> > > >
> > > > > > wrote:
> > > >
> > > > > > >>
> > > >
> > > > > > >>> I'm talking about girl's own submodules:
> > > >
> > > > > > >>>
> > > >
> > > > > > >>> https://git-scm.com/book/en/v2/Git-Tools-Submodules
> > > >
> > > > > > >>>
> > > >
> > > > > > >>> https://git-scm.com/docs/git-submodule
> > > >
> > > > > > >>>
> > > >
> > > > > > >>> Gary
> > > >
> > > > > > >>>
> > > >
> > > > > > >>> On Sun, Aug 30, 2020, 09:09 Rob Tompkins 
> > > > wrote:
> > > >
> > > > > > >>>
> > > >
> > > > > >  By git submodules, are you talking about a symlink to another
> > > git
> > > >
> > > > > >  repository inside one of our repositories?
> > > >
> > > > > > 
> > > >
> > > > > >  -Rob
> > > >
> > > > > > 
> > > >
> > > > > > > On Aug 29, 2020, at 6:52 

Re: [All] New repo for all proper components as submodules?

[John Patrick]

On Mon, 31 Aug 2020 at 14:16, Gary Gregory  wrote:
>
> On Mon, Aug 31, 2020 at 9:11 AM Matt Sicker  wrote:
>
> > Git submodules are pointers to other git commits. Therefore, any component
> > changes made don’t affect the mono repo until you update said mono repo to
> > point to the new commit. If you do this to point at the latest release
> > tags, this makes for less updates. Otherwise, you’ll want to figure out a
> > CI system for automatically updating submodules to the latest master
> > commits as they pass CI.
> >
>
> Can that commit be HEAD?

Used git submodules loads 2010-2015, and not much since. But from
memory it can't be HEAD it has to be a specific commit hash.

We had loads of issues when people worked on the sub modules
independently, it was easier when every worked with the parent git
module. But that was early 2010's so it might now allow HEAD or a
named branch say develop or master/main.

We also had loads of maven warnings because we had a wrapper project
so from the git parent module it saw the submodules as maven modules.
But the git parent module maven pom wasn't the parent pom of the git
submodules maven pom. As parent automatically is
../pom.xml

Our setup was;

git-module
-> pom.xml (GAV project:maven-wrapper:1)
-> git-submodule-parent
--> pom.xml (GAV project:parent:1)
-> git-submodule-core
--> pom.xml (GAV project:core:1, parent GAV project:parent:1) So
correct relative path is ../git-submodule-parent/poml.xml

They had ~35 git submodules, not sure if they are still using submodules.

So it can be useful if you want to have component based git repo's but
it does add an extra overhead layer of maintenance and everyone needs
to be onboard from experience.

John

>
> Gary
>
>
> >
> > On Mon, Aug 31, 2020 at 05:17 sebb  wrote:
> >
> > > On Sun, 30 Aug 2020 at 15:01, Gary Gregory 
> > wrote:
> > >
> > > >
> > >
> > > > On Sun, Aug 30, 2020 at 9:47 AM Rob Tompkins 
> > wrote:
> > >
> > > >
> > >
> > > > >
> > >
> > > > >
> > >
> > > > > > On Aug 30, 2020, at 9:44 AM, sebb  wrote:
> > >
> > > > > >
> > >
> > > > > > Some questions:
> > >
> > > > > >
> > >
> > > > > > - does it affect any existing usage?
> > >
> > > > > >  i.e. can people continue to use the individual repos exactly as
> > > before
> > >
> > > > >
> > >
> > > > > no they can’t
> > >
> > > > >
> > >
> > > >
> > >
> > > > Yes they can... this would be a new repo, and changes nothing for
> > current
> > >
> > > > usage. This does not affect existing repos.
> > >
> > >
> > >
> > > What about my other queries?
> > >
> > >
> > >
> > > - changes to commit messages:
> > >
> > >  can people commit to components directly from the new repo?
> > >
> > > If so, does that change the commit messages?
> > >
> > >
> > >
> > > - maintenance of the new repo:
> > >
> > > what is involved, and how will the project know when updates are needed?
> > >
> > >
> > >
> > > > Gary
> > >
> > > >
> > >
> > > > >
> > >
> > > > > >
> > >
> > > > > > - does it affect Git emails in any way?
> > >
> > > > > >  e.g. do they have different text?
> > >
> > > > >
> > >
> > > > > same emails
> > >
> > > > >
> > >
> > > > > >
> > >
> > > > > > - will it need much maintenance?
> > >
> > > > > > If so, how do we know when it needs updating?
> > >
> > > > >
> > >
> > > > > more maintainance, have to maintain a git hash at a symlink pointing
> > > to an
> > >
> > > > > external repository
> > >
> > > > >
> > >
> > > > > -Rob
> > >
> > > > >
> > >
> > > > > >
> > >
> > > > > > On Sun, 30 Aug 2020 at 14:26, Gary Gregory  > >
> > >
> > > > > wrote:
> > >
> > > > > >>
> > >
> > > > > >> Yes yes "girl" -> "git"
> > >
> > > > > >>
> > >
> > > > > >> On Sun, Aug 30, 2020, 09:24 Gary Gregory 
> > >
> > > > > wrote:
> > >
> > > > > >>
> > >
> > > > > >>> I'm talking about girl's own submodules:
> > >
> > > > > >>>
> > >
> > > > > >>> https://git-scm.com/book/en/v2/Git-Tools-Submodules
> > >
> > > > > >>>
> > >
> > > > > >>> https://git-scm.com/docs/git-submodule
> > >
> > > > > >>>
> > >
> > > > > >>> Gary
> > >
> > > > > >>>
> > >
> > > > > >>> On Sun, Aug 30, 2020, 09:09 Rob Tompkins 
> > > wrote:
> > >
> > > > > >>>
> > >
> > > > >  By git submodules, are you talking about a symlink to another
> > git
> > >
> > > > >  repository inside one of our repositories?
> > >
> > > > > 
> > >
> > > > >  -Rob
> > >
> > > > > 
> > >
> > > > > > On Aug 29, 2020, at 6:52 PM, Gary Gregory <
> > > garydgreg...@gmail.com>
> > >
> > > > >  wrote:
> > >
> > > > > >
> > >
> > > > > > Hi All,
> > >
> > > > > >
> > >
> > > > > > Any thoughts for or against creating a new git repository which
> > > would
> > >
> > > > > > contain all 'proper' Commons components as git submodules?
> > >
> > > > > >
> > >
> > > > > > The idea is to be able to checkout all of Commons 'proper' in
> > > one go
> > >
> > > > > in
> > >
> > > > >  one
> > >
> > > > > > place.
> > >
> > > > > >
> > >
> > > > > > Gary
> > >
> > > > > 
> > >
> 

Re: [All] New repo for all proper components as submodules?

[Gary Gregory]

On Mon, Aug 31, 2020 at 9:11 AM Matt Sicker  wrote:

> Git submodules are pointers to other git commits. Therefore, any component
> changes made don’t affect the mono repo until you update said mono repo to
> point to the new commit. If you do this to point at the latest release
> tags, this makes for less updates. Otherwise, you’ll want to figure out a
> CI system for automatically updating submodules to the latest master
> commits as they pass CI.
>

Can that commit be HEAD?

Gary


>
> On Mon, Aug 31, 2020 at 05:17 sebb  wrote:
>
> > On Sun, 30 Aug 2020 at 15:01, Gary Gregory 
> wrote:
> >
> > >
> >
> > > On Sun, Aug 30, 2020 at 9:47 AM Rob Tompkins 
> wrote:
> >
> > >
> >
> > > >
> >
> > > >
> >
> > > > > On Aug 30, 2020, at 9:44 AM, sebb  wrote:
> >
> > > > >
> >
> > > > > Some questions:
> >
> > > > >
> >
> > > > > - does it affect any existing usage?
> >
> > > > >  i.e. can people continue to use the individual repos exactly as
> > before
> >
> > > >
> >
> > > > no they can’t
> >
> > > >
> >
> > >
> >
> > > Yes they can... this would be a new repo, and changes nothing for
> current
> >
> > > usage. This does not affect existing repos.
> >
> >
> >
> > What about my other queries?
> >
> >
> >
> > - changes to commit messages:
> >
> >  can people commit to components directly from the new repo?
> >
> > If so, does that change the commit messages?
> >
> >
> >
> > - maintenance of the new repo:
> >
> > what is involved, and how will the project know when updates are needed?
> >
> >
> >
> > > Gary
> >
> > >
> >
> > > >
> >
> > > > >
> >
> > > > > - does it affect Git emails in any way?
> >
> > > > >  e.g. do they have different text?
> >
> > > >
> >
> > > > same emails
> >
> > > >
> >
> > > > >
> >
> > > > > - will it need much maintenance?
> >
> > > > > If so, how do we know when it needs updating?
> >
> > > >
> >
> > > > more maintainance, have to maintain a git hash at a symlink pointing
> > to an
> >
> > > > external repository
> >
> > > >
> >
> > > > -Rob
> >
> > > >
> >
> > > > >
> >
> > > > > On Sun, 30 Aug 2020 at 14:26, Gary Gregory  >
> >
> > > > wrote:
> >
> > > > >>
> >
> > > > >> Yes yes "girl" -> "git"
> >
> > > > >>
> >
> > > > >> On Sun, Aug 30, 2020, 09:24 Gary Gregory 
> >
> > > > wrote:
> >
> > > > >>
> >
> > > > >>> I'm talking about girl's own submodules:
> >
> > > > >>>
> >
> > > > >>> https://git-scm.com/book/en/v2/Git-Tools-Submodules
> >
> > > > >>>
> >
> > > > >>> https://git-scm.com/docs/git-submodule
> >
> > > > >>>
> >
> > > > >>> Gary
> >
> > > > >>>
> >
> > > > >>> On Sun, Aug 30, 2020, 09:09 Rob Tompkins 
> > wrote:
> >
> > > > >>>
> >
> > > >  By git submodules, are you talking about a symlink to another
> git
> >
> > > >  repository inside one of our repositories?
> >
> > > > 
> >
> > > >  -Rob
> >
> > > > 
> >
> > > > > On Aug 29, 2020, at 6:52 PM, Gary Gregory <
> > garydgreg...@gmail.com>
> >
> > > >  wrote:
> >
> > > > >
> >
> > > > > Hi All,
> >
> > > > >
> >
> > > > > Any thoughts for or against creating a new git repository which
> > would
> >
> > > > > contain all 'proper' Commons components as git submodules?
> >
> > > > >
> >
> > > > > The idea is to be able to checkout all of Commons 'proper' in
> > one go
> >
> > > > in
> >
> > > >  one
> >
> > > > > place.
> >
> > > > >
> >
> > > > > Gary
> >
> > > > 
> >
> > > > 
> >
> > > > 
> > -
> >
> > > >  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >
> > > >  For additional commands, e-mail: dev-h...@commons.apache.org
> >
> > > > 
> >
> > > > 
> >
> > > > >
> >
> > > > >
> -
> >
> > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >
> > > > > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> > > > >
> >
> > > >
> >
> > > >
> >
> > > > -
> >
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> > > >
> >
> > > >
> >
> >
> >
> > -
> >
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
> >
> > --
> Matt Sicker 
>

Re: [All] New repo for all proper components as submodules?

[Matt Sicker]

Git submodules are pointers to other git commits. Therefore, any component
changes made don’t affect the mono repo until you update said mono repo to
point to the new commit. If you do this to point at the latest release
tags, this makes for less updates. Otherwise, you’ll want to figure out a
CI system for automatically updating submodules to the latest master
commits as they pass CI.

On Mon, Aug 31, 2020 at 05:17 sebb  wrote:

> On Sun, 30 Aug 2020 at 15:01, Gary Gregory  wrote:
>
> >
>
> > On Sun, Aug 30, 2020 at 9:47 AM Rob Tompkins  wrote:
>
> >
>
> > >
>
> > >
>
> > > > On Aug 30, 2020, at 9:44 AM, sebb  wrote:
>
> > > >
>
> > > > Some questions:
>
> > > >
>
> > > > - does it affect any existing usage?
>
> > > >  i.e. can people continue to use the individual repos exactly as
> before
>
> > >
>
> > > no they can’t
>
> > >
>
> >
>
> > Yes they can... this would be a new repo, and changes nothing for current
>
> > usage. This does not affect existing repos.
>
>
>
> What about my other queries?
>
>
>
> - changes to commit messages:
>
>  can people commit to components directly from the new repo?
>
> If so, does that change the commit messages?
>
>
>
> - maintenance of the new repo:
>
> what is involved, and how will the project know when updates are needed?
>
>
>
> > Gary
>
> >
>
> > >
>
> > > >
>
> > > > - does it affect Git emails in any way?
>
> > > >  e.g. do they have different text?
>
> > >
>
> > > same emails
>
> > >
>
> > > >
>
> > > > - will it need much maintenance?
>
> > > > If so, how do we know when it needs updating?
>
> > >
>
> > > more maintainance, have to maintain a git hash at a symlink pointing
> to an
>
> > > external repository
>
> > >
>
> > > -Rob
>
> > >
>
> > > >
>
> > > > On Sun, 30 Aug 2020 at 14:26, Gary Gregory 
>
> > > wrote:
>
> > > >>
>
> > > >> Yes yes "girl" -> "git"
>
> > > >>
>
> > > >> On Sun, Aug 30, 2020, 09:24 Gary Gregory 
>
> > > wrote:
>
> > > >>
>
> > > >>> I'm talking about girl's own submodules:
>
> > > >>>
>
> > > >>> https://git-scm.com/book/en/v2/Git-Tools-Submodules
>
> > > >>>
>
> > > >>> https://git-scm.com/docs/git-submodule
>
> > > >>>
>
> > > >>> Gary
>
> > > >>>
>
> > > >>> On Sun, Aug 30, 2020, 09:09 Rob Tompkins 
> wrote:
>
> > > >>>
>
> > >  By git submodules, are you talking about a symlink to another git
>
> > >  repository inside one of our repositories?
>
> > > 
>
> > >  -Rob
>
> > > 
>
> > > > On Aug 29, 2020, at 6:52 PM, Gary Gregory <
> garydgreg...@gmail.com>
>
> > >  wrote:
>
> > > >
>
> > > > Hi All,
>
> > > >
>
> > > > Any thoughts for or against creating a new git repository which
> would
>
> > > > contain all 'proper' Commons components as git submodules?
>
> > > >
>
> > > > The idea is to be able to checkout all of Commons 'proper' in
> one go
>
> > > in
>
> > >  one
>
> > > > place.
>
> > > >
>
> > > > Gary
>
> > > 
>
> > > 
>
> > > 
> -
>
> > >  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>
> > >  For additional commands, e-mail: dev-h...@commons.apache.org
>
> > > 
>
> > > 
>
> > > >
>
> > > > -
>
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
>
> > > >
>
> > >
>
> > >
>
> > > -
>
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>
> > > For additional commands, e-mail: dev-h...@commons.apache.org
>
> > >
>
> > >
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
>
> --
Matt Sicker 

Re: [All] New repo for all proper components as submodules?

[sebb]

On Sun, 30 Aug 2020 at 15:01, Gary Gregory  wrote:
>
> On Sun, Aug 30, 2020 at 9:47 AM Rob Tompkins  wrote:
>
> >
> >
> > > On Aug 30, 2020, at 9:44 AM, sebb  wrote:
> > >
> > > Some questions:
> > >
> > > - does it affect any existing usage?
> > >  i.e. can people continue to use the individual repos exactly as before
> >
> > no they can’t
> >
>
> Yes they can... this would be a new repo, and changes nothing for current
> usage. This does not affect existing repos.

What about my other queries?

- changes to commit messages:
 can people commit to components directly from the new repo?
If so, does that change the commit messages?

- maintenance of the new repo:
what is involved, and how will the project know when updates are needed?

> Gary
>
> >
> > >
> > > - does it affect Git emails in any way?
> > >  e.g. do they have different text?
> >
> > same emails
> >
> > >
> > > - will it need much maintenance?
> > > If so, how do we know when it needs updating?
> >
> > more maintainance, have to maintain a git hash at a symlink pointing to an
> > external repository
> >
> > -Rob
> >
> > >
> > > On Sun, 30 Aug 2020 at 14:26, Gary Gregory 
> > wrote:
> > >>
> > >> Yes yes "girl" -> "git"
> > >>
> > >> On Sun, Aug 30, 2020, 09:24 Gary Gregory 
> > wrote:
> > >>
> > >>> I'm talking about girl's own submodules:
> > >>>
> > >>> https://git-scm.com/book/en/v2/Git-Tools-Submodules
> > >>>
> > >>> https://git-scm.com/docs/git-submodule
> > >>>
> > >>> Gary
> > >>>
> > >>> On Sun, Aug 30, 2020, 09:09 Rob Tompkins  wrote:
> > >>>
> >  By git submodules, are you talking about a symlink to another git
> >  repository inside one of our repositories?
> > 
> >  -Rob
> > 
> > > On Aug 29, 2020, at 6:52 PM, Gary Gregory 
> >  wrote:
> > >
> > > Hi All,
> > >
> > > Any thoughts for or against creating a new git repository which would
> > > contain all 'proper' Commons components as git submodules?
> > >
> > > The idea is to be able to checkout all of Commons 'proper' in one go
> > in
> >  one
> > > place.
> > >
> > > Gary
> > 
> > 
> >  -
> >  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >  For additional commands, e-mail: dev-h...@commons.apache.org
> > 
> > 
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [All] New repo for all proper components as submodules?

[Romain Manni-Bucau]

+1, sounds like a good transversal and optional/not invasive addition.
Would we get any CI "check" job to ensure we don't miss a (new) repo or
kept an old one?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 31 août 2020 à 08:49, Thomas Vandahl  a écrit :

> On 30.08.20 00:52, Gary Gregory wrote:
> > Hi All,
> >
> > Any thoughts for or against creating a new git repository which would
> > contain all 'proper' Commons components as git submodules?
> >
> > The idea is to be able to checkout all of Commons 'proper' in one go in
> one
> > place.
>
> I understand this is in addition to the current repos?
>
> Bye, Thomas
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [All] New repo for all proper components as submodules?

[Thomas Vandahl]

On 30.08.20 00:52, Gary Gregory wrote:

Hi All,

Any thoughts for or against creating a new git repository which would
contain all 'proper' Commons components as git submodules?

The idea is to be able to checkout all of Commons 'proper' in one go in one
place.


I understand this is in addition to the current repos?

Bye, Thomas

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org