Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [gmf-dev] Generated NOT for class hierarchy
Hello,

Thanks Ed for answering this.

Also GMF-T uses slightly modified custom version of merger, I have just rechecked that @implements / @extends behavior had been left untouched, and the  snippet:
/**
 * <!-- begin-user-doc -->
 * @implements java.lang.Cloneable
 * <!-- end-user-doc -->
 *
 * @generated
 */
indeed preserves implements clause between GMF-T regenerations.

@Igor,
I would also like to insist to use this mailing list for internal development-related discussion between GMF developers.

Please note that we are sharing this list with GMF Runtime and GMF Notation developers, so right now I am effectively spamming those who is probably not very interested in how GMF-T does the merging of generated java files.

Given that this mailing list is a standard channel for releng and cross-project issues, I believe it is better to avoid using it for any other topics.

If you feel that your forum question is not handled, please don't hesitate to contact me at golubev<>montages<>com and I will try to ensure it is finally answered.

Regards,
Michael
--

Michael "Borlander" Golubev
Eclipse Committer (GMF, UML2Tools)
at Montages Think Tank, Prague, Czech Republic
1165/1 Dvorecka, 14700, Prague-4 Podoli

tek: +420 602 483 463



On Mon, Apr 1, 2013 at 1:01 PM, Igor Zapletnev <igor.zapletnev@xxxxxxxxx> wrote:
Yes, I absolutely agree with you that gmf-dev should be used only for the committers.
But when I want to ask some questions for eclipse project my first query is "project-Name user mailing group", like jetty, m2e, ptp or tycho.
I have filters in my inbox it helps to organize all mailing lists. So each of this approach has advantages or/and disadvantages.


On Mon, Apr 1, 2013 at 5:49 PM, Ed Merks <ed.merks@xxxxxxxxx> wrote:
Igor,

The forum is accessible via NNTP which is something the people who respond to questions can poll and keep separate from their regular email and it works exactly like email (at least in my Thunderbird it does).

news://news.eclipse.org:119/eclipse.modeling.gmf

In the end it comes down to the preferences of the developers.  Personally I insist that people not use the emf-dev mailing list for questions; it's intended for the committers to discuss project-related issues.   The gmf-dev developers may have different preferences from mine and can speak for themselves.


On 01/04/2013 12:41 PM, Igor Zapletnev wrote:
Thanks Ed for your help.
I think mailing list is more userfriendly for any eclipse discussions because to check news on the forum you need go to your browser, check all topics etc. 
Probably gmf-user mailing list will be very popular.

Thanks,
Igor



On Mon, Apr 1, 2013 at 5:33 PM, Ed Merks <ed.merks@xxxxxxxxx> wrote:
Igor,

I think it's probably better to use the forum not the developer mailing list.

There are two solutions.  One is to use something other than @generated NOT, e.g., @generated not, to block just the merging of the extends/implements part of the class/interface but still allow merging of the nested contents.  Another approach (better I think) is to use @extends/@implements (they do the same thing) in the user-doc section of the code.  E.g., like we do in EClassifierImpl as follows:


/**
 * <!-- begin-user-doc -->
 * An implementation of the model object '<em><b>EMeta Object</b></em>'.
 * @extends BasicExtendedMetaData.EClassifierExtendedMetaData.Holder
 * <!-- end-user-doc -->
 * ...............
 * @generated
 */
public abstract class EClassifierImpl extends ENamedElementImpl implements EClassifier, BasicExtendedMetaData.EClassifierExtendedMetaData.Holder
{

Then the JMerger will add those things automatically each time.


On 01/04/2013 12:16 PM, Igor Zapletnev wrote:
Hi,

I want to add additional interface for my edit part, for example. In this case I need to add @generated NOT annotation in the header of the file.

Probably I can add my custom interface without annotation in the header?
Somth like that

/**
 * @generated
 */
public class NameEditPart extends CompartmentEditPart implements
ITextAwareEditPart, /** @generated NOT */ MyInterface {

Thanks,
Igor


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


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




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


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



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




Back to the top