On Aug 4, 2007, at 8:12 AM, Christian Voelker wrote: > > Am 04.08.2007 um 05:00 schrieb zxie.dspace: >> http://wiki.dspace.org/index.php/Guide_to_Developing_with_DSpace > > I bet, that is not the whole answer, although there were a lot of > helpful hints added to the wiki recently, notably to this page: > > <http://wiki.dspace.org/index.php/IDE_Integration:_DSpace% > 2C_Eclipse_and_Tomcat> > > I personally dont get my feet on the ground with eclipse. Yesterday > I tried again and did not succeed. For me, it is a problematic thing > that the whole project and its whole structure depend more an more > and working with eclipse which might be prohibitive to some people.
No, the DSpace project is not dependent on Eclipse at all. It is dependent on SVN, Maven and Ant currently for its build, configuration and installation process. > Eclipse loads updates over several hours, adding up to hundreds of > megabytes per month, much more than the initial download and restarts > itself several times during this process. I have never seen such a > complicated online update in any system. And you cant remove any of > the update sources that you did not add yourself even if you are > not interested in the functionality they provide. Sounds like you've got it configured to do updates automatically. My installation of Eclipse (out of the box) only updates that which you select to update manually, unless you've activated some sort of auto-update feature, my version of Eclipse doesn't launch and dialogs concerning updates in its default installation. You might look under your Eclipse Preferences for Update Manager and see if you've selected some sort of autoupdate feature. > Ok, but after telling about my personal annoyance with eclipse that > everybody else seems to love, back to working with two source code > repositories. You can add several repositories to Eclipse but you > cant change between them for the same projects as far as I can see. > This is because the administrative data inside you source tree makes > assumptions about the upstream repo to compare with when telling you > things about current status in your local directory. Thats a rather uncommon approach to working with SCM's Though, you could "unshare the project" then share it into another repo in Eclipse. > This is the same problem that I have when working with the command > line client and my favourite text editor. I solved for me by deciding > that I dont follow the current source. Instead, I download the latest > stable release and put everything inside my local svn repo. I look > into the official repo from time to time, read commit messages and > would merge manually if there were some security fixes or major > functional enhancements, but that has not been the case so far. I would highly recommend not conflating your svn/repository vendor branching to be dependent on Eclipse in any way. For instance, here at MIT (and as a service to the Google communities at dspace-sandbox and dspace-gsoc). We provide a SVK mirror depot with synchronization and automerging of trunks and branches into those communities which I've setup on a nightly CRON schedule. There are folks (commiters) who use it that do not depend on Eclipse as their development environment. Some of our distributed repositories: http://dspace-sandbox.googlecode.com/svn/ http://dspace-gsoc.googlecode.com/svn/ the SVK depot of mirrors I maintain is located here: http://libstaff.mit.edu/svn/repos/mirrors I would also recommend that unless your very familiar with the code, that you work with a more stable branch that is not under as aggressive a development track as the trunk, perhaps the dspace-1_4_x branch. > All the tips about branching and merging in the svn book, which BTW > helped me a lot does not touch this issue. I dont think that this is > DSpace specific although DSpace users might be more willing to develop > their own branch than is usual with other Open Source Projects. To a > certain extent, this has to do with the missing feature of templates > for front end design. So with manakin, there will go away one major > reason for keeping you own tree. Actually, we hope that the whole AddOn mechanism will make this the case for all of DSpace (not just manakin), but only once its "completed" which will be when 1.5 is released in the 3Q of this year. We could certainly use any feedback you may provide if you are so adventurous as to explore working with it "now" in its unstable state in the SVN trunk. But recognize it is unstable and subject to change (as is any development trunk in most open source/open community projects). > > For me, the best solution would be a Subversion feature that allows > you to specify different repos for trunk and branch. You would merge > to branch then, which is your local repo. In a sense that means sup- > porting three way diff from ground up. I you are about to write a > feature request for subversion, I would join in. Interestingly, this is exactly what SVK provides as solution and what I've employed here at MIT as the above mentioned service. http://svk.bestpractical.com/view/HomePage Cheers, Mark ~~~~~~~~~~~~~ Mark R. Diggory - DSpace Systems Manager MIT Libraries, Systems and Technology Services Massachusetts Institute of Technology ------------------------------------------------------------------------- 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/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
