But the whole thing is compiling without those jars. Are you sure. Let me dig deep into the code. Instantiating class purely by reflection without even a single import will cause errors then
Robin On Mon, Feb 8, 2010 at 7:24 PM, Drew Farris <drew.far...@gmail.com> wrote: > The dependency:analyze reports can't be trusted 100% because some of > the jars are used at runtime. > > For example, I recently discovered that > org.slf4j:slf4j-jcl:jar:1.5.8:compile is necessary for proper logging > when running in mvn exec:java -- I suspect that commons-logging is > needed as well because the slf4jcl (jcl = jakarta commons logging) is > a wrapper for commons logging. > > The alternative would be to use another wrapper entirely, but I > believe some of our deps use commons-logging so that could likely lead > to a mess. > > Also, IIRC, The jets3t stuff was added back into examples recently to > support MAHOUT-249 > > The google collections stuff was recently added too, I can't remember > what for however. > > On Mon, Feb 8, 2010 at 7:41 AM, Robin Anil <robin.a...@gmail.com> wrote: > > Kicked direct dependencies. Current Job jar size is 12MB as compared to > 14MB > > > > On Mon, Feb 8, 2010 at 5:35 PM, Sean <sro...@gmail.com> wrote: > > > >> Seems OK to me. I mean, if it doesn't work, we'll know immediately, so > >> little harm. > >> > >> On Mon, Feb 8, 2010 at 11:58 AM, Robin Anil <robin.a...@gmail.com> > wrote: > >> > Take a look at the maven dependency:analyze output > >> > > >> > > >
