I redownloaded spring, even tried to include spring.jar it cant find import org.springframework.test.
I'll just remove test from the build, I dont use it anyway :) Dan Rossi wrote: > It looks like That howto didnt do much because the command line ant run > seemed to download the dependancies. The problem that I overlooked is > that I had to readd all the libraries into the eclipse build path. That > fixed most the problems, but the test directory is still broken > > ie these are missing > > import static org.junit.Assert.assertTrue; > import net.sourceforge.groboutils.junit.v1.MultiThreadedTestRunner; > import net.sourceforge.groboutils.junit.v1.TestRunnable; > > import org.junit.BeforeClass; > import org.junit.Test; > > Looks like junit is missing from the download. > > Mondain wrote: > >> I hear you and I understand, but I can alleviate some of your concern >> by letting you know that Ivy handles branches/tags and the ivy.xml >> goes with the revision so it will know exactly which jars to retrieve >> no matter where they may exist. I personally dont like adding jars to >> "source" control, to me it is a waste of space... spring-2.0.6.jar on >> revision 2140 should be exactly the same as spring-2.0.6.jar on >> revision 50000. >> Lastly, I put an artifact tag in the ivyconfig to point at cvsdude but >> it is not enabled.. it could be used just as simply as googlecode. :) >> >> Paul >> >> On 6/28/07, *Joachim Bauch* <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> Hi Paul, >> >> Mondain schrieb: >> > Ok.. I dont see the problem here, what I mean is I'm not >> "splitting" the >> > codebase. What I put on google is simply a library repository; >> all of >> > the jars are self-contained and self-versioned, they need not be >> merged >> > or updated. Whenever new versions of a particular library are >> released >> > we will place them in the repos if they are not available via >> ibiblio. >> > Do you feel better about this now? >> >> Not really ;) We are actually splitting the codebase if we have two >> repositories that have their own versions. We can't merge the two >> later >> as r123 in the cvsdude repository is different from r123 at google >> code. >> When we switch completely to gcode, we would have to reinitialize the >> repository, sync everything from cvsdude and then re-add the JAR files >> that were in gcode before. >> >> For these JAR files, we would lose the history (which I know isn't too >> bad as there is no real history per file), but more important also >> lose >> the targets of tags that were created for Red5 releases. If somebody >> wants to get say Red5 0.6.3 anytime in the future, he must be able to >> check out a tag and get exactly the files that were used for this >> release. This won't work if we reference rXXXX in the gcode >> repository >> from the tag now and rXXXX will change to rYYYY when we merge with the >> cvsdude repository. >> >> Hope that made my concerns a bit clearer :) >> >> Joachim >> >> >> _______________________________________________ >> Red5 mailing list >> [email protected] <mailto:[email protected]> >> http://osflash.org/mailman/listinfo/red5_osflash.org >> >> >> >> >> >> -- >> It is difficult to free fools from the chains they revere. - Voltaire >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Red5 mailing list >> [email protected] >> http://osflash.org/mailman/listinfo/red5_osflash.org >> >> > > > _______________________________________________ > Red5 mailing list > [email protected] > http://osflash.org/mailman/listinfo/red5_osflash.org > > _______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
