Re: Are wiki pages backed up?

2004-03-25 Thread Leo Simons
Noel J. Bergman wrote:
Are our wiki pages (either old UseMod or new MoinMoin) backed up
regularly?
nope. Manually, every now and then. How lame is that, huh? Need to 
install a cronjob. Forgot about it several times now. Can someone please 
add an entry to jira?

Moin does store previous revisions of files (in the 'backup' folder 
alongside the 'text' folder), but not the latest revision. That, we can 
retrieve, in theory, from the change notifications. In practice, we had 
to do that when the avalon wiki was erronously wiped a while back, and 
it is a major headache which takes hours to figure out.

If someone with enoug priviledges runs an rm -Rf in the wrong place 
we've got a big problem.

Or maybe backed up somewhere like CVS?  Is there something
we can do if someone maliciously edits a page and removes all content?
yes, if the edit is through the web, that is easy enough (though not 
enabled by default). The 'i' icon in the top right corner of each page 
gets you a page with a link to the revision info. Click on the 'view' of 
a revision, and replace 'action=recall' with 'action=raw'. You can 
copy-paste that content in the edit pane of the page to restore it.

I think a better description is in the Moin FAQ.

I don't think anyone has modded moin to automate that process, probably 
in part because...

UseMod kinda, MoinMoin, I'm not sure.  In the longer run, Greg is working on
a Subversion-based Wiki that would be a drop-in replacement for our Moin
Moin Wiki Farm.
--
cheers,
- Leo Simons

---
Weblog  -- http://leosimons.com/
IoC Component Glue  -- http://jicarilla.org/
Articles  Opinions -- http://articles.leosimons.com/
---
We started off trying to set up a small anarchist community, but
 people wouldn't obey the rules.
-- Alan Bennett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Apache should join the open source java discussion

2004-03-18 Thread Leo Simons
Something big is stirring in the java world. There's talks between Sun 
and IBM about releasing an open source version of java. There's talks 
between the linux desktop movers about adopting java as the glue that 
binds the major desktop projects together.

Key ASF individuals are joining these discussions, on weblogs and 
various discussion forums. But the ASF as a whole is silent.

Apache is one of the biggest open source communities, and the leader of 
the pack when it comes to open source java.

I think the Apache community should work together on an open letter to 
Sun, IBM, and the rest of the open source community stating our shared 
position on the subject. Like Havoc Pennington writes 
(http://ometer.com/desktop-language.html), the Community Should Decide 
and It's time to start the discussion.

WDYT?

--
cheers,
- Leo Simons

---
Weblog  -- http://leosimons.com/
IoC Component Glue  -- http://jicarilla.org/
Articles  Opinions -- http://articles.leosimons.com/
---
We started off trying to set up a small anarchist community, but
 people wouldn't obey the rules.
-- Alan Bennett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Apache should join the open source java discussion

2004-03-18 Thread Leo Simons
Geir Magnusson Jr wrote:
the intention is to get involved snip/ really wanted to keep quiet
about it, but your post brought this front and center.
little did I know! See what happens when stuff happens on private 
mailing lists? Duplication of effort :-P

I'll happily shut up, since you're obviously on top of things. And 
thanks for letting us know you're on top of things :D

--
cheers,
- Leo Simons

---
Weblog  -- http://leosimons.com/
IoC Component Glue  -- http://jicarilla.org/
Articles  Opinions -- http://articles.leosimons.com/
---
We started off trying to set up a small anarchist community, but
 people wouldn't obey the rules.
-- Alan Bennett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Ant import problem [was Re: jbs (Jicarilla Build System?) and includes...]

2004-03-02 Thread Leo Simons
Antoine Lévy-Lambert wrote:
Hi Adam, and jicarilla developers,
Hi Antoine!

(this is feeback about the build of jicarilla on gump, a system doing 
nightly builds of head revision of open-source projects)

the jicarilla build is assuming that the user has a .jbs subdirectory, 
this is not very cool.
actually, the location is configurable using an ant property, but hasn't 
been configured.

Anyway, don't worry about it too much. None of the other projects 
participating in gump currently depend on the jicarilla ones, so its 
success or failure is not /that/ important.

http://cvs.sourceforge.net/viewcvs.py/jicarilla/jicarilla-sandbox/buildsystem/build-basic-reactor.xml?view=markup 

?xml version=1.0?

project default=jar:install-snapshot name=JBS-based build basedir=.
   property file=project.properties/
   !-- *what happens if the user does not have a 
${jbs.home}/build-reactor.xml ?* --
   !-- *this is the case of gump *--
property name=jbs.home
value=${user.home}/.jbs/
   import file=${jbs.home}/build-reactor.xml/
I wanted to see what happened. This:

Buildfile: build.xml
 [property] dropping 
/data3/gump/jicarilla-sandbox/platform/components/collections/target/classes 
from path as it doesn't exist
 [property] dropping 
/data3/gump/jicarilla-sandbox/platform/components/collections/target/test-classes 
from path as it doesn't exist

BUILD FAILED
/data3/gump/jicarilla-sandbox/platform/components/collections/build.xml:6: 
Cannot find /home/ajack/.jbs/build-project.xml imported from 
/data3/gump/jicarilla-sandbox/platform/components/collections/build.xml

Total time: 0 seconds

which seems appropriate. I've now changed these projects to depend on 
this one:

http://cvs.sourceforge.net/viewcvs.py/*checkout*/jicarilla/jicarilla-sandbox/platform/gump/gump-jicarilla-build-system.xml?content-type=text%2Fplainrev=1.1

which is supposed to install and update the ~/.jbs directory each night. 
Just to see if this'll work well.

The next step might be to figure out if gump makes something like 
@@GUMP_HOME@@ available (I don't think so), and perhaps use 
@@GUMP_HOME@@/work/.jbs as the base directory if possible.

Another option will be to make .jbs a required installed package (just 
like we're doing with tools like forrest atm. But I think that one is 
inferior because it doesn't quite mirror how the jicarilla build 
actually is used.

--
cheers,
- Leo Simons

---
Weblog  -- http://leosimons.com/
IoC Component Glue  -- http://jicarilla.org/
Articles  Opinions -- http://articles.leosimons.com/
---
We started off trying to set up a small anarchist community, but
 people wouldn't obey the rules.
-- Alan Bennett


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


[wiki] Jakarta wikis set up

2004-02-29 Thread Leo Simons
Dear Jakarta PMC,

I have set up MoinMoin wikis for Jakarta at

   http://wiki.apache.org/jakarta
   http://wiki.apache.org/jakarta-lucene
   http://wiki.apache.org/jakarta-tomcat
   http://wiki.apache.org/jakarta-tapestry
Please take a look at the README file in /www/wiki.apache.org on 
minotaur, http://wiki.apache.org/gump/HelpContents and 
http://moin.sf.net for more information about MoinMoin.

I have also attempted to migrate all content from the UseMod wiki 
installation to the appropriate places in the new MoinMoin wiki 
installation. Since the migration script is not perfect, some pages may 
be missing and/or looking awkward. You will need to fix these manually.

Specifically, page where copied over as follows:

*Jakarta*   -   /jakarta
*Lucene*-   /jakarta-lucene
*Tomcat*-   /jakarta/tomcat
this means that a lot of pages for jakarta subprojects have not been 
migrated to a new final location on the MoinMoin installation yet, and 
are hence located (immutable) at

http://wiki.apache.org/old/

We can set up more subwikis for the jakarta subprojects and migrate 
those pages, or we can copy those pages to the /jakarta subwiki. Just ask.

Note that cvs-style commit messages for changes made to the wiki will be 
sent to the appropriate mailing lists as has been requested (the 
moderator for those mailing lists will likely need to make some changes 
to allow these to go through).

Please contact us on the [EMAIL PROTECTED] mailing list if you 
have any questions (prefix the e-mail subject with '[wiki]').

best regards,

- Leo Simons



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


Re: PMC Nomination

2003-02-19 Thread Leo Simons
Hi peeps,

I am on the avalon PMC. I was a bit scared of the idea of being a PMC 
member at first, thinking about all the additional responsibility and 
all the additional things I would need to do.

Guess what? No need for that at all! The additional responsibility 
being on a PMC entails wasn't additional at all. I already participated 
in voting on releases, already tried to help steer overal direction, 
already took responsiblity for the things avalon did as a group, etc etc.

The main extra task I found was getting avalon.apache.org off the ground 
and setting up the extra infrastructure, which was something I did as a 
committer; there certainly isn't much management involved there! And 
with new top-level projects sprouting up, the process is pretty much 
streamlining.

OTOH, the setting up of avalon as a TLP has forced us to re-think what 
avalon is about, and we're now becoming more focussed again. Most 
jakarta subprojects don't really need the extra focus, but this change 
sort of nudged _us_ in the right direction. I also think we made life 
easier for the jakarta PMC, and our project more transparant for the 
board. Finally, the somewhat mythical idea I and others had about what 
constitutes a PMC is basically gone. [EMAIL PROTECTED] has just 
about no traffic :D

I have also not found my fear that avalon would seperate too much from 
the rest of jakarta mostly unfounded. Dynamics with james and cocoon 
(not jakarta :D) are good/better than ever, lots of people and projects 
are still helping us out (like forrest, maven, ant peeps providing 
infrastructure tools and support) avalon is participating in GUMP again, 
and I find myself going out of my way more than before to ensure less 
duplication between projects, particulary wrt commons. I guess the 
broader perspective gained from thinking about the apache/jakarta 
organisation made me care more for all of its projects in the end.



So in my experience so far, being a PMC member did take some extra time 
(basically because I needed to figure out what it ment), but less and 
less as routine settles in. And it has been a really positive and 
rewarding experience; I've learned a lot about apache in the process, 
and avalon as a project is on the right track again.



The situation is probably a little different with jakarta and its PMC as 
a whole, as it consists of lots of projects and it was pretty hard to be 
on the jakarta pmc in the past (though they've been doing commendably 
well considering), because of the huge size of jakarta being distributed 
on so few shoulders. The inclusion of more committers should make life 
easier for everyone.

I'm not an active committer to any jakarta projects atm, but I would not 
hesistate to sign up for the PMC if I were. Not saying anyone should, 
just that there is no (or not much, at least) need to be scared of 
responsibilities, overhead, or time consumption.

.02 euros only,

cheers,

- Leo



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



Re: PMC Nomination

2003-02-19 Thread Leo Simons
Pier Fumagalli wrote:

So, unless this:


The PMC is responsible for the strategic direction and success of the Jakarta
Project. This governing body is expected to ensure the project's welfare and
guide its overall direction.


Changes to identify that individual PMC members might have oversight only on
a fraction (subproject) of the whole project, I would be against it.


I don't think anyone expects that upon becoming a PMC member one would 
immediately need to gain and maintain intimate knowledge of all corners 
of the jakarta codebases. It is just about humanly impossible. So it is 
probably a good move to ensure the PMC is of a size where there are one 
or more people who do have that intimate knowledge for each particular 
corner.

IOW, I do agree with your observation, but I wouldn't worry too much 
about formal documentation maybe not reflecting reality. Reality is what 
matters anyway, and what should be looked at :D

cheers  g'night!

- Leo



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



Re: nice

2003-01-29 Thread Leo Simons
Robert Simmons wrote:

Welcome to real life business. In the real world, not everything goes your
way. You get to choose between a mass of political bullshit and having no
choice at all.


you have a choice: open source software. And it's a good choice for real 
life business, too.

cheers :D

- Leo



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



Re: [discussion] jakarta-gump as community property

2002-12-20 Thread Leo Simons
On Thu, 2002-12-19 at 18:21, Sam Ruby wrote:
 Gump is now two years old.  It has had contributions from over a dozen 
 people, about a half-dozen this month alone.  There seems to be a 
 renewed interest in gump (some in response to a little nudging grin).
 
 Considering all of this, what I would like to propose is that the 
 contents of jakarta-alexandria/proposal/gump get moved to jakarta-gump, 
 all committers to any jakarta code base be given karma and voting rights 
 on the full contents (descriptors, code, and stylesheets alike) and that 
 a single [EMAIL PROTECTED] mailing be created (we are all devs 
 here, right?)
 
 Thoughts?

I like!

I also agree it'd be cool if avalon, ant, xerces, cocoon etc team (all
the ASF java peeps) to be able to access the thing, too.

cheers,

- Leo Simons




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




Re: New logo for Jakarta, following the one on www.apache.org

2002-10-26 Thread Leo Simons
On Fri, 2002-10-25 at 00:50, Nicola Ken Barozzi wrote:
 Attached is a rehashed logo for Jakarta to mimic more the one on the 
 main Apache page, and explicitly state that Jakarta is an Apache project.
 
 What do you think, should we use this instead?

yes, though the trailing slash should be in the url :)

- Leo



--
To unsubscribe, e-mail:   mailto:general-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:general-help;jakarta.apache.org




RE: Differences between Structs and Turbine ???

2002-10-08 Thread Leo Simons

PHP 5 and MySQL 4 will make java, .Net, and all similar technologies
obsolete.

Said one manager to another manager on a golf court, after having
spent the weekend with his 12 year old son who built the school
website.

It took me a week ton convince the another manager that it might
not be a good idea to start building our SOAP services in PHP.

 I still think that the optimal solution is a true SOC using 
 XML, but the world is too stupid to understand that... All 
 everyone wants is a quick and dirty solution...

Yeah, well, you can edit PHP pages in dreamweaver, and manage your
MySQL databases with it too, all automatically, so who needs
programmers anymore anyway?

Says the 12 year old.

The world, stupid? Nah. People would never choose a technically
inferior VCR. We're going to win this.

cheers,

Leo



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




RE: Differences between Structs and Turbine ???

2002-10-08 Thread Leo Simons

 I recently spent a couple weekend nights and built the 
 StudioZ.tv website in PHP4 on OSX.

Hey, that looks like maven! :P

 It is a pretty cool webapp 
 that has really transformed things for us and made my life 
 MUCH easier (the office staff can fully manage the events 
 that show up on the website via a browser). I incorporate 
 several technologies into the site (including a cool XML-RPC 
 interface that talks to presaleticketing.com to tell us how 
 many tickets have been sold). I used PHP because it was quick 
 and easy and I didn't have time to 'design' the application.

We use PHP all the time (I sometimes call it InstantCMS) and
it is a great tool for whacking up a dynamic website. It's just
that creating enterprise SOAP services in it that talk to oracle
on one side and delphi clients on the other is painful. Or
running a site with like 10,000,000 articles and as many
visitors/day.

 The only thing that sucks is that the code is a complete hack 
 that is going to be terrible to maintain over the long term 
 and half the time, I can't figure out why something does or 
 doesn't work.
 
 =)

