> On 1 Oct 2016, at 13:05, Ralph Goers <ralph.go...@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 <remko.po...@gmail.com> wrote: >> >> >> >> >> Sent from my iPhone >> 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. >> 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 <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 >>> >
