Re: Announcements without Release Notes

2009-01-11 Thread Robert Burrell Donkin
On Tue, 2009-01-06 at 12:51 -0800, Otis Gospodnetic wrote:
 Hello,
 
 General announcement question I have.  I like getting announcem...@jakarta 
 emails, as it allows me to passively keep abreast of new releases.  
 What I like even more is when announcements have a link to release notes of 
 some kind, so I can have a look at 
 and quickly get an idea about the project's direction, velocity, focus, 
 maturity, etc. without being intimately familiar with the project.
 
 For example, I just got an email about Mailet 2.4 release, but there was no 
 link to release notes or a JIRA link that might show what was done between 
 2.3 and 2.4.  I couldn't find any information on the site either.  So, my 
 questions are:
 Maybe I just don't know where to look?

in this case there weren't any substantial changes between 2.3 and 2.4:
2.4 is just a release independent of the server.

but i agree about this point in general and i will try to include more
information in future.

- robert 

(who hopes no one remembers that he wrote quite a lot of the release
documentat...@jakarta)



-
To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
For additional commands, e-mail: general-h...@jakarta.apache.org



RE: [VOTE] Move POI to TLP

2007-05-08 Thread Robert Burrell Donkin
On Mon, 2007-05-07 at 15:36 -0500, Laubach, Shawn Contr 555 ACSS/GFLA1
wrote:
 So I can vote for this but then I'm not a committer anymore?  Just curious.

anyone can vote (and please feel free to do so). however only some votes
are binding upon apache. in this case, it's Jakarta PMC votes. if POI
graduates then only Apache POI PMC votes will be binding.

- robert


signature.asc
Description: This is a digitally signed message part


Re: [VOTE] Move POI to TLP

2007-05-07 Thread Robert Burrell Donkin
On Fri, 2007-05-04 at 10:17 +0100, Nick Burch wrote:

snip

 So, now is the time to vote on the proposal:
 [X] +1 I support the proposal
 [ ] +0 I don't care
 [ ] -1  I'm opposed to the proposal because...

- robert


signature.asc
Description: This is a digitally signed message part


Re: My svn account

2007-01-15 Thread robert burrell donkin
On Wed, 2007-01-10 at 16:44 -0500, Andrew C. Oliver wrote:
 IIRC, this is my 4th attempt to resolve this (I try like every 3-4 
 months).  I would like to commit something.  My SVN account is not 
 working.  per the instructions off the SVN page I emailed [EMAIL PROTECTED]  
 I got 
 no response.  I am still able to log in to people.apache.org.

svnpasswd...?

- robert



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



[ANN] Apache Jakarta Commons Betwixt 0.8 Released

2006-12-30 Thread robert burrell donkin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The Jakarta Commons community is pleased to announce that Apache Jakarta
Commons Betwixt 0.8 is now available for download from
http://jakarta.apache.org/site/downloads/downloads_commons-betwixt.cgi.
Please remember to verify the release when downloading from a mirror.  

Commons Betwixt is a reflective, dynamic, bean-centric object-xml
mapper. It provides a flexible way to map beans into XML - and vice
versa. It requires Java 1.3 or higher. For more details see
http://jakarta.apache.org/commons/betwixt.

Betwixt is an open source library developed by the Jakarta Project of
the 
Apache Software Foundation (see http://jakarta.apache.org/) and released
under the 
Apache License 2.0 (http://www.apache.org/licenses/LICENSE-2.0). Jakarta
commons is an open development community. 
All are invited to contribute by joining us on the mailing lists 
(see http://jakarta.apache.org/commons) or by raising issues and
submitting patches 
through http://issues.apache.org.

Betwixt 0.8 is a feature release. Support for polymorphic mappings has
been improved. 
More flexible mapping are possible using new strategies. Enhancements
have been made 
to mapping formats. Mixed collections are now handled more completely.
Complete
details can be found in the release notes
http://jakarta.apache.org/commons/betwixt/betwixt-0.8/RELEASE-NOTES.txt.

Betwixt 0.8 is compatible with 0.7.

Documentation for this release is available from
http://jakarta.apache.org/commons/betwixt/betwixt-0.8/docs/index.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFltPll6Otx30NTe0RAvu7AJ9L3vcD7XH8AYGMF0kqwto3G70AqQCgiwsc
KDmH0kjk/bzAyhDwkdLz5ZQ=
=BfSe
-END PGP SIGNATURE-



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



[NOTICE] New OpenPGP Subkey For Email

2006-06-19 Thread robert burrell donkin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I have now switched to using a subkey to sign email. Those using GnuPG
may wish to upgrade to the latest version and gpg --refresh-keys.

I maintain a statement of my OpenPGP policy at
http://people.apache.org/~rdonkin/openpgp_policy.asc.

Thanks

Robert Burrell Donkin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFElwfd1TNOdbExPeIRAgsUAJ46C9ugHsZQfw5JyXfnAT7JlIfh7gCeI7YQ
5BenpnDyKs5R1bI+vNwt4Hw=
=t4wD
-END PGP SIGNATURE-


signature.asc
Description: This is a digitally signed message part


Re: testing.apache.org

2006-06-12 Thread robert burrell donkin
On Mon, 2006-06-12 at 14:24 -0400, Rahul Akolkar wrote:
 On 6/11/06, robert burrell donkin [EMAIL PROTECTED] wrote:
  On Thu, 2006-06-08 at 22:50 -0700, Phil Steitz wrote:
   Rahul Akolkar wrote:
 snip/
   
Per the umbrella concern, the question then becomes what -- if any --
are the mitigating factors that can address such a concern with
regards to this proposal. Based on Hen's email, seems like the ball is
still in the board's court -- as we wait for the next meeting -- so
maybe its premature to discuss if we should be trying to address those
comments yet?
   I would also like to understand exactly what the problem is and what
   mitigating steps may be possible.  In particular, I would very much
   appreciate a definition of umbrella that allows Geronimo, Logging,
   Jakarta Commons, DB, XML, Web Services and Struts,  but somehow
   disallows Testing.
 
  (this is the way i see the world and so is likely biased)
 
  the ASF runs on sub-minimal rules. most votes are subjective and not
  objective. the criteria applied are personal and evolve over time. past
  decisions are not revised to take account of changing opinions.
 
 snap/
 
 Thanks for that input Robert, seems in line with what I had
 anticipated -- nice and fuzzy on an objective level.

you know me too well :)

often fuzziness indicates that the issues haven't really been completely
settled as yet

 The thing that is clear, however, is that this is membership driven
 (as it should be too, IMO) so I'll pretty much step aside at this
 point and return to my seat as a casual (yet keenly interested)
 observer.

we don't have the answers. we may not even know the questions. but we do
have confidence in our ability to learn and evolve. that's one reason
why the ASF chooses to grow policy and why policy changes over time.

it's important that every consensus is challenged. once any consensus
opinion of the membership is accepted as true just because it is
received from that group, ossification and group speak sets in.
evolution and growth stops. these are the real threats to apache. 

we need to people to ask 'why?' (so please don't stop) 

coming back to henri's comments: the ASF prefers self-organisation.
reorganisations are much more likely to be approved if it's the
committers involved who are pushing for them. if the communities are
effected are strongly in favour then this has great weight.  

- robert



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



RE: Commons-modeler release request

2006-05-25 Thread robert burrell donkin
On Wed, 2006-05-24 at 18:00 -0400, Henri Yandell wrote:
 On Wed, 24 May 2006, Bill Barker wrote:
  -Original Message-
  From: Henri Yandell [mailto:[EMAIL PROTECTED]

snip

  Backwards incompatible shouldn't be a worry (imo), that's what major
  version numbers are for - but if you mean that Tomcat would
  need specific
  deep down customisations, that does sound like a problem. A
  realization
  that the component design just doesn't work anymore.
 
  Backwards incompatible was never really a big concern.  The discussion on
  [EMAIL PROTECTED] was more focused on the fact that [modeler] doesn't have a
  community, so there wouldn't be enough people for 3 +1s to release it.  So
  far, there aren't any special Tomcat-specific customizations in Tomcat's
  fork.  There is work to reduce it's footprint, but that would just make it a
  2.0 version.
 
 In terms of community - due to history you're all still Jakarta committers 
 afaik and mostly on the PMC, so lots of +1s there. 

 we had a bit of a crisis of confidence over commons releases late last
year but i think that we're over that now. we're now using the correct
voting scheme which is binding votes for all pmc'ers (no more component
specific voting). 

 Plus with the recent move to mostly jakarta-wide svn authentication, you also 
 now have svn 
 access.

+1

if it's just a push towards a release that's needed,  i'm willing to
help out if there's anything useful i can do. 

 So in terms of future direction, I don't think there's anything stopping 
 Tomcat from being the driving part of the community for modeler. Struts 
 definitely does that with some of the components that it is dependent on.
 
 The original idea of Commons as I understand it was as a place for Jakarta 
 projects to come together. The diaspora out of Jakarta has lessened that 
 and I think we should be expanding to thinking about it as a place for 
 Apache projects to come together. It definitely helps that our committer 
 based covers 25% of the ASF already :)

+1

- robert



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



Re: commons-fileupload: Streaming mode

2006-05-23 Thread robert burrell donkin
On Tue, 2006-05-23 at 07:24 -0400, Yoav Shapira wrote:
 Hola,
 +1 to you getting commons-fileupload karma and doing it yourself ;)

+1

i've kicked off the formal vote on commons-dev.

- robert



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



Re: [PROPOSAL] Tiles as the seed for Jakarta Web Components

2006-04-27 Thread robert burrell donkin
On Tue, 2006-04-25 at 22:54 -0700, Martin Cooper wrote:
 On 4/25/06, Nathan Bubna [EMAIL PROTECTED] wrote:
 
  This sounds great, Martin.   But if i may be forgiven a little
  semantic nitpicking, my understanding of previous discussions is that
  JWC would be a grouping rather than a sub-project.  So Tiles would
  be directly a Jakarta sub-project, rather than a sub-sub-project (i.e.
  becoming Jakarta Tiles, not Jakarta Web Components Tiles).
 
 Yes, you are correct, Tiles would be a Jakarta sub-project within the JWC
 grouping. I guess I was trying to simplify the proposal for those who
 haven't paid as much attention to the whole grouping thing, but in
 retrospect, that probably wasn't such a great idea. ;-)

i'd prefer to move away from the term sub-project since it has negative
formal associations. it can't be a project mini-me with formal structure
of it's own. just a Jakarta component: separate product, same project,
same formal organisational structure.

AIUI (and it might be a good idea to check this out with PR) the naming
guidelines mean that it should be Apache Tiles (not Jakarta Tiles or
Jakarta Web Components Tiles). the reason for this is to ensure we can
use trademark law to protect ourselves (if that's ever needed). 

IHMO Apache Tiles from the Jakarta Web Components team sounds pretty
good anyway

- robert



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



Re: [PROPOSAL] Tiles as the seed for Jakarta Web Components

2006-04-27 Thread robert burrell donkin
On Wed, 2006-04-26 at 14:55 -0500, Greg Reddin wrote:
 Sorry to be a latecomer to this thread.  I've had some trouble  
 subscribing for whatever reason.  But I just wanted to add that I am  
 working on Standalone Tiles over at the Struts project and am willing  
 to support it if it's moved to some Jakarta subproject.   

cool :)

  I'll let you guys hash out how the community is structured :-)  I haven't  
 participated in Jakarta enough lately to have an opinion.

i'd hope we're not trying to structure the community, just the formal
organisation supporting it.

- robert



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



Re: [PROPOSAL] Tiles as the seed for Jakarta Web Components

2006-04-27 Thread robert burrell donkin
On Wed, 2006-04-26 at 11:48 -0400, Henri Yandell wrote:
 The Web Components thread is much older than the recent set of threads, it 
 was back in 2005. So I don't think we've heard your reasons against a JWC 
 Sub-Project as opposed to the not-community-of-community threads.

i have worries about any more formal sub-projects: they are too much
like project mini-me's with their own formal structure. IMO the legal
and formal structures are best aligned. 

i do like the idea of a JWC grouping or community within jakarta. with
all the trappings that the old sub-projects had (mailing lists, web site
and so on) but no separate classes of committers under the same pmc. i
think a manifesto would be needed for each grouping (somewhere between
guidelines and a charter) which should define the scope.

 I can find this on wiki:
 
 http://wiki.apache.org/jakarta/CreatingCommonsForWebComponents
 
 which includes a charter - though I think the charter needs changing as 
 that's a copy of the Commons charter which is 5% charter and 95% 
 developer guidelines.

IIRC the document on the wiki was intended to be the starting point for
a charter. 

 I know we voted on the name, I thought we voted on the creation of the 
 subproject as part of that but would need to check archives. Will do that 
 in a bit.

i seem to recall a vote but not sure what it was on...

 On Wed, 26 Apr 2006, Andrew C. Oliver wrote:
 
  No.  There isn't a consensus. 

andrew's right that since he dissents, there isn't an absolute
consensus. i do suspect that he's views are in the minority, though. we
should push things forward until we have something concrete to vote on.

- robert



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



Re: [VOTE] Jakarta Sandbox

2006-04-10 Thread robert burrell donkin
On Sun, 2006-04-09 at 22:31 -0400, Andrew C. Oliver wrote:
 Yes.  A lot of things predate the incubator.  I'm not opposed to say an 
 HTTPD-sandbox for experimental HTTPD related stuff.
 I'm not opposed to a POI-sandbox (indeed we have one but call it 
 scratchpad) for POI-related stuff.  However Jakarta-sandbox is 
 SCOPELESS.  Go have a scopeless sandbox on sourceforge IMO.  If you want 
 to start a whole NEW project then do that in the incubator IMO.

the sandbox already exists. the management and supervision were
entrusted to the commons sub-project. sub-projects have no formal
existence. the scope of the sandbox is the same as the scope for
jakarta.

anything that is in scope for jakarta is in scope for sub-projects. code
in other languages is pretty much out but nearly any subject is in
scope. the only limits are imposed by the community itself. 

jakarta's scope is the problem but it's hard to fix for both historic
and community reasons

- robert 



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



Re: [VOTE] Jakarta Sandbox

2006-04-09 Thread robert burrell donkin
On Sun, 2006-04-09 at 10:20 -0400, Andrew C. Oliver wrote:

snip

 Totally NOT how the incubator was described to me.  As I understand it 
 if Tomcat (for instance) wants to create a new JSP engine, that's kosher 
 for Tomcat.  However if someone in POI wanted to create a new AI engine 
 (having nothing to do with MS file formats) then that is Incubator-toast.

that is a matter of scope, not incubation policy

a hypothetical example might help to illustrate the difference:

