My recollection is vague, tied to pom machinations supporting a similar separation for the 'log4j companions': outside of core log4j - chainsaw, component, extras, receivers and zeroconf'
Some of the issues I recall having to deal with when we had the generic 'component' module: - Some classes start out in one module, like the 'component' module, but then it turns out something in core could benefit from that same class, so it's pulled in to core. This could result in a class rename or package move in the process in order to match the structure of core, naming conventions, etc. If we did this only at a 'backward-compatibility breaking' boundary that would be ok, it can just be confusing and unnecessary if we have one module. We also had the entire 'component' module sucked in to the 'receivers' module when we felt that the separation wasn't useful, with Receivers eventually getting pulled in to Chainsaw, where it didn't really belong IMO.. So my worry is about things getting 'promoted and moved' because they are now useful somewhere else, and the confusion that can ensue. On 1/22/18, Gary Gregory <garydgreg...@gmail.com> wrote: > On Mon, Jan 22, 2018 at 3:54 PM, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > >> >> >> > On Jan 22, 2018, at 3:44 PM, Gary Gregory <garydgreg...@gmail.com> >> wrote: >> > >> > On Mon, Jan 22, 2018 at 3:25 PM, Matt Sicker <boa...@gmail.com> wrote: >> > >> >> The profiles idea would help a lot for local development and making it >> >> easier to run the relevant unit tests when modifying code. This >> >> wouldn't >> >> really help the release process, though, as we'd either need to >> >> release >> >> everything in the repo at once, or we'd end up with unreleased modules >> >> being tagged on release of anything else in the same repo. >> >> >> > >> > Ah... but you COULD make it help in the release just as well but >> > putting >> > what you are releasing into the main profile! That's the beauty of it. >> > Sure, you'd tag the whole thing as one. Presumably, you'd think the RM >> > would make sure at least everything compiles ;-) >> >> I don’t understand. If I perform a release for 2.11.0 and skip certain >> modules they are not going to have their versions updated. They will be >> pointing at 2.11.0-SNAPSHOT as a parent even though the parent has been >> changed to 2.11.1-SNAPSHOT. >> > > The way I see it is that you'd update the POM versions _as if_ you were to > release and had released the modules that in fact are skipped. For example, > if log4j-foo is not in the main-modules profile, it's versions would go > from 2.11.0-SNAPSHOT to 2.11.1-SNAPSHOT. I suppose that might means an > adjustment to a current step or an extra step. > > Gary > > >> >> If I assume all the pom versions are the same at 2.11.0-SNAPSHOT and only >> want to release the mongodb plugin it will update the parent pom and >> mongodb pom to the next version - let’s say 2.11.1-SNAPSHOT. I now cannot >> release log4j as 2.11.0 since the parent pom has already released 2.11.0. >> So you are going to have version numbers skipping all around. >> >> Ralph >> >> >> >
