You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <pe...@apache.org> on 2002/09/24 15:27:43 UTC
stable Fortress?
Hiya,
I just got asked *again* about when Fortress is going to be stable and
released. Quite a few people still use ECM and want to migrate to it's
successor with zero if any significant impact. I would really like to see
Fortress released sooner rather than later and with ECM features closely
matched.
I don't know the status of metadata stuff but it may be a an idea to put it
off till Fortress2 or work on it in a branch or something. However I would
love to see a release soon. If needs be could we go back in time and branch
fortress then to provide a stable release?
--
Cheers,
Peter Donald
-----------------------------------------------------------
Don't take life too seriously --
you'll never get out of it alive.
-----------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Preparing for Fortress 1.0 Release
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Berin Loritsch wrote:
> We have the prereq of making official releases of each of these peices:
>
>> AltRMI (for Instrumentation)
>
AltRMI is actually only required by the Altrmi connector of the
Instrument Manager. If it is
not configured in the instrument configuration file, it is not used.
Currently, it is the only
available connector if you want to access the IM from a client however.
>> Instrument
>> Instrument-Manager
>
>
> Instrument -- Notes on how to make your classes instrumentable. If the
> interfaces are stable, we need to look at making this a
> stable release. (Test cases are critical!!!!)
Ok, I'll push to try and get these done. Been burried with work the
past couple
months. Still a few hours a day I am wasting on sleep that I can use to
get this
done. :-)
> Instrument-Manager -- Notes on how to incorporate the InstrumentManager
> into your projects, as well as how to configure
> it. If there are things that will change here,
> please indicate that.
>
> Leif, Can you take responsibility for the Instrument/Instrument-Manager
> projects to get the docs and some testcases up?
Wil do. The client still needs some work though, but it does not need to be
at the same level of stability as it is an external application.
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Preparing for Fortress 1.0 Release
Posted by Berin Loritsch <bl...@apache.org>.
Fortress does not require I18n, so it is a *little* less work.
>> I18n (for Meta)
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Preparing for Fortress 1.0 Release
Posted by Berin Loritsch <bl...@apache.org>.
Marcus Crafter wrote:
> Hi Berin,
>
> On Wed, Sep 25, 2002 at 09:49:05AM -0400, Berin Loritsch wrote:
>
>>That leaves a volunteer needed for Container. Since I added most of the
>>new things, I can take it. I will be happy to let someone else take
>>care of it though. ;P
>
>
> I can take care of Container if you like.
Excellent! Take a look at how I set up the docs for Event (even the
commented out entries in menu.xml). It will give an idea of what should
be good enough.
>>If we team up and split the labor like that, I think we can get Fortress
>>1.0 out the door. Who has experience with Ant tasks? I want something
>>that can convert an ECM Roles file to a Fortress compatible one. I will
>>add a utility class that will help in the transition--that way we can
>>make the transition as seamless as possible.
>
>
> This shouldn't be too hard to do. I'll take a crack at it.
>
> Do you have any dates for all this in mind BTW ?
As soon as its done.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Preparing for Fortress 1.0 Release
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
Hi Berin,
On Wed, Sep 25, 2002 at 09:49:05AM -0400, Berin Loritsch wrote:
>
> That leaves a volunteer needed for Container. Since I added most of the
> new things, I can take it. I will be happy to let someone else take
> care of it though. ;P
I can take care of Container if you like.
> If we team up and split the labor like that, I think we can get Fortress
> 1.0 out the door. Who has experience with Ant tasks? I want something
> that can convert an ECM Roles file to a Fortress compatible one. I will
> add a utility class that will help in the transition--that way we can
> make the transition as seamless as possible.
This shouldn't be too hard to do. I'll take a crack at it.
Do you have any dates for all this in mind BTW ?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Preparing for Fortress 1.0 Release
Posted by Giacomo Pati <gi...@apache.org>.
On Wed, 25 Sep 2002, Berin Loritsch wrote:
> We have the prereq of making official releases of each of these peices:
>
> > Concurrent
> > Collections
> > Container (for the legacy compatibility)
> > Event
> > I18n (for Meta)
> > Meta (for the metadata stuff)
> > SourceResolver
> > AltRMI (for Instrumentation)
> > Instrument
> > Instrument-Manager
> > Util (for System--haven't moved that over yet)
> > Logger
> > ThreadContext
>
> What we need are some docs for these things. I don't have the time to
> take care of all of them, so I am seeking some help. The Docs need to
> represent the WHAT, WHEN, WHY, HOW questions, as well as any notes about
> future direction. Here are some notes I would like to incorporate:
>
> Concurrent -- Point people to Doug Lea's libraries. Do we want to
> officially deprecate this?
>
> Collections -- It will be replaced in favor of Jakarta-Commons
> Colletions when they make a new release.
>
> Container -- Usage notes on Legacy, ClassLoader, Lookup, Lifecycle
>
> SourceResolver -- Usage notes, and notes on extending it for your
> own protocols.
>
> Instrument -- Notes on how to make your classes instrumentable. If the
> interfaces are stable, we need to look at making this a
> stable release. (Test cases are critical!!!!)
>
> Instrument-Manager -- Notes on how to incorporate the InstrumentManager
> into your projects, as well as how to configure
> it. If there are things that will change here,
> please indicate that.
>
> Logger -- Notes on how to configure the various LoggerManagers.
>
> ThreadContext -- Something. I don't know a whole bunch about this,
> other than it is supported in the ThreadPool.
>
> I will take responsibility for the Event package and moving the
> SystemUtil code into Event. I will also make the Meta package an
> *Optional* dependency for the time being. That means for the purpose
> of a Fortress 1.0 release, we can remove the requirement for Meta
> and I18n so we can document them later enabled classes.
>
> Leif, Can you take responsibility for the Instrument/Instrument-Manager
> projects to get the docs and some testcases up?
>
> Peter D., Can you take responsibility for ThreadContext (I think that is
> your baby)?
>
> Carston or Giacomo, Can you take responsibility for Logger and Source
> Resolver?
I can have a look at Logger (I know: look at Event to get a clue how to
do it ;)
Giacomo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Preparing for Fortress 1.0 Release
Posted by Berin Loritsch <bl...@apache.org>.
We have the prereq of making official releases of each of these peices:
> Concurrent
> Collections
> Container (for the legacy compatibility)
> Event
> I18n (for Meta)
> Meta (for the metadata stuff)
> SourceResolver
> AltRMI (for Instrumentation)
> Instrument
> Instrument-Manager
> Util (for System--haven't moved that over yet)
> Logger
> ThreadContext
What we need are some docs for these things. I don't have the time to
take care of all of them, so I am seeking some help. The Docs need to
represent the WHAT, WHEN, WHY, HOW questions, as well as any notes about
future direction. Here are some notes I would like to incorporate:
Concurrent -- Point people to Doug Lea's libraries. Do we want to
officially deprecate this?
Collections -- It will be replaced in favor of Jakarta-Commons
Colletions when they make a new release.
Container -- Usage notes on Legacy, ClassLoader, Lookup, Lifecycle
SourceResolver -- Usage notes, and notes on extending it for your
own protocols.
Instrument -- Notes on how to make your classes instrumentable. If the
interfaces are stable, we need to look at making this a
stable release. (Test cases are critical!!!!)
Instrument-Manager -- Notes on how to incorporate the InstrumentManager
into your projects, as well as how to configure
it. If there are things that will change here,
please indicate that.
Logger -- Notes on how to configure the various LoggerManagers.
ThreadContext -- Something. I don't know a whole bunch about this,
other than it is supported in the ThreadPool.
I will take responsibility for the Event package and moving the
SystemUtil code into Event. I will also make the Meta package an
*Optional* dependency for the time being. That means for the purpose
of a Fortress 1.0 release, we can remove the requirement for Meta
and I18n so we can document them later enabled classes.
Leif, Can you take responsibility for the Instrument/Instrument-Manager
projects to get the docs and some testcases up?
Peter D., Can you take responsibility for ThreadContext (I think that is
your baby)?
Carston or Giacomo, Can you take responsibility for Logger and Source
Resolver?
Nikola, can you take Collections/Concurrent? For these, we don't have
to instruct how to use the classes, just an overview of what is in there
and what problem the type of class solves (i.e. Buffer, etc.).
That leaves a volunteer needed for Container. Since I added most of the
new things, I can take it. I will be happy to let someone else take
care of it though. ;P
If we team up and split the labor like that, I think we can get Fortress
1.0 out the door. Who has experience with Ant tasks? I want something
that can convert an ECM Roles file to a Fortress compatible one. I will
add a utility class that will help in the transition--that way we can
make the transition as seamless as possible.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: stable Fortress?
Posted by Peter Royal <pr...@apache.org>.
On Tuesday, September 24, 2002, at 09:52 AM, Berin Loritsch wrote:
> We need to add support for the old Recycleable interface (for
> compatibility reasons). My take is to use reflection, and determine if
> the class has a public recycle() method and just use it. That way we
> don't have to migrate interfaces or anything like that.
I'd prefer to migrate the interface, or support it as a lifecycle
extension.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: stable Fortress?
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> Hiya,
>
> I just got asked *again* about when Fortress is going to be stable and
> released. Quite a few people still use ECM and want to migrate to it's
> successor with zero if any significant impact. I would really like to see
> Fortress released sooner rather than later and with ECM features closely
> matched.
>
> I don't know the status of metadata stuff but it may be a an idea to put it
> off till Fortress2 or work on it in a branch or something. However I would
> love to see a release soon. If needs be could we go back in time and branch
> fortress then to provide a stable release?
We need to add support for the old Recycleable interface (for
compatibility reasons). My take is to use reflection, and determine if
the class has a public recycle() method and just use it. That way we
don't have to migrate interfaces or anything like that.
The MetaData stuff is not working yet, but it is being worked on in a
way so as not to interfere with the DefaultContainer (i.e. the current
way of doing things).
That said, we need to add the proper docs (as outlined in another
thread) for Fortress, and all its dependencies. We can release
Fortress then. If we have any volunteers, we can get this party
started sooner than later. I have a class I need to get to the point
where it compiles, and after that I can tackle the "Recyclable" issue.
I need help with documentation and getting the other pieces released.
Fortress uses a lot of other pieces:
Concurrent
Collections
Container (for the legacy compatibility)
Event
I18n (for Meta)
Meta (for the metadata stuff)
SourceResolver
AltRMI (for Instrumentation)
Instrument
Instrument-Manager
Util (for System--haven't moved that over yet)
Logger
ThreadContext
I can release it as Beta which will allow us to use all the other
stuff whether it is released or not. A final release will require
getting everything else released.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: stable Fortress?
Posted by Stephen McConnell <mc...@apache.org>.
Marcus Crafter wrote:
>On Tue, Sep 24, 2002 at 03:51:46PM +0200, Leo Simons wrote:
>
>
>>However, I think it would be a shame if it means that a future
>>fortress, or "merlin's fortress" as talked about before, would
>>need to provide yet more compatibility with old materials (ie
>>with ECM *and* fortress1). I am not familiar enough with fortress
>>to make this estimate.
>>
>>
>
> I'm not familiar enough either, but I still feel that we're
> reinventing the wheel with both Fortress and Merlin continuing as
> separate containers.
>
> I know there's been progress at unifying the common ground with the
> container/ and meta/ subprojects - but I would so much rather 1
> container to work on rather than having to choose between the 2 (as is
> currently happening on cocoon-dev).
>
> Berin, why don't we just make Fortress' MetaDataContainer extend
> from Merlin's DefaultContainer and have it provide Fortress style
> semantics ?
>
This is completely achivable. The ability to plug in a custom lifestyle
manager is already in place - which would be needed to take care of the
particular semntics implied by ECM components.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: stable Fortress?
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
>On Tue, 2002-09-24 at 23:22, Peter Donald wrote:
>
>
>>On Wed, 25 Sep 2002 00:15, Marcus Crafter wrote:
>>
>>
>>> That would allow us to take more advantage of Steven's foundation
>>> level work with Merlin, and would give us a fast and easy upgrade
>>> path for ECM ?
>>>
>>>
>>You will also end up having to customize some Avalon components to work with
>>Meta. These customizations will never ever make them into Avalons CVS (at
>>least for the components I use/manage). So thats another thing to consider.
>>
>>
>
>How happily we work together. Bye bye to cooperation, hello to FUD. I'm
>sure I'm not the only one getting real sick of this.... :'(
>
>
Your not the only one!
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: stable Fortress?
Posted by Leo Simons <le...@apache.org>.
On Tue, 2002-09-24 at 23:22, Peter Donald wrote:
> On Wed, 25 Sep 2002 00:15, Marcus Crafter wrote:
> > That would allow us to take more advantage of Steven's foundation
> > level work with Merlin, and would give us a fast and easy upgrade
> > path for ECM ?
>
> You will also end up having to customize some Avalon components to work with
> Meta. These customizations will never ever make them into Avalons CVS (at
> least for the components I use/manage). So thats another thing to consider.
How happily we work together. Bye bye to cooperation, hello to FUD. I'm
sure I'm not the only one getting real sick of this.... :'(
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: stable Fortress?
Posted by Peter Donald <pe...@apache.org>.
On Wed, 25 Sep 2002 00:15, Marcus Crafter wrote:
> That would allow us to take more advantage of Steven's foundation
> level work with Merlin, and would give us a fast and easy upgrade
> path for ECM ?
You will also end up having to customize some Avalon components to work with
Meta. These customizations will never ever make them into Avalons CVS (at
least for the components I use/manage). So thats another thing to consider.
--
Cheers,
Peter Donald
--------------------------------------------------
"An intellectual is someone who has been educated
beyond their intelligence."
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: stable Fortress?
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Tue, Sep 24, 2002 at 03:51:46PM +0200, Leo Simons wrote:
> However, I think it would be a shame if it means that a future
> fortress, or "merlin's fortress" as talked about before, would
> need to provide yet more compatibility with old materials (ie
> with ECM *and* fortress1). I am not familiar enough with fortress
> to make this estimate.
I'm not familiar enough either, but I still feel that we're
reinventing the wheel with both Fortress and Merlin continuing as
separate containers.
I know there's been progress at unifying the common ground with the
container/ and meta/ subprojects - but I would so much rather 1
container to work on rather than having to choose between the 2 (as is
currently happening on cocoon-dev).
Berin, why don't we just make Fortress' MetaDataContainer extend
from Merlin's DefaultContainer and have it provide Fortress style
semantics ?
That would allow us to take more advantage of Steven's foundation
level work with Merlin, and would give us a fast and easy upgrade
path for ECM ?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: stable Fortress?
Posted by Leo Simons <le...@apache.org>.
> I just got asked *again* about when Fortress is going to be
> stable and
> released. Quite a few people still use ECM and want to
> migrate to it's
> successor with zero if any significant impact. I would really
> like to see
> Fortress released sooner rather than later and with ECM
> features closely
> matched.
Hmm. While it would be nice to have a release, it also means
we need to support it. And then fortress2 will need to support
easy upgrading too otherwise it wouldn't be fair to users.
If the authors of Fortress feel a release is warranted and that
they can support it, and future releases, I'm not going to be in
the way (though I feel there should be more docs ;).
However, I think it would be a shame if it means that a future
fortress, or "merlin's fortress" as talked about before, would
need to provide yet more compatibility with old materials (ie
with ECM *and* fortress1). I am not familiar enough with fortress
to make this estimate.
Just a thought =)
cheers,
Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: stable Fortress?
Posted by Vincent Massol <vm...@octo.com>.
+100. I a user of ECM at work and I've been wanting to move for a while
but I don't have the time to play with nightly builds at the moment. For
the project I'm working on, I need a release.
Thanks
-Vincent
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: 24 September 2002 14:28
> To: avalon-dev@jakarta.apache.org
> Subject: stable Fortress?
>
> Hiya,
>
> I just got asked *again* about when Fortress is going to be stable and
> released. Quite a few people still use ECM and want to migrate to it's
> successor with zero if any significant impact. I would really like to
see
> Fortress released sooner rather than later and with ECM features
closely
> matched.
>
> I don't know the status of metadata stuff but it may be a an idea to
put
> it
> off till Fortress2 or work on it in a branch or something. However I
would
> love to see a release soon. If needs be could we go back in time and
> branch
> fortress then to provide a stable release?
>
> --
> Cheers,
>
> Peter Donald
> -----------------------------------------------------------
> Don't take life too seriously --
> you'll never get out of it alive.
> -----------------------------------------------------------
>
>
> --
> To unsubscribe, e-mail: <mailto:avalon-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:avalon-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: stable Fortress?
Posted by Peter Royal <pr...@apache.org>.
On Tuesday, September 24, 2002, at 09:27 AM, Peter Donald wrote:
> I don't know the status of metadata stuff but it may be a an idea to
> put it
> off till Fortress2 or work on it in a branch or something. However I
> would
> love to see a release soon. If needs be could we go back in time and
> branch
> fortress then to provide a stable release?
We're using an older version (august 7th) of fortress here with no
problems. I would not hesitate to move a version of that "vintage" to a
beta and then release cycle (We are using it in production systems over
here). I have not had a chance to review the changes made to Fortress
in the past month as I've been working on higher-level functionality
for our system and did not want to rock a stable ship.
So what I'm getting at... I'm +1 on a stable release of Fortress soon.
I agree that the metadata work can be for a 1.5 or 2.0 release. But
with a 'deprecated' ECM, we need to provide a path for our users.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>