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 format >> processing into it's own module to reduce dependencies.. ;) Jackson is used >> to parse JSON configuration files and JMX is currently defaulted to be >> always enabled. I don’t see this funny. How library is configured is one thing, how it is used is another. Especially during development programmers do not touch log4j configuration at all untill they have to apply log levels and so on (now with JMX it’s easier), however then it is configuration. In 2.x you assume JSON as default configuration, so it’s your choice but from my personal point of view it is unecessary as I rather preffer property file. Having jackson embedded in tomcat lib for people like me will just raise troubles as it’s popular library used by many developers. It’s worth to answer following question: - Will we put YAML/Groovy/Scala configuration format in core if donated? - What we gonna do if people will love YAML more than JSON? Kind regards, Łukasz Dywicki l...@code-house.org -- Twitter: ldywicki Blog: http://dywicki.pl Code-House - http://code-house.org
