Very High Activity
I Use This!
Project Vulnerability Report

News

Analyzed 15 days ago. based on code collected 15 days ago.
Posted 3 days ago by nore...@blogger.com (Scott Lewis)
In a previous post, I described how ECF Remote Services provided a way to create, implement, test, deploy and upgrade transport-independent remote services.Note that 'transport-independent' does not mean 'transparent'.For example, with network ... [More] services it's always going to relatively likely that a remote service (whether an OSGi Remote Service or any other kind of service) could fail at runtime.   The truth of this is encapsulated in the first fallacy of distributed computing:  The network is reliable.A 'transparent' remote services distribution system would attempt to hide this fact from the service designer and implementer.   Alternatively, the ECF Remote Services approach allows one to choose a distribution provider(s) to meet the reliability and availability requirements for that remote service, and/or potentially change that selection in the future if requirements change.  Also, the dynamics of OSGi services (inherited by Remote Services), allows network failure to be mapped by the distribution system to dynamic service departure.   For example, using Declarative Services, responding at the application level to a network failure can be as simple as implementing a method:void unbindStudentService(StudentService service) throws Exception { // Make service unavailable to application this.studentService = null; // Also could respond by using/binding to a backup service, removing // service from UI, etc}This is only possible if The distribution system detects the failureThe distribution system maps the detected failure to a service unregistration of the proxyIf those two things happen, then using DS the proxy unregistration will result in the unbind method above being called by DS. But the two requirements on the distribution system above may not be satisfied by all distribution providers. For example, for a typical REST/http-based service, there may be no way for the distribution system to detect network failure, and so no unbinding of the service can/will occur. The use of transport-independent remote services, along with the ability to choose/use/create custom distribution providers as appropriate allows micro service developers to easily deal with the realities of distributed computing, as well as changing service requirements. [Less]
Posted 3 days ago
With Mars.2, we released EMF Forms 1.8.0. EMF Forms makes it really simple to create forms that edit your data based on an EMF model. To get started with EMF Forms please refer to our tutorial. In this post, we wish to outline an important ... [More] enhancement for rendering group elements in forms, which allows you to create form-based UIs even more efficiently. The core of EMF Forms is the so-called view model, which essentially describes how a custom form-based UI should look. “Group” is one of the most frequently used layout elements in EMF Forms. This allows you to contain any view element, such as controls or other containers, and therefore, enables you to structure a form. The element group is very flexible, it does not directly imply a certain way of being rendered. The standard EMF Forms renderer will render a group as an SWT group: However it is pretty common to provide custom renderers. This allows you to change the way groups are visualized in your custom product. The benefit is that you do not have to adapt your view models in any way, you just need to provide another renderer. As an example, groups can also be rendered as a Nebula PGroup and therefore make it collapsible: From various customer projects, we have learned that making a group collapsible is a fairly common need. To free adopters from the need to always implement a custom renderer, we have added this as an option the view model itself. Therefore for every group you can specifically configure its collapsibility. If you open a group within your view model, you can change the “Group Type” to “Collapsible”. Additionally, you can then set the initial collapsed state. The EMF Forms default renderer will then render it like this, using an SWT ExpandBar: Another common issue with groups was that they are independent elements, which are also rendered independently. As this makes sense from a conceptional point of view, it sometimes produced unexpected results when it come to layouting. The following screenshot shows two groups below each other. As you can see, the layout is calculated independently for both groups, therefore, the controls are not aligned. As this behavior is fine in some use cases, some users would expect the alignment. In this case, the renderer of the group would have to embed itself into a parent GridLayout, which is calculated and rendered for both groups together. This is now also supported by the EMF Forms default renderer. If you configure the “Group Type” to “Embedded”, the renderer will not create independent Grids for every group, but rather embed them, producing a more homogenous layout: Of course there are many more possible adaptations available for group and other elements. To keep the view model language simple, we try to only add options, which are commonly used across projects. However, by enhancing the existing renderers, all types of customizations are possible. If you miss any feature or ways to adapt it, please provide feedback by submitting bugs or feature requests or contact us if you are interested in enhancements or support. Leave a Comment. Tagged with eclipse, emf, emfcp, emfforms, eclipse, emf, emfcp, emfforms [Less]
Posted 4 days ago
Everyone loves to customize stuff. In Orion 11.0, we provided support for .tern-project files so you can do just that. A .tern-project file, for those unfamiliar with them, is a configuration file that lives at the root of your project, is entirely ... [More] JSON, and tells Tern how and what to run with. Lets see an example file (the one used in the Orion client): { "plugins": { "node": {}, "requirejs": {}, "express": {} }, "ecmaVersion": 5, "libs": [ "ecma5", "browser", "chai" ] } See? It’s not so bad. Now lets talk about what all the parts mean, and why you would want to make one. The first thing typically asked when talking about these files and configuring your project is: “what if I don’t have a .tern-project file?”. The short answer is; we start Tern with a default configuration that contains every plugin we pre-package in Orion. The longer answer is: you get all of the required core services plugins from Orion (like HTML support, parsing plugins, etc) you get all of the pre-packaged plugins (mongodb, redis, mysql, express, amqp, postgres, node, requirejs and angular) you get a default ECMA parse level of 6 you get a default set of definitions (ecma5, ecma6, browser and chai) Basically, everything will work right out of the box, the downside is that you get a lot more stuff loaded in Tern than you might need (or want). ecmaVersion This is the most common element that people create a .tern-project file for, and its an easy one. If you are coding against ECMA 6, the defaults are fine. If you are not, its best to change this to be 5. libs This entry describes type libraries you want Tern to use. These libraries provide type information that is used for content assist and inferencing. At the moment, only the definitions that come pre-packaged in Orion can be entered in this list, which include  ecma5, ecma6, browser and chai. I know what you are thinking. What if I have a definition not in the list I would like to use? We are working on support for custom definition files directly in the project, and providing a UI to install new ones. plugins This entry describes all of the plugins that you want Tern to run with. As mentioned, by default you get everything. Leave it out? You get everything. Empty plugins entry? You get everything. Regardless of what you put in the plugins entry, you will always get the core services plugins that Orion needs to function – so no, you cannot break the tools. While everything will work fine right out of the box with all plugins running – you can really improve the performance and memory usage of the tools if you tell us what support you actually need. For example, working on a node.js project? only include the node plugin. Working on AMD browser project? only include the requirejs plugin. You get the idea – only load what you actually need. At the moment, the list of plugins that can be enabled is amqp, angular, express, mongodb, mysql, node, postgres, redis, requirejs. And yes, we are working on ways to provide your own. loadEagerly This entry is a list of files that are so important, that you just have to have Tern load them when it starts up. All joking aside, this entry is best for pointing Tern at the ‘main’ in your project. For example, say you were working on a web page. You could add index.html in the loadEagerly entry to have Tern automatically load that file and all the dependent scripts right away, so everything was primed and ready to go immediately (as opposed to Tern filling in its type information as you open and close files). dependencyBudget Don’t change this entry. Set too low, it will cause dependency resolution to time out (incomplete type information). Set too high, the IDE will wait longer before answering whatever you asked it (content assist, open decl, etc). So thats it. Those are all of the supported entries that can appear in the .tern-project file. A pretty short list. You can’t break the tools by setting a bad entry – we have sanity checking that will revert to a “something is wrong, load the defaults” state. We also have linting / sanity checking that will alert you if you have broken something in the file. Tern project file linting Broke the file and still navigated to another file (or maybe brought in a change from git that broke the file)? We will alert you that its bad in the banner, with a handy link to jump to the file and fix it! Tern project file banner message Remember, you can ignore all the warnings (if you really want to) and Tern will still start with the defaults as a safety measure. Feeling a bit lazy and don’t want to type out a brand new file for your project? Just open up the new (empty) .tern-project and hit Ctrl+Space, which will auto-magically insert a shiny new template for you. Happy configuring! [Less]
Posted 4 days ago
I thought I’d heard all the arguments for why developers choose IntelliJ IDEA over Eclipse IDE, but this was a new one. I was at a meet-up with lots of Java developers, and inevitably the conversation went to the topic of preferred Java IDE. One ... [More] developer raised the point ‘I never understand the different versions of Eclipse, you know, Luna, Mars, Neon – what does what, which is the Java one I should download? With IntelliJ it’s just IntelliJ community or ultimate,I know what to get.’ I had to stop myself from launching into a let-me-explain-it’s-simple-and-alphabetic explanation and instead just listen and look around to see others were nodding along in agreement with the speaker. Not long after that I was reading this article: Kill extra brand names to make your open source project more powerful by Chris Grams. In the article, Grams talks about the ‘mental brand tax‘  incurred when projects have additional brand names users are expected to understand. This was the name for what the developers were expressing. As Grams explains “…having a bunch of different brand names can be exclusionary to those who do not have the time to figure out what they all are and what they all do.” This sounded like those developers who are busy solving their problems and keeping pace with the fast developments in software. From my corporate days, engineering often had a working project name. For example, there were the projects named after US state names: ‘New Jersey’, ‘California’, etc. However, when it came to release, these internal names were always scrubbed out by the product marketing department and never referred to from the user perspective. In those cases it was easy to see how the project names could cause real confusion out in the world. In Eclipse, the names are part of the development flow. It’s a nice way for the community to get together to choose them and it is a common language for us as Eclipse developers to use. Often we don’t differentiate between developer-users and developer-extenders. We expect all users to know they are alphabetic and follow a similar theme. But if you think about it isn’t that just another level of abstraction put onto Eclipse versioning? Should these names really be going out to the Eclipse users? Should we expect our users to know Neon is the same as Eclipse 4.6 which is the same as the version that was released in 2016? Ditto for all previous versions? (And that is before we get into the different flavours of the IDE e.g. Java, C/C++, etc). So what could we use instead? I don’t have all the answers, but want to kick off the conversation with a proposal. As Grams summarizes “Sometimes the most powerful naming strategy is an un-naming strategy”. What if we did that? The Eclipse simultaneous release is reliably once a year. How about we use the year it comes out to version it. So this year, Neon would be Eclipse IDE 2016, Oxygen becomes Eclipse IDE 2017 and so on. The added benefit to users is that it becomes immediately obvious how old previous versions are. So instead of ‘Are you going to fix my bug in Luna?‘ someone might ask ‘Are you going to fix my bug in Eclipse.2014?‘ It might be more straightforward for them to see they are already 2-3 years behind the latest release. As we, as a community, move towards thinking and treating Eclipse more as a product, this is a change that could be well worth the effort. As Grams notes: “Just because you have a weak confederation of unsupported brands today doesn’t mean you can’t change. Try killing some brand names, replacing them with descriptors, and channel that power back into your core brand.” [Less]
Posted 4 days ago
EclipseCon France is only a couple of weeks away. I’m looking forward to this great conference with a carefully selected program in a beautiful city . And, I’m definitely looking forward to presenting three topics! On Tuesday the conference starts ... [More] with the tutorials and we start with our tutorial on AngularJS – What every Java developer should know about AngularJS. This tutorial specifically addresses Java/Eclipse developers with no previous experience developing web frontends and provides a good hands-on introduction into AngularJS. So, be sure to sign up and bring your own laptop! If you would like to spice up your day with some more web development, we can also recommend the CHE tutorial –  Extending Eclipse Che to build custom cloud IDEs – about how to extend the new web-based IDE at Eclipse. Getting back to  AngularJS, we will also present an ignite talk on JSONForms. This component ships with EMF Forms and allows you to render an EMF-Forms-based form in an AngularJS-based application. With JSONForms, you can leverage the mature tooling of EMF Forms for modeling forms while developing state-of-the-art single-page web applications based on HTML5, CSS, JavaScript/Typescript and JSON/JSON Schema. If you do not know what EMF Forms is, you could also drop by my talk, “EMF, myself and UI” on how to build UIs for EMF-based data. While preparing the presentation, I was amazed by all features that have been added since I presented it at EclipseCon France last year. Just to pick  three important features: 1. We have added AngularJS-based rendering as mention earlier. 2. We have made it really simple to use the Treeviewer and Tableviewer components standalone. 3. And finally, we even built a brand-new Ecore Editor with improved usability based on EMF-Forms.   In the talk we will also give you a sneak preview of unpublished features in the pipeline, so don’t miss it! Apart from the technical content, any EclipseCon is a good opportunity to meet the people behind the technology, to get in contact and maybe solve one or two technical problems on the spot. We are looking forward to meeting you at EclipseCon France. Do not forget to register quickly as there is a discount if you register by May 10th. See you soon in Toulouse! Leave a Comment. Tagged with AngularJS, eclipse, eclipsecon, emf, emf forms, JSON, JSONForms, modeling, AngularJS, eclipse, eclipsecon, emf, emf forms, JSON, JSONForms, modeling [Less]
Posted 4 days ago
EclipseCon France is only a couple of weeks away. I’m looking forward to this great conference with a carefully selected program in a beautiful city . And, I’m definitely looking forward to presenting three topics! On Tuesday the conference starts ... [More] with the tutorials and we start with our tutorial on AngularJS – What every Java developer should know about AngularJS. This tutorial specifically addresses Java/Eclipse developers with no previous experience developing web frontends and provides a good hands-on introduction into AngularJS. So, be sure to sign up and bring your own laptop! If you would like to spice up your day with some more web development, we can also recommend the CHE tutorial –  Extending Eclipse Che to build custom cloud IDEs – about how to extend the new web-based IDE at Eclipse. Getting back to  AngularJS, we will also present an ignite talk on JSONForms. This component ships with EMF Forms and allows you to render an EMF-Forms-based form in an AngularJS-based application. With JSONForms, you can leverage the mature tooling of EMF Forms for modeling forms while developing state-of-the-art single-page web applications based on HTML5, CSS, JavaScript/Typescript and JSON/JSON Schema. If you are new to EMF Forms, you could also drop by my talk, “EMF, myself and UI” on building UIs for EMF-based data. While preparing the presentation, I was amazed by all features that have been added since I presented it at EclipseCon France last year. Here are just three of the important features: 1. We have added AngularJS-based rendering as mentioned earlier. 2. We have made it really simple to use the Treeviewer and Tableviewer components standalone. 3. And finally, we built a brand-new Ecore Editor with improved usability based on EMF-Forms.   In the talk we will also give you a sneak preview of unpublished features in the pipeline, so don’t miss it! Apart from the technical content, any EclipseCon is a good opportunity to meet the people behind the technology, to get in contact and maybe solve one or two technical problems on the spot. We are looking forward to meeting you at EclipseCon France. Do not forget to register quickly as there is a discount if you register by May 10th. See you soon in Toulouse! Leave a Comment. Tagged with AngularJS, eclipse, eclipsecon, emf, emf forms, JSON, JSONForms, modeling, AngularJS, eclipse, eclipsecon, emf, emf forms, JSON, JSONForms, modeling [Less]
Posted 5 days ago
Today at the Samsung Developers Conference, Codenvy announced the first public release of the Samsung Artik IDE which allows building applications for the Samsung Artik IoT devices. By Alex Blewitt
Posted 6 days ago
Wayne Beaton overviews the current state of Eclipse, discussing how to improve the user experience, support channels, and how to tap into the funding available to work on Eclipse IDE improvements. By Wayne Beaton
Posted 6 days ago
MyEclipse supports a large number of features, ranging from Java EE support of specifications like JPA and JAX-RS, to modern web capabilities like Angular JS and CSS 3. Given the breadth of the IDE, it can be easy to miss key timesaving features that ... [More] have been added to MyEclipse over the years. There are too […] The post Boost Productivity with MyEclipse—Project Setup appeared first on Genuitec. [Less]
Posted 6 days ago by ste...@winklerweb.net (Stefan Winkler)
I am currently working for a customer on an existing Eclipse RCP (based on Luna) which consists of 99% Eclipse 3.x API. The customer wants to migrate to E4 gradually, but there is no budget to migrate existing code all at once. Instead, the plan is ... [More] to start using e4 with new features and migrate the other code step by step. So, when I was given the task of creating a new view, I wanted to use the "new" (in Luna, anyways) e4view element for the org.eclipse.ui.views extension point. The good thing about this is that you can easily write JUnit tests for the new class because it is a POJO and does not have many dependencies.  My problem is that part of the customer's RCP uses Xtext and several components or "services" (not actual services in an OSGi sense) are available via Guice. So I was confronted with the requirement to get a dependency available via Guice injected in an E4-style view implementation: public class MyViewPart { @Inject // <- should be injected via Guice ISomeCustomComponent component; @PostConstruct // <- should be called and injected via E4 DI public void createView(Composite parent) { // ... } }   The usual way to get classes contributed via extension point injected by Guice is to use an implementation of AbstractGuiceAwareExecutableExtensionFactory like this: <plugin> <extension point="org.eclipse.ui.views"> <e4view class="my.app.MyExecutableExtensionFactory:my.app.MyViewPart" id="my.app.view" name="my view" restorable="true"> </e4view> </extension> </plugin> The colon in the class attribute is usually interpreted by the framework in a way that the class identified before the colon is instantiated as an IExecutableExtensionFactory and the actual object is identified by the parameter (given after the colon) and created by that factory. But I did not expect this to work, because I thought it would bypass the E4 class creation mechanism; and actually, it seems to be the other way round and the e4view.class element seems to ignore the extension factory create the my.app.MyViewPart to inject it with E4DI. The MyExecutableExtensionFactory is never getting called. As I said, I didn't expect both DI frameworks to coexist without conflict, so I thought the solution to my problem would be to put those objects which I need injected into the E4 context. After googling a bit, I have found multiple approaches, and I didn't know which one is the "correct" or "nice" one. Among the approaches I have found, there were: providing context functions which delegate to the guice injector retrieving the objects from Guice and configure them as injector bindings retrieving the objects from Guice, obtain a context and put them in the context (The first two approaches are mentioned in the "Configure Bindings" section of https://wiki.eclipse.org/Eclipse4/RCP/Dependency_Injection) I ended up trying all three, but could only get the third alternative to work. This is what I tried: Context Functions I tried to register the context functions as services in the Bundle Activator with this utility method: private void registerGuiceDelegatingInjection(final BundleContext context, final Class<?> clazz){ IContextFunction func = new ContextFunction() { @Override public Object compute(final IEclipseContext context, final String contextKey) { return guiceInjector.getInstance(clazz); } }; ServiceRegistration<IContextFunction> registration = context.registerService(IContextFunction.class, func, new Hashtable<>(Collections.singletonMap( IContextFunction.SERVICE_CONTEXT_KEY, clazz.getName() )));} and called registerGuiceDelegatingInjection() in the BundleActivator's start() method for each class I needed to be retrieved via Guice. For some reason, however, this did not work. The service itself was registered as expected (I checked via the OSGi console) but the context function was never called. Instead I got injection errors that the objects could not be found during injection. Injector Bindings I quickly found out that this solution does not work for me, because you can only specify an interface-class to implementation-class mapping in the form InjectorFactory.getDefault().addBinding(IMyComponent.class).implementedBy(MyComponent.class) You obviously cannot configure instances or factories this way, so this is not an option, because I need to delegate to Guice and get Guice-injected instances of the target classes... Putting the objects in the context Finally, the solution that worked for me was getting the IEclipseContext and put the required classes there myself during the bundle activator's start() method. private void registerGuiceDelegatingInjection(final BundleContext context, final Class<?> clazz){  IServiceLocator s = PlatformUI.getWorkbench();  IEclipseContext ctx = (IEclipseContext) s.getService(IEclipseContext.class);  ctx.set(clazz.getName(), guiceInjector.getInstance(clazz));} This works at least for now. I am not sure how it works out in the future if more bundles would directly put instances in the context; maybe in the long-term named instances would be needed. Also, for me this works, because the injected objects are singletons, so it does not do any harm to put single instances in the context. I would have liked the context function approach better, but I could not get it to work so far. Maybe one of you, the readers, can see my mistake. If so, please feel free to comment or to add an answer to my initial StackOverflow question. [Less]