Hi Sebb, Thank you for your advise, but it is a pity that we can not use an build script to generate these codes in the build process. There are two reasons: 1. These codes are generated by GMF, may be we can find its generate source code and write a similar ant build script, but i do not know how to do it. Yes, we can find it out if we want, but this is not the most important reason, there are reason 2. 2. As i said before, GMF just generate basic source code, after code generation process, i must make many changes to the source code to achieve our final goal. And we can not find a solution to split code generation process and code modify process.
So, i can only take care of source code change as little as possible every time. -Gui Xun Long On 6/11/10, sebb <seb...@gmail.com> wrote: > On 11/06/2010, Rahul Akolkar <rahul.akol...@gmail.com> wrote: >> On Thu, Jun 10, 2010 at 10:03 PM, Xun Long Gui <ustbco...@gmail.com> >> wrote: >> > Hi Rahul, >> > >> > Deleting files in SVN server last time is due to my lapse operation, >> > sorry for that :-( >> >> <snip/> >> >> OK, thanks for clarifying, please be careful not to delete going forward. >> >> >> >> > In fact, pattern in (B) is not avaiable, we can not help developers >> > generate all the necessary code by theirselves because we can only >> > generate basic source code and we must change source code by hand to >> > achieve our aim. So, i think we can use pattern A and i will be MORE >> > and MORE careful to maintain SVN workspace. >> > >> >> <snap/> >> >> Indeed, thats a good point. Speaking of changes to be made by hand, I >> have a few suggestions (related to naming etc.) -- I will try to find >> some time this weekend to send an email about that. >> > > Can the changes be automated in any way? E.g. editor scripts and the like? > If so, then it should be possible to include the scripts in the build > process. > > For example, Commons DBCP uses a scripted approach to fix the sources > for different versions of JDBC. > > If it's not possible to automate the changes, then there needs to be > detailed documentation on how to do the changes and what triggers the > need to make changes. > >> -Rahul >> >> >> >> > -Gui Xun Long >> > >> > On 6/11/10, Rahul Akolkar <rahul.akol...@gmail.com> wrote: >> >> The generated code needs to be better managed with respect to SVN >> updates. >> >> >> >> As an example of a pattern we don't want to see, r953073 [1] deletes a >> >> number of (previously) generated files. Subsequently, r953075 [2] adds >> >> back some of those files after regenerating based on changes to the >> >> model. Such an SVN usage pattern isn't very useful because (a) SVN >> >> history is wiped clean any time we delete and add back, and (b) the >> >> diffs could be much smaller if we don't delete. >> >> >> >> So it should be possible to do better. There are atleast two >> >> approaches that could be adopted here: >> >> >> >> (A) Don't delete any files from SVN as done above, just check in the >> >> changes after regeneration. This should result in smaller diffs. Need >> >> to be careful about not losing license headers and any other >> >> round-trip induced problems. >> >> >> >> (B) Don't check in generated files at all. This means that anyone >> >> trying to build the plugin will have to download the correct Eclipse >> >> environment and generate code themselves -- so its a little harder for >> >> anyone to just try things. But folks will need a suitable environment >> >> to run the plugin anyway. >> >> >> >> What is your preference? Perhaps we can start using the pattern in (A) >> >> and see how things go? It'd be good to decide how we want to manage >> >> these updates before the next round of such SVN updates. >> >> >> >> -Rahul >> >> >> >> [1] http://svn.apache.org/viewvc?view=revision&revision=953073 >> >> [2] http://svn.apache.org/viewvc?view=revision&revision=953075 >> >> >> > >> > >> > -- >> >> > Best Regards >> > >> > Gui Xun Long (桂训龙) >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Best Regards Gui Xun Long (桂训龙) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
