Re: [Proposal] HiveMind Service Framework

[Berin Loritsch]

J Aaron Farr wrote:
FYI:

   I think someone wanted this to get forwarded to the Avalon 'general' mailing
list, but since that doesn't exist, I thought I'd send it to our dev list. 

For the Avaloners:

There's been a bit of discussion lately on [EMAIL PROTECTED] about what to do with
Hivemind seeing that it has started to outgrow its current location in
commons-sandbox.  Some have suggested that it fits better over here in Avalon
(as a sub-project) than in Jakarta.  In some respects, I agree.  I think its a
little light to be its own top-level project (hivemind.apache.org) and if you
look at the jakarta charters vs avalon charters, Hivemind falls more on the
Avalon side of things.  Not sure what Howards thoughts are on that.


Hmm.  The thing is if it is "chucked over here", the whole Hivemind approach
will be factored toward the way we are doing things.  We only have so many
developers, and supporting something like this would be kind of a strain on our
resources.
Have the IP issues been sorted out with this package?  There are a whole host
of questions that we would need to sort out, PMC to PMC.  In the interest of
fairness, I think we should seriously talk about that in that capacity.  We
would, of course, include Howard in on the conversation.


--- Danny Angus <[EMAIL PROTECTED]> wrote:



Howard wrote:



3) Chuck it over to Avalon

I've looked to see how we could graft HiveMind into Avalon and vice-versa,
but they are really quite different beasts.  The type-1 > vs. type-2/type-3
split is intrinsic and difficult to reconcile.  HiveMind's concept of a
module doesn't map so easily into the  Avalon space, and HiveMind's
free-for-all approach doesn't jive with Avalon's dogmatic security model
(including its explicit application construction descriptor).
I didn't mean to suggest that you should try to move avalon architecture
towards hivemind or vice versa,
but I did wonder if there would be support @avalon for an alternative
approach as an avalon sub-project.
The danger of having an Avalon alternative @jakarta is that it will be seen
by people as somehow being Jakarta's favoured solution, rather than as one
of two (or more) alternatives promoted by Avalon.
If you see what I mean.
Of course you went through this whole debate when we discussed whether we
needed Tapestry as an alternative to Struts, as equal members of Jakarta
neither approach can be seen to be in any way an "endorsed" or
"favourite". The same (IMO) would not be true for service frameworks if
Hivemind was a Jakarta project not an Avalon one. Hivemind would be seen by
some to be Jakarta's favoured solution.
FWIW I'm certainly not going to oppose this, Hivemind seems to be a well
thought out proposal, but I don't want Jakarta to be accused of trying to
replace Avalon, and I guess that will mean involving Avalon folks in the
discussion.
Imagine the reaction there would be if I proposed a "make" utility as a
Jakarta sub-project, and perhaps you'll get the thrust of my concern.
d.


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


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




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

Re: Differences between Structs and Turbine ???

[Berin Loritsch]

Nick Chalko wrote:
> 
>>-Original Message-
>>From: Rich Persaud [mailto:[EMAIL PROTECTED]]
>>Sent: Tuesday, October 08, 2002 8:26 PM
>>To: Jakarta General List
>>Subject: re[2]: Differences between Structs and Turbine ???
>>
>>Preferred pain is a known pain with an experience-based cap.
>>
>>New and improved pain may promise an average POI 
>>(Pain-on-Investment) that 
>>is 50% of the familiar pain, but will be assigned a risk profile with 
>>unknown maximum pain.
>>
>>If your previous experience confirms that max(NewPain) <= 
>>max(OldPain), 
>>then go ahead and implement NewPain, but make it look like 
>>OldPain.  If 
>>max(NewPain) turns out to be >> max(OldPain), you're on the 
>>hook.  But you 
>>would have first hand experience to make the call, whereas 
>>your boss (and 
>>definitely his boss) would not (or they wouldn't object in the first 
>>place).
>>
>>One successful implementation of NewPain where max(NewPain) <= 
>>max(OldPain), while delivering promised improvements, will 
>>set a precedent. 
>> But someone has to take the risk.  And it won't be people 
>>twice-removed 
>>from the pain.
>>
>>...  in my (painful) experience.
> 
> 
> 
> Here is the short answer.
> Always say "Boss I think this will take a little refactoring of some code.
> I should be able to reuse the most of the code.  
> I will only change what has to changed, and I will make sure that the
> changes are isolated."
> 
> Then do you whatever it takes, including throwing out ALL THE OLD CODE.
> 
> It's your reputation regardless.  You will not be able to say "My manager
> wouldn't let me do it right"
> They will always say "If you knew it was the wrong approach, you should have
> come to me so we can discuss it with your manager.

Sure I can.  They litterally can't afford change--not even the more painful
way.  I started doing it correctly, but I was instructed to stop.  Can
we say "pointy haired boss?"

BTW, I have a reputation in the company for doing a good job of bringing
order out of chaos.  They just wanted to wallow in chaos.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Differences between Structs and Turbine ???

[Berin Loritsch]

Daniel Rall wrote:
> Berin Loritsch <[EMAIL PROTECTED]> writes:
> 
> 
>>Pier Fumagalli wrote:
>>
>>>On 8/10/02 1:30 am, "Jon Scott Stevens" <[EMAIL PROTECTED]> wrote:
>>>
>>
>>>>on 2002/10/7 5:21 PM, "Pier Fumagalli" <[EMAIL PROTECTED]> wrote:
>>>>
>>>>
>>>>
>>>>>JSPs are the "root of all evil" because HTMLers think to have the power (and
>>>>>obligation, after a while) to blatantly destroy your entire container in
>>>>>less than 2 minutes of uptime... To that respect, even ASP are better...
>>>>
>>>>It is so nice to hear you say that finally Pier. =)
>>>
>>>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...
>>
>>Even when Quick and Dirty takes longer.  I tried to convince my boss that
>>a certain "customization" required so many fundamental changes that it would
>>be quicker and easier to develop/maintain if we did it right.  He told me
>>that he would never be able to convince the CEO that was the right choice,
>>so the "Quick and Dirty" route was the choice--taking me twice as long to
>>get it done.
> 
> 
> Depending on the situation, my response to something like that is my
> way or the highway.

Funny, that was the tack that my manager gave me... ;P

BTW, I took the highway and I need a job...  (actually they went broke,
but the result is the same).

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


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

Re: Differences between Structs and Turbine ???

[Berin Loritsch]

Pier Fumagalli wrote:
> On 8/10/02 1:30 am, "Jon Scott Stevens" <[EMAIL PROTECTED]> wrote:
> 
> 
>>on 2002/10/7 5:21 PM, "Pier Fumagalli" <[EMAIL PROTECTED]> wrote:
>>
>>
>>>JSPs are the "root of all evil" because HTMLers think to have the power (and
>>>obligation, after a while) to blatantly destroy your entire container in
>>>less than 2 minutes of uptime... To that respect, even ASP are better...
>>
>>It is so nice to hear you say that finally Pier. =)
> 
> 
> 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...

Even when Quick and Dirty takes longer.  I tried to convince my boss that
a certain "customization" required so many fundamental changes that it would
be quicker and easier to develop/maintain if we did it right.  He told me
that he would never be able to convince the CEO that was the right choice,
so the "Quick and Dirty" route was the choice--taking me twice as long to
get it done.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [IMPORTANT] What actions can the ASF take to enforcecopyright?

[Berin Loritsch]

After finally closing the loop with the person, I found out that the
document was an internal company document "protected" by NDA.

The person who contacted me was a project manager, and discovered
it by someone else's prompting.  I reminded the gentleman that the
source document is protected by the ASL, which generally states that
if you do not change it you can distribute it freely.

I asked him to restore the original "by-line", and he was happy with
that.

There is no public URL to review the stolen bit.  Apparently, it was
a total of 12 pages ripped off (not just a bit), and appended with
a rip off of another document from OSS(?).

> -Original Message-
> From: Pier Fumagalli [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, May 16, 2002 10:12 AM
> To: Jakarta General List
> Cc: 'Avalon Developer's List'
> Subject: Re: [IMPORTANT] What actions can the ASF take to 
> enforcecopyright?
> 
> 
> Berin, do you have any pointer/URL for the "stolen" bits? 
> Both ours and the "illegal" copy... I believe that we can 
> have someone to write  to the offending party and maybe 
> reason with them?
> 
> Pier
> 
> "Berin Loritsch" <[EMAIL PROTECTED]> wrote:
> 
> > I have been informed by someone who felt it was very necessary for 
> > them to act (they called my home, they sent a message to 
> > [EMAIL PROTECTED],
> > etc.) about a straight up violation of copyright and plagerism.
> > 
> > The Jakarta documentation in question is the Avalon docs (I 
> think he 
> > was referring to the "Developing with Avalon" documentation), the 
> > actual specifics I am trying to get from the person.
> > 
> > Basically, He reported that someone grabbed the documentation 
> > verbatim, ripped my name off, and put his own.  The 
> documentation is 
> > specifically released under the ASL 1.1 (modified only to say 
> > documentation instead of software). The documentation has 
> been donated 
> > to the ASF, Jakarta, and specifically Avalon.
> > 
> > From what I know of copyright (I studied it for a week under Al 
> > Schlessinger, the top lawyer in the field), the copyright 
> is only as 
> > good as its enforcement. I personally do not have a problem with 
> > sharing the information, and donating it to the ASF where 
> it is free 
> > to be distributed at will.  I do have a problem when 
> someone without 
> > talent rips off work and passes it off as their own.  To 
> this kind of 
> > person, I can tell them to grow some balls and learn how to 
> write for 
> > themselves.
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:avalon-dev-> [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: [IMPORTANT] What actions can the ASF take to enforce copyright?

[Berin Loritsch]

Further followup with the gentleman showed that the document was
internal to the company he works for.  I let him know that if he
restored the "by-line" for the proper credit, then it was perfectly
fine for him to distribute the document in his company.

> -Original Message-
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, May 16, 2002 9:04 AM
> To: 'Jakarta General List'
> Cc: 'Avalon Developer's List'
> Subject: [IMPORTANT] What actions can the ASF take to enforce 
> copyright?
> 
> 
> I have been informed by someone who felt it was very 
> necessary for them to act (they called my home, they sent a 
> message to [EMAIL PROTECTED],
> etc.) about a straight up violation of copyright and plagerism.
> 
> The Jakarta documentation in question is the Avalon docs (I 
> think he was referring to the "Developing with Avalon" 
> documentation), the actual specifics I am trying to get from 
> the person.
> 
> Basically, He reported that someone grabbed the documentation 
> verbatim, ripped my name off, and put his own.  The 
> documentation is specifically released under the ASL 1.1 
> (modified only to say documentation instead of software). The 
> documentation has been donated to the ASF, Jakarta, and 
> specifically Avalon.
> 
> >From what I know of copyright (I studied it for a week under Al
> Schlessinger,
> the top lawyer in the field), the copyright is only as good 
> as its enforcement. I personally do not have a problem with 
> sharing the information, and donating it to the ASF where it 
> is free to be distributed at will.  I do have a problem when 
> someone without talent rips off work and passes it off as 
> their own.  To this kind of person, I can tell them to grow 
> some balls and learn how to write for themselves.
> 
> --
> 
> "They that give up essential liberty to obtain a little 
> temporary safety  deserve neither liberty nor safety."
> - Benjamin Franklin
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:general-> [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]>

[IMPORTANT] What actions can the ASF take to enforce copyright?

[Berin Loritsch]

I have been informed by someone who felt it was very necessary for them
to
act (they called my home, they sent a message to
[EMAIL PROTECTED],
etc.) about a straight up violation of copyright and plagerism.

The Jakarta documentation in question is the Avalon docs (I think he was
referring to the "Developing with Avalon" documentation), the actual
specifics
I am trying to get from the person.

Basically, He reported that someone grabbed the documentation verbatim,
ripped
my name off, and put his own.  The documentation is specifically
released under
the ASL 1.1 (modified only to say documentation instead of software).
The
documentation has been donated to the ASF, Jakarta, and specifically
Avalon.

>From what I know of copyright (I studied it for a week under Al
Schlessinger,
the top lawyer in the field), the copyright is only as good as its
enforcement.
I personally do not have a problem with sharing the information, and
donating
it to the ASF where it is free to be distributed at will.  I do have a
problem
when someone without talent rips off work and passes it off as their
own.  To
this kind of person, I can tell them to grow some balls and learn how to
write
for themselves.

--

"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
- Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Scarab (was RE: [ANN] in-house mail archive...)

[Berin Loritsch]

Andrew C. Oliver wrote:
> Dude... is that available to other projects?  Secondly, are there any 
> bugs stored in it?  I tried to run a few queries to try it out and got 
> no results.  I'd love to try scarab and might convince POI to use it. 
> But I'd rather kinda start sooner rather than later because once we have 
> a lot of open RFE's and bugs it could hurt to switch. 
> So far I like what I see.  I just want to take it out for a spin...  Can 
> you maybe give me a couple hints on some queries to run? 
> Thanks,
> 

Andy,

I am loving Scarab too.  I have a copy installed on my laptop (along
with MySQL and Tomcat).  It's administration is clean, the app is well
documented and user friendly.

Last time I inquired about it, Jason Van Zyl said that it was a testing
area.  By virtue of the fact that it is running on port 8080, it is not
meant to be supported for primetime yet.

However, he did seem accommodating about adding a module for a
jakarta project.  Just ask.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Maven is growing

[Berin Loritsch]

Jon Scott Stevens wrote:
> on 5/3/02 10:37 AM, "Berin Loritsch" <[EMAIL PROTECTED]> wrote:
> 
> 
>>Jon Scott Stevens wrote:
>>
>>>on 5/3/02 10:19 AM, "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>
>>>>http://sourceforge.net/project/stats/?group_id=36516
>>>
>>>
>>>50 cvs actions over the life of the project?
>>>
>>>OooAhh
>>
>>And who is the hypocrite this time?
>>
>>From a previous post of yours (copy and pasted):
>>
>>
>>I listen to the following:
>>
>>   Code.
>>   Patches.
> 
> 
> ?. I think I made myself pretty clear.
> 

I see, shorten your list, ignore your negatives--just so you can
escape your own double-talk.  I see how you play the game :)

Seriously Jon, I put my money where my mouth is.  YOu can ask
anyone that knows me.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


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

Re: Maven is growing

[Berin Loritsch]

Jon Scott Stevens wrote:
> on 5/3/02 10:19 AM, "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:
> 
> 
>>http://sourceforge.net/project/stats/?group_id=36516
> 
> 
> 50 cvs actions over the life of the project?
> 
> OooAhh

And who is the hypocrite this time?

 From a previous post of yours (copy and pasted):


I listen to the following:

 Code.
 Patches.
 Real suggestions for improvement.
 Intelligent discussion.

I don't listen to the following:

 Flame wars about technologies used.
 Whiny people who can't learn a new technology.
 Whiny people who only use 'standards'.
 People who are clearly without a clue.
 Hypocrites.


So you can't stand to learn a new technology, huh?
You can't be bothered to try to improve things, huh?

I think this is a case of the pot calling the kettle black.
Careful what you say, it will bite you later.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Maven is growing

[Berin Loritsch]

Jon Scott Stevens wrote:
> Nice to see people who are upset about Maven actually recognizing that it is
> pretty cool and can be made better (have to start somewhere, right?).
> 
> Berin posted this:
> 
> 
>>Despite my comments on General@, I really like what maven offers.  There
>>are some things that I would like to have in Maven or Centipede, so I
>>guess the best thing is to lend a hand.  I have limited time, so I will
>>start with participating on the dev list.  If I can manage code patches
>>I will send them here.
> 
> 
> Sam is also on the list and participating.
> 
> :-)

Remember, I participate as long as I feel welcome.  If I don't feel
welcome, I move one.