JSP engines are in-scope for tomcat but out-of-scope for xerces. xerces
is not allowed a JSP engine as part of that project. 

but if a new JSP engine wanted by tomcat was created outside the ASF, it
would need to come in through the incubator. if it arrives without a
external community (for example, because it was developed off-shore by
tomcat developers) then it's a simply process of legal sign off. if it
arrives with a community then it needs to enter as a podling to ensure
that the community gets the help they need to understand how apache
works.

however, if the xerces developers (let's say for sake of argument)
wanted to create a JCP engine at apache but outside tomcat they would
need to create a new project. it is now seems more difficult for new
projects to be created at apache (the test is subjective and democratic
so this is an observation not a rule). it is much easier to create a new
project offshore and then bring it in through the incubator. so, the
scope issue would (for practical purposes) probably require them to go
through the incubator.

- robert



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



Re: Encoding and format of RSS.XML

2006-04-02 Thread robert burrell donkin
On Sat, 2006-04-01 at 22:50 +0100, sebb wrote:
 Should the RSS.XML file use encoding=WINDOWS-1252?
 
 Most (all) the other files use encoding=ISO-8859-1.
 
 Also, the layout is not all that easy to read - not all that important
 for end-users, but makes it a bit harder to review changes. Adding
 indent=yes should sort this.
 
 Any objections to changing these items?

sounds good

- robert


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



Re: [VOTE] Remove SVN restrictions

2006-03-27 Thread robert burrell donkin
On Mon, 2006-03-27 at 02:50 -0500, Henri Yandell wrote:

 [X] +1
 [ ] -1

- robert


signature.asc
Description: This is a digitally signed message part


Re: [VOTE] Remove SVN restrictions

2006-03-27 Thread robert burrell donkin
On Mon, 2006-03-27 at 20:01 +0100, sebb wrote:
 On 27/03/06, Henri Yandell [EMAIL PROTECTED] wrote:
 
  Vote to remove the SVN barriers within Jakarta such that all jakarta-*
  groups are merged into the one jakarta group with the exception of
  jakarta-hivemind, jakarta-slide, jakarta-cactus and jakarta-jmeter under
  the assumption that they are moving to having their own PMCs. Tapestry is
  already within its own auth group.
 
  [X] +1
 
 Can Jakarta committers for projects moving to their own PMCs remain as
 Jakarta committers ?

that's what's happened in the past

- robert


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



Re: Submitting patches

2006-03-26 Thread robert burrell donkin
On Sun, 2006-03-26 at 12:41 +0100, sebb wrote:
 Generally I find that patches are much easier to process as Bugzilla
 attachments, rather than sent to the developer list as an attachment.
 
 And if the patch is large, it uses everyones mail resources, most of
 whom aren't interested.
 
 Just received such a patch on JMeter - the poster helpfully has a blog
 where he says that he followed the guidelines in:
 
 http://jakarta.apache.org/site/source.html#Patches
 
 which do indeed suggest sending patches to the developer mailing list.
 
 I'd like to suggest a change, so that the preferred method of
 submitting patches is via Bugzilla or JIRA.
 
 In the case of projects using JIRA, I believe that asks for a software
 grant, so it's important that code is submitted that way.
 
 [Actually, I'm not sure when emailed patches are appropriate...]
 
 I'd also like to split the patch section into two:
 
 Patch Creation
 
 Patch Submission
 
 Any objections to this?

sounds good :)

 If not, I'll make a start on updating the text - and put a copy on my
 home page for review.

no need to bother: if the feedback's positive then commit and we'll
review the diffs. 

perhaps this information may be better at foundation level but any move
can wait until you've patched...

- robert


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



Re: adding a link from commons.apache.org to Jakarta Commons?

2006-03-23 Thread robert burrell donkin
On Wed, 2006-03-22 at 22:04 -0500, Henri Yandell wrote:
 Now Martin's answer becomes very apt - something to sell across the ASF 
 and there will be push back. ie) Good luck.
 
 However, I think it's not a bad idea. commons.apache.org as a Federation 
 for the various Commons projects around the ASF - even if I am suggesting 
 that J-C and J should start to merge into each other. Assuming I'm 
 understanding what you mean by virtual front.

i think that we need to start breaking the legal and formal organisation
from the ontological. all the components in the various commons across
apache are similar in many ways. users should really need to care which
particular committee is charged with oversight.

i think that DOAP can help. the germ's there but it's going to need a
lot richer system of categorisation. the output generated by
projects.apache.org needs some styling but that should be easy enough to
do. 

how about introducing a suitable category and forwarding to that
category?

i like administration being decentralised: any suitable component in any
apache project could join just by declaring the category in the DOAP.

- robert


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



Re: Jakarta Sandbox?

2006-03-23 Thread robert burrell donkin
On Wed, 2006-03-22 at 15:51 -0300, Felipe Leme wrote:
 Hi Rahul (and others),
 
 First of all, sorry for the delay (but as they say here Better later 
 than never :-)

+1

 Still, I think it worths to create a separate sub-project for the Standard 
 Taglibs - even if it's DOA on activity, it's still a different project 
 (because of the TCK, history, importance of JSTL, etc...)

we're trying to move away from sub-projects so possible a standards
grouping might make more sense. a home for EL as well ;)

- robert


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



Re: Invitation

2006-03-19 Thread robert burrell donkin
On Sat, 2006-03-18 at 23:32 -0500, Henri Yandell wrote:
 I'm assuming at the moment that this is a case of somebody spoofing 
 Karthik's address. I doubt the spam is from Karthik - just something that 
 snuck through the spamassassin and various other email controls and 
 happens to be a subscribed address.

looks like we're going to need to think about turning on address
checking sooner or later this year. probably need to think about ways to
allow committers to post from their apache addresses...

- robert


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



software grants drop location

2006-03-19 Thread robert burrell donkin
when a software grant is received, it's important that the actual
donated code is recorded in the repository: the actual code donated is
identified by it's MD5 sum. it seems best to me to adopt a single drop
point in jakarta for these grants. i propose
http://svn.apache.org/repos/asf/jakarta/grants/.

any objections/improvements?

- robert


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



Re: software grants drop location

2006-03-19 Thread robert burrell donkin
On Sun, 2006-03-19 at 12:09 -0500, Henri Yandell wrote:
 
 On Sun, 19 Mar 2006, robert burrell donkin wrote:
 
  when a software grant is received, it's important that the actual
  donated code is recorded in the repository: the actual code donated is
  identified by it's MD5 sum. it seems best to me to adopt a single drop
  point in jakarta for these grants. i propose
  http://svn.apache.org/repos/asf/jakarta/grants/.
 
  any objections/improvements?
 
 Should it be an incubator location? ie) one place for all of Apache?

leo think so and (on reflection) i agree. waiting for more feedback and
i'll report back a little later... 

- robert


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



RE: [PROPOSAL] Cleanup pmc members

2006-03-18 Thread robert burrell donkin
On Fri, 2006-03-17 at 10:48 -0500, Henri Yandell wrote:
 
 On Fri, 17 Mar 2006, Noel J. Bergman wrote:
 
  My proposal is that we create a file in SVN in which PMC members can list
  themselves as being active. After 1 month, failure to appear in that list
  will result in removal from the PMC.
 
  Why not just send out e-mail to the PMC members asking them if they want to
  remain active?
 
 Sounds good. Seems to fit with Sandy and Danny's preferences without being 
 too complex - just a chunk of email to send out.
 
 Can deal with those who've not replied and email addresses that bounce if 
 and when that happens.

+1

 Will do so if no one is against the idea in 10 days or so.
 
  We have done this with another PMC, and had one person repeatedly ask to
  stay listed as active.  I don't think that I've seen a post from him other
  than that in some years now, but as long as he's happy reading and has
  nothing to say, I have no problem with keeping him.
 
  There is no quorum to be met for the PMC.
 
 There is on the Jakarta PMC (informally due to our charter), but it's 
 something we should drop anyway. :)

+1 

is this a board thing or can we just vote to fix it now?

i agree with noel we should aim for as few rules as possible :)

in this spirit, i wonder whether we actually need to formally remove
people from the committee (once the quorum issue is fixed). 

i agree that it's important to know which pmc'ers are still active to
address oversight but this could be achieved without formally removing
anyone from the pmc: just create a subsection on the website inside the
pmc section for emeritus pmc'ers. in the case of those people who don't
reply, move them to that subsection of the website but leave them on the
legal committee. saves paperwork and means that there's no hassle
reactivating.

- robert


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



Re: [PROPOSAL] Jakarta Language Components

2006-03-14 Thread robert burrell donkin
On Tue, 2006-03-07 at 19:13 +, Stephen Colebourne wrote:
 Reposted (edited) from original commons proposal.
 Currently this proposal has general, though not unanimous, support.
 A vote thread may follow this thread if the mood remains positive.

i'm a little unsure whether this will turn out for better or worse but
if people out there have energy, i'm willing to give it a go. time's
probably right for a little innovation and experimentation.

i like the idea of tagging emails better: a single list with cool server
side filtering and metrics. we don't have the technology for this yet so
i'm willing to see the mailing lists split so long as people would be
willing to consider coming back if it every arrives...

 I hereby propose the creation of a new Jakarta entity named 'Jakarta 
 Language Components'.
 
 This will be formed from the following codebases:
 [lang]
 [io]
 [collections] - expected to divide
 [primitives]
 [codec]
 [id] - on exit from sandbox
 [beanutils] - logging to be removed
 
 The following are invited to join if their communities desire:
 [oro]
 [regexp]
 [cli]
 
 Jakarta Language Components mission:
 'Enhancing Java SE'
 
 Jakarta Language Components will:
 - develop multiple independent components

yep

 - each component will have no dependencies
 - each component will have no configuration

perhaps a description may be better than a proscription: charters are
bad since they need votes and formalism. groupings should be less formal
and more social than sub-projects. 

i think groupings will only work if the formal structures required
(voting, karma, websites and so on) can be kept fixed and cross grouping
so that groupings can be more fluid. 

 - each component provides an extension to the JavaSE
 - code judged by would it be out of place in the JavaSE

probably the wrong test: some of the stuff that's included is pretty
controversial and grows in scope all the time. i'm not sure that this is
really what a lot of the extra rubbish is wanted: eg logging, crypto,
sql, corba, swing.

isn't it only really the lang, util, io and beans packages that are
really of interest?

 - a component typically has a broad API (many callable methods)
 - each method typically does relatively little processing

KISS: not needed in a charter

might be better to be descriptive: offer a separate positive description
of an architypical component. this can be longer and can be amended more
easily. grouping ethos document, perhaps?

 - have mailing lists (language-user/language-dev)

is there any need for a another user list?

given smaller mail volumes and the nature of the audience for these
components (java developers), i think it would be better to retain a
common user list but encourage posting by users to the dev list.

the commons was more active when there was no user lists. i'd like to
propose we try that again for this new grouping. if a user list proves
necessary then it can easily be added later.

 - not have a sandbox

does that mean: use the jakarta sandbox if every needed?

 - use [EMAIL PROTECTED] ML (new) for cross group issues

general would feel better (to me) for discussing cross group issues but
maybe dev might be needed for votes later...

- robert


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



Re: Jakarta Web Components

2006-03-14 Thread robert burrell donkin
On Mon, 2006-03-06 at 19:49 +0100, Ortwin Glück wrote:
 
 Sandy McArthur wrote:
  As a programmer looking for useful code to help me with uploaded
  files, I'm going to look in something named Jakarta *Web* Components
  first. When I see Jakarta HTTP Components I think of interacting with
  the HTTP protocol. I know FileUpload does both, but when I'm writing
  an webapp I think I'm working with a *web* app first and while I am
  working with HTTP it is a secondary concern.
  
  --
  Sandy McArthur
 
 This may be true, but it shouldn't influence how the communities around 
 the code are organised. This is more a matter of communication and branding.

i think that's one of the advantages of flattening karma and voting: .
we need to separate the formal legal structure (karma, voting) from the
community (developers hanging out) from the ontological (communicating
that the components are). 

from an ontological perspective, fileupload needs to be tagged as both
http and web component with a sideways relationship to codec.

from a community perspective, martin feels more at home with the
httpclient team and it sounds like there are sound reasons to believe
development might be more progressive.

from a legal perspective, we're all jakarta: karma and voting need to be
communal.

in some ways, we need to find a way since the whole of apache is going
to be facing these problems soon...

- robert


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



Re: [PROPOSAL] Jakarta Language Components

2006-03-14 Thread robert burrell donkin
On Tue, 2006-03-14 at 15:29 -0500, Henri Yandell wrote:
 Board report done - now I can irritate you all on these threads again :)
 
 On Tue, 14 Mar 2006, robert burrell donkin wrote:

snip

  - each component provides an extension to the JavaSE
  - code judged by would it be out of place in the JavaSE
 
  probably the wrong test: some of the stuff that's included is pretty
  controversial and grows in scope all the time. i'm not sure that this is
  really what a lot of the extra rubbish is wanted: eg logging, crypto,
  sql, corba, swing.
 
  isn't it only really the lang, util, io and beans packages that are
  really of interest?
 
 +1. 'core of JavaSE' ?

better :)

nice'n'fuzzy

  - have mailing lists (language-user/language-dev)
 
  is there any need for a another user list?
 
 Also, why cause users pain while we experiment. How about we do the -dev 
 list, and see how the -user list goes?
 
  given smaller mail volumes and the nature of the audience for these
  components (java developers), i think it would be better to retain a
  common user list but encourage posting by users to the dev list.
 
  the commons was more active when there was no user lists. i'd like to
  propose we try that again for this new grouping. if a user list proves
  necessary then it can easily be added later.
 
 Ah. I thought you were suggesting that they would continue to use 
 commons-user. :)

both at once, really :)

any users who want to can use the commons-user list but not having a
user list will encourage more people to subscribe to dev. which is a
good thing.

 I'm +1 to commons-user. I'm only +1 to not havin a user list if we get the 
 commits/wiki/jira out of the user's face.

that'd be easy. might be better for oversight to have these posted to
[EMAIL PROTECTED] anyway.

  - not have a sandbox
 
  does that mean: use the jakarta sandbox if every needed?
 
 Pretty sure it does.
 
  - use [EMAIL PROTECTED] ML (new) for cross group issues
 
  general would feel better (to me) for discussing cross group issues but
  maybe dev might be needed for votes later...
 
 Yep. Re-word as:
 
 - use Jakarta wide lists for cross group issues.
 
 We can modify what those are if we think that general@ is overwhelmed by 
 Jakarta and we'd like it to be more pan-Apache Java or general-interest.

+1

start here with the probably that we'll move later

- robert


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



Re: Representing project inactivity on the site

