WebLogic Workshop 8.1 (WLW) now offers an extensibility model for developers, ISVs and language vendors to integrate their services directly into WLW. Given that Workshop is now fully extensible, this sets it up as a complete competitor to Eclipse, although WLW is still aimed at building apps within the WebLogic Platform.
Check out WebLogic 8.1 Extensibility portal
and press release
this sets it up as a complete competitor to Eclipse
Perhaps for WL shops, but if you are already using an OS dev stack (i.e. Eclipse+JBoss or Jonas) what is the benefit? Almost all the Java IDEs allow plugins now, but I really believe it's hard to stop a moving train at this stage of the game.
Perhaps for WL shops, but if you are already using an OS dev stack (i.e. Eclipse+JBoss or Jonas) what is the benefit?
Somehow, I don't think their number one target is the shop running JBoss and/or Jonas. BEA is a products company; they will generally target customers that can and will pay for software licenses, or ISVs that will get others to pay for them. Just my guess.
: Clustered JCache for Grid Computing!
Maybe.. there is two kind tools near future.
One is Commercial product + free/non+free plugins
the other is Open IDE Framework(like Eclipse) + free/non-free Plugins
Who is real competative tools against Eclipse platform.
In my opinioin, that is
Agile Tools - IDEA Intellij 4.0
Web IDE - Exadel's Struts Studio
OR Frameworks - JDO Implementation IDE
By FrameworksLab, Inc.
I have recently attended BEA class on Workshop (called Workshop on Workshop).
It's not just an IDE. It's a tool that provides a unified development environment to all BEA products. For example, you can develop BPM, map it directly to you business logic (EJBs or Java code), drag and drop integration with enterprise resources (adaptors), do all kinds of data transformation, expose or consume Web services, design portals (with Portlets), or just develop JSP's or page flow based on STRUTS 1.1
Every kind of development can be either visual graphical drag-and-drop type, or plain code, and their editor is completely reverseable and bi-directional.
My take away from it: they have a very interesting concept of "server-side controls", which unlike VB-type controls encapsulate server-side resource. Anythink in Workshop can be a control, like EJB, Database, JMS, and custom or packaged applications, Web service, or the entire BPM. These controls represent "best practices" for working with these resources, and are easy to use, re-use, distribute, and hide the complexity that otherwise would have to be dealt with.
I liked the thing. You can develop end-to-end app really fast, that would include everything from portal through BPM and integration down to Java code.
Another good thing - unlike what we are used to in J2EE, with Workshop you just press a button and your app gets immediately deployed and runs on the server, with the test harness automatically generated to test input or trace SOAP.
I found it cool. If you can't find this class, BEA has an evaluation guide that you can download from their site - a complete copy of everything we had done.
I attended essentially the same class on friday, and i agree with you a lot of the way.
I just think that the editor itself is nowhere near IDEA or eclipse, and if you want to do more than make a demo workflow/web service/whatever application, you really need a strong editor (my own productivity has risen dramatically since switching to eclipse).
The perfect solution would be if BEA focused on the integration parts, and built it as plugins to Eclipse. This, however, will probably not happend.
It seems stupid to bring a new IDE to market now, instead of leveraging existing products.
I appreciate the positive comments as well as the negative. With Workshop we're building (as somone noted), something hasn't been built before... it's more than a traditional IDE (it has, e.g., controls, visual portlet and portal creation, BPM editor/designer, etc.) but also is, we think, a solid IDE with great debugging, good source editing capabilities, etc. However because we are covering so much ground, we are constantly faced with how we prioritize this or that feature. So the feedback is welcome.
I will make one strategy note. Workshop is designed to expand the Java community beyond its current reach. We are on a mission to make Java and J2EE the platform of choice for developers building net applications (which are not just web pages, but web services, orchestrated business processes, WSRP and JSR 168 portlets, etc.) So when we are designing Workshop, we often ask ourselves: what features will it take to win a developer using X or Y non-Java technology over to our platform? Controls are a great example, as are our visual designers. Sometimes this does mean that we have to make tradeoffs that we (and Java developers) might regret (refactoring is a painful hole in 8.1, for example) but on the whole we're hearing that we struck a good balance between serving the today's Java developers while at the same time providing an environment that other non-Java developers want to switch to.
On the Eclipse and extensibility questions, Sam has covered the SWT issue well (standards are absolutely critical to BEA), and I'd also add that we just plain think our approach provides a better experience for developers and for extension writers. Yes, the community is absolutely key and the traction Eclipse is getting is great for the Java camp in general. But you'll be seeing a ton more from BEA on this front over the next few months.
Finally, I'd like to point out that WebLogic dev seats (including Workshop, WLS and the whole platform) are available free from BEA. Yes, we're in this to make money when people deploy their apps on WebLogic (we have stockholders to make sure of that), but part of winning over more developers to Java/J2EE is making it as easy as possible for them to switch, and BEA understands that development seats need to be free to developers.
Byron Sebastian, BEA WebLogic Workshop team.
We've been working with Workshop 8.1 and the platform for a couple of months now, on some actual projects.
While some things are sorely lacking (like various refactoring features, as Byron mentioned), I'd hate to go back to something else for Web development.
Some of the elements from the platform, like XMLBeans, EJBgen and Javelin are already available as either free or open source components, so it's not a total BEA lock-in scenario to create apps with Workshop. It'd be nice to get the PageFlow framework released as a free/open sourced component as well - it is much more convenient to work with than straight Struts.
We've been integrating Sed scripts, and some XSLT scripts with Workshop until it gets support for refactoring, Javabeans generation, etc. Plus, it's very good in allowing external tools to work with files within your project - it picks up externally modified files right away, and compiles/builds them automatically if needed.
I was just reading the marketing material on your site and was a bit confused by the following:
<QUOTE> Although the Workshop IDE continues to be focused on developers interested in leveraging the Workshop framework, and not for J2EE development in general (where we recommend Borland JBuilder, WebLogic Edition), many of the basic editing, debugging, and management features of leading IDEs are important to all developers, and we've made great strides in increasing the sophistication of the Workshop IDE itself </QUOTE>
This statement seems incongruous with the idea of a general purpose IDE framework upon which plug-ins provide specific functionality, which, if I am not mistaking, is what you were describing. Can you clarify the direction that you see the tool taking.
It all depends upon the level of knowledge a developer has on the technology on which he works. Workshop is not a tool for senior J2EE Developer. As a leading company in Java technology BEA is not supposed to bring the "Easy and Hide" approach into software business. BEA has to understand that one simple factor that portability and open approach of Java technology played a great role in early days of JAVA developments. I understand there are millions of idiots want to see their web application deployed into a server by one click, for them workshop is a good tool, especially dump ass managers of some corporate America. As far as a real JAVA developer is concerned WORKSHOP is waste of time and money. By the way, buddy, if your one click deployment failed, where do u call for support!!!?.
TQ, I think you are missing the point. BEA is dedicated to the Java and J2EE community. While we continue to innovate, we are also continually folding our innovations back into the Java/J2EE communities through the JCP process (and other standards organizations).
With Workshop, BEA is trying to make it easier for "non-J2EE experts" (though not necessarily managers) to be able to productive and still deploy on a J2EE platform. Microsoft is going after this same market so we feel that the Java community must continue to look for ways of making Java/J2EE easier and more accessible to non-experts.
The first step is to integrate the development environment and paradigms for J2EE applications, web services, portals, and integration. Workshop 8.1 goes a long way down this path but, as Byron points out, some prioritizations had to be made to be able to get the release out the door. One of the sacrificed things in Workshop 8.1 was better, richer support for the traditional Java/J2EE expert. We are not through and I suspect that you will see better support for traditional Java/J2EE development as we move forward.
As always, BEA continues to work with partners to provide alternative IDE options for our customers. JBuilder 9 is a good example of this. We try to do what we can to support as many IDE options for our customers as possible. However, the reality is that BEA is that we have to prioritize our work based on our long-term strategy, our customers' needs, and our limited resources.
As Byron points out, Workshop (and all other BEA product) development licenses are free from BEA and BEA offers support for Workshop.
Just my two cents,
Co-Author of Mastering BEA WebLogic Server: Best Practices for Building and Deploying J2EE Applications
The great thing about eclipse is that it has tremendous momentum (30 Million downloads from the eclipse site), a dedicated community, and a huge number of plug-in projects underway (more than 600 plug-in projects). It is hard to imagine how Weblogic will compete with that. I wonder why they don't just join the eclipse project and work on adding functionality, the way myeclipse is doing; rather than trying to go it alone.
SWT is not the right way to go now. It is a barrier to interoperbility and bad idea. Someday IDEA and Workshops plugins could be compatible. But with Eclipse not using Swing, there is little chance that will be intergrated.
I think that SWT is the right way to go now. Although, I must admit, when I first heard that eclipse was going to use a new widget toolkit, I also thought it was a bad idea.
However, after seeing the results, I have changed my mind. From a practical perspective SWT is available on a large number of platforms and IMHO provides a significantly better user experience than is usually achieved using Swing.
The following is a quote from the eclipse sight discussing the reasons that they feel justify the introduction of a new toolkit:
<QUOTE>The Swing toolkit attempts to address this problem by providing non-native implementations of high level widgets like trees, tables, and text. This provides a great deal of functionality, but applications developed in Swing stand out as being different. Platform look and feel emulation layers help the applications look more like the platform, but the user interaction is different enough to be noticed. This makes it difficult to use emulated toolkits to build applications that compete with shrink-wrapped applications developed specifically for a particular OS platform
I know that this issue is a highly contentious one, and that there are some passionate Swing developers who would disagree with this justification. I also am aware that some Swing developers are angry that this new toolkit was introduced without going through the JCP. However, I think now that it has been done, it will not be possible to put the genie back in the bottle. It seems to me, now that Sun is talking about joining the eclipse project, that the SWT could very well be a replacement for Swing. I believe if this happens it will be a positive thing for the Java community, as it will allow Java applications to better compete against native apps.
It might be slightly better for some platforms and it is much worse for other platforms. Big deal. We need interoperability so that we (as a community) only need to write plugins once instead of one SWT version and one Swing version. Try Workshop from BEA and you will see that Swing can be just as fast as an SWT interface. Most people are surprised to find out that Workshop isn't an native application.
Can someone from the Eclipse development team comment on how hard it would be to rewrite Eclipse in Swing or at least a prototype so that we can see what progress has been made since 1.2?
Many people argue that examples like IntelliJ IDEA and BEA Workshop showing that Swing based GUI can be as good as native GUI. That's why no reason for using SWT. But the problem is how many effort that you have to put in order to make Swing works smooth? With SWT, it is naturally close to native. Everyone can easily create applications as smooth as Eclipse.
Someday IDEA and Workshops plugins could be compatible. But with Eclipse not using Swing, there is little chance that will be intergrated.
Is this problem insurmountable in JSR 198 "A Standard Extension API for Integrated Development Environments"? It seems the JSR assumes that all GUIs derive from AWT or Swing:
"2.5 Please give a short description of the underlying technology or technologies:
J2SE, AWT, Swing"
Indeed Jini's GUI API also has dependencies on AWT and maybe Swing, making it unlikely or impossible that Jini GUIs use SWT.