There's several more things...I just always remember that PHP
used to stand for Personal Home Page =)

cheers,

Leo



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




Re: localhost:8080 vs localhost???

2002-07-19 Thread Leo Simons

I didn't reply because I know POI is just one of microsoft's ploys to
bring java to its knees. The idea behind this scheme is to bring the
worsts bits of their own software to java, promote it using massive FUD
(your recent e-mail proof of this, as is JSP), then improve their own
software, and finally block java from windows all together stating as
reason that it contains lots of crappy stuff like POI.

You, of course, secretly work for microsoft and were specifically hired
to start this dirty game.

I was going to keep silent (as you sent me quite a few of micro$oft $$
to do so), but since you now asked for it specifically, I feel obliged
to share this valuable and dangerous knowledge with the jakarta
community.

best regards,

- Leo Simons

PS: I will be moving house and country 2 minutes after I send this
message, have transferred all my funds to Swiss banks, am undergoing a
sex change tomorrow and have contacted the MIB to erase my identity, so
do not try and track me to let me pay for bringing this news out into
the world. I have also taken the precaution of killing all my family and
friends so you have no way to blackmail me.

;)

On Thu, 2002-07-18 at 22:10, Andrew C. Oliver wrote:
 But no one replied to my lovely email when I said that other than POI 
 and HTTPD there was only actually
 one Apache project, all the others are the same project implemented 
 different ways and that JSP had the
 structure of a dog turned inside out...  I was so proud of that...how 
 mean of you all not to respond :-(
 
 ;-)
 
 -Andy



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




Re: FW: Together ControlCenter for jakarta projects

2002-07-19 Thread Leo Simons

On Fri, 2002-07-19 at 15:04, Vincent Massol wrote:
 What do you think ? Do you think it would be nice to have a free
 TogetherCC license so that projects who wish can create UML diagrams as
 part of their website docs for example ?

yes!

It's funny to see jakarta as an academy though.

You think you can get them to extend the offer to all of apache? (some
of our friends at xml may like it, too :)

- Leo

 
 -Vincent
 
  -Original Message-
  From: Richard Pitt [mailto:[EMAIL PROTECTED]]
  Sent: 19 July 2002 10:47
  To: Vincent Massol (E-mail)
  Subject: Together ControlCenter for jakarta projects
  
   Hi Vincent,
  
   I am just persuing the Together ControlCenter licence issue for you.
   I am proposing that TogetherSoft gives the Jakarta Project an
 academic
   licence, and that all the committers be considered as faculty
 members.
  
   Do you think this would be useful for and/or wanted by jakarta sub-
  projects?
  
   Regards,
   Richard
  
   Richard Pitt
   Mentor
   TogetherSoft UK



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




Re: localhost:8080 vs localhost???

2002-07-18 Thread Leo Simons

  Is that site generated by maven ? ;))
  
  Mvgr,
  Martin
 
 Anakia
 
 I hate to admit it here, but the output is .html files which are then
 processed through PHP. I'm going to be moving away from even using Anakia
 and just using PHP.
 
 PHP is terribly fugly and encourages the worst code design ever, but you can
 get a lot more done with it in a short amount of time and there is no way in
 hell I would ever lower myself to using JSP.
 
 =)

yeah. And it's got a template language called Smarty which is *way*
better than velocity!!!

:P

- Leo, who figured there was another flamefest when he saw all those
e-mails and is now eagerly waiting for a picture of a crossdressing
jon...



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




process of OSS development at jakarta

2002-07-02 Thread Leo Simons

From some private discussions (edited a bit):

  Ok. So, I'll double check the code, get some samples together,
  check it in, and send in a summary email to the list covering
  everything you mentioned above. Sounds like a good plan. Thanks a
  lot for your advice.
 
 pretty much sums it up yes. So your basic process:
 
 1) analysis of use case
 2) figure out problem domain
 3) figure out where to satisfy use case
 4) code solution
 5) test
 6) post solution for peer discussion and review
   7) refactor
   8) test
   9) post revised solution
   10) summarize
 11) satisfactory solution? If not, back to 6. If yes:
 12) document
 
 did I get that right? Probably.

Yes. The process is right on. Perhaps there's a 13) Fix any bugs :)

It all reads like common-sense. I guess somtimes, people need it
to be pointed out to them :) but it's great to have a guide of
what to do, especially how to handle the chicken  egg issues like
'commit, then post', or 'post, then commit', etc.

  Absolutely. I'll be saving this email away in my
  'worth-its-weight-in-gold' folder for I'm sure, many future
  references. :)
 
 cool! If this is indeed such a valuable insight, perhaps it should be
 somewhere for the world to readhmm.

Yes, I was going to say it would be great as part of a 
newbie-committer-kit or the like ? or available somewhere else
easily accessible.

If y'all could comment and perhaps expand a bit, I'll put a webpage somewhere.
Or, if I missed the mark completely, I'll do nothing =)

regards,

- Leo Simons


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




Re: process of OSS development at jakarta

2002-07-02 Thread Leo Simons

that's the idea.

can someone get me karma to site2?

thanks!

On Tue, 2002-07-02 at 13:20, Ted Husted wrote:
 Leo Simons wrote:
  
  If y'all could comment and perhaps expand a bit, I'll put a webpage somewhere.
  Or, if I missed the mark completely, I'll do nothing =)
 
 How about tieing that page in with the outline we started here:
 
 http://jakarta.apache.org/site/guides



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




RE: Interesting quote....

2002-06-24 Thread Leo Simons

just like the BSD tcp/ip code in windows. MS is very good at taking the
best bits of free software and running away with it. They should do it
more often.

 Struth! It gets better! 
 
 What next? IIS - Help - About (c) 1998 ASF That'd be the day

yeah. It'd solve a lot of security problems for starters!

cheers,

- Leo, who's thinking how nice it'd be to be able to plug in mod_webapp
into that IIS



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




Re: Job postings ?

2002-06-04 Thread Leo Simons

 Just wondering if posting Tomcat-specific job offers on the list is
 acceptable, or if there is another place I could post that too (the
 rationale would be to be able to hire someone with extensive Tomcat
 knowledge, and even better someone already involved with the community).
 Since there's now a Vendor page on the Jakarta website, maybe I could add
 a Job Listings page :)
 
 Comments ?

If this takes off, it is going to be a pain for whoever has to maintain
it as good java developers are always in demand (at least over here,
they are), and reqruitment companies will see it as a very useful
(free!) alternative to monsterboard  co.

A list of agencies specializing in matching employers and server side
java developers would perhaps be a little more manageable?

I personally think that forums for advertising job offerings are
well-known and available, online, in abundance, making such a page both
unneccessary and a waste of resources. So I'm -0.

As for job postings on this list, -1. There's enough cruft on this list
already.

regards,

- Leo



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




Re: [PROPOSAL] Committer access and responsibilities...

2002-05-29 Thread Leo Simons

  Case can be made that since putting something in CVS is putting
  something up for lazy majority vote (and I subscribe to that), this is
  not a good 'use case'. But what is wrong with a role for people that
  have the option to propose something for a lazy majority vote, and then
  no right/obligation to actually vote on that 'something' or anything
  else?
  
 
 I think with rights comes responsibility.

Yeah, exactly. And what if there is someone who actually wants less
responsibility and less rights than a committer, but still more than a
contributor?

It is all about granularity: less rights, less responsibility.

 Gee I'd like to dump my code
 here and not bother with the community

Gee I've created this amazing forked version of your codebase (this
amazing book about your project, ..., ...) and now got permission from
my employer to contribute it back. This is quite a lot of stuff, you can
find it at http://somewhere/ to look at. If you accept, do you want 20MB
worth of patches or can you give me CVS access?

