Re: Differences between Structs and Turbine ???
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 ???
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Differences between Structs and Turbine ???
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [IMPORTANT] What actions can the ASF take to enforcecopyright?
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: Maven is growing
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Maven is growing
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Maven is growing
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: Scarab (was RE: [ANN] in-house mail archive...)
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Centaven and Friends (was Re: You make the decision(was Re: Quick! convert all your projects to maven!))
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Centaven and Friends (was Re: You make thedecision(was Re: Quick! convert all your projects to maven!))
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: You guys are so funny.
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: You guys are so funny.
[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.
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Database Subproject Discussion : creation of DBCommons ?
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jakarta subproject scope (was Re: Quick! convert all your projectsto maven!)
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Reality Check (was Re: Quick! convert all your projects to maven!)
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: GUMP RULEZ WAS: Re: Quick! convert all your projects to maven!
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? /Steven (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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: subproject layout conventions
-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
-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
-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: subproject layout conventions
-Original Message- From: Leo Simons [mailto:[EMAIL PROTECTED]] another lenghty post, so I'll start with a summary: - color variations (and all other lf changes) should be part of the original look-and-feel design. Giving programmers free reign to do this spells disaster. It would be best to have the original designer of a look and feel work this out. Very strictly. :( Seriously, I don't dig the big blue background. 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 is not enough, and neather is the strict maven style site. But both together will provide a good balance. Another issue is the ever recurring
RE: LICENSE in .jar files
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: mailto:general- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- 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: 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]
Printable pages
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Printable pages
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]
RE: Printable pages
In that case, the entire Jakarta site needs to be redesigned. It makes use of embedded tables and font elements. It does not use CSS at all. 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 link tag to have a printable stylesheet... This is what Scarab does... link rel=stylesheet type=text/css href=/scarab/style/print.css media=print / -jon -- 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]
RE: Printable pages
-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 font 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]
LogKit 1.0.1 Released
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
The Avalon team is proud to announce Avalon Excalibur 4.1
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: More abuse of coding styles...
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: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Newsletter
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Standard Change Log and ToDo
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Standard Change Log and ToDo
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 task name=Action info pUnit tests for the codeorg.apache.struts.action/code package./p /info assigned a href=mailto:[EMAIL PROTECTED];Rob Leland/a /assigned /task 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] . -- 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]
The Avalon Team is proud to announce Avalon Framework 4.1
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comment for Apache.org
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Distributing the JSSE
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- 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)
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: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: License Question (JDBC 2 vs. JDBC 3)
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]
Avalon Phoenix 4.0a1 Released
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]
Standardizing build.xml files
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: Standardizing build.xml files
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]
Re: [OT] $un, M$ and Java
Kevin A. Burton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Stevens [EMAIL PROTECTED] writes: http://news.cnet.com/news/0-1003-200-6839693.html?tag=mn_hd snip 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
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
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] FW: Sun Headquarter Briefings: Developing Web Services
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? http://sdc.sun.com/briefings/agenda.cgi?eventkey=5100 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
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
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? http://sdc.sun.com/briefings/agenda.cgi?eventkey=5100 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: [OT] FW: Sun Headquarter Briefings: Developing Web Services
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
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: Loggers, loggers, all over the place
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
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]
Avalon Framework 4.0 Released
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!
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
What are we doing in regards to JDK 1.4?
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
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]
Re: The Lie
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]
Avalon Beta 3: Showstopper Fix.
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
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
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]
