I Use This!
Very High Activity

News

Analyzed 6 days ago. based on code collected 15 days ago.
Posted 3 days ago
The WildFly/EAP team is looking for a Eclipse developer to help move forward the Eclipse IDE tooling around WildFly/EAP server, Java and JavaEE. If you are into making developers life easier and like to be able to ... [More] get involved in many different technologies and get them to work great together then do apply for this one. The official job listing are here: Senior Software Engineer Have fun! Max Rydahl Andersen @maxandersen [Less]
Posted 3 days ago
Scott Jenson published a very good article last week, where he nicely showed how far away we still are from the shiny Jetson-like marketing promises about smart homes. He asked us to take a step back so that we can think about the holistic shape of ... [More] the “right” solution for smart homes. Let’s do so! Missing Technology? Doing a shameless shortening of his thoughts, he concluded that many issues would be solved if all devices had a smart setup that allows users a very simple way of commissioning auto-arrangement through proximity-detection a globally accepted way of announcing their capabilities a mechanism to share their data instead of keeping it in a silo These are the technologies that we as a community are still lacking and that need to be tackled. Only if these are in place, it will enable devices to automatically form a distributed ensemble which we all aim for. While I very much agree with all his points, I believe that solving the technological issues alone won’t suffice, but that we need to take yet another step back to see the big picture. Taking Another Step Back When talking about adding IoT devices to “the network”, it is out of question for most people to wonder “which network” - since we are talking about the Internet of Things, the network can only be The Internet where everything is connected, right? Silos and Accounts If we have a closer look at today’s smart home devices (and also other IoT setups), the truth is that everyone uses IP, i.e. Internet technology. But are the devices available “on the Internet”? No, many of them effectively do not allow you to communicate in any direct way with them. Instead, they open an encrypted tunnel to a cloud service, which then acts as a portal to the device for the user - all data is kept secretly (not saying securely) in the cloud under full control of the manufacturer. Effectively, we have a big number of siloes that can be regarded as VPNs. It is important to note that these are deliberate silos - this choice is not (only) the fault of missing interoperability standards! This setup is a major reason for Scotts points 1 (smart setup) and 4 (sharing data): The manufacturers do not want to give control to the users, but instead force them to create accounts at their cloud service, accept the manufacturers terms and conditions and let the manufacturer decide how and with whom to share the data. This is the major issue that needs to be addressed: The mindset of people that are building IoT devices must move away from this omni-present IoT architecture. The outlook that users will have to create web accounts for every single household object (everything’s going to be connected, right?) they buy in the future is ridiculous. This works as long as only nerds with a dozen devices play around with smart homes, but it definitely won’t scale. Manufacturers must let their devices go - only if they are unleashed the devices will have a chance to communicate with each other and form distributed ensembles. Internet vs. Intranet Let’s for the moment assume the devices were unleashed. Is the Internet then really the best place for them? Even if all potential authentication and authorization issues were solved, we all know that all those devices are hackable. Do we really want to see them publicly listed on Shodan.io? Having isolated VPNs isn’t such a bad idea after all and in the case of the smart home the most natural fit is the local Intranet. What you want to have on the public Internet are services (hosted on “real” servers that are hardened against attacks) and not household devices. A good compromise is in my opinion the concept of the Physical Web, where the discovery and authorization could be done through low-range radio like BLE, while the heavy lifting is done through cloud servers - but this really hardly applies to the smart home itself. If services of a home should be shared (this decision should really be up the user), it could be made available on any standard-compliant cloud service (i.e. no vendor lock-in), once Lego brick 3 (Standard Descriptions) is in place. Unfortunately, I am not as optimistic as Scott to have a “shared, common approach soon” - maybe for technical operability, but most likely not for semantical interoperability. A Matter of Perspective Taking the perspective of the user instead of the perspective of the manufacturer definitely brings us much closer to the desired solution. But putting the user in the center also causes some dilemma in the context of a smart home: After all, a home usually has multiple inhabitants, furthermore there are visitors, pets, burglars (hopefully not), etc. For the home to become smart and autonomous, the devices must become an integral part of the home and must not be a property of a single user. This is another clear indicator that we are still in an early phase: Most devices are bought off-the-shelf, installed DIY and registered to a certain user, who configures it to meet his needs. The devices are the personal objects of a person; they are not a part of the home. If this person moves the house, he will take his personal belongings with him. This works as long as you have only a dozen smart bulbs, a door lock and a web cam. It won’t work - and especially it does not make any sense - for a photovoltaic system, a complex central heating, the in-wall motion sensors, the smart frontdoor,… you get the point. You are also not ripping out the wall switches and your windows when you sell a house. A smart home should be allowed to exist on its own, even if nobody lives there. What brings it into existence are its bricks and its infrastructure - including the local IP network as the communicatin backbone for its parts. Water, Electricity, Smartness Smart home features and connectivity thus have to become a matter of course, just like electricity or water - it should not be treated as something that is retrofitted by the owner; instead, it must be an integral part of a home, which in turn becomes a smart, self-organizing entity. Having the devices build a local private network would ensure data privacy and the smallest possible attack target. This should be the long-term vision when designing smart home devices. In consequence, this means that devices must not require a mandatory user registration work (at least in a basic way) without a cloud connection provide a local API for interaction with other devices (and not limiting access to a small set of business-oriented partnerships) and expect the same from the others In short, things should focus again on being things in the first place and not cloud-connected devices - they must be unleashed to show their full potential. This might sound trivial, but unfortunately these features are widely ignored in the industry - although they would secure the adoption of smart home technology in the long-term. How can the industry possibly be influenced to see that a bit more communism will eventually grow the cake for everyone? [Less]
Posted 3 days ago by nore...@blogger.com (Andrey Loskutov)
A look on Eclipse 4.6 from Eclipse 3.8 point of view The good, the bad and the ugly PrefaceThis is my personal, condensed, not comprehensive overview of changes in the Eclipse platform happened between last major 3.x release (3.8.0) from September ... [More] 2012 and now (4.6.3). This overview is written from a user perspective and is for end-users, API changes are not part of the discussion.Here are official "New and Noteworthy" links for each release:4.2 N&N (2012)4.3 N&N (2013)4.4 N&N (2014) 4.5 N&N (2015)4.6 N&N (2016)Please note that Eclipse 3.8.0 was released at same time with 4.2.1 but did not contain some features related to the UI programming model change. The difference between 3.8.0 and 4.6.3 are not just 5 years or 5 major Eclipse releases, it is also a bigger change of the UI programming model from 3.x to 4.x API (aka e4).Why to talk about 3.x to 4.x changes today? Because Eclipse 3.8.2 was exceptionally well made, stable and reliable release. It required five (!) 4.x releases to reach similar stable state (may be not even same state, but at least some usable state). Also because most plugins till recently were still supporting 3.x stream and because 3.x was good enough to support development of Java 7 based software. But as soon as your business switches to Java 8, the time is for Eclipse 4.x, because JDT in 3.8 does not know and does not support Java 8. Themes aka L&F Eclipse 4.x introduces "themed UI", where many UI elements can be "styled" with CSS rules. This is a highly controversial change, which from the one side allowed such features like "dark theme" but from the other side ruined UI performance, especially in distributed environments. A good example how NOT to design ergonomic IDE theme (4.2. on Windows) Same misery (4.2.1) on Linux 3.8.0 on same system Either way (with or without themes), Eclipse 4.x doesn't look like Eclipse 3.8. Initial 4.2.1 in the default theme was simply ugly, on every operating system. With the time, 4.x stream got some polishing and starting with 4.6 reached the state of 3.8, more or less. From the performance point of view, CSS themes add a considerable computational overhead for complex UI's (plus extra layer of code which can be broken) and can significantly slow down Eclipse (to completely unusable state) in specific environments, like remote usage via vncviewer, rdesktop and Co. Recommendation: don't use CSS themes to have less bugs, slicker and faster UI experience. Here is the how Eclipse looks like on Windows 10 without CSS themes: 4.6.3 with themes disabled, Windows 10 High-DPI monitors support SWT now automatically scales images on high-DPI monitors on Windows and Linux, similar to the Mac's Retina support on OS X. In the absence of high-resolution images, SWT will auto-scale the available images to ensure that SWT-based applications like Eclipse are scaled proportionately to the resolution of the monitor. Sometimes this automatic scale doesn't work or looks not nice - in this cases there are ways to tweak the default behavior.  GTK3 support  As if it would be not enough UI nonsense introduced with new themes, Eclipse 4.5+ uses GTK3 instead of GTK2 on Linux by default. Slick, useful, clean widgets from GTK2 are replaced by a pixel eating monsters from GTK3. The only solution for that is to use GTK3 themes with more "human" button sizes, but good GTK3 themes are very rare. Unfortunately, GTK3 is here to stay and GTK2 will be obsoleted sooner or later. One can still switch to GTK2 however: either export SWT_GTK3=0 in the shell before starting Eclipse or add this two lines to your eclipse.ini: --launcher.GTK_version2 Modeled UI Eclipse 4.x UI layout is more flexible and removes some restrictions 3.x Eclipse had. Now one can place editors and views in the same stack and move editors outside of the main window. FWIW, I personally never used this flexibility, but there are always corner cases where this could be useful. Flexible UI Unfortunately, with flexibility comes also complexity and bugs. So migration from 3.x workspace to 4.x with opened editors results in editors without close buttons and close menus (bug 509712). First time user who don't know this are surprised and are helpless to find out how to close the editor in the new world. Another bug (511798) is also not nice: if you have two editors in the split screen mode (like in example above), you will see an ugly white bar over them. Quick access One shortcut every Eclipse user should learn is , or "Quick Access". You can open views, start commands etc, very handy. To make it more prominent for new users, a permanent text box was added in the top right corner in Eclipse 4.x. Unfortunately, this changed the location and size of the resulting dialog, which a step backwards compared to 3.x. Instead to open in front of user and have appropriate size and location, it opens somewhere far right, with a small size where nothing really fits into. Crippled Quick Assist in 4.x Fortunately, there is a workaround which allows to restore 3.x L&F. One has to right click on the thin text box border and if one has luck, one will be able to click on the "Hide" menu: Hide that ugly box! and voila, the old good quick assist appears at the expected location and with size where everything fits: Welcome back, quick assist with 3.x L&F! Open resource Open Resource dialog got some love. It can now filter duplicated resources, show or hide derived resources, show only files from specific working set. Additionally, files can be either opened with a default editor or user can choose which editor should be used to open them. Split editor Sometimes one want to see code from two functions at same time - in a large file this is of course not possible, therefore there is now a new Window > Editor > Toggle Split Editor menu: Split editor vertical Word wrap Believe or not, it took only 12 years for Eclipse to implement soft wrapping in text editors. But better later then never, we have now a button on the toolbar and a shortcut to toggle word wrapping in the current editor: Word wrap! Configure left and right sides in Compare editors Another one change we waited about 10 years finally quietly made into Eclipse 4.6.2 release: one can configure Eclipse to show the new changes on the right side of the diff editor! Unbelievable, but differently to the rest of the world, Eclipse always has shown local changes not on the right but on the left side, which was and is quite surprising for everyone. Since the old way was there for a decade, by default, the compare editor still shows the local changes on the left side, but the user finally can change this! There are two ways to do so: a new "swap left and right view" button in the compare editor toolbar: Local changes on the right side! and the Window > Preferences > General > Compare / Patch > Text Compare > Swap left and right: Preference to see local changes on the right side Console improvements Word wrap button is also added to all I/O consoles, where it enables soft word wrapping for long output. Beside this, I/O consoles got "automatic scroll lock" mode, which is automatically enabled by scrolling up in the Console view using keys, mouse wheel, or scroll bar. When you scroll down to the end of the console, the scroll lock is automatically released again. Console with word wrap and scroll lock Root of all evil Don't drink and drive Don't run Eclipse as root! This happens seldom, but if it happens, it will you make busy for the next few hours. Finally, Eclipse helps us and allows prevent to start it with root rights via new command line option: -protect root. This option will make sure Eclipse don't start if you have root rights on Linux. Show in system explorer Right click on any file or folder in Eclipse and say Show In > System Explorer. This will open system default "Explorer" and highlight the selected file or folder. In case the system default "Explorer" doesn't open (Linux), the command line to launch it can be configured under Window > Preferences > General > Workspace > Command for launching system explorer. Show In System Explorer Improved Open With ... Other dialog The Open With > Other... dialog now has: Open With... extended a filter field remembers last used choice options to remember the selected editor as default for the selected file name or type. Tabs "Close..." menus The context menu of editor and view tabs now offer Close Tabs to the Left and Close Tabs to the Right menu: Tabs menu MRU or automatic editor shufflingIn classic 2.x versions of Eclipse the editors tab placement strategy was simple: they were shown in exact the order they were opened by the user. This is how all tools in the universe work. Then, in Eclipse 3.0 this simple universal standard was changed to show the most recently used tabs (MRU) first, and automatically reorder tabs to always show few last used if there is not enough place to show all. This change was highly controversial, see lengthy discussions in bug 68684. Finally, via bug 461736 the tab visibility strategy has has been turned into a separate preference, so everyone can decide if MRU should be turned on or off.The new preference can be found under Window > Preferences > General > Appearance > Visible Tabs on overflow > Show most recently used tabs: MRU off! UI responsiveness monitoring This feature is might be uninteresting for the end user, but it greatly helps IDE developers to recognize misbehaved code which causes UI freezes. UI responsiveness monitoring can be turned on via Window > Preferences > General > UI Responsiveness Monitoring. UI responsiveness preferences Please enable monitoring and please report UI freezes (they are reported to the Eclipse error log) to bugzilla. Copy/paste for files improved / of a files in same folder in explorer views to create a copy automatically proposes now just the old name followed by the digit 2 (or 3, etc., if that name is already taken). This is really handy if one wants create few file duplicates in same folder. Shortcut for Skip All Breakpoints   A very handy Ctrl+Alt+B has been added as the shortcut for Skip All Breakpoints: Zoom font in editors and In text editors, you can now use Zoom In or and Zoom Out commands to increase and decrease the font size. Like a change in the Window > General > Appearance > Colors and Fonts preference page, the commands persistently change the font size in all editors of the same type. If the editor type's font is configured to use a default font, then that default font will be zoomed.Automatic save of dirty editors Auto-save of dirty editors is now available in Eclipse. The autosave option is disabled by default. A new autosave preference page (Window > Preferences > General > Editors > Autosave) is available and allows to enable/disable the autosave and change the interval of autosave. The countdown is reset on keyboard activity, mouse click, or when a popup is displayed (e.g. content assist, preference page, ...). Autosave preferences Workspace selection dialog The workspace selection dialog now allows you to start a previously selected workspace directly via a link. The path to the workspace is shortened. The full path is available if you hover over the link. You can remove existing entries via the context menu. Workspace selection dialog Screen space tweaks Main toolbar can be hidden (Window > Appearance > Hide Toolbar), and Eclipse window can be put in the "Full Screen" mode without title bar (Window > Appearance > Toggle Full Screen). In 4.7 there will be another tweak: Window > Appearance > Hide Status Bar. Guess what it will do :-) Print button is hidden Yep, the global toolbar does not show "Print" button by default, to save space. It turned out, no one actually uses this function, so why should it be on the main toolbar? Default text editor for unknown files Since ever Eclipse tried to open a system editor for files which did not have a dedicated editor in Eclipse. In 4.x there is a possibility to stop this and to chose to always use default text editor from Eclipse instead. On the Window > Preferences > General > Editors > File Association page, you can now define an editor selection strategy for unassociated file types. Three strategies are proposed out-of-the-box: System Editor; if none: Text Editor (default) will open the system editor associated with the file, if available. If no system editor is associated with the given file, fall back to the Eclipse Text Editor Text Editor will always open Eclipse's Text Editor on unassociated file types Ask via pop-up will open the same dialog as using Open With > Other... on a file and let you choose which editor to use (inside or outside the IDE) Keep in mind that in any case, it's possible to assign an editor for an unassociated file type either via this same preference page, or via the Open With > Other... context-menu on the fileEclipse sources are in Git Along with 4.x transition, all Eclipse sources were moved to Git (from CVS). This opened a really nice path for contributions. If you are interested in Eclipse hacking, or just want to fix this nasty XYZ bug - please consider to contribute back to the community: https://wiki.eclipse.org/Platform_UI/How_to_Contribute. [Less]
Posted 5 days ago
Lots of thanks to Christian for figuring this out together. The complete example is available on github. Also, we included all the files as Listings at the end of the article. They are heavily commented. Objective Inside an Eclipse plugin, we have ... [More] EMF models defined in both Xcore and Ecore, using types from each other. Also, we have a Helper Xtend class that’s called from Xcore and uses types from the same model. We want to build the Eclipse Plugin with Maven. We also don’t want to commit any generated sources (from Xtend, Xcore, or Ecore). Issue Usually, we would use xtend-maven-plugin to build the Xtend classes, xtext-maven-plugin to build the Xcore model, and MWE2 to build the Ecore model. However, we have a cyclic compile-time dependency between AllGreetings calling GreetingsHelper.compileAllGreetings() which receives a parameter of type AllGreetings. Solution Java (and Xtend) can solve such cycles in general, but only if they process all members at the same time. Thus, we need to make sure both Xtend and Xcore are generated within the same Maven plugin. We didn’t find a way to include the regular Ecore generator in the same step, so we keep this in a separate MWE2-based Maven plugin. For generating persons.ecore, we call an MWE2 workflow from Maven via exec-maven-plugin. The workflow itself gets a bit more complicated, as we use INamedElement from base.xcore as a supertype to IPerson inside persons.ecore. Thus, we need to ensure that base.xcore is loaded, available, and can be understood by the Ecore generator. Afterwards, we use xtext-maven-plugin to generate both Xtend and the two Xcore models. To do this, we need to include all the required languages and dependencies into one single plugin in our maven pom. Missing Bits The workaround of using MWE2 to build Ecore models has (presumably) the side effect that we cannot refer to Ecore contents within Xtend. The respective parts are commented in GreetingsHelper.compileAllPersons() and drawn grey in the diagram above. Remarks We developed this using Eclipse Mars.2. The example project should be free of errors and warnings, and builds in all of Eclipse, MWE2, and Maven.In Maven, you might see some warnings due to an Xtext bug. It should not have any negative impact. When creating the Ecore file, make sure only to use built-in types (like EString) from http://www.eclipse.org/emf/2002/Ecore. They may be listed several times. In our genmodel file, Eclipse tends to replace this way of referring to platform:/resource/org.eclipse.emf.ecore/model/Ecore.genmodel#//ecore by something like ../../org.eclipse.emf.ecore/model/Ecore.genmodel#//ecore. This would lead to ConcurrentModificationException in xtext-maven-plugin or MWE2, or “The referenced packages ”{0}” and ”{1}” have the same namespace URI and cannot be checked at the same time.” when opening the GenModel editor.In this case, open the genmodel file with a text editor and use the platform:/resource/org.eclipse.emf.ecore/model/Ecore.genmodel#//ecore form in the genmodel:GenModel#usedGenPackages attribute. Sadly, this needs to be fixed every time the Genmodel Editor saves the file. The Xcore builder inside Eclipse automatically picks up the latest EMF complianceLevel, leading to Java generics support in generated code. The maven plugin does not use the latest complianceLevel, thus we need to set it explicitly. The modelDirectory setting in both Xcore and Ecore seem to be highly sensitive to leading or trailing slashes. We found it safest not to have them at all. Using all the involved generators (MWE2, Xcore, Xtend, …) requires quite a few dependencies for our plugin. As a neat trick, we can define them in build.properties rather than MANIFEST.MF. This way, they are available at build time, but do not clog our run-time classpath. As we can see on the right, they are also listed separately in the Eclipse dependency editor. maven-clean-plugin seems to be quite sensitive how its filesets are described. Even when disregarding the .dummy.txt entries in our pom, the *-gen directories were only cleaned if we listed them in separate fileset entries. The workflow should reside within an Eclipse source folder. To separate it from real sources, we created a new source folder named workflow. Listings Project Layout GreetingsHelper.xtend 1234567891011121314151617181920212223242526272829303132 package de.nikostotz.xtendxcoremaven.greetings.helper import de.nikostotz.xtendxcoremaven.greetings.AllGreetings class GreetingsHelper { // This method is called from greetings.xcore and has AllGreetings as parameter type, // thus creating a dependency circle def static String compileAllGreetings(AllGreetings it) { var totalSize = 0 // We access the AllGreetings.getGreetings() method in two different ways // (for-each-loop and map) to demonstrate different error messages if we omit // 'complianceLevel="8.0"' in greetings.xcore for (greeting : it.getGreetings()) { totalSize = totalSize + greeting.getMessage().length } ''' Greetings: «it.getGreetings().map[greeting | greeting.getMessage()].join(", ")» ''' } // This does not work currently with Maven. I didn't figure out why yet, but have some clues: // AllGreetings.getPersons() refers to type IPerson, which is defined in Ecore. // This might not be generated yet when the Xtend generator runs in Maven. // def static String compileAllPersons(AllGreetings it) { // ''' // Hello Humans: // «it.getPersons().map[person | person.describeMyself()].join(", ")» // ''' // } } base.xcore 12345678910111213141516171819 @GenModel( // This sets the target directory where to put the generated classes. // Make sure NOT to start or end with a slash! // Doing so would lead to issues either with Eclipse builder, MWE2 launch, or Maven modelDirectory="de.nikostotz.xtendxcoremaven/xcore-gen", // required to fix an issue with xcore (see https://www.eclipse.org/forums/index.php/t/367588/) operationReflection="false" ) package de.nikostotz.xtendxcoremaven.base // This enables usage of the @GenModel annotation above. The annotation would work without // this line in Eclipse, but Maven would fail. // (WorkflowInterruptedException: Validation problems: GenModel cannot be resolved.) annotation "http://www.eclipse.org/emf/2002/GenModel" as GenModel interface INamedElement { String name } persons persons.ecore 1 < ?xml version="1.0" encoding="UTF-8"?> persons.genmodel 12345 < ?xml version="1.0" encoding="UTF-8"?> persons.ecore greetings.xcore 123456789101112131415161718192021222324252627282930313233343536 @GenModel( modelDirectory="de.nikostotz.xtendxcoremaven/xcore-gen", operationReflection="false", // This enables Java generics support in EMF (starting with version 6.0). // If omitted, we'd get a "Validation Problem: The method or field message is undefined" in Maven // because AllGreetings.getGreetings() would return an EList instead of an EList, thus // we cannot know about the types of the list elements and whether they have a 'message' property. // In other cases, this leads to error messages like "Cannot cast Object to Greeting". complianceLevel="8.0" ) package de.nikostotz.xtendxcoremaven.greetings // referring to Ecore import de.nikostotz.xtendxcoremaven.persons.persons.IPerson // referring to Xtend import de.nikostotz.xtendxcoremaven.greetings.helper.GreetingsHelper annotation "http://www.eclipse.org/emf/2002/GenModel" as GenModel class AllGreetings { contains IPerson[] persons contains Greeting[] greetings op String compileAllGreetings() { // calling Xtend inside Xcore GreetingsHelper.compileAllGreetings(this) } } class Greeting { String message refers IPerson person } MANIFEST.MF 1234567891011121314151617181920212223 Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: %pluginName Bundle-SymbolicName: de.nikostotz.xtendxcoremaven;singleton:=true Bundle-Version: 1.0.0.qualifier Bundle-ClassPath: . Bundle-Vendor: %providerName Bundle-Localization: plugin Bundle-Activator: de.nikostotz.xtendxcoremaven.XtendXcoreMavenActivator Require-Bundle: org.eclipse.core.runtime, org.eclipse.emf.ecore;visibility:=reexport, org.eclipse.xtext.xbase.lib, org.eclipse.emf.ecore.xcore.lib Bundle-RequiredExecutionEnvironment: JavaSE-1.8 Export-Package: de.nikostotz.xtendxcoremaven.greetings.impl, de.nikostotz.xtendxcoremaven.greetings.util, de.nikostotz.xtendxcoremaven.base, de.nikostotz.xtendxcoremaven.base.impl, de.nikostotz.xtendxcoremaven.base.util, de.nikostotz.xtendxcoremaven.persons.persons, de.nikostotz.xtendxcoremaven.persons.persons.impl, de.nikostotz.xtendxcoremaven.persons.persons.util Bundle-ActivationPolicy: lazy build.properties 1234567891011121314151617181920212223242526 # bin.includes = .,\ model/,\ META-INF/,\ plugin.xml,\ plugin.properties jars.compile.order = . source.. = src/,\ emf-gen/,\ xcore-gen/,\ xtend-gen/ src.excludes = workflow/ output.. = bin/ # These work the same as entries in MANIFEST.MF#Require-Bundle, but only at build time, not run-time additional.bundles = org.eclipse.emf.mwe2.launch,\ org.apache.log4j,\ org.apache.commons.logging,\ org.eclipse.xtext.ecore,\ org.eclipse.emf.codegen.ecore.xtext,\ org.eclipse.emf.ecore.xcore,\ org.eclipse.xtend.core,\ org.eclipse.emf.codegen.ecore,\ org.eclipse.emf.mwe.core,\ org.eclipse.emf.mwe.utils,\ org.eclipse.emf.mwe2.lib generateGenModel.mwe2 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647 module GenerateGenModel var projectName = "de.nikostotz.xtendxcoremaven" var rootPath = ".." Workflow { // This configures the supported model types for EcoreGenerator. // Order is important. // Should be the same list as in Reader below. bean = org.eclipse.emf.ecore.xcore.XcoreStandaloneSetup {} bean = org.eclipse.xtend.core.XtendStandaloneSetup {} bean = org.eclipse.xtext.ecore.EcoreSupport {} bean = org.eclipse.emf.codegen.ecore.xtext.GenModelSupport {} bean = org.eclipse.emf.mwe.utils.StandaloneSetup { // Required for finding the platform contents (Ecore.ecore, Ecore.genmodel, ...) under all circumstances platformUri = "${rootPath}" // Required for finding above mentioned models inside their Eclipse plugins scanClassPath = true } // As persons.ecore refers to a type inside base.xcore (IPerson extends INamedElement), // we need to load base.xcore before we can generate persons.ecore. component = org.eclipse.xtext.mwe.Reader { // This configures the supported model types for this Reader. // Order is important. // Should be the same list as beans above. register = org.eclipse.emf.ecore.xcore.XcoreStandaloneSetup {} register = org.eclipse.xtend.core.XtendStandaloneSetup {} register = org.eclipse.xtext.ecore.EcoreSupport {} register = org.eclipse.emf.codegen.ecore.xtext.GenModelSupport {} // This asks the Reader to read all models it understands from these directories (and sub-directories). path = "model" path = "src" // Put the models inside a ResourceSet that's accessible by the EcoreGenerator. loadFromResourceSet = {} } // Generate persons.ecore (via persons.genmodel). component = org.eclipse.emf.mwe2.ecore.EcoreGenerator { genModel = "platform:/resource/${projectName}/model/persons.genmodel" srcPath = "platform:/resource/${projectName}/emf-gen" } } pom.xml 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359 4.0.0 de.nikostotz.xtendxcoremaven 1.0.0-SNAPSHOT de.nikostotz.xtendxcoremaven UTF-8 1.8 1.8 3.7.100 3.5.101 2.12.0 2.12.0 2.11.0 2.10.0 1.2.0 1.3.1 1.1.100 2.8.3 org.eclipse.emf org.eclipse.emf.common ${emf-common-version} org.eclipse.emf org.eclipse.emf.ecore ${emf-version} org.eclipse.emf org.eclipse.emf.ecore.xcore.lib ${ecore-xcore-lib-version} org.eclipse.xtext org.eclipse.xtext.xbase.lib ${xtext-version} org.apache.maven.plugins maven-compiler-plugin 3.3 maven-clean-plugin 2.6.1 .dummy.txt emf-gen .dummy.txt xtend-gen .dummy.txt xcore-gen org.codehaus.mojo build-helper-maven-plugin 1.9.1 add-source generate-sources add-source ${basedir}/emf-gen ${basedir}/xcore-gen ${basedir}/xtend-gen org.codehaus.mojo exec-maven-plugin 1.4.0 mwe2Launcher generate-sources java org.eclipse.emf.mwe2.launch.runtime.Mwe2Launcher ${project.basedir}/workflow/generateGenModel.mwe2 -p rootPath=${project.basedir}/.. compile true false org.eclipse.emf org.eclipse.emf.mwe2.launch ${emf-mwe2-launch-version} org.eclipse.xtext org.eclipse.xtext.xtext ${xtext-version} org.eclipse.text org.eclipse.text ${eclipse-text-version} org.eclipse.core org.eclipse.core.resources ${core-resources-version} org.eclipse.xtend org.eclipse.xtend.core ${xtext-version} org.eclipse.xtext org.eclipse.xtext.ecore ${xtext-version} org.eclipse.xtext org.eclipse.xtext.xbase ${xtext-version} org.eclipse.emf org.eclipse.emf.codegen.ecore.xtext ${ecore-xtext-version} org.eclipse.emf org.eclipse.emf.common ${emf-common-version} org.eclipse.emf org.eclipse.emf.ecore ${emf-version} org.eclipse.emf org.eclipse.emf.ecore.xmi ${emf-version} org.eclipse.emf org.eclipse.emf.codegen ${emf-codegen-version} org.eclipse.emf org.eclipse.emf.codegen.ecore ${emf-codegen-version} org.eclipse.emf org.eclipse.emf.ecore.xcore ${ecore-xcore-version} org.eclipse.emf org.eclipse.emf.ecore.xcore.lib ${ecore-xcore-lib-version} org.eclipse.text org.eclipse.text ${eclipse-text-version} org.eclipse.core org.eclipse.core.resources ${core-resources-version} org.eclipse.xtend org.eclipse.xtend.core ${xtext-version} org.eclipse.xtext org.eclipse.xtext.ecore ${xtext-version} org.eclipse.xtext org.eclipse.xtext.xbase ${xtext-version} org.eclipse.emf org.eclipse.emf.codegen.ecore.xtext ${ecore-xtext-version} org.eclipse.emf org.eclipse.emf.common ${emf-common-version} org.eclipse.emf org.eclipse.emf.ecore ${emf-version} org.eclipse.emf org.eclipse.emf.ecore.xmi ${emf-version} org.eclipse.emf org.eclipse.emf.codegen ${emf-codegen-version} org.eclipse.emf org.eclipse.emf.codegen.ecore ${emf-codegen-version} org.eclipse.emf org.eclipse.emf.ecore.xcore ${ecore-xcore-version} org.eclipse.emf org.eclipse.emf.ecore.xcore.lib ${ecore-xcore-lib-version} org.eclipse.xtext xtext-maven-plugin ${xtext-version} generate-sources generate org.eclipse.xtext.ecore.EcoreSupport org.eclipse.emf.codegen.ecore.xtext.GenModelSupport org.eclipse.xtend.core.XtendStandaloneSetup ${project.basedir}/xtend-gen org.eclipse.emf.ecore.xcore.XcoreStandaloneSetup ${project.basedir}/xcore-gen ${basedir}/src ${basedir}/emf-gen ${basedir}/model 1.8 org.eclipse.text org.eclipse.text ${eclipse-text-version} org.eclipse.core org.eclipse.core.resources ${core-resources-version} org.eclipse.xtend org.eclipse.xtend.core ${xtext-version} org.eclipse.xtext org.eclipse.xtext.ecore ${xtext-version} org.eclipse.xtext org.eclipse.xtext.xbase ${xtext-version} org.eclipse.emf org.eclipse.emf.codegen.ecore.xtext ${ecore-xtext-version} org.eclipse.emf org.eclipse.emf.common ${emf-common-version} org.eclipse.emf org.eclipse.emf.ecore ${emf-version} org.eclipse.emf org.eclipse.emf.ecore.xmi ${emf-version} org.eclipse.emf org.eclipse.emf.codegen ${emf-codegen-version} org.eclipse.emf org.eclipse.emf.codegen.ecore ${emf-codegen-version} org.eclipse.emf org.eclipse.emf.ecore.xcore ${ecore-xcore-version} org.eclipse.emf org.eclipse.emf.ecore.xcore.lib ${ecore-xcore-lib-version} .gitignore 12345 bin/* target emf-gen/* xcore-gen/* xtend-gen/* [Less]
Posted 5 days ago
Lots of thanks to Christian for figuring this out together. The complete example is available on github. Also, we included all the files as Listings at the end of the article. They are heavily commented. Objective Inside an Eclipse plugin, we have ... [More] EMF models defined in both Xcore and Ecore, using types from each other. Also, we have a Helper Xtend class that’s called from Xcore and uses types from the same model. We want to build the Eclipse Plugin with Maven. We also don’t want to commit any generated sources (from Xtend, Xcore, or Ecore). Issue Usually, we would use xtend-maven-plugin to build the Xtend classes, xtext-maven-plugin to build the Xcore model, and MWE2 to build the Ecore model. However, we have a cyclic compile-time dependency between AllGreetings calling GreetingsHelper.compileAllGreetings() which receives a parameter of type AllGreetings. Solution Java (and Xtend) can solve such cycles in general, but only if they process all members at the same time. Thus, we need to make sure both Xtend and Xcore are generated within the same Maven plugin. We didn’t find a way to include the regular Ecore generator in the same step, so we keep this in a separate MWE2-based Maven plugin. For generating persons.ecore, we call an MWE2 workflow from Maven via exec-maven-plugin. The workflow itself gets a bit more complicated, as we use INamedElement from base.xcore as a supertype to IPerson inside persons.ecore. Thus, we need to ensure that base.xcore is loaded, available, and can be understood by the Ecore generator. Afterwards, we use xtext-maven-plugin to generate both Xtend and the two Xcore models. To do this, we need to include all the required languages and dependencies into one single plugin in our maven pom. Missing Bits The workaround of using MWE2 to build Ecore models has (presumably) the side effect that we cannot refer to Ecore contents within Xtend. The respective parts are commented in GreetingsHelper.compileAllPersons() and drawn grey in the diagram above. Remarks We developed this using Eclipse Mars.2. The example project should be free of errors and warnings, and builds in all of Eclipse, MWE2, and Maven. In Maven, you might see some warnings due to an Xtext bug. It should not have any negative impact. When creating the Ecore file, make sure only to use built-in types (like EString) from http://www.eclipse.org/emf/2002/Ecore. They may be listed several times. In our genmodel file, Eclipse tends to replace this way of referring to platform:/resource/org.eclipse.emf.ecore/model/Ecore.genmodel#//ecore by something like ../../org.eclipse.emf.ecore/model/Ecore.genmodel#//ecore. This would lead to ConcurrentModificationException in xtext-maven-plugin or MWE2, or “The referenced packages ”{0}” and ”{1}” have the same namespace URI and cannot be checked at the same time.” when opening the GenModel editor. In this case, open the genmodel file with a text editor and use the platform:/resource/org.eclipse.emf.ecore/model/Ecore.genmodel#//ecore form in the genmodel:GenModel#usedGenPackages attribute. Sadly, this needs to be fixed every time the Genmodel Editor saves the file. The Xcore builder inside Eclipse automatically picks up the latest EMF complianceLevel, leading to Java generics support in generated code. The maven plugin does not use the latest complianceLevel, thus we need to set it explicitly. The modelDirectory setting in both Xcore and Ecore seem to be highly sensitive to leading or trailing slashes. We found it safest not to have them at all. Using all the involved generators (MWE2, Xcore, Xtend, …) requires quite a few dependencies for our plugin. As a neat trick, we can define them in build.properties rather than MANIFEST.MF. This way, they are available at build time, but do not clog our run-time classpath. As we can see on the right, they are also listed separately in the Eclipse dependency editor. maven-clean-plugin seems to be quite sensitive how its filesets are described. Even when disregarding the .dummy.txt entries in our pom, the *-gen directories were only cleaned if we listed them in separate fileset entries. The workflow should reside within an Eclipse source folder. To separate it from real sources, we created a new source folder named workflow. Listings Project Layout GreetingsHelper.xtend 1234567891011121314151617181920212223242526272829303132 package de.nikostotz.xtendxcoremaven.greetings.helper import de.nikostotz.xtendxcoremaven.greetings.AllGreetings class GreetingsHelper { // This method is called from greetings.xcore and has AllGreetings as parameter type, // thus creating a dependency circle def static String compileAllGreetings(AllGreetings it) { var totalSize = 0 // We access the AllGreetings.getGreetings() method in two different ways // (for-each-loop and map) to demonstrate different error messages if we omit // 'complianceLevel="8.0"' in greetings.xcore for (greeting : it.getGreetings()) { totalSize = totalSize + greeting.getMessage().length } ''' Greetings: «it.getGreetings().map[greeting | greeting.getMessage()].join(", ")» ''' } // This does not work currently with Maven. I didn't figure out why yet, but have some clues: // AllGreetings.getPersons() refers to type IPerson, which is defined in Ecore. // This might not be generated yet when the Xtend generator runs in Maven. // def static String compileAllPersons(AllGreetings it) { // ''' // Hello Humans: // «it.getPersons().map[person | person.describeMyself()].join(", ")» // ''' // } } base.xcore 12345678910111213141516171819 @GenModel( // This sets the target directory where to put the generated classes. // Make sure NOT to start or end with a slash! // Doing so would lead to issues either with Eclipse builder, MWE2 launch, or Maven modelDirectory="de.nikostotz.xtendxcoremaven/xcore-gen", // required to fix an issue with xcore (see https://www.eclipse.org/forums/index.php/t/367588/) operationReflection="false" ) package de.nikostotz.xtendxcoremaven.base // This enables usage of the @GenModel annotation above. The annotation would work without // this line in Eclipse, but Maven would fail. // (WorkflowInterruptedException: Validation problems: GenModel cannot be resolved.) annotation "http://www.eclipse.org/emf/2002/GenModel" as GenModel interface INamedElement { String name } persons persons.ecore 12345678910111213141516 < ?xml version="1.0" encoding="UTF-8"?> xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"    xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="persons" nsURI="de.nikostotz.xtendxcoremaven.persons" nsPrefix="persons">   xsi:type="ecore:EClass" name="IPerson" abstract="true" interface="true"      eSuperTypes="base.xcore#/EPackage/INamedElement">     name="describeMyself" lowerBound="1" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString">>   >   xsi:type="ecore:EClass" name="Human" eSuperTypes="#//IPerson">     xsi:type="ecore:EAttribute" name="knownHumanLanguages" upperBound="-1"        eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString">>   >   xsi:type="ecore:EClass" name="Developer" eSuperTypes="#//IPerson">     xsi:type="ecore:EAttribute" name="knownProgrammingLanguages"        upperBound="-1" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString">>   > > persons.genmodel 123456789101112131415161718192021222324252627282930 < ?xml version="1.0" encoding="UTF-8"?> xmi:version="2.0"     xmlns:xmi="http://www.omg.org/XMI" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"     xmlns:genmodel="http://www.eclipse.org/emf/2002/GenModel"     modelDirectory="de.nikostotz.xtendxcoremaven/emf-gen" modelName="Persons"     importerID="org.eclipse.emf.importer.ecore" complianceLevel="8.0"     copyrightFields="false" importOrganizing="true"     usedGenPackages="base.xcore#/1/base platform:/resource/org.eclipse.emf.ecore/model/Ecore.genmodel#//ecore">         >persons.ecore>     prefix="Persons" basePackage="de.nikostotz.xtendxcoremaven.persons"         disposableProviderFactory="true" ecorePackage="persons.ecore#/">         image="false" ecoreClass="persons.ecore#//IPerson">             ecoreOperation="persons.ecore#//IPerson/describeMyself">>         >         ecoreClass="persons.ecore#//Human">             createChild="false"                 ecoreFeature="ecore:EAttribute persons.ecore#//Human/knownHumanLanguages">>         >         ecoreClass="persons.ecore#//Developer">             createChild="false"                 ecoreFeature="ecore:EAttribute persons.ecore#//Developer/knownProgrammingLanguages">>         >     > > greetings.xcore 123456789101112131415161718192021222324252627282930313233343536 @GenModel( modelDirectory="de.nikostotz.xtendxcoremaven/xcore-gen", operationReflection="false", // This enables Java generics support in EMF (starting with version 6.0). // If omitted, we'd get a "Validation Problem: The method or field message is undefined" in Maven // because AllGreetings.getGreetings() would return an EList instead of an EList, thus // we cannot know about the types of the list elements and whether they have a 'message' property. // In other cases, this leads to error messages like "Cannot cast Object to Greeting". complianceLevel="8.0" ) package de.nikostotz.xtendxcoremaven.greetings // referring to Ecore import de.nikostotz.xtendxcoremaven.persons.persons.IPerson // referring to Xtend import de.nikostotz.xtendxcoremaven.greetings.helper.GreetingsHelper annotation "http://www.eclipse.org/emf/2002/GenModel" as GenModel class AllGreetings { contains IPerson[] persons contains Greeting[] greetings op String compileAllGreetings() { // calling Xtend inside Xcore GreetingsHelper.compileAllGreetings(this) } } class Greeting { String message refers IPerson person } MANIFEST.MF 1234567891011121314151617181920212223 Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: %pluginName Bundle-SymbolicName: de.nikostotz.xtendxcoremaven;singleton:=true Bundle-Version: 1.0.0.qualifier Bundle-ClassPath: . Bundle-Vendor: %providerName Bundle-Localization: plugin Bundle-Activator: de.nikostotz.xtendxcoremaven.XtendXcoreMavenActivator Require-Bundle: org.eclipse.core.runtime, org.eclipse.emf.ecore;visibility:=reexport, org.eclipse.xtext.xbase.lib, org.eclipse.emf.ecore.xcore.lib Bundle-RequiredExecutionEnvironment: JavaSE-1.8 Export-Package: de.nikostotz.xtendxcoremaven.greetings.impl, de.nikostotz.xtendxcoremaven.greetings.util, de.nikostotz.xtendxcoremaven.base, de.nikostotz.xtendxcoremaven.base.impl, de.nikostotz.xtendxcoremaven.base.util, de.nikostotz.xtendxcoremaven.persons.persons, de.nikostotz.xtendxcoremaven.persons.persons.impl, de.nikostotz.xtendxcoremaven.persons.persons.util Bundle-ActivationPolicy: lazy build.properties 1234567891011121314151617181920212223242526 # bin.includes = .,\ model/,\ META-INF/,\ plugin.xml,\ plugin.properties jars.compile.order = . source.. = src/,\ emf-gen/,\ xcore-gen/,\ xtend-gen/ src.excludes = workflow/ output.. = bin/ # These work the same as entries in MANIFEST.MF#Require-Bundle, but only at build time, not run-time additional.bundles = org.eclipse.emf.mwe2.launch,\ org.apache.log4j,\ org.apache.commons.logging,\ org.eclipse.xtext.ecore,\ org.eclipse.emf.codegen.ecore.xtext,\ org.eclipse.emf.ecore.xcore,\ org.eclipse.xtend.core,\ org.eclipse.emf.codegen.ecore,\ org.eclipse.emf.mwe.core,\ org.eclipse.emf.mwe.utils,\ org.eclipse.emf.mwe2.lib generateGenModel.mwe2 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647 module GenerateGenModel var projectName = "de.nikostotz.xtendxcoremaven" var rootPath = ".." Workflow { // This configures the supported model types for EcoreGenerator. // Order is important. // Should be the same list as in Reader below. bean = org.eclipse.emf.ecore.xcore.XcoreStandaloneSetup {} bean = org.eclipse.xtend.core.XtendStandaloneSetup {} bean = org.eclipse.xtext.ecore.EcoreSupport {} bean = org.eclipse.emf.codegen.ecore.xtext.GenModelSupport {} bean = org.eclipse.emf.mwe.utils.StandaloneSetup { // Required for finding the platform contents (Ecore.ecore, Ecore.genmodel, ...) under all circumstances platformUri = "${rootPath}" // Required for finding above mentioned models inside their Eclipse plugins scanClassPath = true } // As persons.ecore refers to a type inside base.xcore (IPerson extends INamedElement), // we need to load base.xcore before we can generate persons.ecore. component = org.eclipse.xtext.mwe.Reader { // This configures the supported model types for this Reader. // Order is important. // Should be the same list as beans above. register = org.eclipse.emf.ecore.xcore.XcoreStandaloneSetup {} register = org.eclipse.xtend.core.XtendStandaloneSetup {} register = org.eclipse.xtext.ecore.EcoreSupport {} register = org.eclipse.emf.codegen.ecore.xtext.GenModelSupport {} // This asks the Reader to read all models it understands from these directories (and sub-directories). path = "model" path = "src" // Put the models inside a ResourceSet that's accessible by the EcoreGenerator. loadFromResourceSet = {} } // Generate persons.ecore (via persons.genmodel). component = org.eclipse.emf.mwe2.ecore.EcoreGenerator { genModel = "platform:/resource/${projectName}/model/persons.genmodel" srcPath = "platform:/resource/${projectName}/emf-gen" } } pom.xml 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405 xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">     >4.0.0>     >de.nikostotz.xtendxcoremaven>     >1.0.0-SNAPSHOT>     >de.nikostotz.xtendxcoremaven>     >         .build.sourceEncoding>UTF-8>                 .compiler.source>1.8>         .compiler.target>1.8>                 -resources-version>3.7.100>         -text-version>3.5.101>         -version>2.12.0>         -common-version>2.12.0>         -codegen-version>2.11.0>         -version>2.10.0>         -xtext-version>1.2.0>         -xcore-version>1.3.1>         -xcore-lib-version>1.1.100>         -mwe2-launch-version>2.8.3>     >     >         >             >org.eclipse.emf>             >org.eclipse.emf.common>             >${emf-common-version}>         >         >             >org.eclipse.emf>             >org.eclipse.emf.ecore>             >${emf-version}>         >         >             >org.eclipse.emf>             >org.eclipse.emf.ecore.xcore.lib>             >${ecore-xcore-lib-version}>         >         >             >org.eclipse.xtext>             >org.eclipse.xtext.xbase.lib>             >${xtext-version}>         >     >     >         >             >                 >org.apache.maven.plugins>                 >maven-compiler-plugin>                 >3.3>             >             >                 >maven-clean-plugin>                 >2.6.1>                 >                     >                         >                             >                                 >.dummy.txt>                             >                             >emf-gen>                         >                         >                             >                                 >.dummy.txt>                             >                             >xtend-gen>                         >                         >                             >                                 >.dummy.txt>                             >                             >xcore-gen>                         >                     >                 >             >                         >                 >org.codehaus.mojo>                 >build-helper-maven-plugin>                 >1.9.1>                 >                     >                         >add-source>                         >generate-sources>                         >                             >add-source>                         >                         >                                                         >                                 />${basedir}/emf-gen                                 />${basedir}/xcore-gen                                 />${basedir}/xtend-gen                             >                         >                     >                 >             >                         >                 >org.codehaus.mojo>                 >exec-maven-plugin>                 >1.4.0>                 >                     >                         >mwe2Launcher>                         >generate-sources>                         >                             >java>                         >                     >                 >                 >                     >org.eclipse.emf.mwe2.launch.runtime.Mwe2Launcher>                     >                         >${project.basedir}/workflow/generateGenModel.mwe2>                         >-p>                         >rootPath=${project.basedir}/..>                     >                     >compile>                     >true>                     >false>                 >                 >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.mwe2.launch>                         >${emf-mwe2-launch-version}>                     >                     >                         >org.eclipse.xtext>                         >org.eclipse.xtext.xtext>                         >${xtext-version}>                     >                     >                         >org.eclipse.text>                         >org.eclipse.text>                         >${eclipse-text-version}>                     >                     >                         >org.eclipse.core>                         >org.eclipse.core.resources>                         >${core-resources-version}>                     >                     >                         >org.eclipse.xtend>                         >org.eclipse.xtend.core>                         >${xtext-version}>                     >                     >                         >org.eclipse.xtext>                         >org.eclipse.xtext.ecore>                         >${xtext-version}>                     >                     >                         >org.eclipse.xtext>                         >org.eclipse.xtext.xbase>                         >${xtext-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.codegen.ecore.xtext>                         >${ecore-xtext-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.common>                         >${emf-common-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.ecore>                         >${emf-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.ecore.xmi>                         >${emf-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.codegen>                         >${emf-codegen-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.codegen.ecore>                         >${emf-codegen-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.ecore.xcore>                         >${ecore-xcore-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.ecore.xcore.lib>                         >${ecore-xcore-lib-version}>                     >                     >                         >org.eclipse.text>                         >org.eclipse.text>                         >${eclipse-text-version}>                     >                     >                         >org.eclipse.core>                         >org.eclipse.core.resources>                         >${core-resources-version}>                     >                     >                         >org.eclipse.xtend>                         >org.eclipse.xtend.core>                         >${xtext-version}>                     >                     >                         >org.eclipse.xtext>                         >org.eclipse.xtext.ecore>                         >${xtext-version}>                     >                     >                         >org.eclipse.xtext>                         >org.eclipse.xtext.xbase>                         >${xtext-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.codegen.ecore.xtext>                         >${ecore-xtext-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.common>                         >${emf-common-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.ecore>                         >${emf-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.ecore.xmi>                         >${emf-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.codegen>                         >${emf-codegen-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.codegen.ecore>                         >${emf-codegen-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.ecore.xcore>                         >${ecore-xcore-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.ecore.xcore.lib>                         >${ecore-xcore-lib-version}>                     >                 >             >                         >                 >org.eclipse.xtext>                 >xtext-maven-plugin>                 >${xtext-version}>                 >                     >                         >generate-sources>                         >                             >generate>                         >                     >                 >                 >                     >                         >                             >org.eclipse.xtext.ecore.EcoreSupport>                         >                         >                             >org.eclipse.emf.codegen.ecore.xtext.GenModelSupport>                         >                         >                             >org.eclipse.xtend.core.XtendStandaloneSetup>                             >                                 >                                     >${project.basedir}/xtend-gen>                                 >                             >                         >                         >                             >org.eclipse.emf.ecore.xcore.XcoreStandaloneSetup>                             >                                 >                                     >${project.basedir}/xcore-gen>                                 >                             >                         >                     >                                         >                         >${basedir}/src>                         >${basedir}/emf-gen>                                                 >${basedir}/model>                     >                                         >1.8>                 >                 >                     >                         >org.eclipse.text>                         >org.eclipse.text>                         >${eclipse-text-version}>                     >                     >                         >org.eclipse.core>                         >org.eclipse.core.resources>                         >${core-resources-version}>                     >                     >                         >org.eclipse.xtend>                         >org.eclipse.xtend.core>                         >${xtext-version}>                     >                     >                         >org.eclipse.xtext>                         >org.eclipse.xtext.ecore>                         >${xtext-version}>                     >                     >                         >org.eclipse.xtext>                         >org.eclipse.xtext.xbase>                         >${xtext-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.codegen.ecore.xtext>                         >${ecore-xtext-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.common>                         >${emf-common-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.ecore>                         >${emf-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.ecore.xmi>                         >${emf-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.codegen>                         >${emf-codegen-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.codegen.ecore>                         >${emf-codegen-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.ecore.xcore>                         >${ecore-xcore-version}>                     >                     >                         >org.eclipse.emf>                         >org.eclipse.emf.ecore.xcore.lib>                         >${ecore-xcore-lib-version}>                     >                 >             >         >     > > .gitignore 12345 bin/* target emf-gen/* xcore-gen/* xtend-gen/* [Less]
Posted 6 days ago
What are the top Eclipse Marketplace plugins? How can you benefit from them? Find out!
Posted 6 days ago
What are the top Eclipse Marketplace plugins? How can you benefit from them? Find out!
Posted 6 days ago
All third party content must be taken through the Eclipse Foundation’s Intellectual Property (IP) Due Diligence Process before being used by an open source project hosted by the Eclipse Foundation. This includes all third party content that is ... [More] incorporated into project code, included in builds, or otherwise required by the project code to provide functionality. The Eclipse Foundation’s Guidelines for the Review of Third Party Dependencies defines various classifications of third party content and how project teams should engage in the IP process. The classification of third party content most commonly used is the so-called prerequisite dependency: a prerequisite dependency is third party content that the project either needs to distribute along with the project code, or otherwise have present in order to function. Third party content is likely a prerequisite dependency if: project code accesses APIs; project code includes an import statement for a package from a library; project code uses reflection or other means to reference a library’s APIs and implementation; the Java/OSGi manifest for a project bundles makes a direct reference; or project code invokes a command line tool to access the functionality. This list is not intended to be exhaustive, but rather to provide common examples. Fundamentally, if project code makes some kind of use of third-party content, then that content is likely a prerequisite. The guidelines provide for so-called works with and exempt prerequisite dependencies, but I’ll save that discussion for a future post. Project committers can engage in the IP Due Diligence process by creating a contribution questionnaire (CQ) in the Eclipse Foundation’s IPZilla system. The term contribution questionnaire is a bit misleading when it comes to third party content. Third party content is not a really a contribution to the project, but since the requirements for tracking project code and third party content is very similar, the same mechanism is used for both. The workflow looks a little something like this: Committer Tools There’s an entry point that project committers can use to Create a Contribution Questionnaire in the Committer Tools block that is on every project’s information page (see the image on the right). In the first step, the committer creates the CQ record with essential information about the third party content and then attaches the source code for that content (this currently happens in two separate steps). The corresponding Project Management Committee (PMC) must sign-off on the CQ before any further processing occurs. As a general rule, a CQ should be created for each separate library. The process permits for some flexibility with regard to the definition of library. Content that has source in a single source repository that is distributed as multiple JAR files can very likely be regarded as a single library. There has also been cases where the IP Team has accepted a single CQ to do license certification for a collection of many different JavaScript sources. If you’re not sure, check with the IP Team. License scanning software will be engaged for third party content that’s to be reviewed for license certification (type A). As we roll out this new type of IP due diligence, the IP Team is engaging the tool manually, evaluating the output, and making a determination. Our plan is to automate the invocation of the tool and make a determination automatically where possible (e.g. in cases where the licenses are clearly indicated in the content) and have the IP Team investigate further when necessary. For requests to perform the more thorough IP due diligence process (type B), the workflow is different. For content that qualifies for parallel IP processing, the IP Team will do a cursory review and—assuming that the content passes muster—grant check in, meaning that the content can be pushed into the project’s source code repository and included in builds. The full due diligence review includes verification of the content’s provenance and a scan for all kinds of other anomalies (more on this in future posts). This process is a lot work that can take quite a lot of time to complete, and very often requires interaction with the committer. When the IP team completes a full review with a successful outcome, they’ll mark the CQ as approved. All third party content must be either license certified or approved before an project can issue an official release. Any release that includes license certified content must be marked as a type A. A type A release may include type B content; A type B release, however, cannot include type A content. I’ve thrown out a few concepts in this post without providing explanations. I’ll try and fill in the gaps in future posts, which will all be grouped in the intellectual property category. [Less]
Posted 6 days ago
It’s been a wild few weeks on the journey I now simply call “Two”. (Until it becomes an Eclipse project, I can’t call it one. And rightly so). The feedback I’ve received, especially as it hit the presses, was fantastic. It’s driven a lot of traffic ... [More] to my github repo. I’ve even received a few pull requests from people cleaning up my mess as I plow through it. At the very least, people are intrigued by idea of an IDE built with Web UI technologies running locally under Electron. As I work through the vision, I don’t think it’s fair to simply call it yet another Eclipse IDE. It’s much grander than that. For me, Two is about that vision. It’s more than a code editor. It’s more than just taking the existing Eclipse IDE and implement it in HTML5 running locally. It’s about a whole new way for developers to work with their tools and access the resources available to them on the web. Developers today have access to many powerful web services. Github is a huge one. At Eclipse we use Bugzilla for bug tracking. A lot of companies use JIRA. People may be using Gitlab as their private Github. You may be using Gerrit for code reviews. I notice LLVM is using Phabricator for code reviews. And there’s the venerable Review Board still active today. Jenkins for continuous integration. And don’t tell me you don’t cut and paste error messages into Google searches to find others who’ve seen the same problem and worked out a solution. The Web is a critical tool in the developers belt. I was intrigued by an article written by the creators of a tool called Ship. It’s a Mac native, i.e. Cocoa, app that integrates with the Github issue tracker. This quote hit me: “A point of pride for us is that many people we have shown Ship 2.0 haven’t been able to tell where the web-based content ends and the native Cocoa stuff begins.” That’s exactly it. If we can say the same for Two, where you can’t tell where the web ends and integration with local tools begin, then we’ve hit a home run. Integrated Development Environments provide the most value when they have integrations between tools, which the developer has had to do manually for years. The IDE’s role is to automate workflows that transgress all the tools the developer has to use, where the workflow becomes the key, not the individual tools themselves. This focus makes it much easier for them to accomplish their objectives, so they don’t have to learn all the intricacies of underlying environments, but provide a unified language. And that’s what Two needs to be, a tools integrator that includes not only the tools the user has installed locally, but also integrates with these super powerful web resources in seamless workflows. The other important factor with IDEs that so many forget, is that experienced developers will always have a bit of mistrust in their IDE no matter how good it is. They need to be able to get close to the iron and run the underlying tools manually at a place where their trust is higher. An IDE that hides that, or makes those tools hard to get to, will struggle being universal. That’s why I’m not a fan of Cloud or Docker hosted tools. In making deployment easy for the provider, they make it hard for the user to touch the bits they’re creating. The main reason I don’t want to call this Eclipse Two is that this isn’t just about a next generation Eclipse IDE. That IDE was my One, the first IDE that I’ve had a hand in creating. I want to rethink the whole developer experience and create an IDE that works well in the modern world, now almost 20 years after One. This is Two. [Less]
Posted 7 days ago
A few months ago we introduced the Eclipse Marketplace Favourites List. To explain how it works I created a video tutorial. This article will be a more classic tutorial to explain what Eclipse Marketplace is and how you can use the Favourite Lists to ... [More] your advantage. What is Eclipse Marketplace? The Eclipse Marketplace is a place to discover, share, and install relevant Eclipse plugins and solutions. Think of it like an app store for Eclipse solutions. One of it’s main uses is to add plugins to your Eclipse installation. You will also find applications based on Eclipse Platform, tooling for IoT and other solutions and services. In this article you’ll find out how to do so – you might even learn a few new tricks along the way. Favourite list online One of the great features of the Eclipse Marketplace is the possibility to create and share a list of plugins. This is very helpful if you have many Eclipse installations, and want to find and install your favourites one quickly. How can you do this on the Eclipse website? How to do this on the website? Go to https://marketplace.eclipse.org/ and sign up. Or create an account if you don’t have one yet. Search for your favourite solution Click on the white star below the logo to add a plugin to your Favourites list. Visual Example In this example, Darkest Dark Theme will be added to my favourites plugins list. Once a plugin has been “starred” it is automatically added to your list. To view it, simply go to “My Marketplace”: And there it is, in your list of favorites! Marketplace Client in Eclipse Manage plugins Did you know? You can install plugins from your Eclipse IDEs using the Marketplace Client. To launch it: Click on the “Help” tab in the menu. Click on “Eclipse Marketplace”. You can also launch it using the Quick Access Bar at the top right of your Eclipse workspace. Click “Alt + 3” (Windows) or “Command + 3” (Mac) to launch the Quick Access search bar Type “Eclipse Marketplace” Hit “Enter” and voila – you’re there! You can display and manage your favorites here too: You can off course add, remove, and install plugins. The Eclipse Marketplace Client and the website store your favorites with your eclipse.org account, so they are synchronised. Copying Another User’s Favourite List If you want to install plugins in the list of someone else, say, a colleague, or another contributor to a project, this is also possible.  You can import a favourites list from an other Community users, and then select the plugin you want. It’s also possible to install plugins from someone else’s list , say, a colleague, or another project contributor. To import a favourites list from an other Community users in your workspace Marketplace client: Click on “Import Favourites List” Copy/paste the link to someone’s favorites lists. All plugins are automatically selected. Unselect any plugins you don’t want by unchecking the checkboxes to the left of each individual plugin. Click import. Here is an example with Lars Vogel‘s plugins. Share Long story short, to save time or to share your favourite plugins quickly and easily with someone else, you can add plugins to your favourites list. Sharing is simple, all you need is the link to your list. You can find this link on your user profile: Here are a few Favourites Lists that I would like to share with you. You can import them directly by copying and pasting the link in Eclipse Marketplace Client: Java – Lars Vogel https://marketplace.eclipse.org/user/lvogel/favorites C / C++ – Doug Schaefer https://marketplace.eclipse.org/user/dschaefer/favorites Modelling (Sirius) – Cédric Brun https://marketplace.eclipse.org/user/cbrun/favorites Do not hesitate to share your favourite list on social networks. You can use #EclipseMarketplace on Twitter. Feedback welcome As usual, feedback is welcome and discussion is open. Do not hesitate to comment this article or to open an bug. [Less]