[Robert Patt-Corner]

This message has not been recovered.

[Riyad Kalla]

This message has not been recovered.

[Robert Patt-Corner]

This message has not been recovered.

[Riyad Kalla]

This message has not been recovered.

[Robert Patt-Corner]

@support-rkalla wrote:

hmmm… this is exactly what I’m testing with. Can you deploy new projects without the infinite hang? Is it something about that one particular project that causes the infinite hang? Also when a project is deployed Exploded, MyEclipse will sync the changes instantly, so you shouldn’t need to reopen the dialog each time and hit redeploy, but even if you did that, it should still work.

I do believe it is something about the project, in that a new clean project deploys without problem. However after deploying our target project the interaction between Blue and WAS becomes corrupted in some way, in that
the new project will no longer deploy. Likewise, while I understand the expected behaviour of a change while deployed, we lose that capability once we’ve failed to deploy.

Ever going to do Linux?

We will respond to the user demand for it, if it’s there.

Consider it demanded, at least from here. Faster, more reliable, safer. We do all our development using the Linux-based tooling

By “do you have a reference” do you mean “how did I do it?” or “who said it was supported?”. Nobody said it was supported, be glad to post a how to if you want one.

Oh yea, I meant “how did you do it exactly”? I wanted to get some more insight into what you did exactly.

Did this:

1. Added WAS Build library with alternate workspace JRE per http://www.myeclipseide.com//PNphpBB2-viewtopic-t-20093.html

2. Resolved JAXB references by adding WebSphere 6.1 Web Service Client Libraries

3. Removed any extraneous IBM imports in the code

4. Add genuitec NATURES to the .project file to recognize as a web project:
<nature>com.genuitec.eclipse.j2eedt.core.webnature</nature>
<nature>org.eclipse.jdt.core.javanature</nature>

5. Add an adjusted .mymetadata file

=====
In order to work around the multitude of variables with migration, I’m trying a clean approach with slightly better but still problematic results, which I’ll address in my next reply in this thread.

[Robert Patt-Corner]

Clean Approach to JSF project Migration
========================
Tried a clean approach to JSF migration that still has some significant issues, maybe bugs, maybe not. The overall observations are:

1. The clean project approach is doable, albeit with loss of SVN data
2. Initially, at least the clean migrated project partially runs (we’ll deal with bugs separately).
3. The deployed clean project is initially modifiable, unlike the hand-hacked migrated project. However in at least one case I had to undeploy, and then found I could never deploy the unmodified hand migrated project again ,even with stopped server, etc. Behaviour was the same as with the hacked-migrated project … deploy never finishes, no error
4. Note that this project uses both the IBM hx extended faces libraries and MyEclipse tomahawk, integrated successfully in AST and RAD. There is a chance that Blue does not deal happily with that mix of JSF tag libraries
5. For reasons that escape me, the IBM Web Services-WS library is no longer available in my workspace, and I can’t find or recall how to enable it. Same WS-enabled IBM server. What am I missing? Had to hand-include jaxb in the classpath for build.

The process I used for clean migrate was:

1. Create a clean Blue Web and EAR project using JEE 1.4
2. Accept default naming for WebRoot. Note that in my previous attempts at clean construction I followed the IBM convention of WebContent. That shouldn’t matter, but who knows?
3. Added JSF and Spring natures from the MyEclipse menu, specifying the Sun RI, as the IBM extended tags will need SUN 1.1.
4. Added java sources by copy and paste from a resources view. Copy and paste from JEE view does bad things, doesn’t maintain package structures
5. Resolved extensive classpath issues. JARS manually added to WEB-INF/lib:
tomahawk 1.1.6 and tomahawk sandbox 1.1.7
jsf-ibm.jar and odc-jsf.jar for the IBM HX jsf libraries
spring-test.jar because the MyEclipse Spring Testing Support Llibraries did not resolve all my classes in our JUnits
struts.jar because we use Tiles on top of JSF. Did not try the MyEclipse struts … might have worked
JRE from WAS 6.1 server
JUNIT 4
com.ibm.jaxws.thinclient_6.1.0.jar from WAS_ROOT/runtimes because I couldn’t find the WebSphere WS library entry I’d seen earlier

6. Copied the web code but not web-inf contents into WebRoot

7. Copied tiles-defs.xml into WEB-INF

At this point the application was complete and compiling, but essentially disabled, since the original web.xml, applicationContext.xml and faces-config.xml were still in place. I ran it to test behaviour. It ran, and was modifiable, at least at the JSP level.

8. Copied the contents, not the files of the 3 config files above to their Blue counterparts, being careful to use the Blue DTD’s.

9. Ran the application with success

The application was modifiable mostly. Blue doesn’t see a change in a resource bundle, but sees changes in .Java and .jsp OK, which is fine. However in a series of deploy and redeploys I eventually hung and had to rollback the environment. Happily all our work is in VMWare.

The IBM tags are not happy … will post as a separate bug

[Riyad Kalla]

Robin,
I sent this off to one of the leads on the Blue project to analyze and then get back to you. We are introducing our new project migration in the 6.5 release of Blue and you posted a significant amount of details here that we should look into and be able to anticipate during that process.

[Author]

Posts