Re: JUnit 4.4 released

David Saff wrote:

> It is easy to spot fail-fast problems, but not necessarily easy to fix
> them--we have at least one user a month who posts to the user list
> confused about how to get just the single junit.jar on their
> classpath.
> 
> I'm saying that both are problems, and any solution is a trade-off.
> My personal hunch is that if you ask Java developers the first jar
> they ever put on their classpath, JUnit scores high, and I'm very
> concerned about making that experience any more complicated than
> necessary.

I agree - it's a trade-off based on how one uses the library, and also on personal preferences.
But then again, the number of libraries that one adds to the classpath is growing rapidly,
with all the available open-source projects.   And the emphasis is on modularisation and 
re-usability, ie best practice, rather than the potential problems of a novice.

> On the other hand, so much of the complexity here is unnecessary.  I
> believe that a vanilla Java installation should include a jpkg command
> line, so that the answer to the first JUnit FAQ could be:
> 
> jpkg install junit
> 
> It would be great if end-users didn't have to care how many jar files
> were installed to make that work, or even what a jar file is.
> 
>> - by bundling hamcrest-core you are also surrendering the advantage of a clear versioned dependency
>>     structure, which is extremely important with so many open-source libraries, all interconnected
>> among them.  A lot of people nowadays use maven or maven-like repositories for their project
>> dependencies.
> 
> I'd love to see more people use maven (it's the closest thing to the
> mythical jpkg we have), so making life hard for them is not good.
> However, I think that there's still more people who are downloading
> the jar manually from the website, and still more who just use
> whatever ships with their IDE, so balance is important.
> 

Well, I don't know much about jpkg, but from it docs it seems to be similar to Gentoo Portage.

In any case, any sofware management tool will necessarily have dependency management.

Maven put's a lot of emphasis on dependency management - and it's precisely for the reason of 
keeping dependency management nice and simple that it's important to be able to have the option to 
use libraries with unbundled dependencies.

>> Ideally, I would like to see junit released with all its constituent libraries - mandatory or
>> optional - separate.  And perhaps have a junit-all that bundles all of the them, including
>> hamcrest-library, as a utility packaging for those that choose to use it.  Other users may choose
>> not to.
>>
>> Alternately, I would be grateful if junit could also release the unbundled jar - call it junit-dep
>> or whatever, which requires the external dependency to be present in the classpath.
> 
> I think that the second is the right solution.  Look for further news
> soon.  Thanks,
> 

Cool - I'll look forward to it.   Do you think you could re-release 4.4 with the additional 
unbundled junit jar?   Or simply release the additional unbundled jar.

Thanks, Mauro


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/