Both projects have alot to offer.  Are you on the Centipede list?
You might find something to learn there as well.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Database Subproject Discussion : creation of DBCommons ?

[Berin Loritsch]

Geir Magnusson Jr. wrote:
> I hate to interrupt all the good fun over standards, bike sheds, and general
> good community feelings,  but I would like to solicit community opinion on
> something unrelated to DVSL or Jon Stevens (both of which I like, btw...)

You're taking away all the fun :)

> 
> Recently, it was proposed that ObjectBridge be brought to Jakarta as a
> subproject.
> 
> Costin suggested, and I supported, that a subproject of wider scope be
> created to allow the collection of similar technologies into one larger
> subcommunity (that isn't an exact quote, but I think he'll agree in general
> with that.)  
> 
> The idea would be to bring in ObjectBridge, but create a Commons-like
> environment in which other projects can be brought.   Call it DB-Commons as
> a working name.

Ok.

> 
> There are some good reasons, including community alignment, inter-project
> synergy (there, I used the word in an Apache-related post), and ease of
> discovery for new users and developers.

:)

> 
> Off the top of my head, in Jakarta we have lots of db related tools already
> (Torque, commons-dbcp, and I am sure others...), and having a db-focused
> subproject in which they can be brought to with a lower barrier than
> 'fullsubproject' might be very benficial.
> 
> We already have the successful Commons model to use as a starting point.
> 
> Anyone have any comments?
> 

Can we have Avalon related components in DB commons?  Avalon has the
DataSourceComponent interface and associated implementations.  There are
some things we have in Excalibur that we *can't* donate to Commons
because the charter does not allow it (I think its something about the
project can't rely on non-commons projects or something).

It only makes sense to have a focused commons-like area.  This would
make the third one.  Excalibur is (at least now) a commons-like area
focused on Avalon, Jakarta Commons is multipurposed, and this would
be fine.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: You guys are so funny.

[Berin Loritsch]

Craig R. McClanahan wrote:
> 
> It seems to me that authors of a build environment that they want
> "everyone" to use would think about going and asking the potential users
> (i.e. committers on various other projects) what their requirements are,
> before any attempt (by those authors, or by anyone else as was the case
> that started this particular flamefest) to shove it down everyone's
> throats.

Which gets back to one of my first points.

General build improvement issues should be discussed on General so that
we know what we want.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: You guys are so funny.

[Berin Loritsch]

[EMAIL PROTECTED] wrote:
> Berin Loritsch says:
> 
>>There are other dirty underhanded things that M$ did to get where it
>>is today.  Don't try to compare us to M$.  We're not M$.
> 
> 
> 
> Whenever someone tells me how much MSFT has done for technology, I
> can't help but think of how far we might have gotten if MSFT hadn't
> been so in the way all these years!


:)  We'd probably be running UNIX on our desktops with a standard
and friendly GUI.



-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


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

Re: You guys are so funny.

[Berin Loritsch]

Michael McCallum wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 
>>I do that because I believe standards are essential - even if
>>'simpler' pet-solutions exist. Standards are the only way to
>>get people to work togheter -  and DocBook, HTML, XSLT are
>>the standards.
>>
> 
> Microsoft did not get where it was by using standards. It created things which were 
>easy for people to use
> and they became the de facto standards.

Grmble grmble grmble.

Microsoft got where it is based on the shear might of its marketing
prowess.  It made it easier than Mac to develop, so more developers
created solutions for it.  I've seen Java tools beat out M$ tools
for the same job.

You can't claim microsoft has legitimately better technology if they
haven't worked with it.  I've worked with it, and to say I dislike it
would be an understatement.  MFC is the work of a raving mad mob of
developers rushing to get product out the door.  It combines both
OOD and procedural mindsets within the same API.

Microsoft is *not* easy to develop.  It's easier than Macintosh
(at least during the critical time frame when Mac could have done
better).  Easy to use means that several apes pounding on keyboards
produced something that a user liked somewhere.

There are other dirty underhanded things that M$ did to get where it
is today.  Don't try to compare us to M$.  We're not M$.

> 
> Tools that solve problems tend to be much more pratical than standards.
> 

And standards solve problems tend to be doubly more practical.
Standards allow you to communicate more freely, because everyone
speaks the same language.  There is no impedence mismatch because
I say To-mah-to and you say To-may-to.  There is no misunderstanding
because I call a toilet a jon and you call it a lavatory.  That is
what standards are about.  No more wasted energy trying to explain
what we mean by a piece of code.  Its a standard.


My 2c


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: You guys are so funny.

[Berin Loritsch]

Kurt Schrader wrote:
> On Thu, 2 May 2002, Berin Loritsch wrote:
> 
> 
>>There are things to like with both projects.  However you do ignore some
>>things that are important.  GUMP integration is important--I like the
>>fact that Centipede works out of the box with it.
> 
> 
> Just to clear this up, "ant maven:gump-descriptor" will generate a Gump
> project descriptor for a Mavenized project.

WIth certain limitations.  Where is the Nag entries, etc.?

It's getting better, but the fact remains that the gump descriptor is
generated--not extended.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


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

Re: You guys are so funny.

[Berin Loritsch]

Jon Scott Stevens wrote:
> on 5/2/02 8:44 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> 
> 
>>Same here, I'll -1 a switch to either maven or centipede on the projects I
>>have a vote on until they find a way to work togheter.
>>
>>DVSL may be a nice language, but XSLT is the standard - regardless of how
>>you play with the word. I'm fine with a tool that supports both.
>>
>>Costin
> 
> 
> You guys are so funny.
> 
> 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.
> 
> On top of it, in *years*, no one has gone and replaced Jakarta-site2 with
> anything better. Sure, Craig did a XSLT stylesheet, but no one changed the
> main Jakarta site to use it and I still see new Anakia sites on
> Sourceforget.net all the time.
> 
> The next thing to replace jakarta-site2 will be Maven. Just like with
> Anakia, I honestly don't care if you -1 it. You aren't doing the work and
> therefore your argument against it is simply a bike shed and is thus not
> valid in my opinion.
> 
> Costin, just like with Tomcat 3 vs. Tomcat 4. We all learned that you can't
> force projects to work together. Nor can you vote -1 on it. Given our
> history, I'm really surprised to hear you trying to argue for something like
> that. You hypocrite.


Finally.  Jon, I knew you could do it.  You wrote your first intelligent
post in this whole thread!

;P

There are things to like with both projects.  However you do ignore some
things that are important.  GUMP integration is important--I like the
fact that Centipede works out of the box with it.  I honestly don't like
the Maven look--but the feel is ok.  The problem is that Maven does not
make it easy to change either the look or the feel.  It takes more
effort than should be required for a _build_ tool.  The types of docs
that it generates are fantastic.  They are very useful.

I personally lean toward Centipede because it uses more of *my* pet
projects :)  And there lies the rub.  I personally would like to see
where some projects use Maven and some use Centipede.  Either way,
I want them to be compatible with GUMP.

> 
> Learning Technology
> ---
> 
> The argument about learning minor technologies to make money is so silly it
> is funny. I have owned/started several companies now and have been
> responsible for hiring or directly approving the hiring of about 50-60
> people over the last 10 years. Not a huge amount, but not small either.
> 
> Never once did I think to myself, hmmm...that person knows minor technology
> X better than minor technology Y. What I cared the most about was that the
> person had a general good skill set and the aptitude to learn something new.
> So, if learning DVSL vs. XSLT is beyond your aptitude, I probably would not
> have hired you anyway.
> 

And who said it was beyond our aptitude.  All anybody said is that it
was beyond our desire.  If we have a tool that works for us, and it
garners more and more _tool_ support--we will use it.  It's what makes
for the project.  Yes money is not the key motivator, and anyone who
thinks it is should be shot, but if we need to find a new employer--
we will have a better time if we know XSLT as opposed to DVSL.

So sometimes decisions to use a product or project is completely out
of your control.  Nevertheless, I maintain that I can wrap my head
around anything in under two weeks (two weeks being for very complex
projects).  That's if I need to.  I personally balance involvement
in four projects (2 on XML.apache and 2 on Jakarta), a personal
life, a professional life, and hobbies.  The less I have to learn
for a build the better.  If I need to update the look and feel of
a site to brand a project for my own purposes--I don't want to waste
two weeks figuring it out.  I want to use what I already know so
I can just do it.

Its as simple and pragmatic as that.

> On top of it, the mentality of having to fit into the box because everyone
> else is doing it would make me instantly not like your personality. I like
> people who are free thinkers and who can think outside of the box. Software
> is an art form, not something that you can just cookie cutter produce (and
> have it come out being any good). IMHO, it is the free thinkers that have
> the most creative and bug free code. Thinking outside of the box shows that
> you care about the code and systems you are creating.
> 

And yet, you insist that all free thinkers think like you.  Not all free
thinkers fit in your box (sometimes it is a little confining ;P ).

> 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!
> 

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

[Berin Loritsch]

Jon Scott Stevens wrote:
> on 5/1/02 11:58 PM, "Steven Noels" <[EMAIL PROTECTED]> wrote:
> 
> 
>>Which basically boils down to "let's just invent our own little language
>>and try to get enough people bragging about it"
> 
> 
> It isn't a little language... It is Velocity templates using a well
> known/used API (DOM4J).

Language != technology.

DOM4J is technology.  THe DVSL markup is language.  It just so happens
that you use DOM4J in the parts where you change things--but DVSL is
where you mark what you change and when.



> Just like there are more JSP users than Velocity users.
> 
> Still doesn't mean that JSP is better than Velocity.

And it doesn't mean that Velocity is better than JSP.  I personally am
not a JSP fan, but different tools for different fools.  Quit comparing
apples and oranges.  Let's get back to your thought provoking posts.

> 
> 
> Using technology that is well supported, developed by a community of people
> who are not motivated by commercial or academic interests (instead, motived
> by real world requirements).
> 
> Heck, I bet you haven't even tried DVSL, so don't knock it until you try it.
> 

I haven't had a need to.  If I can do everything I need outside of DVSL,
using standard technologies that can be used in other settings, what
incentive do I have?  Besides Xalan is an Apache project, as is Xerces.
We use them.  So how is that *not* using a technology that is *well*
supported.

As to your assertation that commercial or academic interests are not
valid motivations, you forget that they *are* real world requirements.
In fact I would assert that development efforts not originated in some
way by commercial or academic needs are efforts that are done for the
sake of doing them.

We have to eat.  I eat because I program.  I use Apache products because
they are better than many commercial products for the same purpose, and
because I can convince my managers that we can build our solutions with
them.

But I degress...


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[Berin Loritsch]

Jon Scott Stevens wrote:
> on 5/2/02 2:54 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> 
> 
>>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. Any 'coming together' is going to be a very difficult decision to get
>>past the maven developer community, because they have a tool that works and
>>is going in a consistent direction from a design perspective, and that
>>coming together will result in much slowing of progress. I don't think,
>>IMHO, either tool is mature enough at this point to merge.
> 
> 
> I can agree with that. Hell, the dvsl vs. xsl is a showstopper for me.
> 
> I can't stand XSL...


And I can't be bothered with non-standard transformation languages...

Centipede uses Cocoon, which allows you to use Velocity, or whatever you
want to transform your documents.  You aren't locked into XSL if you
don't want.  THat's the beauty of it.  WIth Maven, you are locked into
DVSL, and there is no other way of doing things. :/

But again, Reality Check: how often do you mess with the look and feel
of a site?  If the theme exists--use it.  It's that simple.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: GUMP RULEZ WAS: Re: Quick! convert all your projects to maven!

[Berin Loritsch]

[EMAIL PROTECTED] wrote:
> Berin Writes:
> 
> 
> 
>>Forrest was started and talked about publicly on the general@xml
>>list before it was even started.  That is something that somewhat
>>perturbs me about the Turbine projects.  SOmething with Maven's
>>scope and ability should have been talked about publicly instead of
>>sneaking up on us.  When we get the message "convert all your
>>projects...", that would definitely catch alot of people off guard.
> 
> Well, given I don't subscribe to general@xml, Forrest was COMPLETELY 
> unknown to me. Maven was publicly discussed in the turbine-dev & 
> turbine-user lists. So from my perspective: What's Forrest :)

Of course missing the point completely.

The Forrest project was discussed on the GENERAL list for the main
project it belongs to (i.e. [EMAIL PROTECTED]).  Therefore,
for all people you are interested and support the XML.apache.org
project--they were included.

Such is not the case with Maven.  It was discussed in the Turbine
lists--not [EMAIL PROTECTED]  Therefore not everyone who
supports or are interested in JAKARTA.apache.org project knew about
Maven.

That is the key distinction.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: GUMP RULEZ WAS: Re: Quick! convert all your projects to maven!

[Berin Loritsch]

Andrew C. Oliver wrote:
>>
>> Translation:
>>
>> Jakarta = jakarta.apache.org
>> XML = xml.apache.org
>>
>> And the reason on XML.apache.org there is no discussion is:
>> everyone seems to be on board with Forrest--which is using Centipede.
>>
>>
> 
> Yeah so why can't these work together?  I still just don't get it.  "Gee 
> we don't like that lets do our own thing or integrate with anything but 
> this or that".  It just baffles the crap out of me. 
> If I had the choice.  I'd use NEITHER.  I choose Centaven WITH GUMP.


Fine.  The history is that Forrest was in motion before I even knew
there was such a thing as Maven.  I know the folks involved with
Forrest, and they are top notch people.  The whole purpose of Forrest
is to work with GUMP.  (Notice the synergy: Forrest Gump).

Forrest was started and talked about publicly on the general@xml
list before it was even started.  That is something that somewhat
perturbs me about the Turbine projects.  SOmething with Maven's
scope and ability should have been talked about publicly instead of
sneaking up on us.  When we get the message "convert all your
projects...", that would definitely catch alot of people off guard.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: GUMP RULEZ WAS: Re: Quick! convert all your projects to maven!

[Berin Loritsch]

Steven Noels wrote:
> Berin,
> 
> 
>>How does that match up with the NIH attitude towards Krysalis?
>>
>>I wasn't aware of a Jakarta/XML project named cruise control.?
> 
>  
> 
> Hey, this is a [EMAIL PROTECTED] discussion. For some strange
> and perhaps slightly biased reason, I'm not too surprised threads like
> these don't exist across the wall in [EMAIL PROTECTED] country.
> 
> One wonders... testosteron?
> 
> 
> 
> (ducking away, asbesto suit on)
> 


Translation:

Jakarta = jakarta.apache.org
XML = xml.apache.org

And the reason on XML.apache.org there is no discussion is:
everyone seems to be on board with Forrest--which is using Centipede.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Reality Check (was Re: Quick! convert all your projects to maven!)

[Berin Loritsch]

There have been alot of talk back and forth about Maven, Krysalis
Centipede, GUMP, ANT, etc., and we are all missing some basic
points.

1) GUMP is a continuous integration tool.  It is not meant to be
more than that.  I find it an invaluable tool, and the information
it gives me is necessary.

2) ANT is a build tool.  It does its job, but little more.  It is like
the "make" command on UNIX boxes.  In the right hands, it is both
powerful and dangerous at the same time.  You can really do something
right, or you can really screw something up.

3) Maven and Centipede are "competing" equivalents.  Neither are
to the point where ANT is yet.  Both Jason Van Zyl and Nikola Ken
Barozzi are great guys, and are very accommodating.  Both projects
have issues to work out.  Jason and Nikola both recognize that.
I have suggested improvements to Maven, and Jason has been open
to them.  I have not tried Centipede yet, but Nikola personally
offered to help with integrating it on a project.

4) Bottom line is we need something at the Maven/Centipede level.  We
can really use an automated build that is plug and play for a new
project.  However, we need soemthing that can deal with subprojects
and Commons-like arrangements.  Last time I checked Maven/Centipede
weren't there yet--but had it in their plans to support something
like that.

