Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of sebbaz@gmail.com designates
 209.85.160.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=aaHOtRyfX1HwC7Hw9PjzzTdFvzrfIBAhjHqbKxwK0Qu4y83EtAP/EcUbIX0o2onmwl
         qrpnU4IChW6bXXdvlrTbvDePkEIDxTtguB5pmYkB6g7/bioyVuMvZLCovLA5/gEzntHw
         1HZlEA1S8OGoYZCFg9J0q7WQFpOw0JxSy14gA=
MIME-Version: 1.0
In-Reply-To: <AANLkTilYT6jLlj-Q-1uEmGdg0MW1g6PWgvnbUPhH0RHr@mail.gmail.com>
References: <AANLkTik2KyNYEDTw0lHqqrengRGGNaDklOFeM1TzY6h8@mail.gmail.com>
	<AANLkTikriMHe1djGUDBPAfMScuBmGkK-i_lEIuc6BO8S@mail.gmail.com>
	<AANLkTikb4srhJ2u_4LHSkGXgn6BmbRYVODzKVuoeLRgV@mail.gmail.com>
	<AANLkTin4e5pBE_27ufXh41Sm9uIHMeOIKsZXDBEUtjRX@mail.gmail.com>
	<AANLkTilYT6jLlj-Q-1uEmGdg0MW1g6PWgvnbUPhH0RHr@mail.gmail.com>
Date: Fri, 11 Jun 2010 15:16:38 +0100
Message-ID: <AANLkTinqncfEpOSBpOEsrNGcT5wsQ2F015KsN56I-S0D@mail.gmail.com>
Subject: Re: [scxml-eclipse] Managing generated code in SVN
From: sebb <sebbaz@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

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 eve=
ry 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 operatio=
n,
>  >>  > sorry for that :-(
>  >>
>  >> <snip/>
>  >>
>  >>  OK, thanks for clarifying, please be careful not to delete going for=
ward.
>  >>
>  >>
>  >>
>  >>  > In fact, pattern in (B) is not avaiable, we can not help developer=
s
>  >>  > 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 MO=
RE
>  >>  > 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 fin=
d
>  >>  some time this weekend to send an email about that.
>  >>
>  >
>  > Can the changes be automated in any way? E.g. editor scripts and the l=
ike?
>  > 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] dele=
tes a
>  >>  >> number of (previously) generated files. Subsequently, r953075 [2]=
 adds
>  >>  >> back some of those files after regenerating based on changes to t=
he
>  >>  >> model. Such an SVN usage pattern isn't very useful because (a) SV=
N
>  >>  >> history is wiped clean any time we delete and add back, and (b) t=
he
>  >>  >> 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 Ecli=
pse
>  >>  >> environment and generate code themselves -- so its a little harde=
r for
>  >>  >> anyone to just try things. But folks will need a suitable environ=
ment
>  >>  >> to run the plugin anyway.
>  >>  >>
>  >>  >> What is your preference? Perhaps we can start using the pattern i=
n (A)
>  >>  >> and see how things go? It'd be good to decide how we want to mana=
ge
>  >>  >> these updates before the next round of such SVN updates.
>  >>  >>
>  >>  >> -Rahul
>  >>  >>
>  >>  >> [1] http://svn.apache.org/viewvc?view=3Drevision&revision=3D95307=
3
>  >>  >> [2] http://svn.apache.org/viewvc?view=3Drevision&revision=3D95307=
5
>  >>  >>
>  >>  >
>  >>  >
>  >>  > --
>  >>
>  >> > Best Regards
>  >>  >
>  >>  > Gui Xun Long (=B9=F0=D1=B5=C1=FA)
>  >>  >
>  >>
>  >>  --------------------------------------------------------------------=
-
>  >>  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 (=B9=F0=D1=B5=C1=FA)
>
>  ---------------------------------------------------------------------
>  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