I feel as though anything that requires an outside dependency (other than log4j-api) should probably be in its own module. The core should consist of everything that is doable without dependencies outside Java SE.
So, even though JMS uses Java EE, it could be its own module since that's not standard Java SE. On 14 April 2014 10:21, Ralph Goers <ralph.go...@dslextreme.com> wrote: > I, for one, am not upset by this discussion. As I have said, I have no > objection to pulling some stuff out of core and I am thinking we need to > start a companion project for “extra” stuff. That said, most Log4j users > will expect that the core will contain roughly the same components that > were in Log4j 1.x. But I am not convinced that JPA (or even SMTP) needs to > be a core component. And I would probably be in favor of moving JMX out > too, but I know it might be difficult to get consensus on that. > > Ralph > > > > On Apr 14, 2014, at 7:42 AM, Matt Sicker <boa...@gmail.com> wrote: > > Oh right, that is true. Well, you still need to provide the Jackson > dependencies for JSON files to work. > > I agree on the god library front, too. I just don't know how to get the > point across without upsetting everyone. > > On Monday, 14 April 2014, Łukasz Dywicki <l...@code-house.org> wrote: > >> Hey Matt, >> I assumed JSON is default (or has higher priority than XML at least) >> based on documentation. >> >> Log4j will inspect the "log4j.configurationFile" system property and, if >> set, will attempt to load the configuration using the >> ConfigurationFactory that matches the file extension. >> If no system property is set the JSON ConfigurationFactory will look for >> log4j2-test.json or log4j2-test.jsn in the classpath. >> If no such file is found the XML ConfigurationFactory will look for >> log4j2-test.xml in the classpath. >> If a test file cannot be located the JSON ConfigurationFactory will look >> for log4j2.json or log4j2.jsn on the classpath. >> If a JSON file cannot be located the XML ConfigurationFactory will try to >> locate log4j2.xml on the classpath. >> If no configuration file could be located the DefaultConfiguration will >> be used. This will cause logging output to go to the console. >> >> Sadly you did not catch sense of my question. Point was - how much >> configuration *formats* you gonna place in core, when people will opt for >> scala configuration dsl, what will happen? >> >> Anyway, it’s up to you how you drive your library. You might not see need >> to split core, that’s fine for me. Just remind that creation of "god-like” >> thinks is bad practice in software development regardless if it’s class, >> package or module. >> >> Best regards, >> Łukasz Dywicki >> -- >> l...@code-house.org >> Twitter: ldywicki >> Blog: http://dywicki.pl >> Code-House - http://code-house.org >> >> Wiadomość napisana przez Matt Sicker <boa...@gmail.com> w dniu 13 kwi >> 2014, o godz. 18:27: >> >> XML is the default file format. You need to add the jackson libraries to >> get JSON and YAML support. If people like YAML more than JSON, they're >> using the same library, so it's perfectly alright! >> >> What would you mean by Groovy and Scala formats? You can already use >> Log4j2 with any JVM language, and you can write your own custom >> implementation of Configuration (though it's usually only done to support >> more file formats due to the need to represent a parsed configuration file). >> >> Really, the parts that I think make most sense for modularity are any >> packages that have optional dependencies. It's just that each optional >> dependency tends to correspond to about 3-5 java files, so it seems >> pointless to make entire JARs for each of those. I think that's the problem >> everyone else is seeing. >> >> >> On 13 April 2014 05:53, Łukasz Dywicki <l...@code-house.org> wrote: >> >> Hey, >> Please find my replies inline. I do reply on all mails at the same time. >> >> >> >> I had a great idea inspired by Mark from Tomcat (forget his full name) in >> regards to splitting up core: we can set up a parallel repository that uses >> svn:external to organise the various packages into separate modules. Then >> separate pom.xml files can be written for these sub-modules. This might be >> a better route to go. >> >> I think you have spoken to Mark Thomas who did presentat few things. I >> also spoken to Christopher Schultz who had tomcat monitoring presentation >> and he is also tomcat commiter. He told me that Tomcat build is quite >> complicated and that’s reason why they did not switch to maven. No need to >> mention how big is build.xml for them. Main reason why their build is >> complicated and hard to get it done is big core. >> >> In Tomcat, they keep all their source code in one tree. However, their >> Ant build scripts build several JARs from that tree by pulling in various >> sub-directories. This is actually a big reason why they couldn't easily >> move to Maven (amongst other reasons I bet). It was suggested to make a >> parallel repository like I mentioned above. >> >> I don’t think that having source code in one tree is bad thing. Sometimes >> you will have different releases having exactelly same code producing >> unecessary traffic on maven repos and so on (we will let Sonatype pay for >> it ;-))). For most of people it does not make a big difference. But on >> Tomcat build example you can see a big technology debt. Multiple >> repositories are bringing some extra effort to releases too. >> >> Also, amusingly enough, Lucas, I've had quite a similar discussion here >> before. The main thing here is that nobody seems to think that core is >> large enough to be split. It's a different way of thinking about >> development when you move to OSGi. >> >> I can understand that. But you already see bunch of things which are >> sitting next to each other having not that much in common. You can also >> take a look on camel which is big project in apache having many >> dependencies. You might run it under tomcat and they have fine grained >> dependencies. I never seen anybody on their mailing lists considering that >> as mistake or wrong thing. >> >> Also, if you drop Log4j into a web container currently it will >> automatically initialize in a Servlet 3 container. I’ve always been a bit >> uncomfortable with that and it was originally in its own jar, but others >> preferred it the way it currently is. >> >> I do use log4j under tomcat as default logging backend also for container >> so in the container I just need slf4j bridge since all apps I have made are >> not dependant on logging backend. These times many libraries are already >> backed to slf4j so it is even easier to go. >> >> Wait, some one is going to want to split each configuration forma >> >> >> > > -- > Matt Sicker <boa...@gmail.com> > > > -- Matt Sicker <boa...@gmail.com>
