Re: [jdee-devel] building JDEE
Brought to you by:
paullandes
Menu
▾
▴
Re: [jdee-devel] building JDEE
|
From: Phillip L. <phi...@ne...> - 2008-03-06 18:10:42
|
I've suggested to Dimitre off list that he send me the build files. I can check in on a branch. We can test on the different OS from the branch. If it works, I guess we can merge it back to trunk. Having a working cross-platform build would be a big help. Without this, people can't really contribute to JDEE in a meaningful way. Phil >>>>> "CK" == Carlos Konstanski <cko...@pi...> writes: CK> Dimitre Liotev writes: >> Phillip Lord <phi...@ne...> writes: >> >> >>>>>> "DL" == Dimitre Liotev <dl...@zn...> writes: >> > >> > DL> Phillip Lord <phi...@ne...> writes: >> > >> > >> All >> > >> >> > >> I've been playing around with the build system, in an attempt to >> > >> make JDEE buildable; at the moment it doesn't work for me on >> > >> either windows or linux. >> > >> >> > >> I'm trying to write a very simple, does nothing clever build. My >> > >> thought it to use both make and ant because this should be >> > >> quickest. So far, though, the work is not going quickly. >> > >> >> > >> Has anyone else got any further with this yet? >> > >> > DL> I tried to build the Java code. The package jde.debugger is in a >> > DL> bad state. In particular class DebugeeProcess can not compile, it >> > DL> causes 11 errors the first of which is this: >> > >> > DL> trunk\jde\java\src\jde\debugger\DebuggeeProcess.java:62: >> > DL> cannot find symbol [javac] symbol : constructor >> > DL> ObjectStore(jde.debugger.DebuggeeProcess) [javac] location: >> > DL> class jde.debugger.ObjectStore [javac] store = new >> > DL> ObjectStore(this); >> > >> > >> > DL> Does anyone know why this class is out of sync? >> > >> > DL> Otherwise if I remove the jde.debugger package all the rest of >> > DL> the Java code compiles (but I use a modified build.xml - the one >> > DL> that is currently in SVN does not work for me). >> > >> > >> > Well the debugger probably needs to be removed. If you have a modified >> > build.xml, then it would be good to get that into svn. >> > >> > Did you manage to get the lisp component building? I really don't >> > understand the make file for that. >> > >> > Phil >> >> Well, I think that the make file will be a problem for many people, >> especially those who use Windows. Probably it would be easier for people >> to start contributing if they do not have such difficulties with the >> build system. >> >> I've tried to remove the make files, and do the whole build with Ant, and >> it seems to work well. I'll have to find the time to work a bit more on >> it and once I am ready I'll share the code - I'll put it on my server so >> that you and the others can download and have a look at it. >> >> Do we have a person who is responsible for approving and committing >> changes to the code? How does this process work? >> >> >> -- Dimitre Liotev >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft Defy all challenges. >> Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ jdee-devel mailing list >> jde...@li... >> https://lists.sourceforge.net/lists/listinfo/jdee-devel CK> If I'm not mistaken, this email from Paul Kinnucan is the last published CK> word on how the development process works. There was subsequent CK> discussion re: CVS versus subversion, and I'm not clear whether it was CK> later decided that the developer would simply commit their changes to CK> SVN, or if they would still stick with the original plan of sending CK> files to the reviewer. CK> ;; CK> I've had to review a lot of JDEE bug fixes submitted as patches over the CK> years and I have to say that it is very obnoxious compared to reviewing CK> whole files as is done here at the MathWorks. It seems that everybody CK> uses a different diff utility and almost half the time the patch utility CK> I use doesn't work with the submitted patch file. So I have to spend a CK> half hour or so painstakingly applying the patch by hand to a file CK> before I can even begin the review. This is an error-prone process that CK> can lead to changes not being applied or applied incorrectly. The CK> proposed whole file process tries to avoid burdening the reviewer with CK> having to spend time patching a file. CK> The process I am suggesting is as follows. The developer always makes CK> his changes to the head of the trunk for that file (or a branch if CK> development is being done on the branch). The reviewer ediffs the whole CK> file submitted by the developer against the head of the trunk. The diff CK> reveals the changes the developer has made and only those changes. This CK> is essentially the process used at the MathWorks and it works well. CK> The whole point is to minimize the burden on the code reviewer. The code CK> reviewer's job is to review the changes to the head of the trunk before CK> they are committed to ensure that they do what they are intended to do CK> in the best possible way. Period. It is the developer's responsibility CK> to ensure that the file he submits for review is the head of the trunk CK> plus his changes only, to respond appropriately to the reviewer's CK> comments, and to commit the approved changes and only those changes to CK> the repository. CK> I like Len's idea of posting changes to the jdee-devel list, giving CK> everybody a chance to review code changes. With this model, the process CK> would be CK> 1. Post trunk+changes revision to devel list for review. CK> 2. Anyone who wants to review the file posts a response to list with CK> estimated time of completing the review. CK> 3. Reviewers post their comments to list, attaching their revisions to CK> the submitted revision if desired. CK> 4. Developer applies review changes to the submitted version and commits CK> the results to the repository, along with a log file that notes the CK> purpose of the change, the tracker number for the change being made, and CK> the names of the reviewers. CK> 5. Reviewer closes out tracker entry for the change. CK> ;; CK> Carlos Konstanski CK> ------------------------------------------------------------------------- CK> This SF.net email is sponsored by: Microsoft Defy all challenges. CK> Microsoft(R) Visual Studio 2008. CK> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ CK> _______________________________________________ jdee-devel mailing list CK> jde...@li... CK> https://lists.sourceforge.net/lists/listinfo/jdee-devel -- Phillip Lord, Phone: +44 (0) 191 222 7827 Lecturer in Bioinformatics, Email: phi...@ne... School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Claremont Tower Room 909, skype: russet_apples Newcastle University, NE1 7RU |