[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Splitting Junit (was: Re: Large-scale java policy violations)



Bill Wohler wrote:


  I see. By that same reasoning, you'd also put /lib/libc.so.6 in say,
  fileutils? ;-)


No, but libc6 contains also some binaries because it makes no sense
to seperate the binaries from the library (each package would depend
on the other).


  2. placing both the script, if any, and the jar in libfoo-java.


That's exactly what libc6 did if you want to use that example.


  3. placing the jar in libfoo-java and the script in foo.


This makes no sense at all as I have already outlined in my previous mail.

I don't care much if the package is named libjunit-java or junit, but
I prefer to name application packages (binaries are applications) like
the application itself. It's just important that there's only one package
containing both the script and the jar.


  The only time you'd put a jar in a package named foo is if you would
  never, ever, use the jar directly. That is, the only one in the
  entire world that uses the jar is the script. This is definitely NOT
  the case with junit. Also, we have a precedent for placing jars in
  libfoo-java. It would be as if all the programs depended on
  fileutils instead of libc6. I don't think #1 is a great solution.


Why can't you include junit.jar in your classpath if the package is
called "junit"? You can simply depend on junit instead of libjunit-java.

  I would be surprised if sticking the script in libfoo-java would
  have any precedent at all, so I think we can certainly rule out #2.


Why? As stated above, there are also binaries in libc6.


  Thus, I think I'd lean towards #3. How bad of a problem can this be?


It's not a problem but more a redundancy and package bloat. Why would
you want to seperate them? Do you really care about some more bytes in
a shell script in /usr/bin/ if you want to install a jar with 100+ KB?
You gain absolutely nothing from two packages "junit" and "libjunit-java".

So with your suggestion, I would have to split tomcat in at least 3 packages
because some other applications might use an embedded Tomcat, e.g. JBoss
or Enhydra?

--
Stefan Gybas





Reply to: