commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <rahul.akol...@gmail.com>
Subject Re: [scxml-eclipse] Managing generated code in SVN
Date Sun, 13 Jun 2010 00:23:33 GMT
2010/6/11 Xun Long Gui <ustbcoder@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 <sebbaz@gmail.com> wrote:
>> On 11/06/2010, Xun Long Gui <ustbcoder@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 <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 (桂训龙)
>>>  >>  >
>>>  >>
>>> --
>>>
>>> Best Regards
>>>
>>>  Gui Xun Long (桂训龙)
>>>
>
>
> --
> 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