I appreciate the enthusiasm of the original post, but I think it is
a little premature.  Anything more than that is mudslinging, and FUD,
and trying to correct misrepresentations.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: GUMP RULEZ WAS: Re: Quick! convert all your projects to maven!

[Berin Loritsch]

James Taylor wrote:
> 
> 
> Yes! All of us over in maven land are big fans of continuous
> integration. We were in discussion with the cruise control folks about
> working together, and are planning on integrating the best features from
> it into maven so that any project with a descriptor can immediately be
> set of for continuous integration (since maven supports version control
> and unit/integration tests out of the box, this is going to be quite
> easy (and fun!) to implement.


How does that match up with the NIH attitude towards Krysalis?

I wasn't aware of a Jakarta/XML project named cruise control.?



-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: jakarta subproject scope (was Re: Quick! convert all your projectsto maven!)

[Berin Loritsch]

John McNally wrote:
> On Tue, 2002-04-30 at 20:38, Geir Magnusson Jr. wrote:
> 
>>On 4/30/02 11:31 PM, "John McNally" <[EMAIL PROTECTED]> wrote:
>>
>>
>>>I do not know where to locate Turbine's original charter and I think it
>>>is a good idea to try to follow it.  Are these published somewhere or
>>>should Turbine maintain it in its own documentation?  However the scope
>>>of a subproject is likely to grow/evolve over time.  Velocity does
>>>provide at least one servlet that allows it to be used to develop a
>>>webapp independent of any other framework.
>>
>>I think that's stretching 'webapp'  I guess tomcat does the same thing as it
>>supplies servlets...  :)
> 
> 
> Well I would not be bothered if tomcat had developed a build system that
> it packaged as an independent entity with the idea that it might be more
> generally useful. Tomcat is a large project and they certainly could
> have had the itch. And if they promoted it occasionally what's the big
> deal. 


Where do you think we got ANT from?  That started with Tomcat as a
subproject and then became its own project.



-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Quick! convert all your projects to maven!

[Berin Loritsch]

Jon Scott Stevens wrote:
> on 4/30/02 5:31 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
> 
> 
>>I have yet to be able to build Maven.
>>
>>- Sam Ruby
> 
> 
> echo "maven.home=${user.home}/maven" >> ~/build.properties

That's an extra step that we don't need.  See if you can
build without it.



-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: FW:

[Berin Loritsch]

Look at JEdit.  I don't know how integrated everything is, but I
think they may have one

> -Original Message-
> From: Andrus Adamchik [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, April 04, 2002 2:24 PM
> To: Jakarta General List
> Subject: Re: FW:
> 
> 
> I don't know of this particular case, but this raises is an 
> interesting 
> point. When doing XML publishing with Anakia (using vi to 
> type the text 
> :-)), typos are unavoidable.
> 
> I wonder if there are any Java spellcheckers out there that have 
> acceptable licensing terms. Such a spellchecker could be 
> integrated with 
> Anakia, to generate spelling warnings during the build. This 
> could be a 
> very nice enhancement.
> 
> -- 
> ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
> - Andrei (a.k.a. Andrus) Adamchik
> Home of Cayenne - O/R Persistence Framework 
> http://objectstyle.org/cayenne/
> email: andrus-jk at 
> objectstyle dot org
> 
> 
> 
> Pier Fumagalli wrote:
> > Not acknowledged
> > 
> > Pier
> > 
> > -- Forwarded Message
> > From: "Maher, Dan" <[EMAIL PROTECTED]>
> > Date: Thu, 4 Apr 2002 11:16:32 -0600
> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> > 
> > 
> > hate to nitpick, but a misspelling on the Jakarta site might in a 
> > small way, affect its adoption. This is from the Jetspeed page:
> > 
> > "The term "Portal" was created that described a Web 
> Application that 
> > was designed to present a ton of information in a consise 
> and centered 
> > way"
> > 
> > Concise, not consise
> > 
> > 
> > 
> > 
> >>Daniel Maher
> >>Software Engineer - Sprint PCS/IT
> >>Application Development Solution Center - Nashville TN 615-341-7814 
> >>(Voice) 615-341-7684 (Fax)
> >>[EMAIL PROTECTED]
> 
> 
> --
> To unsubscribe, e-mail:   
> 
> For 
> additional commands, e-mail: 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: subproject layout conventions

[Berin Loritsch]

> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] 
> 
> On 3/29/02 8:26 AM, "Berin Loritsch" <[EMAIL PROTECTED]> wrote:
> 
> >> -Original Message-
> >> From: Pier Fumagalli [mailto:[EMAIL PROTECTED]]
> >> 
> >> "Berin Loritsch" <[EMAIL PROTECTED]> wrote:
> >> 
> >>> Attached is a small screenshot of the maven page with a
> >> white header.
> >> 
> >> Aaah WINXPCRAP! :)
> > 
> > Whatever hater ;P
> > 
> > It pays the bills, ya know what I mean?
> > 
> 
> So do my Mac's running OS X. (OS < X is another story...)  
> It's java!  Come to the light!
> 
> ;->

I said it pays the bills, I didn't say it was the best...

Besides, MS Word is not Java--and it costs too much not to have
it bundled with a new machine.  (I looked at Mac laptops, really).


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

RE: subproject layout conventions

[Berin Loritsch]

> -Original Message-
> From: Pier Fumagalli [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, March 28, 2002 5:12 PM
> To: Jakarta General List
> Subject: Re: subproject layout conventions
> 
> 
> "Berin Loritsch" <[EMAIL PROTECTED]> wrote:
> 
> > Attached is a small screenshot of the maven page with a 
> white header.
> 
> Aaah WINXPCRAP! :)

Whatever hater ;P

It pays the bills, ya know what I mean?


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

RE: subproject layout conventions

[Berin Loritsch]

> -Original Message-
> From: Leo Simons [mailto:[EMAIL PROTECTED]] 
> 
> > > - color variations (and all other l&f 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.

I a GIMPer myself...


> >  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?

As long as the original bitmap supports alpha blending, all
is well (i.e. PNG).  It's text you have to worry about


> > 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).

We can fiddle with the design until we have something we like.

> 
> > > - 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.

When you have a group of related sub-projects, it is very
much warranted.  The maven layout kicks butt to display all
sub project info, and allow you to jump from one sub-project
to another easily.

I don't think we will be going that much deeper than what
you see in maven... But at that point it is really beyond
the scope of Jakarta guidelines.

> 
> (...)
> 
> > 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".

?!? Section headers currently match the main header color.  So if
the main header color becomes black on white, the section headers
become black on white.  The result is subdued if anything.

> 
> > 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? :)
> 

Oh, yeah (I own it)

"I've come to peck a fight"


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: subproject layout conventions

[Berin Loritsch]

> -Original Message-
> From: Leo Simons [mailto:[EMAIL PROTECTED]] 
> 
> another lenghty post, so I'll start with a summary:
> 
> - color variations (and all other l&f 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.  With
projects like Batik, we can generate images that fit
with any background color.

Let me say this plainly: color should be flexible to a
point.  The background color for the main text area
must be white and the main text color should be black.
The color customization whould be in the project header.

> - 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.

> 
> here's the elaboration:
> 
> Look and Feel
> -
> (replying to:
> > > 2) Project color-scheme
> >
> > No problem :-)
> )
> 
> IMHO, look and feel variations should be designed into the 
> template by the original designer, then set in stone. When 
> you say flexible with color, I find that scary. When its "the 
> background color of a locations also containing images", 
> that's a lot of work as well (ie the blue bar on the maven
> site) as we work with anti-aliased images which you need
> to duplicate for each color change.
> I know a bit about this as I was on the team that had to
> tackle this for www.planet.nl. Rather than having some 
> programmers talk about this, I'd much rather have the 
> original designer propose exactly what parts of the layout 
> can change to what colors.

And I have designed several web applications, and also am
well versed in site design and color customization.  I even
created a demo site to generate logos and other images on the
fly--even when the background was a different color.

Anti-aliased images won't really be a problem.

> 
> I hope I don't offend anyone too much when I state that, 
> generally speaking, programmers (and other technical people) 
> are really bad at designing intuitive interfaces. Jakarta is 
> no exception.

But they like simple color schemes--which is what I would want.
Many sites include a customized color depending on what major
part of the site you are visiting (my.yahoo.com, mail.yahoo.com,
etc.)

> 
> Navigation structure
> 
> I proposed a breadcrumb trail in my earlier post.

Those work well, but keep in mind that we need to make all
peers available as well.

> 
> Berin:
> > > The question then becomes how do we make Maven's 
> organization expand 
> > > to Jakarta-site3?  One thing that we must understand is that 
> > > sub-projects can have sub-projects.  Jakarta Commons, Jakarta 
> > > Sandbox, Avalon Excalibur, and Avalon Apps all attest to that.
> 
> Jason:
> > You can look at the Turbine layout sites for an example of 
> what we've 
> > done.
> 
> Berin:
> > > I see the line with the sub-projects able to be two lines 
> tall. The 
> > > first line would be the parent level, and the second line 
> would be 
> > > the current line.
> 
> I like a breadcrumb trail better. My last post was a bit 
> abstract in explaining, so I'll try an example now...
> 
> 
> Imagine you're at 
> http://jakarta.apache.org/avalon/applications/avalon-db/client
> /gui/userguide
> /introduction.html
> (which might very well exist in the near feature)
> 
> Using a breadcrumb trail, you'd have
> 
> apache.org > jakarta > avalon > applications > avalon-db > 
> client > gui >
> userguide:
>   -== INTRODUCTION ==-
> 
> in addition to maybe a menu like this:
> 
> Avalon Client
>   - overview
>   - getting started
>   - download
>   - install
>   - ...
> 
> GUI User Guide
>   - introduction
>   - the menubar
>   - the db browser
>   - running queries
>   - ...
> 
> Commandline User Guide
>   - introduction
>   - getting started
>   - command reference
>   - BeanShell integration
>   - ...
> 
> ...
> 
> The setup Maven currently provide would have
> the Jakarta logo, the avalon logo, followed
> by a list of avalon-db sub projects in the
> horizontal bar, and the same menu on the left.
> Using an extra horizontal bar would add a
> list of avalon-apps sub projects. You would
> really need at least _another_ horizontal bar.
> See the problem?

What's wrong with both the breadcrumb trail and the
sub-projects bar?

I.e.

jakarta.apache.org > avalon > excalibur
CLI Collection Command Concurrent 

And the right hand navigation like on the maven site?

Honestly, the breadcrumb alone 

RE: subproject layout conventions

[Berin Loritsch]

> -Original Message-
> From: Glenn A. McAllister [mailto:[EMAIL PROTECTED]] 
> 
> On Thu, 28 Mar 2002, Berin Loritsch wrote:
> 
> > Everything should definitely feel the same.  However, color is a 
> > definite clue that you have changed contexts.  By drilling down a 
> > Project's heirarchy, it helps to have a visual clue that 
> you are not 
> > at the same level you used to be.
> > 
> > Color customization is not just a cosmetic tool, it does help to 
> > understand a project's hierarchy.  Logo changes can be 
> missed, but a 
> > different background or header color is hard to ignore.
> 
> Unfortunately, you can't depend solely on colour to 
> communicate an important piece of information.  If all 
> subprojects have a blue background and all subsubproject have 
> a purple background and thats the only 
> indication of the project level, anyone who is red-green 
> colour blind is 
> hosed.  Anyone who is completely colour blind is obviously hosed.

Agreed.  That is why the the the logo changes as well.  The
color change is just an additional cue to the non-colorblind.


> I don't disagree that colour is a very useful tool, just 
> don't depend on it.  You need an additional way of indicating 
> what the current project depth is.
> 
> And no, I'm not colour blind. :-)

Contrast is just as important.  A better analogy would be if
we alternated light and dark.  Now, if the light color was lt. red
or yellow, it doesn't really matter to the colorblind.  The next
level down would become dark again.

But that choice should be left to the sub projects to decide their
color schemes.  It is an easy change to support, and it communicates
enough information without becoming a crutch.


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

RE: subproject layout conventions

[Berin Loritsch]

> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]] 
> 
> On Thu, 2002-03-28 at 09:05, Berin Loritsch wrote:
> > I would definitely like to see a Maven like system across 
> the projects 
> > in Jakarta--even if the main site is not altered much. It would be 
> > good to give the freedom to the sub-projects to refine their color 
> > choices, but the general layout and site organization should be the 
> > same.
> 
> We had this discussion the other day and I tend to be 
> somewhat forceful in my idea that the organization and 
> presentation of the information is crucial in helping someone 
> to easily understand a project and that it's important that 
> all projects look identical insofar as the develop 
> documentation is concerned. Colors maybe, but I would like if 
> that once someone had become familiar with the layout of a 
> maven project then learning another project becomes a matter 
> of custom.

The only thing I would want to customize are:

1) Project Logo
2) Project color-scheme

That's it.  I really don't think that is too much to ask.  The
layout should remain constant without a doubt.


> I'm not trying to stifle anyone's creative urges, I just feel 
> that in the matter of project comprehension that it is 
> pragmatic to have everything look the same. Some don't agree 
> with me but what I'm really trying to avoid is the infinite 
> configuration quagmire where everyone adds things to make 
> things look the way they like and thus you loose all cross 
> project cohesion.

Everything should definitely feel the same.  However, color is
a definite clue that you have changed contexts.  By drilling
down a Project's heirarchy, it helps to have a visual clue that
you are not at the same level you used to be.

Color customization is not just a cosmetic tool, it does help
to understand a project's hierarchy.  Logo changes can be missed,
but a different background or header color is hard to ignore.

As a side note, it would be cool if we could include the Jakarta
and project logos as a header in the printed documentation, but
that is a stylesheet change.

> 
> > I just wish I new about Maven a lot earlier--it delivers on 
> a lot of 
> > promises, and in my book that's golden.
> 
> It's been in the works for a long time but really it's only 
> been in the last 3-4 weeks that others have worked on it and 
> it's taken off primarily because of the interest people have 
> in making their develop lives easier. There is definitely an 
> interest there because people would rather focus on their 
> apps then fart around trying to get a build system to work 
> and have it produce useful information.

Absolutely.


So what did you think about the two line navigation approach for
Jakarta Site?

> > I see the line with the sub-projects able to be two lines tall. The 
> > first line would be the parent level, and the second line 
> would be the 
> > current line.  That way we can have something like this at the root 
> > level:
> > 
> >   Alexandria Avalon BCEL ...
> > 
> > And at the sub-project level, we would be able to have 
> something like 
> > this:
> > 
> > Jakarta|  Theory Framework LogKit *Excalibur* Cornerstone 
> Phoenix Apps
> >   CLI Collections Concurrent 
> > 
> > That way we can easily navigate the site, and drill down quickly to 
> > the actual information we need.
> >   
> > 
> > 
> 
> > --
> > To unsubscribe, e-mail:   
> <mailto:general-> [EMAIL PROTECTED]>
> > For 
> additional commands, 
> e-mail: 
> > <mailto:[EMAIL PROTECTED]>
> -- 
> jvz.
> 
> Jason van Zyl
> [EMAIL PROTECTED]
> 
http://tambora.zenplex.org


--
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: Printable pages

[Berin Loritsch]

> -Original Message-
> From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, March 21, 2002 4:07 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Printable pages
> 
> 
> 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  elements.  It does not use CSS at 
> > all.
> 
> Correct. 
> 
> My long time goal has been to convert the Jakarta site over 
> to use Scarab's stylesheets since it has been created by a 
> CSS expert (who works for
> CollabNet) and it also looks better visually...it works 
> extremely well in all browsers.
> 
> I also want to switch from Anakia to DVSL so that all you 
> XSLT weenies can stop crying about Anakia's inability to be 
> declarative. :-)

