Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[smila-dev] netiquette

hi marius and others,

if u prefer to use the digested form of this mailing list ur are free to do so. 
but please, if u reply, leave only those mails in the mail to which u reply.

it makes it much nicer for the rest of us to follow ur train of thoughts and ur context. 
it wanst a problem in this case but it was before (at least for me).

Kind regards
Thomas Menzel @ brox IT-Solutions GmbH


-----Original Message-----
From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of Marius Cimpean
Sent: Montag, 6. Oktober 2008 12:29
To: smila-dev@xxxxxxxxxxx
Subject: [smila-dev] epl source header vs. generated code 

Hi

I have just read the two solutions proposed by Ivan...

Basically each bundle that needs to generate some sources has a schema.cmd 
file that needs to be manually called.

Here is my proposal:
- I suggest modifying the schema.cmd files (by adding new ant - call task), 
so after the the sources have been generated the ant task gets called. The 
new ant task shall use regular expression with a substitution pattern for 
the new generated sources.

Advantages:
- no extra manually work (after sources get generated they are immediately 
altered with the appropriate header)
- sources are committed in the right format on svn (no extra task to be run)

reference : http://ant.apache.org/manual/OptionalTasks/replaceregexp.html

Best Regards,
Marius


----- Original Message ----- 
From: <smila-dev-request@xxxxxxxxxxx>
To: <smila-dev@xxxxxxxxxxx>
Sent: Monday, October 06, 2008 12:16 PM
Subject: smila-dev Digest, Vol 4, Issue 9


