On Sat, Oct 24, 2015 at 4:21 PM, David Jencks <[email protected]> wrote: > I like having several felix subprojects open in one eclipse instance at once, > which the current svn structure facilitates. Having just one git svn rebase > to run is nice. Is there a way to stitch together several smaller git repos > that would work similarly? Not knowing how to do this, I am starting to lean > towards one big repo.
Well, there are git submodules. But I hate to take everyone into that rabbit hole. I think we should aim to start with one big repo and assume we can tame the maven-release-plugin to start with. > > FWIW, I’m hoping to move DS onto a gradle based build soon. > > thanks > david jencks > >> On Oct 24, 2015, at 2:51 PM, Benson Margulies <[email protected]> wrote: >> >> Greeting, Marcel, >> >> It's not my intention to try to talk anyone into changing how they >> release anything. For the things that are built with Maven, it's my >> preference to avoid exercising the maven-release-plugin's feature of >> handling multiple released items in a repo, but it's just a >> preference. If the acceptable compromise is to have less repos than >> releasable items (possibly as few as one repo), I'd personally rather >> do that than not move to git at all. >> >> regards, >> >> benson >> >> >> On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans >> <[email protected]> wrote: >>> On 24 October 2015 at 11:36:03, Benson Margulies >>> ([email protected](mailto:[email protected])) wrote: >>> >>>>> So I would definitely argue against getting a Git repository per bundle. >>>>> Per subproject sounds like the right granularity to me. >>>> >>>> If a subproject is released all at once, then we're completely >>>> agreeing. If not, then your preference means exercising the >>>> occasionally squishy part of the release plugin; maybe it will get >>>> fixed once and for all. >>> >>> So for the dependency manager we reasoned as follows: >>> >>> 1) When talking about releases within Apache, we are talking about source >>> code. Releasing that a subproject at a time makes sense to me as the code, >>> even if it ends up in different bundles, clearly belongs together. >>> >>> 2) Binary releases are a matter of convenience and “what is convenient” >>> depends a lot on where you’re coming from. A lot of people would argue that >>> putting a binary in Maven is convenient, but there are definitely other >>> options. The binary releases also don’t have to have a 1:1 mapping with the >>> source, so we can have N bundles being put in Maven and other repositories >>> all from the same source release. >>> >>> Greetings, Marcel >>> >>> >
