I feel workshop as an IDE is still not mature enough.I moved from sp1 to sp2 and now to sp3. Each version needs one or other patch for bugs. Moreover it is not a complete development tool. For eg to develop cutom ejb''s I still use Jbuilder. Not to mention how much resource hog it is when tryiung to run the ide and development server on the same machine.

We have been using WLW for the last six weeks with a large project previously maintained using JBuilder. Our biggest problem is stability. WLW has several bugs causing it to become unstable where we typically have to quit and restart in order to get it to operate properly. This of course never happens with JBuilder and has been a real turn off for the team of developers seriously trying to use Workshop. (This is with WLW SP3. WLW SP2 had even more issues).

It is very likely that we will be back to giving Borland our dollars for development environments, as WLW is not ready for use in a serious development project.

albatross - WLW does nothing but build an ANT file for its build. As a matter of fact you can export it and modify it to you hearts content. Read about it here http://e-docs.bea.com/workshop/docs81/doc/en/workshop/guide/howdoi/howUs...

Server''s great, but we avoid WLW as much as we can. We use JBuilder and invest learning in that tool.

In the past, I was looking for a top-level declaration of what an application is doing, tag-based. Not JPF.

Please give us an Ant file to build applications--the workshop build is encoded in java--in class files--the build is a proprietary java program (this is nuts).

WLW should not try to talk to the server. I never have both WLW and the Server running at the same time because I can never get anything accomplished.

We just try to get around WLW as much as we can, using it only to do the application tasks that we have no other way to do.

I choose to use WL Workshop for some aspects of development and choose not to use if for other aspects. My biggest complaint is the meta language used in WL workshop compiles to class files, and not source code. I don''t like the fact that you create a "control" and then behind the scenes an ejb, jms queue, and a web service is created, and you have no idea this happens unless you analyze the config.xml or console. If the meta language compiled into source code, I would probably use it much more often. I think you guys are close to having a really great product.

I also decided to use Struts instead of flows. It is easier to upgrade if you use Struts rather than upgrading all your flows from Portal 4.0 to Portal 8.1