Hi, before this is even considered, you should state what is the problem (at that means concretely), then describe the options to solve it, then pose why submodules fix it, then describe the problems of submodules, then describe why the workflow of all other developers needs to be broken, then describe the consequences for the buildsystem. As you can see there is a long list of things to do, before even considering introducing a new technology into the netbeans build system.
To be frank: What is the f****** problem? Cloning the netbeans repository with a depth of 1 results in this: matthias@athena:~/tmp$ time git clone --depth=1 [email protected]:apache/netbeans.git Cloning into 'netbeans'... remote: Enumerating objects: 95646, done. remote: Counting objects: 100% (95646/95646), done. remote: Compressing objects: 100% (61517/61517), done. remote: Total 95646 (delta 36963), reused 57418 (delta 22084), pack-reused 0 Receiving objects: 100% (95646/95646), 87.47 MiB | 2.68 MiB/s, done. Resolving deltas: 100% (36963/36963), done. Updating files: 100% (80311/80311), done. real 0m58.594s user 0m9.030s sys 0m3.475s matthias@athena:~/tmp$ This means: ~ 90MB are cloned in under 60s. This test was executed from a hotel wlan, from a fixed connection it would have even been quicker. I also tried a full clone: matthias@athena:~/tmp$ time git clone [email protected]:apache/netbeans.g it Cloning into 'netbeans'... remote: Enumerating objects: 14, done. remote: Counting objects: 100% (14/14), done. remote: Compressing objects: 100% (12/12), done. remote: Total 327867 (delta 3), reused 5 (delta 2), pack-reused 327853 Receiving objects: 100% (327867/327867), 194.90 MiB | 2.76 MiB/s, done. Resolving deltas: 100% (181522/181522), done. Updating files: 100% (80311/80311), done. real 1m21.883s user 0m23.210s sys 0m5.686s matthias@athena:~/tmp$ For repeated contributions this is a one-time action. My gut feeling is, that the size of the binaries required for building is larger. If you think, that you can build a cluster of netbeans independently from the others you are wrong, there are dependencies between the clusters and some of these are not just friend dependencies, but implementation dependencies. Yes that is all solveable, but at what price? Sorry if this sounded rude, but I've seen such "sounds like a good idea, lets do it" actions in the past and had to cleanup the mess, that resulted. Greetings Matthias Am Montag, den 07.09.2020, 09:08 +0200 schrieb Czukowski: > IMHO the value of splitting the source code into multiple > repositories > would really come up if it were possible (and practical) to develop > NetBeans modules independently, for example, clone a module repo, > work > on it, then run/test it using an already built IDE, then release the > module update (increment the version, etc). And when the time comes > to > release new NetBeans version, build script would pull all the pieces > together. > > Then again, they don't necessarily need to be git submodules as they > could prove to be a little hard to use due to having to link them > all > using git and re-link on each update. It would suffice if the build > script just knew where to get them (eg. repo URLs), then if a > specific > cluster is build, it wouldn't be necessary to download all of them. > > Regards. > > 06.09.2020 16:15, Eric Bresie wrote: > > While reading an article recently, the topic of git submodules came > > up, which I started looking up the topic (1). > > > > Given the size of the netbeans code base and the complexity of > > other projects inclusion like the specific plugin/clusters, etc., I > > was wondering if it’s worth considering breaking out some of these > > elements into separate submodule projects. > > > > This would reduce the overall size of the netbeans project (but the > > placeholder submodule - normally empty until submodule is pulled) > > and would allow each submodule to be managed independently. > > > > The drawback may be a little learning curve on submodule usage > > which may add to some issues initially as well as a few extra steps > > during builds. > > > > (1) https://git-scm.com/book/en/v2/Git-Tools-Submodules > > Eric Bresie > > [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
