merge git submodules back into main repo

[shroffk]

Restructuring the repo to move some git sub modules back into the main repo.

[shroffk]

Moved bundleJava into the epicsCoreJava repo

[ralphlange]

How are we going to handle the tags?

[shroffk]

How are we going to handle the tags?

https://docs.google.com/document/d/1Oe6aDGxId6R1nANHD1Kxs9tH7caE832eULO6JueX1YA/edit#

[shroffk]

@ralphlange @mrkraimer can this be merged now...

[ralphlange]

Have you moved a copy of the current status to epics-rip? Updated the submodules so they point to the correct URLs? Did a test check-out of an old tag to make sure we don't tell BS in this readme?

[ralphlange]

Or do you want me to do that?

[shroffk]

I have not moved...not sure what should happen first. The PR or the move.
I had assumed we would simply transfer ownership to epics-rip

[anjohnson]

Transferring ownership causes Github to set up redirects at the old URLs, and also moves all of the issues and PRs as well. That might not be what you want, unless you're going to rename the merged result as well (this would probably be the time to change the name if you do want to do that though).

[shroffk]

I can fork the above repo's into epics-rip and then remove them from epics-base after moving the appropriate issues onto epicsCoreJava.

@ralphlange could you help with the refactoring of the gitsubmodule paths

I am tempted with remove the "Java" from all the names. Does anyone else agree with this or feels strongly about this? @kasemir @mrkraimer @mdavidsaver @ralphlange

[ralphlange]

-1

Changing repository names without technical justification is bikeshedding.

Changing the name after ten years when retiring repositories is meta-bikeshedding.

Remember that the main (if not only) use of the move is to be able to checkout old releases, which makes it similar to archiving the repos. Changing their names when archiving things is neither clear nor useful.

[shroffk]

ok @ralphlange no name change now...let us just close this PR for now.

[ralphlange]

Didn't want to sound harsh...

See, it's called epics-rip for a reason. Your proposal sounds like taking the funeral as a opportunity to change the name on the headstone. Which ... won't help people looking for the grave, will it?

[shroffk]

I have forked all the pertinent repos to the epics-rip organization.
Here are the links..
https://github.com/epics-rip/pvDataJava
https://github.com/epics-rip/pvAccessJava
https://github.com/epics-rip/normativeTypesJava
https://github.com/epics-rip/bundleJava

[ralphlange]

Update: I was playing around with this a bit. This is not as trivial as it seemed in the first place. Hm, well, maybe it is.

Submodule URLs are part of the repository. i.e. past releases will always point to the old URLs. Changing URLs in the repository needs a commit thus does not work with old releases.

Renaming the moved repositories is not advisable. (See above comment. It might also not work with the redirects generated by an ownership change.)
Renaming the merged parent result could be done as it does not change much. (Everyone will have to use the new name for the parent repo; embedded names of submodules will stay the same.)

I can see two options:

1. Forking the existing repos into epics-rip (as it is done now). Existing issues and pull requests stay at the old place. Checking out an older version needs client side configuration (rewriting URLs for the moved repos). That setup needs to be documented and tested. What are we doing with the old repos? Delete them? (What about the issues and PRs then?)
2. Changing ownership of the existing repos. This will setup Git and URL redirects, so that checking out old releases should work without client side changes. It will move existing issues and PRs, so that they stay around for examination and archiving. It will make the existing repos disappear, so they don't confuse people.

I would say 2. seems to be the better option.
What do you say? @anjohnson @shroffk @berryma4 @mdavidsaver

[anjohnson]

I agree that changing the repo ownership is the better solution. I almost wrote that as a comment yesterday but got distracted...

[shroffk]

I had initially suggested option 2. so I think I will come back to supporting it :)

[ralphlange]

So, yes, please go ahead.
Merge, remove the forks in epics-rip, transfer ownership of the retired repos to epics-rip.

[georgweiss]

I'm not on the review list, so I'll just ask a question: are all Java models to be found under https://github.com/epics-base/epicsCoreJava once the PR is merged?

[ralphlange]

All modules that are affected by the merge, yes.

[ralphlange]

The main goal is - for this set of closely related modules - being able to do PullRequests that concern multiple modules.

In the existing separate repo layout, that used to be a set of PRs (one for each repo), and no CI can do automated multi-PR builds across repositories.

[georgweiss]

I'm a bit confused... Is the merge completed? A Maven build shows that the pom file is missing from four submodules.

[ralphlange]

For which modules? Are you sure you checked out the remaining Git submodules recursively?

[georgweiss]

pvaClientJava, pvaDatabaseJava, directoryService and exampleJava. I have not done any recursive checkout, I thought the purpose was to have all modules under a common "parent" that would - when cloned - contain all required modules. My point is that these modules are referenced in the top level pom, which Maven picks up but fails to build.

[ralphlange]

Only the core modules (that are closely coupled) have been merged. The loosely coupled modules (like client and server helpers and examples) stay in separate repos and are linked using Git submodules.

Please do a full recursive checkout with submodules, and all will compile fine. (Works for me and Travis.)