What if the community would very much like you to provide that stuff,
you're already committer in other apache projects, but have no time to
support your submission for longer than, say, a month? Should you be
committer for a month?

etc etc etc.

cheers,

- Leo



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




Re: [PROPOSAL] Committer access and responsibilities...

2002-05-29 Thread Leo Simons

On Wed, 2002-05-29 at 14:04, Andrew C. Oliver wrote:
 
  Yeah, exactly. And what if there is someone who actually wants less
  responsibility and less rights than a committer, but still more than a
  contributor?
  
 
 -1

why?

 Does the term white elephant mean anything to you?

thought that was a special kind of elephant...

http://www.dictionary.com/search?q=white%20elephant

...does now.

  I don't think
 there is anything to forbid a community from temporarily granting CVS
 access.

;)

Well, I think our guidelines forbid us. You cannot give someone CVS
access without giving them all the committer rights and responsibilities
as well. That's the point of the discussion, innit?

 I would say such a gift should not be interpreted with the direct
 meaning of the word in German.  Such things usually are wrought with
 problems and with this person who dumps a bunch of code into your
 repository and leaves, well generally it reduces the quality of your
 codebase and no one who IS part of the community knows the code.

This is of course, generalising, and we're leading away from the
discussion here. I say we should evaluate role/right/responsibility
granularity, you write an example line of thought of a potential
candidate for a new role to illustrate you disagree, so I provide a
counterexample.

Not going anywhere; I'd rather see an answer to:

Why is increased granularity in role/right/responsibility bad in
general?

and

Why is defining a new role that is in between the currently defined
roles of contributor and committer in terms of rights and
responsibilities a bad thing?

cheers,

- Leo



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




Re: [PROPOSAL] Committer access and responsibilities...

2002-05-28 Thread Leo Simons

 Since this is a volunteer organization, and we all have other pressing
 responsibilities, it is important that we do not encourage any systemic
 bottlenecks.

I wrote:
  user: no rights, no responsibilities
  developer: right to get quoted as author for authored pieces, no
  responsibility
  committer: right to vote as per voting guidelines, responsibility to
  sign and submit Contributor License Agreement
  pmc member: right and obligation to set overall project direction

this is not quite reflective of our current situation. The term
developer can sometimes be misleading (contributor would be better,
perhaps), while committer perhaps should include some added guidelines
wrt responsibilities.

You might call the fact that these definitions are somewhat out of whack
a systemic bottleneck.

 Since committing is voting, what I think what some people want is a
 non-vetoing Committer.

I think 'some people' don't see/don't agree to the committing is
voting, and then what they want is a Developer-with-CVS-access, which
is more or less what they said.

Committing is voting is not reflected in our guidelines (at least I
couldn't find such a notion).

 Someone to do the work without sharing in the
 responsibility.

sounds like what we call developer in our guidelines ;)

 Which is to say, we can reject what they do, but they
 can't reject what we do. Personally, I would find that type of
 master/slave relationship difficult to maintain in a volunteer 
 organization like this. If you are working hard enough to need commit 
 rights, you are working hard enough to have veto rights. 

What if someone wants/needs commit rights but doesn't want the veto
rights (and responsibilities)? The right to vote also means an
obligation to vote/abstain. The implication of your statement is if you
are given cvs access, you should also take on the responsibility of
voting.

cheers,

- Leo



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




Re: [PROPOSAL] Committer access and responsibilities...

2002-05-27 Thread Leo Simons

  + some mailing list management software + some product release software) it 
  would be very beneficial to push the administration down onto project leads 
 
 So we'll also have 'project leads' ? 

 And some people who write and maintain code, but have different rights ?

we have, in practice, in quite a few of the subprojects. The in
practice part in that sentence explains the quotes around leads.

We have a nice theoretical meritocracy model defining several roles and
responsibilities. That's just fine. The current model defines user,
developer, committer and pmc member.

In real life, there's more roles, overlapping roles, more specific
roles, less specific roles.

Examples: with Avalon, Peter and Berin handle most of our releases; they
assume the role of release manager. Jeff Turner's been working on the
build process; he had the cap of build process manager, now passed
over to Nicola Ken, all informally.

Fortunately, this is all okay and no-one complains. Like Ted said, we're
pragmatic about it.

Thing is, formal roles and responsibilities currently are
(as per http://jakarta.apache.org/site/roles.html):

user: no rights, no responsibilities
developer: right to get quoted as author for authored pieces, no
responsibility
committer: right to vote as per voting guidelines, responsibility to
sign and submit Contributor License Agreement
pmc member: right and obligation to set overall project direction

when these no longer reflect the ad hoc pragmatic roles defined within
subprojects, or when they make using these pragmatic roles difficult,
we should think about changing these definitions, roles and
responsibilities.

Fact of the matter is, the model is not perfect, and not everyone in our
community fits into these categories very well. Saying that everyone who
submits a patch is a developer is a bit of a strange definition, as you
don't really develop documentation, etc etc etc.

Pier brings this up, perhaps in a somewhat clumsy way, but with a valid
point and valid arguments: voila, heated discussion and comments on a
personal note.

if it ain't broken, don't fix it leads to things like windows. We'd
still be forced to work with AWT and JSP.

- Leo



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




Re: [VOTE] New Committer Dan Sandberg

2002-05-24 Thread Leo Simons

  I believe we deserve some explanation from the 'members', I'm
  quite unhappy about this whole issue. If there are some new
  quantitative standards for becoming a commiter ( or a member )
  we should know about.
 
 The ASF members didn't impose any standard. Read my mail on _why_ I CCed the
 members list (I just explained it, the issue of bars and such was brought
 up, meaning that there's interest) and I'd like to do some cross-project
 pollination

While I think we should recognise that each project can set its own
standards up to a degree, becoming a committer also entitles you to some
jakarta-wide priveledges, which means there should be an (albeit
unspoken) agreement between projects on what is the minimum. So I
agree this is a valuable discussion.

 Dan made some excellent contribution to the SSIServlet, great, but on my
 archive, I can see that he posted 7 times to the list, and the first time
 exactly 24 days ago.

I do not think this has to mean he is not a member of the developers
community per se.

For example, Avalon is tightly coupled to Cocoon. A lot of stuff in
Avalon has been brought over from cocoon. There could be a member who
has been working on that code for a long time, using avalon for a long
time, and now is becoming a maintainer of that code, while only ever
having posted 3 messages to the avalon list before. I can see how this
person could qualify for committer status.

However, the following quote alone

He has already put in a great deal of work in re-factoring the
SSIServlet in Tomcat 4.x, and seems to be willing to further contribute
to working on this.

doesn't imo provide enough of a case to grant this person (who I don't
know anything about, btw) committer status.

I'm guessing that there are other unspoken qualities about him /
assurances of his commitment that made some of the tomcat committers
feel this person in fact should be granted committer status. When all
committers know about these other facts, everything is fine. When they
do not (which I assume happened in this case), a -1 is in order, and the
proposal can be ellaborated upon, after which the -1 can become a +1.

If the guy who voted -1 still feels it is a valid vote after this
ellaboration and following discussion, well, the candidate will probably
understand the reasoning, and if he truely does deserve committer
status, it will be granted to him in time, no?

So I think there is no reason to be very unhappy with the current
process we have: no project is even remotely likely to be destroyed by
committers not worth the status, and no potential committer with a thick
enough skin to survive at jakarta in the long run is turned away.

regards,

- Leo



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




Re: Criteria for commit access

2002-05-24 Thread Leo Simons

 Just one question, have you ever voted -1 on a committer? (and not just to
 you, but to every committer on this list).

I've abstained, informally (off-list, that is) from voting, once. The
guy in question had been active in a part of our project but I hadn't
been following on that at all, so I felt incapable to judge.

(ducks in fear of flaming swords coming down from the sky at blazing
speed to strike him dead for committing (pun intended) this terrible
sin)

- Leo



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




Re: new volunteer

2002-05-17 Thread Leo Simons

 i'd like to volunteer a sizeable chunk of my time to apache
 
 i've 3 years java, xml, etc most of which was spent benefitting from 
 apache code without the time to contribute (or was it willingness?)
 
 i'd like to improve my technical writing (partly as an employment move) 
 so I thought apache could do with my labour - which, what, when, where?
 
 I'm committed to DocBook and XSLT so how could this fit with Anakia?
 
 would an apache  DocBook customisation (doctype or scripts) be of use? 
 has one been done?

http://jakarta.apache.org/avalon/developing is in docbook format
(see cvs module jakarta-avalon); it uses Cocoon and XSLT instead of
Anakia. There's probably other places I'm not aware of.
Atitudes toward DocBook vary wildly per project. As a whole, jakarta
isn't committed to DocBook, or XSLT.

XSLT doesn't fit within Anakia very well (the primary author, Jon, is
not too fond of XSLT - search the archives for reasoning).

I would suggest not investing a lot of time into Anakia though - we are
seeing movement to newer tools to handle our documentation
generation...try and search the archive of this list for information on
maven, centipede, forrest, gump and the lot.

starting points:
maven: http://jakarta.apache.org/turbine/maven
centipede: http://www.krysalis.org/centipede

As for documentation content, well, many subprojects could use help.
Check with the ones you are interested in / have knowledge about, on
their respective mailing lists. The content on the jakarta site itself
is pretty good, imo. If you want to supply patches for that, check out

http://jakarta.apache.org/site/jakarta-site2.html

for information.

cheers,

- Leo



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




Re: [Actual Action Taken] Re: Advertisement using Apache lists

2002-05-14 Thread Leo Simons

 Is this for any vendor who wants free ads,

-1

 or only for companies that 
 support Apache projects

+1

 ( and pay the salary for apache commiters ) ?

-1

I think it should just be a these are some companies providing
commercial support for jakarta, and there should be no more ties than
that. Gets messy to quickly. The page should reflect (thinking of an
authority we all know) a search on google about commercial support for
apache software, but sorted categorically/alphabetically rather than by
any kind of rank.

