My personal opinion: clusters are an organization we already have in place, one based on some criteria. There may be some imperfection, but it is hard to imagine an organization that would not have any. Choosing another organization means someone will need to lead a discussion, pick criteria, pick group names, pick modules that belong to individual groups, etc. This is likely to lead to a bikeshed. So, unless there's someone (Tim?) who wants do that work, using clusters seems to make sense.
I don't foresee too many moves of modules from one cluster to another, and if that happens, it is a matter of running "git mv", does not feel like it should be too hard to move modules from one cluster to another. Jan On Sun, Aug 19, 2018 at 7:08 AM, Tim Boudreau <[email protected]> wrote: > > > > Clusters form the distribution and functional unit of Apache NetBeans. > > With > > the introduction of ergonomics they are becoming quite visible even for > > end > > users. In no way I'd dare to call them arbitrary. > > > > Exactly. They are a unit of binary *packaging*. Which makes them a > strange tool for organizing units of *code*, which might or might not map > to the dependency graph within the code. > > If you are a developer trying to figure out what is what, which seems to me > to be the actual target audience for any organizational schema for a large > project, a more useful split might be (off the top of my head, looking at a > directory listing of my checkout) something like: > > - Platform > - Editor > - Editing > - VersionControl > - Projects > - BuildTools > - Languages / Java | Javascript | XML | ... > - Utilities > - LibraryWrappers > - Testing > - Building > - Debugging > - ... maybe another category or two > > No taxonomy will be perfect - there will always be modules that could make > some sense in more than one category. But short of representing the > dependency graph as a symlink farm, nothing will be. The dependency graph > is reality. Everything else is an arbitrary layer someone invented to make > things easier to understand. So we might as well make it a layer designed > to be understood by the target audience of code - developers - rather than > the packaging units that were convenient for end users of the IDE. > > However that cannot be said about cluster based subdirectories - they > > provide > > a deterministic structure. The location of sources will actually match > > their > > final placement in the product. At the end it may actually be easier for > > developers to find the module they search for. > > > > I was one of the people who pushed hardest for cluster-based distributions > - the whole "module packs" thing. It is *an* organization of things, but > the contents was more driven by marketing concerns - what modules did we > believe users wanted all or none of. There's nothing deterministic about > that - it was decided by a combination of intuition, user research and > technical needs, and all but the last are subject to change. > > -Tim > > -- > http://timboudreau.com >
