Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [smila-dev] epl source header vs. generated code

doh, of course!  ..unless u work via reflection, but that would be even more hassle....

well, then i'm for prepending the header info after generating the files.

fixing the JAXB generator would be nice, but I'd let them worry about that.

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 13:24
To: Smila project developer mailing list
Subject: Re: [smila-dev] epl source header vs. generated code

Hi Thomas

developers always need access to the generated classes inside eclipse ide.
otherwise it will be compile errors and it will be impossible to launch
application by launcher for debugging - it will be impossible to work ).

So, if generate during build "on the fly" it will be also required to
generate manually and exclude from SVN
it's not so hard, from the other hand...

Thomas Menzel wrote:
> hi,
>
> 1. i personally resent the idea of checking in generated code, hence I'd prefer to have that in the build process, although I see the convenience of it.
>
> 2. I see the problem for the developers that need the generated classes if they want to program their code. but is this really problem? the dev. developing the bundle surely knows what he needs to do. a more valid case would be if these generated classes are used outside the bundle. this then causes an avalanche of compiler errors in eclipse. but do we have such cases? where? would it be better to remove such dependencies and restrict the usage of the generated classes to inside the bundle?
> IMO it is likely that the generated code changes more frequently than a bundle API really should... (API in the eclipse sense). internalizing makes even more sense when u think of the case that (for JAXB) a schema gets adjusted to provide new features but the API really should change because of existing code base breakage etc.
>
>
> 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 12:47
> To: Smila project developer mailing list
> Subject: Re: [smila-dev] epl source header vs. generated code
>
> Hi Marius,
> Thank you for the idea.
> I may suggest small  upgrade :  to generate classes without header
> initially - it will be easier to match
>
> so, there are 3 ideas:
>
> 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"
> 2. to fix XJC compiler for supporting configurable file header
> 3. to patch generated files by ANT immediately after compiling schema
>
>
> --
> Regards,  Ivan
>
>
> Marius Cimpean wrote:
>
>> 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
>>
>
> _______________________________________________
> smila-dev mailing list
> smila-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/smila-dev
> _______________________________________________
> smila-dev mailing list
> smila-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/smila-dev
>

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


Back to the top