2010/6/11 Xun Long Gui <ustbco...@gmail.com>: > Second stage is normal coding period, we write codes that we need as > we do every day, i do not think this stage we can automated :-) > <snip/>
I agree. Lets document the changes made post generation. At the minimum, we could document which files have been hand-edited and why (in the sdocbook directory for now). Perhaps also add begin and end comment markers in code around hand-edited portions. -Rahul > -Gui Xun Long > > On 6/11/10, sebb <seb...@gmail.com> wrote: >> 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 (桂训龙) >>> >> > >>> >> >>> -- >>> >>> Best Regards >>> >>> Gui Xun Long (桂训龙) >>> > > > -- > Best Regards > > Gui Xun Long (桂训龙) > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
