Hi all,
I just wanted to say that I also think that the work that went into Fusion is important on multiple levels :
- first of all I integrate J2 with my product in a way very similar to what Fusion does, so if J2 changes a lot, I spend my time refactoring my code and understanding the changes, but this is my problem (btw currently I've frozen the version of J2 I use so that I can work on the integration)
- Fusion is a great "test case" for using J2 as a "component library", and I think that this has generally been a very good influence on the design of J2
- as other have said Fusion is a great migration path
Anyway, I didn't have time to follow the whole refactoring work on deployment, but as long as it's able to deploy from a directory and maybe has a listener interface I think it should be ok.
Regards, Serge Huber.
David Sean Taylor wrote:
Ate Douma wrote:
> 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.
Here is my acknowledgement: resolve the Fusion issues before merging.
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.
Me too
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.
Great
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
I'll take that as a -1 on deprecating Fusion ;)
-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.
Well, we did everything except put out a release, and its long overdue.
We need to figure out if we want to release 1.6 with:
2.0 M1 2.0 M2 2.0 Final Release
We could do a 1.6.1 release with M2, 1.6.2 with the Final Release
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