There should be a note on the page probably mentioning that this is the
page its sole intention, and that companies can request addition if they
want (in the form of a patch, I'd say).

 I think it would be fair and nice if projects would include such a page
 in the releases, maybe next to the list of commiters who wrote the code.

That is, of course, up to individual projects. I'm not really in favor
of it (what if there's a new company providing support, giving a client
the distro, and not being listed on that page...too many possible
headaches).

Sorry, Andy, no time for lunch for me today so no patch either...

cheers,

- Leo



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




Re: Advertisement using Apache lists

2002-05-13 Thread Leo Simons

+1 to all of that.

- Leo

 Sun Micro, has a page of here are Java companies  -- lets innovate 
 it and put up a similar Jakarta page -- Here are companies and folks who 
 support Apache Jakarta software.  I volunteer. Secondly, lets Make a 
 rule NOT to post advertising to the mail lists, that is NOT what they 
 are there for.
 
 This does a few things:
 
 1. Provides a good rationale to companies to use Apache Jakarta Software 
 (not a specific goal of the group but a personal goal of several people 
 here including myself as I like working with GOOD software)
 
 2. Gives those companies a place to post thats relevant to Jakarta, 
 won't annoy people who might otherwise use them.
 
 3. Give those companies a high visability web page to advertise on.
 
 4. God I don't need more spam.  My spam filter entries will one day 
 reach the limit on the number of strings I can match on.



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




Re: Advertisement using Apache lists

2002-05-13 Thread Leo Simons

On Mon, 2002-05-13 at 15:44, Alex McLintock wrote:
 At 14:06 13/05/2002, Andrew C. Oliver wrote:
   Secondly, lets Make a rule NOT to post advertising to the mail lists, 
  that is NOT what they are there for.
 
 
 Don't get hung up on adverts. We need somewhere to discuss commercial 
 issues - and there is no apache forum where this is allowed.
 If there was a forum/ mailing list for such matters then you could all say 
 that that is where to post adverts to and *no where else*.

I can see you need somewhere to discuss commercial issues. I cannot see
why such a forum would have to be an apache forum. We can include a link
on the page Andrew is going to make to such a forum in an external
location.

I am all for commercial use and support of apache products, however I do
not think that facilities to enable this commercial use and support
should be provided by apache itself.

twisted analogy: few people that work on the linux kernel have a problem
with red hat; however, I think they'd not like it that much if
kernel.org were to host a forum for use by red hat and the like.

cheers,

- Leo


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




Re: Project Activity

2002-05-11 Thread Leo Simons

This makes me think of all the projects on SourceForge that shoot up
high into the project ratings, with a high activity percentile, just
because they turn the news function into a message board.

If I were to move code from src/java to src/foo, that's quite a few
commits.

You written your 1000 lines today? :D

- Leo

On Sat, 2002-05-11 at 17:07, [EMAIL PROTECTED] wrote:
 Back in mid March there was a discussion around the jakarta overview ( 
 http://jakarta.apache.org/site/overview.html ) and what / wasn't a good 
 measure of project activity. My comment back then was commits on a project 
 are a good indicator.
 
 So anyway, I've added this reporting into the cvs head of maven. For a 
 sample, see: http://jakarta.apache.org/turbine/maven/maven-reports.html
 
 In particular the change log, developer activity and file activity.
 --
 dIon Gillard, Multitask Consulting
 Work:  http://www.multitask.com.au
 Developers: http://adslgateway.multitask.com.au/developers
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 




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




RE: Maven is growing

2002-05-06 Thread Leo Simons

There used to be, at least, back when I was 17...

grz,

- Leo

On Mon, 2002-05-06 at 13:05, Fernandez Martinez, Alejandro wrote:
 Is it not ok to post strong language on this list? Are there kids around?
 
 Un saludo,
 
 Alex Fernández.



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




Re: Database Subproject Discussion : creation of DBCommons ?

2002-05-03 Thread Leo Simons

  The only problem is that yours so far is the only public positive comment
  so far.  I let it stew for a bit and will talk to OJB in the intrim, but if
  people don't see this as a good idea, then it very could might not be.

well, if you insist, +1 then ;)

As long as there's room for avalon-dependent components, I'll support
it...

- Leo



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




Re: Maven is growing

2002-05-03 Thread Leo Simons

You know how many views /. gets? Microsoft.com?

This is getting _really_ silly.

LOL

On Fri, 2002-05-03 at 20:00, Jon Scott Stevens wrote:
 on 5/3/02 10:37 AM, Andrew C. Oliver [EMAIL PROTECTED] wrote:
 
  page views dude, just my way of thanking you for publicity.
  project just switched repositories.
 
 O...page views dude?...you didn't say that...
 
 well, just yesterday we had:
 
 [daedalus] 10:56am ~  grep -c /maven/ 02
 7546
 
 Looks like the *entire* life of your project has been around 9500...
 
 OhhA


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




Re: [PROPOSAL] Centaven and Friends (was Re: You make the decision(was Re: Quick! convert all your projects to maven!))

2002-05-02 Thread Leo Simons

  Centaven Reasoning: I don't see how we can easily do this. The approaches
  are wildly different at basic levels, e.g. dvsl vs xsl, entities vs
  external build files for ant, extending GUMPs descriptor vs generating one
  etc.
 
 I can agree with that. Hell, the dvsl vs. xsl is a showstopper for me.
 
 I can't stand XSL...

you guys are better software architects than this. Whether to use DVSL
or XSL could be use case decided and probably hot-pluggable if it
matters that much. This is possible and not a showstopper at all.

Both projects may need some refactoring. Stop the whining about that it
is not possible. I'm perfectly sure that if y'all want it to be
possible, then it is possible. I've seen GUMP people say it is to some
extent at least, I've seen Centipede people say it is...

It might not be possible, but not for technical reasons. Don't present
it as such.

  Krysalis lists (in the archive) total 53 posts. Maven
  dev (includes cvs) has 780, and the user list 151.
 
 Lol...guess it is really fact now.

what is?

and it goes on

  I'm perfectly happy when people don't like
  XSLT and scratch their own itches, but I do find it quite
  counterproductive when projects are considered to be less 'cool'
when
  they prefer to use standards above home-brown solutions. I'm afraid
I
  really don't want to know your opinion on Xalan and Cocoon, then :-)
 
 First off, Velocity isn't any more home brewed than JSP. Just because
it
 came from 'Sun' doesn't mean it is a standard.
 
 Reality is that JSP was created by someone who never created a web app
in
 his life.

2 definitions of standard:

1) endorsed by a standards body accepted as authoritive
2) being in widespread daily use across the industry

XSLT is a W3C recommendation so it fits 1), there's dozens of open and
closed source projects using it so it fits 2).

JSP fits 2), sadly so. I blame MS and Sun for flooding the market with
tools released to soon.

I think Velocity fits 2), though I've never seen this measured in any
accurate way. I don't know at all about DVSL (in fact, I don't know much
more about DVSL than that it is quite useful and easy to use).

Having said the above, the argument could be made that XSLT is more of a
standard than DVSL is (which I think can for some of our use cases be
compared to an extent).

However, the implicit argument home-brewn solutions are worse than
standards simply doesn't always hold true. It doesn't here. Both XSLT
and DVSL are here at Apache, which, for me, is enough of a standard.

Basically, all this is to point out masquerading of egotism as technical
discussion. This is all very much unneccessary. I personally don't
really care what build tool/platform becomes a standard at Apache. I
also don't care about XSL vs DVSL. As long as it fills the use case
(which every project at Jakarta and XML has), I'm happy. However, it
would be __really nice__ to have some kind of internal apache standard.

If y'all could agree on at least parts of the 'client API' (ie what I
have to do to maven/centipede/gump/forrest/whatever-enable my projects),
that'd be really cool and I'd help out as much as I can. If this won't
work because of egos, standards, or other annoying things being in the
way, well, that's sad.

cheers,

- Leo



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




Re: [PROPOSAL] Centaven and Friends (was Re: You make the decision(was Re: Quick! convert all your projects to maven!))

2002-05-02 Thread Leo Simons

+1

I'm not a big fan of me-too posts, but this is one, bigtime. Apache as a
whole and I think all of the subprojects individually have a real need
for something like this.

- Leo

On Thu, 2002-05-02 at 00:15, [EMAIL PROTECTED] wrote:
 +1
 
 I would go even further and propose a top level project that will
 host all project-management tools, including Gump.

snip

 ***
  PROPOSALS
 ***
  This multi-proposal is an effort to unite forces on the build-system front
  and to give a sense to all project build/documentation/site projects on
  xml.apache and Jakarta.
  
  
  JAKARTA-GUMP
 ***
  Alexandria started as a multi-project documentation system, and is now dead.
  Gump started there by using the Alexandria descriptors but has become a
  conyinuous-integration tool.
  
  I propose that it finally becomes a top-level Jakarta project, as it is now
  de-facto.
  
  The Vindico proposal will migrate to that project as well and will have the
  possibility to challenge the current de-facto Gump codebase with a vote as
  permitted by the Jakarta rules.
  
  
  JAKARTA-ALEXANDRIA
 ***
  Alexandria still has an important mission, that of creating beautiful
  cross-referenced Java project documentation.
  Maven has taken part of the code-base AFAIK and is using it.
  Centipede is producing source-code cross reference with javasrc and
  umldoclet, and is working on creating SVG UML package charts.
  
  Alexandria can continue with its mission.
  Maven can port-back the code it uses.
  Javasrc developer Bill Smith has decided to DONATE the code to the
  Alexandria project and continue coding there
  (http://sourceforge.net/forum/message.php?msg_id=1552505).
  Centipede will give all the code it has that generates documentation.
  
  CENTAVEN
 ***
  Maven and Centipede have similar goals but different approaches.
  
  I would like to see them united, and have a single project description
  system.
  
  We have the need, we have the community, we have the code.
  
  Centipede will never be able to make it into Maven and viceversa, because
  the approaches are very different.
  
  I think that these can be overcome, and that we can devide a comon system
  that solves *all* our  _needs_.
  
  
  SUMMARY
 ***
  Here is my +1+1+1 for all three proposals.
  
  This is the best I can do, and what I think is in the best interest for
  Apache.
  
  What do you think?
  
  --
  Nicola Ken Barozzi   [EMAIL PROTECTED]
  - verba volant, scripta manent -
 (discussions get forgotten, just code remains)
  -
  
  
  --
  To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
  For additional commands, e-mail: mailto:[EMAIL PROTECTED]
  
  
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 




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




Re: You guys are so funny.

2002-05-02 Thread Leo Simons

 Bike Sheds
 --
 
 At first, people -1'd the use of Anakia to generate the Jakarta website. But
 then when I took the effort to make it simple and easy to use and took away
 the bike shed argument, people adopted it and used it all over the world.

I really _don't care_ whether it is XSLT, or DVSL, a GUMP project
descriptor or a maven descriptor. I don't care which project hosts what.

I want all my bikes to fit into the same shed. I think there's quite a
few more people out there that feel the same.

Use case


1) fire up computer
2) run grab-a-coffee-during-complete-update.sh
   - cvs update of everything
   - build of everything
   - test of everything
   - compilation of errors sent via e-mail to me
   - overview of changes sent via e-mail to me
3) read e-mail

everything should include docs, dependency graphs, javadocs, javasrc,
website, pdfs, etc in an ideal situation.

I also need pluggable look and feel (I don't want my company website
looking like the Jakarta one), extensibility, pluggability and
manageability.

* easiest way of satisfying use case

Combining that complete myriad of tools other people wrote would enable
me to do this. I could rip out the components I need from different bike
sheds and build the power plant I need over the weekend.

There'd be Yet Another Bike Shed, and everyone would do it, and there'd
be no more collaboration.

* best way of satisfying use case

Discuss with smarter people that wrote those tools how to handle this,
agree on course of action, combine different bike sheds into reusable
power plant.

Use case 2
--

The avalon project badly needs a better website. It needs a better look
and feel.

* no satisfaction

There's a jakarta project(1) that handles this, but I do not like the
look it provides. I created a MVC presentation layer file(2) in the
project's custom presentation layer language(3) to provide a custom
look. I found it too difficult to create a patch for this project that
enabled this look while preserving the one currently in use by this
project.

* satisfaction

