You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2016/09/30 16:50:11 UTC
Modules
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: garydgregory@gmail.com | ggregory@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
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Modules
Posted by Ralph Goers <ra...@dslextreme.com>.
I think your opinion would change if you tried to do the release.
Ralph
> On Sep 30, 2016, at 10:05 AM, Gary Gregory <ga...@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 <boards@gmail.com <ma...@gmail.com>> wrote:
> Oh wait, Ralph is talking about something else entirely.
>
> On 30 September 2016 at 11:58, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
> I think log4j-nosql could be merged into log4j-core.
>
> On 30 September 2016 at 11:50, Gary Gregory <garydgregory@gmail.com <ma...@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: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@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 <boards@gmail.com <ma...@gmail.com>>
>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@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>
Re: Modules
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Sep 30, 2016 at 8:03 PM, Remko Popma <re...@gmail.com> wrote:
> Thanks!
>
Were you thinking of doing a release as an "exercise" to improve the
process? ;-)
Gary
>
> Sent from my iPhone
>
> On 1 Oct 2016, at 11:34, Gary Gregory <ga...@gmail.com> wrote:
>
> On Sep 30, 2016 7:15 PM, "Remko Popma" <re...@gmail.com> wrote:
> >
> > Can anyone send a link to the release procedures?
>
> http://wiki.apache.org/logging/Log4j2ReleaseGuide
>
> Gary
> >
> > Sent from my iPhone
> >
> > On 1 Oct 2016, at 2:31, Ralph Goers <ra...@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 <bo...@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 <ga...@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 <bo...@gmail.com>
> wrote:
> >>>>>
> >>>>> Oh wait, Ralph is talking about something else entirely.
> >>>>>
> >>>>> On 30 September 2016 at 11:58, Matt Sicker <bo...@gmail.com> wrote:
> >>>>>>
> >>>>>> I think log4j-nosql could be merged into log4j-core.
> >>>>>>
> >>>>>> On 30 September 2016 at 11:50, Gary Gregory <ga...@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: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Matt Sicker <bo...@gmail.com>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
> >>
> >>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Modules
Posted by Remko Popma <re...@gmail.com>.
Thanks!
Sent from my iPhone
> On 1 Oct 2016, at 11:34, Gary Gregory <ga...@gmail.com> wrote:
>
> On Sep 30, 2016 7:15 PM, "Remko Popma" <re...@gmail.com> wrote:
> >
> > Can anyone send a link to the release procedures?
>
> http://wiki.apache.org/logging/Log4j2ReleaseGuide
>
> Gary
> >
> > Sent from my iPhone
> >
> > On 1 Oct 2016, at 2:31, Ralph Goers <ra...@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 <bo...@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 <ga...@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 <bo...@gmail.com> wrote:
> >>>>>
> >>>>> Oh wait, Ralph is talking about something else entirely.
> >>>>>
> >>>>> On 30 September 2016 at 11:58, Matt Sicker <bo...@gmail.com> wrote:
> >>>>>>
> >>>>>> I think log4j-nosql could be merged into log4j-core.
> >>>>>>
> >>>>>> On 30 September 2016 at 11:50, Gary Gregory <ga...@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: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Matt Sicker <bo...@gmail.com>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
> >>
> >>
Re: Modules
Posted by Gary Gregory <ga...@gmail.com>.
On Sep 30, 2016 7:15 PM, "Remko Popma" <re...@gmail.com> wrote:
>
> Can anyone send a link to the release procedures?
http://wiki.apache.org/logging/Log4j2ReleaseGuide
Gary
>
> Sent from my iPhone
>
> On 1 Oct 2016, at 2:31, Ralph Goers <ra...@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 <bo...@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 <ga...@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 <bo...@gmail.com> wrote:
>>>>>
>>>>> Oh wait, Ralph is talking about something else entirely.
>>>>>
>>>>> On 30 September 2016 at 11:58, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>
>>>>>> I think log4j-nosql could be merged into log4j-core.
>>>>>>
>>>>>> On 30 September 2016 at 11:50, Gary Gregory <ga...@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: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
>>
>>
Re: Modules
Posted by Remko Popma <re...@gmail.com>.
Can anyone send a link to the release procedures?
Sent from my iPhone
> On 1 Oct 2016, at 2:31, Ralph Goers <ra...@dslextreme.com> wrote:
>
> I would have a �gcore�h project and an �gextras�h, �gextensions�h or some other name. They are all already separate jars. I just want to split them out because they don�ft (or shouldn�ft) 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 <bo...@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 <ga...@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 <bo...@gmail.com> wrote:
>>>> Oh wait, Ralph is talking about something else entirely.
>>>>
>>>>> On 30 September 2016 at 11:58, Matt Sicker <bo...@gmail.com> wrote:
>>>>> I think log4j-nosql could be merged into log4j-core.
>>>>>
>>>>>> On 30 September 2016 at 11:50, Gary Gregory <ga...@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: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
>
Re: Modules
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <bo...@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 <garydgregory@gmail.com <ma...@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 <boards@gmail.com <ma...@gmail.com>> wrote:
> Oh wait, Ralph is talking about something else entirely.
>
> On 30 September 2016 at 11:58, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
> I think log4j-nosql could be merged into log4j-core.
>
> On 30 September 2016 at 11:50, Gary Gregory <garydgregory@gmail.com <ma...@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: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@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 <boards@gmail.com <ma...@gmail.com>>
>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@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 <boards@gmail.com <ma...@gmail.com>>
Re: Modules
Posted by Matt Sicker <bo...@gmail.com>.
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 <ga...@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 <bo...@gmail.com> wrote:
>
>> Oh wait, Ralph is talking about something else entirely.
>>
>> On 30 September 2016 at 11:58, Matt Sicker <bo...@gmail.com> wrote:
>>
>>> I think log4j-nosql could be merged into log4j-core.
>>>
>>> On 30 September 2016 at 11:50, Gary Gregory <ga...@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: garydgregory@gmail.com | ggregory@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
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker <bo...@gmail.com>
Re: Modules
Posted by Gary Gregory <ga...@gmail.com>.
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 <bo...@gmail.com> wrote:
> Oh wait, Ralph is talking about something else entirely.
>
> On 30 September 2016 at 11:58, Matt Sicker <bo...@gmail.com> wrote:
>
>> I think log4j-nosql could be merged into log4j-core.
>>
>> On 30 September 2016 at 11:50, Gary Gregory <ga...@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: garydgregory@gmail.com | ggregory@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
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Modules
Posted by Matt Sicker <bo...@gmail.com>.
Oh wait, Ralph is talking about something else entirely.
On 30 September 2016 at 11:58, Matt Sicker <bo...@gmail.com> wrote:
> I think log4j-nosql could be merged into log4j-core.
>
> On 30 September 2016 at 11:50, Gary Gregory <ga...@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: garydgregory@gmail.com | ggregory@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
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
Matt Sicker <bo...@gmail.com>
Re: Modules
Posted by Matt Sicker <bo...@gmail.com>.
I think log4j-nosql could be merged into log4j-core.
On 30 September 2016 at 11:50, Gary Gregory <ga...@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: garydgregory@gmail.com | ggregory@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
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker <bo...@gmail.com>
Re: Modules
Posted by Matt Sicker <bo...@gmail.com>.
I do like the idea of moving plugins that have optional dependencies into
their own modules that have required dependencies. That would certainly
make usage easier.
On 3 October 2016 at 03:21, Mikael Ståldal <mi...@magine.com>
wrote:
> If we should reorganize the project, there is another issue we should
> consider: transitive dependencies
>
> Currently, log4j-core has quite some optional dependencies. I don't like
> that since the user needs to manually keep track of which transitive
> runtime dependencies to use, efficiently negating the advantage of using
> Maven (or Ivy, Gradle, SBT) in the first place.
>
> If we should split up log4j-core, then I would like to move out everything
> that have transitive dependencies to their own modules, and make those
> dependencies non-optional in those new modules.
>
> I don't really see the point of an uber jar. Isn't everyone using
> Maven (or Ivy, Gradle, SBT) nowadays?
>
> On Sat, Oct 1, 2016 at 6:26 AM, Remko Popma <re...@gmail.com> wrote:
>
>>
>> On 1 Oct 2016, at 13:05, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> I don’t cut a release branch. The Maven release plugin updates the pom
>> versions, creates the release tag, and then changes the pom version to be a
>> snapshot. It then essentially does a mvn deploy on the tag. The release
>> plugin typically performs a build against the snapshot to confirm the build
>> works before it runs the deploy step. Both run all the unit tests, which is
>> why the release build takes so long.
>>
>> Could the deploy step be run with-DskipTests since the release plugin
>> just finished running a full build (including the tests) against the
>> snapshot?
>>
>> Or even better, could the deploy step not use the artifacts produced by
>> the full build it just ran?
>>
>>
>> In doing this a number of times I have learned that it is much better to
>> do the pre-work prior to running the release plugin because it takes so
>> long to perform the release. Essentially, when I send out the vote email I
>> am already voting +1 on the release.
>>
>> I have no desire to change the site, however the Maven site plugin
>> wouldn’t be able to include the submodules that aren’t part of the project.
>> However, I have no doubt that we could find a way to integrate the two
>> sites together.
>>
>> Ralph
>>
>> On Sep 30, 2016, at 6:32 PM, Remko Popma <re...@gmail.com> wrote:
>>
>>
>>
>>
>> Sent from my iPhone
>> On 1 Oct 2016, at 2:04, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> Actually, I just created LOG4J2-1627 for this and I specifically did
>> bring Java 9 modules into the discussion because they should at least be
>> considered along with the Java 8 profiles. Right now I am sure we have
>> stuff that would create problems with trying to run in compact profiles 1
>> and 2.
>>
>> That said, my primary motivation isn’t to split things up for those
>> reasons. It is simply because it takes me a minimum of 4 hours to perform a
>> release. That is because I run a rat check on the project, then build the
>> project, then build the site. Only after I check all of those do I start
>> the release build, which by itself takes 45 minutes. I then have to build
>> the site again against the release tag.
>>
>> Why do you have to run the project and site builds twice? Couldn't you
>> cut the time in half by doing
>> 1. rat check
>> 2. cut a release branch
>> 3. prepare for release on that branch (pom versions etc)
>> 4. build project
>> 5. build site
>> 6. now do the checking you used to do in the middle
>> 7. if you're happy with the release merge any changes back into master
>> (this could be done post-release)
>>
>> I haven't looked at the release procedures so I may be missing something,
>> but that could be a nice improvement. The release is also no longer
>> impacted by commits happening while the release process is ongoing.
>>
>> Overall I don't oppose reorganizing the project but I do wonder how that
>> will impact the user experience. Can we keep the site the same as it is now?
>>
>> Considering that just running mvn clean install takes about 25 minutes
>> now you can see why this becomes a large effort. And it is getting worse
>> with every release. This is primarily due to the tests run in core. There
>> is also a huge delay that occurs after running the unit tests and before
>> running the functional tests. I am attributing this to the time the
>> failsafe plugin must be spending just to figure out which test classes to
>> call. I plan to address that by moving the functional tests to their own
>> module.
>>
>> Ralph
>>
>> On Sep 30, 2016, at 9:50 AM, Gary Gregory <ga...@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: garydgregory@gmail.com | ggregory@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
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@magine.com
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>
--
Matt Sicker <bo...@gmail.com>
Re: Modules
Posted by Mikael Ståldal <mi...@magine.com>.
If we should reorganize the project, there is another issue we should
consider: transitive dependencies
Currently, log4j-core has quite some optional dependencies. I don't like
that since the user needs to manually keep track of which transitive
runtime dependencies to use, efficiently negating the advantage of using
Maven (or Ivy, Gradle, SBT) in the first place.
If we should split up log4j-core, then I would like to move out everything
that have transitive dependencies to their own modules, and make those
dependencies non-optional in those new modules.
I don't really see the point of an uber jar. Isn't everyone using Maven (or
Ivy, Gradle, SBT) nowadays?
On Sat, Oct 1, 2016 at 6:26 AM, Remko Popma <re...@gmail.com> wrote:
>
> On 1 Oct 2016, at 13:05, Ralph Goers <ra...@dslextreme.com> wrote:
>
> I don’t cut a release branch. The Maven release plugin updates the pom
> versions, creates the release tag, and then changes the pom version to be a
> snapshot. It then essentially does a mvn deploy on the tag. The release
> plugin typically performs a build against the snapshot to confirm the build
> works before it runs the deploy step. Both run all the unit tests, which is
> why the release build takes so long.
>
> Could the deploy step be run with-DskipTests since the release plugin just
> finished running a full build (including the tests) against the snapshot?
>
> Or even better, could the deploy step not use the artifacts produced by
> the full build it just ran?
>
>
> In doing this a number of times I have learned that it is much better to
> do the pre-work prior to running the release plugin because it takes so
> long to perform the release. Essentially, when I send out the vote email I
> am already voting +1 on the release.
>
> I have no desire to change the site, however the Maven site plugin
> wouldn’t be able to include the submodules that aren’t part of the project.
> However, I have no doubt that we could find a way to integrate the two
> sites together.
>
> Ralph
>
> On Sep 30, 2016, at 6:32 PM, Remko Popma <re...@gmail.com> wrote:
>
>
>
>
> Sent from my iPhone
> On 1 Oct 2016, at 2:04, Ralph Goers <ra...@dslextreme.com> wrote:
>
> Actually, I just created LOG4J2-1627 for this and I specifically did bring
> Java 9 modules into the discussion because they should at least be
> considered along with the Java 8 profiles. Right now I am sure we have
> stuff that would create problems with trying to run in compact profiles 1
> and 2.
>
> That said, my primary motivation isn’t to split things up for those
> reasons. It is simply because it takes me a minimum of 4 hours to perform a
> release. That is because I run a rat check on the project, then build the
> project, then build the site. Only after I check all of those do I start
> the release build, which by itself takes 45 minutes. I then have to build
> the site again against the release tag.
>
> Why do you have to run the project and site builds twice? Couldn't you cut
> the time in half by doing
> 1. rat check
> 2. cut a release branch
> 3. prepare for release on that branch (pom versions etc)
> 4. build project
> 5. build site
> 6. now do the checking you used to do in the middle
> 7. if you're happy with the release merge any changes back into master
> (this could be done post-release)
>
> I haven't looked at the release procedures so I may be missing something,
> but that could be a nice improvement. The release is also no longer
> impacted by commits happening while the release process is ongoing.
>
> Overall I don't oppose reorganizing the project but I do wonder how that
> will impact the user experience. Can we keep the site the same as it is now?
>
> Considering that just running mvn clean install takes about 25 minutes now
> you can see why this becomes a large effort. And it is getting worse with
> every release. This is primarily due to the tests run in core. There is
> also a huge delay that occurs after running the unit tests and before
> running the functional tests. I am attributing this to the time the
> failsafe plugin must be spending just to figure out which test classes to
> call. I plan to address that by moving the functional tests to their own
> module.
>
> Ralph
>
> On Sep 30, 2016, at 9:50 AM, Gary Gregory <ga...@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: garydgregory@gmail.com | ggregory@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
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@magine.com
Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
Re: Modules
Posted by Remko Popma <re...@gmail.com>.
> On 1 Oct 2016, at 13:05, Ralph Goers <ra...@dslextreme.com> wrote:
>
> I don’t cut a release branch. The Maven release plugin updates the pom versions, creates the release tag, and then changes the pom version to be a snapshot. It then essentially does a mvn deploy on the tag. The release plugin typically performs a build against the snapshot to confirm the build works before it runs the deploy step. Both run all the unit tests, which is why the release build takes so long.
Could the deploy step be run with-DskipTests since the release plugin just finished running a full build (including the tests) against the snapshot?
Or even better, could the deploy step not use the artifacts produced by the full build it just ran?
>
> In doing this a number of times I have learned that it is much better to do the pre-work prior to running the release plugin because it takes so long to perform the release. Essentially, when I send out the vote email I am already voting +1 on the release.
>
> I have no desire to change the site, however the Maven site plugin wouldn’t be able to include the submodules that aren’t part of the project. However, I have no doubt that we could find a way to integrate the two sites together.
>
> Ralph
>
>> On Sep 30, 2016, at 6:32 PM, Remko Popma <re...@gmail.com> wrote:
>>
>>
>>
>>
>> Sent from my iPhone
>> On 1 Oct 2016, at 2:04, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>>> Actually, I just created LOG4J2-1627 for this and I specifically did bring Java 9 modules into the discussion because they should at least be considered along with the Java 8 profiles. Right now I am sure we have stuff that would create problems with trying to run in compact profiles 1 and 2.
>>>
>>> That said, my primary motivation isn’t to split things up for those reasons. It is simply because it takes me a minimum of 4 hours to perform a release. That is because I run a rat check on the project, then build the project, then build the site. Only after I check all of those do I start the release build, which by itself takes 45 minutes. I then have to build the site again against the release tag.
>> Why do you have to run the project and site builds twice? Couldn't you cut the time in half by doing
>> 1. rat check
>> 2. cut a release branch
>> 3. prepare for release on that branch (pom versions etc)
>> 4. build project
>> 5. build site
>> 6. now do the checking you used to do in the middle
>> 7. if you're happy with the release merge any changes back into master (this could be done post-release)
>>
>> I haven't looked at the release procedures so I may be missing something, but that could be a nice improvement. The release is also no longer impacted by commits happening while the release process is ongoing.
>>
>> Overall I don't oppose reorganizing the project but I do wonder how that will impact the user experience. Can we keep the site the same as it is now?
>>
>>> Considering that just running mvn clean install takes about 25 minutes now you can see why this becomes a large effort. And it is getting worse with every release. This is primarily due to the tests run in core. There is also a huge delay that occurs after running the unit tests and before running the functional tests. I am attributing this to the time the failsafe plugin must be spending just to figure out which test classes to call. I plan to address that by moving the functional tests to their own module.
>>>
>>> Ralph
>>>
>>>> On Sep 30, 2016, at 9:50 AM, Gary Gregory <ga...@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: garydgregory@gmail.com | ggregory@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
>>>
>
Re: Modules
Posted by Ralph Goers <ra...@dslextreme.com>.
I don’t cut a release branch. The Maven release plugin updates the pom versions, creates the release tag, and then changes the pom version to be a snapshot. It then essentially does a mvn deploy on the tag. The release plugin typically performs a build against the snapshot to confirm the build works before it runs the deploy step. Both run all the unit tests, which is why the release build takes so long.
In doing this a number of times I have learned that it is much better to do the pre-work prior to running the release plugin because it takes so long to perform the release. Essentially, when I send out the vote email I am already voting +1 on the release.
I have no desire to change the site, however the Maven site plugin wouldn’t be able to include the submodules that aren’t part of the project. However, I have no doubt that we could find a way to integrate the two sites together.
Ralph
> On Sep 30, 2016, at 6:32 PM, Remko Popma <re...@gmail.com> wrote:
>
>
>
>
> Sent from my iPhone
> On 1 Oct 2016, at 2:04, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>
>> Actually, I just created LOG4J2-1627 for this and I specifically did bring Java 9 modules into the discussion because they should at least be considered along with the Java 8 profiles. Right now I am sure we have stuff that would create problems with trying to run in compact profiles 1 and 2.
>>
>> That said, my primary motivation isn’t to split things up for those reasons. It is simply because it takes me a minimum of 4 hours to perform a release. That is because I run a rat check on the project, then build the project, then build the site. Only after I check all of those do I start the release build, which by itself takes 45 minutes. I then have to build the site again against the release tag.
> Why do you have to run the project and site builds twice? Couldn't you cut the time in half by doing
> 1. rat check
> 2. cut a release branch
> 3. prepare for release on that branch (pom versions etc)
> 4. build project
> 5. build site
> 6. now do the checking you used to do in the middle
> 7. if you're happy with the release merge any changes back into master (this could be done post-release)
>
> I haven't looked at the release procedures so I may be missing something, but that could be a nice improvement. The release is also no longer impacted by commits happening while the release process is ongoing.
>
> Overall I don't oppose reorganizing the project but I do wonder how that will impact the user experience. Can we keep the site the same as it is now?
>
>> Considering that just running mvn clean install takes about 25 minutes now you can see why this becomes a large effort. And it is getting worse with every release. This is primarily due to the tests run in core. There is also a huge delay that occurs after running the unit tests and before running the functional tests. I am attributing this to the time the failsafe plugin must be spending just to figure out which test classes to call. I plan to address that by moving the functional tests to their own module.
>>
>> Ralph
>>
>>> On Sep 30, 2016, at 9:50 AM, Gary Gregory <garydgregory@gmail.com <ma...@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: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@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>
Re: Modules
Posted by Remko Popma <re...@gmail.com>.
Sent from my iPhone
> On 1 Oct 2016, at 2:04, Ralph Goers <ra...@dslextreme.com> wrote:
>
> Actually, I just created LOG4J2-1627 for this and I specifically did bring Java 9 modules into the discussion because they should at least be considered along with the Java 8 profiles. Right now I am sure we have stuff that would create problems with trying to run in compact profiles 1 and 2.
>
> That said, my primary motivation isn�ft to split things up for those reasons. It is simply because it takes me a minimum of 4 hours to perform a release. That is because I run a rat check on the project, then build the project, then build the site. Only after I check all of those do I start the release build, which by itself takes 45 minutes. I then have to build the site again against the release tag.
Why do you have to run the project and site builds twice? Couldn't you cut the time in half by doing
1. rat check
2. cut a release branch
3. prepare for release on that branch (pom versions etc)
4. build project
5. build site
6. now do the checking you used to do in the middle
7. if you're happy with the release merge any changes back into master (this could be done post-release)
I haven't looked at the release procedures so I may be missing something, but that could be a nice improvement. The release is also no longer impacted by commits happening while the release process is ongoing.
Overall I don't oppose reorganizing the project but I do wonder how that will impact the user experience. Can we keep the site the same as it is now?
> Considering that just running mvn clean install takes about 25 minutes now you can see why this becomes a large effort. And it is getting worse with every release. This is primarily due to the tests run in core. There is also a huge delay that occurs after running the unit tests and before running the functional tests. I am attributing this to the time the failsafe plugin must be spending just to figure out which test classes to call. I plan to address that by moving the functional tests to their own module.
>
> Ralph
>
>> On Sep 30, 2016, at 9:50 AM, Gary Gregory <ga...@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: garydgregory@gmail.com | ggregory@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
>
Re: Modules
Posted by Matt Sicker <bo...@gmail.com>.
The performance regression tests would make sense to be moved to
log4j-perf. We should include some sort of script or instructions on how to
run the specific performance tests to verify performance hasn't gotten
worse in each release.
On 3 December 2016 at 22:43, Remko Popma <re...@gmail.com> wrote:
>
> On 1 Oct 2016, at 2:04, Ralph Goers <ra...@dslextreme.com> wrote:
>
> Actually, I just created LOG4J2-1627 for this and I specifically did bring
> Java 9 modules into the discussion because they should at least be
> considered along with the Java 8 profiles. Right now I am sure we have
> stuff that would create problems with trying to run in compact profiles 1
> and 2.
>
> That said, my primary motivation isn’t to split things up for those
> reasons. It is simply because it takes me a minimum of 4 hours to perform a
> release. That is because I run a rat check on the project, then build the
> project, then build the site. Only after I check all of those do I start
> the release build, which by itself takes 45 minutes. I then have to build
> the site again against the release tag. Considering that just running mvn
> clean install takes about 25 minutes now you can see why this becomes a
> large effort. And it is getting worse with every release. This is
> primarily due to the tests run in core. There is also a huge delay that
> occurs after running the unit tests and before running the functional
> tests. I am attributing this to the time the failsafe plugin must be
> spending just to figure out which test classes to call. I plan to address
> that by moving the functional tests to their own module.
>
>
> Shall we move the failsafe tests to log4j-perf? I could be wrong, but I
> thought they are mostly performance regression tests anyway, rather than
> true "functional" tests.
>
> There are also tests that take a long time for mysterious reasons.
>
> So there may be other ways to improve the build speed.
>
> To be honest I find LOG4J2-1627 a bit confusing. Since the bulk of the
> time is spent in running tests I'm not sure if moving components out to a
> separate project will help speeding up the build.
>
> At the same time I agree it's becoming a serious problem.
>
> Should I make a separate JIRA that focuses on speeding up the build
> through other means than what LOG4J2-1627 proposes?
>
> Remko
>
>
> Ralph
>
> On Sep 30, 2016, at 9:50 AM, Gary Gregory <ga...@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: garydgregory@gmail.com | ggregory@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
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Modules
Posted by Remko Popma <re...@gmail.com>.
> On 1 Oct 2016, at 2:04, Ralph Goers <ra...@dslextreme.com> wrote:
>
> Actually, I just created LOG4J2-1627 for this and I specifically did bring Java 9 modules into the discussion because they should at least be considered along with the Java 8 profiles. Right now I am sure we have stuff that would create problems with trying to run in compact profiles 1 and 2.
>
> That said, my primary motivation isn’t to split things up for those reasons. It is simply because it takes me a minimum of 4 hours to perform a release. That is because I run a rat check on the project, then build the project, then build the site. Only after I check all of those do I start the release build, which by itself takes 45 minutes. I then have to build the site again against the release tag. Considering that just running mvn clean install takes about 25 minutes now you can see why this becomes a large effort. And it is getting worse with every release. This is primarily due to the tests run in core. There is also a huge delay that occurs after running the unit tests and before running the functional tests. I am attributing this to the time the failsafe plugin must be spending just to figure out which test classes to call. I plan to address that by moving the functional tests to their own module.
Shall we move the failsafe tests to log4j-perf? I could be wrong, but I thought they are mostly performance regression tests anyway, rather than true "functional" tests.
There are also tests that take a long time for mysterious reasons.
So there may be other ways to improve the build speed.
To be honest I find LOG4J2-1627 a bit confusing. Since the bulk of the time is spent in running tests I'm not sure if moving components out to a separate project will help speeding up the build.
At the same time I agree it's becoming a serious problem.
Should I make a separate JIRA that focuses on speeding up the build through other means than what LOG4J2-1627 proposes?
Remko
>
> Ralph
>
>> On Sep 30, 2016, at 9:50 AM, Gary Gregory <ga...@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: garydgregory@gmail.com | ggregory@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
>
Re: Modules
Posted by Ralph Goers <ra...@dslextreme.com>.
Oh, and FWIW, I have never really been interested in the uber jar. To me, the bom is really all that is required for that.
Ralph
> On Sep 30, 2016, at 10:04 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> Actually, I just created LOG4J2-1627 for this and I specifically did bring Java 9 modules into the discussion because they should at least be considered along with the Java 8 profiles. Right now I am sure we have stuff that would create problems with trying to run in compact profiles 1 and 2.
>
> That said, my primary motivation isn’t to split things up for those reasons. It is simply because it takes me a minimum of 4 hours to perform a release. That is because I run a rat check on the project, then build the project, then build the site. Only after I check all of those do I start the release build, which by itself takes 45 minutes. I then have to build the site again against the release tag. Considering that just running mvn clean install takes about 25 minutes now you can see why this becomes a large effort. And it is getting worse with every release. This is primarily due to the tests run in core. There is also a huge delay that occurs after running the unit tests and before running the functional tests. I am attributing this to the time the failsafe plugin must be spending just to figure out which test classes to call. I plan to address that by moving the functional tests to their own module.
>
> Ralph
>
>> On Sep 30, 2016, at 9:50 AM, Gary Gregory <garydgregory@gmail.com <ma...@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: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@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>
Re: Modules
Posted by Ralph Goers <ra...@dslextreme.com>.
Actually, I just created LOG4J2-1627 for this and I specifically did bring Java 9 modules into the discussion because they should at least be considered along with the Java 8 profiles. Right now I am sure we have stuff that would create problems with trying to run in compact profiles 1 and 2.
That said, my primary motivation isn’t to split things up for those reasons. It is simply because it takes me a minimum of 4 hours to perform a release. That is because I run a rat check on the project, then build the project, then build the site. Only after I check all of those do I start the release build, which by itself takes 45 minutes. I then have to build the site again against the release tag. Considering that just running mvn clean install takes about 25 minutes now you can see why this becomes a large effort. And it is getting worse with every release. This is primarily due to the tests run in core. There is also a huge delay that occurs after running the unit tests and before running the functional tests. I am attributing this to the time the failsafe plugin must be spending just to figure out which test classes to call. I plan to address that by moving the functional tests to their own module.
Ralph
> On Sep 30, 2016, at 9:50 AM, Gary Gregory <ga...@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: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@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>