> Send smila-dev mailing list submissions to
> smila-dev@xxxxxxxxxxx
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://dev.eclipse.org/mailman/listinfo/smila-dev
> or, via email, send a message with subject or body 'help' to
> smila-dev-request@xxxxxxxxxxx
>
> You can reach the person managing the list at
> smila-dev-owner@xxxxxxxxxxx
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of smila-dev digest..."
>
>
> Today's Topics:
>
>   1. Re: epl source header vs. generated code (Ivan Churkin)
>   2. RE: epl source header vs. generated code (Thomas Menzel)
>   3. code freeze for renaming org.EILF -> smila (Thomas Menzel)
>   4. opinion wanted: check in generated code or not vs.copyright
>      notice (Thomas Menzel)
>   5. RE: code freeze for renaming org.EILF -> smila
>      (Juergen.Schumacher@xxxxxxxxxxx)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 06 Oct 2008 14:59:21 +0700
> From: Ivan Churkin <ivan@xxxxxxxxxxxx>
> Subject: Re: [smila-dev] epl source header vs. generated code
> To: Smila project developer mailing list <smila-dev@xxxxxxxxxxx>
> Message-ID: <48E9C559.7000907@xxxxxxxxxxxx>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hi folks.
>
> We using XJC generation tool for generating JAXB classes from XSD schemes.
> For each class XJC generates headers, like the next one.
>
> // This file was generated by the JavaTM Architecture for XML
> Binding(JAXB) Reference Implementation, vhudson-jaxb-ri-2.1-520
> // See <a
> href="http://java.sun.com/xml/jaxb";>http://java.sun.com/xml/jaxb</a>
> // Any modifications to this file will be lost upon recompilation of the
> source schema.
> // Generated on: 2008.05.19 at 09:37:58 AM GMT
>
>
> but, it's not a EPL license type header and XJC does not support custom
> file headers  (its only allowed to turn header off).
>
> We may to add some tasks to build procedure for compiling schemes to
> classes by XJC on the fly.
> But I beware that it may be not convenient for developers because this
> classes required in dev stage.
>
> Situation:
> Developer creates bundle with generated classes located in "code/gen" 
> folder
> Solutions:
> 1. Developer excludes manually "code/gen" folder from SVN commit and it
> will be added task for make.xml to generate classes "on the fly" for 
> budles
> 2. It's possible to fix XJC compiler for supporting custom/configurable
> file header
>
> What is better by your opinion?
>
> --
> Regards, Ivan
>
>
>
> Thomas Menzel wrote:
> >do I have generated to code?
> >a.       yes:
> >does the generator support custom file headers to put it the EPL?
> >      i.      yes:
> >do so and keep the generated source in SVN
> >  ii.      no:
> > add specific bundle build step to generate ur code
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 6 Oct 2008 10:18:57 +0200
> From: Thomas Menzel <tmenzel@xxxxxxx>
> Subject: RE: [smila-dev] epl source header vs. generated code
> To: Smila project developer mailing list <smila-dev@xxxxxxxxxxx>
> Message-ID:
> <6CDC32AFFBA5AA4B8BEA6397594F76BD1FA018F654@xxxxxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="utf-8"
>
> hi,
>
> i'm posting a question about this on the 
> http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/maillist.html 
> to get some input from others too and how they have handled this.
>
> Kind regards
> Thomas Menzel @ brox IT-Solutions GmbH
>
> -----Original Message-----
> From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] 
> On Behalf Of Ivan Churkin
> Sent: Montag, 6. Oktober 2008 09:59
> To: Smila project developer mailing list
> Subject: Re: [smila-dev] epl source header vs. generated code
>
> Hi folks.
>
> We using XJC generation tool for generating JAXB classes from XSD schemes.
> For each class XJC generates headers, like the next one.
>
> // This file was generated by the JavaTM Architecture for XML
> Binding(JAXB) Reference Implementation, vhudson-jaxb-ri-2.1-520
> // See <a
> href="http://java.sun.com/xml/jaxb";>http://java.sun.com/xml/jaxb</a>
> // Any modifications to this file will be lost upon recompilation of the
> source schema.
> // Generated on: 2008.05.19 at 09:37:58 AM GMT
>
>
> but, it's not a EPL license type header and XJC does not support custom
> file headers  (its only allowed to turn header off).
>
> We may to add some tasks to build procedure for compiling schemes to
> classes by XJC on the fly.
> But I beware that it may be not convenient for developers because this
> classes required in dev stage.
>
> Situation:
> Developer creates bundle with generated classes located in "code/gen" 
> folder
> Solutions:
> 1. Developer excludes manually "code/gen" folder from SVN commit and it
> will be added task for make.xml to generate classes "on the fly" for 
> budles
> 2. It's possible to fix XJC compiler for supporting custom/configurable
> file header
>
> What is better by your opinion?
>
> --
> Regards, Ivan
>
>
>
> Thomas Menzel wrote:
> >do I have generated to code?
> >a.       yes:
> >does the generator support custom file headers to put it the EPL?
> >      i.      yes:
> >do so and keep the generated source in SVN
> >  ii.      no:
> > add specific bundle build step to generate ur code
>
>
> _______________________________________________
> smila-dev mailing list
> smila-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/smila-dev
>
> ------------------------------
>
> Message: 3
> Date: Mon, 6 Oct 2008 10:54:17 +0200
> From: Thomas Menzel <tmenzel@xxxxxxx>
> Subject: [smila-dev] code freeze for renaming org.EILF -> smila
> To: Smila project developer mailing list <smila-dev@xxxxxxxxxxx>
> Message-ID:
> <6CDC32AFFBA5AA4B8BEA6397594F76BD1FA018F664@xxxxxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="us-ascii"
>
> hi folks,
>
> we need to rename all our bundles from the old eilf to smila to be able to 
> checkin our code @ eclipse.
> there was already the notion that this should just make one person, and I 
> agree it has certain benefits.
> on the other hand this way it will take a few days and during this time we 
> really should have a code freeze, i.e. where no other check ins occur.
>
> so how does it look on ur end in regard to that?
> can we lock done the SVN for ~3 days so this can be done?
> or are there very important changes that u are working on that will make 
> it particular painful merging/resolve conflict session for u?
> if so, when would be a good time/when is ur tricky part done?
>
> if there is no negative feedback on this we plan to do this ASAP, e.g. as 
> of tomorrow.
>
> Kind regards
> Thomas Menzel @ brox IT-Solutions GmbH
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> https://dev.eclipse.org/mailman/private/smila-dev/attachments/20081006/d2b209f5/attachment.html
>
> ------------------------------
>
> Message: 4
> Date: Mon, 6 Oct 2008 10:56:14 +0200
> From: Thomas Menzel <tmenzel@xxxxxxx>
> Subject: [smila-dev] opinion wanted: check in generated code or not
> vs.copyright notice
> To: "eclipse.org-committers@xxxxxxxxxxx"
> <eclipse.org-committers@xxxxxxxxxxx>
> Cc: Smila project developer mailing list <smila-dev@xxxxxxxxxxx>
> Message-ID:
> <6CDC32AFFBA5AA4B8BEA6397594F76BD1FA018F665@xxxxxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="us-ascii"
>
> hi,
>
> I just wanted to get your opinion on this subject:
>
> we have some generated code (JAXB) that we use in the SMILA project.
>
> in the past we have just checked in these source files in our non-eclipse 
> projects as they change infrequently and are needed for the developers to 
> write their code.
> now, at eclipse we need to provide a proper copyright notice but 
> unfortunately the code generator  wont let us add a custom jdoc where we 
> could place that.
> modifying the generated source files to add the notice is cumbersome and 
> probably tends to get forgotten.
>
> generating during build is technically feasible but from the developers 
> point of view not an ideal situation as the code would be cleaned on every 
> build and u would have to make at least a partial build to start 
> developing.
>
> so, have anybody of u crossed this issue as well?
> how have u dealt with it in regard  to IP cleanliness?
>
> Kind regards
> Thomas Menzel @ brox IT-Solutions GmbH
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> https://dev.eclipse.org/mailman/private/smila-dev/attachments/20081006/a423c939/attachment.html
>
> ------------------------------
>
> Message: 5
> Date: Mon, 6 Oct 2008 11:16:09 +0200
> From: <Juergen.Schumacher@xxxxxxxxxxx>
> Subject: RE: [smila-dev] code freeze for renaming org.EILF -> smila
> To: <smila-dev@xxxxxxxxxxx>
> Message-ID:
> <69D276452CD2904980D5B6AC33C9BE170D4C6145@xxxxxxxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Make it so (:
>
>
>
> Cheers,
>
> Juergen.
>
>
>
> From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] 
> On Behalf Of Thomas Menzel
> Sent: Monday, October 06, 2008 10:54 AM
> To: Smila project developer mailing list
> Subject: [smila-dev] code freeze for renaming org.EILF -> smila
>
>
>
> hi folks,
>
>
>
> we need to rename all our bundles from the old eilf to smila to be able to 
> checkin our code @ eclipse.
>
> there was already the notion that this should just make one person, and I 
> agree it has certain benefits.
>
> on the other hand this way it will take a few days and during this time we 
> really should have a code freeze, i.e. where no other check ins occur.
>
>
>
> so how does it look on ur end in regard to that?
>
> can we lock done the SVN for ~3 days so this can be done?
>
> or are there very important changes that u are working on that will make 
> it particular painful merging/resolve conflict session for u?
>
> if so, when would be a good time/when is ur tricky part done?
>
>
>
> if there is no negative feedback on this we plan to do this ASAP, e.g. as 
> of tomorrow.
>
>
>
> Kind regards
>
> Thomas Menzel @ brox IT-Solutions GmbH
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> https://dev.eclipse.org/mailman/private/smila-dev/attachments/20081006/938b29e2/attachment.html
>
> ------------------------------
>
> _______________________________________________
> smila-dev mailing list
> smila-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/smila-dev
>
>
> End of smila-dev Digest, Vol 4, Issue 9
> ***************************************
>
> 


_______________________________________________
smila-dev mailing list
smila-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/smila-dev


Back to the top