2006-03-14 Thread robert burrell donkin
On Mon, 2006-03-06 at 16:53 +0100, Martin van den Bemt wrote:
 Just zap alexandria (we just zapped the mailinglist too). We can look at it 
 as being promoted to TLP 
   anyway (gump).
 ORO and Regexp ar kind of finished I thought, we should mark it stable or 
 something like that.
 Don't know about ECS though.

ECS is pretty much complete. 

- robert


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



RE: Other Jakarta Components

2006-03-14 Thread robert burrell donkin
On Mon, 2006-03-13 at 19:18 -0500, Noel J. Bergman wrote:
 In terms of finding homes, I wonder if we should have a root directory under
 which we have inactive codebases.  One problem would be that no PMC would be
 responsible.  Or we could create a sort of reverse incubator: a curatorship,
 where no active development takes place, but where oversight exists.  If a
 community wakes up around the codebase again, the curators can help put the
 codebase back into a community.

curatorship is an interesting idea :)

a good curator does what's necessary to preserve the codebase and so
wouldn't preclude some development (the very occasional bug fix and the
like).

probably no reason why the code needs to be moved or websites changed.
perhaps use a single mailing list with apmail magic to forward and
prefix messages from the old lists. this would give confidence about
oversight.

- robert


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



Re: [Jakarta Wiki] Update of OneCommunityProposals by StephenColebourne

2006-03-13 Thread robert burrell donkin
On Sun, 2006-03-12 at 23:32 +0100, Andrew C. Oliver wrote:
 I'd like to note my opposition.  I don't have the same vision as you do 
 and do not wish to be distracted by 100 irrelavant emails a day about 
 Commons ABCD.
 
 I'm glad Henri posted that reorganization things were being discussed. 
   I would have preferred that he posted a more detailed message as I 
 think others would likely be opposed to such forms of social 
 engineering.  Things evolve the way the evolve for a reason.  That POI 
 has relatively little to do with Commons-DB is not really a good reason 
 to force us to listen to noise/interference.  In radio, you tend to try 
 and pick bands that aren't real close together so that you don't overlap 
 and trample on each other's bandwidth.  I had to do this with my 
 wireless network because my neighbor's stuff kept interferring.  No I 
 don't think it would be great if we both shared channel 6 and I don't 
 feel like vetting some non-technical irrelevant change by someone who 
 wanted to get their API used by more projects (nevermind that it 
 performs half as well as the JDK implementation and sucks down 100 other 
 dependencies).   And I bet [EMAIL PROTECTED] would be 
 REALLY popular...so popular that ALL questions about POI would go to 
 [EMAIL PROTECTED] with CC to every email address I've ever had and 
 appologies for not posting on the list but half the time you can't 
 unsubscribe and I really don't want 1 emails a day about stuff I'm 
 not using.

you've just an excellent argument for moving poi to top level :) 

like it or not, it's the jakarta pmc which has the binding votes.
henri's proposal only formalises and organises the actual current state
of affairs. if you don't trust my judgement enough to allow me a veto on
poi commits then you need to talk to the other poi committers about
graduating poi to top level status. 

 If projects share obvious common technical ties then it makes sense, 
 otherwise lets let darwin decide rather than radical social engineering.
 
 The PMC should ASK the individual projects if they would like to share a 
 common list and set of committers rather than a top down decision 
 proposed on a list that most committers don't subscribe to (which might 
 indicate...duh...that they don't want to be on a list mostly not about 
 their project).  This proposal and any that resemble it are non-starters 
 for me.
 
 A lot of this sounds like Commons trying to remake Jakarta in its image. 
   As an alternative why can't commons be top level?  The namespace is 
 now free (http://commons.apache.org/).

hmmm...

commons, taglibs, http components and whatnot going to
commons.apache.org

that'd only leaves POI in jakarta: does that really make more sense than
apache poi?

- robert


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



Re: [Jakarta Wiki] Update of OneCommunityProposals by StephenColebourne

2006-03-13 Thread robert burrell donkin
On Mon, 2006-03-13 at 23:48 +0100, Andrew C. Oliver wrote:
  that'd only leaves POI in jakarta
 
 did you have a point there?  :-)

thanks for highlighting my bad grammar (it's past my bed time)

the point was the bit you snipped :)

preserving jakarta as a special umbrella for poi seems more than a
little odd to me. 

- robert


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



Re: OT: Gmail Labels enhancement: show recent message count in a label

2006-03-13 Thread robert burrell donkin
On Wed, 2006-03-08 at 00:09 -0500, Sandy McArthur wrote:
 spam
 I wrote a GreaseMonkey user script to help me manage the mail on the
 Jakarata mailing lists and thought I'd share because I noticed a good
 number of people here email from Gmail. If this is completely
 inappropriate to post here let me know and I won't do it again.

this is just what this list used to be for in the good-old bad-old days.
we need more off topics posts :)

- robert


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



Re: Other Jakarta Components

2006-03-13 Thread robert burrell donkin
On Tue, 2006-03-07 at 22:20 +0100, Thomas Dudziak wrote:

 As a side note, perhaps this is an opportunity to evaluate if there
 are better homes for some of the components ? E.g.
 betwixt/digester/jxpath could benefit from going to XML commons, 

xml tends to be about nuts and bolts. not really suitable. webservices
is a possibility.

jxpath is a bean utility and has quite a lot in commons with beanutils.

betwixt is a data mapping tool and IMHO has a lot more in common with
the db community than with xml. a move to db would probably be healthy
for betwixt.

 dbcp and dbutils from going to DB etc. ?

this is a community issue: dbcp is very closely related to pool. 

- robert


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



Re: Other Jakarta Components

2006-03-13 Thread robert burrell donkin
On Tue, 2006-03-07 at 23:07 +0100, Thomas Dudziak wrote:
 On 3/7/06, Henri Yandell [EMAIL PROTECTED] wrote:
 
  DbUtils and DBCP to db.apache.org sounds like a win to me; DBCP would
  point back to Jakarta for a dependency on [pool], but that helps to foster
  intra-project involvement.
 
  Betwixt, Digester and JXPath strike me as a bit more to swallow and XML
  might not want to taking such bites. You want to go ahead and ask them?
 
 Well, yes, JXPath might be a bit much, but Digester and Betwixt IMO
 would fit nicely.

definitely not xml. webservices would be a possibility. not particularly
keen, though. 

IMHO moving would mean no more releases (too few full time developers to
gain a quorum outside jakarta). realistically it means shutting down
these components so it would be throwing code over the wall. would be
kinder to shoot them.

in terms of community, db would be a better home for betwixt: it's has
much more in commons with bean-based OR mappers than with schema
catalogs. 

- robert


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



Re: Subproject Charters

2006-03-12 Thread robert burrell donkin
On Sun, 2006-03-05 at 17:31 -0500, Henri Yandell wrote:
 On Sun, 5 Mar 2006, Martin Cooper wrote:
  On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote:
  On Sun, 5 Mar 2006, Martin Cooper wrote:
  On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote:

snip

  Say some Prolog constraint framework decided it wanted to be part of
  Commons. Where would you point them to explain that that's not what
  Commons
  is about?
 
  The Jakarta charter where it says Java (which in fact it doesn't say -
  might be a bit of an ommission).
 
 
  OK, then what about a Java constraint framework?
 
  If it's large: -1 to Commons, -1 to Jakarta. If it's tiny +0 to Commons,
  +1 to Jakarta, but they're converging to both be a +1 if not too framework
  like.
 
 
  I specifically chose a framework for my example because we have long stated
  that frameworks should not live in Commons, and that is stated in our
  charter. Are you saying you want to change that now, to allow frameworks as
  Commons components? I so, -1 from me.
 
 Other way, frameworks -1 to being within Jakarta. Depends on definition of 
 framework - VFS is a framework to me; an interface structure designed for 
 multiple implementations. I'd stay +1 for small things like VFS.

IMO VFS is a bridging library, not a framework.

bridging libraries have a simple, user facing API is intended to be used
as a standard library. they also have a SPI (typically a mini-framework)
to allow the library to be extended by adding new implementations.
normal users should never use this: they just use it as a normal
library.

there are actually a number of bridging APIs in the commons and some
more are in the sandbox (for example, proxy). they are small and useful
for library creators since they allow projects to support multiple
backend configurations. bridging APIs have a number of similarities and
would probably make sense as a grouping.

- robert


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



Re: New Commons SubProject Proposal

2006-02-18 Thread robert burrell donkin
On Fri, 2006-02-17 at 14:57 +0530, Karthik Kumar wrote:
 On 2/17/06, robert burrell donkin [EMAIL PROTECTED]
 wrote:
 
  On Wed, 2006-02-15 at 16:52 -0800, Martin Cooper wrote:
   Given its database-centric nature, and the fact that it's a framework,
  this
   would appear to be more appropriate for the Apache DB Project:

 Hmm.. okay. it isn't a large framework. but, okay.

jakarta commons does bricks not frameworks

(however, it is possible that you are actually describing something
which is an adaptive bridge brick and not technically a framework)

 
   http://db.apache.org/
 
  +1 but don't let that discourage you :)
 
 
 jakarta isn't really accepting sub-projects any more: we're very slowly
  moving away from that model towards something flatter.
 
  - robert
 
 
 
 I was specifically referring to the Commons. Well, okay! :)

it was the language that fooled me :)

sub-projects are jakarta mini-me's with separate communities, mailing
lists and so on. apache has found that sub-projects don't scale.
components are the bricks the community happens to be working on.

but martin's right that we try to push data access related proposals
towards the db project. 

- robert


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



[ANNOUNCEMENT] ApacheCon EU 2006

2006-02-18 Thread robert burrell donkin
The ApacheCon Planners have announced that ApacheCon Europe
2006 will be held in Dublin, Ireland, at the Burlington Hotel
(http://www.jurysdoyle.com/ireland/doyle_burlington.htm), June 26-30.

Further details to follow as they are available.

Robert


signature.asc
Description: This is a digitally signed message part


Re: [RESULT] Tapestry TLP

2006-02-07 Thread robert burrell donkin
On Tue, 2006-02-07 at 09:43 -0800, Howard Lewis Ship wrote:
 Below is the result of the recent Tapestry committers vote to move
 Tapestry to an Apache top level project. Pending the approval of the
 Jakarta PMC, we'll be submitting the request to the Apache board.

is another VOTE needed for approval or can we just go with the VOTE held
on the tapestry thread?

- robert


signature.asc
Description: This is a digitally signed message part


Re: Users on Tomcat

2006-02-02 Thread robert burrell donkin
for a more quantitative answer, please ask on the tomcat user list.
please read http://tomcat.apache.org/lists.html.

- robert

On Thu, 2006-02-02 at 10:56 -0500, Travis Quarterman wrote:
 Carl,
 Don't know the exact answer, but Apache is scaled better than Tomcat's Http
 server.  This can be proven during a load test.
 
 On 2/2/06, Carl Crawford [EMAIL PROTECTED] wrote:
 
  How many users can tomcat support at one time.  We are using tomcat's
  build in http server not apache.
 
  Thanks,
  Carl
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 


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



Re: Jakarta subproject-package system

2006-01-10 Thread robert burrell donkin
On Wed, 2005-12-28 at 09:55 -0100, jan meskens wrote:
 Hello Henri,
 
 I was looking to these page :
 http://jakarta.apache.org/commons/charter.html
 
 Maybe that's the wrong page for these info... .

not wrong probably just a little confusing

the jakarta commons charter encapsulates the opinions of the jakarta pmc
at that particular moment in time. 

- robert


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



Re: Notice of intent.... #2

2006-01-10 Thread robert burrell donkin
On Tue, 2006-01-10 at 10:20 -0800, Martin Cooper wrote:
 On 1/10/06, Henri Yandell [EMAIL PROTECTED] wrote:
 
 
  As a second email in the Notice of intent series; here's what I think
  being a Jakarta component will be like in the future.
 
  * Jakarta is a collection of components. Hopefully all sitting at the same
  level. ie) a big bag of things.
 
  * Groups exist. These are categorically not subprojects, but a way to
  allow for slicing of the website etc. Some groups may have their own mail
  list; thus the importance of making sure they don't become subprojects. An
  important rule will probably be that they must do votes on the main list.
 
 
 I prefer the term groupings (which, interestingly, you switch to below ;)
 over groups. 

+1

gave up groups (topological or even finite simple) when i left uni ;)

 I also think we should allow the component:grouping
 relationship to be 1:N, since not all components will fit tidily into a
 single grouping. As a corollary, I don't believe groupings should have their
 own mailing lists.

not sure

i like the idea of fuzzy groupings with 1-N

components need to be mapped 1-1 to dev mailing lists but 1-N would work
fine on user lists. might be possible to factor 1-1 dev lists (for
traffic purposes) whilst retaining fuzzy users lists.

 Hopefully we can keep it at a point where the groups are really just there
  to refine the flow of mail, not to separate it. HttpComponents is an
  example of this (though not a good one as most of its components came from
  HttpClient). WebComponents (formerly hoped to be known as Silk) is another
  example.
 
  Commons would be groupalized out. Hopefully. Groupings are not vague names
  - HttpComponents good, Silk bad. CoreComponents good, Turbine bad. The
  idea with that being that boring grouping names are intentionally dull, no
  subcommunity identification.
 
  * No svn authentication beyond being in the jakarta group. Velocity coders
  have rw access to POI.
 
  * Improved Committer-PMC process. Chair's responsibility (I've failed at
  this so far) is to turn around the new committer process. A new committer
  of 6 months is effectively voted against going to the PMC, not for. Might
  not be able to make it exactly that way, but the idea being that joining
  the PMC is the exception, not the norm. Personally I'd like to see
  committership be removed if people repeatedly are not allowed onto the
  PMC.
 
 
 Well, except that the process is that the PMC has to vote in a new committer
 to the PMC and then notify the board of that vote. I'm definitely not in
 favour of magic notifications to the board when the six months are up,
 without an associated vote.

i don't like the idea of magic notifications (to the board) but
something needs to be done: ATM we're dysfunctional. just take a look at
the nominations per nominator over the last year or two: nomination
hasn't become ingrained in the culture.

ATM we're slipping up but maybe statistics and reminders may be better
for the moment than automatic nomination...

- robert


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



Re: feed parser enclosure support

2005-11-02 Thread robert burrell donkin
this list is for general matters effecting the whole of jakarta. please
read http://jakarta.apache.org/site/mail.html and subscribe to either
commons-user or commons-dev. please read
http://jakarta.apache.org/site/mail.html and remember to add
[feedparser] as a prefix to the subject.

- robert

