On Thu, 14 Aug 2003, Stanley,Michael P. wrote:
> ...projects in all my projects. I want to add my two cents to this > conversation. Always welcome. > -1 on any combination. Core / Combo - whatever. I think it is a bad > idea. > > Dealing with dependencies and versions in Java is difficult enough. One > of the benefits of the commons, in my opinion, is the ability to have > fine control over the classes & versions that you currently need. You Not suggesting that this go away. The Combo distribution is in addition to the others. > can resolve conflicts in small increments. For example. If I'm using > Commons Collections 2.1 but another dependency that I use requires > Commons Collections 2.0, I can easily resolve this tiny conflict in a > number of ways. The larger jars become the harder this becomes > (especially as the project grows in size). It is much easier to manage > 50 jar dependencies than it is to resolve a conflict that occurs in 5 > large jars. It can be a serious problem. A colleague once wasted ages debugging JavaMail to finally realise that his EJB container had its own older JavaMail jar built inside its core jar. The other side of the problem though is that in a world of no conflict, the 50 jar dependencies are far more painful than the 5 large jars. > I don't think that creating a Commons Combo distribution is in any way > beneficial. If this is the biggest complaint : > > > This is the biggest complaint about Commons at the moment [I think], that > > we have some kind of reproduction of jars going on in which more and more > > jars appear in the user's code. > > Then there are other ways to ease the management of commons dependencies. > > I suggest creating a small interactive utility that can be run by the > end user. The utility will display some known packaged configurations > (such as the ones currently being discussed). The same tool can also > offer an advanced option that lets the user pick and choose the package > and configuration they want. Once a configuration is selected, the > utility grabs the releases off the net, combines them in a jar, and > creates a dependency README file of sorts. The idea is great, but the reality is not. My two main reasons: 1) Resource. An interactive build will chew CPU, someone needs to code this up and people only code to their itches and most importantly, Apache does not currently have a production facing machine that runs a JVM. The last is getting closer to happening. There is a Sun box that does the nightly builds, I suspect the infrastructure people would not want it to be running part of the website. 2) Application. The best application for this would be a Maven sub-project, but this has issues. They don't currently record the required JVM version, they don't upload POM files to the repositories and it would mean mandating usage of Maven by Commons projects. > This will save a lot of time and energy in the long run, and provides a > solution to the "biggest complaint". Apart from those, I like the idea and would love to use said software. In a way it's a maven-install program and to make a Combo distribution would just be a case of a single project.xml with dependencies. The current feasibility is just not high. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