Avalon currently uses cocoon (sort of an eat-your-own-dogfood case), and
other developers would like this to stay that way. There is a tool(4)
that does the same thing as the jakarta project, created by people from
xml.apache. The tool does allow me to plug in this look, and it uses
cocoon.
I complain about how difficult it is to plug in the look, as docs are
lacking. The tool author(5) promises better docs, and in the meantime,
promises to provide the look I envisioned with his tool.

So, what's the bad part? The jakarta project is being pushed by some
people(6) at jakarta to be the next de facto standard for generating all
of jakarta's web site documentation. I like to follow standards, de
facto or not, if at all possible.

* optimal satisfaction

The two competing projects merge to the extend where they satisfy the
use case together. Avalon can keep eating its own dogfood, as that food
becomes part of the to-be-de-facto standard. As there are no more
competing projects, this de facto standard becomes more 'standard'.

(1) Maven
(2) at
http://cvs.apache.org/viewcvs/jakarta-avalon/src/proposal/site/anakia/xdocs/stylesheets/site.vsl?rev=1.3content-type=text/vnd.viewcvs-markup
(3) DVSL
(4) Centipede
(5) Nicola Ken
(6) Jon

Summary
---

I have personal, commercial and jakarta project use cases for a tool
that combines features from all the different build tools that exist.
Many of those tool authors have those use cases as well and are open to
this combination and would like to cooperate to make this work.

Problem
---

The optimal satisfaction of the mentioned use cases is, as far as I can
tell, only hindered by an unwillingless of some of the tool authors to
cooperate.

Where, in all this, am I building any kind of shed? Where am I not
thinking free? Who is missing which point?

 People
 --
 
 Needless to say, the attitudes here are becoming more and more familiar.
 Andrew reminds me of the early days of dealing with Peter Donald (credit to
 Peter for eventually coming to his senses...I think joining the PMC helped).
 Steven reminds me of Paulo. Deja vu!

I am not on any PMC, I have never hired anyone in my life, I have no
degree, I have no imposing career, no company. I don't have a car. I
don't even have a driving license. I have, in terms of code, contributed
only in a very modest way to the jakarta community, and I have not been
around very long either.

Does any of that matter, at all? If it does to you, well, I don't really
think you're thinking free, or open, at all.

cheers,

- Leo



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




Re: You make the decision (was Re: Quick! convert all your projectsto maven!)

2002-05-01 Thread Leo Simons

 If the two work 
 together its virtually irrelevant to me WHERE.  I just want the to.  
 
 Personally I'd like to see the combined Centaven moved to a 
 jakarta.org/centaven level.  If this effort is truely undertaken, POI 
 will upgrade to a combined centaven.  (I don't care what its named its 
 the senitment).. .  Then who wins?  Well everyone.  We get what we need.  

I'd give a big +1 or so to that one. We've been having some troubles
with this over at avalon, not wishing to choose one over the other,
wanting features from both, not having time to do the integration
ourselves.

I'm quite sure we would switch within like 72 hours after the first
combined alpha coming out. Maybe sooner.

- Leo



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




Re: You make the decision (was Re: Quick! convert allyour projects to maven!)

2002-05-01 Thread Leo Simons

  There are things I like about Centipede, too, e.g. the cents, and I think
  there could be a lot of synergy between maven and centipede, e.g. the skins
  side of things is something I'd like to see with maven, but looking @ POI's
  site under Linux, the stylesheets need some work :)
 
 Andrew, consider using the CSS from the Tigris Style project
 http://style.tigris.org/.  It's a new project, but already in use in
 several major OSS code bases, including Maven, Scarab, and Eyebrowse.

I looked at these and they're a major pain in the *** to modify - you
have to modify code in 3 places in 3 files or something for every change
you wish to make; css classes are used more widely than their naming
implies, etc.

While this is a very plausible effort and I would like to help out, I
found it too difficult to figure out where to start so ended up
reworking some design I had lying around to do a quick demo. People
liked that a lot and it got used in POI. While cross-browser support is
somewhat worse, the sheet is generally clean enough to understand.

It'd be cool if the style.tigris.org stuff got some docs and a little
refactoring so I could take those as a basis to start from and do some
tweaking. As it stands, such 'tweaking' would be a maintainance
nightmare.

 The CSS was developed primarily by Todd Fahrner (a co-worker of mine
 who did a bit of work on the spec), and has excellent cross browser
 and accessiblity support.

I would have to disagree on the accessibility. Without going into
details (most of you wouldn't be interested), I found it too difficult
to figure out where to submit what kind of patch.

Maybe in a few weeks...

cheers,

- Leo



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




Re: New Subproject proposal Config4J

2002-04-29 Thread Leo Simons

We had a nice discussion 'bout this on avalon-dev a while back. You can
read the thread at

http://www.mail-archive.com/avalon-dev@jakarta.apache.org/msg07495.html
http://www.mail-archive.com/avalon-dev@jakarta.apache.org/msg07589.html

This was about nondescriptive naming of packages inside a subproject
with a nondescriptive name inside a jakarta project with a
nondescriptive name, inside jakarta, which has a nondescriptive name.

Basically, it'd be nice to call Avalon ServicesFramework4J, but its
not really fair to do so (Turbine's Stratum is also a
ServicesFramework4J), so we don't. Deal with it.

BTW, I've found that hardcore coding is absolutely _the_ place for
what you call stupid names:

linux
GNU
Emacs
Bash
Less
Apache
Jakarta
Gnome
(...)

grz,

- Leo, typing a message inside Ximian Evolution, running on Red Hat
linux, not getting annoyed at any of those names

On Mon, 2002-04-29 at 10:11, Endre Stølsvik wrote:
 On Wed, 24 Apr 2002, Jon Scott Stevens wrote:
 
 | One more thing, come up with a more creative name. :-)
 |
 | The whole FooBar4J thing is tired IMHO.
 
 May I say that the whole Jakarta naming scheme is really tired, imho. What
 does Velocity do? What does Tomcat do? What does any of these stupid
 names do?? log4j does _at least_ give you a definite clue of what to
 expect from the package.
 
 Creative names.. Well.. This isn't a fashion school or something. It's
 hardcore coding. And I'd like to use log4j, JServ and Macro4Web,
 rather than Pink, Lovely and Housewarm..
 
 
 -- 
 Mvh,
 Endre
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 




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




outlook virus targetting apache developers

2002-04-29 Thread Leo Simons

all,

one of the latest outlook worms has found its way to a user with lots of
ties to Jakarta. I believe the apache mail servers are filtering out the
malicious messages correctly, but if you use an address other than
[EMAIL PROTECTED] you may be affected if you use windoze.

I'm mentioning this because the virus includes fake from: headers, so
you might be led to suspect the apache machines or developers have been
compromised, where this is not the case.

I've contacted the offending ISP via e-mail.

Please don't hit each other on the head because of someone else's faults
and update your virus scanners (or switch to a decent OS) if you haven't
already.

regards,

- Leo Simons





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




RE: RE: Subproject Proposal - crossdb

2002-04-25 Thread Leo Simons

 So, I'm kind of curious what the general consensus is regarding this.  Seems to be 
in various directions.  

I think JDBC should be a lot better; it should incorporate all the
features of CrossDB (though maybe a little different), and some more.
Then there should be higher-level tools like Torque that use it.

Since JDBC has limitations, there should be something like a patch
library that adds the extra features, while staying on the same level
as JDBC.

Torque should then use that.

Whether the library should be a part of Torque or not is really only
of marketing/exposure/etc concern; as long as its decoupled I'm happy.

Jon indicates that this low level library already exists within Torque
and that it is easy to use. If this is true, it may perhaps need some
decoupling, and some of the stuff from CrossDB and similar OSS products
fed into it.

Since I will probably not do the programming of any of that anytime
soon(no cycles), this is very IMHO.

cheers,

- Leo


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




RE: Subproject Proposal - crossdb

2002-04-22 Thread Leo Simons

 I never said they were the same. I said that crossdb is a few generations
 behind Torque in design and thinking.

In the sense that Torque is an object-relational tool and crossdb is not,
Torque has a newer design. That does not mean relational tools do not have
a place in Java anymore.

 You also left out all the code related to getting the 'conn' 
 object. Torque
 abstracts all that away so it isn't necessary at all.

Which is not valid in every use case. CrossDB uses a factory.

 Another problem with crossdb design is that you are defining all of the
 database logic within the code instead of abstracting it elsewhere.

Which has advantages over O/R, which is the reason not everyone uses O/R
for everything. I'd say it is a choice instead of a problem.

 What is the benefit of using crossdb over Torque?

You do not have to use an O/R layer that abstracts you away from the
database you are using so much that it limits your ability to use the
DB's functionality in something resembling a db-natural way.

You do not have to worry about typical O/R problems such as speed
impediments. You can use crossDB in an interactive mode (like with
BSH), while you cannot with Torque.

I could go on and on, but I see no point. Summary:

Torque is a persistence layer that uses O/R mapping to use a database
to provide persistence. A persistence layer is a handy tool in many
server applications.

CrossDB is a database abstraction layer that uses the Factory and the
Builder pattern a lot which enables you to write code that works on
several databases, transparantly. You can see it as an extension to
JDBC. Database abstraction layers are useful in any application that
talks to databases.

While these may not be accurate summaries, I hope you now do see that
CrossDB and Torque are not, in the majority of use cases, alternatives
to one another.

Note: I gathered all this from just three code snippets on the CrossDB
site and extensive use of Torque in my projects, so I may be wrong.

- Leo

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




RE: Subproject Proposal - crossdb

2002-04-22 Thread Leo Simons

 Torque doesn't have a 'newer design'. It has a more mature design. Torque
 has been around for about 3-4 years now.

SQL's been around for 20. APIs to create SQL statements have been
around for about as long.

  Which has advantages over O/R, which is the reason not everyone uses O/R
  for everything. I'd say it is a choice instead of a problem.

 Right...like using JSP over Velocity is a choice. That said, JSP still
 sucks. :-)

A strange comparison. JSP and Velocity fulfill the same use case, where
JSP does it badly and Velocity rocks. That is nto the case here.

  What is the benefit of using crossdb over Torque?
 
  You do not have to use an O/R layer that abstracts you away from the
  database you are using so much that it limits your ability to use the
  DB's functionality in something resembling a db-natural way.

 That is like trying to argue that using ECS is the way to write HTML.

It is not. How easy (or sensible) is it to call an ancient stored
procedure written in a procedural language using Torque?

  While these may not be accurate summaries, I hope you now do see that
  CrossDB and Torque are not, in the majority of use cases, alternatives
  to one another.

 I'm sorry. I don't see that. Torque can do everything crossdb can do and
 more.

Since you're talking examples, let me as well:

I have a 25 year old banking application, for which was written 12 years
ago an SQL layer to integrate it with the newer tools. To this was added,
6 years ago, another layer that used stored procedures for everything.
Then, 3 years ago, a tool was written to pipe all info from that db, using
the stored procedures, into pgsql to hook up to JSP and the internet.

I want to have a jar file that can be used to talk to the stored
procedure layer, the piping tool, the pgsql database and also the 12 year
old SQL layer because I discovered lost functionality there that I need
for the new eCommerce stuff.
This will be used in the existing JSP application as well as in a new
management console, where the management console should also be able to
talk to a much newer database application running Oracle.

