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