Then here is my +20,

let's get this going!



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

RE: Printable pages

[Berin Loritsch]

In that case, the entire Jakarta site needs to be redesigned.
It makes use of embedded tables and  elements.  It does
not use CSS at all.  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.

> -Original Message-
> From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, March 21, 2002 3:51 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Printable pages
> 
> 
> What I would like to do regarding this is to not have to 
> generate two sets of pages or have to generate PDF files as 
> well as HTML.
> 
> I would rather see the Jakarta site/stylesheet to use CSS and 
> take advantage of the  tag to have a printable stylesheet...
> 
> This is what Scarab does...
> 
>href="/scarab/style/print.css" media="print" />
> 
> -jon
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Printable pages

[Berin Loritsch]

My point is that every page should have a link to the printable
format.  The normal Jakarta layout is not printer friendly,
and the main site does not have a link to printer friendly docs.

We should have a standard for Jakarta that will always have printer
friendly docs for people to use.  Whether it is in the form of
PDF docs or just printerfriendly HTML docs I really don't care.


> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, March 21, 2002 1:57 PM
> To: Jakarta General List
> Subject: Re: Printable pages
> 
> 
> On 3/21/02 11:17 AM, "Jason van Zyl" <[EMAIL PROTECTED]> wrote:
> 
> > On Thu, 2002-03-21 at 08:39, Berin Loritsch wrote:
> > 
> >> I tried looking at the BCEL manual, and while it looks nice on 
> >> screen, when I tried to print it out it cut off almost two 
> inches of 
> >> text.
> > 
> > Yup, that's my fault. I will remedy the situation with PDFs. A very 
> > long time ago before Anakia we had PDFs being produced with 
> stylebook. 
> > The Turbine and Velocity docs were actually available in 
> PDF format. 
> > Anakia presented some problems that made it impossible to 
> use the fop 
> > stuff we created but that is different now with DVSL. Long story 
> > short: you will have PDF docs for BCEL sooner rather than later.
> > 
> 
> Did you try to use the printable target?  There is a second 
> stylesheet that generates a printer-friendly version of the docs.
> 
> 
> 
> -- 
> Geir Magnusson Jr. 
> [EMAIL PROTECTED]
> System and Software Consulting
> POC lives!
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:general-> [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]>

Printable pages

[Berin Loritsch]

Could we have two templates for the jakarta pages?  The problem is that
the
embedded tables inside tables inside tables inside tables ... approach
of the
default template causes many very useful pages to not print nicely.  We
need
a nice template that produces printable pages.  That means that the
pages
will not do fancy things with tables.  It should be simple, using CSS to
style the text (this works on all 4.0 or better browsers), with only a
link
to the referring page.

I tried looking at the BCEL manual, and while it looks nice on screen,
when I
tried to print it out it cut off almost two inches of text.  With a
printable
page template, we can run the templates twice.  Once to provide the
current
look, another to provide the printable page spec.

The problem with the BCEL manual presents itself in many situations,
such as
with the Turbine documentation, or just about any project.  That is why
on the
Avalon site we created a PDF document of our developer's doc.  It is
important
that users learn how to use our projects--and printable documentation
makes
that possible.  I learn best when my reference material is on an 8.5" x
11"
sheet of paper next to my machine so that I can refer to it as I am
working
in the source code editor.

To make things easier on ourselves, we could make all printable pages
show up
in a new window--then just have the printable pages close the window
they are
in when you click on the link.


"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
- Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: LICENSE in .jar files

[Berin Loritsch]

> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] 
> 
> BTW.  Define: "release" ;-)


That sounds like former persident Bill Clinton with his
"define sexual relations".  Such a question insinuates
guilt, and that you are trying to find a letter of the
law loop hole to be clever about.

Lawers are like wolves, they'll eat you for lunch.  You
may think you have a loop hole, but just shed the right
light, and it is exposed.

You're always better following the spirit of the law,
because the devil is in the details (and in the pin
striped suite)

> 
> On Wed, 2002-03-20 at 19:55, Conor MacNeill wrote:
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > > On Thu, 21 Mar 2002, Peter Donald wrote:
> > >
> > >
> > > I think what Peter said was that you can read the spec 
> only if you 
> > > agree with the licence, and that prevents you from 
> implementing it 
> > > unless you follow all the rules.
> > >
> > 
> > You can read the spec. You just can't use the spec to create a 
> > cleanroom implementation of the specification. You can 
> still read it 
> > to understand how to use somebody else's implementation. 
> Presumably, 
> > however, having read the spec, you are tainted.
> > 
> > > That includes the requirement to pass the official test 
> suite, and 
> > > probably other restrictions I don't understand.
> > 
> > The problematic clause is this one, I presume:
> > "(vi) satisfies all testing requirements available from the 
> > Specification Lead relating to the most recently published 
> version of 
> > the Specification six (6) months prior to any release of the clean 
> > room implementation or upgrade thereto;"
> > 
> > Presumably we cannot distribute the xml-apis unless we can 
> meet this 
> > requirement of the spec.
> > 
> > This page http://jcp.org/aboutJava/communityprocess/final/jsr063/
> > 
> > asserts that there is a JAXP TCK, although you can't seem 
> to purchase 
> > it online.
> > 
> > Other restrictions - who knows? When the spec says "(vii) does not 
> > derive from any of the Specification Lead's source code or 
> binary code 
> > materials;", it is not clear to me what that covers, 
> especially in the 
> > case of JAXP where I think the RI comes from Apache, based on code 
> > originally contributed by the Specification Lead (Sun).
> > 
> > Also there may be a specific Out-of-Band Sun-Apache licence 
> in place 
> > as alluded to by Dirk earlier.
> > 
> > >
> > > It's obvious some of the people who worked on this did 
> read the spec 
> > > - so it seems this is not a legal implementation.
> > >
> > 
> > If there is no specific agreement between Sun and Apache covering 
> > this, then I agree.
> > 
> > > The licencing and jcp lists are closed to the public, and 
> this seems 
> > > to be the job of the PMC and ASF ( to verify that all the 
> software 
> > > is legally used ). I can only hope a lawyer will be used 
> to validate 
> > > it.
> > >
> > > If this is not resolved - we have to start removing all 
> dependencies 
> > > to JAXP and all other APIs that are not legal, and 
> eventually work 
> > > on replacements.
> > >
> > > There is no other way.
> > 
> > I presume you can still depend on JAXP without having your 
> own clean 
> > room implementation, nor including it in a distribution. You would 
> > have to require the user to acquire their own copy of the jaxp 
> > classes/interfaces. I haven't seen any restrictions in the spec on 
> > linking.
> > 
> > Conor
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> > For 
> additional commands, 
> e-mail: 
> > 
> > 
> -- 
> http://www.superlinksoftware.com
> http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 
> Compound Document 
> format to java 
> http://developer.java.sun.com/developer/bugParade/bugs/4487555
.html 
- fix java generics!
The avalanche has already started. It is too late for the pebbles to
vote. -Ambassador Kosh


--
To unsubscribe, e-mail:

For additional commands, e-mail:



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: License issue (the come back)

[Berin Loritsch]

Danny Angus wrote:
>>The last point is the only real problem IMHO. Basically, it forbids to
>>export software in "free world ennemy countries TM". I don't know
>>if making
>>somone from such a country able to download software from a
>>website could be
>>considered software exportation, but considering the technical
>>impossibility
>>to prevent it, i doubt Sun itself could claims to fulfill it.
> 
> 
> On the other hand it would be hard to prove that you exported it yourself to
> a banned country, and didn't provide it to a user in the continental US who
> then sent it abroad.
> It certainly seems unworkable in principle, and as a foreigner I wonder what
> the US lawmakers would consider to be adequate protection against
> downloading by evil foreigners.
> You can pretty much bet the farm that terrorists won't let licence
> conditions stop their plans.


Then again, you can pretty much bet the farm that they aren't using Java
anyways.  Terrorists that use encryption are likely to use more powerful
russian (FSU?) encryption suites.  They also are not interested in
development, or ease of use.  They are interested in weapons and causing
damage.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

LogKit 1.0.1 Released

[Berin Loritsch]

LogKit 1.0.1 Released
-
  The Avalon team is proud to announce the 1.0.1 final
  release of LogKit.

About Avalon

  The Avalon project is Apache's Java Server Framework.
  It is separated into five sub projects: Framework,
  Excalibur, LogKit, Cornerstone, and Phoenix. Its
  purpose is to simplify server side programming for
  Java based projects. It formalizes serveral best
  of breed practices and patterns for server side programming.

For more information about Avalon, please go to
http://jakarta.apache.org/avalon

About LogKit 1.0.1
--
  LogKit is an easy to use logging toolkit designed
  for secure performance oriented logging. It's design
  encourages integration into existing products
  with minimal impact.

For more information about LogKit 1.0.1, please go to
http://jakarta.apache.org/avalon/logkit

ChangeLog for LogKit 1.0.1

*)  Fixed spelling in the documentation files. [PD]

*)  Fix javadoc warnings from "@returns" tags used instead
  of "@return". [PD]

*)  added new constructors to produce better readable
  file names in the File Strategy classes. [GP]

*)  Added fixes to AsyncLogTarget: Make sure that the
  LogTarget delegated to cannot disrupt thread by
  throwing an exception. Remove uneeded step from
  documentation. [PD]

*)  Many improvements to PatternFormatter including:
  Made it possible to specify the format of date in the
  auxilliary parameter of the format for dates. Cached
  the date and DateFormatter objects so that they are
  not created every time a LogEvent is formatted. Added
  a getRTime() method to format relative time. Just
  delegates to getTime at the moment for backwards
  compatability. [PD]

*)  Made sure that additivity is transitive (in Logger)
  - even when you only inherit your loggers from your
  parent. [PD]

*)  Added isPriorityEnabled() method to Logger to determine
  if specified priority is enabled. [PD]

*)  Various build improvements. [LM]


Downloads for LogKit 1.0.1 available at

http://jakarta.apache.org/builds/jakarta-avalon/release/logkit/latest




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

The Avalon team is proud to announce Avalon Excalibur 4.1

[Berin Loritsch]

Avalon Excalibur 4.1 Released
-
  The Avalon team is proud to announce the 4.1 final
  release of the Avalon Excalibur.

About Avalon

  The Avalon project is Apache's Java Server Framework.
  It is separated into five sub projects: Framework,
  Excalibur, LogKit, Cornerstone, and Phoenix. Its
  purpose is to simplify server side programming for
  Java based projects. It formalizes serveral best
  of breed practices and patterns for server side programming.

For more information about Avalon, please go to
http://jakarta.apache.org/avalon

About Avalon Excalibur 4.1
--
  Avalon Excalibur contains several premade Avalon
  Components and utilities to make your server side
  programming easier. There are several pool implementations,
  Component management implementations, and database
  management implementations.

For more information about Avalon Excalibur 4.1, please go to
http://jakarta.apache.org/avalon/excalibur

ChangeLog for Avalon Excalibur 4.1

*)  Initial port of Cocoon's Source resolvers and XML
  parsers [CZ]

*)  Added many fixes to the XML Resource Bundles and Resource
  Bundle access code. [NP]

*)  Update the extension management code and make it
  more robust. [PD]

*)  Add new Container abstraction to separate ComponentManager
  from Container code (i.e. ExcaliburComponentManager
  violates this). The new ContainerManager and Container
  abstraction make the system much easier to manage. [BL]

*)  Add new CommandManager architecture to manage all
  asynchronous commands and the ThreadManager architecture
  to manage the thread allocation policy for the CommandManager. [BL]

*)  New component to handle automatic XML Catalog resolution. [DP]

*)  Many improvements to the cache component. Extended
  cache validation support, multiple store backends,
  and more. [EP]

*)  Add an XPathProcessor abstraction Component with
  ThreadSafe implementations for Jaxen and Xalan
  backed XPath processors. [JT]

*)  Made automatic proxy code even more robust. [PD]

*)  Add support for recursive property resolution.
  Added appropriate unit test to accompany feature. [PD]

*)  Optimized pool implementations, and provided a
  new abstraction for managed pools (in scratchpad). [BL]

*)  Add many new LogTargetFactories to LogKitManager. [GP]

*)  Add new LoggerManager abstraction that works with
  the new framework Logger abstractions. [BL]

*)  Fixed some classloader issues in the i18n package
  for loading resources. Also fixed some i18n related
  issues in FileUtil and IOUtil. [PD]

*)  Applied many optimizations and logic fixes to DataSourceComponent
  code. [LM]

*)  Applied fixes to ReadWriteLock from Avi Drissman
  ([EMAIL PROTECTED]) [BL]

*)  Officially deprecate Lock in favor of Mutex. They
  have the same purpose, and Mutex is more correct. [BL]

*)  Optimize logging calls throughout components.
  Also, make the log messages more informative. [BL]

*)  ListUtils now checks for duplicates when merging
  Lists. [PD]

*)  Make BinaryHeap and PriorityQueue use Objects instead
  of Comparables. Optimize BinaryHeap code. [PD]

*)  Add new Buffer classes to the collections package.
  These are amazingly performant. It is based on CircularBuffer,
  which is now deprecated. [BL]

*)  Shake out some more performance of CLI Util, as well
  as better support for DUPLICATES_ALLOWED. [BL]

*)  Added some build improvements. [LM]

*)  Add new profiler instrumentation interfaces inspired
  by Matt Welsh's SEDA architecture. [BL]

*)  Add new asynchronous event queue system inspired
  by Matt Welsh's SEDA architecture. [BL]

*)  Update all the components to the new LogEnabled interface. [BL]


Downloads for Avalon Excalibur 4.1 available at

http://jakarta.apache.org/builds/jakarta-avalon/release/excalibur/latest




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: More abuse of coding styles...

[Berin Loritsch]

Sam Ruby wrote:

> Stephane Bailliez wrote:
> 
>>I can understand why:
>>
>>public void setSomething(Object something){
>>   something = something;
>>}
>>
> 
> Another solution is
> 
> public void setSomething(Object something) {
>  this.something = something;
> }


Just beware of this bug:

public void setSomething(Object somthing) { // something misspelled
 this.something = something;
}





-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: License change for new year ?

[Berin Loritsch]

Peter Donald wrote:

> On Wed, 9 Jan 2002 10:55, Vincent Massol wrote:
> 
>>1/ Now that we are in 2002, do we need to change the text in all our
>>license files to be : "Copyright (c) 1999-2002 The Apache Software
>>Foundation" instead of "Copyright (c) 1999-2001 The Apache Software
>>Foundation" ?
>>
> 
> should change it to include 2002. However the start date is determined by 
> when the project actually started/was donated to Apache - so many of the 
> newer ones will be 2001-2002
> 
> 
>>2/ Some license files only have "Copyright (c) 1999 The Apache Software
>>Foundation" and some others have a year range as in "Copyright (c)
>>1999-2001 The Apache Software Foundation". Should one be preferred over
>>the other ? Are they both valid ?
>>
> 
> It should be the longest duration at which it has been continuously developed 
> and owned by Apache. So most projects will be one of
> 
> 1999-2002
> 2000-2002
> 2001-2002
> 
> However some projects were mothballed and if we ever restarted work on them 
> we would have to do something like
> 
> 1999-2000,2002 (for stylebook for instance)


Basically once the code is "published" in some form, (I.e. public CVS, official

release, etc.) you have to have a stamp on it.  Print publications have full
dates for each release of the publication--though we shouldn't need to do that
for our code.




-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: More abuse of coding styles...

[Berin Loritsch]

Endre Stølsvik wrote:

> On Thu, 3 Jan 2002, Jon Scott Stevens wrote:
> 
> The _instanceVariable and also the __staticVariable idea makes real good
> sense to me nowadays. Do you have any arguments against it? (btw; this is
> a genuine question!)..


