On 11/06/2010, Xun Long Gui <ustbco...@gmail.com> wrote: > 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.
I did not mean to suggest replacing the initial code generation process. > 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. Can this second stage be automated? > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
