Can anyone send a link to the release procedures? Sent from my iPhone
> On 1 Oct 2016, at 2:31, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > I would have a “core” project and an “extras”, “extensions” or some other > name. They are all already separate jars. I just want to split them out > because they don’t (or shouldn’t) change nearly as often as the core stuff - > although we may get to the point where core is pretty stable and we are > actually adding to the extensions more than we are working on core. > > If you look at Maven it has every plugin in its own project. I am not really > looking for that. I am just looking for ways to make the release process less > time consuming. > > Ralph > > > >> On Sep 30, 2016, at 10:08 AM, Matt Sicker <boa...@gmail.com> wrote: >> >> Increased modularity is the OSGi way, but it's also a hard thing to convince >> people of. I've met many developers (notably Spring fanboys) that are still >> in a monolithic classpath mindset of "why bother splitting this up?" >> >> Anyways, Ralph, are you proposing spinning out the non-core stuff into a >> single Logging Services project, or multiple ones that can be released as >> needed? >> >>> On 30 September 2016 at 12:05, Gary Gregory <garydgreg...@gmail.com> wrote: >>> Right, hence this thread ;-) I am not hot about having multiple builds FYIW. >>> >>> Gary >>> >>>> On Fri, Sep 30, 2016 at 9:59 AM, Matt Sicker <boa...@gmail.com> wrote: >>>> Oh wait, Ralph is talking about something else entirely. >>>> >>>>> On 30 September 2016 at 11:58, Matt Sicker <boa...@gmail.com> wrote: >>>>> I think log4j-nosql could be merged into log4j-core. >>>>> >>>>>> On 30 September 2016 at 11:50, Gary Gregory <garydgreg...@gmail.com> >>>>>> wrote: >>>>>> Ralph recently mentions that he'd like some modules removed while Matt >>>>>> mentioned merging some back into Core. >>>>>> >>>>>> Shall we discuss this on the ML instead of Jira? >>>>>> >>>>>> I could also see doing an uber jar (mod the mutually exclusive jars) and >>>>>> reorging the system with a smaller core (everything except appenders), >>>>>> an all-appenders module, and/or what some folks have mentioned: one >>>>>> module per appender (yikes!) >>>>>> >>>>>> What are all the options we should consider? >>>>>> >>>>>> Personally and for the current projects I have involved in, an uber jar >>>>>> with optional deps is the simplest to deal with. If I had to do an app >>>>>> for a light bulb, I'd think differently ;-) >>>>>> >>>>>> (Let's leave Java 9 modules out of the discussion!) >>>>>> >>>>>> Gary >>>>>> >>>>>> -- >>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>> Java Persistence with Hibernate, Second Edition >>>>>> JUnit in Action, Second Edition >>>>>> Spring Batch in Action >>>>>> Blog: http://garygregory.wordpress.com >>>>>> Home: http://garygregory.com/ >>>>>> Tweet! http://twitter.com/GaryGregory >>>>> >>>>> >>>>> >>>>> -- >>>>> Matt Sicker <boa...@gmail.com> >>>> >>>> >>>> >>>> -- >>>> Matt Sicker <boa...@gmail.com> >>> >>> >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> Java Persistence with Hibernate, Second Edition >>> JUnit in Action, Second Edition >>> Spring Batch in Action >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >> >> >> >> -- >> Matt Sicker <boa...@gmail.com> >