On Tue, 2005-11-01 at 10:34 -0800, m h wrote:
 Hello
 
 Trying to use feedparser for some rss parsing tasks --
 need enclosure support.  The LinkFeedParserListener
 mentions that it is there, but there are no
 onEnclosure methods -- I cant find any such methods in
 any of the classes.  
 
 Whats wierd is when I go to 
 
 http://jakarta.apache.org/commons/sandbox/feedparser/xref/org/apache/commons/feedparser/RSSFeedParser.html
 
 I do see some support for enclosures, however in the
 RSSFeedParser class available in cvs, those sections
 are absent.
 
 Can anyone help on this issue?  Thank you in advance.
 
 
 
 
   
 __ 
 Yahoo! FareChase: Search multiple travel sites in one click.
 http://farechase.yahoo.com
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


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



Re: no jsp2 path possible NO SUFFICIENT DOCUMENTING

2005-10-27 Thread robert burrell donkin
the usual comment when this arises is: please post to the correct list
(which is tomcat-user please read http://tomcat.apache.org/lists.html). 

however, i'd would strongly suggest that you research your problem and
try to prepare a better question before posting. tomcat is a
specification-compliant servlet container and i suspect that your
question is really related to the servlet specification in general
(rather than tomcat specifically). it does not contain general
information about creating J2EE application since better sources exist
elsewhere.

there are very many books and articles (in many languages) which cover
tag libraries. please take a while to google and then read them. IMHO
this will prove a lot more productive than asking on the list.

- robert

On Tue, 2005-10-25 at 01:00 +1000, NICEPHOTOG wrote:
 [Tomcat docs not sufficient about .tld  and tag handler classes]
 FINALLY THIS MESSAGE IS TO LET YOU KNOW THERE IS NO SUFFICIENT
  DOCUMENTING FOR WEB APP CUSTOM TAG CLASSES RELATING EITHER JAR OR
 DIRECTORY FOR JASPER-TOMCAT5.0 ANYWHERE ON THE WEB OR
 THE PLANET BUT TRUTHFULLY FOR ANY LEVEL OF JSP AND ENGINE.
 [its all well to say org.apache... says its a path in a jar but its not part 
 of my or
 anyone elses application and i have looked through suns jsp2.0 specs,
 then thats j2ee and that would probably operate FOR J2EE.]
 I cannot find either a path or jar file path system to operate the 
 tag handlers through .tld for tomcat 5.0
 Im new to tomcat but i have never found and for the point ANY documentation
 that explicitly tells the path to a tag handler class in the .tld relative or 
 in context
 to the web application custom web-app base.
 web.xml servlet matching, most do not find required for custom tag handler 
 classes
 but i have got it down to the .tag will load but the classes do not and are 
 not
 explicitly either not loading or not found after being sure the path is either
 /WEB-INF/tags or /META-INF/tags with the .tld /WEB-INF/wap.tld
 in the .war
 The servlet operated ok but the jsp custom tagging cannot be located
 as either jar or class.
 jsp-config
 jsp-property-group
 tag-class
 name
 tag(not tag-file)
 
 thanks anyway though
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


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



Re: Fw: Subscribing a new Project into Jakarta

2005-10-12 Thread robert burrell donkin
On Tue, 2005-10-11 at 14:36 -0300, [EMAIL PROTECTED] wrote:
 
 Hello, my name is João, i'm a Brazillian Java developer. 

hi João

 In this email i will describe the general proposal for my project, the
 JFTP4I (Java FTP for Integration). My intentions are basically to put
 my project inside the Jakarta/Apache umbrella. 

the way these things are done now is through the incubator
http://incubator.apache.org/. please take some time to read the
documentation on the site. 

i don't want to dampen your enthusiasm but i'd like to offer a realistic
assessment of some of the obstacles you may find upon your way...

jakarta's been self consciously shrinking over the last few years (it's
just too big and too complex) with a lot of old sub-projects graduating
to lop level status. it's more difficult now to persuade people that new
sub-projects should be accepted. (of course, this doesn't mean that
JFTP4I couldn't aim for top level or for a sub-project of another
project)

there's quite a deal of ceremony associated with incubation now: it
requires time, dedication and effort to succeed (up and beyond creating
a successful open source project). the aim of incubation is to try to
help the new project to learn apache ways and adopt systems which we
believe lead to healthy long term projects but the process is still
evolution and there are some rough edges left still...

 For that i give you a detailed description of my project. 
 
 Project Description:  
 
 The JFTP4I is a new idea for the concept of using FTP for integration
 purposes. Here in Brasil (and i think very much in the rest of the
 world), all the legacy systems are basically using FTP as a way of
 integrating different platforms running under TCP/IP.

i wouldn't have thought associated dynamic applications with ftp but now
you pointed it out, it can see why a project like this makes sense :)  

snip

 The project has already started (exists), and is hosted in the
 sourceforge.net. I have 3 friends helping me develop the solution. The
 FTP engine, trace, and Log are already done, and we are now working in
 the transaction and delegation parts for the requests. You can found a
 alpha version to be download in the following link:
 http://sourceforge.net/projects/jftp4i 
 Obs.: I don´t now if you guys can actually download the code, but if
 this is important, and you could not download the source, please
 contact me and i will be glad to send to you. 
 PS.: This is not another FTP Server, this is actually a framework that
 uses a FTP engine to dinamically generate content. 

BTW http://producingoss.com/ is a good read for people starting open
source projects...

all the best and good luck with jftp4i

- robert


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



Re: [Request for Comment] Http Components proposal

2005-09-25 Thread robert burrell donkin
On Sun, 2005-09-25 at 12:27 +0200, Oleg Kalnichevski wrote:
 On Sat, 2005-09-24 at 20:34 -0700, Martin Cooper wrote:
  On 9/24/05, Henri Yandell [EMAIL PROTECTED] wrote:
 ...
   * Jakarta Http Components MUST be content agnostic. The project DOES NOT
   develop components intended to produce or consume content of HTTP
   messages.
  
  
  While I understand what you're trying to say here, this wording appears to
  preclude some of what is in HttpClient today, namely multipart content
  handling.
  
 
 Hi Martin,
 
 This statement is not accidental. The plan is to factor the multipart
 content handling out of HttpClient. There's already a project in Commons
 Sandbox led by Mark R. Diggory
 http://svn.apache.org/repos/asf/jakarta/commons/dormant/codec-multipart/ 
 for that end. 
 Unfortunately the project has been dormant for quite some time but the plan 
 is to revive 
 the project at some point, get it graduate from Sandbox and possibly get it 
 merged with
 Commons Codec proper at some point of time.

IMHO a clause need to be inserted to allow the sub-project maintain the
existing codebase (since it will be out-of-scope otherwise). actually,
i'd prefer to see the pmc give the explicit responsibility for
maintenance to the sub-project.

   * Jakarta Http Components DOES NOT define a server side API on top of the
   low level transport API.
  
  
  Again, I understand what you want to say. However, I think it would be
  better said in terms that make it clear that it is intended for use on the
  client side _of the protocol_, since many people are using HttpClient on the
  server side today, but as a client to other servers.
  
 
 Actually we see more and more often HttpClient code used to implement
 server side of the protocol as well. This statement is primarily to
 ensure that the project will not sidetrack into developing and
 _application_ API competing with javax.servlet API. We merely want to
 provide low level generic transport primitives. 

IMHO if this is the vision then it would be better to rephrase the final
clause to make this clear. maybe something like:

* Jakarta Http Components will provide ONLY a toolset of low level
generic transport APIs. In particular, server side application layer
APIs WILL NOT be developed.

- robert


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



Re: GMANE

2005-09-01 Thread robert burrell donkin
On Thu, 2005-09-01 at 15:13 -0400, David Smiley wrote:
 Hello all.  I love using GMANE ( http://www.gmane.org ) to access 
 mailing lists because:
 1. one stop mailing-list shopping -- a consistent experience
 2. NNTP access
 3. easiest path to posting a question to a list that you're not a member 
 of, examining the responses, and then leaving.
 4. emails for lists don't go into my mailbox; I don't want them there (I 
 prefer NNTP)
 
 I think a mention of GMANE on Jakarta would be helpful for the 
 community.  This page could use it:
 http://jakarta.apache.org/site/mail.html   (by the Archives section)
 And perhaps elsewhere; I don't know.

if you think so then create a patch and contribute it though bugzilla :)

- robert


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



Re: JK Isapi Redirector and IE6 problem

2005-08-30 Thread robert burrell donkin
hi Thomas

you'll get a faster and better response if you ask this question on the
tomcat user list. please read http://jakarta.apache.org/site/mail.html.

- robert

On Tue, 2005-08-30 at 07:32 +0100, Kubiak, Thomas wrote:
 Hello guys.
 
 We have the following configuration:
 
 Server 1:   Tomcat 5.5.9
 
 Server 2:   Win 2003 Server + IIS
 Jakarta Isapi Redirector 1.2.14
 
 All client machines uses MS IE6 with activated integrated windows
 authentification.
 
 Now our problem is, that with active windows authentification the user will
 not be identified by the server running the IIS and the Isapi Redirector.
 The common Windows login window appears, but even when we put in the right
 login-data the user can not be logged in. It asks for login data for server
 2. Anonymouse access is diabled within the virtual host on the IIS machine.
 Integrated windows auth. is enabled.
 
 When turning off that feature in IE6, the login + redirection works ok. But
 that's the problem, we need this integrated windows authentification
 feature enabled for other applications.
 
 We use this code to idetify the user:
 
 %
 Response.Cookies(user).Value = User.Identity.Name
 Response.Cookies(authorization).Value = ntlm
 %
 
 and then redirect to server 1. Server 1 then uses that cookie to confirm the
 userlogon.
 
 Any ideas how to get this working with enabled windows authentification ?
 
 Thanks + regards
 
 Thomas
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


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



Re: List moderation

2005-08-13 Thread robert burrell donkin
On Thu, 2005-08-11 at 22:13 +0200, Torsten Curdt wrote:
  we're moving towards insisting on pgp keys so we could check and
  moderate through all signed apache.org email without danger.
 
 
 You mean forcing all subscribers to use gpg
 Although I love the idea of forcing people to
 sign their mails
 
 http://vafer.org/blog/tcurdt/archives/93.html
 http://vafer.org/blog/tcurdt/archives/000174.html
 
 I fear there is no way we can get away with that.

not for all posts, just for those unsubscribed. 

