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 :-)
-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 (桂训龙) >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> 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 > > -- Best Regards Gui Xun Long (桂训龙) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
