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 <mikael.stal...@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 <remko.po...@gmail.com> wrote: > >> >> 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 >> <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.stal...@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 <boa...@gmail.com>