given that there's a rising tide of demand to make all lists subscriber
only, i think that this would be better than simply sending all
unsubscribed posts to /dev/null.

  This would leave open for moderation only a few broad lists (for
  instance [EMAIL PROTECTED], which I have the pleasure to
  moderate :-( ), killing a lot of wasted hours.
 
  Also, FYI, joes2 is doing some info gathering on moderation  
  request to
  aid us in filtering incoming moderation spam. See
  irc://irc.freenode.net/#asfinfra for more info.
 
 Language is english for all lists. Filtering out
 mails with all kinds of weird characters would be
 a first step. Still wondering why we don't have
 that already.

+1

  i've been wondering for a while whether it'd be better to move towards
  bots and some sort of web app for smarter collaborative moderation.  
  (one
  moderators marks a message as spam and all identical ones are
  automatically rejected from all pending lists.)
 
 That would be much better ...but it's also quite
 an effort to set this up. I just don't know whether
 it's worth it for those few cross postings

i have personal itches about some of the required technologies and i
know some of the spam assassin guys are keen on some of the others.
maybe i'll try to ambush some people on irc... 

- robert


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



Re: List moderation

2005-08-11 Thread robert burrell donkin
On Wed, 2005-08-10 at 17:25 +0200, Santiago Gala wrote:
 El mié, 10-08-2005 a las 11:27 +0200, Torsten Curdt escribió:
   Hi,
  
   I've been a moderator for the bcel-dev@jakarta.apache.org and
   bcel-user@jakarta.apache.org for a few months now. In that time there
   have been 2 valid emails from people who weren't subscribed, and a few
   thousand spam mails.
  
   I'm rather tired of being a human spam filter for the mailing list. As
   the ratio of bad to good emails is so high, I suggest that all mails
   from unsubscribed users simply be discarded making moderation
   unnecessary.
  
   What's the general opinion about this?
  
  The question is why do we use moderation at all?
  
  I can see only the reason of cross-posting
  which is discouraged anyway ...and still could
  be done by people who are subscribed to both lists.
  
  ...so I am with you on this
  
 
 with some scripting magics, we could add to the allow list of all
 maining lists all apache.org addresses and aliases set up in some files
 (iclas.txt and other ones), which would also kill the main use case for
 moderation.
 
 Even allowing all email addresses subscribed to any apache.org list to
 post to the rest of the public onesm though this would be less safe.

we're moving towards insisting on pgp keys so we could check and
moderate through all signed apache.org email without danger. 

 This would leave open for moderation only a few broad lists (for
 instance [EMAIL PROTECTED], which I have the pleasure to
 moderate :-( ), killing a lot of wasted hours.
 
 Also, FYI, joes2 is doing some info gathering on moderation request to
 aid us in filtering incoming moderation spam. See
 irc://irc.freenode.net/#asfinfra for more info.

i've been wondering for a while whether it'd be better to move towards
bots and some sort of web app for smarter collaborative moderation. (one
moderators marks a message as spam and all identical ones are
automatically rejected from all pending lists.)  

- robert


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



Re: Web Components/Common project

2005-08-08 Thread robert burrell donkin
On Mon, 2005-08-08 at 13:14 -0400, Frank W. Zammetti wrote:
 On Mon, August 8, 2005 12:42 pm, robert burrell donkin said:
  On Mon, 2005-08-08 at 01:54 -0300, Felipe Leme wrote:

snip

  Anyway, the Jakarta Taglib Project has voted how it would like to take
  part on this new project, and the result was:
 
  1.The Jakarta Taglibs Project would like to be merged into the project
  2.The Jakarta Standard Taglib should then be a project of its own
  3.The remaining taglibs would be gradually migrated to the new project,
  the most actives first
  4.It's not decided yet if the migrated taglibs would have a newer
  release prior to the migration
 
 I'm not sure there was ever a consensus on what the overall structure of
 the project would be either (someone can correct me if I'm wrong on that
 point)... It seems like there might be a risk of sub-projects within
 sub-projects within sub-projects, which I'm not sure would be the best
 organizational stucture... if you had Jakarta Taglibs as a sub-component
 of the JWP4J project (assume for the sake of argument that name sticks),
 and then have Jakarta Standard Taglib as a sub-project of Jakarta Taglibs,
 is that the best structure to have?  How deep of a hierarchy is OK and how
 deep is too deep?

any deep is too deep :) 

AIUI everything will be flat: collective management and only social
divisions. standard taglibs will become a jakarta sub-project.

BTW is there any real reason not to start the promotion process for
standard taglibs ASAP?

- robert


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



[ANNOUNCEMENT] Jakarta-Commons Betwixt 0.7 Released

2005-07-27 Thread robert burrell donkin
The Jakarta Commons Team is pleased to announce the latest release of
common-betwixt from Apache.

Betwixt is a flexible, dynamic, start-from-beans xml-object binder. For
more information on Betwixt, please see
http://jakarta.apache.org/commons/betwixt/.

Betwixt 0.7 is a feature release adding numerous new features. It is
binary compatible with the last release (0.6) but there are a small
number of semantic changes. It is believed that these should have
minimal impact on existing users but these users are advised to read the
release notes.

Binary and source distributions can be download from
http://jakarta.apache.org/site/downloads/downloads_commons-betwixt.cgi.
Since the distributions are download from mirrors, please check the md5
sum and verify the detach signature using the files linked from the
download page (hosted on an ASF server).  

Robert


signature.asc
Description: This is a digitally signed message part


Re: Copyright line in code submissions

2005-07-27 Thread robert burrell donkin
On Tue, 2005-07-26 at 08:57 +0100, Danny Angus wrote:
 Robert wrote:
 
 i sometimes find it hard to work out where opinion stops and policy
 begins...
 
 Then again... it is surely the PMC's business to know or find out, and
 enforce?
 
 I mean, IANAL but as a manager I would think that if the PMC is charged
 with oversight it is surely marginally better for the PMC as a body to
 mis-interpret and mis-enforce centrally than for there to be n different
 personal mis-interpretations of legal requirements of all kinds.
 
 I would have thought that a jakarta web-page of legal FAQ would at least
 allow us to have an auditable standard, and if the standard is wrong it
 should then be wrong for all to see, wrong everywhere to the same degree
 and require one fix, rather than a big analysis effort up front.

i think i'm (almost) persuaded by this. it's been too fuzzy for too long
and we need to start tightening things up. 

we have been trying to move any more general material from jakarta to
the foundation site. so, this would be better at the foundation level.
probably better quality of oversight there, as well.  

i follow the licensing list. IIRC there was a plan to create a legal FAQ
for committers. i might volunteer to set something in motion...

- robert


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



Re: svn commit: r225366 - in /jakarta/site: docs/site/downloads/downloads_tomcat-connectors.html xdocs/downloads/downloads.xml

2005-07-26 Thread robert burrell donkin
hi Jean-Frederic

docs/site/downloads/download_tomcat.html is generated and so these
changes are in grave danger of being reverted next time someone
regenerates the site.

- robert

On Tue, 2005-07-26 at 18:08 +, [EMAIL PROTECTED] wrote:
 Author: jfclere
 Date: Tue Jul 26 11:08:22 2005
 New Revision: 225366
 
 URL: http://svn.apache.org/viewcvs?rev=225366view=rev
 Log:
 Arrange dowload page for mod_jk.
 
 Modified:
 jakarta/site/docs/site/downloads/downloads_tomcat-connectors.html
 jakarta/site/xdocs/downloads/downloads.xml
 
 Modified: jakarta/site/docs/site/downloads/downloads_tomcat-connectors.html
 URL: 
 http://svn.apache.org/viewcvs/jakarta/site/docs/site/downloads/downloads_tomcat-connectors.html?rev=225366r1=225365r2=225366view=diff
 ==
 --- jakarta/site/docs/site/downloads/downloads_tomcat-connectors.html 
 (original)
 +++ jakarta/site/docs/site/downloads/downloads_tomcat-connectors.html Tue Jul 
 26 11:08:22 2005
 @@ -2,7 +2,7 @@
  html
  head
  meta http-equiv=Content-Type content=text/html; charset=iso-8859-1/
 -titleThe Jakarta Site - Tomcat Connectors (mod_jk, mod_jk2, mod_webapp) 
 Downloads/title
 +titleThe Jakarta Site - Tomcat Connectors (mod_jk, mod_jk2) 
 Downloads/title
  link rel=stylesheet href=/style/style.css type=text/css/
  /head
  body
 @@ -161,8 +161,8 @@
  td class=main-body valign=top align=left
  div class=section
  div class=section-header
 -a name=Tomcat Connectors (mod_jk, mod_jk2, mod_webapp) Downloads
 -strongTomcat Connectors (mod_jk, mod_jk2, mod_webapp) Downloads/strong
 +a name=Tomcat Connectors (mod_jk, mod_jk2) Downloads
 +strongTomcat Connectors (mod_jk, mod_jk2) Downloads/strong
  /a
  /div
  p
 @@ -197,7 +197,7 @@
  p
  The codeKEYS/code link links to the code signing keys used 
 to sign the product. The codePGP/code link downloads the OpenPGP 
 compatible signature from our main site. 
  /p
 -pFor more information concerning Tomcat Connectors (mod_jk, mod_jk2, 
 mod_webapp), see the a 
 href=http://jakarta.apache.org/tomcat/connectors-doc/; class=nameTomcat 
 Connectors (mod_jk, mod_jk2, mod_webapp)/a site. /p
 +pFor more information concerning Tomcat Connectors (mod_jk, mod_jk2), see 
 the a href=http://jakarta.apache.org/tomcat/connectors-doc/; 
 class=nameTomcat Connectors (mod_jk, mod_jk2)/a site. /p
  div class=links
  span class=link
  a href=http://www.apache.org/dist/jakarta/tomcat-connectors/KEYS;KEYS/a
 @@ -215,18 +215,18 @@
  /div
  ul
  li class=download
 -a 
 href=[preferred]/jakarta/tomcat-connectors/jk/source/jakarta-tomcat-connectors-current-src.tar.gzJK
  1.2.10 Source Release tar.gz/a
 +a 
 href=[preferred]/jakarta/tomcat-connectors/jk/source/jk-1.2.14/jakarta-tomcat-connectors-1.2.14.1-src.tar.gzJK
  1.2.14 Source Release tar.gz/a
  ul class=attributes
  li
 -span class=pgp[a 
 href=http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jakarta-tomcat-connectors-current-src.tar.gz.asc;pgp/a]/span
 +span class=pgp[a 
 href=http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jk-1.2.14/jakarta-tomcat-connectors-1.2.14.1-src.tar.gz.asc;pgp/a]/span
  /li
  /ul
  /li
  li class=download
 -a 
 href=[preferred]/jakarta/tomcat-connectors/jk/source/jakarta-tomcat-connectors-current-src.zipJK
  1.2.10 Source Release zip/a
 +a 
 href=[preferred]/jakarta/tomcat-connectors/jk/source/jk-1.2.14/jakarta-tomcat-connectors-1.2.14.1-src.zipJK
  1.2.14 Source Release zip/a
  ul class=attributes
  li
 -span class=pgp[a 
 href=http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jakarta-tomcat-connectors-current-src.zip.asc;pgp/a]/span
 +span class=pgp[a 
 href=http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jk-1.2.14/jakarta-tomcat-connectors-1.2.14.1-src.zip.asc;pgp/a]/span
  /li
  /ul
  /li
 
 Modified: jakarta/site/xdocs/downloads/downloads.xml
 URL: 
 http://svn.apache.org/viewcvs/jakarta/site/xdocs/downloads/downloads.xml?rev=225366r1=225365r2=225366view=diff
 ==
 --- jakarta/site/xdocs/downloads/downloads.xml (original)
 +++ jakarta/site/xdocs/downloads/downloads.xml Tue Jul 26 11:08:22 2005
 @@ -1047,13 +1047,13 @@
/downloads
  /project
  
 -project id=tomcat-connectors name=Tomcat Connectors (mod_jk, 
 mod_jk2, mod_webapp) href=http://jakarta.apache.org/tomcat/connectors-doc/;
 +project id=tomcat-connectors name=Tomcat Connectors (mod_jk, 
 mod_jk2) href=http://jakarta.apache.org/tomcat/connectors-doc/;
downloads keys=jakarta/tomcat-connectors/KEYS 
 primary=http://www.apache.org/dist/; mirrored=true 
 archive=http://archive.apache.org/dist/jakarta/tomcat-connectors/; 
 md5-text=false
  group label=JK 1.2
download name=JK 1.2 Binary Releases 
 href=jakarta/tomcat-connectors/jk/binaries/ directory=true/
group label=Source
 -  download name=JK 1.2.10 Source 

Re: svn commit: r225366 - in /jakarta/site: docs/site/downloads/downloads_tomcat-connectors.html xdocs/downloads/downloads.xml

2005-07-26 Thread robert burrell donkin
On Tue, 2005-07-26 at 16:52 -0400, Rahul Akolkar wrote:
 On 7/26/05, robert burrell donkin [EMAIL PROTECTED] wrote:
  hi Jean-Frederic
  
  docs/site/downloads/download_tomcat.html is generated and so these
  changes are in grave danger of being reverted next time someone
  regenerates the site.
 snip/
 
 I also see a pending mod for Stefan's update of whoweare.html. 

i posted something to stefan off list (wanted to email him anyway).

 I just regenerated the site, but I avoided reverting those two. I could
 easily have committed those; I just didn't know what the etiquette
 is.

for me, it's a judgement call depending on the person and the change.
hopefully, other people will jump in here with more general opinions...

- robert


signature.asc
Description: This is a digitally signed message part


Re: Copyright line in code submissions

2005-07-25 Thread robert burrell donkin
On Mon, 2005-07-25 at 17:22 +1200, Simon Kitching wrote:

snip

 Basically, I think it's legal for code submitted to apache to have the
 copyright of the original author but there are good reasons to avoid
 this if possible.
 
 Certainly the norm for commons projects is to have only one copyright
 statement, being that of the ASF.

+1

 I'd be interested to know if there is a general Apache policy on this.

i sometimes find it hard to work out where opinion stops and policy
begins...

cliff schmidt seems like a good person
(http://www.apache.org/foundation/) to ask and is pretty approachable. 

 IANAL and all that.

+1

legal discuss is the list for committers where those who are lawyers
hang out...

- robert


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



Re: [RESULT][POLL] drop point 12

2005-07-05 Thread robert burrell donkin
+1

- robert

On Mon, 2005-07-04 at 02:16 -0400, Henri Yandell wrote:
 We should do the same on Commons at some point. Throw out the ones that 
 seem dead.
 
 Hen
 
 On Sun, 3 Jul 2005, robert burrell donkin wrote:
 
  i count 4 +1's
 
  the consensus seems to be in favour of removal so that's what i'm going
  to do.
 
  i propose to leave retain the number by noting those that have been
  deleted (rather than removing them).
 
  - robert
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


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



[RESULT] [POLL] drop 8

2005-07-05 Thread robert burrell donkin
i count 5 +1's and no objections so i'm going to go ahead and delete
it. 

- robert

On Sun, 2005-07-03 at 19:44 +0100, robert burrell donkin wrote:
  8. Packages are encouraged to either use JavaBeans as core objects, a
  JavaBean-style API, or to provide an optional JavaBean wrapper.
 
 doesn't seem very relevant. i think that it'd be simpler just to drop
 it.
 
 here's my +1
 
 - robert
 
 --8---
 [ ] +1 Get rid!
 [ ] -1 Keep it (please give a reason...)
 --
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


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



Re: [site] Added svn resource to library.xml

2005-07-05 Thread robert burrell donkin
committed. many thanks.

- robert

On Tue, 2005-07-05 at 20:19 +0200, Fredrik Westermarck wrote:
 Henri Yandell wrote:
 
  Is there a BZ or Jira where one can open issues and add patches to the 
  jakarta-site module? Or is all such requests handled on this ml?
 
   This mailing list is the best place.
 
 Hi!
 
 Here's the patch that I promised.
 
 Regards,
 Fredrik Westermarck
 Plain text document attachment (library.diff)
 Index: xdocs/site/library.xml
 ===
 --- xdocs/site/library.xml(revision 208774)
 +++ xdocs/site/library.xml(arbetskopia)
 @@ -73,6 +73,12 @@
  /p
  
  p
 +ba href=http://svnbook.red-bean.com/;Version Control with 
 Subversion/a/bbr/
 +Written by Ben Collins-Sussman, Brian W. Fitzpatrick amp; C. Michael Pilato.
 +This is a Subversion manual that currently provides information about 
 Subversion 1.0 and 1.1.
 +/p
 +
 +p
  h3Source Code Philosophy Resources /h3
  The following are a set of articles written about the recent source code 
 movements that help
  illustrate some of the attributes of a collaborative project such as this. 
 You may not agree with all of
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


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



Re: new components

2005-07-05 Thread robert burrell donkin
there doesn't see any enthusiasm for those new ideas and no objections
to phil's draft. i think we should go ahead and make the changes
suggested by phil.

- robert 

On Sun, 2005-07-03 at 22:39 +0100, robert burrell donkin wrote:
 On Sun, 2005-07-03 at 13:13 -0700, Phil Steitz wrote:
  Here is a stab at replacement text for 15, 17 and 18.
 
 great :)
 
 looks good but threw up some ideas...
 
  15-1 Any member of the community may propose a new package. To be 
  accepted, a package proposal must receive majority approval of the
  subproject committers and at least one committer must volunteer to serve 
  as an initial package team member. Proposals should identify the 
  rationale for the package, its scope, its interaction with other 
  packages and products, the insert-subproject-name resources, if any, 
  to be created, the initial source from which the package is to be 
  created, and the sponsoring committers.
  
  15-2 The subproject will maintain an svn repository, referred to as the 
  isandbox/i, as a workplace for new packages.  Once approved, new 
  packages must all begin in the sandbox. Any apache committer may 
  contribute code directly to the sandbox and this code may form the 
  initial source for new packages.  Code from existing apache projects 
  can, with the support of the contributing projects, also be imported 
  directly into the sandbox.  Finally, patches contributed incrementally 
  by community members may be committed to the sandox by a subproject 
  committer. If the initial source for a new package is from outside of 
  apache, the new package must be brought into apache via the apache 
  incubator.
 
 not sure but wonder whether we might need to tightening this last
 sentence so that it can't be read as implying that having only a portion
 of the initial source from external sources is ok. opinions?
 
  15-3 A majority vote among subproject commiters is required to 
  graduate a package from the sandbox to become a proper package. Only 
  proper packages may make releases. If a package remains in the sandbox 
  for more than six months, a majority vote will be required to prevent 
  its being archived from svn and removed from the subproject web site and 
  any other public locations (e.g. nightly or continuous integration 
  builds). Proper packages may not release code with dependencies on 
  sandbox packages.
 
 1. i wonder whether it'd be better to have bi-annual reviews to simplify
 administration. in january, review all sandbox components which were
 created before the previous july. could run them as a single vote.
 
 2. i wonder whether we actually need to remove them from svn: just could
 copy them into an archive directory.
 
 - robert
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


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



Re: [POLL] Marking changes

2005-07-05 Thread robert burrell donkin
On Tue, 2005-07-05 at 15:23 -0400, Rahul Akolkar wrote:
 (Was: Re: [Jakarta Wiki] Update of
 DraftCharterForWebComponentCommons by RobertBurrellDonkin) - pasted
 here since the title was getting too long ;-)
 
 Thanks for making the changes Robert!
 
 I propose we wrap changes in {{{DELETED}}} and {{{/DELETED}}} tags
 (or ADDED tags, as appropriate) rather than purely relying on font
 minutae. Amongst other things, that will work better for
 accessibility. I'm +1.

