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 <remko.po...@gmail.com> wrote: > > On 1 Oct 2016, at 2:04, Ralph Goers <ralph.go...@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 <garydgreg...@gmail.com> wrote: > > Ralph recently mentions that he'd like some modules removed while Matt > mentioned merging some back into Core. > > Shall we discuss this on the ML instead of Jira? > > I could also see doing an uber jar (mod the mutually exclusive jars) and > reorging the system with a smaller core (everything except appenders), an > all-appenders module, and/or what some folks have mentioned: one module per > appender (yikes!) > > What are all the options we should consider? > > Personally and for the current projects I have involved in, an uber jar > with optional deps is the simplest to deal with. If I had to do an app for > a light bulb, I'd think differently ;-) > > (Let's leave Java 9 modules out of the discussion!) > > Gary > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > <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 <boa...@gmail.com>
