Hi, > On 18 Jun 2018, at 14:45, Eugen Stan <[email protected]> wrote: > > Hello Radu, > > Thanks for the tip. I did not knew that. I have tried it with the full > aggregator and the IDE is quite unresponsive and it's not for lack of > resources. I have SSD drive and 12GB of RAM.
My instance of IntelliJ is configured to use 2GB of heap and it can handle the whole Sling codebase. > > I will try to combine the advice Robert gave and yours and make them > work together but the experience so far is not great. > > How are you working on Sling? Although I work mainly on scripting, I prefer to have all the codebase available so that I can inspect other modules easier rather than downloading the sources for each dependency. I’ve also enabled the Git + JIRA integrations for Sling, so that I can benefit from autogenerated commit messages - very useful when your changes span across different modules (this happens a lot for HTL). > > > The question that I am looking for an answer is: > > Having all of these modules requires some mental effort to navigate, > especially for Sling beginners like me. Does a Sling developer need to > have access to all of them all the time? I imagine the answer is No. I > imagine things are logically grouped into related projects. Instead of > having this flat hierarchy, can we make it more nested? I can identify > some projects like: sling-discovery, sling-models, sling-launchpad, > sling-karaf, sling-scripting, sling-auth , etc. > > I believe grouping those modules with git-repo (and not git submodules) > would be an improvement in being easy to work on specific area of Sling > functionality. > > I imagine that working on Sling Karaf or Sling Scripting does not > require me to update Sling API at the same time. Even if that was the > case, I would still have to get through the community to discuss/approve > the changes to the lower level API. > > Having those modules grouped by logical functionality into directories, > I (a developer) can open just that part of Sling and not be bothered > with the rest of the project. I think it reduces the mental effort that > I have to deal with and does not lose flexibility. Correct. You technically need only the group where your module is and I guess the groups the aggregator defines are more or less what we used to have before in SVN. The only difference now is the flat file-system structure. Several ideas floated around regarding how we should organise a full-checkout on the filesystem and IIRC two of them resonated with the developer community: 1. tree structure + autogenerated reactor POMs, that emulates the previous setup 2. flat structure + autogenerated reactor POMs Unfortunately nobody had time to implement either of them. > > > Regards, > > Eugen Cheers, Radu