You can probably figure out a design where Torque fits in. But it wouldn't
really be the right tool for the job. I don't know whether CrossDB is, but
its use case description fits rather nicely.

- Leo


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




RE: Subproject Proposal - crossdb

2002-04-22 Thread Leo Simons

 Torque has been separated for about a year now.
 
 We haven't found a reason to make it a top level project yet.
 
 I really don't understand why the location of a set of code matters.

The one reason I can think of is exposure.

Which could be seen as a good one.

- Leo

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




RE: subproject layout conventions

2002-03-30 Thread Leo Simons

 Leo Simons wrote:
  As long as we agree that nothing should get into the way of 
 site functionality (and we do), why would you oppose a site that 
 also is easy to navigate and looks good?
 
 The only thing I oppose is the idea something being set in stone or
 approved by some mythical designer. 
 
 http://www.mail-archive.com/general%40jakarta.apache.org/msg04500.html

ouch. Bad wording. Not what I ment. I'll -1 myself on that :)

We're in agreement (I was sure we were, just didn't get where it went
wrong). Sorry to waste your time.

regards,

- Leo

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




Re: subproject layout conventions

2002-03-29 Thread Leo Simons

 There is no paid staff, and AFAIK, no designers who are also
 committers.

The maven layout looks like it has been designed by a designer.

  except that the website is not only for geeks. It's also for people
  that make decisions and have money.
 
 Says who? 

Me. I wan't to use jakarta stuff in the 'corporate' world. Parts of the corporate 
world want a 'sleek' looking site. Where it doesn't hamper anything else, I think 
there is no problem making the site look 'sleek'.

 Personally, I leave the eye-candy to others, and focus on functionality.

I thin navigation is part of functionality, not eye-candy. Without navigation, you 
need to know the address of every web page on the site.

 I'm not saying that I would be particularly interested in any design
 anyone else came up with. I'm just saying that if I need to change it,
 I'm going to change it, because there ain't nobody else here to do it.

I need to change it, so I want to do so. Since I believe the changes I need to make 
will benefit all of jakarta, I am trying to make them in a way that all of jakarta can 
live with.

 Personally, I'd say it's better that our sites don't look ~too~ good.

Don't worry, we're not gonna look too good just yet :D

 That way people don't get the wrong impression. There is no commericial
 support here. Just a bunch of volunteers doing the best they can.
 Jakarta is an all-you-can-eat buffet, and should probably look like one
 :o)

Jakarta is partly funded by commercial companies. I think some of them would rather 
not be associated with something looking like an all-you-can-eat ;)

As long as we agree that nothing should get into the way of site functionality (and we 
do), why would you oppose a site that also is easy to navigate and looks good?

regards,

- Leo


__
Launch your own web site Today!
Create a Web site for your family,
friends, photos, or a special event.
Visit: http://www.namezero.com/sitebuilder

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




RE: Managing versions of Apache Jakarta software

2002-03-28 Thread Leo Simons

It would also be very nice if this were rolled into Maven :)

cheers,

- Leo

 Well, at this point Adam, we don't so much has have a written guideline
 for creating a Jakarta release, so adding versioning to a non-existent
 guidelines poses something of a challenge :O)

  Please please please make it a standard that all Jakarta JARs are
  distributed with correct version information in them.

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




RE: subproject layout conventions

2002-03-28 Thread Leo Simons

  - color variations (and all other lf changes) should be
part of the original look-and-feel design. Giving
programmers free reign to do this spells disaster.
It would be best to have the original designer of a
look and feel work this out. Very strictly.
 
 :(
 
 Seriously, I don't dig the big blue background.

that is something we agree on =) While we're at it, I
think the entire header should be smaller. The jakarta
logo is just too big. I'm not volunteering though...
I'm no photoshop biggie.

  With
 projects like Batik, we can generate images that fit
 with any background color.

really? How well does that work? Does it work on bitmaps?

 The color customization whould be in the project header.

note that all jakarta subproject logos currently are meant
to work with a white background. The Avalon logo would
probably look terrible against something else (as it has
little color). Yet the maven design falls apart if you make
the header white (doesn't really fit in).

  - the navigation setup we currently have sucks. The
one used by turbine right now is slightly better,
but only slightly. We need arbitrarily deep levels.
The best option is a breadcrumb trail.
 
 Yes and no.  The Breadcrumb trail + the Maven approach
 would be ideal.  It is easier to get a grip on what
 is available without having to go back to the parent
 level each time.  You should at least see all peers.

I agree. In general, I would not recommend it, but most
of the peer pages on jakarta have a tight enough
relationship that is warranted. Is it true for all
pages, though? Maybe a peer list should dissapear at
a certain depth. This deserves more thought.

(...)

 And I have designed several web applications, and also am
 well versed in site design and color customization.

Then you will agree that changing of the header color should
also mean changing of the color of all the section headers.
And that, if you change the header to white (as would be
required for some subproject logos), you should change the
section headers to a black background. Which is
equivalent to shouting.
Hence I'm scared of free reign.

 jakarta.apache.org  avalon  excalibur
 CLI Collection Command Concurrent 
 
 And the right hand navigation like on the maven site?

I would probably not have the breadcrumb and peer lists
directly below each other in the current maven layout.
This deserves more thought.

  anyone feel like throwing stones at me yet? :)
 
 Sure, but let me get my aim just right :P

You seen braveheart? :)

cheers,

- Leo

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




RE: Managing versions of Apache Jakarta software

2002-03-28 Thread Leo Simons

and to think I haven't even downloaded it yet! :D

 *gets the feeling that the project marketing campaign for Maven has 
 begun and wonders if he bought into a time share and singed up for a 
 free seminar by accident*
 
 Leo Simons wrote:
 
 It would also be very nice if this were rolled into Maven :)


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




RE: subproject layout conventions

2002-03-28 Thread Leo Simons

Hey, I'm a programmer myself ;)

as a reassurance:

the changes this discussion talks about will happen in jakarta-site2,
and will consist of backwards-compatible changes to site.xsl and
site.vsl. Projects that depend on jakarta-site2 will change to the
new look and feel automatically. For projects that don't, all I ask
is that they, after evalutation of the changes, update their local
copies of those files. And it really is just a request.
So this will _not_ change the way a project website is maintained.

Somewhat further down the road is converting your project to use
maven. This is apparantly not that difficult. The advantage maven
will bring you is that you have to worry _less_ about updating the
website, as it does a lot of boring stuff for you.
This is of course a project's own decision!

as background:

Our company is venturing out from its microsoft-only platform and
directly into open source, because a big new client requires it.
Some of my collegues want to move from ASP to PHP. I wan't to move
to all the wonderful stuff at jakarta. Problem is, my boss makes the
decision. To convince him, step 1 is a project site which he likes.

Danny:
 I agree with Ted, it'd be nice to have a more polished and brand conscious
 site, but at then end of the day we're just a bunch of geeks writing stuff
 for other geeks, and in general I think we each want to concentrate our
 efforts on the geek stuff.

except that the website is not only for geeks. It's also for people
that make decisions and have money.

 Leo Simons wrote:
  anyone feel like throwing stones at me yet? :)

Ted:
 Only to remind you that the programmers/developers are the
 decision-makers here. So if you want them to buy into something, you
 need to coddle them the same way you would your boss or any other suit.

And I always thought being reasonable, giving good arguments and doing
the job yourself if you want it done was how we work =)

 The day Jakarta starts to say, it has to be this-way or
 else, is the day a lot of us would choose or-else.

I think many people will agree that how the website looks and works
is something where it would be very benificial to all the projects
if there was a consensus. So I think Jakarta _should_ say:
*here's* why we recommend we all do it *this way*, and *here's* how to do
that
(ie see: http://jakarta.apache.org/site/jakarta-site2.html)

 When the original designers are not available, whoever is available
 needs to do whatever needs to be done. The only ones we are sure are
 going to be here are the programmers, so the programmers ~have~ to be
 able to do everything.

I very much agree. I was under the impression though that at this point,
there are some designers available somewhere. It would be good if they
would explain which things would be good to change so we can put that
into the system.

 I'm very much in favor of what you are trying to do, but what we want to
 hear is that this is something that should just work out of the box for
 everyone, but can still be easily adjusted if necessary.

=) One thing the proposed changes will do is that they will make it easier
to adjust the stylesheet.

In short, I understand these concerns, they are of course addressed, and
we can go a little further than that once maven stabilises and make
everything even better (how's that for marketing? :P)

cheers,

- Leo



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




jakarta-site2 stylesheet makeover (was: RE: Printable pages)

2002-03-27 Thread Leo Simons

Taking the release early, release often advice to heart, I've
applied changes mentioned to the page at the url I posted earlier
and started work on the site.vsl file in jakarta-site2 (which
basically means cutting out a whole lot of stuff).

I've got no real previous experience with either the module or
velocity, so there might be 'some' mistakes :) Wasn't quite able
to figure out how to do testing. Someone wanna lend a hand?

cheers,

- Leo, short on time(tm)

 -Oorspronkelijk bericht-
 Van: Leo Simons [mailto:[EMAIL PROTECTED]]
 Verzonden: Sunday, March 24, 2002 10:00 PM
 Aan: Jakarta General List
 Onderwerp: RE: Printable pages
 
 
 Berin:
In that case, the entire Jakarta site needs to be redesigned.
It makes use of embedded tables and font elements.  It does
not use CSS at all.
 
 Jon:
   Correct.
 
 Me:
  I don't know much about anakia, but I know more about xhtml and css
  than I do about java (sadly so =). I'll volunteer.
 
 http://www.leosimons.com/scratchpad



site-proposal.vsl
Description: application/cnet-vsl