Honestly, I don't like the underscore notation.  If there is any deviation
from that, it would be simple scope modifiers like m_memberVariable.

I have adopted the practice of explicitly scoping all my veriables.  It is
better supported by IDEs with autocompletion, so for me it even reduces
typing.  Also, I try not to ever use a parameter that is the same as a
member variable.


> 
> And while talking about code conventions; people writing like this:
> 
> if (something)
> {
> 
> }


As long as the deviation is *documented*.  If you supercede the Sun
conventions, you must document exactly how it is done.  Examples of
this are in both the Struts and the Avalon projects.  Both clearly
identify coding practices that supercede Sun's conventions.

This also means that *all* Commons code must adopt the coding convention.

Honestly, the aditional space forced by the brace on the following line
_does_ increase legibility.


> 
> should be shot right there on the spot, in the act of typing it.
> 
> The ONLY way to write blocks is like this:
> 
> if (something) {
> 
> }
> 
> 
> ;)
> 
> 



-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Jakarta Newsletter

[Berin Loritsch]

Jon Scott Stevens wrote:

> Hi Rob,
> 
> It is indeed a great idea. However, the two editors given credit at the
> bottom of the url you posted are Sun employee's who get paid to do the job
> so they don't really count as 'volunteers'.


:)  This is true.


> 
> The Jakarta project has plenty of great minds and thus great ideas. What we
> are lacking is great volunteers. Everyone is too busy bitching about what an
> asshole I am.


That's a full time job, and it's fun!  ;P

Seriously though, a newsletter takes alot of time.



-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Standard "Change Log" and "ToDo"

[Berin Loritsch]

Ted Husted wrote:

> On a similar note, has anyone started a format for a XML Status file,
> like the one described here:


BTW, the Avalon team decided to abandon maintaining a separate TODO file
in favor of using BugZilla for the same thing.  It is less likely to be
lost in the shuffle, thanks to the periodic notifications we get from
BugZilla (although I haven't seen any lately).


> 
> http://jakarta.apache.org/site/source.html
> 
> 
> Ted Husted wrote:
> 
>>We have a rudimentary XML format for a TODO list at Struts, but it needs
>>work. Here's a sample
>>
>>
>>  
>>Unit tests for the org.apache.struts.action
>>package.
>>  
>>  
>>mailto:[EMAIL PROTECTED]";>Rob Leland
>>  
>>
>>
>>Right now, we put "release notes" into the documentation, which acts as
>>a Change Log. That's been a real pain though, and I'm not sure if it's
>>effective.
>>
>>What would be handy if we had compatible TODO and Changelog XML formats,
>>so when something was done, we could update the TODO and then paste it
>>into to the Changelog.
>>
>>-T.
>>
>>Paul Spencer wrote:
>>
>>>Is their a standard or common "Change Log" and "To Do" format for
>>>Jakarta projects?  I would like to add a change log to the Jetspeed project.
>>>
>>>It appears the Cocoon project uses Stylebook.  Jakarta projects use
>>>Anakia, but I have not found any macros in Jakarta-site2 that reference
>>>a Change Log or To Do list.
>>>
>>>Paul Spencer
>>>
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> .
> 
> 



-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Standard "Change Log" and "ToDo"

[Berin Loritsch]

Peter Donald wrote:

> Hi,
> 
> The advantage of XML for changelogs is that is easier to generate the 
> ChangeLog in whatever format you want. For instance Avalon generates HTML 
> (same format as cactus changelog), GNUs format and a lite text format. We 
> even use it it when generating our announcement texts/xml snippets for new 
> versions. I think (though I am not sure) that Berin even versions his PDF 
> documents using an XML changelog (and these documents are also available as 
> html).


Yep, this is true!





-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

The Avalon Team is proud to announce Avalon Framework 4.1

[Berin Loritsch]

Avalon Framework 4.1 Released
-
  The Avalon team is proud to announce the 4.1 final
  release of the Avalon Framework.

About Avalon

  The Avalon project is Apache's Java Server Framework.
  It is separated into five sub projects: Framework,
  Excalibur, LogKit, Cornerstone, and Phoenix. Its
  purpose is to simplify server side programming for
  Java based projects. It formalizes serveral best
  of breed practices and patterns for server side programming.

For more information about Avalon, please go to
http://jakarta.apache.org/avalon

About Avalon Framework 4.1
--
  The Avalon Framework formalizes the contracts and
  patterns used in the other Avalon projects. It is
  derived from modern software engineering techniques
  and aims to provide a solid basis on which to build
  server products.

  What that means is that we define the central interface
  Component. We also define the relationship (contract)
  a component has with peers, ancestors and children.
  This documentation introduces you to those patterns,
  interfaces, and relationships.

  The Avalon Framework raises the abstraction level
  from Object-Oriented Programming concept one notch
  to the Component-Oriented Programming model. This
  enables programmers to concern themselves with
  assemblies of classes, rather than the classes themselves--thus
  reducing the number of things the programmer must
  keep in mind, and speeding up application development.

  The Avalon Framework is already used in Cocoon2 (http://xml.apache.org/cocoon2),
  an XML publishing framework. The Avalon Framework
  is also used in Apache JAMES (http://jakarta.apache.org/james),
  a Java(tm) Mail Server. Another project that is built
  on Avalon Framework is Jestkop (http://www.jesktop.org),
  a cross-platform replacement for your ordinary
  desktop. If you are evaluating Avalon and want the
  proof that it's claims are valid check them out.


For more information about Avalon Framework 4.1, please go to
http://jakarta.apache.org/avalon/framework

ChangeLog for Avalon Framework 4.1

*)  Improve and update the configuration javadocs to
  reflect the new namespace support. [JT]

*)  Deprecate the Loggable and AbstractLoggable classes,
  and replace them with LogEnabled and AbstractLogEnabled. [BL]

*)  Add an abstraction layer to the Logging implementation.
  Thanks to Peter Donald for supplying the interface. [BL]

*)  Add Namespace support to Configuration files. [BL]

*)  Add AvalonFormatter that was in LogKit's heirarchy.
  This way, we avoid circular dependancies. [BL]

*)  Previously resolve did not throw a ContextException.
  This made it difficult to indicate errors resolving
  objects. It now throws an exception thus allowing
  errors to be propogated and recorded. [PD]

*)  New ConfigurationSerializer to have your configuration
  objects persist. [BL]

*)  Upgrade DefaultConfigurationBuilder to be JAXP
  compliant, with the option to pass in your own XMLReader. [BL]

*)  Configuration objects are now Serializable. [PD]

*)  Add new support to ask a component manager if it has
  a component. [BL]

*)  Bug fixes for documentation [PD]

*)  Update developers docs to support new configuration
  methods. [BL]

*)  Improved "Hello World" documentation. [PH]

*)  Add UML diagrams supplied by Dieter Wimberger [PD]

*)  Add new author bios. [BL]

*)  Update build process to proposed standard. [BL]

*)  Added a method to Version to parse a Version from a
  string. Added accessor methods to Version to allow
  access to major/minor/micro components of version. [PD]

*)  Updated Version class to refer to micro version rather
  than revision. This is to match the terminology for
  JDK versioning. This is just documentation changes. [PD]

*)  Changed access of Enum and ValuedEnum constructors
  from public to protected, to prevent Enum users from
  breaking type-safety by adding new Enum items. This
  breaks backwards-compatibility in cases where
  Enum and ValuedEnum were being incorrectly used. [JT]


Downloads for Avalon Framework 4.1 available at

http://jakarta.apache.org/builds/jakarta-avalon/release/framework/latest



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Comment for Apache.org

[Berin Loritsch]

lloyd wrote:

>>Wow. It would be really great if you wrote an email that made some logical
>>
> 
> Having lurked on this list for awhile, I'd say it would be great if you
> could get through one e-mail exchange without being an asshole.


Not again.

People, even if you don't like Jon, can we just let this one go please?
I don't want to see YAFF (Yet Another Flame Fest) on netiquette.





-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: License Question (JDBC 2 vs. JDBC 3)

[Berin Loritsch]

Sam Ruby wrote:
> 
> Berin Loritsch wrote:
> >
> > public class java.sql.SavePoint {}
> >
> > Sun guards the java.* classes jealously, and I need to know if this
> > is really a solution.
> 
> What Sun generally tries to do is to stop people from extending or
> subsetting the full API.  What you are describing certainly looks like a
> subset to me.

Are you sure it is not a superset?  In a Jdbc 2.0 environment, this class
is not even available.  All the other classes are not touched, superceded,
or anything.  I can make the SavePoint interface match Sun's definition,
which would avoid the "subsetting" issue.  The question is, is this enough?


-- 

"Those who would trade liberty for
 temporary security deserve neither"
- Benjamin Franklin

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

Re: License Question (JDBC 2 vs. JDBC 3)

[Berin Loritsch]

Sam Ruby wrote:
> 
> Berin Loritsch wrote:
> >
> > public class java.sql.SavePoint {}
> >
> > Sun guards the java.* classes jealously, and I need to know if this
> > is really a solution.
> 
> What Sun generally tries to do is to stop people from extending or
> subsetting the full API.  What you are describing certainly looks like a
> subset to me.

The only other alternative is to use the filtering/substitution in the
build.  What this would do is add a couple directives like this:

@JDBC3_START@

void methodCall() {}

@JDBC3_END@

If JDBC3.0 is installed, the two directives would be replaced with an
empty string "".  If JDBC3.0 is not installed, it is replaced with the
C-Style comment delimiters "/*" and "*/" respectively.

I don't like that solution as the code cannot compile by itself, and
leads to abuses in macros that Java so diligently tries to avoid.


-- 

"Those who would trade liberty for
 temporary security deserve neither"
- Benjamin Franklin

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

Re: License Question (JDBC 2 vs. JDBC 3)

[Berin Loritsch]

Sam Ruby wrote:
> 
> Berin Loritsch wrote:
> >
> > public class java.sql.SavePoint {}
> >
> > Sun guards the java.* classes jealously, and I need to know if this
> > is really a solution.
> 
> What Sun generally tries to do is to stop people from extending or
> subsetting the full API.  What you are describing certainly looks like a
> subset to me.

Ok, so how do I handle that?  Do I keep the ugly hacks in the build process?
Do I include the full interface?  Keep in mind this is only for JDBC 2.0
environments where this class does not exist.


-- 

"Those who would trade liberty for
 temporary security deserve neither"
- Benjamin Franklin

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

License Question (JDBC 2 vs. JDBC 3)

[Berin Loritsch]

In Avalon Excalibur, we want to make our Connection Pooling code
future compatible with JDK 1.4.  We currently do it with conditional
compiling, and renaming some classes.  I find this to be a clumsy
solution, and leads to questions from people not familiar with the
build process.  Almost all the new methods except the new transaction
handling methods can be included in the JdbcConnection class.

The issue is the SavePoint class.  SavePoint is new to the JDBC 3.0
collection, and is accessed from the Connection object.  It is used
to allow you to make Save Points in a transaction--so you can restore
to a SavePoint and try an alternate solution.  The problem is, in order
to remain compatible in JDBC 2.0 environments, we need to have a
SavePoint class that can do absolutely nothing.

We would have to have a class in the jar like this:

public class java.sql.SavePoint {}


During the compile, if a Jdbc3.0 environment was detected, the class
would be excluded from the build and the Jdbc3Connection class would
be included.  The opposite would happen when we don't have Jdbc3.0
available.

Sun guards the java.* classes jealously, and I need to know if this
is really a solution.

-- 

"Those who would trade liberty for
 temporary security deserve neither"
- Benjamin Franklin

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Distributing the JSSE

[Berin Loritsch]

Guillaume Rousse wrote:
> 
> Ainsi parlait Kasper Nielsen :
> > > > so this is an US export law issue and not a Sun License issue?
> > >
> > > I think so. It would be possible to distribute it but it would take a lot
> >
> > of
> >
> > > work to get all paper work done and I think there was other conditions
> > > (ie must be us citizen, must get the connections from embargoed countries
> >
> > blocked
> >
> > > etc)
> >
> > thats strange on http://java.sun.com/products/jsse/index-102.html they have
> > a link to
> >
> > Download JSSE 1.0.2 global software and documentation with support for
> > strong encryption.
> >
> > and a Download JSSE 1.0.2 domestic (US/Canada) software and documentation
> > with support for strong encryption
> >
> > Don't know what the difference is, but I would imagine its legal to
> > distribute something that is allready allowed to be globally distributed?
> Sofar no one answered this mail... Does US crytopgraphy export restrictions
> apply to both version of JSSE, or only to domestic version ? And do these
> restictions apply everywhere, or only for US-based download location ?

The latest version of JSSE complies with US restrictions for most countries.
However, US export law forbids ANY type of encryption to certain countries
(mostly known for supporting or allowing terrorist activity).

> Said otherwise, can jpackage project (jpackage.sourceforge.net) provide JSSE
> global version packages, as any other Sun java API packages, eventually only
> on non-US mirrors, or is it a special case ?

It is a special case, as certain countries are not allowed to get ANY type
of US encryption technologies.

> --
> Guillaume Rousse <[EMAIL PROTECTED]>
> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 


-- 

"Those who would trade liberty for
 temporary security deserve neither"
- Benjamin Franklin

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

LogKit 1.0 Released

[Berin Loritsch]

LogKit 1.0 Released
---
 The Avalon team is proud to announce the 1.0 final
 release of LogKit.

About Avalon

 The Avalon project is Apache's Java Server Framework.
 It is separated into five sub projects: Framework,
 Excalibur, LogKit, Cornerstone, and Phoenix. Its
 purpose is to simplify server side programming for
 Java based projects. It formalizes serveral best
 of breed practices and patterns for server side programming.

For more information about Avalon, please go to
http://jakarta.apache.org/avalon

About LogKit 1.0

 LogKit is an easy to use logging toolkit designed
 for secure performance orientated logging. It's
 design encourages integration into existing products
 with minimal impact.

For more information about LogKit 1.0, please go to
http://jakarta.apache.org/avalon/logkit

ChangeLog for LogKit 1.0


Downloads for LogKit 1.0 available at 

http://jakarta.apache.org/builds/jakarta-avalon/release/logkit/latest

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

Avalon Phoenix 4.0a1 Released

[Berin Loritsch]

Avalon Phoenix 4.0a1 Released
-
 The Avalon team is proud to announce the 4.0a1 alpha
 release of Avalon Phoenix.

About Avalon

 The Avalon project is Apache's Java Server Framework.
 It is separated into five sub projects: Framework,
 Excalibur, LogKit, Cornerstone, and Phoenix. Its
 purpose is to simplify server side programming for
 Java based projects. It formalizes serveral best
 of breed practices and patterns for server side programming.

For more information about Avalon, please go to
http://jakarta.apache.org/avalon

About Avalon Phoenix 4.0a1
--
 Avalon Phoenix is a micro-kernel designed and implemented
 on top of the Avalon Framework. It is both an API to
 program to and a reference implementation. The reference
 implementation provides a number of facilities
 to manage the environment of Server Applications.
 Such facilities include log management, classloading,
 thread management and security. In the future it
 will conditionally offer support extra facilities
 such as central server management, server pools,
 and other facilities aimed at reducing the time to
 market. The API defines a standard method of piecing
 togther server components and creating a server.

 In order to see Avalon Phoenix at work, you should
 grab the example applications or servers that are
 included in Avalon Cornerstone. Apache James (http://jakarta.apache.org/james/)
 uses Phoenix for it's mail server.


For more information about Avalon Phoenix 4.0a1, please go to
http://jakarta.apache.org/avalon/phoenix

ChangeLog for Avalon Phoenix 4.0a1

*)  Too many things to enumerate here. This is the first
 public release, and the code is still considered
 alpha. In future releases, we will be much more careful
 to record the changes to Phoenix. [BL]


Downloads for Avalon Phoenix 4.0a1 available at 

