> 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 >> JUnit in Action, Second Edition >> Spring Batch in Action >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >
