Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between pages "Graphical Modeling Framework/Tutorial/Part 2" and "WTP Build Process and Procedures"

< Graphical Modeling Framework‎ | Tutorial(Difference between pages)
m
 
m (→‎Build mechanics)
 
Line 1: Line 1:
−
In this second part of the GMF Tutorial, some of the more advanced capabilities of the generation and runtime frameworks will be explored. Specifically, information on adding feature initializers, diagram validation, nested child nodes, and manual extension of generated features will be covered.
+
This page is to collect general information and references about the WTP build process and procedures. The idea is that any WTP committer can update it, pretty much "on the fly" or "as you go", or "as needed", so that there will often be a bit of a disorganized, stream of consciousness flavor to it. Hopefully, occasionally, some kind-hearted committer will stop and organize all the miscellaneous notes and tips and references that are provided, into fun-to-read treasure that you  just can't put down.  
  
−
== Feature Initializers ==
+
Note: since only committers can edit these pages, if anyone from the community has contributions or suggestions for additions, please open a [[https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Web%20Tools;component=releng feature request]] on our releng component.
  
−
When you create a new element on a diagram, there is typically a domain element created or modified as a result.  In some cases, it's necessary to provide additional initialization information to ensure that objects are properly created.  For example, the links we create between topics in our mindmap diagram come in three flavors: dependency, includes, and extends. The 'type' attribute of the Relationship class is used to hold the RelationshipType enum value for the new instance.  In our graphical definition, we will create a figure and corresponding link for each type, along with a creation tool for each in our tooling definition.  We'll then use a feature sequence initilizer in our mapping definition to properly initialize our domain objects, depending on the type of link created on the diagram.
+
Thanks, [[User:David williams|David Williams]] 01:42, 2 February 2006 (EST)
  
−
Another possible initialization is to set the 'label' attribute of the Relationship as well, if the appearance of the link is not enough to distinguish between the types. 
+
== Build Schedules ==
  
−
[[Image:graph_links.png|right]]
+
As of February 1, 2006
  
−
First, create a three distinct polyline connections with properties and decorations as you see fit. For each add a connection for each of the new Dependency, Includes, and Extends links as shown in the figure. For each connection, create a Creation Tool in your mindmap.gmftool model.
+
Our WTP 1.0.1 contributions are due by EOD on Monday's, we smoke test that build on Tuesday's, and plan to declare it by Wednesday's at noon (eastern time).  
  
−
<blockquote>
+
Our WTP 1.5 contributions are due by EOD Wednesday's, we smoke test that build on Thursday's, and plan to declare it by Friday's at noon (eastern time).  
−
<font color="darkblue">'''Tip''' :</font> Don't forget that you can use copy/paste to duplicate elements in your models.  This will come in handy as you create three links, connections, tools, and mappings.
+
−
</blockquote>
+
  
−
<br style="clear:both;"/>
 
  
−
[[Image:feature_init.png|right]]
+
== Build mechanics ==
  
 +
The platform's releng tool should be used to "release" projects to the map files.
 +
Be sure to have the appropriate branch of releng project (which has the map files)
 +
loaded in your workspace.
 +
R1_0_maintenance for 1.0.x builds, and HEAD for 1.5 builds.
  
−
In the mapping model, for each of your Link Mappings, create a 'Feature Seq Initializer' element. This will hold subsequent 'Feature Value Spec' elements as seen in the figure.  OCL is the language currently supported, so be careful that the body expressions you enter are valid.  In the case of initializing the enumeration field, you'll enter 'RelationshipType::DEPENDENCY' while in the case of initilizing the label attribute, you'll enter the string value within single quotes.  Keep in mind that the order of the 'Feature Value Spec' elements will determine the order in which they are executed.
+
As projects are versioned, please use the "standard" format, in UTC time, following
 +
vYYYYMMDDHHMM.  
 +
This is important as these cvs tags become the qualifier field of the plugin's version.
  
−
<br style="clear:both;"/>
+
Note: do NOT use underscores in the CVS version, as there are some issues with Eclispe tooling when it finds an underscore in a plugin or version qualifier, see [[https://bugs.eclipse.org/bugs/show_bug.cgi?id=89428 89428]].
  
−
With these steps complete, we can regenerate our mindmap.gmfgen and code. When the diagram code is generated, below is what willl be generated within the Initializers inner class of MindmapElementTypes:
+
== Background and Further Reading References ==
  
−
<pre>
+
We in WTP following the basic process and recommendations for versioning as the base Eclipse platform.
−
public static final ObjectInitializer Relationship_3003 = new ObjectInitializer(
+
[http://www.eclipse.org/equinox/documents/plugin-versioning.html Plugin Versioning]
−
new FeatureInitializer[] {
+
−
new FeatureInitializer(
+
−
"RelationshipType::DEPENDENCY", //$NON-NLS-1$
+
−
MindmapPackage.eINSTANCE.getRelationship(),
+
−
MindmapPackage.eINSTANCE.getRelationship_Type()),
+
  
−
new FeatureInitializer(
+
Very helpful guide to builds and automatic testing.
−
"'depends'", //$NON-NLS-1$
+
[http://www.eclipse.org/articles/Article-PDE-Automation/automation.html Build and Test Automation for plug-ins and features]
−
MindmapPackage.eINSTANCE.getRelationship(),
+
−
MindmapPackage.eINSTANCE
+
−
.getRelationship_Label())
+
  
−
});
+
Good step-by-step on how to do updates. [http://www.eclipse.org/articles/Article-Update/keeping-up-to-date.html How To Keep Up To Date]
−
</pre>
+
  
−
During link creation, the following code is executed in CreateIncomingRelationship3XXXCommand, found in the TopicItemSemanticEditPolicy class:
+
We base our builds on the Eclipse platform's "basebuilder".
 +
[http://wiki.eclipse.org/index.php/Platform-releng Platform-releng]
  
−
<pre>
+
With our WTP specific needs addressed in the WTP project called releng.wtpbuilder.
−
protected EObject doDefaultElementCreation() {
+
While slightly out of date, see the [[https://bugs.eclipse.org/bugs/attachment.cgi?id=26584 attachment]] to [[https://bugs.eclipse.org/bugs/show_bug.cgi?id=108259 bug 108259]]
−
Relationship newElement = (Relationship) super
+
−
.doDefaultElementCreation();
+
−
if (newElement != null) {
+
−
newElement.setTarget((Topic) getTarget());
+
−
newElement.setSource((Topic) getSource());
+
−
MindmapElementTypes.Initializers.Relationship_3004
+
−
.init(newElement);
+
−
}
+
−
return newElement;
+
−
}
+
−
</pre>
+
  
−
This generated code within FeatureInitializer will ultimately be called on each value spec you've added, which as you can see constructs an OCL query for evaluation and uses the result to initialize the field you selected.
+
Our basic server configuration and cruise control triggers is handled by the WTP project called releng.builder (see especially the tools/cruise directory in that project).
  
−
<pre>
+
And ... never forget [http://help.eclipse.org/help31/index.jsp Eclipse Help] ... search for things related to update manager, PDE, features, site.xml, etc.
−
void init(EObject contextInstance) {
+
−
if (this.query == null) {
+
−
this.query = QueryFactory.eINSTANCE.createQuery(
+
−
expressionBody, contextClass);
+
−
}
+
−
Object value = query.evaluate(contextInstance);
+
−
if (sFeature.getEType() instanceof EEnum
+
−
&& value instanceof EEnumLiteral) {
+
−
value = ((EEnumLiteral) value).getInstance();
+
−
} else if (value != null && sFeature.isMany()) {
+
−
value = new BasicEList((Collection) value);
+
−
}
+
−
contextInstance.eSet(sFeature, value);
+
−
}
+
−
</pre>
+
−
 
+
−
<br style="clear:both;"/>
+
−
 
+
−
[[Image:runtime_init.png|right]]
+
−
 
+
−
If you launch your runtime instance and test these new initializers, you will find that the type attribute is set according to the Relationship tool selected, and that the label attribute is preset to the names you defined above.
+
−
 
+
−
<br style="clear:both;"/>
+
−
 
+
−
== Validation ==
+
−
 
+
−
 
+
−
== Nested Child Nodes ==
+
−
 
+
−
 
+
−
== Manual Extension ==
+
−
 
+
−
== Summary ==
+

Revision as of 10:08, 6 February 2006

This page is to collect general information and references about the WTP build process and procedures. The idea is that any WTP committer can update it, pretty much "on the fly" or "as you go", or "as needed", so that there will often be a bit of a disorganized, stream of consciousness flavor to it. Hopefully, occasionally, some kind-hearted committer will stop and organize all the miscellaneous notes and tips and references that are provided, into fun-to-read treasure that you just can't put down.

Note: since only committers can edit these pages, if anyone from the community has contributions or suggestions for additions, please open a [feature request] on our releng component.

Thanks, David Williams 01:42, 2 February 2006 (EST)

Build Schedules

As of February 1, 2006

Our WTP 1.0.1 contributions are due by EOD on Monday's, we smoke test that build on Tuesday's, and plan to declare it by Wednesday's at noon (eastern time).

Our WTP 1.5 contributions are due by EOD Wednesday's, we smoke test that build on Thursday's, and plan to declare it by Friday's at noon (eastern time).


Build mechanics

The platform's releng tool should be used to "release" projects to the map files. Be sure to have the appropriate branch of releng project (which has the map files) loaded in your workspace. R1_0_maintenance for 1.0.x builds, and HEAD for 1.5 builds.

As projects are versioned, please use the "standard" format, in UTC time, following vYYYYMMDDHHMM. This is important as these cvs tags become the qualifier field of the plugin's version.

Note: do NOT use underscores in the CVS version, as there are some issues with Eclispe tooling when it finds an underscore in a plugin or version qualifier, see [89428].

Background and Further Reading References

We in WTP following the basic process and recommendations for versioning as the base Eclipse platform. Plugin Versioning

Very helpful guide to builds and automatic testing. Build and Test Automation for plug-ins and features

Good step-by-step on how to do updates. How To Keep Up To Date

We base our builds on the Eclipse platform's "basebuilder". Platform-releng

With our WTP specific needs addressed in the WTP project called releng.wtpbuilder. While slightly out of date, see the [attachment] to [bug 108259]

Our basic server configuration and cruise control triggers is handled by the WTP project called releng.builder (see especially the tools/cruise directory in that project).

And ... never forget Eclipse Help ... search for things related to update manager, PDE, features, site.xml, etc.

Retrieved from "https://wiki.eclipse.org/index.php?title=Graphical_Modeling_Framework/Tutorial/Part_2&oldid=2111"

Back to the top