On Mon, Jan 22, 2018 at 2:58 PM, 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. > That reminds me that just like when I cast a VOTE I try to say what I did and how. I would be nice if we had a 'build log' the RM would save some place when putting up an RC. Gary > > 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> >
