On Jul 2, 2004, at 6:00 AM, Scott T Weaver wrote:


Now this is a question of how we manage these APIs : should they be deleted
or should they be part of a "library API" for J2 ? As David mentioned some
APIs are also used by Fusion, so removing methods might break J1, and that
is not something that we would like.

No, its not good at all to break other people's things. It is somewhat a (good) surprise that software that is still in the alpha stages is depended on by other projects in the way that J2 is.


thanks for updating the Fusion dependencies Haven't tested it yet, still dealing with J2 test deploy test failing


On another side, freezing APIs should only be done I think on "major"
releases, so I'm open to options. I will still have the problem of managing
somehow navigation state, and J2's current implementation relies solely on
PortletWindow objects.
+1.  There is still A LOT of refactoring yet to be done on J2, and
IMOHO, the refactoring will never stop.  We still have many things left

"The refactoring will never stop"
Well, I take issue with that. I personally am mortal, when I die, or better yet when I retire or 'move on', the refactoring stops for me
Or maybe there is a refactoring hell ;-)


in /portal that need to be made into components.  I think I have
PAM/Deployment pretty much ready to move.

Well I think a lot of that refactoring could go on in the Pluto CVS to make the Pluto API a lightweight component good citizen
We've a ways to go there


My current refactoring will involve making the Engine a component
I think someone has already signed up for making the pipeline a component



-- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to