I have a question about updating from the Red5 Trunk.
This may be a stupid question but bear with me. I can update from the SVN without any problem. My question is how often should I run ANT to update from IVY? Will there be a message in the SVN to update for new dependencies from IVY or is it expected to update from IVY every time I do an SVN update. I know that this may sound elementary but all I want to know is when to or when not to update dependencies from IVY. I now can update either from Eclipse or from a standalone SVN tool and either run ANT from a command line or from within Eclipse. Since I mainly build the webwar which it runs fine with the jar files in place now. I may have missed this in the build.xml file but is there a ANT command which just asks IVY to check so see if the dependencies exists and skip downloading them again? All I am trying to so is make sure I have the right setup when updating from the SVN and then checking for any new dependency from IVY. Let me be clear, I am not complaining, just seeking a clear direction for future updating. Thanks, Lenny On 6/29/07, Mondain <[EMAIL PROTECTED]> wrote:
All you have to do in eclipse is add the Ivy dependency entry it manages the libraries, the IvyDE prefs file is checked into SVN so I dont know why youre seeing any error at all. Paul On 6/29/07, Dan Rossi <[EMAIL PROTECTED]> wrote: > > 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 > -- 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