http://jakarta.apache.org/builds/jakarta-avalon/release/phoenix/latest

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

Avalon Excalibur 4.0 Final Release Available

[Berin Loritsch]

Avalon Excalibur 4.0 Released
-
 The Avalon team is proud to announce the 4.0 final
 release of the Avalon Excalibur.

About Avalon

 The Avalon project is Apache's Java Server Framework.
 It is separated into five sub projects: Framework,
 Excalibur, LogKit, Cornerstone, and Phoenix. Its
 purpose is to simplify server side programming for
 Java based projects. It formalizes serveral best
 of breed practices and patterns for server side programming.

For more information about Avalon, please go to
http://jakarta.apache.org/avalon

About Avalon Excalibur 4.0
--
 Avalon Excalibur contains several premade Avalon
 Components and utilities to make your server side
 programming easier. There are several pool implementations,
 Component management implementations, and database
 management implementations.

For more information about Avalon Excalibur 4.0, please go to
http://jakarta.apache.org/avalon/excalibur

ChangeLog for Avalon Excalibur 4.0

*)  Update user docs. [BL]

*)  Remove dead code in scratchpad. [PD]

*)  Rework thread pooling package to a new design. This
 provides a mechanism to run a cleanup thread when
 the JVM is killed. [PD]

*)  Add classloader extension framework into the extension
 package. [PD]

*)  Add Container mechanism from Avalon Phoenix. [PD]

*)  Add support for recursive property resolution.
 Added appropriate unit test to accompany feature.
 (Property utils). [PD]

*)  Problem Fixed: I've encountered a problem with the
 SingleThreadedPool in that it alternatley returns
 valid and null pooled objects until you've got the
 "initial" constructor argument + 1 and then it starts
 returning (Poolable)m_factory.newInstance().
 Submitted by: "Corey O'Donovan". [PD]

*)  Fix some bugs found by Pool Profiling tests. [BL]

*)  Add new resource monitoring facility. This allows
 you to actively monitor resources and be notified
 if they are changed by outside forces. [BL]

*)  Set hierarchy via constructor to allow LogKit to
 work in sub classloaders. Submitted By: Sylvain
 Wallez. [DP]

*)  Update FileUtils with methods to count size of a directory,
 input argument check, fix javadoc, and method to
 convert an array of Files into URLs. [DP]

*)  ClassLoaderObjectInputStream moves from Cornerstone
 to Excalibur. [PH]

*)  Promote the i18n ResourceManager code to Excalibur
 production. [DP]

*)  Updated log messages for JdbcConnection--as well
 as added runtime detection if no connections could
 be created. This provides better reporting if the
 connection has configuration errors or other mitigating
 errors. [BL]

*)  Add direct support for Informix connection pooling.
 Requires the most recent JDBC drivers from Informix
 to use this feature. [BL]

*)  Deprecated the oradb attribute in JdbcDataSourceComponent,
 and added a keepalive element.This way we can test
 the line with valid SQL statements no matter what
 the DB is. Informix had trouble with the "select 1"
 and I am sure there are others. [BL]

*)  Fix bugs found by ReadWriteLock Test Case in the concurrent
 package. [BL]

*)  Update component package with support for Paremeterizable
 components (patch from Mircea Toma) [DP]

*)  Add support to display if an option is required. Patch
 was from Tom Jordahl (from xml-axis project). [BL]

*)  Fixed bug "CLArgsParser loops infinitely on OPTIONAL
 options" like "-Fa -B" where F optionally has an argument.
 Added unit tests to verify that it has been fixed. [PD]

*)  Update javadocs with '@since' tags so that we know
 when components have been introduced. [JT]

*)  Update JDBC datasource component so that you can
 specify your keep-alive query. This is for databases
 that don't like "SELECT 1;" as a query. [BL]

*)  Add new JUnit TestCase for automatically setting
 up Avalon Components and running tests. [GP]

*)  Fix a number of tests, and provided a couple new tests. [BL]

*)  Fix build process for tests and fix some of the tests. [PD]

*)  Add new LogKit Management framework to allow each
 component to have unique logger implementations
 and provide fine grained control over logging. [GP]

*)  Add new JNDI package to Excalibur with Memmory and
 RMI providers. [PD]

*)  Updated Announcement.xml to not refer to Testlet
 anymore. [BL]


Downloads for Avalon Excalibur 4.0 available at 

http://jakarta.apache.org/builds/jakarta-avalon/release/excalibur/latest

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

Re: Standardizing build.xml files

[Berin Loritsch]

The Alexandria project with Gump, Maveric, et. al.
are doing a great job of keeping all the builds working
with each other.  It also helps with notifying projects
of changes in the API.

But there hasn't been any official documentation or requests
for target naming conventions like I just proposed.  If everyone
likes the approach, Ant should place the information in their
manual (like gnumake does with its conventions)--and all project
leaders should either make the modifications to the build
files or propagate the information to the team (someone will do
it).

Personally, I will copy the proposal to the Avalon and Cocoon
development lists.  It seems that the proposal struck a couple
cords on this list, so we will see if the build scripts change :).

Jon Stevens wrote:
> 
> Please join the alexandria project's mailing lists. Gump, Maveric, JJAR,
> etc, are all trying to do this in one way or another.
> 
> I think that the first priority is to get CJAR* working. Once we have that,
> using the information provided by Gump to create standardized build files
> for projects becomes a whole lot easier.
> 
> * I like CJAR better than CJAN as a name now. CJAR == Comprehensive Jar
> Archive Repository.
> 
> -jon
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

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

Standardizing build.xml files

[Berin Loritsch]

I propose that we all use a standard target convention for
all Ant based projects.  This is something that helps adopters
of GNU software all over.  A person who has never seen GNOME
or GCC knows they can compile it by running "./configure"
and "make all check install".  These conventions make it
easier for the newbie to come up to a fresh project and
get it to compile.

One of the reasons I have come up with the proposal is that
every project has its own conventions.  I have been involved
in at least seven Apache projects in some capacity or another
and have contributed code to four of them.  They each have
different conventions.  One of the ways I work is building
the project completely fresh before testing--I uncover more
bugs that way.  I would very much like to run "./build clean all"
but most projects have a different target name for the default
build target.  Already most projects use the following target
names: "clean", "docs", "dist", and "javadocs".  Most "clean"
targets leave some artifacts behind, and only a couple projects
have the concept of "distclean".

I propose we borrow a number of conventions from the GNU
"make" utility manual
(http://www.gnu.org/manual/make-3.79.1/html_chapter/make_14.html).

If a program can be installed, then a build file must
use these properties (which can be overridden by a user's
.antrc file).  The properties and default values follow:

* install.dir=.
* install.bin.dir=${install.dir}/bin
* install.lib.dir=${install.dir}/lib
* install.data.dir=${install.dir}/conf
* install.doc.dir=${install.dir}/docs

By using these properties, Ant is able to customize how the
program is installed and filter the scripts to point to the
proper jars, etc.

The standard targets I propose we all adopt are similar to
the Make utility conventions ('all' is the default target):

'all'
Compiles the program with debugging enabled by default.
This target is not required to build documentation.  Standard
compilation properties and defaults are:
* build.debug=on
* build.optimize=off
'install'
This target ensures that everything is built, including
documentation.  It then copies the files in the corresponding
directories already mentioned above.  All jars should be
considered libraries, and scripts should be provided to run
them.  If installation is not provided by a project,  the
build script should display a message to that effect.  Optionally,
{build.optimize} could be set to "on" for this target.
'uninstall'
This target removes all the project files from the afformentioned
directories.  IMPORTANT:  The uninstall script should NOT
assume that the {install.[*].dir} directories are direct decendants
of the {install.dir} directory.  If installation is not provided
by the project, the build script should display a message to
that effect.
'clean'
This target deletes all files that are generated by the build
process--but does not delete files used to configure the build
process.
'distclean'
This deletes all files that are left from clean and returns the
project to its distributed state.
'docs'
This generates all documentation for a project.  This includes
user docs and javadocs.
'javadocs'
This simply generates the javadocs for the project.
'printerdocs'
This generates a printer friendly version of the documentation.
Most projects dynamically build their documentation from XML
anyway. They should provide a nice and simple stylesheet that
avoids all the HTML tables embedded in tables approach most
site docs use.
'dist'
This target should be used for generating all the artifacts used
for a distribution.  That means the tar ball and zip file used to
distribute projects, and any dynamically generated announcement
files.
'check'
This target is used to compile and execute any unit tests that
are built into the project.

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

Re: [OT] $un, M$ and Java

[Berin Loritsch]

Alex Fernández wrote:
> 
> Hi Berin!
> 
> Berin Loritsch wrote:
> > "Kevin A. Burton" wrote:
> > > I hate this!
> > >
> > > "Sun called on consumers "to demand that Microsoft include the Java platform in
> > > their XP operating system." Sun also said consumers should demand "PC vendors
> > > like Dell, Compaq, Gateway, IBM and HP (Hewlett-Packard) include the Java
> > > platform in their applications."
> >
> > I don't have a problem with this at all.  It means that I can have clients install
> > my software without having to download anything first.  Sure it helps SUN, but it
> > also helps me.  Kind of a win/win situation if you will.
> 
> It's hard to believe. What are you selling? Applets? Kind of a support
> nightmare for you then. Otherwise, you run what you need on the server
> and don't care about client JVMs.

Full fledged Java applications.  One of our suite of applications that
is impractical
to do on the server-side is one that maps a physical store layout to the
categories
of products.  It requires JVM 1.2 or higher, and is somewhat of a
complex beast.

What about JBuilder, Together, and other all Java applications?  They
all have extra
bulk because they all include the JVM that they run on.  It is
impractical to have
5 JVMs on the machine that are in almost all points identical when 1
will do.

> > They would find a way--or they would step up the FUD campaign.  With SUN 
>controlling
> > Java, there is little that MS can do to belittle it.  SUN has proven itself in
> > the marketplace, and serves as that single point to blame if something goes wrong.
> > That accountability keeps SUN honest in regards to Java.
> 
> Try this:
> http://conferences.oreilly.com/oscon/
> The FUD campaign against GPL is at full throttle right now.
> 
> Now, as to Sun: you seem to imply that we may trust Sun or we may move
> somewhere else. This is simply not true. Nobody can own a language --
> you can develop a free alternative if you wish to, and then call it
> something else. Sun will sue you so you do not display the Java logo in
> the box -- big deal.

Sun has a certain industry respect--and like it or not it transfers onto
Java to
a certain degree.  Beyond that, I don't trust any proprietary company to
control
languages or frameworks.

> This point is moot. Tomorrow I'll send Linus a patch so the next Linux
> kernel is fully SMP capable with 1024 CPUs -- I'm sure he'll happily
> apply it.

I'd like to see that kind of hardware sold (It's impossible with
current
Intel architecture so we would be using a RISC based approach I
presume).  Last
I checked (which was a couple years ago), the best Intel could do with
its x86
line was 8-way processing.

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

Re: [OT] $un, M$ and Java

[Berin Loritsch]

"Kevin A. Burton" wrote:
> 
> > What I would like to see is something *better* than the JCP.  I believe in
> > open research.  OSS fits a great many needs, but there are some key points in
> > Free Software (GPL/LGPL) that I don't necessarily agree with.
> 
> I don't think that *anyone* should have problems with Free Software itself.
> Apache is Free Software.  I think you probably mean copyleft.  Copyleft is a
> controversial concept and I think it is still a number of years until it is
> really appreciated.


When I spoke of Free Software, I spoke with the definitions that Richard
Stallman uses--which excludes Apache.  Apache is OSS compliant though.

As to Copyleft appreciation, I used to be a proponent of that approach.  The
benefit of Copyleft is obvious to many people, however it's license is not
written in an easily understood manner.  This leads to potential violations
whether intentionally or not.  The simplicity of the Apache Software License
or the X Server License makes using them easier.  I am more confident with
those licenses because I can usually incorporate any code I want and all will
be well.

My conclusion of the whole licensing issue is this: for the desktop or user level
software use the GPL, but for server side stuff where you need to provide dynamic
elements that are corporate specific use an ASL style license.

There are fewer issues to deal with when you use this type of approach.  I am
pretty pragmatic, and I use what works for me.  Most of the time OSS works for
me due to budget constraints (I would rather spend $2000 to fix a broken transmission
than buy a new IDE).

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

Re: [OT] $un, M$ and Java

[Berin Loritsch]

"Kevin A. Burton" wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Jon Stevens <[EMAIL PROTECTED]> writes:
> 
> > 
> 
> 
> I hate this!
> 
> "Sun called on consumers "to demand that Microsoft include the Java platform in
> their XP operating system." Sun also said consumers should demand "PC vendors
> like Dell, Compaq, Gateway, IBM and HP (Hewlett-Packard) include the Java
> platform in their applications."

I don't have a problem with this at all.  It means that I can have clients install
my software without having to download anything first.  Sure it helps SUN, but it
also helps me.  Kind of a win/win situation if you will.

Another benefit will be a larger number of people complaining to SUN about certain
defects or performance drops with every new release of the Java language (1.3 is
slower than 1.2 which is slower than 1.1.x on several IO routines).  I realize that
JDK 1.4 is supposed to seriously address these issues, but there are other issues
with JDK 1.4.

> Why would we want yet ANOTHER proprietary application shipped as a standard on
> an OS?  It would be a different story if the JVM were OSS but guess what?  It
> isn't.  Why would I want to help SUN increase their stranglehold over the
> computer industry?

It truly is a convenience.  If a user is buying a PC with JRE preinstalled, they
will use it--or explore using programs that use it.  It opens up a
lot of potential clients for our OSS projects.  Let's face it, we chose to build
a lot of projects on a proprietary "standard".

> It seems to me that as soon as they OSS Java, all their problems will go away:

I disagree, see below.

> - - No more competition from .NET/C#. (why would anyone want to support an MS
>   proprietary language?)

You might think that, but there are a number of MS shops out there who implement
things on MS technology because it was MS.  Case and point, I worked on a project
for a couple state law enforcement agencies, and my employer insisted on an all
MS technology.  When we tried to drum up more business, the remaining states were
clamoring for Oracle and Unix--so the division folded up with two successful
projects under it's belt.  The example shows both the danger of dependency on
MS technology, and the cycle of dependancy it forces you in.

> - - If it were GPL/LGPL MS couldn't embrace and extend?

They would find a way--or they would step up the FUD campaign.  With SUN controlling
Java, there is little that MS can do to belittle it.  SUN has proven itself in
the marketplace, and serves as that single point to blame if something goes wrong.
That accountability keeps SUN honest in regards to Java.

> - - All the bugs that have been sitting in the JVM for *years* will finally get
>   fixed.

I would have to agree to this point.  SUN does need to explore methods of accepting
patches from the general community--but they still need to be in control.  The
truth is some of those patches will inevitably break something else in another system
altogether.  Java is HUGE, and no one user will be able to test *every* use of a
core object.  Of course, they could test to spec--in which case all other areas that
break have to be fixed.

Allowing just anyone to commit a patch without full testing could cause some high
paying customers alot of headache.

> - - They don't have to spend the millions of dollars they spend on maintaining the
>   JVM.

They can explore a number of options with maintaining the JVM that could potentially
lower the amount that they spend.  Basically the cost of maintaining the JVM won't
change (it might even increase), but it will be spread accross many companies that
maintain it.

> - - Universal industry acceptance of Java.

Ok, you now have bitten the "OSS is the god of the software world" bug.  OSSing Java
would actually alienate a number of large IT firms.  I know personally a couple
customers of my company that would not allow it on their servers simply because it
is open source.  (They don't allow Apache HTTPD on their servers for that reason,
even if it has been proven time and again).

> - - Tons of cool stuff! :)

That's pretty specific. ;P


-- Loss of millions of marketing dollars and industry buzz

