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 > <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 <mailto:garydgreg...@gmail.com> | > ggreg...@apache.org <mailto:ggreg...@apache.org> > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/> > Home: http://garygregory.com/ <http://garygregory.com/> > Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory> > > > -- > Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>> > > > > -- > Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>> > > > > -- > E-Mail: garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> | > ggreg...@apache.org <mailto:ggreg...@apache.org> > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/> > Home: http://garygregory.com/ <http://garygregory.com/> > Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory> > > > -- > Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
