You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Paul Hammant <Pa...@yahoo.com> on 2002/01/07 00:35:16 UTC
[Vote] ARMI to move
Folks,
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/armi/
I have done a lot of work on ARMI and think it is time for me to ask
committers to vote for a move of this tool from 'sandbox' in to the main
CVS tree. It also needs a rename (ARMI is already used in the context
of Java by another academic team). Please do not think of this as a
full replacement for RMI. It is merely an alternative that bizarely
might be most useful (to Avalon) entirely inside one VM.
With respect to the rename, I think FacadePublisher gives the most
meaning, but is not snappy.
Now, I guess I have no vote myself as I am only a committer to 'soapbox'
but I would be interested to know if know the outcome of a vote from
those that do......
Two votes:
1) for ARMI being renamed to FacadePublisher (or other)
2) for migrating from 'soapbox' to main CVS.
Thanks in advance....
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI to move
Posted by Jeff Turner <je...@socialchange.net.au>.
On Sun, Jan 06, 2002 at 11:35:16PM +0000, Paul Hammant wrote:
> Folks,
...
> 2) for migrating from 'soapbox' to main CVS.
+1
It will be used in Avalon projects, but since it's generic, better here
than Avalon CVS.
--Jeff
>
> Thanks in advance....
>
> Regards,
>
> - Paul H
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI to move
Posted by Paul Hammant <Pa...@yahoo.com>.
So far we have one vote placed. I am pleased to say it is in favour of
ARMI (probably to be repackaged as AltRMI) moving to regular Commons CVS.
Anyone else case to cast a vote?
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI to move
Posted by Dirk Verbeeck <di...@pandora.be>.
My vote: +1 to add it to commons
If you think the API is stable enough to give it to the public, go for
it
We have a place for reusable components and that is commons.
But I understand if you want to go back to your Avalon roots.
These discussions are common on commons ;-)
Do we use this component or that other one; accept this or that
style/component/coding method. Don't listen too much to those
discussions.
The bottom line is as always, is the code good enough ? The answer must
be yes otherwise it wouldn't be accepted into Avalon.
For the support part, maybe you can ask some Avalon committers for their
unofficial support / votes.
New components must get a chance in the real world (outside the sandbox)
and if the code is used in Avalon there will be somebody the support it.
Dirk Verbeeck
Paul Hammant wrote:
>
> Folks,
>
> > 2) Take it back to excalibur and just shove it in (where it becomes a
> > tool amngst many that already have a community).
>
> Actually I don't think this is so rude after all. It is not like ARMI
> was commissioned or solicited for. I'll go back to where I came from,
> with the official vote being one for and one against.
>
> - Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI as Commons package
Posted by robert burrell donkin <ro...@mac.com>.
On Wednesday, January 9, 2002, at 05:19 PM, Paul Hammant wrote:
> Ted,
>
>> I believe that its possible that not enough of us understand the
>> background of the ARMI codebase.
>> There's a lot going on, and it can be helpful to spoonfeed us old,
>> feeble, and bandwith-challenged folk =:0)
>>
> Primarily it is an alterative to RMI. It exports* method calls to other
> processes. It does not need to enforce inheritace of a base interface
> (refer 'Remote') not tack on exceptions to the throws of each method
> exported (refer 'RemoteException'). As such in can export 'normal'
> interfaces. Even one the original authors throught not remote accesible.
> Now this is not my invention. A buddy tells me that .NET has a 'hassle
> free' method exporting feature. Graham Glass did it first with Glue.
> Glue is The-Mind-Electric's interface exporter over SOAP. It is truly
> excellent stuff. Incidentally Graham is the original author of the
> legendary ObjectSpace Voyager app-server ( if anyone can remember back to
> 96).
>
> * In the PROPOSAL.txt document in CVS, there are fuller details
> especially the multiple transports. The most useful is barely a
> transport at all - it is a Pipe implementation that is of direct use to
> Avalon (and probably nothing else) as it transport method calls between
> classloader leaves in the same VM.
>
>> Given the other tidbits that have come up in this thread, I would now
>> toss my binding
>> +1
>>
> I understand that the move cannot happen before it's use anywhere. Given
> that rule (which is fair I guess) I might be inclined to stay here.
> However I suspect I will be voted down at any stage, because people just
> plain do not see the need. This makes me feel essentially unwelcome and
> that I should just go back to Avalon where I am welcome.
>
>> It's important to understand that the sandbox is open to any Jakarta
>> committer, and it's helpful to make an actual proposal, as detailed in
>> the Commons charter, so that we know what's what.
>>
>> If the component is also going to be useful to the Avalon codebase, then
>> I would say it has a high potential of being supported in the longterm,
>> and would be a welcome addition.
>>
> Thanks for taking time to pen a weighty reply. I am still unsure whether
> I am wasting my time here... There have been 100 postings on politics and
> 10 on AltRMI (nee ARMI), mostly just me talking to myself or defending a
> position. This group is way more political than Avalon. Anyway, thanks
> for the lengthy and concilliatory reply - you're a worthy Apache dude.
> Peace n Love n all that....
i'm sorry that you feel this way.
the problem is that here in the commons everything takes much longer. IMHO
it's not so much that the commons is political - it's more a case of
people trying to figure out how the commons can be made to work
effectively. we'll all still learning here - and that is often noisy and
sometimes painful.
i really would have liked to have the chance to take a look at ARMI and to
make a few comments (even if i ended up only saying "well done") before i
cast my vote but i really haven't had the time. (i think of casting a +1
for a new sub project as meaning that i'm willing to undertake basic
project maintenance and field user questions when there's no one else who'
s more able available.)
you've been pretty active and i certainly think you've got the energy to
push forward a solo project but i'd feel much happier if ARMI had one or
two more committers who are willing and able to field questions about ARMI
and who you're happy about reviewing and committing patches when you're
not around.
i also agree with scott's point that choosing a new name should have come
before pushing for the commons vote.
"more haste, less speed"
<sigh> +1 </sigh>
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI as Commons package +1
Posted by Paul Hammant <Pa...@yahoo.com>.
Ted,
>I believe that its possible that not enough of us understand the
>background of the ARMI codebase.
>
>There's a lot going on, and it can be helpful to spoonfeed us old,
>feeble, and bandwith-challenged folk =:0)
>
Primarily it is an alterative to RMI. It exports* method calls to other
processes. It does not need to enforce inheritace of a base interface
(refer 'Remote') not tack on exceptions to the throws of each method
exported (refer 'RemoteException'). As such in can export 'normal'
interfaces. Even one the original authors throught not remote
accesible. Now this is not my invention. A buddy tells me that .NET
has a 'hassle free' method exporting feature. Graham Glass did it first
with Glue. Glue is The-Mind-Electric's interface exporter over SOAP.
It is truly excellent stuff. Incidentally Graham is the original
author of the legendary ObjectSpace Voyager app-server ( if anyone can
remember back to 96).
* In the PROPOSAL.txt document in CVS, there are fuller details
especially the multiple transports. The most useful is barely a
transport at all - it is a Pipe implementation that is of direct use to
Avalon (and probably nothing else) as it transport method calls between
classloader leaves in the same VM.
>Given the other tidbits that have come up in this thread, I would now
>toss my binding
>
>+1
>
I understand that the move cannot happen before it's use anywhere.
Given that rule (which is fair I guess) I might be inclined to stay
here. However I suspect I will be voted down at any stage, because
people just plain do not see the need. This makes me feel essentially
unwelcome and that I should just go back to Avalon where I am welcome.
>It's important to understand that the sandbox is open to any Jakarta
>committer, and it's helpful to make an actual proposal, as detailed in
>the Commons charter, so that we know what's what.
>
>If the component is also going to be useful to the Avalon codebase, then
>I would say it has a high potential of being supported in the longterm,
>and would be a welcome addition.
>
Thanks for taking time to pen a weighty reply. I am still unsure
whether I am wasting my time here... There have been 100 postings on
politics and 10 on AltRMI (nee ARMI), mostly just me talking to myself
or defending a position. This group is way more political than Avalon.
Anyway, thanks for the lengthy and concilliatory reply - you're a
worthy Apache dude. Peace n Love n all that....
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI as Commons package +1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/9/02 12:15 PM, "bayard@generationjava.com" <ba...@generationjava.com>
wrote:
> I'm a +1 on it being in Commons.
>
> It's an itch that sounds very generic and reusable. Seems a good commons
> to me. I think the only question is whether something should move from the
> sandbox to commons without really gaining much peer review/use.
>
> However, it sounds as though Avalon will have a dependency on it, in which
> case, should any Jakarta project that isn't in a sandbox be dependant on a
> sandboxed project?
That's up to them, isn't it? The upside is that it motivates them to send a
crew over to help out :)
>
> The Utils project in the sandbox is a project from which many projects
> grow, but it also has classes that belong in it. They're very usable but
> should other projects be dependent on them?
>
> It seems that the obvious solutions conflict with each other.
>
> Bay
>
> On Wed, 9 Jan 2002, Ted Husted wrote:
>
>> Paul,
>>
>> I believe that its possible that not enough of us understand the
>> background of the ARMI codebase.
>>
>> There's a lot going on, and it can be helpful to spoonfeed us old,
>> feeble, and bandwith-challenged folk =:0)
>>
>> Given the other tidbits that have come up in this thread, I would now
>> toss my binding
>>
>> +1
>>
>> It's important to understand that the sandbox is open to any Jakarta
>> committer, and it's helpful to make an actual proposal, as detailed in
>> the Commons charter, so that we know what's what.
>>
>> If the component is also going to be useful to the Avalon codebase, then
>> I would say it has a high potential of being supported in the longterm,
>> and would be a welcome addition.
>>
>> -- Ted Husted, Husted dot Com, Fairport NY USA.
>> -- Building Java web applications with Struts.
>> -- Tel +1 585 737-3463.
>> -- Web http://www.husted.com/struts/
>>
>>
>> Paul Hammant wrote:
>>>
>>> Folks,
>>>
>>>> 2) Take it back to excalibur and just shove it in (where it becomes a
>>>> tool amngst many that already have a community).
>>>
>>> Actually I don't think this is so rude after all. It is not like ARMI
>>> was commissioned or solicited for. I'll go back to where I came from,
>>> with the official vote being one for and one against.
>>>
>>> - Paul H
>>>
>>> --
>>> To unsubscribe, e-mail:
>>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
>>> <ma...@jakarta.apache.org>
>>
>> --
>> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>> For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Now what do we do?"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI as Commons package +1
Posted by ba...@generationjava.com.
I'm a +1 on it being in Commons.
It's an itch that sounds very generic and reusable. Seems a good commons
to me. I think the only question is whether something should move from the
sandbox to commons without really gaining much peer review/use.
However, it sounds as though Avalon will have a dependency on it, in which
case, should any Jakarta project that isn't in a sandbox be dependant on a
sandboxed project?
The Utils project in the sandbox is a project from which many projects
grow, but it also has classes that belong in it. They're very usable but
should other projects be dependent on them?
It seems that the obvious solutions conflict with each other.
Bay
On Wed, 9 Jan 2002, Ted Husted wrote:
> Paul,
>
> I believe that its possible that not enough of us understand the
> background of the ARMI codebase.
>
> There's a lot going on, and it can be helpful to spoonfeed us old,
> feeble, and bandwith-challenged folk =:0)
>
> Given the other tidbits that have come up in this thread, I would now
> toss my binding
>
> +1
>
> It's important to understand that the sandbox is open to any Jakarta
> committer, and it's helpful to make an actual proposal, as detailed in
> the Commons charter, so that we know what's what.
>
> If the component is also going to be useful to the Avalon codebase, then
> I would say it has a high potential of being supported in the longterm,
> and would be a welcome addition.
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Building Java web applications with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
>
>
> Paul Hammant wrote:
> >
> > Folks,
> >
> > > 2) Take it back to excalibur and just shove it in (where it becomes a
> > > tool amngst many that already have a community).
> >
> > Actually I don't think this is so rude after all. It is not like ARMI
> > was commissioned or solicited for. I'll go back to where I came from,
> > with the official vote being one for and one against.
> >
> > - Paul H
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI as Commons package +1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/9/02 11:36 AM, "Ted Husted" <hu...@apache.org> wrote:
> Paul,
>
> I believe that its possible that not enough of us understand the
> background of the ARMI codebase.
>
> There's a lot going on, and it can be helpful to spoonfeed us old,
> feeble, and bandwith-challenged folk =:0)
>
> Given the other tidbits that have come up in this thread, I would now
> toss my binding
>
> +1
Ted - I have come to understand you as a stickler for rules and order (among
other positive qualities :)
A related thread is discussing the fact that the proposal doesn't even
satisfy the rules that you took the time to record for us and post...
>
> It's important to understand that the sandbox is open to any Jakarta
> committer, and it's helpful to make an actual proposal, as detailed in
> the Commons charter, so that we know what's what.
It's not 'helpful'. Isn't 'required' the word you are looking for?
> If the component is also going to be useful to the Avalon codebase, then
> I would say it has a high potential of being supported in the longterm,
> and would be a welcome addition.
Yes - that I agree with.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI as Commons package +1
Posted by Ted Husted <hu...@apache.org>.
Paul,
I believe that its possible that not enough of us understand the
background of the ARMI codebase.
There's a lot going on, and it can be helpful to spoonfeed us old,
feeble, and bandwith-challenged folk =:0)
Given the other tidbits that have come up in this thread, I would now
toss my binding
+1
It's important to understand that the sandbox is open to any Jakarta
committer, and it's helpful to make an actual proposal, as detailed in
the Commons charter, so that we know what's what.
If the component is also going to be useful to the Avalon codebase, then
I would say it has a high potential of being supported in the longterm,
and would be a welcome addition.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
Paul Hammant wrote:
>
> Folks,
>
> > 2) Take it back to excalibur and just shove it in (where it becomes a
> > tool amngst many that already have a community).
>
> Actually I don't think this is so rude after all. It is not like ARMI
> was commissioned or solicited for. I'll go back to where I came from,
> with the official vote being one for and one against.
>
> - Paul H
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Vote] ARMI to move
Posted by Paulo Gaspar <pa...@krankikom.de>.
IMO, being a common use component (not Avalon specific) you should push
it here even if you have to call for the support of the other Avalon
committers.
As far as I understand, that is what the Struts guys are doing and I
think that they are damn RIGHT! That promotes code reuse.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Sent: Wednesday, January 09, 2002 11:10 AM
>
>
> Folks,
>
> > 2) Take it back to excalibur and just shove it in (where it becomes a
> > tool amngst many that already have a community).
>
> Actually I don't think this is so rude after all. It is not like ARMI
> was commissioned or solicited for. I'll go back to where I came from,
> with the official vote being one for and one against.
>
> - Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI to move
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/9/02 5:09 AM, "Paul Hammant" <Pa...@yahoo.com> wrote:
> Folks,
>
>> 2) Take it back to excalibur and just shove it in (where it becomes a
>> tool amngst many that already have a community).
>
> Actually I don't think this is so rude after all. It is not like ARMI
> was commissioned or solicited for. I'll go back to where I came from,
> with the official vote being one for and one against.
There's no official vote from me...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI to move
Posted by Paul Hammant <Pa...@yahoo.com>.
Folks,
> 2) Take it back to excalibur and just shove it in (where it becomes a
> tool amngst many that already have a community).
Actually I don't think this is so rude after all. It is not like ARMI
was commissioned or solicited for. I'll go back to where I came from,
with the official vote being one for and one against.
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI to move
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
I am going to go through these in order - I looked ahead and am fascinated
at what the process has become.
Note that is really my interest - while I know nothing of you or the project
yet, you are spoken highly of...
On 1/9/02 4:17 AM, "Paul Hammant" <Pa...@yahoo.com> wrote:
> Geir,
>
>>>> Geir :
>>>> Don't you need more active committers?
>>>>
>>> Some could argue that. Is that a -1 for you then? :-)
>>>
>>
>> If you'd prefer, sure.
>>
>
> I don't of course, just trying tio elicit a vote :-)
>
>> The point is that we in the midst of a large, active discussion in part
>> about how the community is being shaped by adding more and more projects to
>> jakarta, and how some strongly feel that it's a shame that we can't get
>> people to adhere to 'community conventions'. (Which I personally feel can
>> be too loosely defined... But anyway...)
>>
>> In this case, it's not even a guideline of commons, but one of the rules. I
>> don't think we should be so flip about it.
>>
>> The point of the sandbox is to build/introduce something and see if it as a
>> project can get momentum, build a community, get a clear picture if there is
>> enough interest behind something to bring to Commons with the expectation of
>> success towards a release, not just a 'dressing room...'
>>
>
> I've been watching the discussions, It's all good debate. I'm guilty
> of developing something from start to completion (more or less) in about
> two weeks *without* a community. Now I was going to do it in
> Avalon-Excalibur but then we recieved an invitation to move some widely
> re-usable stuff into Commons. I'm faced with two rude options:
>
> 1) Bring over some Avalon committers and make a community for ARMI.
> i.e. gerrymandering.
To me, that's cool, if they are really interested. If not, and you are just
getting two names to throw on there, then yes, gerrymandering is indeed a
good word for it - you can understand why that¹s against the spirit of the
commons rules.
If it's not, then we should simply alter the rule, as it serves no purpose.
> 2) Take it back to excalibur mad just shove it in (where it becomes a
> tool amngst many that already have a community).
That could work too.
> As soon as it is bedded in somewhere permanent, I'll be firing more
> components into Avalon-Cornerstone that uses it for general reuse. I'll
> then change Avalon-Cornserstone/apps/ftpserver and apps/AvalonDB to
> directly use those 'blocks' If it works well with these two, I'll make
> representations to the JAMES team to do the same. I'm make some bsh
> scripts so that BeanShell can use it, then rest my weary fingers for a
> while. It, after a pause of some months, it proves to be working well
> Peter Donald (as I pester him) might consider it for an alternative
> Kernel for Avalon-Pheonix (alternate as in an extension of the current).
>
> Advise?
About Peter? I don't understand the man myself :)
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Be a giant. Take giant steps. Do giant things...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI to move
Posted by Paul Hammant <Pa...@yahoo.com>.
Geir,
>>>Geir :
>>>Don't you need more active committers?
>>>
>>Some could argue that. Is that a -1 for you then? :-)
>>
>
>If you'd prefer, sure.
>
I don't of course, just trying tio elicit a vote :-)
>The point is that we in the midst of a large, active discussion in part
>about how the community is being shaped by adding more and more projects to
>jakarta, and how some strongly feel that it's a shame that we can't get
>people to adhere to 'community conventions'. (Which I personally feel can
>be too loosely defined... But anyway...)
>
>In this case, it's not even a guideline of commons, but one of the rules. I
>don't think we should be so flip about it.
>
>The point of the sandbox is to build/introduce something and see if it as a
>project can get momentum, build a community, get a clear picture if there is
>enough interest behind something to bring to Commons with the expectation of
>success towards a release, not just a 'dressing room...'
>
I've been watching the discussions, It's all good debate. I'm guilty
of developing something from start to completion (more or less) in about
two weeks *without* a community. Now I was going to do it in
Avalon-Excalibur but then we recieved an invitation to move some widely
re-usable stuff into Commons. I'm faced with two rude options:
1) Bring over some Avalon committers and make a community for ARMI.
i.e. gerrymandering.
2) Take it back to excalibur mad just shove it in (where it becomes a
tool amngst many that already have a community).
As soon as it is bedded in somewhere permanent, I'll be firing more
components into Avalon-Cornerstone that uses it for general reuse. I'll
then change Avalon-Cornserstone/apps/ftpserver and apps/AvalonDB to
directly use those 'blocks' If it works well with these two, I'll make
representations to the JAMES team to do the same. I'm make some bsh
scripts so that BeanShell can use it, then rest my weary fingers for a
while. It, after a pause of some months, it proves to be working well
Peter Donald (as I pester him) might consider it for an alternative
Kernel for Avalon-Pheonix (alternate as in an extension of the current).
Advise?
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Project Organisation [ was Re: [Vote] ARMI to move ]
Posted by Ted Husted <hu...@apache.org>.
David Bullock wrote:
>
> In this email, I address two concerns:
>
> 1) policy for promoting commons-sandbox to commons
AFAIK, whether a codebase lives in the sandbox, or elsewhere, doesn't
matter. The same rules for creating a Commons package apply. A sandbox
package can be proposed to any Jakarta subproject (not just the
Commons).
See the Commons charter
http://jakarta.apache.org/commons/charter.html
If the codebase is maturing, and is ready to promote to the larger
community, you might consider a "Call for Volunteers" describing the
package, and what you see as its future direction.
My personal criteria is that since our codebases use Apache Software
Foundation resources, they should speak to the ASF mission, and be able
to "... exist beyond the participation of individual volunteers". So
it's important that there be a community of volunteers (however small)
behind a package, and that is has the potential of attracting other
volunteers if needed.
> 2) the general direction of Jakarta
The general direction of the Commons is always a good topic here :), but
the general direction of Jakarta is a better topic for the General list.
As Geir said, thoughtful comments are always welcome =:)
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Jakarta Project Organisation [ was Re: [Vote] ARMI to move ]
Posted by Vincent Massol <vm...@octo.com>.
David,
> -----Original Message-----
> From: David Bullock [mailto:dbullock@lisasoft.com]
> Sent: 09 January 2002 08:23
> To: Jakarta Commons Developers List
> Subject: Jakarta Project Organisation [ was Re: [Vote] ARMI to move ]
>
[snip]
> For example, at the time that J2EEUnit became Cactus, an
> alternative project, JUnitEE, existed. It did not cater to
> the testing of JSP's, but the architecture was much cleaner
> and simpler to use. There was no discussion at the time if
> Cactus' contorted multiple proxy idea was in fact the best way
> to get the job done. Someone just said, 'how about this?' and
> it got in!
>
You seem to know a bit about Cactus but obviously not enough ... :-). I
am the original creator and currently an active committer. I can tell
you that when Cactus was called J2EEUnit and hosted on sourceforge, I
tried several time to convince Jeff to merge forces (Jeff is the creator
of JUnitEE) but he preferred to stay separate. We exchanged a few emails
on the subject that I can forward to you if you're interested. Also,
recently, we re-opened the subject on the cactus mailing-list and I
tried again. We made some progress, as you can see on
http://jakarta.apache.org/cactus/howto_junitee.html. The result was that
it was decided with JUnitEE committers that Cactus users should view
JUnitEE as a Test Runner for Cactus (that executes on the server side as
a servlet).
> Nobody asked 'well, what does it really mean to try to run JUnit
> tests in this environment', and identify facts like that there is no
> way to use the ServletContext's log stream from within a test-case
> even if you write your own TestRunner.
Are you so sure ? Have you tried Cactus ? :-)
http://jakarta.apache.org/cactus/javadoc/servlet22/org/apache/cactus/ser
ver/AbstractServletContextWrapper.html
> If someone had come up
> with a list of issues like this and then approached the JUnit authors
> with a proposal, maybe contributed, or maybe offered to adopt the
> codebase, who can doubt that testing of J2EE and other application
> with JUnit would be much simpler today
again, are you so sure ? I wonder if you've ever been subscribed to the
junit mailing-list ? Several persons have tried to change JUnit but its
original authors have always resisted change (maybe that was the right
way). Instead they encourage extensions to be written. Validmir
Bossicard is even writing a new version of "JUnit" called apricot for
the time being (can't find the url now but I can send it if you're
interested - or simply subscribe to the junit mailing list or look in
the archives).
> and Cactus a much less
> cumbersome and more popular product? Especially given that Jakarta
> is custodian of the javax.servlet.http API too!
>
Well, there is always room for improvements ! I welcome your ideas on
cactus-user@jakarta.apache.org. Feel free to participate. I can assure
you that we're trying very hard to make Cactus as easy and powerful to
use as possible.
See the goals page for Cactus and you'll see that one of the possible
long-term goal is to define a container SPI API for J2EE testing.
> As has been pointed out, it is up to volunteers to contribute their
> time and they cannot be *forced* to contribute in a particular way,
but
> that is no reason why the PMC cannot get volunteers to qualify and
> improve thier ideas, consider a bigger picture, before they get
> started coding. Most people will quite readily accept the
> challenge of a bigger picture, and you would probably get the
> same non-initiating volunteer base because it is still a 'famous'
> organisation to contribute to, and there is a genuine need for good
> J2EE testing software and many people like to not start from scratch
> by themselves.
I'm glad you recognize there is a need for J2EE testing ! :-)
Well, one *very* long-term goal of Cactus is to bring the addition of a
*standard* testing service to J2EE container by making it part of the
J2EE spec. ;-)
Do you want to help ?
>
>
> Guess that must be close to a dime? The exchange rate is pretty
> bad from this end ;-)
Well, I wouldn't give it $0.0 as you're not lucky and has picked the
wrong example to make your point ! ;-). Do some research in the future !
>
> cheers,
> David.
>
Cheers,
-Vincent
>
> --
> ----
> David Bullock - dbullock@lisasoft.com +61 4 0290 1228
> http://www.lisasoft.com/ (Architect) http://www.auug.org.au/
(President,
> SA)
> http://www.ajug.org.au/sajug/sa.html (Activist) Sun Cert'd Programmer
for
> Java 2
>
> "The key ingredients of success are a crystal-clear goal, a realistic
> attack plan to achieve that goal, and consistent, daily action to
reach
> that goal."
> Steve Maguire, "Debugging the Development Process".
>
>
> --
> To unsubscribe, e-mail: <mailto:commons-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-
> help@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Project Organisation [ was Re: [Vote] ARMI to move ]
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Good thoughtful post. Answer inline...
On 1/9/02 3:22 AM, "David Bullock" <db...@lisasoft.com> wrote:
> In this email, I address two concerns:
>
> 1) policy for promoting commons-sandbox to commons
> 2) the general direction of Jakarta
>
>
> 1) ON POLICY FOR COMMONS
>
> This is a general observation, and not made with respect to the ARMI
> proposal itself, but about project organisation at Jakarta.
>
> On Wed, 9 Jan 2002, Geir Magnusson Jr. wrote:
>
>> The point of the sandbox is to build/introduce something and see if it as a
>> project can get momentum, build a community, get a clear picture if there is
>> enough interest behind something to bring to Commons with the expectation of
>> success towards a release, not just a 'dressing room...'
>
> The point about commons not being a 'dressing room' is good.
>
> However, there is an obvious tension:
>
> 1. projects are encouraged to componentise and make facilities
> reusable
>
Yes - that was one of the intents in founding Comons
> 2. 'baby components' start in commons-sandbox, and don't get promoted
> to maturity in commons until there are 'enough' committers.
Hm. Nothing to disagree with there, but not sure of why it's been said
>
> 3. projects should only rely on mature components in commons
Yes (but we don't) :)
> So it seems like the path to spinning a good idea into the commons is
> going to mean maintaining 2 separate codebases for the same idea for a
> while ( one in the project, one in the sandbox ), until the comitter
> community catches up and it can become one codebase ( in the commons )?
Maybe.
For example, Digester et al from Struts came here, was sandboxed and grown,
and at the same time Struts depended upon what it still head, making the
switch later.
Now, nothing states (afaik) that code *must* go into the sandbox first (it's
not a dressing room :)
For example, you could propose that component X from Jakarta project Y is
made a commons component, and will be supported by committers A, B from Y
and also C from Z, and used by project Y & Z (this of course is great,
bridging projects Y and Z through shared code)
For something like that, I think that it doesn't have to go to the sandbox
as you have a few things going for it :
1) Support : it has a community of developers and users to support it ( from
Y, as it came from Y as well as the bonus add on from Z)
2) Reuse : It is getting > 1 Jakarta projects to use it (reuse good!)
3) Relevance : an existing project Y is already using it, and Z is saying
they will - it's therefore provably a relevant component. This of course
isn't required, else there could be no innovation, as the relevance of 'new
stuff' is often an insight by the original developer not seen by others
initally...
The combination of 1 & 2 supports the likelihood of success as a standalone
component.
> I don't think the right place to nip this cyclical dependency is to
> rush maybe-good ideas to premature 'maturity'. But maybe something
> else could change?
>
> Perhaps the maturity distinction could be based on:
>
> sandbox/immature: only 1 PROJECT using it
No - I don't support that - there could be something of wider usefulness -
for example, Velocity uses a popular parser generator, JavaCC, which is not
used by any other jakarta project....
> commons/mature: more than 1 project using it
>
> and constraint 3 relaxed?
>
> ( ie. maturity based on actual dependencies, rather than a raw count of
> comitters ... the support needed to ensure its continued existence is
> pretty much guaranteed if 2 projects actually *rely* on it, and it has
> proved its stripes in being reusable as soon as >1 project actually does
> use it ).
Not sure about that. Not disagreeing, but not sure. I believe that if
several projects depend on it (even 1) then you *should* be able to round up
3 committers that will support it from the get-go, so it shouldn't even *be*
a problem.
And I am not sure about this because I know personally I couldn't commit to
supporting every component that projects I work on depend on. Just not
enough time in the day. I mean, I could rubber stamp the requirement by
listing myself to get by the rule, but the spirit of the rule is important
here, not just the letter.
>
> This kind of policy makes for a 'commons' for genuine *components OF*
> top-level projects.
Yes - however I can see how you wouldn't want that requirement - for
example, I wouldn't hesitate for a second to support bringing something like
Poolman here to commons - it has a dedicated developer and user base, even
though no project here in Jakarta depends on it explicitly. Of course, you
would need to add to the outside component's community one (or more) Jakarta
committers to start...
>
> Maybe there is another kind of policy ( say, 'incubator' ) for aspiring
> top-level projects, and maybe the 'count of comitters' metric is more
> appropriate here.
>
Yes - but I will still argue the 'count of committers' shouldn't be a
problem at all if you have multiple projects already depending on something
- so there is no need for a variant to the rule.
> Of course, one would need separate CVS repositories for projects
> under each policy, to avoid confusion.
>
>
>
> 2) ON FOCUS and LEADERSHIP
>
> On another thread, there are some very loud yells of 'no better
> than sourceforge' and 'duplication!'
I am on that other thread :)
I openly support duplication - promotes innovation. I will admit to
worrying about the 'sourceforgification' of Jakarta.
>
> I personally think that Jakarta have been a little too lax in
> really qualifying their ideas. The criticism of duplication can
> apply not just intra-Jakarta but intra- the open-source community.
>
> [ I find some of the discussion quite amusing given this angle ]
>
> For example, at the time that J2EEUnit became Cactus, an
> alternative project, JUnitEE, existed. It did not cater to
> the testing of JSP's, but the architecture was much cleaner
> and simpler to use. There was no discussion at the time if
> Cactus' contorted multiple proxy idea was in fact the best way
> to get the job done. Someone just said, 'how about this?' and
> it got in!
>
> Nobody asked 'well, what does it really mean to try to run JUnit
> tests in this environment', and identify facts like that there is no
> way to use the ServletContext's log stream from within a test-case
> even if you write your own TestRunner. If someone had come up
> with a list of issues like this and then approached the JUnit authors
> with a proposal, maybe contributed, or maybe offered to adopt the
> codebase, who can doubt that testing of J2EE and other application
> with JUnit would be much simpler today and Cactus a much less
> cumbersome and more popular product? Especially given that Jakarta
> is custodian of the javax.servlet.http API too!
>
> As has been pointed out, it is up to volunteers to contribute their
> time and they cannot be *forced* to contribute in a particular way, but
> that is no reason why the PMC cannot get volunteers to qualify and
> improve thier ideas, consider a bigger picture, before they get
> started coding.
Yep.
Or as I would like, sharpen the focus - and work to make a place for things
that don't quite fit.
I won't belabor my views from general@ here.
> Most people will quite readily accept the
> challenge of a bigger picture, and you would probably get the
> same non-initiating volunteer base because it is still a 'famous'
> organisation to contribute to, and there is a genuine need for good
> J2EE testing software and many people like to not start from scratch
> by themselves.
>
>
> Guess that must be close to a dime? The exchange rate is pretty
> bad from this end ;-)
:)
> cheers,
> David.
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Now what do we do?"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Jakarta Project Organisation [ was Re: [Vote] ARMI to move ]
Posted by David Bullock <db...@lisasoft.com>.
In this email, I address two concerns:
1) policy for promoting commons-sandbox to commons
2) the general direction of Jakarta
1) ON POLICY FOR COMMONS
This is a general observation, and not made with respect to the ARMI
proposal itself, but about project organisation at Jakarta.
On Wed, 9 Jan 2002, Geir Magnusson Jr. wrote:
> The point of the sandbox is to build/introduce something and see if it as a
> project can get momentum, build a community, get a clear picture if there is
> enough interest behind something to bring to Commons with the expectation of
> success towards a release, not just a 'dressing room...'
The point about commons not being a 'dressing room' is good.
However, there is an obvious tension:
1. projects are encouraged to componentise and make facilities
reusable
2. 'baby components' start in commons-sandbox, and don't get promoted
to maturity in commons until there are 'enough' committers.
3. projects should only rely on mature components in commons
So it seems like the path to spinning a good idea into the commons is
going to mean maintaining 2 separate codebases for the same idea for a
while ( one in the project, one in the sandbox ), until the comitter
community catches up and it can become one codebase ( in the commons )?
I don't think the right place to nip this cyclical dependency is to
rush maybe-good ideas to premature 'maturity'. But maybe something
else could change?
Perhaps the maturity distinction could be based on:
sandbox/immature: only 1 PROJECT using it
commons/mature: more than 1 project using it
and constraint 3 relaxed?
( ie. maturity based on actual dependencies, rather than a raw count of
comitters ... the support needed to ensure its continued existence is
pretty much guaranteed if 2 projects actually *rely* on it, and it has
proved its stripes in being reusable as soon as >1 project actually does
use it ).
This kind of policy makes for a 'commons' for genuine *components OF*
top-level projects.
Maybe there is another kind of policy ( say, 'incubator' ) for aspiring
top-level projects, and maybe the 'count of comitters' metric is more
appropriate here.
Of course, one would need separate CVS repositories for projects
under each policy, to avoid confusion.
2) ON FOCUS and LEADERSHIP
On another thread, there are some very loud yells of 'no better
than sourceforge' and 'duplication!'
I personally think that Jakarta have been a little too lax in
really qualifying their ideas. The criticism of duplication can
apply not just intra-Jakarta but intra- the open-source community.
[ I find some of the discussion quite amusing given this angle ]
For example, at the time that J2EEUnit became Cactus, an
alternative project, JUnitEE, existed. It did not cater to
the testing of JSP's, but the architecture was much cleaner
and simpler to use. There was no discussion at the time if
Cactus' contorted multiple proxy idea was in fact the best way
to get the job done. Someone just said, 'how about this?' and
it got in!
Nobody asked 'well, what does it really mean to try to run JUnit
tests in this environment', and identify facts like that there is no
way to use the ServletContext's log stream from within a test-case
even if you write your own TestRunner. If someone had come up
with a list of issues like this and then approached the JUnit authors
with a proposal, maybe contributed, or maybe offered to adopt the
codebase, who can doubt that testing of J2EE and other application
with JUnit would be much simpler today and Cactus a much less
cumbersome and more popular product? Especially given that Jakarta
is custodian of the javax.servlet.http API too!
As has been pointed out, it is up to volunteers to contribute their
time and they cannot be *forced* to contribute in a particular way, but
that is no reason why the PMC cannot get volunteers to qualify and
improve thier ideas, consider a bigger picture, before they get
started coding. Most people will quite readily accept the
challenge of a bigger picture, and you would probably get the
same non-initiating volunteer base because it is still a 'famous'
organisation to contribute to, and there is a genuine need for good
J2EE testing software and many people like to not start from scratch
by themselves.
Guess that must be close to a dime? The exchange rate is pretty
bad from this end ;-)
cheers,
David.
--
----
David Bullock - dbullock@lisasoft.com +61 4 0290 1228
http://www.lisasoft.com/ (Architect) http://www.auug.org.au/ (President, SA)
http://www.ajug.org.au/sajug/sa.html (Activist) Sun Cert'd Programmer for Java 2
"The key ingredients of success are a crystal-clear goal, a realistic attack plan to achieve that goal, and consistent, daily action to reach that goal."
Steve Maguire, "Debugging the Development Process".
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI to move
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/8/02 2:16 AM, "Paul Hammant" <Pa...@yahoo.com> wrote:
>> Geir :
>> Don't you need more active committers?
> Some could argue that. Is that a -1 for you then? :-)
If you'd prefer, sure.
The point is that we in the midst of a large, active discussion in part
about how the community is being shaped by adding more and more projects to
jakarta, and how some strongly feel that it's a shame that we can't get
people to adhere to 'community conventions'. (Which I personally feel can
be too loosely defined... But anyway...)
In this case, it's not even a guideline of commons, but one of the rules. I
don't think we should be so flip about it.
The point of the sandbox is to build/introduce something and see if it as a
project can get momentum, build a community, get a clear picture if there is
enough interest behind something to bring to Commons with the expectation of
success towards a release, not just a 'dressing room...'
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI to move
Posted by Paul Hammant <Pa...@yahoo.com>.
Some could argue that. Is that a -1 for you then? :-)
>Don't you need more active committers?
>
-PH
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI to move
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/9/02 1:10 PM, "Martin Cooper" <ma...@tumbleweed.com> wrote:
>> Don't you need more active committers?
>
> Interesting question. My initial assumption was that, yes, that's what the
> rules say. However, on checking the Commons charter, it doesn't actually say
> how many committers are required for a package to be accepted (or if it
> does, I missed it). The Jakarta rules do, of course. Perhaps this is
> something we should define?
>
I think so - this issue is the motivation for me trying to get this
discussed. The Jakarta rules do apply here.
It appears though that no one except me cares about that little problem, so
it must be my misinterpretation of something, which I will go back and
review.
> The vote for acceptance, however, is well defined as a positive
> super-majority.
>
> --
> Martin Cooper
>
>
> ----- Original Message -----
> From: "Geir Magnusson Jr." <ge...@optonline.net>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Monday, January 07, 2002 7:50 PM
> Subject: Re: [Vote] ARMI to move
>
>
>> Don't you need more active committers?
>>
>>
>> On 1/6/02 6:35 PM, "Paul Hammant" <Pa...@yahoo.com> wrote:
>>
>>> Folks,
>>>
>>> http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/armi/
>>>
>>> I have done a lot of work on ARMI and think it is time for me to ask
>>> committers to vote for a move of this tool from 'sandbox' in to the main
>>> CVS tree. It also needs a rename (ARMI is already used in the context
>>> of Java by another academic team). Please do not think of this as a
>>> full replacement for RMI. It is merely an alternative that bizarely
>>> might be most useful (to Avalon) entirely inside one VM.
>>>
>>> With respect to the rename, I think FacadePublisher gives the most
>>> meaning, but is not snappy.
>>>
>>> Now, I guess I have no vote myself as I am only a committer to 'soapbox'
>>> but I would be interested to know if know the outcome of a vote from
>>> those that do......
>>>
>>> Two votes:
>>>
>>> 1) for ARMI being renamed to FacadePublisher (or other)
>>>
>>> 2) for migrating from 'soapbox' to main CVS.
>>>
>>> Thanks in advance....
>>>
>>> Regards,
>>>
>>> - Paul H
>>>
>>>
>>> --
>>> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>>>
>>
>> --
>> Geir Magnusson Jr. geirm@optonline.net
>> System and Software Consulting
>> "He who throws mud only loses ground." - Fat Albert
>>
>>
>> --
>> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"They that can 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: [Vote] ARMI to move
Posted by Martin Cooper <ma...@tumbleweed.com>.
> Don't you need more active committers?
Interesting question. My initial assumption was that, yes, that's what the
rules say. However, on checking the Commons charter, it doesn't actually say
how many committers are required for a package to be accepted (or if it
does, I missed it). The Jakarta rules do, of course. Perhaps this is
something we should define?
The vote for acceptance, however, is well defined as a positive
super-majority.
--
Martin Cooper
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Monday, January 07, 2002 7:50 PM
Subject: Re: [Vote] ARMI to move
> Don't you need more active committers?
>
>
> On 1/6/02 6:35 PM, "Paul Hammant" <Pa...@yahoo.com> wrote:
>
> > Folks,
> >
> > http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/armi/
> >
> > I have done a lot of work on ARMI and think it is time for me to ask
> > committers to vote for a move of this tool from 'sandbox' in to the main
> > CVS tree. It also needs a rename (ARMI is already used in the context
> > of Java by another academic team). Please do not think of this as a
> > full replacement for RMI. It is merely an alternative that bizarely
> > might be most useful (to Avalon) entirely inside one VM.
> >
> > With respect to the rename, I think FacadePublisher gives the most
> > meaning, but is not snappy.
> >
> > Now, I guess I have no vote myself as I am only a committer to 'soapbox'
> > but I would be interested to know if know the outcome of a vote from
> > those that do......
> >
> > Two votes:
> >
> > 1) for ARMI being renamed to FacadePublisher (or other)
> >
> > 2) for migrating from 'soapbox' to main CVS.
> >
> > Thanks in advance....
> >
> > Regards,
> >
> > - Paul H
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> "He who throws mud only loses ground." - Fat Albert
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI to move
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Don't you need more active committers?
On 1/6/02 6:35 PM, "Paul Hammant" <Pa...@yahoo.com> wrote:
> Folks,
>
> http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/armi/
>
> I have done a lot of work on ARMI and think it is time for me to ask
> committers to vote for a move of this tool from 'sandbox' in to the main
> CVS tree. It also needs a rename (ARMI is already used in the context
> of Java by another academic team). Please do not think of this as a
> full replacement for RMI. It is merely an alternative that bizarely
> might be most useful (to Avalon) entirely inside one VM.
>
> With respect to the rename, I think FacadePublisher gives the most
> meaning, but is not snappy.
>
> Now, I guess I have no vote myself as I am only a committer to 'soapbox'
> but I would be interested to know if know the outcome of a vote from
> those that do......
>
> Two votes:
>
> 1) for ARMI being renamed to FacadePublisher (or other)
>
> 2) for migrating from 'soapbox' to main CVS.
>
> Thanks in advance....
>
> Regards,
>
> - Paul H
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>