if it'll make things easier to read and you're willing to do the
formatting changes, i'm +1

- robert 


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



Re: Dormant guidelines proposal?

2005-07-03 Thread robert burrell donkin
On Fri, 2005-07-01 at 01:55 -0500, Curt Arnold wrote:
 There has been some discussion about modifying the Logging Services  
 project bylaws (http://logging.apache.org/site/bylaws.html) to  
 address some concerns particular to the project.  I was researching  
 the Jakarta guidelines and stumbled across http://jakarta.apache.org/ 
 site/proposal.html.  It is referenced at the bottom of  http:// 
 jakarta.apache.org/site/guidelines.html as a working proposal, but it  
 does not appear from the SVN log to have any activity for over two  
 years.

i thought that it'd been removed during spring cleaning earlier this
way. anyone remember any reasons why it was retained?

 Was there a resolution on the proposal?  If so or if has been  
 abandoned, then it might be good to pull it and the link from the  
 site or at least update the status.  Has the activity moved elsewhere  
 or is it just sleeping?  

it's a bit of a long story. the only real records exist on the (private)
archives of the jakarta pmc mailing list. 

IIRC this represents the earliest stage of the long road towards reform.
the consensus was that the problem wasn't the guidelines but the basic
bylaws. once these were fixed, arguing about the guidelines became
moot...

 If either was going to be considered as a  
 starting point for a rework of the LS bylaws, would you recommend the  
 proposal or the accepted guidelines?

i'm not sure whether it'd be a good idea to start from either. i'd start
from the bylaws and from henri's wiki pages. 

it seems to me that the guidelines have really turned into a directory
page for general information. a lot of the information linked to
probably belongs at the foundation level (though would need editing).

 I haven't had a chance to attempt to compare and contrast the current  
 and proposed guidelines, but the proposal's one page format left a  
 better impression since you can see everything at one glance.

the proposals are a good document in a cool format but didn't solve the
real problems

 One of significant differences between our current bylaws and either  
 of the proposal or existing guidelines is that the PMC is tasked with  
 electing new committers.  There is a desire to move that decision  
 towards the sub-project, 

i recommend asking this question again on community. 

the model used by jakarta is believed (by many seniors figures from
other projects) to be both unusual (within apache) and far from best
practise. some feel that too much delegation to sub-projects may be to
the detriment of the community spirit at project level. others that it
creates problems with oversight. IMHO the model works ok for us here but
i'd hesitate to recommend it to other projects. 

 but I'm concerned that without any role for  
 the PMC and no private medium for the vote, that there isn't a clean  
 way for the PMC to address a potential disruptive or legally  
 entangling committer candidate except to accept the sub-project vote  
 and for the PMC to attempt to revoke his committer rights requiring a  
 full consensus.  

AIUI no project is actually entitled to abdicate responsibility for
oversight. IMHO the right way to proceed (if this happened here at
jakarta) would be to -1 the result posted to the pmc list and so veto
the action (lazy consensus). this should force a vote on the pmc list.

one of the problems with holding votes for committers on public lists is
that there is no way that the individual in question could be kept from
the knowledge of their rejection. 

 There would also be no private forum to discuss any  
 sensitive issues since only the PMC has a private list.   

this is a problem that we have here at jakarta. current practise is that
there is usually a certain amount of private chat (but it would be
better if this happened on a private list).

 For the LS bylaws, I was considering suggesting a two-phase vote, lazy 
 consensus  
 at the sub-project and then lazy approval followed by lazy consensus  
 at the PMC.  Considering the damage a rogue committer could do,  
 having the PMC with some means of intervening without invoking the  
 nuclear option would seem to be warranted.

the pmc is charged with oversight. whatever system is agreed must
provide that.

- robert


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



[RESULT][POLL] drop point 12

2005-07-03 Thread robert burrell donkin
i count 4 +1's

the consensus seems to be in favour of removal so that's what i'm going
to do. 

i propose to leave retain the number by noting those that have been
deleted (rather than removing them).

- robert


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



Re: mailing lists for components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]

2005-07-03 Thread robert burrell donkin
On Sat, 2005-07-02 at 14:33 -0400, Martin Cooper wrote:
 On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote:
  On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
  
   4.1 in the guidelines repeats the error that I thought was fixed in the
   j-c guidelines saying that each package has its own mailing list.  If
   that is intentional, I think that is a *bad* idea, especially to start.
  
  it was intentional in as much as it was a copy of the jakarta commons
  charter :)
  
   Don't like the many little lists implied by 11 -- dev + user works fine
   in j-c (I know some disagree, but I personally view this as the key to
   the health of j-c)
  
  i agree. just dev and user lists.
  
  in jakarta commons, the common mailing lists hold together the single
  community. i'd like to see just one mailing list with components using
  prefixing (as per jakarta commons). i'd like to see changes to the draft
  so that it's clear that this will be the arrangement.
  
  opinions?
 
 +1 to just one dev and one user list, shared for all components, a la
 Jakarta Commons.

i think we've established a consensus on this. any objections to
amending the draft appropriately? 

- robert


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



[POLL] drop 8

2005-07-03 Thread robert burrell donkin
 8. Packages are encouraged to either use JavaBeans as core objects, a
 JavaBean-style API, or to provide an optional JavaBean wrapper.

doesn't seem very relevant. i think that it'd be simpler just to drop
it.

here's my +1

- robert

--8---
[ ] +1 Get rid!
[ ] -1 Keep it (please give a reason...)
--



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



Re: new components

2005-07-03 Thread robert burrell donkin
On Sat, 2005-07-02 at 14:52 -0400, Martin Cooper wrote:
 On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote:
  On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
  
  snip
  
   Interpreted literally, 17 goes against standard practice in jakarta (or
   apache, to my knowledge, other than in the incubator).  I would
   recommend that new packages require existing committers to support them.
   I would at least recommend changing Anyone to Any apache committer.
If an individual has already contributed enough to be voted in as a
   committer, then that should be done in a separate VOTE.
  
  this certainly doesn't reflect the current practise in the jakarta
  commons. though anyone can propose a new component, they really won't
  have any chance of winning a VOTE unless they have the support of
  existing committers.
  
  there is also the issue of the incubator: any new component bringing
  code from outside apache would need to be incubated.
 
 We have a few different scenarios here, I believe.
 
 1) A new component is proposed, with no existing code to back it up.
 I'm not sure that this has ever happened in Jakarta Commons, or is
 likely to happen in the new subproject, so frankly I don't much care
 about how that would work. ;-)

yep. vaporware can take care of itself :)

 2) A new component is proposed by an existing Apache committer. This
 will almost certainly be backed up by code in the sandbox.
 Historically, in Jakarta Commons, there hasn't so much been a
 proposal, but rather a new project materialises in the sandbox. This
 has, in part, been responsible for dregs that lie around forever. This
 could be handled through the after 6 months vote that has been
 mentioned in another thread.

then at some time later, a promotion vote is held.

 3) A new component is proposed by a non-committer. Code to back up
 such a proposal would necessarily be coming from somewhere else. This
 is a situation in which the component should, I believe, come in
 through the incubator. The incubation process would resolve the
 questions of committers, etc., before the component lands in the new
 subproject. (I want to emphasise here, for the folks that might be
 concerned about this, that incubation need not be an onerous process,
 and can happen rather quickly, if conditions are right.)

+1

 I would suggest that we come up with wording in the charter to reflect
 these scenarios, rather than trying to crib from the Jakarta Commons
 charter in this instance.

+1

maybe the whole sandbox issue should have it's own subsection detailing
how the sandbox is to work and how promotion should work.

  is 19 needed in addition to 15?
 
 This seems to be a different topic entirely, but my vote would be yes,
 because 15 relates only to the proposal, while 19 relates to the
 component as it exists, and is developed, within the subproject.

sorry: meant 17

- robert


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



Re: new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]

2005-07-03 Thread robert burrell donkin
On Sat, 2005-07-02 at 12:27 -0700, Phil Steitz wrote:
 Martin Cooper wrote:
  On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote:
  
 On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
 
 snip
 
 Interpreted literally, 17 goes against standard practice in jakarta (or
 apache, to my knowledge, other than in the incubator).  I would
 recommend that new packages require existing committers to support them.
 I would at least recommend changing Anyone to Any apache committer.
  If an individual has already contributed enough to be voted in as a
 committer, then that should be done in a separate VOTE.
 
 this certainly doesn't reflect the current practise in the jakarta
 commons. though anyone can propose a new component, they really won't
 have any chance of winning a VOTE unless they have the support of
 existing committers.
 
 there is also the issue of the incubator: any new component bringing
 code from outside apache would need to be incubated.
  
  
  We have a few different scenarios here, I believe.
  
  1) A new component is proposed, with no existing code to back it up.
  I'm not sure that this has ever happened in Jakarta Commons, or is
  likely to happen in the new subproject, so frankly I don't much care
  about how that would work. ;-)
  
  2) A new component is proposed by an existing Apache committer. This
  will almost certainly be backed up by code in the sandbox.
  Historically, in Jakarta Commons, there hasn't so much been a
  proposal, but rather a new project materialises in the sandbox. This
  has, in part, been responsible for dregs that lie around forever. This
  could be handled through the after 6 months vote that has been
  mentioned in another thread.
  
  3) A new component is proposed by a non-committer. Code to back up
  such a proposal would necessarily be coming from somewhere else. This
  is a situation in which the component should, I believe, come in
  through the incubator. The incubation process would resolve the
  questions of committers, etc., before the component lands in the new
  subproject. (I want to emphasise here, for the folks that might be
  concerned about this, that incubation need not be an onerous process,
  and can happen rather quickly, if conditions are right.)
  
  I would suggest that we come up with wording in the charter to reflect
  these scenarios, rather than trying to crib from the Jakarta Commons
  charter in this instance.
 
 Agreed. After a little more discussion, we should rewrite this. 

+1

anyone feel like jumping volunteering to come up with a draft?

 FWIW, I did NOT mean to suggest that only committers could *suggest* 
 projects, 
 only that to actually get one *started*, support from ideally more than 
 one committer is required.  I think the following is also possible, 
 since at least one j-c component started this way:
 
 4) A new component is proposed by a (some) non-committer(s).  One or 
 more existing committers are interested in working on the component. 
 The initial code base is built up incrementally in the sandbox from 
 patches contributed by community members.  This is more or less the way 
 we started commons-math.  The initial code base was contributed 
 incrementally, with patches discussed, reviewed and in some cases 
 refactored before being committed. I don't see anything wrong with this, 
 nor requiring a trip through the incubator.

+1

but i think that this can be covered as a subcase of the sandbox route.
the key factor is that the code is original. 


- robert


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



Re: new components

2005-07-03 Thread robert burrell donkin
On Sun, 2005-07-03 at 13:13 -0700, Phil Steitz wrote:
 Here is a stab at replacement text for 15, 17 and 18.

great :)

looks good but threw up some ideas...

 15-1 Any member of the community may propose a new package. To be 
 accepted, a package proposal must receive majority approval of the
 subproject committers and at least one committer must volunteer to serve 
 as an initial package team member. Proposals should identify the 
 rationale for the package, its scope, its interaction with other 
 packages and products, the insert-subproject-name resources, if any, 
 to be created, the initial source from which the package is to be 
 created, and the sponsoring committers.
 
 15-2 The subproject will maintain an svn repository, referred to as the 
 isandbox/i, as a workplace for new packages.  Once approved, new 
 packages must all begin in the sandbox. Any apache committer may 
 contribute code directly to the sandbox and this code may form the 
 initial source for new packages.  Code from existing apache projects 
 can, with the support of the contributing projects, also be imported 
 directly into the sandbox.  Finally, patches contributed incrementally 
 by community members may be committed to the sandox by a subproject 
 committer. If the initial source for a new package is from outside of 
 apache, the new package must be brought into apache via the apache 
 incubator.

not sure but wonder whether we might need to tightening this last
sentence so that it can't be read as implying that having only a portion
of the initial source from external sources is ok. opinions?

 15-3 A majority vote among subproject commiters is required to 
 graduate a package from the sandbox to become a proper package. Only 
 proper packages may make releases. If a package remains in the sandbox 
 for more than six months, a majority vote will be required to prevent 
 its being archived from svn and removed from the subproject web site and 
 any other public locations (e.g. nightly or continuous integration 
 builds). Proper packages may not release code with dependencies on 
 sandbox packages.

1. i wonder whether it'd be better to have bi-annual reviews to simplify
administration. in january, review all sandbox components which were
created before the previous july. could run them as a single vote.

2. i wonder whether we actually need to remove them from svn: just could
copy them into an archive directory.

- robert


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



Re: Name for commons-like area for web

2005-06-28 Thread robert burrell donkin
On Mon, 2005-06-27 at 19:37 +0200, Torsten Curdt wrote:
  Pardon my ignorance, but if Web were a subproject under Jakarta
  Commons, could Web itself have subprojects?
 
 AFAIK there is no project that has such subproject.
 ...but that does not mean it's completely impossible.
 Probably needs to be discussed.

please, please no sub-sub-projects!

apache has been trying to unwind the deep hierarchical structure (that
jakarta used to have) for several years now in favour of a flatter
model. the reason is simple: hierarchical structures tend to fragment
and create problems with oversight. this issue of oversight is of
critical importance for the board (and anyone else who cares about the
future of the foundation). 


projects and sub-projects are constructs for legal oversight and
management. one of the issues for a flatter jakarta is guiding uses
through a myriad of components managed by a single community of
developers. all components are equal but the management structure and
the relationship structure expressed by the website navigation do not
necessarily need to coincide. 

- robert


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



Re: The content of the folder weapps of tomcat disappeared.

2005-06-26 Thread robert burrell donkin
this sounds to me like a question that would be better directed to the
tomcat user list. see http://jakarta.apache.org/site/mail.html. 

- robert

On Fri, 2005-06-24 at 16:05 -0300, Cosmo Luís Arrivabene wrote:
 The content of the folder weapps of tomcat disappeared.  Did not have 
 intervention human being, somebody can help to understand it?  Tank's
 
  
 
 My tomcat version is 4.1
 
  
 


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



