> Raising one question: do you thing some production project could use > latest version of project commons.A and old version of commons.B ? They > would probably not like merging both projects into one. Is this a use > case we want to address or is it too theoretical ?
Well, the dependencies between versions exist now in the status quo. Except perhaps you could have a newer version of commons logging with an older package that uses commons logging. But I tend to find the problem with needing very specific versions in the classpath arises from classloader issues in non-osi environments. (For example deployed war files on JBoss where the classloading isn't standards compliant by default.) And in these cases, the version of the lowest level component, e.g. commons logging, tends to be the main problem. So my problem is usually that my version of component X requires a newer version of commons logging than is provided by JBoss in the classpath. And it's usually found by a junior programmer on a project who already spent 2 days trying to troubleshoot before asking for help. But to answer your question accurately, I really don't know. I can't think of a truly valid reason. But that doesn't mean someone hasn't. Is it in the 80% case? > It means much bigger jars. 3M jars when people complain about the > size of the 500k Collections jar. I think a lot of that is not the > size of the jar, but the ability to grok the fullness of the API - > anyone who actually cares about jar size should be using tools like > jarjar. Still, it's often been the main complaint and there are people > who strongly dislike the 500k collections jar. Regarding jar file sizes mentioned earlier in the thread. I've never really understood the tendency for people to complain about 300kb jars. Or even a larger Java API. (The JRE for 1.6 is 80MB, which is nothing compared to even a tiny 60GB disk.) I think you're right that it's more about the ability to grok the full API. Lessons I've taken from the training business is that people initially feel overwhelmed. But when you teach them it's okay to just know the 20% primer, and show them how to find other answers on demand, it sets their mind at ease (and in fact leads to empowerment). So perhaps it's just a matter of having a nice concise "getting oriented" document. Taking the opposite point of view for a moment... It is fair to say that jarjar doesn't automatically solve every problem. When I use a dependency injection framework that configures the factories in XML or .properties, jarjar usually can't automatically figure out which .class files I really use. So I have to teach jarjar what not to throw out (which isn't always so easy). But heck, for every time I've had to do that, I can think of 10 times I had to deal with version number hell. The bottom line for me is believing that the simplest solution that does the job is often the best and most flexible (that's partly why I like Struts and Wicket). And I strong believe 1 fat jar is simpler to manage than 10 think ones. But I also agree people would be up in arms about combining commons-lang with commons-logging. I don't know why, but they would. Perhaps exploring that question would lead to insights into the larger topic. Warmest Regards, Doug --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
