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 <remko.po...@gmail.com> wrote: > > > > > Sent from my iPhone > On 1 Oct 2016, at 2:04, Ralph Goers <ralph.go...@dslextreme.com > <mailto: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 >>> <mailto: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 <mailto:garydgreg...@gmail.com> | >>> ggreg...@apache.org <mailto: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 <http://garygregory.wordpress.com/> >>> Home: http://garygregory.com/ <http://garygregory.com/> >>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
