Hi Ondrej, Thanks for the fast reply. I am modifying SableVM, and in the process of moving most of my work out of a private CVS to a branch in SableVM's SVN repository (aside: why are you even advocating CVS anymore? :-). If and when it becomes stable then hopefully it can be merged into the trunk. However, without Soot, my SableVM work is useless -- the transformers and analysers are an integral part of the project. And therefore since anybody who wants to use my project needs access to the code, I can't just keep it private. So ............... I don't know. Etienne doesn't think it should be in SableVM, and that's why I'm asking. I don't think it's a good idea to set up a third public repository just for a few pieces of Soot-using Java code that are needed for my SableVM work. As for me modifying Soot itself ... it seems unlikely at this point, I think all of the functionality I need is there. And if I did need extra functionality, I can't imagine how it would be specific to this SableVM project. But out of curiousity, do you require Soot contributors that keep their work in a branch to maintain that work? Certainly I can understand this requirement for whatever lands on the trunk. If I do put it all in SableVM, I need to modify the LICENSE file and any Soot-using source files to mention Soot as well, right? Cheers, Chris Ondrej Lhotak wrote: Hi Chris... If your project does not require modifying existing code in either Soot or SableVM, I would recommend keeping it in a separate repository, separate from both Soot and SableVM. It should only go into the Soot or SableVM repository if you think that some day, it will be useful to users of Soot or SableVM in general. By making it part of Soot or SableVM, you are implicitly agreeing to maintain it for Soot or SableVM users in the future. We already have a hard enough time with code in Soot whose authors have disappeared, and nobody knows how it works (but it's too valuable to Soot users to just rip out). If you need minor modifications to Soot, but the bulk of your code can be separate from those modifications, then you can make those minor modifications in the Soot repository, and keep the rest of your code separate. Again, I don't know your exact intentions for the future of this code, but I would only put it into the Soot repository if you intend to one day make it an integral part of Soot and maintain it as such. If you want your own private repository, it's very easy to get one on the lab machines. Simply set your CVSROOT environment variable to /home/research/ccl/sable/CVS, go to an empty directory, type "cvs import my_repository_name VENDOR RELEASE", then go to some other directory and type "cvs co my_repository_name". This creates a directory called my_repository_name in which you can use CVS to maintain your project. Ondrej On Mon, Nov 03, 2003 at 01:29:47PM -0500, Chris Pickett wrote:Hi. I have a little bit of code that extends Soot to transform some classes (in the Java sense, no actual modification of Soot source files yet -- all I do is extend BodyTransformer and add my own main method that adds my phase and calls Soot's main method). It might grow a little in the future to include some other analyses, but I'm not sure if I will ever actually modify the core Soot files. Then again maybe I already am modifying Soot because my code calls it and is called by it. This is part of a speculative multithreading (spmt) project I'm doing in SableVM (I insert dummy method calls that are recognized and transformed by SableVM at method preparation time). Etienne (the SableVM maintainer) says it's better if I put Soot-related stuff in the Soot repository . . . what do you guys think? Should I make a copy of the trunk in soot/branches/soot-2-spmt and create my own spmt directory in that branch? Or put a license statement about Soot in my SableVM project and keep it all there? By the way, SableVM is also under the LGPL. Right now, it seems easiest for me if I just have one repository to worry about, but I will do this if it's the best way. I'm just a Soot user at the moment, but it seems that this also means developer, hence the confusion / hesitation / questions. Cheers, Chris |