new Standard/JSTL subproject? [WAS Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin]

2005-06-26 Thread robert burrell donkin
On Thu, 2005-06-23 at 20:14 -0400, Henri Yandell wrote:
 On Thu, 23 Jun 2005, robert burrell donkin wrote:
 
  On Thu, 2005-06-23 at 00:49 -0300, Felipe Leme wrote:
  Apache Wiki wrote:
 
  Please do not edit comments into this text: please use the 
  CharterForWebCommonsRequestForComments
   or post to  [http://jakarta.apache.org/site/mail.html General At
  Jakarta].
 
  OK, here I am posting :-)
 
  3.What about the Standard Taglibs? Should it be part of this new project
  or should it be a separate project. The reasoning here is that, because
  that sub-project provide the codebase for JSTL's implementation (and
  maybe other JSR taglibs in the future as well, such as the Web Services
  taglib), its development activities/cycles might be different from the
  non-standard ones (we could even try to apply the TCK on such projects
  in the future, for instance).
 
  if the new subproject is anything like the commons then each component
  will have it's own development rhythm.
 
  it might be easier to raise extra hands when needed for these efforts if
  these share the same infrastructure (mailing lists, subproject
  organization and so on).
 
  opinions?
 
 My vote is for the active Taglibs to roll into the web component 
 subproject, but for the Standard/JSTL taglib to move to Jakarta subproject 
 status.
 
 Taglibs-user is dominated by JSTL questions and the JSTL committers don't 
 have any obvious overlap with the other taglib committers (that I've 
 noticed). Also in terms of codebase, Standard is the relative behemoth.
 
 Lastly it has a much higher profile than other parts of 
 web-component-subproject will have and as a spec implementation it has a 
 different set of issues to deal with.

+1

are there any committers involved with JSTL around?

if not, would anyone like to volunteer to sound them out about a move to
subproject status? 

- robert


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



Re: [Jakarta Wiki] Update of CreatingCommonsForWebComponents by FelipeLeme

2005-06-23 Thread robert burrell donkin
On Thu, 2005-06-23 at 00:38 -0300, Felipe Leme wrote:
 I also fixed the alphabetic order of the existing proposals (but 
 accidently typed enter before adding that comment).

thanks

- robert



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



RE: [ANNOUNCEMENT] Proposal For Jakarta Sub Project For WebApplication Components

2005-06-23 Thread robert burrell donkin
On Thu, 2005-06-23 at 09:45 -0400, Bernard, Shawn wrote:
 If someone is interested in this project, what should they do?

you've already taken the first step: signing up to this list and joining
in :)

at the moment, this is just a proposal. for this to get any further,
there are some tangible things that need to happen such as choosing a
name and creating a charter. there are also intangible things like
bootstrapping a community. the jakarta committers will need a name and a
charter as well as a community to be convinced of the viability. 

right now, we need community support in developing (in more concrete
terms) exactly what this new subproject should be and how it should be
organised. the final charter should be an expression of these ideas. 

take a look at the documents on the wiki and post improvements and
criticisms (at the moment, they are just a starting point: copies of the
current jakarta commons charter). (sign up and) add new linked documents
containing anything you think might help (ideas for components, perhaps
or best practices). think of names or come up with reasons why a
particular name should be picked (or not picked). the wiki should
provide bootstrap documentation for the subproject. join in the
discussions.

in other words: get involved in the best way you see fit.

- robert


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



Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications

2005-06-23 Thread robert burrell donkin
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:

snip
 
 Here are some comments on the draft charter.
 
 It is nice to see so much borrowed from the (at least I think) 
 successful j-c model ;-)

everything borrowed, in fact. not that it'll stay that way for long...

 
 A couple of things should be changed, though, IMHO.

i'm sure there are few more than that ;)

i've decided to chop phil's good reply up into bits so that items
requiring more discussion can get their own threads...

 First in the scope statement intended for use in server-related 
 development could be narrowed to web application development

+1

 Uniformly change CVS to SVN (I assume! :)

+1

snip

 4.2 should probably reference JSP/Servlet spec level requirements as 
 well as JDK requirements

+1

 
 +1 to bullet under 7 :-)

++1


 Don't know what kind of goo 12 would result in or who would use such a 
 thing ;-)

+1 

i'm all for removing 12. this proved just too difficult to coordinate.

unless anyone feels the need to -1 any of these, someone should go ahead
and make these changes...

- robert


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



mailing lists for components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]

2005-06-23 Thread robert burrell donkin
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:

 4.1 in the guidelines repeats the error that I thought was fixed in the 
 j-c guidelines saying that each package has its own mailing list.  If 
 that is intentional, I think that is a *bad* idea, especially to start.

it was intentional in as much as it was a copy of the jakarta commons
charter :)

 Don't like the many little lists implied by 11 -- dev + user works fine 
 in j-c (I know some disagree, but I personally view this as the key to 
 the health of j-c)

i agree. just dev and user lists.

in jakarta commons, the common mailing lists hold together the single
community. i'd like to see just one mailing list with components using
prefixing (as per jakarta commons). i'd like to see changes to the draft
so that it's clear that this will be the arrangement.

opinions?

- robert


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



configuration files [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]

2005-06-23 Thread robert burrell donkin
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:

 9 or somewhere else should speak to J2EE or other external config 
 requirments, which should be fine, even encouraged in some cases

is 9 needed? are any configuration guidelines needed?

if they are then i agree that they should encourage specification
compliance. would a general statement about specification compliance be
better? 

- robert


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



[POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]

2005-06-23 Thread robert burrell donkin
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:

snip

 Don't know what kind of goo 12 would result in or who would use such a 
 thing ;-)

this has proved impractical in the jakarta commons. i propose we drop
point 12.

- robert

--8---
[ ] +1 Get rid!
[ ] -1 Keep it (please give a reason...)
--





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



new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]

2005-06-23 Thread robert burrell donkin
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:

snip

 Interpreted literally, 17 goes against standard practice in jakarta (or 
 apache, to my knowledge, other than in the incubator).  I would 
 recommend that new packages require existing committers to support them. 
 I would at least recommend changing Anyone to Any apache committer. 
  If an individual has already contributed enough to be voted in as a 
 committer, then that should be done in a separate VOTE.

this certainly doesn't reflect the current practise in the jakarta
commons. though anyone can propose a new component, they really won't
have any chance of winning a VOTE unless they have the support of
existing committers.

there is also the issue of the incubator: any new component bringing
code from outside apache would need to be incubated.

is 19 needed in addition to 15?

- robert


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



sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]

2005-06-23 Thread robert burrell donkin
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:

snip

 I guess 18 refers to the sandbox?  I do not understand what the intent 
 of this is.

is boils down to the question: does this subproject need it's own
sandbox or will neophyte components start in the jakarta commons
sandbox?

- robert



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



Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications

2005-06-23 Thread robert burrell donkin
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:

snip

 One final thing to think about.  I know lots of apache people are 
 opposed to umbrella projects for lots of reasons, one of which is the 
 fragmentation and abandonment that can result.  We have certainly not 
 been immune to that in j-c.  Two things that have been critical to 
 keeping us going have been 1) a relatively small (changing over time) 
 set of key contributors who look after multiple components and 2) some 
 large internal customers (tomcat, struts, maven et al) whose 
 committers jump in to push things along as needed.  This project would 
 be starting without the large internal customers.  It would probably 
 be a good idea, therefore, to start with a narrower, rather than broader 
 scope, so that the fledgling community would not get fragmented too 
 quickly and the key contributors could emerge.  Just a thought.

good points 

it's clear to me that there needs to be sufficient interest from
developers with free time for this subproject to be viable

- robert


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



Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin

2005-06-23 Thread robert burrell donkin
On Thu, 2005-06-23 at 00:49 -0300, Felipe Leme wrote:
 Apache Wiki wrote:
  
  Please do not edit comments into this text: please use the 
  CharterForWebCommonsRequestForComments 
   or post to  [http://jakarta.apache.org/site/mail.html General At 
 Jakarta].
 
 OK, here I am posting :-)
 
 I'd like to suggest 2 things:
 
 1.We prefereably use Maven for the builds, as it helps a lot handling 
 the dependencies (if we stick to Ant, we should at least use Ivy or M2 
 Ant stuff for dependency management). For instance, I haven't applied 
 some patches to the Jakarta Taglibs because my computers are not set for 
 building them anymore (and I don't have the time/patience to fix it).

jakarta commons is agnostic (but uses maven for the website). i'd
recommend official agnosticism with unofficial encouragement to maven.
it is a good idea to provide ant scripts generated by maven in SVN. 

 2.Regarding the Jakarta Taglibs, we should create the new taglibs from 
 scratch. I mean, of course we should reuse the code, but we better do 
 some refactoring first (for instance, eliminating redundant taglibs, 
 defining a role for TLD names, etc...) - the current Jakarta Taglibs 
 would then be frozen in time.

IMHO it would probably be more convenient to maintain these frozen
taglibs (from an official perspective) within the new subproject. with
subversion, it's really nice and easy to have cool directory
structures...

 3.What about the Standard Taglibs? Should it be part of this new project 
 or should it be a separate project. The reasoning here is that, because 
 that sub-project provide the codebase for JSTL's implementation (and 
 maybe other JSR taglibs in the future as well, such as the Web Services 
 taglib), its development activities/cycles might be different from the 
 non-standard ones (we could even try to apply the TCK on such projects 
 in the future, for instance).

if the new subproject is anything like the commons then each component
will have it's own development rhythm.

it might be easier to raise extra hands when needed for these efforts if
these share the same infrastructure (mailing lists, subproject
organization and so on). 

opinions?

- robert


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



Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin

2005-06-23 Thread robert burrell donkin
On Thu, 2005-06-23 at 00:52 -0300, Felipe Leme wrote:
 Felipe Leme wrote:
  
  I'd like to suggest 2 things:
  ...
  3
 
 Damn, beaten by the ENTER key again :-(

shades of monty python's flying circus ;)

- robert


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



Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications

2005-06-22 Thread robert burrell donkin
On Sun, 2005-06-19 at 15:34 -0400, Frank W. Zammetti wrote:

 robert burrell donkin wrote:
  web parts is a good name. 
 
 I thought so... that's why I chose it ;)
 
   trademarks are of particular importance for
  the ASF but it's also important to do the right thing ethically. i
  wouldn't be happy to see a jakarta subproject take the name of a related
  open source project against the wishes of those involved in that
  project.
 
 It might be worth noting that this weekend marked the first actual 
 release of my project... granted it's a pre-alpha release, but a release 
 none the less.  I am still interested in collapsing my project into this 
 new Jakarta sub-project, hence my participation in this discussion... if 
 that happens, Jakarta Web Parts sounds good to me, I'd have no problem 
 closing down my project and passing the name along.  If my project 
 remains separate though, I'd prefer to not have to change my name :)

that's understandable but is likely to cause wrinkles in the approval
process. a subproject needs a name and a charter before it can be
approved. no guarantees could be offered since accepting new committers
is something that sould be delegated to the new community.   

anyone have any opinions about this?

  web parts appears to in use by dot net. not sure whether anyone holds
  trademarks. FWIW AIUI sun are opposed to names such as java web parts
  (trademark reasons): they believe it should be web parts for java
  (WP4J).
 
 Well, if it is part of .Net, then maybe I have to change mine anyway :) 
   In any case, I actually very much like the Sun approach here, although 
 I'm not sure I know why!  Web Parts For Java (WP4J) sounds pretty 
 good... although JWP is a shorter abbreviation ;)

if you could leave it a little while before changing the name of your
project to WP4J, that might give us some time to prepare the documents
in...

  in any case, the official name would be jakarta web parts (or jakarta
  web bricks). if a consensus emerges then the pmc could probably check
  out the legal side.
 
 Or Jakarta Web Parts For Java, or JWP4J, which has the benefit of being 
 what I am now (JWP) with 4J appended.  I for one like it!

that sounds good to me too. 

anyone else have an opinion?

  this leads to the question: what's the best way to develop the charter? 
  
  i've been contemplating using the wiki to store a working draft whilst
  debating content on this list. opinions?  
 
 That seems reasonable to me... In fact, what might be nice is to have a 
 link off the Wiki page labeled Request For Comments... that way people 
 can post their ideas to that without the possibility of missing anything 
 on the mailing list, and without changing the content outright... I'm 
 sure we all have our filters set up and we all try to manually filter as 
 well, and I for one can't say I've never missed something I would have 
 been interested in.

that sounds like a good plan. 

- robert


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



Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications

2005-06-22 Thread robert burrell donkin
On Wed, 2005-06-22 at 16:53 -0400, Frank W. Zammetti wrote:
 I'll step back and let you guys get it off the ground then...

no one's asking you to step back :) 

the reason why this discussion was moved to this forum was to encourage
people to get involved with the discussion and help to shape the sub
project. consider staying and doing that.

it's important to understand that there's a distinction between
importing existing code into apache (which would mean incubation to
build a community, educate committers and ensure there were no legal
issues) and collaborating in the development of new code covering
similar ground.

i can think of (at least) one example of a Jakarta Commons committer who
developed open source libraries covering similar ground. the apache
contributions were new code and so the question of importing code does
not arise.

 However, the one point that I believe to be very relevant at this 
 junction, in light of what Robert has said about a name being required 
 up-front, is that I may not be willing to give up the Java Web Parts 
 name.  Since that was one of the suggestions, I think that is a relevant 
 point.  And since mere similarity of names was mentioned by someone as 
 well, it is that much more relevant.

fine (feel free to remove any names you're not happy with from the wiki)

 Martin Cooper wrote:
  Can we please separate the two different topics being discussed here?

+1

we need to start some new threads with better subjects...

- robert


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



Re: [ANNOUNCEMENT] Proposal For Jakarta Sub Project For Web Application Components

2005-06-22 Thread robert burrell donkin
i considered posting this to one or more of the announcement lists in an
attempt to widen the audience but i didn't feel confident that it would
be appropriate or wise.

opinions?

- robert

On Wed, 2005-06-22 at 22:48 +0100, robert burrell donkin wrote:
 There has been considerable interest over the last few weeks and months
 concerning the possibility of a new Jakarta sub project similar to the
 Jakarta Commons but aimed at independent reusable web application
 components.
 
 There are a number of matters which need to be discussed and ideas
 developed. Anyone who is interested is invited to subscribe to the
 general list at Jakarta (http://jakarta.apache.org/site/mail.html).
 
 A start has been made at documenting some of these:
 http://wiki.apache.org/jakarta/CreatingCommonsForWebComponents.
 
 - robert
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


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



Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications

2005-06-22 Thread robert burrell donkin
On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
 Stephen Colebourne wrote:
  robert burrell donkin wrote:
  
  there have been a number of long running threads in the commons
  discussing the possibility of commons components for use in web
  applications. the consensus emerged that it would be best if a new
  subproject with a structure similar to the commons was created for
  components intended for use in web applications.
 
  opinions, please!
  
  
  I am in favour of this, although whether I would be able to spare much 
  time is debatable.
 
 I am also in favor, also not likely to have much time to contribute. 
 Here are some comments on the draft charter.
 
 It is nice to see so much borrowed from the (at least I think) 
 successful j-c model ;-)

the text is the jakarta commons charter :)

