You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@d-haven.org> on 2004/04/08 18:57:06 UTC
Is the Fortress Direction Official?
I know that Avalon has decided to focus on Merlin. I have no problems
with that, and I wish you all the best in that endeavor. I thought that
the exact direction of Fortress was still up in the air--beyond no
longer supporting it.
If that is the case, I would like to host it over on D-Haven, or perhaps
something like it that is compatible. While I know there should be no
issue with the latter course, the first one does require a "buyout" so
to speak with Avalon.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Fortress to Merlin howto ?
Posted by Stephen McConnell <mc...@apache.org>.
filipdef@cirquedigital.com wrote:
>>filipdef@cirquedigital.com wrote:
>>
>>>Hi,
>>>
>>>Is there any documentation so far on the migration from Fortress
>>>to Merlin ? I think even a quick howto describing some of the pitfalls
>>>would be very helpful..
>>
>>This subject is largely a work in progress. So far I have not dealt
>>with any Fortress to Merlin migration scenarios, only ECM to Fortress.
>>However - in principal a Fortress to Merlin migration should be easier
>>than a ECM to Merlin migration.
>
>
> that's a relief ;-)
>
>
>>Important points:
>>
>> * merlin will do a lot of the work for you - in merlin land
>> less information is better - merlin will do the grunt work
>> for you
>>
>> * pooled lifestyle are not supported in native merlin -
>> basically the best approach is to declare a component that
>> provides the pool and service interface to access a pooled
>> instance (lots of technical reasons backing this)
>
>
> n/a in my use case.
>
>
>> * selectors are not supported - but if you need selection
>> semantics then solutions are available using the finder
>> facility - post some details about your scenario and we
>> will help with the migration
>
>
> that is an issue for me: GUIApp uses selectors to get to specific
> screen instances and my app does as well; basically lots of times
> I have a component that has a number of instances with different
> configurations, sometimes different implementations that all need
> to work together.
>
> E.g.
> InfoProvider --> DiskInfoProvider
> --> JDBCInfoProvider
> --> FtpInfoProvider
>
> All these do the same thing (provide info about my nodes), but
> use a different transport for each case.
OK - here is some terminology:
deployment scenario
the description of a request for the deployment
of a component type with a particular configuration,
content, parameters, service binding, etc. that is
uniquely addressable
component type
a description of a component, including its class,
deployment and runtime dependencies and associated
attributes
service
a functional interface exposed by an identifiable
component type
In you case InfoProvider is a common service. You have multiple
deployment scenarios (DiskInfoProvider, JDBCInfoProvider,
FtpInfoProvider, etc.) .. and you need to be able to declare that your
service dependency is more than just the interface - its also the
functionality delivered by the service.
We can setup a test case that leverages parameterized service
definitions as the selection reference. What this means is that at a
code level you should be able to publish not only the service interface
that a component supports, but also associate attributes with the
exported service definition. This is real important because it means
that we can separate the component implementation declarations from the
deployment declarations - which means your components become reusable.
However .. you go on to say:
> Now, the use case is that multiple of these guys are loaded and
> that they can be activated in sets. E.g. you can have 5 info
> providers and declare 2 sets, set 1 has info providers 1,2,3,4
> and set 2 has info providers 3,4,5.
>
> The output of the info providers gets aggregated by the container
> and the container answers the questions from the user (custom
> container in fortress).
>
> The actual implementation of this typically does the following
>
> Info Provider Other Provider
>
> | |
>
> DiskInfoProvider DiskOtherProvider
>
> \ |
>
> DiskProviderBase
>
>
> So the actual DiskXXX implementations share a common base component
> that deals with e.g. the root directory that those particular DiskXXX
> components share.. (you can have more than one DiskXXX set of components
> that have a different base). So, I declare these things as:
>
> <disk-base id="base1" root="C:/bla" />
> <disk-index id="index1" base="base1" />
>
> <disk-base id="base2" root="//SERVER/disk" />
> <disk-index id="index2" base="base2" />
> <disk-index id="index2b" base="base2" />
This is deployment level differentiation (as distinct for
differentiation of the semantics underlying a particular service). For
example in the above case you qualifying a particular deployment
scenario (with a configuration or context). In effect what you are
doing is describing the implementation of a sub-system that is capable
of providing a set of features where features are keyed by an id.
To maintain the overall component model integrity we need to encapsulate
this into either (a) a specific component deployment scenario, or (b) a
distinct service. This is what we'll sort out with the avalon-finder
facility.
> The index components then do serviceManager.lookup( Base.ROLE+"/"+
> conf.getAttribute("base")) to get to the base component..
Which is where the problems lies. This introduced semantics to an
generic operation that cross a boundary between component type
information and component deployment information.
Instead we should be doing:
MyFinder finder =
(MyFinder) serviceManager.lookup( "myFinder" );
Object wiget = finder.locate( conf.getAttribute("base") );
> Just doing a generic serviceManager.lookup( Base.ROLE ) won't work
> in this case, I need to find a specific base rather than just any
> base.
>
> (this kindof scenario happens a couple of times)
>
>
>>Take a tour of the tutorials .. they provide a good insight into how
>>merlin works and from that your should get a good idea of transition
>>overhead. Normally a transition should be relatively easy. But there
>>are special cases that require attention - and for the time being that
>>means posting info to the list about your scenario.
>
>
> will do, thanks.. Started looking at it a while ago, but then
> got sidetracked in delivery stuff..
>
> Another concern I have is the startup speed of Merlin. One of my
> applications is a GUI application (if you didn't get this by now ;-) )
> and obviously for these things startup time is crucial, and needs to
> be in the order of 3-4 seconds on a fast computer -- any ideas on
> how merlin will behave in this respect ?
I think we can deal with this via something inside the kernel.
Basically what I'm thinking of is some properties that tell the kernel
its running in an interactive mode together with sufficient info to
generate the splash screen during kernel deployment.
Cheers, Stephen.
> Thanks a lot,
>
> - Filip
>
>
>
>>Cheers, Stephen.
>>
>>
>>>Thanks,
>>>- Filip
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>>>For additional commands, e-mail: dev-help@avalon.apache.org
>>>
>>>
>>
>>
>>--
>>
>>|------------------------------------------------|
>>| Magic by Merlin |
>>| Production by Avalon |
>>| |
>>| http://avalon.apache.org/merlin |
>>| http://dpml.net/merlin/distributions/latest |
>>|------------------------------------------------|
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>>For additional commands, e-mail: dev-help@avalon.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Fortress to Merlin howto ?
Posted by fi...@cirquedigital.com.
> filipdef@cirquedigital.com wrote:
>> Hi,
>>
>> Is there any documentation so far on the migration from Fortress
>> to Merlin ? I think even a quick howto describing some of the pitfalls
>> would be very helpful..
>
> This subject is largely a work in progress. So far I have not dealt
> with any Fortress to Merlin migration scenarios, only ECM to Fortress.
> However - in principal a Fortress to Merlin migration should be easier
> than a ECM to Merlin migration.
that's a relief ;-)
>
> Important points:
>
> * merlin will do a lot of the work for you - in merlin land
> less information is better - merlin will do the grunt work
> for you
>
> * pooled lifestyle are not supported in native merlin -
> basically the best approach is to declare a component that
> provides the pool and service interface to access a pooled
> instance (lots of technical reasons backing this)
n/a in my use case.
>
> * selectors are not supported - but if you need selection
> semantics then solutions are available using the finder
> facility - post some details about your scenario and we
> will help with the migration
that is an issue for me: GUIApp uses selectors to get to specific
screen instances and my app does as well; basically lots of times
I have a component that has a number of instances with different
configurations, sometimes different implementations that all need
to work together.
E.g.
InfoProvider --> DiskInfoProvider
--> JDBCInfoProvider
--> FtpInfoProvider
All these do the same thing (provide info about my nodes), but
use a different transport for each case.
Now, the use case is that multiple of these guys are loaded and
that they can be activated in sets. E.g. you can have 5 info
providers and declare 2 sets, set 1 has info providers 1,2,3,4
and set 2 has info providers 3,4,5.
The output of the info providers gets aggregated by the container
and the container answers the questions from the user (custom
container in fortress).
The actual implementation of this typically does the following
Info Provider Other Provider
| |
DiskInfoProvider DiskOtherProvider
\ |
DiskProviderBase
So the actual DiskXXX implementations share a common base component
that deals with e.g. the root directory that those particular DiskXXX
components share.. (you can have more than one DiskXXX set of components
that have a different base). So, I declare these things as:
<disk-base id="base1" root="C:/bla" />
<disk-index id="index1" base="base1" />
<disk-base id="base2" root="//SERVER/disk" />
<disk-index id="index2" base="base2" />
<disk-index id="index2b" base="base2" />
The index components then do serviceManager.lookup( Base.ROLE+"/"+
conf.getAttribute("base")) to get to the base component..
Just doing a generic serviceManager.lookup( Base.ROLE ) won't work
in this case, I need to find a specific base rather than just any
base.
(this kindof scenario happens a couple of times)
>
> Take a tour of the tutorials .. they provide a good insight into how
> merlin works and from that your should get a good idea of transition
> overhead. Normally a transition should be relatively easy. But there
> are special cases that require attention - and for the time being that
> means posting info to the list about your scenario.
will do, thanks.. Started looking at it a while ago, but then
got sidetracked in delivery stuff..
Another concern I have is the startup speed of Merlin. One of my
applications is a GUI application (if you didn't get this by now ;-) )
and obviously for these things startup time is crucial, and needs to
be in the order of 3-4 seconds on a fast computer -- any ideas on
how merlin will behave in this respect ?
Thanks a lot,
- Filip
>
> Cheers, Stephen.
>
>>
>> Thanks,
>> - Filip
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>> For additional commands, e-mail: dev-help@avalon.apache.org
>>
>>
>
>
> --
>
> |------------------------------------------------|
> | Magic by Merlin |
> | Production by Avalon |
> | |
> | http://avalon.apache.org/merlin |
> | http://dpml.net/merlin/distributions/latest |
> |------------------------------------------------|
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Fortress to Merlin howto ?
Posted by Stephen McConnell <mc...@apache.org>.
filipdef@cirquedigital.com wrote:
> Hi,
>
> Is there any documentation so far on the migration from Fortress
> to Merlin ? I think even a quick howto describing some of the pitfalls
> would be very helpful..
This subject is largely a work in progress. So far I have not dealt
with any Fortress to Merlin migration scenarios, only ECM to Fortress.
However - in principal a Fortress to Merlin migration should be easier
than a ECM to Merlin migration.
Important points:
* merlin will do a lot of the work for you - in merlin land
less information is better - merlin will do the grunt work
for you
* pooled lifestyle are not supported in native merlin -
basically the best approach is to declare a component that
provides the pool and service interface to access a pooled
instance (lots of technical reasons backing this)
* selectors are not supported - but if you need selection
semantics then solutions are available using the finder
facility - post some details about your scenario and we
will help with the migration
Take a tour of the tutorials .. they provide a good insight into how
merlin works and from that your should get a good idea of transition
overhead. Normally a transition should be relatively easy. But there
are special cases that require attention - and for the time being that
means posting info to the list about your scenario.
Cheers, Stephen.
>
> Thanks,
> - Filip
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Fortress to Merlin howto ?
Posted by fi...@cirquedigital.com.
Hi,
Is there any documentation so far on the migration from Fortress
to Merlin ? I think even a quick howto describing some of the pitfalls
would be very helpful..
Thanks,
- Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Is the Fortress Direction Official?
Posted by Stephen McConnell <mc...@apache.org>.
Bruno Dumon wrote:
> On Thu, 2004-04-08 at 20:01, Stephen McConnell wrote:
> <snip/>
>
>>fortress/ecm migration
>>----------------------
>>
>>Irrespective o9f interests in delivering an ecm/fortress facility -
>>there remains an outstanding requirement for the delivery of an
>>ecm/fortress migration strategy. Based on experience with the Turbine
>>Fulcrum project .. this is reasonably strait forward for non-pooled
>>components. The main problem areas concern Selector semantics -
>>however, this can be address using the finder facility. Today this
>>means on-list collaboration - and form that we'll get in place the docs
>>for general migration. My guess is that this will be demand driven ...
>>i.e. don't wait for it to happen - if you need it push for it!
>
>
> ok, I'll help to do some pushing. I could use something like selectors.
> It doesn't have to be selectors, the finder would also fit.
Good - my impression is that there are a number of people that would
like to see a viable migration strategy. Finder is the first step on
that path.
> Currently the finder looks like this:
>
> public interface Finder
> {
> Object find( Class service ) throws FinderException;
> void release( Object object );
> }
>
> To have something selector-like, it should need an additional find
> method like:
>
> Object find( Class service, String hint ) throws FinderException;
We have to kill the "hint" word - it's a key with semantics.
> The hint could be specified on the component as an attribute.
>
> Or more generic:
>
> Object find( Class service, Map attributes ) throws FinderException;
Better.
> whereby the attributes would be checked against the attributes declared
> on components.
Two levels to consider:
(a) attributes at the level of the component type
(b) attributes at the level of a service export declaration
(c) attributes at the level of a component deployment descriptor
Classic ECM and Fortresss is based on (c) - but the end-gain here is to
provide (a), (b) and (c). I need a little time to clear up the current
3.3 build but once that's out of the way we can really dig into this area.
Cheers, Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Is the Fortress Direction Official?
Posted by Bruno Dumon <br...@outerthought.org>.
On Thu, 2004-04-08 at 20:01, Stephen McConnell wrote:
<snip/>
> fortress/ecm migration
> ----------------------
>
> Irrespective o9f interests in delivering an ecm/fortress facility -
> there remains an outstanding requirement for the delivery of an
> ecm/fortress migration strategy. Based on experience with the Turbine
> Fulcrum project .. this is reasonably strait forward for non-pooled
> components. The main problem areas concern Selector semantics -
> however, this can be address using the finder facility. Today this
> means on-list collaboration - and form that we'll get in place the docs
> for general migration. My guess is that this will be demand driven ...
> i.e. don't wait for it to happen - if you need it push for it!
ok, I'll help to do some pushing. I could use something like selectors.
It doesn't have to be selectors, the finder would also fit.
Currently the finder looks like this:
public interface Finder
{
Object find( Class service ) throws FinderException;
void release( Object object );
}
To have something selector-like, it should need an additional find
method like:
Object find( Class service, String hint ) throws FinderException;
The hint could be specified on the component as an attribute.
Or more generic:
Object find( Class service, Map attributes ) throws FinderException;
whereby the attributes would be checked against the attributes declared
on components.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Is the Fortress Direction Official?
Posted by Berin Loritsch <bl...@d-haven.org>.
Stephen McConnell wrote:
> Berin Loritsch wrote:
>
<snip/>
>
>> While I know there should be no issue with the latter course, the
>> first one does require a "buyout" so to speak with Avalon.
>
> Personal preference is to do it right - re-cut Fortress based on the
> enabling Avalon technologies and in the process provide a viable
> migration path. Niclas has already said he's ready to cut the
> meta-integration, I'm ready to deal with the repo-synchronization. All
> we really need is an ECM/Fortress expert (hint, hint).
Well, I think Alex Karasulu will be interested in helping out, and I
just talked to filipdef at D-Haven also concerned about the future of
Fortress.
As for me, I keep singing the same time song (I'm sure your tired of it
by now), but I am always available for questions.
BTW, what do you mean "deal with the repo-synchronization"? Are you
talking about putting "Repository" into Fortress? If so, please don't.
There are a lot of folks who have been wanting to make it optional on
Merlin to no avail. If it is still that controversial, then Fortress
would be available for those who don't want to buy in.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Is the Fortress Direction Official?
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> I know that Avalon has decided to focus on Merlin. I have no problems
> with that, and I wish you all the best in that endeavor. I thought that
> the exact direction of Fortress was still up in the air--beyond no
> longer supporting it.
I think is is really important to separate out here the following:
(a) fortress codebase
(b) fortress/ecm semantics
(c) fortress/ecm migration
fortress codebase
-----------------
I have three concerns with the fortress codebase.
(i) get is into a stable sustainable state - meaning that it
builds cleanly and is validatable via gump
(ii) that the code base is accessible for the purpose of a fork
in the context of a hypothetical user base that could form a
viable community around which this product can be maintained
(iii) a reference point for a semantic adapter based on merlin
technology, enabling binary support for ecm and fortress
components
fortress/ecm semantics
----------------------
Putting in place fortress and ecm semantic support based on the Avalon
platform is no big deal from a technical point of view. It is totally
feasible to provide a facility that is itself a container of ecm and/or
fortress components. The principal question is if this is a worthwhile
exercise. I put together an initial cut on an ECM facility a few weeks
ago and posted a note to avalon dev and cocoon - feedback zero - i.e. as
far as I can tell there is not interest in perusing this avenue. As a
consequence I've deleted the ecm facility. Personally I think this
direction is the right direction but its only going to happen if the
community wants it to happen.
fortress/ecm migration
----------------------
Irrespective o9f interests in delivering an ecm/fortress facility -
there remains an outstanding requirement for the delivery of an
ecm/fortress migration strategy. Based on experience with the Turbine
Fulcrum project .. this is reasonably strait forward for non-pooled
components. The main problem areas concern Selector semantics -
however, this can be address using the finder facility. Today this
means on-list collaboration - and form that we'll get in place the docs
for general migration. My guess is that this will be demand driven ...
i.e. don't wait for it to happen - if you need it push for it!
> If that is the case, I would like to host it over on D-Haven, or perhaps
> something like it that is compatible.
No problem with the codebase being hosted somewhere else -assuming that
your presuming an independent package namespace.
> While I know there should be no
> issue with the latter course, the first one does require a "buyout" so
> to speak with Avalon.
Personal preference is to do it right - re-cut Fortress based on the
enabling Avalon technologies and in the process provide a viable
migration path. Niclas has already said he's ready to cut the
meta-integration, I'm ready to deal with the repo-synchronization. All
we really need is an ECM/Fortress expert (hint, hint).
Cheers, Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Is the Fortress Direction Official?
Posted by Stephen McConnell <mc...@apache.org>.
Vijay Kumar AB wrote:
I agree it makes sence
> to put all teh efforts in one Container Merlin, but then we should make sure
> there is some kind of back-ward compatibility or wasy way to migrate to
> Merlin.
+1
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Is the Fortress Direction Official?
Posted by Vijay Kumar AB <vi...@hathway.com>.
I agree with you Shash...WE have a very stable website working on Cocoon and
is working great, It also uses ECM and there are about 70-80 components
working to a very stable website, Now my management is really not sure
whether to migrate to Merlin? or just be happy with the current work. And
mind you this is a growing webiste and we have to take decisions on whether
to stay with ECM or move on to Merlin or totally ditch Avalon and look at
other alternatives, as nobody really knows the reason why ECM should be
forked. I, as one of the developers, am very happy the way things are going.
I wish somebody takes this up and saves ECM/fortress. I agree it makes sence
to put all teh efforts in one Container Merlin, but then we should make sure
there is some kind of back-ward compatibility or wasy way to migrate to
Merlin. Otherwise Merlin will not sell.
----- Original Message -----
From: "Shash Chatterjee" <sh...@badfw.org>
Newsgroups: gmane.comp.jakarta.avalon.devel
Sent: Friday, April 09, 2004 7:43 AM
Subject: Re: Is the Fortress Direction Official?
>
> >> I know that Avalon has decided to focus on Merlin. I have no problems
> >> with that, and I wish you all the best in that endeavor. I thought
> >> that the exact direction of Fortress was still up in the air--beyond
> >> no longer supporting it.
> >>
> >> If that is the case, I would like to host it over on D-Haven, or
> >> perhaps something like it that is compatible. While I know there
> >> should be no issue with the latter course, the first one does require
> >> a "buyout" so to speak with Avalon.
> >
> >
> > anyone talk to Shash yet? Keelframework being one of the big fortress
> > users, his thoughts would be valuable :-D
> >
>
> Since when did users matter? :-)
> And, better yet, since when did the original developers matter?
>
> Keel definitely derives a big benefit from Fortress, and to me it feels
> "just right". I will definitely do what it takes to keep Fortress alive.
> D-haven hosting works for me, particularly since Berin has never, ever
> shown any interest in keeping Fortress alive :-). I think the Keel
> community would welcome the CVS hosting of Fortress in Keel also, if
> that is what needs to be done. However, as Jaaron has suggested,
> keeping Fortress under the Apache umbrella (as long as Berin, Peter, Leo
> **2, and other original authors of the framework have authority over it)
> makes a lot of sense; let us not underestimate the value of the Apache
> name: the original authors deserved that label and support, and should
> continue to do so.
>
> As I said in my earlier post, in response to Niclas' note about the IRC
> log, I am concerned that one implementation (even though it is Avalon's
> own) should drive the interface (framework) that should drive *all*
> implementations. I think that is purely asinine! If the interfaces
> don't change, and it is only about meta-data...then I'd be less
> concerned. We and a lot of other folks have developed a lot of code
> based on those interfaces. We shouldn't have to unnecessarily change a
> single line of code to keep using the INTERFACES, whether or not
> Fortress is forked; Apache and Avalon owes us that much.
>
> Overall, I think what is happening in Avalon is completely
> bass-ackwards! Here we have an Apache Avalon interface that is stable,
> implemented by three mature containers (ECM, Phoenix, Fortress) and
> one getting mature but evolving (Merlin), in use by two superbly
> successful Apache projects (Cocoon and James). We have most of the
> original developers behind that. That to me is the legitimate legacy
> worthy of the Avalon name. Yet, all of that proven technology is being
> frozen or forced to fork, most of the original developers are quitting
> in disgust, while completely unproven stuff (as of yet) is being given
> the mantel and the Apache/Avalon name. Go figure. I thought only Leo's
> initials had LSD in it!
>
> Leo, Berin, or even the Avalon PMC....anybody that is listening. What
> do we need to do to a) get ECM, Fortress, Phoenix, Loom, Jcontainer,
> Plexus and other containers using a common interface banded together? b)
> Can we start a mailing list with the known interested folks? c) I don't
> understand the beaureaucracy, what are our alternatives in taking our
> complaint and concerns outside Avalon PMC and to a higher body within
> Apache? In other words, what can users do to get their voices heard?
>
> Shash
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Is the Fortress Direction Official?
Posted by Leo Simons <ls...@jicarilla.org>.
Stephen McConnell wrote:
> Carsten Ziegeler wrote:
>
>> I would like
>> to keep the current package names for compatibility. I guess
>> if Fortress moves out of Apache this isn't possible.
>
> It it moves outside of Avalon it isn't possible either.
with the new 2.0 license, it is, even if code moves out of the ASF:
"6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file."
such permission can now be granted in a seperate agreement between the
ASF and a third party without being in violation of the actual license.
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
Component Community -- http://componentplanet.org/
Component Glue -- http://jicarilla.org/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Is the Fortress Direction Official?
Posted by Stephen McConnell <mc...@apache.org>.
Carsten Ziegeler wrote:
> I personally would prefer if we could keep Fortress somewhere at
> Apache. Apart from other things (visibility etc.), I would like
> to keep the current package names for compatibility. I guess
> if Fortress moves out of Apache this isn't possible.
It it moves outside of Avalon it isn't possible either. The Avalon PMC
is responsible for the content in the org.apache.avalon and
org.apache.excalibur namespace - period.
> And I don't see a real problem having it at Avalon if
> we clearly indicate that the "official" Avalon container is
> Merlin bla bla.
Agreed.
As far as I am concerned the entire subject of "where should Fortress
go" is completely academic. There is still work needed in getting the
fortress suite up to spec. in terms of build, gump, etc. Independently
of that anyone can fork the code base to anywhere - but reality is that
the codebase is getting attention from the yourself and the core
developers - and anything outside of Avalon is *not* going to get the
same attention in the short term.
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Is the Fortress Direction Official?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
I personally would prefer if we could keep Fortress somewhere at
Apache. Apart from other things (visibility etc.), I would like
to keep the current package names for compatibility. I guess
if Fortress moves out of Apache this isn't possible.
And I don't see a real problem having it at Avalon if
we clearly indicate that the "official" Avalon container is
Merlin bla bla.
Anyways, as long as I have commit access to the new home, I don't
care that much about the place.
Carsten
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Leo Simons
> Sent: Friday, April 09, 2004 9:32 AM
> To: dev@avalon.apache.org
> Subject: Re: Is the Fortress Direction Official?
>
> Shash Chatterjee wrote:
> > Leo, Berin, or even the Avalon PMC....anybody that is
> listening. What
> > do we need to do to a) get ECM, Fortress, Phoenix, Loom,
> Jcontainer,
> > Plexus and other containers using a common interface banded
> together?
>
> I think the only fair answer is that no-one knows. I will
> assert that the chances for such a thing succeeding are
> exceedingly small though.
>
> > b) Can we start a mailing list with the known interested folks?
>
> of course we can! Anyone can start a mailing list about anything.
> Getting people to subscribe to it and talk about stuff is the
> hard part.
>
> > c) I don't
> > understand the beaureaucracy, what are our alternatives in
> taking our
> > complaint and concerns outside Avalon PMC and to a higher
> body within
> > Apache? In other words, what can users do to get their voices heard?
>
> very simple: the first thing to do is to post e-mail to this
> list. The second place to go (if you want the conversation to
> be private) is pmc@avalon.apache.org. Several people from
> "higher bodies" within the ASF are also listening there.
>
> You can also send e-mail to Aaron Farr (the PMC chair) or the
> ASF board.
> Aaron would probably start a discussion of your e-mail on the
> avalon PMC list. The ASF board is very unlikely to do
> anything but refer you back to the Avalon PMC. The ASF
> projects are self-managing. Just about the only other thing I
> can imagine them actually /doing/ (if everyone complains loud
> enough) is disbanding the avalon project completely, which
> will only make sure that your voice *won't* get heard. They
> are certainly not going to tell avalon what its technical
> direction should be.
>
> --
> cheers,
>
> - Leo Simons
>
> --------------------------------------------------------------
> ---------
> Weblog -- http://leosimons.com/
> Component Community -- http://componentplanet.org/
> Component Glue -- http://jicarilla.org/
> --------------------------------------------------------------
> ---------
> "We started off trying to set up a small anarchist community, but
> people wouldn't obey the rules."
> --
> Alan Bennett
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org For
> additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Is the Fortress Direction Official?
Posted by Leo Simons <ls...@jicarilla.org>.
Shash Chatterjee wrote:
> Leo, Berin, or even the Avalon PMC....anybody that is listening. What
> do we need to do to a) get ECM, Fortress, Phoenix, Loom, Jcontainer,
> Plexus and other containers using a common interface banded together?
I think the only fair answer is that no-one knows. I will assert that
the chances for such a thing succeeding are exceedingly small though.
> b) Can we start a mailing list with the known interested folks?
of course we can! Anyone can start a mailing list about anything.
Getting people to subscribe to it and talk about stuff is the hard part.
> c) I don't
> understand the beaureaucracy, what are our alternatives in taking our
> complaint and concerns outside Avalon PMC and to a higher body within
> Apache? In other words, what can users do to get their voices heard?
very simple: the first thing to do is to post e-mail to this list. The
second place to go (if you want the conversation to be private) is
pmc@avalon.apache.org. Several people from "higher bodies" within the
ASF are also listening there.
You can also send e-mail to Aaron Farr (the PMC chair) or the ASF board.
Aaron would probably start a discussion of your e-mail on the avalon PMC
list. The ASF board is very unlikely to do anything but refer you back
to the Avalon PMC. The ASF projects are self-managing. Just about the
only other thing I can imagine them actually /doing/ (if everyone
complains loud enough) is disbanding the avalon project completely,
which will only make sure that your voice *won't* get heard. They are
certainly not going to tell avalon what its technical direction should be.
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
Component Community -- http://componentplanet.org/
Component Glue -- http://jicarilla.org/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Is the Fortress Direction Official?
Posted by Shash Chatterjee <sh...@badfw.org>.
>> I know that Avalon has decided to focus on Merlin. I have no problems
>> with that, and I wish you all the best in that endeavor. I thought
>> that the exact direction of Fortress was still up in the air--beyond
>> no longer supporting it.
>>
>> If that is the case, I would like to host it over on D-Haven, or
>> perhaps something like it that is compatible. While I know there
>> should be no issue with the latter course, the first one does require
>> a "buyout" so to speak with Avalon.
>
>
> anyone talk to Shash yet? Keelframework being one of the big fortress
> users, his thoughts would be valuable :-D
>
Since when did users matter? :-)
And, better yet, since when did the original developers matter?
Keel definitely derives a big benefit from Fortress, and to me it feels
"just right". I will definitely do what it takes to keep Fortress alive.
D-haven hosting works for me, particularly since Berin has never, ever
shown any interest in keeping Fortress alive :-). I think the Keel
community would welcome the CVS hosting of Fortress in Keel also, if
that is what needs to be done. However, as Jaaron has suggested,
keeping Fortress under the Apache umbrella (as long as Berin, Peter, Leo
**2, and other original authors of the framework have authority over it)
makes a lot of sense; let us not underestimate the value of the Apache
name: the original authors deserved that label and support, and should
continue to do so.
As I said in my earlier post, in response to Niclas' note about the IRC
log, I am concerned that one implementation (even though it is Avalon's
own) should drive the interface (framework) that should drive *all*
implementations. I think that is purely asinine! If the interfaces
don't change, and it is only about meta-data...then I'd be less
concerned. We and a lot of other folks have developed a lot of code
based on those interfaces. We shouldn't have to unnecessarily change a
single line of code to keep using the INTERFACES, whether or not
Fortress is forked; Apache and Avalon owes us that much.
Overall, I think what is happening in Avalon is completely
bass-ackwards! Here we have an Apache Avalon interface that is stable,
implemented by three mature containers (ECM, Phoenix, Fortress) and
one getting mature but evolving (Merlin), in use by two superbly
successful Apache projects (Cocoon and James). We have most of the
original developers behind that. That to me is the legitimate legacy
worthy of the Avalon name. Yet, all of that proven technology is being
frozen or forced to fork, most of the original developers are quitting
in disgust, while completely unproven stuff (as of yet) is being given
the mantel and the Apache/Avalon name. Go figure. I thought only Leo's
initials had LSD in it!
Leo, Berin, or even the Avalon PMC....anybody that is listening. What
do we need to do to a) get ECM, Fortress, Phoenix, Loom, Jcontainer,
Plexus and other containers using a common interface banded together? b)
Can we start a mailing list with the known interested folks? c) I don't
understand the beaureaucracy, what are our alternatives in taking our
complaint and concerns outside Avalon PMC and to a higher body within
Apache? In other words, what can users do to get their voices heard?
Shash
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Is the Fortress Direction Official?
Posted by Shash Chatterjee <sh...@badfw.org>.
>> I know that Avalon has decided to focus on Merlin. I have no problems
>> with that, and I wish you all the best in that endeavor. I thought
>> that the exact direction of Fortress was still up in the air--beyond
>> no longer supporting it.
>>
>> If that is the case, I would like to host it over on D-Haven, or
>> perhaps something like it that is compatible. While I know there
>> should be no issue with the latter course, the first one does require
>> a "buyout" so to speak with Avalon.
>
>
> anyone talk to Shash yet? Keelframework being one of the big fortress
> users, his thoughts would be valuable :-D
>
Since when did users matter? :-)
And, better yet, since when did the original developers matter?
Keel definitely derives a big benefit from Fortress, and to me it feels
"just right". I will definitely do what it takes to keep Fortress alive.
D-haven hosting works for me, particularly since Berin has never, ever
shown any interest in keeping Fortress alive :-). I think the Keel
community would welcome the CVS hosting of Fortress in Keel also, if
that is what needs to be done. However, as Jaaron has suggested,
keeping Fortress under the Apache umbrella (as long as Berin, Peter, Leo
**2, and other original authors of the framework have authority over it)
makes a lot of sense; let us not underestimate the value of the Apache
name: the original authors deserved that label and support, and should
continue to do so.
As I said in my earlier post, in response to Niclas' note about the IRC
log, I am concerned that one implementation (even though it is Avalon's
own) should drive the interface (framework) that should drive *all*
implementations. I think that is purely asinine! If the interfaces
don't change, and it is only about meta-data...then I'd be less
concerned. We and a lot of other folks have developed a lot of code
based on those interfaces. We shouldn't have to unnecessarily change a
single line of code to keep using the INTERFACES, whether or not
Fortress is forked; Apache and Avalon owes us that much.
Overall, I think what is happening in Avalon is completely
bass-ackwards! Here we have an Apache Avalon interface that is stable,
implemented by three mature containers (ECM, Phoenix, Fortress) and
one getting mature but evolving (Merlin), in use by two superbly
successful Apache projects (Cocoon and James). We have most of the
original developers behind that. That to me is the legitimate legacy
worthy of the Avalon name. Yet, all of that proven technology is being
frozen or forced to fork, most of the original developers are quitting
in disgust, while completely unproven stuff (as of yet) is being given
the mantel and the Apache/Avalon name. Go figure. I thought only Leo's
initials had LSD in it!
Leo, Berin, or even the Avalon PMC....anybody that is listening. What
do we need to do to a) get ECM, Fortress, Phoenix, Loom, Jcontainer,
Plexus and other containers using a common interface banded together? b)
Can we start a mailing list with the known interested folks? c) I don't
understand the beaureaucracy, what are our alternatives in taking our
complaint and concerns outside Avalon PMC and to a higher body within
Apache? In other words, what can users do to get their voices heard?
Shash
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Is the Fortress Direction Official?
Posted by Leo Simons <ls...@jicarilla.org>.
Berin Loritsch wrote:
> I know that Avalon has decided to focus on Merlin. I have no problems
> with that, and I wish you all the best in that endeavor. I thought that
> the exact direction of Fortress was still up in the air--beyond no
> longer supporting it.
>
> If that is the case, I would like to host it over on D-Haven, or perhaps
> something like it that is compatible. While I know there should be no
> issue with the latter course, the first one does require a "buyout" so
> to speak with Avalon.
anyone talk to Shash yet? Keelframework being one of the big fortress
users, his thoughts would be valuable :-D
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
Component Community -- http://componentplanet.org/
Component Glue -- http://jicarilla.org/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Is the Fortress Direction Official?
Posted by Alex Karasulu <ao...@bellsouth.net>.
Berin,
I recommended in our IRC meeting that Avalon give Fortress to D-Haven if
D-Haven will take her. I'm a +1 for this thinking Fortress will be better
off there.
Alex
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Berin Loritsch
> Sent: Thursday, April 08, 2004 12:57 PM
> To: dev@avalon.apache.org
> Subject: Is the Fortress Direction Official?
>
> I know that Avalon has decided to focus on Merlin. I have no problems
> with that, and I wish you all the best in that endeavor. I thought that
> the exact direction of Fortress was still up in the air--beyond no
> longer supporting it.
>
> If that is the case, I would like to host it over on D-Haven, or perhaps
> something like it that is compatible. While I know there should be no
> issue with the latter course, the first one does require a "buyout" so
> to speak with Avalon.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org