+1 Max Best Regards, Higor +100 to all and if you'll take a look at the features Red Hat have been adding the later years
to Eclipse, JBoss Tools, vscode and Che the later years then that is all about content assist, ease-of-incremental-deploy and
small smart helpers. This is why I think pausing WTP and redo the interesting parts as LSP's is the way forward. /max
http://about.me/maxandersen On 1 Mar 2018, at 15:37, arjan tijms wrote: Hi, On Thu, Mar 1, 2018 at 2:32 PM, Mrinal Kanti <mrinal.kanti@xxxxxxxxx> wrote: I think a more appropriate question at this point would be to ask which areas would be benefited most from the Java EE tooling support?
IMHO, tooling these days (for Java EE) is primarily needed to support autocompletion, navigate into, call references, etc. For example, when I'm editing a Facelet (using the .xhtml/html/web editor) and enter a search _expression_, I'd like the editor to autocomplete it, and provide documentation. In JSF 2.3 we added a bunch of default keywords: Keyword | Description | @child(n) | The nth child of the base component | @composite | The closest composite component ancestor of the base component | @id(id) | All component descendants of the base component with the specified component id | @namingcontainer | The closest NamingContainer ancestor of the base component | @next | The next component in the view after the base component | @parent | The parent of the base component | @previous | The previous component to the base component | @root | The UIViewRoot |
These keywords are currently not being recognised by the Eclipse editor. In 2.3 we also added the option to define custom keywords. This may be more difficult to support by an IDE (as they can be added programmatically), but it would be really handy if these can be supported as well. Furthermore, in JSF 2.3 I added a number of annotations to inject various JSF artifacts. (see http://arjan-tijms.omnifaces.org/p/jsf-23.html#1316), these are currently not recognised by Eclipse. Since these are part of JSF, Eclipse could have build-in knowledge of these. There's also one new implicit object in JSF 2.3; #{externalContext}, but this is only there if the @FacesConfig annotation is used and set to 2.3. The IDE could relatively easy pick that up, but today it doesn't. Hence, when you type #{externalContext} on a Facelet it won't autocomplete anything as it doesn't know the object. There's a bunch more like this, but hopefully this gives same insight. It's definitely NOT about dragging visual components, those days are indeed long gone, but about support when coding textually. Looking at https://www.eclipse.org/webtools/, I can think of a few areas and how the landscape has evolved over the last decade for some of them: Server Tools: These were primarily app server connectors which were responsible to call the appropriate startup/shutdown/restart or deploy hooks of their respective app servers from within the IDE. There is little room for improvement in that area so long as the tools are kept updated with the latest app server versions. Server Profiling: This is a very grey area. Eclipse used to have TPTP which was retired long back. However, IBM continued to provide a very similar functionality in their WAS profiling. Oracle have their own proprietary AppXRay and I think even JBoss had(?) its own profiler project based on JVMPI and JVMTI. Besides, the profiling landscape has changed a lot to catch up with the demands of the industry. The need has shifted from server profiling to application profiling as enterprises are finding themselves in heterogeneous environments. They are looking for specialized context aware profiling tools (such as APM tools for end-to-end transaction profiling) which are provided by third party vendors. The application profiling tools market is pretty competitive here and with the need to support profiling for cloud based deployments or in heterogeneous environments, I don’t think any vendor would be willing to wait for Eclipse tools to catch up and provide a base for them. Also with the evolution of Restful APIs and the cloud based service models many of the profiling capabilities are built into the API management tools themselves which require them for monitoring SLAs. Web UI tooling: There was a time when companies like Exadel, Genuitec(MyEclipse IDE), Instantiations(GWT designer) had a thriving market for the UI tools they provided on top of Eclipse. Those days are long past. The tooling support was needed because the UI components were being generated on the server for most of the web frameworks available during that time. And server-side programmers did not have the necessary skills or time to create attractive UI. Today, in order to facilitate lean multi-channel architectures, enterprises require building channel specific UI on top of their RESTful services. Today we speak of rich-clients which are not just browser based but have to cater to mobile platforms as well. The current crop of UI libraries and frameworks do not require much IDE support to build rich UI on top of REST APIs. (Btw, if we are speaking about supporting the current crop of UI frameworks and libraries then it is worth mentioning that Jetbrains has a solid presence and a clear lead there which leaves little room for Eclipse to establish itself). Even on the server-side, thanks to annotation based approaches, we no longer require scaffolding code to publish or consume REST services, so not much need for IDE support there as well. Database tooling: JPA is widely used for relational databases and its support for NoSQL data is still not mature enough. So unless the specifications become mature and stable on that front, there is little to benefit from tooling, as the JPA implementations continue to provide their own approaches for NoSQL access. On the relational front, I think the current tooling capabilities are sufficient. DevOps and the Invasion of scripting environments: I remember those nostalgic days when WebLogic used to provide WLST. It made life simple for automating so many configuration management and deployment tasks. Today, DevOps have evolved into a discipline of its own and even developers are relying on console based tools for automating some their development tasks. The scripting extensions are far more easier to build and customize than building a set of Eclipse plugins to perform the same tasks. Summarily, we need to re-evaluate where the webtools projects are headed and how relevant are those tools in the current enterprise web-development landscape. My 2 cents. -Mrinal On Wed, Feb 28, 2018 at 7:22 PM, reza_rahman <reza_rahman@xxxxxxxxx> wrote: We can definitely try to do that, identifying it as a clear gap area. One issue of course is that the current Java EE Guardians community at least is very NetBeans heavy. The same may or may not be true of the current broader Java EE community as well. If it's not too stupid a question - besides IBM, who would the other potential vendors be to stand behind Eclipse IDE Java EE support? Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone -------- Original message -------- Date: 2/28/18 5:15 AM (GMT-05:00) Subject: Re: [ee4j-community] Eclipse is still behind the current state of Java EE 8 I agree but unfortunately many non-Red Hat Eclipse IDE contributors have dropped away. The community needs to step up and help or convince other vendors to come back. While I myself am an avid NetBeans user, I do agree excellent support in the Eclipse IDE is extremely important for the success of Jakarata EE for the reasons stated. Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone -------- Original message -------- Date: 2/27/18 5:29 AM (GMT-05:00) Subject: Re: [ee4j-community] Eclipse is still behind the current state of Java EE 8 thank your for your reply. Well, in my project we use IntelliJ as the IDE for the consulters. Our client is using the Eclipse IDE though, since they are from the public sector and cannot buy the expensive license. NetBeans was not an option, because of several problems we were having integrating our server. However, the problem is that the Eclipse IDE is being used in the market by far more then 70% of the Java EE developers. This is a statistic that was automatically collected last year by the Consulter-Agency GULP here in Germany. And now that Java EE 8 is under the hood of the Eclipse Foundation, it would be beneficial to have a good support of Java EE 8 in the Eclipse IDE. Gesendet: Dienstag, 27. Februar 2018 um 03:45 Uhr
Von: "Ryan Cuprak" <rcuprak@xxxxxxxxx>
An: "EE4J community discussions" <ee4j-community@xxxxxxxxxxx>
Betreff: Re: [ee4j-community] Eclipse is still behind the current state of Java EE 8 Hi Alexander, Both Intellij (Ultimate) and NetBeans have excellent support for Java EE. Eclipse is definitely way behind, its support for _javascript_ is absolutely abysmal as well. This has been the case fo many years now. I would raise this issue with the Eclipse IDE and in the meantime recommend checking out either NetBeans or IntelliJ Ultimate. When I give Java EE training classes at work I always use NetBeans as it is free and includes GlassFish (integrated). Note, Oracle donated NetBeans to Apache, that donation looks to be going pretty well. Excluding Eclipse, the state of Java EE tooling is pretty good. the current version of "Java EE for Developers" (with Eclipse Oxygen) is still far behind the current state of Java EE 8.
This not only concerns the GlassFish tools, but also WTP. Almost all technologies aren't referred updated. E.g. When using JSF, still the deprecated "managed bean package" way is offered. When using project facets, alsmost all the technologies are been offered in older versions. We need to be vigorously and decidedly updating here, because not only does this endanger the Eclipse IDE, but also the Java EE 8 standard, since Eclipse is the most widely used IDE for Java EE. _______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
_______________________________________________ ee4j-community mailing list ee4j-community@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/ee4j-community _______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community |
