Correcting my prior comment: the nightmare I was referring to was the ugliness we did and un-did related to the never-released receivers and 'component' companions. Definitely feels like deja vu.
https://github.com/apache/log4j-component/blob/trunk/pom.xml apache-log4j-companions-parent etc etc On 1/22/18, Matt Sicker <boa...@gmail.com> wrote: > Using Maven profiles could help, though when tagging a release, if we > didn't release every module within, then it'd get out of sync anyways. Then > it would still require building every single component in each release, > even when said components haven't changed at all. > > On 22 January 2018 at 15:50, Gary Gregory <garydgreg...@gmail.com> wrote: > >> Coming back around to the idea of One Repo to Rule Them All*TM* ... what >> if >> we used Maven profiles to separate out the "main" build from "other" >> builds? >> >> All that is needed to move modules from one build to another is just to >> edit the profile! >> >> Gary >> >> On Mon, Jan 22, 2018 at 12:48 PM, Ralph Goers >> <ralph.go...@dslextreme.com> >> wrote: >> >> > I don’t see why this work would require 3.0 as we aren’t planning on >> > breaking any contracts to do this. >> > >> > As I’ve said, I am not tied to each plugin having its own repo. I am OK >> > with these options; a) each plugin has its own repo and site and is >> > released independently, b) we use the plugins repo and move all the >> > more >> > lightly used components there. It would have its own site, or c) we >> > group >> > plugins by how they are related (RDBMS, NoSQL, “Transport” (Flume or >> > similar) with each having its own site. >> > >> > Obviously I do not consider continuing to add new plugins to the main >> > build as one of the options. >> > >> > Ralph >> > >> > > On Jan 22, 2018, at 12:36 PM, Matt Sicker <boa...@gmail.com> wrote: >> > > >> > > This whole conversation just reminds me of all the times in the past >> > > I >> > > suggested full modularization of the core API/SPI. I think such an >> effort >> > > would make sense in a 3.0 release. >> > > >> > > In 2.x, perhaps what we can do is define a stable plugin API based on >> > what >> > > we already have. Since we're still supporting Java 7, I'd suggest we >> make >> > > abstract classes be the stable part of the API since we don't have >> > default >> > > methods on interfaces here. >> > > >> > > And yes, the GitBox integration thing sounds neat, particularly for >> code >> > > review, though that's a separate topic entirely. >> > > >> > > On 22 January 2018 at 00:37, Gary Gregory <garydgreg...@gmail.com> >> > wrote: >> > > >> > >> On Sun, Jan 21, 2018 at 4:14 PM, Ralph Goers < >> > ralph.go...@dslextreme.com> >> > >> wrote: >> > >> >> > >>> I am very much against the idea of a single repo. Yes, you can have >> > >>> multiple projects in the repo but I am not sure how that can be >> sanely >> > >>> released. I much prefer the model that Maven has taken. They are >> > >>> now >> > >> using >> > >>> gitbox [1] which seems to allow GitHub to be the primary repo. >> > >> >> > >> >> > >> GitHub is a distracting tangent here IMO. I really like GitHub's >> > >> code >> > >> commenting feature, but it should not matter if we use Apache's Git >> > hosted >> > >> repos or GitHub's. So I'm not sure why we are mixing GitHub in the >> > >> conversation... ;-) >> > >> >> > >> Gary >> > >> >> > >> >> > >>> Every Maven plugin is individually released. Scroll down the link >> below >> > >> to >> > >>> the Maven section and you can see all the plugin repos. >> > >>> >> > >>> The upside to this is that it are: >> > >>> 1. It is far easier to perform releases of the individual >> > >>> components. >> > >>> 2. It is much easier to accept plugin contributions. >> > >>> The downsides are: >> > >>> 1. A page like https://maven.apache.org/plugins/ < >> > >>> https://maven.apache.org/plugins/> is needed to keep track of the >> > plugin >> > >>> versions. >> > >>> 2. It could make sense to have log4j-parent and log4j-bom >> > >>> projects. The first to help keep the builds similar and the second >> > >>> to >> > >> help >> > >>> customers pick up the latest versions. >> > >>> >> > >>> Ralph >> > >>> >> > >>> [1] https://gitbox.apache.org/repos/asf <https://gitbox.apache.org/ >> > >>> repos/asf> >> > >>> >> > >>>> On Jan 21, 2018, at 8:55 AM, Gary Gregory <garydgreg...@gmail.com> >> > >>> wrote: >> > >>>> >> > >>>> Hi All, >> > >>>> >> > >>>> I am writing this to in an effort to understand how we can manage >> and >> > >>> grow >> > >>>> Log4j. I use the term 'grow' not in the 'bigger is better' sense >> > >>>> but >> > >> more >> > >>>> in the maturing sense. >> > >>>> >> > >>>> I am prompted to write this by Ralph's comment that log4j-core and >> the >> > >>> main >> > >>>> repo is too big and that releases take too long make, partially >> > >> prompted >> > >>> by >> > >>>> my addition of a new module called log4j-jdbc-dbcp2 which >> > >>>> currently >> > >>>> contains one small class with a dependency on Apache Commons DBCP >> > >>>> 2. >> > >>>> >> > >>>> I would like to express my gratitude at Ralph's efforts to >> revitalized >> > >>>> Log4j and performing most release management duties. Thank you >> Ralph! >> > >>>> >> > >>>> I can see two main orthogonal issues: >> > >>>> - The size of the git repo. >> > >>>> - The size of the log4j-core module. >> > >>>> >> > >>>> Ralph has proposed that new modules like log4j-jdbc-dbcp2 be moved >> to >> > >>>> another 'plugin' repo. >> > >>>> >> > >>>> I really dislike this idea: >> > >>>> - The plugin repo has never been released. Not that one releases a >> > repo >> > >>> but >> > >>>> you get the point. >> > >>>> - How do you keep things in sync between repos and code when we >> > >>>> have >> > no >> > >>>> official 'core' SPI. >> > >>>> >> > >>>> For my money, we should keep _everything_ in one repo. Good enough >> for >> > >>>> Google, so good enough for me. What we release out of that repo is >> > >>>> a >> > >>>> different story and what I would like to discuss next. >> > >>>> >> > >>>> This is not the same as Maven plugins IMO but the case could be >> > >>>> made >> > >> for >> > >>> it >> > >>>> I suppose where a lot/most plugins live in their own repos. It is >> not >> > >> the >> > >>>> same as with Maven IMO because our plugins rely on log4j-core and >> it's >> > >>>> guts, for which we only make loose compatibility guarantees -- as >> > >> opposed >> > >>>> to log4j-core where we are strict(er). Maven OTOH, has a API for >> > plugin >> > >>>> auteurs. >> > >>>> >> > >>>> For example, log4j-jdbc-dbcp2 replies on the guts of log4j-core >> > >>>> and >> we >> > >>> have >> > >>>> no 'official' core SPI, so splitting it off into a separate repo >> would >> > >>>> greatly increase the risk of it falling out of sync. It is just so >> > much >> > >>>> more easier to maintain when it is all in one repo. >> > >>>> >> > >>>> My proposal is to: >> > >>>> >> > >>>> - Put everything back into one repo (Chainsaw too?) >> > >>>> - Define a core SPI for plugin writers where we make some >> > >>>> statement >> > >> about >> > >>>> BC, more than the casual 'we try not break stuff.' >> > >>>> - Defining what Log4j project 'components' we have and release >> > >>>> based >> > on >> > >>>> that. For example, today, all of the main Log4j repo is one >> component >> > >>> with >> > >>>> many modules. Chainsaw would be another component of the Log4j >> > project. >> > >>>> Maybe we need to redefine components: API, File, JDBC and so on. A >> > >>>> component can have one of more module >> > >>>> - Got for there. >> > >>>> >> > >>>> Thoughts? Help me flush this out? >> > >>>> >> > >>>> Thank you for reading! >> > >>>> Gary >> > >>> >> > >>> >> > >> >> > > >> > > >> > > >> > > -- >> > > Matt Sicker <boa...@gmail.com> >> > >> > >> > >> > > > > -- > Matt Sicker <boa...@gmail.com> >