but it's just a starting point: hopefully it'll stimulate some
discussion and people can start to move to forward...

- robert


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



Re: [patch] site change for Jelly release

2005-06-16 Thread robert burrell donkin
committed.

hopefully, someone will sort you out with site karma sometime soon (it's
open to all jakarta committers upon request)... 

- robert

On Fri, 2005-06-17 at 02:34 +1000, Brett Porter wrote:
 As per http://jakarta.apache.org/commons/releases/release.html I am
 sending this here.
 
 I do not have access to the jakarta-site SVN module and am not a
 Jakarta PMC member. Would somebody be able to apply the above to
 jakarta-site?
 
 I've scp'd the resulting docs files up to the web server and confirmed
 the permissions are right, so next svn up from there should just merge
 them in.
 
 Thanks,
 Brett
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


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



[PROPOSAL] subproject that's a home for bricks reusable in java web applications

2005-06-16 Thread robert burrell donkin
there have been a number of long running threads in the commons
discussing the possibility of commons components for use in web
applications. the consensus emerged that it would be best if a new
subproject with a structure similar to the commons was created for
components intended for use in web applications.

opinions, please!

in particular:

a charter needs to be developed (based on the commons one)

a name needs to found 

(feel free to start new threads on these topics)

some debate has already started on various lists (pmc, commons-dev,
taglibs) but all are invited to consolidate the discussions onto this
list...

- robert


signature.asc
Description: This is a digitally signed message part


Re: Need JAR file with...

2005-06-13 Thread robert burrell donkin
jetspeed has graduated to: http://portals.apache.org/

follow the instructions to download the jetspeed jars

- robert

On Mon, 2005-06-13 at 10:07 -0700, Bosko Popovic wrote:
 ...org.apache.jetspeed.security.spi.impl.LdapCredentialHandler class as well 
 as all necessary prerequisite classes,
 thanks Boli Popovic
 
 
   
 -
 Discover Yahoo!
  Have fun online with music videos, cool games, IM  more. Check it out!


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



Last Call For ApacheCon Europe 2005 Early Birds

2005-06-13 Thread robert burrell donkin
 Forwarded Message 
 ApacheCon Europe 2005 - Early Bird registration runs out June 17.
 
 ApacheCon Europe 2005
 July 18-22, 2005
 Stuttgart, Germany
 
 Only a few days to save money! By registering prior to June 17
 you can save more than 200 EUR! More pricing specials such as
 company team discounts and a 25% off for students are available
 as well.
 
 ApacheCon Europe 2005 offers an immense program consisting of
 several half-day and full-day tutorials on July 18 and 19 and
 more than 70 sessions on July 20-22. With plenty of room for
 networking and peer discussions, attendees can meet ASF members
 and and participants during the ApacheCon Expo, evening events,
 Birds-of-a-Feather sessions and a number of informal social
 gatherings.
 
 Among the highlights of ApacheCon Europe 2005 you can find a
 keynote presentation by Horst Zuse, son of Konrad Zuse, who is
 considered as the inventor of the first programmable computer.
 Horst Zuse will give a keynote presentation on the origins of
 the computer, leading through the history of computing.
 
 All information on ApacheCon Europe 2005 and registration
 possibilities can be found at http://www.apachecon.com.
 
 
 Best Regards...
 -- 
 Lars Eilebrecht
 [EMAIL PROTECTED]




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



Re: Update jakarta site with commons-lang 2.1 release info

2005-06-12 Thread robert burrell donkin
hi steven

i don't think that the diff made it. you might need to upload it to
people.apache.org or create an issue report

alternatively, you could ask for site karma and apply it yourself...

- robert

On Sun, 2005-06-12 at 14:39 -0400, Steven Caswell wrote:
 Per the instructions at
 http://jakarta.apache.org/commons/releases/release.html, I have
 attached the diff for the jakarta site files I've changed for the
 commons-lang 2.1 release. Could someone please complete the step for
 updating the jakarta site.
 
 TIA
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


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



Re: Apache cannot connect to Tomcat in httpd.conf

2005-06-05 Thread robert burrell donkin
hi andreas

you'll probably get a faster response if you post this question to the
tomcat user list. please read http://jakarta.apache.org/site/mail.html.

- robert

On Sun, 2005-06-05 at 12:54 +0200, Andreas Bauer wrote:
 Hello!
 
 
 
 Can somebody help me, please?
 
 My OS is Suse 9.2 pro. Apache and Tomcat work for me.
 But If I start Apache with normal httpd.conf, Apache works for me.
 If I paste my lines for Apache-Tomcat Connection, Apache doesn't
 work for me, only Tomcat. It must be something wrong with this lines, but
 the same lines in httpd.conf
 
 in a windows XP Tomcat-Apache configuration works for me:
 
 
 
 The pasted lines in httpd.conf are:
 
 LoadModule jk2_module modules/mod_jk2.so
 Location /*.jsp
 JkUriSet worker ajp13:localhost:8009
 /Location
 Location /mywebapp
 JkUriSet worker ajp13:localhost:8009
 /Location
 
 
 
 The Tomcat Connector Modul mod_jk2.so is in the rigth directory
 and Apache doesn't send an errormessage,, because of the module, when I
 start Apache from the commandoline. If I took another Tomcatconnectormodul,
 I got errormessage.
 
 With the old one, not.
 
 
 
 My jk2.properties is:
 TOMCAT_DIR/conf/jk2.properties, adding the following line:
 channelSocket.port=8009
 
 
 
 Configuration of server.xml is:
 server.xml configuration from Tomcat/conf directory:
 look for the non-SSL Coyote HTTP/1.1 Connector. This is
 the standard Tomcat-only connector and comment it out since we'll be using
 Apache for handling HTTP requests. In the same file, look for a commented
 line that says Context path= docBase=ROOT debug=0. Right after
 that line, add the following Context path:
 Context path= docBase=APACHE_DIR/htdocs debug=0 reloadable=true
 crossContext=true/
 
 
 
 Workers2.properties is:
 APACHE_DIR/conf directory/workers2.properties:
 [shm]
   file=APACHE_DIR/logs/shm.file
   size=1048576
 # socket channel
   [channel.socket:localhost:8009]
   port=8009
   host=127.0.0.1
 
 # worker for the connector
   [ajp13:localhost:8009]
   channel=channel.socket:localhost:8009
 
 The working script is from
 http://www.dynamicobjects.com/d2r/archives/002574.html
 http://www.dynamicobjects.com/d2r/archives/002574.html
 
 The same T-A Connector Configuration with a windows Connector Module works
 for me in a windows system.
 
 Best regards and many thanks
 
 Andreas
 


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



Re: SSH access to jakarta.apache.org

2005-05-05 Thread robert burrell donkin
AIUI the dns names have changed around a bit. jakarta.apache.org is now
being served from ajax. you should now access your minotaur as
people.apache.org. ajax is mirrored so you'll need to wait for the
mirrors to sync before you'll be able to see any changes you make. 

- robert

On Thu, 2005-05-05 at 19:01 +0200, Oliver Zeigermann wrote:
 Folks!
 
 As already said it seems I will need SSH access to jakarta.apache.org
 to update the jakarta commons transaction website - which I am a
 committer for.
 
 Is that right? If so who can grant that for me?
 
 Thanks,
 
 Oliver
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 



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



Re: Verifying Downloads

2005-05-01 Thread robert burrell donkin
sadly, AFAIK this document does not exist as yet. (i have been intending
to create one for quite a long time.) 

please google for the theory behind these technologies but i'll try to
give a brief guide. 

md5 is a checksum. a checksum is a numeric hash of a file. the idea is
that two different files will have different checksums. you use a
secure, trusted channel to learn the checksum then use the same
algorithm to calculate the checksum for the file which has been obtained
from an untrusted channel. if the checksum calculated matches then you
can conclude that the file is identical to the one that the trusted
checksum was calculated from.

in ASF terms, downloading a file from a apache mirrored and an md5
checksum from an apache server and calculating the md5 sum for that file
should allow you to determine whether the file you downloaded from the
mirror is identical to the file that the sum placed on the apache server
was calculated from.
 
checking the md5 sum should be a good enough guarantee for the vast
majority of users. 

if you have more stringent requirements, you might also want to check
the openPGP compatible digital signature. this tells you something
different: which key was used to sign the release. if you have a public
key matching the private key used to sign the release then you can
verify the signature of the file. this tell you whether the file is
identical to the one used to create the signature. note that you can
only trust this method of verification as far as you can trust the
public key. unless your web of trust extends to the key in question,
this method may be no more secure than the md5 sum. see
http://people.apache.org/~henkp/.

in terms of implementations, i use http://www.gnupg.org for the
signatures, and openssl or md5sum for the sums.

- robert

On Sun, 2005-05-01 at 12:02 -0600, Robert Voelkerding wrote:
 Please direct me to an explanation of how to use MDE and/or PGP keys to 
 verify downloads.
 
 Thank you.


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



Re: Verifying Downloads

2005-05-01 Thread robert burrell donkin
On Sun, 2005-05-01 at 14:59 -0400, Henri Yandell wrote:
 That would be a good link to have on the download pages wouldn't it :)
 
 Googling, I get:
 
 http://www.hybridized.org/forum/viewtopic.php?t=222
 
 which contains nice links to Windows programs. Verifying MD5 is easy on 
 unix-based machines as it's the output of either the md5 or md5sum 
 commands.
 
 Closer to home Apache-wise, there's the HTTPD document on verifying the 
 PGP keys.
 
 http://httpd.apache.org/dev/verification.html
 
 Hope that helps, and I'll add having a better answer on the site to the 
 todo list.

the best place would probably be in the release FAQ over on the
foundation site. i've been meaning to add some information on this for a
while but haven't found the time as yet.

- robert


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



Re: Wiki structure

2005-04-19 Thread robert burrell donkin
On Tue, 2005-04-19 at 15:23 +0100, sebb wrote:
 On 4/19/05, Simon Kitching [EMAIL PROTECTED] wrote:

snip

  And by the way, what is the reason for having all these separate wikis
  anyway, instead of just one?
 
 Dunno.

IIRC the pmc had no objections to subprojects creating their own wiki's.
the decision was delegated to them and most ended up deciding to have
their own. 

- robert


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



Re: VOTE: Tomcat - TLP

2005-04-07 Thread robert burrell donkin
On Wed, 2005-04-06 at 19:36 -0400, Ian F. Darwin wrote:

 [X] +1 Vote in support
 [ ]  0   Abstain
 [ ] -1  Vote against

(Jakarta PMC)

- robert


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



Re: help with patch submission for VFS

2005-04-06 Thread robert burrell donkin
you'll find general information on contributing on the website and in
particular http://jakarta.apache.org/site/getinvolved.html.

there are two ways to submit patches: either through bugzilla
(http://issues.apache.org) or by posting an email to the commons-dev
list (see http://jakarta.apache.org/site/mail.html) with subject prefix
[vfs][PATCH]. you might need some patience and require some gentle
reminders before it's picked up.

- robert

On Tue, 2005-04-05 at 19:55 -0600, Dan Mingus wrote:
 I'm trying to figure out where to submit a patch for the VFS sandbox
 project in jakarta-commons.  Any help?
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 



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



Re: future for maven generated websites?

2005-03-28 Thread robert burrell donkin
On Mon, 2005-03-28 at 10:49 +1000, Brett Porter wrote:
 There are a few alternatives. If webDAV is the answer from infra, then
 we can definitely get that into the site plugin. It is on the todo
 list as Tim noted, but the list remains very long at this point :)

sounds familiar: so much work, so few hours :)

a lot of folks are keen on mavenised websites here so i think that we
should be able to find volunteers to hack the code provided that there
are maven folks willing to give a lead and make sure the work's done in
the right way.  

given that infrastructures talking about switching off accounts on
minotaur in a matter of months and there's work that's going to be
needed to be done, it's probably worth trying to pull some stuff
together sooner rather than later. this seems like an apache-wide
infrastructure issue for maven so there are a number of lists that might
be appropriate for this discussion (maven-dev, infrastructure, general
at jakarta). i'd be inclined to leave the thread here (might be easier
to find bodies who aren't working on maven right now). opinions?

- robert


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



future for maven generated websites?

2005-03-27 Thread robert burrell donkin
does anyone have a plan to cope with rebuilding maven based websites
when shell access is switched off to the machine serving the website?

will we be able to run regular maven site regeneration on a
jakarta.apache.org partition?  

- robert


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



Re: Jakarta Apache Tomcat as a TLP ?

2005-03-22 Thread robert burrell donkin
On Mon, 2005-03-21 at 17:20 -0800, Bill Barker wrote:
 - Original Message -
 From: Stephen Colebourne [EMAIL PROTECTED]
 To: Jakarta General List general@jakarta.apache.org
 Sent: Monday, March 21, 2005 2:45 PM
 Subject: Re: Jakarta Apache Tomcat as a TLP ?
 
 
  From: Henri Gomez [EMAIL PROTECTED]
   Well I'd like to know the pros and cons of Tomcat being TLP.
  
   As I said in tomcat-dev, it was proposed when ant became TLP and at
   this time the consensus was to stay under jakarta umbrella.
  
   What motivate the move to TLP now.
 
  Currently, Tomcat developers are having to take time away from their main
  task (coding) to answer management issues raised by Jakarta. This raises
 the
  question of whether Tomcat is big enough and mature enough to manage these
  issues itself, without the involvement of Jakarta.
 
 
 Great.  Now this thread has moved from JBoss-bashing to dissing the entire
 Tomcat community.
 
 I'm looking forward to your involvement on tomcat-dev so that we can all
 know that Tomcat has the proper adult supervision.

this isn't tomcat bashing: it applies equally to all jakarta
sub-projects. 

the jakarta pmc (including stephen) supervises every sub-project
(including tomcat) on behalf of the board. once a sub-project community
feels that they are ready to manage their own affairs, that's great but
there can be no question of self-governing sub-projects: it's time for
them to move on and up :)

- robert


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



  1   2   3   >