Let's face it, SUN promotes Java well.  By making them lose control of the platform,
what incentive will they have?  SUN will pull a MS and put together another competing
standard.


What I would like to see is something *better* than the JCP.  I believe in open 
research.
OSS fits a great many needs, but there are some key points in Free Software (GPL/LGPL) 
that
I don't necessarily agree with.

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

Re: [OT] $un, M$ and Java

[Berin Loritsch]

--- Jon Stevens <[EMAIL PROTECTED]> wrote:
> Lets see:
> 
> Sun doesn't open Java so that M$ can do cool stuff
> with Java and put them
> out of business.

Some of that stuff was cool, but it broke platform
neutrality (hmm, familiar modus operandi).  If M$
decided to make it _obvious_ that COM integration
was a M$ specific feature instead of muddying the
concept of what the proper API was, it wouldn't
have been such a big deal.

> M$ attempts to do cool stuff with it anyway by
> creating a clean room
> implementation. Go M$!

I don't mind a clean room implementation.  I don't
mind them trying to get a really fast VM.  I just
want to be assured software I write works in EVERY
PLATFORM--with no mods.

> Sun sues M$ for trying to do something cool with
> Java:
> 
> > "It is ironic that we spent three years in
> litigation with Sun over their
> > attempt to stop us from shipping Java in Windows,
> and now they are complaining
> > that we are not shipping it by default in Windows
> XP," said Jim Cullinan,
> > Windows XP lead product manager."
> 
> M$ creates competition with .NET and removes Java
> from its OS.

No serious development was targeted at M$ VM anyway,
it was too old.  It is a *good* thing that we can
have a common standard work on all platforms!

> Sun takes full page ads out and whines like a baby.
> 
> > "Microsoft certainly is not doing Java users any
> favors," he said. "It's
> > entirely understandable and predictable they would
> do something like that.
> > They have been an underminer of Java since day
> one."

I could think of some full page adds that M$ has run
whining like a baby, so I don't get your point.  It's
all marketing anyway.

> Someone should run an ad in the various newspapers
> to tell Sun to get a
> f*cking clue.



__
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

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

Re: [OT] FW: Sun Headquarter Briefings: Developing Web Services

[Berin Loritsch]

Peter Donald wrote:
> 
> On Fri, 10 Aug 2001 09:29, Geoff Soutter wrote:
> > > Another key
> > > difference is the emphasis on ubiquity.
> >
> > Yes, seems to me this one of the main difference (apart from the
> > "marketing" aspects). This comes from using a public, "free" network rather
> > than private, fee based network to transmit the data.
> 
> I wonder how long that will last. I don't have any experience in this area
> but I would find it insane for any decent sized organization to rely on the
> internet for any time sensitive data. Imagine what happens when network goes
> down or slows up. Time sensitive data may not be delivered on time and thus
> may incur fines or may have to wait till next delivery period. And I would
> hazard to guess that this could be costly for the organiztion.

Every example I have seen for web services would lay in the area of
"trivial
applications".  These are not full service EDI applications.  However,
the
web services technologies can be adapted for private fee based networks
to
replace aging mainframes and COBOL code.

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

Re: [OT] FW: Sun Headquarter Briefings: Developing Web Services

[Berin Loritsch]

Geoff Soutter wrote:
> 
> Isn't Web Services basically just the EDI concept with a trendy new name?
> 
> Applications have been talking to each other across company boundaries since
> the 80's after all.
> 
> Just ask the car makers who've done all their purchasing, etc via "web
> services" for aeons ... :-)

This is true to a large extent.  There are two key differences though:  the
information is in a standard format (XML) which only requires a generic parser
to read, and the addition of automatic discovery of services.  Another key
difference is the emphasis on ubiquity.

I doubt Web Services will replace traditional EDI soon, but there are some
neat things that the Web Services approach allows you which EDI does not (at
least my _very_limited_ understanding of EDI).  The first thing is UDDI for
automatic publication and registration of services offered.  EDI typically
is set up on a company by company basis involving humans.  This approach
cannot scale to the extent that Web Services claims to (i.e. like HTML web sites).
The second is the standard markup definition used for data exchange.  By using
XML, a company can choose the XML parser based on performance and load criteria
(something that EDI can't offer alot of choice in).

Web Services is the next big idea for a smart web where things just "work".
One way I can see this take off is in a "smart kitchen".  Imagine if you will
the kitchen of the future where the refrigerators and cupboards keep track of
inventory and order groceries to be delivered on a "Just in Time" basis.  This
of course would be first adopted by professional establishments, and then find
their way into everyday homes.  The scenario outlined above also buys into the
embedded market in what they preach.  It is a "realizable dream" in that it
can be done with today's technology--the business side of things has to be worked
out though.

Web Services do have potential beyond what EDI preaches--and it is in small services
that can be combined into a larger service.  This is in contrast to one large 
transaction
with one party.  The interesting twist to Web Services is that you can change the
players that make up compound service without affecting the logic of the service.

> 
> Geoff
> 
> - Original Message -
> From: "Jon Stevens" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, August 09, 2001 1:23 AM
> Subject: [OT] FW: Sun Headquarter Briefings: Developing Web Services
> 
> > Can someone explain to me what the heck "web services" are so that I can
> > decide whether or not this is even worthwhile to learn about?
> >
> > 
> >
> > I'm guessing it is fancy marketing foo about SOAP/XML-RPC or it is about
> how
> > to build a website with JSP.
> >
> > -jon
> >
> > -- Forwarded Message
> > From: Ann Wilkins <[EMAIL PROTECTED]>
> > Reply-To: Ann Wilkins <[EMAIL PROTECTED]>
> > Date: Wed, 8 Aug 2001 07:08:00 -0700 (PDT)
> > Cc: [EMAIL PROTECTED]
> > Subject: Sun Headquarter Briefings: Developing Web Services
> >
> > Dear Developer:
> >
> > Judging from all the recent announcements in the industry, Web services is
> > clearly the next big thing.
> >
> > Sun Microsystems, Inc. invites members of the development community to
> > attend a one day Sun Headquarter Briefing on "Developing Web Services".
> > This Briefing is scheduled for Thursday, September 6, 2001.
> >
> > At this briefing, developers will receive first-hand information from the
> > very people who are working with this new generation of web services.
> > Developers will also learn how to start developing web services today.  In
> > addition, this briefing will attempt to clear the fog on web services
> > development including steps in the process such as design, create,
> assemble,
> > publish, and deploy.
> >
> > For more information or to register for the Briefing, go to:
> >
> > http://sdc.sun.com/briefings  or call:  1.800.795.7578
> >
> > PLEASE NOTE:  When you register on-line, please be sure to click the check
> > box on the upper left-hand of the description.
> >
> > See you at the Briefing!
> >
> > Ann Wilkins
> > Sun Headquarter Briefings
> > Phone:  +1-408-635-0854
> > Email: [EMAIL PROTECTED]
> >
> >
> >
> > -- End of Forwarded Message
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

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

Re: [OT] FW: Sun Headquarter Briefings: Developing Web Services

[Berin Loritsch]

Umar Syyid wrote:
> 
> Hi Berin,
> 
> Berin Loritsch wrote:
> > The compelling example that was given in WSDJ was a very simple web service to
> > find out how much any book from Borders would cost in any currency.  The cool
> > part of SOAP and therefore WS is the support for transactions.  You can compose
> > larger WS from smaller ones.  The example used two existing WS--one from Borders
> > that returns the price of a book (specified by ISBN number) in US currency, and
> > one that converts from one currency to another with the current exchange rates.
> > The web service that was written took markup that specified the ISBN number and
> > the resultant currency type you wanted.  The web service would create a transaction
> > that spanned the two other WS calls.  First it accessed Border's WS and got the
> > US price.  Then it accessed the exchange rate WS to find the price according to
> > the desired currency.
> 
> When you say transaction here, are you using the term in the technical
> sense?

Yes.  The transactions are part of the SOAP protocol along with security
constraints.  Please check the SOAP docs for more info.

> How does the transactional context propagate across varying resource
> types? For example, if one web service is executing an EJB
> implementation how do web services help the transaction to cross
> boundaries to COM+ objects running under MTS? Are web services a better
> integration technology then what exists today? Has someone built
> products that address cross app server interoperability concerns such as
> the one I mentioned above? Or are web services meant to be used only as
> a simple data exchange mechanism?

The transaction mechanism is in the protocol.  The underlying implementations
do not change the mechanisms in the protocol.  This means that you can have a
web service that uses EJB, that uses a web service using DCOM, that uses a
service using CORBA.  The SOAP protocol is able to specify when a request
failed and the calling service then can "rollback" all the changes it made.

Basically SOAP has become your Transaction Authority.

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

Re: [OT] FW: Sun Headquarter Briefings: Developing Web Services

[Berin Loritsch]

Jon Stevens wrote:
> 
> on 8/8/01 9:59 AM, "Berin Loritsch" <[EMAIL PROTECTED]> wrote:
> 
> > All the stuff I've read about for WebServices comprise
> > UDDI, SOAP, and WSDL.
> >
> > The three combined provide a way to automatically discover remote resources
> > that my webapp can use and then actually use it.
> 
> I'm surprised no one has mentioned JXTA. Where does that fall into this web
> services picture?
> 
> <http://www.jxta.org/>

The nebulous definition of a Web Service is:

"A dynamic web resource designed to be accessed and used by applications."

The key part here is "used by applications".  If you incorporate pieces of
www.jxta.org into the picture--then that is how you defined your Web Service.
The tools commonly agreed upon (according to the premier Web Services Developer's
Journal [WSDJ] that was included with the next to last JDJ issue) are UDDI, SOAP, and
WSDL.  Another part that is required is Schema support (but you knew that already
because UDDI, SOAP, and WSDL either require it or provide methods of specifying it).

The compelling example that was given in WSDJ was a very simple web service to
find out how much any book from Borders would cost in any currency.  The cool
part of SOAP and therefore WS is the support for transactions.  You can compose
larger WS from smaller ones.  The example used two existing WS--one from Borders
that returns the price of a book (specified by ISBN number) in US currency, and
one that converts from one currency to another with the current exchange rates.
The web service that was written took markup that specified the ISBN number and
the resultant currency type you wanted.  The web service would create a transaction
that spanned the two other WS calls.  First it accessed Border's WS and got the
US price.  Then it accessed the exchange rate WS to find the price according to
the desired currency.

That relatively simple example demonstrated why the WS concept is so powerful.
The biggest thing is that this is all done from within applications.  Your
front end can be a web page, or a standalone app.  They would both function
identically--just with different user interfaces.  In fact, you can add your
own web service that uses this example, and will bring up a list of ISBNs and
the cost from a Title.

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

Re: [OT] FW: Sun Headquarter Briefings: Developing Web Services

[Berin Loritsch]

Sam Ruby wrote:
> 
> Jon Stevens wrote:
> >
> > Can someone explain to me what the heck "web services" are so that I can
> > decide whether or not this is even worthwhile to learn about?
> >
> > 
> >
> > I'm guessing it is fancy marketing foo about SOAP/XML-RPC or it is about
> how
> > to build a website with JSP.
> 
> WebServices == SOAP is a good first order approximation.

All the stuff I've read about for WebServices comprise
UDDI, SOAP, and WSDL.

The three combined provide a way to automatically discover remote resources
that my webapp can use and then actually use it.

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

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

Re: Loggers, loggers, all over the place

[Berin Loritsch]

Conor MacNeill wrote:
> 
> > FACT: Jog4J supports JDK 1.1.x and higher,
> > while JogKit only supports JDK 1.2+, and JDK 1.4 logging is only
> _officialy_
> > available in JDK 1.4.
> 
> Not terribly interested in Loggers, but I think I might need a JogKit.
> Actually I've got a bit of a mainframe, will Jog4J RUN :-)
> 
> I think you may have typed Log too many times !

I agree!  Keep in mind that Jog4J doesn't RUN, it jogs.
That was a good catch ;P

(ok, so I lied about the last post being my last).

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

Re: Loggers, loggers, all over the place

[Berin Loritsch]

Cedric Berger wrote:
> 
> Tal Dayan wrote:
> 
> > We plan to add a logger to one of our products and we are not sure
> > which one to use.
> 
> If you want to try the JDK 1.4 logging for older JDK:
> http://www.javelinsoft.com/jlogger/

Too bad I can't use it with JDK 1.3 (check Ceki's new critique regarding
that issue).  I wonder how long this exists before Sun sends a "cease and
desist" letter...

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

Re: Loggers, loggers, all over the place

[Berin Loritsch]

Cedric Berger wrote:
> 
> Ceki Gülcü wrote:
> 
> > Cedric,
> >
> > Please see
> >
> > http://jakarta.apache.org/log4j/docs/critique.html
> >
> > and
> >
> > http://jakarta.apache.org/log4j/docs/critique2.html
> >
> > before jumping to conclusions. Regards, Ceki
> 
> Great, thanks for posting that new (critique2) information!
> (I already read the old one)
> And thanks for getting involven in making the 1.4 API better!
> 
> But this makes my point stronger: JDK 1.4 is a good API,
> and telling people to "stay away from it" (from Berin and Jon
> messages) is stupid and irresponsible.

I would advise anyone to stay away from an unreleased JDK--as
has been demonstrated here too many things are up to change.
If you coded your app against the initial JDK1.4 logging proposal,
you would have to make changes.  This is not cool--but that is
the risk of using unreleased code.

My advice now, as previously is stay away from JDK 1.4 logging
until it is fully released.  The API is subject to change.

BTW,
Calling people "stupid and irresponsible" when you assume you
have all the facts is pretty inflammatory.  Have some respect
for some hard workers--who know more than a little bit about
what they are saying.

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

Re: Loggers, loggers, all over the place

[Berin Loritsch]

Tal Dayan wrote:
> 
> Recently I saw an Avalon announcement regarding a logger kit. Is this is
> related in any way to the Log4J project ? If not, what are the key
> differences between the two ?  And while we are on the subject, what
> are the differences between these two and the Sun logging API ?

Log4J, LogKit, and JDK 1.4 Logging are all different APIs.  They are of
varying quality and complexity.  You will find that many concepts are
shared between LogKit and Log4J.  JDK1.4 Logging is considered by many
to be an experimental logging infrastructure because it has not had the
benefit of hard use in actual released software.  It takes a couple
iterations of an API to get it right, and Sun foolishly decided to include
the API without the real world testing and feedback.  Almost all the other
APIs they included with JDK 1.4 have been released first as a separate
project--something that would have benefitted JDK 1.4 Logging.

That really leaves you with LogKit 1.0b4 and Log4J 1.1.3.  These two
logging appplications are becoming more and more similar as the days
pass (whether the authors are aware of it or not).  The difference
between the two is largely the concepts they were built on.  You will
find better documentation for Log4J, and probably a larger group of
people who use it.  The LogKit team give special attention to server
side issues beyond simple application logging.  Those server side issues
include reliability, security, and atomicity--along with performance.
This is not to insinuate that Log4J ignores those issues, but it's
primary focus on application logging rather than server logging.


> We plan to add a logger to one of our products and we are not sure
> which one to use.

Hopefully the information presented here will help you.  I would stay
away from JDK1.4 logging, and use either LogKit or Log4J which are of
equal quality--but slightly different focuses and underlying concepts.

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

Avalon Framework 4.0 Released

[Berin Loritsch]

Avalon Framework 4.0 Released
-
 The Avalon team is proud to announce the 4.0 final
 release of the Avalon Framework.

About Avalon

 The Avalon project is Apache's Java Server Framework.
 It is separated into six sub projects: Framework,
 Excalibur, LogKit, Cornerstone, Phoenix, and Testlet.
 Its purpose is to simplify server side programming
 for Java based projects. It formalizes serveral
 best of breed practices and patterns for server side
 programming.

