Re: JUnit 4.4 released

Hi All,

I have been a silent reader for a while. I should say that this recent
addition to JUnit has caused a lot of confusion. JUnit used to be a
clean, lightweight library. I think it would be great if it is kept
this way. 

Wouldn't it make more sense to drop hamcrest from JUnit and let the
hamcrest develop it in a way so that it can be easily plugged in into
JUnit [if needed]?

Regards,

Slava Imeshev


> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf 
> Of Mauro Talevi
> Sent: Monday, August 13, 2007 10:28 AM
> To: [email protected]
> Subject: Re: [Junit-devel] 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/
_______________________________________________
> Junit-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/junit-devel
> 


-------------------------------------------------------------------------
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/