body, td {
			background-color: white;
			color: black;
			font-family: Arial, Helvetica, sans-serif;
			font-size: 11pt;
}
p {
	 		text-align: justify;
}
div {
			margin: 0px;
			padding: 0px;
}
h1, h2, h3, h4, h5, h6 {
			background-color: #003366;
			color: white;
			font-family: Verdana, Arial, sans-serif;
			font-weight: bold;
			padding-left: 5px;
			padding-right: 5px;
			padding-top: 2px;
			padding-bottom: 2px;
			margin: 0px;
}
h1 {
			font-size: 18pt;
}
h2 {
			font-size: 13pt;
}
h3 {
			font-size: 11pt;
}
h4 {
			font-size: 10pt;
}
h5 {
			font-size: 10pt;
}
h6 {
			font-size: 10pt;
}
a, a:visited {
			color: #336699;
}
a:hover, a:active {
			color: #003366;;
}
#contents div { margin-left: 40px; }
#breadcrumbs {
			border-top: 1px solid #003366;
			border-bottom: 1px solid #003366;
			margin-top: 10px;
			margin-bottom: 20px;
			padding-top: 0px;
			padding-bottom: 2px;
			padding-left: 10px;
			font-size: 10pt;
			font-weight: bold;
}
#menu {
			border-top: 1px solid #003366;
			border-left: 1px solid #003366;
			border-right: 1px solid #003366;
			border-bottom: 1px solid #003366;
			width: 175px;
}
#submenu ul {
			margin-top: 5px;
			margin-bottom: 5px;
			margin-left: 25px;
}
#footer {
			border-top: 1px solid #003366;
			margin-top: 20px;
			padding: 3px;
			text-align: center;
			font-size: 9pt;
			font-style: italic;
}
a.breadcrumbs, a.breadcrumbs:visited, a.menu, a.menu:visited {
			font-size: 10pt;
			font-weight: bold;
			text-decoration: none;
}
a.breadcrumbs:hover, a.breadcrumbs:active, a.menu:hover, a.menu:active {
			text-decoration: underline;
}
.code {
			font-family: Courier, Courier New, monospace;
}
.section .code {
			margin-left: -40px;
}
@media print {
	body td {
		font-family: Times New Roman, Zurich Bt, serif;
		font-size: 10pt;
	}
	h1 h2 h3 h4 h5 h6 {
		page-break-after: avoid;
		color: black;
		background-color: transparent;
		padding: 0px;
	}
	h1 {
		margin-left: 40px;
	}
	h2 {
		margin-left: 80px;
	}
	h3 {
		margin-left: 120px;
	}
	h4 {
		margin-left: 160px;
		font-style: italic;
	}
	#menu h4 {
		margin-left: 0px;
	}
	h5 {
		text-align: center;
	}
	h6 {
		text-align: center;
		font-style: italic;
	}
	.code {
		page-break-inside: avoid;
	}
	p ul {
		page-break-inside: avoid;
	}
	.section .code {
		margin-left: 0px;
	}
	#menu {
		display: none;
		width: 0px;
	}
	#contents div {
		margin: 0px;
	}
}




site.vsl.diff
Description: Binary data

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


subproject layout conventions

2002-03-27 Thread Leo Simons

It has been brought up by many people that there
is no common way of organising subproject websites.
I propose we draft a set of guidelines (_not_
rules) on a general structure.

Lets start with some discussion :)
---
Navigation / Organisation
---
The current website is presented as three layers:

- Jakarta main
- subproject main
- subproject menu
- subproject submenu

so the deepest level you end up in is

jakarta  subproject  section  webpage #position-on-webpage

The jakarta site has grown a lot bigger than supported
in such a hierarchy, hence the problems. Some projects
try to adhere closely to unofficial convention by
adding a layer:

- jakarta main
- subproject main
- sub-subproject main
- sub-subproject submenu

jakarta  subproject  sub-subproject  section  webpage
#position-on-webpage

while maintaining the layout. Avalon is an example.
Recently, Turbine has chosen a new layout to add this
extra level.

I don't really like this solution, as it will likely prove
to be inadequate in time. Also, subprojects that organise
themselves differently according to different criteria might
not fit into such a layout IMHO, we should have arbitrarily
deep levels, and a navigation structure which reflects
this.

There are five main approaches in websites tackling this:

1) breadcrumb trail
site  subsection  ...  subsection  page
example: www.dmoz.org

2) GUI-style menubar.
Your browser probably has one. Requires DHTML or similar
technology, _still_ doesn't seem to work well (ie combined
with html forms etc). example:
http://www.webreference.com/dhtml/hiermenus/

3) GUI-directory style tree.
Don't know of a file browser that hasn't got one (ok, so
you can do something different in MacOS 10, so what?).
Also requires DHTML or similar technology to work; scripts
available that _do_ work well.
example: http://msdn.microsoft.com/library

4) keyword-associated.
Kinda difficult to create by hand; WikiWiki's are usually
structured into tree-like structures by many people.
example: http://c2.com/cgi/wiki

5) criterium-selected.
An example is slashdot where the criterium is date of
placement. Older items fade into oblivion.

Each of these is often accompanied by a keyword-based search
facility, and depending on the site can have specific search
options as well.

They can, of course, be combined.

There are, of course, silly sites that have an approach that's
different from these. Users get lost on those.

So far for stating the obvious.

I would like to combine #1 with listing a limited tree containing
the current subsection and the parent subsection. Its scalable and
simple, and degrades well towards older browsers. Also, it is very
commonly used on many websites so users are familiar with it.

---
Common Sections
---
These can only be commonly defined to a limited extent. However,
recognising that we are dealing with open source software projects
means the subproject sites (can/probably should) have more than
just a navigation structure in common.

For each subproject, I propose, based on what the various projects
are currently doing, the following sections and subsections:

Essentials
- Overview
- News and Status
- Features
- Downloads
- project specifics

Documentation
- Installation
- Getting Started
- Tutorial
- User Guide
- Developer Guide
- Javadocs
- project specifics

Development
- Changes
- Todo
- Proposals
- Resolutions
- References
- project specifics

project specifics

for subprojects that do not have further subprojects. For
those that do, I propose the following sections and subsections:

Essentials
- Overview
- News and Status
- Downloads
- project specifics

Subprojects
- list of subprojects

Development
- Changes
- Todo
- Proposals
- Resolutions
- References
- project specifics

project specifics


regards,

- Leo Simons


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




Re: Printable pages

2002-03-25 Thread Leo Simons

  thoughts? Is this wanted?
 
 Looks good to me, certainly better than the avalon section as it stands
 IMHO, just a couple of points though.
 I like the Apache.org  Jakarta  Avalon  Framework:  depth indication -
 would be great to see this applied across the board.
 I can't decide which way around I like the logos at the top but in this

nor can I =) Probably the current arrangement is better.

 (maybe we could use half size versions in print - not thought this
 through yet though).

that's what I would like to do. To apply this across the board means we need to create 
smaller logos for all projects first, because text might become unreadable otherwise.

 I like the menu on the left being boxed but can't see how its that useful in
 print - why not use a @print  display:none

I haven't actually done a print-specific stylesheet yet. The print preview was more to 
show what would print for browsers that don't support @print. (my IE has background 
printing disabled by default, so it decides to print the headers in grey for some 
reason)

Will do as suggested tho'.

 but in print my preference is for high
 contrast and so I would prefer black rather than grey for the headings - If
 its going to come out grey on black and white printers then maybe choose the
 blue instead to add a bit more contrast to colour prints.

my thoughts exactly...will do.

 Just my 2p,

thanks!

regards,

- Leo


__
Launch your own web site Today!
Create a Web site for your family,
friends, photos, or a special event.
Visit: http://www.namezero.com/sitebuilder

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




RE: Printable pages

2002-03-24 Thread Leo Simons

Berin:
   In that case, the entire Jakarta site needs to be redesigned.
   It makes use of embedded tables and font elements.  It does
   not use CSS at all.

Jon:
  Correct.

Me:
 I don't know much about anakia, but I know more about xhtml and css
 than I do about java (sadly so =). I'll volunteer.

http://www.leosimons.com/scratchpad
(note I tried to put this in CVS but have no karma so...)

Here's a design I've had lying around adapted to Jakarta. Two screen
shots using IE 5.5, one is normal the other is print preview. I should
be able to make this work (more or less, at least) in everything
from NS2.x upwards. HTML also available for browsing.

The main problem is the code sections. If the line is too long to
fit on screen or page, it causes the entire page to break out, which
is ugly. The only thing I can think of is to use a css float: left
directive with @print, which cuts of a bit of the code. That, and
adapting the pages manually to keep the line length at bay. Suggestions?

Of course, colors are adaptable to current ones if desired...

thoughts? Is this wanted?

cheers,

- Leo Simons

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




RE: Now what? (was: Jakarta Overview)

2002-03-23 Thread Leo Simons

 - Audience and Marketing:
 Specifically, it is directed towards users, who hope to find
 something useful for their own projects. (Those users may turn
 into contributors over time!)

It takes too much effort to support a user base for a project
that changes rapidly (ie any 'alpha' status code). Hence these
parts are not advertised very well. It should stay that way.

 I cannot understand why Leo and Ceki refer to the document (and,
 by implication, others like it) as Marketing - a term which 
 carries in this context clearly condescending connotations.

as dion said. When a project you are working on very hard for
a long time is listed as immature or something like that, it
is very hard to find the right wording for a response.

 - Users vs Developers

again, I personally distinguish between alpha, beta and final
releases. You only offer support (answers to mailing list
questions) for released products.

 - Personal Assessment and Maintenance:
 In terms of maintenance: Once everything is set up, this should
 not take too much effort (just updates of revision numbers and
 release dates, really). I think I also hinted (cough) that I
 might be willing to help with that (to the degree that I have
 available resources, of course) provided that maintaining such
 an overview document at all is solidly supported by the community.

as we say: documentation is always welcome!

 Now what? 
 =
 
 The News section has also disappeared - I consider
 that a bit sad: I think some measure for the activity of the
 project would be helpful, but there may be better ways to determine
 it. I would have thought that the date of the most recent release 
 would not be considered a subjective judgement.

it's simply not a good indicator. FA, almost nothing happens
over at Avalon Framework, but it gets more releases than the
way more busy other Avalon parts because it is, well, released.

 Should we:
 - collect suggestions to improve the initial draft so that the 
   majority here considers it a good thing to have and develop it
   further along those line?
 - leave it as is?
 - drop it altogether?
 - replace it with something altogether different?

it should, -- after consent by others here -- be merged with the
current overview on the front page. That's imho, of course.

greetz,

- Leo Simons

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




RE: JCP Program Chair responds to Apache Software Foundation

2002-03-23 Thread Leo Simons

I'll break my no-me-too-posts rule for this occasion:

 Thank you, Thank you, Thank you, Thank you, Thank you, Thank you.
 
 Did I miss anyone?  Great job, guys.  

Definately. Thanks.

- Leo

guess I can deinstall the .net development kit again...for now =)
(and in the line of 'met too's -- I really need JMX opened up!)

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




RE: Jakarta Overview

2002-03-22 Thread Leo Simons

- there's too many committers in jakarta to get 'em all to
  vote on jakarta-site2. Pointless waste of energy, imho.
- committers are responsible people (or they should be,
  at least!)
- as a whole, open source lacks docs. So does Jakarta. For
  those that disagree: look at sensible-documentation-per-
  api-method at msdn.microsoft.com, then look at us.
- many people monitor the site and its changes.

The points above lead me to believe the current (lack of
rigid) system is the right one. And I do think we all agree
that the jakarta site should be as objective as possible.

regards,

- Leo Simons

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




RE: Printable pages

2002-03-21 Thread Leo Simons

 on 3/21/02 12:57 PM, Berin Loritsch [EMAIL PROTECTED] wrote:

  In that case, the entire Jakarta site needs to be redesigned.
  It makes use of embedded tables and font elements.  It does
  not use CSS at all.

 Correct.

I don't know much about anakia, but I know more about xhtml and css
than I do about java (sadly so =). I'll volunteer. I will probably
need help with Anakia, though.

IMHO, a website should be accessible using:

- pentium 200
- 800x600X16bit

- IE 4+
- NS 5+
- Opera 5+
- other standards compliant (or almost) browsers like konqueror

And I mean totally viewable and printable. This is possible while also
being xhtml 1.0 and CSS 1 compliant.

