David Sean Taylor wrote:
Well we now have a new complication with Fusion.
The CVS head for 2.0 will soon change its deployment model.
In the deployment branch, quite a few interfaces that Fusion is dependent on are now deleted.
The code doesn't even compile against this branch.
Once again, J2 developers have no consideration for Fusion.
This is a bold statement.
I know and you know that I started in the new deployment branch from a clean sheet. I explicitly stated that this would *initially* result in some features gone missing. I also said these features have to be recreated once we decide this proposed new deployment model. Right now, I have had no formal acknowledgment from *anyone* yet to go ahead and commit my changes to the main branch. Probably everybody does know though I definitely would like to see this happen, but I will be the first to acknowledge that it isn't ready for that yet. Providing support back for undeployment, unregistration, registration, ServerManager integration, *AND FUSION* absolutely is a requirement I will stand for before moving to the new deployment model (if it comes to that).
Now, I *did* look at Fusion when I started my deployment refactoring and how it is dependent on the current deployment features of J2. As far as I can tell (I'm no Fusion expert, I'll admit that), the currently missing features from the deployment branch are quite easy to replace, if not easier than it was initially (alright, maybe that's a bold statement of mine).
The most prominent missing functionality in the new deployment branch for Fusion is the FilesystemPAM. All of its features (as used by Fusion) are now available from the new PortletApplicationManager. Maybe at first sight the deploy and undeploy features are still missing from it, but Fusion isn't actually using these methods, other than hooking into them to synchronize the J1 Registry. The new PortletApplicationManager registerPA and unregisterPA methods provide functionally the same hooks AFAIK.
And then of course the integration with the ServerManager. This will be quite easy to bring back online. Actually, I've already done so. I have the TomcatManager working again. Furthermore, I created a new (secured) ManagerServlet through which you can interact with the ApplicationManagerServer as well as the PortletApplicationManager. I've used the Tomcat ManagerServlet as example for this.
Right now I can list, start, stop, unregister and undeploy a PortletApplication all from the commandline or webbrowser and working without problems. Providing the same features to Fusion will be a peace of cake.
I'm still working on an deploy command (uploading a deployment object like a war or decorator). The basic code is already in place, the only thing left to implement is the uploading part in the new commandline tool (JetspeedConsole).
I'm putting in a lot of effort to get this all working even *better* than it did before, and I'm going to provide as much effort as needed to get Fusion working again with the new deployment model, once we decided it will be the used for J2.
Perhaps we should formally call a vote on the jetspeed-dev list: 1. deprecate fusion
Nonsense
-or-- 2. require developers to test fusion
I do care about Fusion and, as far you *can* require that, I have no objection to make it a policy.
We should think about an easier way to test fusion do though because getting J1 and J2 to build right beside each other is quite a hassle...
Frankly the whole situation has led to me becoming less and less involved in Jetspeed as my contributions are devaluated.
I think you are over reacting. I value your contributions very highly and I know I'm not alone ;-)
You did a hell of a job (and I know it was a hell of a job) to integrate J2 with J1, AKA Fusion. I think it is one of the most important contributions to Jetspeed (as a whole, J1 and J2 together) because it not only provides a JSR-168 container but also a view of the power of J2 and a migration path for J1 users not (yet) ready to make the jump to J2.
As Jeff Sheets said in another response: J1 is much more stable and complete than J2. Fusion provides JSR-168 support *now* to end users of Jetspeed.
Anyway, enough of my whining.;-)
What we could do put out the 1.6 release with 2.0 M1
But since the deployment is changing in M2, this means that Fusion is stuck at M1 until someone comes along and refactors the Fusion deployment.
As I said above, I'm more than willing to do so. Doing that with your help would make it much quicker and easier though.
Regards, Ate
Im open to suggestions
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
