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/02 00:53:58 UTC
ARMI mobilisation?
Commoners,
I have pushed a working verision of ARMI into commons-scratchpad and
anyone with Ant should be able to build and test it.
To become a proper commons project what needs to happen? Normally
Jakarta rules insist that a project has an active developer community
behind it before it gets hosted at Apache. This is not the case for
ARMI as it has been a solo effort so far. Is it as simple as a vote
from Commons committers?
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ARMI mobilisation?
Posted by Jeff Turner <je...@socialchange.net.au>.
On Tue, Jan 01, 2002 at 11:53:58PM +0000, Paul Hammant wrote:
> Commoners,
>
> I have pushed a working verision of ARMI into commons-scratchpad and
> anyone with Ant should be able to build and test it.
>
> To become a proper commons project what needs to happen? Normally
> Jakarta rules insist that a project has an active developer community
> behind it before it gets hosted at Apache. This is not the case for
> ARMI as it has been a solo effort so far. Is it as simple as a vote
> from Commons committers?
I think a vote is all that's needed, but the vote would be (strongly?)
influenced by the amount of 'active developer community' the project
has.
(for the record, everyone, Paul is an *extremely* active Avalon
developer.. he's not likely to lose interest and disappear;)
I'd say, what the heck; call a VOTE, and we'll see a) if people think
having a user community is a precondition for a Commons project b) just
how much interest from committers there is.
Everyone's busy on their own little project here.. sometimes it requires
a lot of arm-waving to get a response ;)
Here's Craig's post to an earlier thread, which seems relevant.
>> According to the Commons charter, it doesn't take a vote to put
>> proposed code in the sandbox -- any committer on any Jakarta project
>> can do this. It's a good way to look at some potential code and play
>> with it a little. Once the package has been proven to be a good
>> idea, it can be voted in to the standard commons repository (by the
>> committers on COMMONS-DEV).
>>
>> In practice, it seems to work pretty well ... people get a chance to
>> evaluate new ideas (and get interested in contributing) in the
>> sandbox, so a proposed new package can start building a
>> mini-community around it instead of being a one-man show.
>> Historically, migration to the commons repository has been approved
>> every time it's been proposed so far, so it's not like this is really
>> a roadblock.
--Jeff
>
> Regards,
>
> - Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ARMI mobilisation?
Posted by Paul Hammant <Pa...@yahoo.com>.
Lance,
>>Any thoughts for ARMI (though it needs a rename as "Async RMI"
>>used). Is commons the place for it? Yes/No?
>>
>
>Paul,
>
>Sorry I haven't had an opportunity to test ARMI yet, but thought I'd
>chime in here anyway:
>I always thought (somehow) that ARMI stood for "Alternative RMI" ;-)
>
It does for me but the other (academic) team uses ARMI to mean
"Asynchronous RMI".
>And Commons seems a reasonable place for it, at least until it develops
>enough audience/neccessity to become its own project (as Cactus did).
>
I'm going to roll in BCEL use soon. That could please more people.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ARMI mobilisation?
Posted by Lavandowska <fl...@yahoo.com>.
--- Paul Hammant <Pa...@yahoo.com> wrote:
> Any thoughts for ARMI (though it needs a rename as "Async RMI"
> used). Is commons the place for it? Yes/No?
Paul,
Sorry I haven't had an opportunity to test ARMI yet, but thought I'd
chime in here anyway:
I always thought (somehow) that ARMI stood for "Alternative RMI" ;-)
And Commons seems a reasonable place for it, at least until it develops
enough audience/neccessity to become its own project (as Cactus did).
Lance
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ARMI mobilisation?
Posted by Juozas Baliuka <ba...@mwm.lt>.
Hi,
I am not commiter and it is not a veto. It is possible to implement "The
best RPC for JAVA", but RMI will be better :)
I think you are wasting your time, but good luck.
At 11:39 2002-01-05 +0000, you wrote:
>Juozas,
>
>><snip>
>>
>>I see no ARMI advantages.
>
>I am not stopping anyone useing RMI if they want to. I note in the
>proposal it is no good for EJB. It's other limitations are noted too.
>It does have advatages, just read the Proposal.
>
>I guess we (you and I) will never meet in the middle. I'll feel free to
>ignore your projects too, and look forward to your -1 when the time comes.
>
>Regards,
>
>- 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: contributors list
Posted by Jeff Turner <je...@socialchange.net.au>.
On Sat, Jan 05, 2002 at 10:01:24PM +0000, robert burrell donkin wrote:
>
> this last bit got me thinking - i don't really know who is a commons
> committer. if i don't, then what chance will people have who haven't been
> on this mailing list as long as me?
>
> maybe the commons contributors page is more important than just an
> optional 'howdy' page. maybe it needs to contain all committers so that
> people can work out when a veto is a veto. the maintenance effort wouldn't
> be too great if new committers were added to the list as soon as they are
> voted in.
I agree. It would be nice if it was a jakarta-wide thing, not just
Commons.
The list of current committers can be determined by logging on to
cvs.apache.org (icarus), and typing:
cat /home/cvs/CVSROOT/avail | grep jakarta-commons
Resulting in:
avail|morgand,husted,conor,geirm,costin,remm,vmassol,craigmcc,nacho,rwaldhoff,jvanzyl,donaldp,jericho,sanders,jstrachan,dmitri,jariw,dirkv,dsale,martinc,bayard,dwinterfeldt,rdonkin,jefft|jakarta-commons
avail|morgand,husted,conor,geirm,costin,remm,vmassol,craigmcc,nacho,rwaldhoff,dweinr1,jvanzyl,sanders,donaldp,jericho,jstrachan,mschachter,dmitri,werken,dlr,knielsen,jon,leonardr,dsale,bayard,martinc,oalexeev,rdonkin,hammant,jefft|jakarta-commons-sandbox
It would be easy to set up a cron job to transform the 'avail' file into
a set of publicly accessible XML files, one for each project, containing
names of committers. Projects could then have an Ant task to fetch this
info:
<get src="http://jakarta.apache.org/" dest="committers/${name}.xml"/>
And then integrate it with the regular project docs, via
<style>/Anakia/Cocoon/whatever.
The only practical difficulty is that CVS is on a different box from the
website, so things would have to be done via ssh and scp.
I can do the script if people think this is a good idea.
--Jeff
> - robert
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
contributors list [WAS Re: ARMI mobilisation?]
Posted by robert burrell donkin <ro...@mac.com>.
On Saturday, January 5, 2002, at 11:39 AM, Paul Hammant wrote:
> Juozas,
>
>> <snip>
>>
>> I see no ARMI advantages.
>
> I am not stopping anyone useing RMI if they want to. I note in the
> proposal it is no good for EJB. It's other limitations are noted too.
> It does have advatages, just read the Proposal.
>
> I guess we (you and I) will never meet in the middle. I'll feel free to
> ignore your projects too, and look forward to your -1 when the time comes.
this last bit got me thinking - i don't really know who is a commons
committer. if i don't, then what chance will people have who haven't been
on this mailing list as long as me?
maybe the commons contributors page is more important than just an
optional 'howdy' page. maybe it needs to contain all committers so that
people can work out when a veto is a veto. the maintenance effort wouldn't
be too great if new committers were added to the list as soon as they are
voted in.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ARMI mobilisation?
Posted by Paul Hammant <Pa...@yahoo.com>.
Juozas,
> <snip>
>
> I see no ARMI advantages.
I am not stopping anyone useing RMI if they want to. I note in the
proposal it is no good for EJB. It's other limitations are noted too.
It does have advatages, just read the Proposal.
I guess we (you and I) will never meet in the middle. I'll feel free to
ignore your projects too, and look forward to your -1 when the time comes.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ARMI mobilisation?
Posted by Juozas Baliuka <ba...@mwm.lt>.
Hi,
I see you still want to implement alternative RMI . I can't understad this.
1. RemoteException. "}catch(ARMIRuntimeException are){" is it better ?
You handle fatal exeptions, don't you ?
Generate wrappers for remote interfaces, and you will not have any problems
with remote exception handling.
2. Remote interface. RMI must know how to marshal objects, by value or by
reference. Remote interface tells this.
Your ARMI knows this, don't it ? Have you a better solution ?
3. You want to have same remote and local interfaces. Use factory design
pattern and generated wrappers if your code does not depend on marshaling.
4. You want to use alternative transport. Is it JAVA RMI problem ? Use
java.rmi.server.RMIServerSocketFactory and
java.rmi.server.RMIClientSocketFactory, it is possible implement RMI over
ARMI :).
5. Most of distributed applications hosted by EJB servers, Is ARMI useful
for j2ee application ?
I see no ARMI advantages. Use RMI, well known design patterns and you will
have portable and good code.
I thing it can be useful project if you use standard JAVA RMI, implement
code generators for wrappers, IDE plugins, alternative
transports, default remote exception handlers, write documentation for RMI
design patterns.
At 18:41 2002-01-03 +0000, you wrote:
>Folks,
>
>Any thoughts for ARMI (though it needs a rename as "Async RMI" already
>used). Is commons the place for it? Yes/No?
>
>Regards,
>
>- 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: ARMI mobilisation?
Posted by Paul Hammant <Pa...@yahoo.com>.
Folks,
Any thoughts for ARMI (though it needs a rename as "Async RMI" already
used). Is commons the place for it? Yes/No?
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>