While I'm at it, will I offend anyone if I change some stuff (like the
blue in the subprojects bit on the front page =)? If not, send in a few
feature requests if you want to. Stressing a few.

   We also have issues with older browsers.
  Only versions 5.5 and later will support the Print stylesheet.
 
  IE 5.5+
  Netscape 6
  Mozilla
 
  Anything before that, and you can't count on the stylesheet
  working.

 I'm ok with that.

I'm not. There is no reason for advanced graphical stuff on a site about
programming stuff. Requiring JDK1.3, megs of libraries to download, reading
6 books on programming techniques first, etc, I'm okay with that, but lets
avoid browsers wars!

 Netscape 6 and IE 5.5 are released versions of
 the latest
 technologies. If those new technologies support the features we need, then
 lets require them for those features. It is like the big switch
 from JDK 1.1
 to JDK 1.2. :-)

IMHO, Netscape sucks on the UI part. IE doesn't run on *nix...

Anyway, I'll just shut up and do it...I have no time really but I'll try
and finish somewhere next week. You guys okay with that?

grz,

- Leo Simons


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




RE: Jakarta Overview

2002-03-19 Thread Leo Simons

first, good effort. Thanks.

 I am not deeply familiar with many of the Jakarta projects (in
 particular, I can't quite fathom the full extend of some of the
 frameworks, such as Avalon or Turbine, at this time), but in the
 spirit of 'release-early/release-often' I would like to make the
 information I have compiled so far available to the community.  

 subsection name=Avalon
   !-- purported benefits of Avalon are hard to find out! --

the same as for any framework, mostly.
where it says reusable components, best-of-practice pattern
enforcements, etc, you'll find commercial companies talking about
how it redefines the way you work, allows faster time-to-market,
keep your programmers happy, etc etc.
When .Net was first announced, did you have any idea what it was
about?

   libFramework/b
 !-- No overview or list of features and functionalities --
 
 pThe Avalon framework consists of interfaces that
 define relationships between commonly used application
 components, best-of-practice pattern enforcements, and
 several lightweight convenience implementations of the
 generic components./p

i.e. the main feature is that it does some thinking work for you.
It is easy to write bad software using Java. It becomes
somewhat more difficult if you use Avalon. So, avalon framework
itself has no simple real-life functionality (ie HTTP server).

   libPhoenix/b
 pMinimal Application Server (manages classloader, security 
   and logging needs)/p
 pPurpose somewhat unlear, possibly still starting out./p

phoenix is not an application server in the normal sense. Its a
micro-kernel, which is something different.

 ul
   libDocumentation:nbsp;/bVery sketchy/li

While this is true, I would appreciate it not to list something
like this on the front page. It encourages people not even to
look into the available docs, so to speak. 

   libDocumentation:nbsp;/bExtensive: Several Overview
 documents, HowTos, Javadoc. Apparently no worked
 Hello world example./li

It doesn't make sense to have turbine say hello world when
it includes Velocity, which is there to talk to the world. 

In short, some projects on jakarta are not easy to capture in
'marketing' terms, because they have a possibly very wide scope.
I don't think we should even attempt to do so for projects
still in alpha (ie phoenix).

regards,

- Leo Simons

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




RE: The Complete Server Platform?

2002-02-25 Thread Leo Simons

'kay. Summary:
(everyone, please correct and add to?)

---
SIMILAR EFFORTS
---
Here's a list of similar efforts that I know of...
(requirments:
   1) some kind of application platform
   2) 100% java
   3) open source)

JBoss
-
goal:provide open source J2EE server.
offers:  J2EE compliance, EJB, JMS, O/R-mapping, JNDI,
 JCA, JTA/JTS, JAAS, GUI Management (JMX),
 Servlet/JSP, Database, JDO
license: LGPL
url: http://www.jboss.org
status:  release
notes:   huge developer community

Jahia
-
goal:provide portal solution built on J2EE components.
offers:  JBoss, Database, Servlet/JSP, custom portal
 server (dunno what it does as the installer
 fails on my win2000 box)
license: Jahia License (commercial)
url: http://products.xo3.com:8080/
status:  (preliminary) release
notes:   Paul, seems like a shrink-wrap commercial
 solution to me???

Enhydra
---
goal:provide open source web application server.
offers:  Servlets/JSP, Template Engine (XMLC), Sessions,
 Database connectivity, MVC Framework
license: Enhydra Public License (Mozilla-style)
url: http://www.enhydra.org
status:  release
note:dying slowly it seems, as Lutris is pulling out

EAS
---
goal:provide BSD-style license J2EE server.
offers:  Servlets/JSP, EJB, Avalon
license: BSD-Style
url: http://eas.betaversion.org
status:  alpha
note:been dead a while now as backing company went
 bankrupt.


OPEN ENTERPRISE DISTRIBUTION

goal:provide an open source alternative architecture to
 J2EE.
offers:  Database, Pooling, Logging, Management, etc.
 (to be defined)
license: Apache-style
url: none (will be sourceforge)
status:  conceptual

Candidate Components For Inclusion
--
Jakarta:
Avalon
Struts
Turbine
Velocity
James
Jetspeed
Slide
Tomcat

Apache XML:
Cocoon
SOAP

SourceForge:
Enterprise Object Broker
Simper (soon, anyway)
HSQL
Ozone
JBoss
Maverick
Jetty
Niggle
OpenCMS
Pi
(...the list goes on and on...)

Exolab:
OpenEJB
OpenJMS
OpenORB
Castor
Tyrex

(...)

Clearly, there are loads. We need some criteria.

Architecture

One thing I think OEB needs is formalization of
the patterns of choice in the form of core
interfaces. The two projects I know that deal
with that are Avalon and Turbine.

Another thing it needs is a definition of how it
glues. Options are JNDI, SOAP, JMX, Avalon
Service framework, Turbine Services Framework,
CORBA...and I'm sure I'm missing a few.

Of those, of course _I_ am in favor of the
setup Avalon uses, but hey ;)

This e-mail is now officially more than long
enough.

cheers,

- Leo

-Oorspronkelijk bericht-
Van: Andrus Adamchik [mailto:[EMAIL PROTECTED]]
Verzonden: maandag 25 februari 2002 1:27
Aan: Jakarta General List
Onderwerp: Re: The Complete Server Platform?




Tim Hyde wrote:
 Andrus,

 I'm 100% behind the idea of the complete platform, but I'm worried that
your
 proposal talks about 'Web Applications'.

 I believe that what's needed is an alternative to the very idea that J2EE
 (or even J2SE) is *the* definitive collection of java libraries, and that
 the project should offering a number of sensible alternatives for use in
any
 architecture.

We still will depend on certain commercial JVM's (Sun or IBM), right?



 Database access, Logging, and Development Process are three things that
 you've specifically mentioned that aren't particularly Web or Server
 oriented.

 Web Applications, or Server Applications, are more part of today's
'fashion'
 than inherent categories of how you make a computing solution, and we can
 expect things to move on during the lifetime of Java. Well, we can hope,
 anyway. :-)

You are right. I was mentioning Web applications just cause I wanted to
limit initial scope to something sane. And I guess because I am myself
is a better expert in this area then in any other. This would've helped
to concentrate on a certain solution-based approach from the beginning.
But I agree we can widen the scope as long as we can outline the
problems being solved.


 So, if possible, why not talk about a 'development and deployment platform
 for Java applications' - and then start off by assembling both the
 underlying 'component' toolsets and a number of combination-examples, such
 as the jGuru one Ted mentioned, and whatever else might emerge during the
 project as perhaps 'miniature live examples'.

+1, like I said above, I am for it if we define use cases we are going
after.


 Naturally, server applications are the primary interest point initially,
but
 it would be nice to think that the collection of tools being provided for
 distribution would be offered 

The Complete Server Platform?

2002-02-23 Thread Leo Simons

There has been a lot of talk about what is wrong with the
current main enterprise server platforms, whether it's
about J2EE, .Net or Oracle.

Many of the Jakarta projects provide a (IMHO) superior
alternative to parts of those platforms. Yet Jakarta as a
whole does not provide an alternative to the entire
platform.

I think it would be good if it did.


Why An Integrated Solution Would Be Nice

...should be rather obvious. The advantages are exactly what
makes many companies get a complete solution rather than a
loose set of components tied together.
Imagine:
Welcome to the Jakarta software platform. _click here_ to
download the Jakarta Server Development Kit. It includes all
documentation you need; the documenation is also _available
online_.
Extensions to the base framework include content management
tools, template engines, and implementations of many
important java standards like Servlets and JMX. Browse the
_Jakarta Server Component Library_ to find the applications
you need.


Why It Doesn't Happen

...is also pretty straightforward. Individual developers
work on the various Jakarta projects because they have an
immediate, specific need for the project they're working
on. So that's what they do.
There isn't enough people around devoting energy to
inter-project communication to get an integration project
underway.


What To Do

Besides paying Sam Ruby to become a fulltime communications
manager, there's a few things I think would help
integration.

1) as proposed before, a separate (from general) mailinglist
dedicated to general discussion. Sharing thoughts should
develop into sharing code every so often.

2) a statement of intent in important places on the website.
I'm guessing that putting we would like to see tomcat
integrate with avalon on the projects' respective websites
would mean that such will happen sooner.

3) creation of implementations of Java APIs that increase
interoperability between applications (JMX, JNDI, JMS).
Having a JMX implementation within the Apache fold would
definately ease the tying together of projects.


Why This Rant

I'm trying to state the obvious here. If anything, I'm
curious if anyone has figured out yet where jakarta wants
the balance between total-control-of-direction-from-above
and total-chaos-where-the-only-authority-is-cvs to be.

best regards,

- Leo Simons
(Avalon project)

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




EJB .net = bad . . . so good = ?

2002-02-23 Thread Leo Simons

I have some experience working with:

Oracle 8i
J2EE
Vignette StoryServer
SAP
ASP.NET
Tomcat/Turbine/Velocity
Avalon

all enable the creation of complex server
applications. All have flaws and virtues.

question: what does the perfect enterprise
server framework look like?


let's start with requirements...I guess it...
- has a Database (like AvalonDB -
  http://cvs.apache.org/viewcvs/jakarta-avalon-cornerstone/apps/db/)
- employs MVC (pull MVC -
  http://jakarta.apache.org/turbine/turbine-2/pullmodel.html)
- follows Inversion of Control (
  http://jakarta.apache.org/avalon/framework/inversion-of-control.html)
- is Event-based (like SEDA -
  http://www.cs.berkeley.edu/~mdw/proj/sandstorm/)
- is Component-based(COP/SOP -
  http://jakarta.apache.org/avalon/developing/introduction.html)
- allows hot-(re)deploy (Tomcat Manager -
  http://jakarta.apache.org/tomcat/tomcat-4.0-doc/manager-howto.html)
- is manageable (JMX Impl -

http://cvs.apache.org/viewcvs/jakarta-avalon-phoenix/src/java/org/apache/jmx
/)
- supports transactions (JTA -

http://jakarta.apache.org/slide/javadoc/org/apache/slide/transaction/package
-summary.html)
- has a template engine (Velocity -
  http://jakarta.apache.org/velocity/index.html)
- includes a webserver (Apache -
  http://httpd.apache.org)

Besides that, it needs to be scalable, stable,
portable, secure, etc.

But what architecture does that lead to?

takers?

- Leo Simons


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