commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Xun Long Gui <ustbco...@gmail.com>
Subject Re: [scxml-eclipse] Managing generated code in SVN
Date Fri, 11 Jun 2010 14:03:59 GMT
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 <sebbaz@gmail.com> wrote:
> On 11/06/2010, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>> On Thu, Jun 10, 2010 at 10:03 PM, Xun Long Gui <ustbcoder@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.akolkar@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-unsubscribe@commons.apache.org
>>  For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
Best Regards

Gui Xun Long (桂训龙)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message