On Tue, 2007-03-27 at 17:45 -0600, Filip Hanik - Dev Lists wrote: > Remy Maucherat wrote: > > Filip Hanik - Dev Lists wrote: > >> oh, and can we have the JULI with support for commons-logging built > >> as part of the standard build? > >> if, yes, then I will be happy to do it > > > > IMO, no. I'd like to keep a no dependencies, no nonsense build :) I > > don't see any need to use log4j for Tomcat logging anyway, unless you > > like running into problems. > it's more about being able to publish all our packages consistently.
That is understandable. > For example, Geronimo, needs to be able to have a unified logging > system, and they do, commons logging. > And right now, since those packages are not part of an official release, > I can't publish that JAR unless I do it manually. I'd like to be able to > publish the actual JAR out of the release. IMHO and pretty much the Gentoo Linux Java philosophy is bundled stuff is bad. FOSS Java apps tend to do it more than others. Please consider a slightly different viewpoint. But surely not trying to debate, or etc. Anytime deps are bundled as part of a release, you are locked into that version. If there are bug fixes and other releases. They don't tend to make it into other applications. Take Netbeans for example, current 5.5 version ships with a now outdated version of Tomcat 5.5, I believe 5.5.17, might be 5.5.20. Can't recall exactly. Just to be clear either way, current addition of commons-logging won't make much difference for us on Gentoo. Why? Because we install once instance of a given library, app or etc. We then provide all apps using that library, symbolic links to it said jar file or etc. Providing it's API/ABI etc compliant with other dependencies. If dependencies are fixed on a particular version. We "slot" it and allow for multiple instances to be installed. In Tomcat sense we install one version of Tomcat that say can be used with either Netbeans or Eclipse, in place of any version being shipped. ( Although not sure if eclipse plugins or etc ship tc, I know they have issues when tc is split via C_HOME/C_BASE as we do on Gentoo ) This allows for easier management. Say in this case, commons-logging has a new release. As it's package and updated it's updated for all applications using that "slot". Now one might thing manually fetching a dep to be bad. (On Gentoo it's automated) However that also allows end user to make a choice on version to use. If it's been some time past primary app release, in this case Tomcat. Then it's possible what ever version they ship at the time is newer than the bundled version say in a previous Tomcat release. For a further example take Tomcat's jasper-jdt.jar or should I really call it by it's real name, Eclipse JDT. Or at least some of it. Which I can understand slimming the package down to all that is necessary. But that also means future updates to Eclipse JDT won't make it into Tomcat. On Gentoo, I might end up replacing that file with a symlink. For I am letting the build system do it's thing and repackage what it needs. So again not trying to really change the direction or debate this. Just providing a different view point. I can also understand our solution is quite limited to operating systems that allow for symbolic links. Then again from another point of view, could be more that allow for symbolic links than not ;) But in the end bundled stuff is bad IMHO. If it can be avoided it should be, and manually fetching deps is not a bad thing. Definitely when it's not pertinent to the application. But only a subset that might run on the application and want things available about of convenience. Consistency again I can understand, but does that mean things have to be consistent forever and not subject to change? Anyway, just some food for thought. Sorry for length, and hijacking thread topic a bit. Just felt it was kinda a good time to mention it all, since the discussion was along similar lines. Thanks for your time :) -- William L. Thomson Jr. Gentoo/Java
signature.asc
Description: This is a digitally signed message part