For more information about Avalon, please go to
http://jakarta.apache.org/avalon

About Avalon Framework 4.0
--
 The Avalon Framework formalizes the contracts and
 patterns used in the other Avalon projects. It is
 derived from modern software engineering techniques
 and aims to provide a solid basis on which to build
 server products.

For more information about Avalon Framework 4.0, please go to
http://jakarta.apache.org/avalon/framework

ChangeLog for Avalon Framework 4.0

*)  Added new method to Component Manager and Selector
 for discovering if a Component exists inside or not.
 Also augmented the default versions with the basic
 implementation to discover them. [BL]

*)  Added stylesheet to convert Stylebook markup to
 DocBook markup. [BL]

*)  Changed the documentation build process to use Cocoon
 to build the site. [BL]

*)  Added new "Developing with Avalon" book in DocBook
 format. [BL]

*)  Added Executable interface to activity package. [PD]

*)  Updated Resolvable interface to allow a ContextException
 to be thrown on failure. [PD]

*)  Add a makeReadOnly() method to the default implementations
 of Configuration, Context and ComponentManager.
 Calling this method after the respective object
 has been filled will make the object read-only. This
 is a safety precaution to stop code performing unwanted
 operations. [PD]

*)  Updated the javadocs of many of the classes. [PD]

*)  Update documentation so that it is more accurate
 and descriptive. [BL]


Downloads for Avalon Framework 4.0 available at 

http://jakarta.apache.org/builds/jakarta-avalon/release/framework/latest

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

Re: Attachments Deleted by MailScan!

[Berin Loritsch]

"Pier P. Fumagalli" wrote:
> 
> Avi Cherry at [EMAIL PROTECTED] wrote:
> 
> > Looks like we just got a copy of the new Outlook Trojan horse.
> > Shields up, everybody.  At least if you run Outlook and are dumb
> > enough to double-click on random attachments in your emails. :-)
> 
> There was no attachment (thank god) and the user has been unsubscribed.

I received a coupld of emails with the subject labeled "1-NEEDS AND WANTS TONESCALE 
TAB"
or "1-NEEDS YOUR HELP" both had attachments of the type ".xls.pif".  In the
case of the "NEEDS YOUR HELP" variation, I emailed the original sender asking
him to repackage it in a text file.  The results where that the mail was from
a virus.

All I can say is don't open any MS attachments.  And keep all communication
on the lists Text only.  Anything else should be ignored.
 S/MIME Cryptographic Signature

Re: What are we doing in regards to JDK 1.4?

[Berin Loritsch]

Jon Stevens wrote:
> 
> on 6/20/01 2:33 PM, "Berin Loritsch" <[EMAIL PROTECTED]> wrote:
> 
> > I have been looking through JDK 1.4, and there are a few
> > instances where what is included in the JDK steps on some
> > of our projects.  Most notably:
> 
> Turbine has this problem in a great degree. For example, we wrote a JDBC
> Connection pool about 3 years ago. Now, JDBC has an interface and whole
> system for creating a Connection pool. Personally, I think that it's
> implementation is bad OO design because they overloaded the use conn.close()
> to release the connection back to the pool in order to maintain backwards
> compatibility easily without having to modify existing code. Sure, it makes
> a good business case for existing code, but 10 years down the line, people
> will wonder why close() also returns a connection to the pool. Long term
> considerations were simply not made. :-(

It has an interface--but I have yet to find any documentation that allows
me to get a handle on the DataSource object in the client drivers.  It wants
you to go through a J2EE server--but what if you are writing the server?

Avalon has pooling code as well, modeled after the JDBC methodology.  I don't
think that JDBC 3 will obviate the need for custom pooling techniques.

> This problem is only becoming more and more apparent and important as more
> and more people's excellent OSS code becomes obsolete or "questioned"
> (because it is not "standard") literally overnight. It is nice to see that
> others are now starting to get bitten by this as well. :-)

It's not nice.  I work mostly with Avalon, and we have been pretty protected
up to now.  Although with JSR-111 on the horizon, it will hit Avalon square
on the shoulders.  I am involved with that effort so it is in my best interest
to champion the way Avalon does things.

However, when the "standard" sucks like JSR-42 logging, why use it?

> For example, I also have to deal with people like Craig constantly bringing
> up the fact that Struts is more "J2EE Compatible" (and therefore better in
> his eyes) than Turbine even though Turbine has had the same exact features
> for years now and they have been well used, well liked, and well tested.
> Probably more so than existing J2EE code.

My biggest complaint with it is that there is nothing that tells me exactly
what it is trying to accomplish.  That and the fact that it has been a moving
target with the API.  Cocoon had to alter their hooks into Struts JDBC pooling
a few times.  But that's water under the bridge.

> Next year, you might hear him and others saying that Log4J or ORO or Regexp
> (which is included in Catalina) or Avalon isn't J2EE Compatible because they
> don't follow the specifications that Sun releases.

Hopefully you're off the mark there.  The danger is in J2EE next-gen standards.
There are some serious holes in J2EE that I don't like--and want to change.

> One could bring up the OSS argument and say that the code in the JDK isn't
> OSS and therefore isn't worth using the API's, but that gets nullified as
> soon as Sun decides to OSS the code or someone realizes that IT managers
> don't listen very well.

The fact that the code is in the JDK means that the API is not going to change
drastically.  This is a major plus for IT managers and programmers.  The fact
that it is a standard also means that questions about it's longevity are removed
from the pointy-haired boss.  In my company, we have deviated from the standard
and used another product when that other product suited our needs better.

> Also, where do you draw the line? I know that JDBC has been around forever
> and everyone agrees to use it, but what if we had some special way of
> abstracting out talking to the database and suddenly JDBC came along and
> usurped whatever we had used before? Same problem...

It's somewhat different.  JDBC is a standard that all DB vendors can rally around
and ship drivers for.  A consortium of them have been trying to push an alternative
called JSQL or something like that--but people stick with JDBC.

> One can also spend many hours working for Sun for free, to try to convince
> the super powers that their code is better than Sun's code or that Sun and
> the JCP are doing something wrong in the API, but you end up having to
> battle with the needs of not only yours but whatever commercial pressures
> that Sun is under (look at their stock price as an example). You also get to
> battle with the spec leads individual preferences. This is what Ceki is
> doing with his Log4J. I'm sure that Daniel Savarese would be doing the same
> for his ORO package if he had the time and energy to spend on it.

This is true.  But put yourself in Ceki

What are we doing in regards to JDK 1.4?

[Berin Loritsch]

I have been looking through JDK 1.4, and there are a few
instances where what is included in the JDK steps on some
of our projects.  Most notably:

java.util.logging
-
Ceki has already made us aware of that and listed his
greivances.  I am not happy with the official JDK logger
myself.


java.util.regex
---
This steps on the toes of both jakarta-regexp and jakarta-oro.
In fact by its existence in the JDK, the Apache projects will
either loose mindshare, or remain static in their mindshare.

java.util.prefs
---
This somewhat affects jakarta-avalon in the configuration
APIs.  The JDK configuration elements are more cumbersome
and complex, so there may be a continued use for jakarta-avalon's
configuration API.
 S/MIME Cryptographic Signature

Re: The Lie

[Berin Loritsch]

Peter Donald wrote:
> 
> At 10:03 AM 6/7/01 -0400, Berin Loritsch wrote:
> >Alex Fernández wrote:
> >
> >> I read 12 fallacies and flaws in 5 sentences:
> >> 06- "in the public domain" was the term used 20 years ago for open
> >> source. Not useful any more.
> >
> >Not entirely accurate.  Public Domain is a copyright law term referring to a
> >published work where the copyright has expired OR the author chose to waive
> >their copyright.  While it is true that there were several freely available
> >source code distributions that were in the public domain, but they had no
> >protection.
> >
> >A work in the public domain cannot have any license or protection under the
> >law.  This means anyone can use the work, and make dirivitive works on it
> >without consequence or ramifications.  It also means that you can strip the
> >original author's name from the source code and put your own there--nothing
> >the author can do.
> 
> IMHO there is a far worse characteristeric of PD works. Usually
> opensource/free-software has a disclaimer clause in license (ie the don't
> sue me if the program screws your computer clause). Because users of the
> program accept the license (or else they couldn't use program/source), this
> gives the developer protection. They can't be harmed if a bug in their
> software causes damage to a system.

This will be my last post on the subject, but this is also a misnomer.
Public Domain works are open to all without license or warranty.  They
cannot have any license or warranty due to the nature of public domain
as a whole.

If you use public domain code, and it screws up your system, there is
no one to prosecute except yourself.  The reason being is that once a
work enters the public domain, there is no guarantee that the copy of
the work you have is the original.

This is especially true in the USA where a copyright lasts 50 years after
someone dies (only for works copywritten after 1971).  If a work has
gone into public domain at this point, not only is the code archaic, but
there is no one alive to help you out anyway.

Basically Public Domain works are completely unprotected in every way shape
or form, and their use is also unprotected in every way shape or form.
That is why it is best to have a license of some sort.

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

Re: The Lie

[Berin Loritsch]

Alex Fernández wrote:

> I read 12 fallacies and flaws in 5 sentences:
> 06- "in the public domain" was the term used 20 years ago for open
> source. Not useful any more.

Not entirely accurate.  Public Domain is a copyright law term referring to a
published work where the copyright has expired OR the author chose to waive
their copyright.  While it is true that there were several freely available
source code distributions that were in the public domain, but they had no
protection.

A work in the public domain cannot have any license or protection under the
law.  This means anyone can use the work, and make dirivitive works on it
without consequence or ramifications.  It also means that you can strip the
original author's name from the source code and put your own there--nothing
the author can do.

Open Source Software does NOT waive the copyright priviledges, nor does it
waive the ability to publish the work with a license.  The reason Open Source
Software came into existence is to have all the advantages of Public Domain,
without the disadvantages.  People _like_ ensuring they get the recognition
for good code.

Richard Stallman's rendition of Open Source is Free Software.  This notion
is separate and distinct from *both* Open Source AND Public Domain.  He does
have a rather socialistic view on software as a whole, despite his denial of
such.  The GPL is not compatible with a number of Open Source licenses that
seek to protect Recognition of the author or organization that produced the
software (read Apache Software License and original BSD license).  To me
this is bad.

> 08 - "Linux is not in the public domain", so what? Straw man forever.

This statement is never truer.  Linux is not public domain, it is protected
by copyright law, as well as the GPL distribution license.  All licenses have
a price--though not always measured in money.

> 12 - Kant's Golden Rule -- suppose everyone does what Ballmer tells us
> is so bad, use GPL licences, do you see any bad consequence for mankind?
> What would it be?

If everything were GPL, nothing would be in violation of GPL.  All software
would have source code available.  These are good things.  The bad is when
you mix software with different licenses.  That is where conflict arrises.
Because the GPL is purposely vague in key terminology such as what is a
"derivative work", there is a legitimate perception that any code that uses
GPL code either as a basis, or as a plug-in would force the license to change.

IMO this is not the best of all worlds.  I appreciate Richard Stallman's goals,
and his desire to see all software free (according to his definition).  However,
there are other tools beside the GPL that ensure open software that is compatible
with commercial licensing (read Apache Software License and original BSD license).

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

Avalon Beta 3: Showstopper Fix.

[Berin Loritsch]

The Avalon team announces the beta 3 release of Avalon
Framework and Excalibur 4.0. This release includes a serious
bug fix in Excalibur's Component Management infrastructure.
If you have downloaded Avalon 4.0 beta 2, then you are
encouraged to upgrade. The bug only affects users of the
ExcaliburComponentSelector.  

Avalon
--
http://jakarta.apache.org/avalon

The Avalon project is Apache's Java Server Framework. It is
separated into six sub projects: Framework, Excalibur, LogKit,
Cornerstone, Phoenix, and Testlet. It's purpose is to simplify
server side programming for Java based projects.  It
formalizes serveral best of breed practices and patterns for
server side programming. 

Avalon Framework 4.0 beta 3
---
http://jakarta.apache.org/avalon/framework

Avalon Framework is the core of all of the Avalon projects,
and formalizes all the contracts and patterns used within all
Avalon compliant projects. 

Avalon Excalibur 4.0 beta 3
---
http://jakarta.apache.org/avalon/excalibur

Avalon Excalibur contains several premade Avalon Components
and utilities to make your server side programming easier.
There are several pool implementations, Component management
implamentations, and database management implementations.

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

Re: doinking around with a logo

[Berin Loritsch]

bill parducci wrote:
> 
> kicking around the apache web site i noticed that jakarta uses the basic
> apache logo. since many of the projects seem to have their own logos i
> figured i would give it a shot to see what i came up with. here is what
> i did:
> 
> http://www.pier64.com/jakarta.jpg
> 
> if nothing else, i would be interested to see what anyone may think
> about it.

I think it's kool

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

Avalon Beta 2 Released

[Berin Loritsch]

The Avalon team are proud to annound the beta 2 release
of Avalon Framework and Excalibur 4.0 and Avalon LogKit 1.0.
This release includes bugfixes and more current documentation. 

The Avalon project is Apache's Java Server Framework. It is
separated into six sub projects: Framework, Excalibur, LogKit,
Cornerstone, Phoenix, and Testlet. It's purpose is to simplify
server side programming for Java based projects.  It
formalizes serveral best of breed practices and patterns for
server side programming. 

Avalon Framework 4.0 beta 2
---

Avalon Framework is the core of all of the Avalon projects,
and formalizes all the contracts and patterns used within all
Avalon compliant projects. 

Avalon Excalibur 4.0 beta 2
---

Avalon Excalibur contains several premade Avalon Components
and utilities to make your server side programming easier.
There are several pool implementations, Component management
implamentations, and database management implementations. 

Avalon LogKit 1.0 beta 2


Avalon LogKit is a logging toolkit designed for secure
performance orientated logging in applications. It is the
logging toolkit used in all of Avalon's projects.

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

Re: FW: Velocity and Avalon

[Berin Loritsch]

Peter Donald wrote:
> 
> Here is a prime example of someone using an alpha product whichs explicitly
> stated "the developer team is not investing _any_ effort in providing back
> compatibility between alpha releases". And when it changes they are ...
> what ... shocked? If they are, then they shows a decided lack of
> intelligence.

Peter, you could have left off the last sentence, it is only inflamatory.

However, Velocity gambled on the API, it changed from its Alpha form
to its Beta form.  The Beta API is the stable API, and deprection will
be used from that point.

> 
> At 12:19 PM 5/20/01 -0700, Jon Stevens wrote:
> >Here is a prime example of why deprecation is important.
> >
> >-jon
> >
> >-- Forwarded Message
> >From: steve <[EMAIL PROTECTED]>
> >Reply-To: [EMAIL PROTECTED]
> >Date: Sun, 20 May 2001 12:29:52 -0400 (EDT)
> >To: [EMAIL PROTECTED]
> >Subject: Velocity and Avalon
> >
> >Hi,
> >
> >I'm trying to use Avalon with Velocity and I've
> >run into a version conflict in the logger.
> >
> >I have Avalon 4.0b1 ...
> >
> >I see that Velocity uses the Avalon logger by
> >default and I haven't changed that, but it looks
> >like it must be an older version.  Can I simply
> >replace the logger in Velocity with the newer
> >version? ...any other tips?
> >
> >Thanks,
> >
> >Steve
> >
> >PS:  I had sent a "newbie" question out last week
> >about suggestions on the best way to integrate
> >a DB component into a Velocity servlet.  I looked
> >at Turbine but in the end decided that it didn't
> >really suit my needs.  I did discover that Avalon
> >would provide me with some very useful
> >components.  Thanks to all who responded.
> >
> >
> >-- End of Forwarded Message
> >
> >
> Cheers,
> 
> Pete
> 
> *-*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof."   |
> |  - John Kenneth Galbraith   |
> *-*
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

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