commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Bateman <d...@dougbateman.net>
Subject Re: Consolidating Subprojects
Date Sun, 22 Nov 2009 20:57:10 GMT
> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message