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 Remko Popma <re...@gmail.com> on 2016/10/01 01:32:34 UTC
Re: Modules
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>.
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>