Re: jcs
I'm sure JCS would be much more widely used if we got out a release. Right now, the major impediment is that users have to build it themselves. If we had a release, more sample applications and further For a long time I hoped a release could be avoided until after the JCache JSR was at least in public draft form and we could decide if we wanted to use their API. However at this point I can only assume that JSR is completely dead so it may not be a realistic concern. -- jt (who doesn't care where JCS 'lives') - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Maven as a top-level apache project]
As far as L/GPL jars go that's not something Maven controls. Projects state their own dependencies and if an Apache project is violating Apache policies how is that Maven's problem? If it was an Ant build that used the get/ task to link in an L/GPL jar is that Ant's problem? Obviously not. So, assuming[1] for the moment that LGPL jars can not be imported into ASF code: Can we agree that 1. It is not allowed for Maven or any of its plugins which are licensed to import (L)GPL code 2. Plugins distributed under a different license and distributed from a non ASF location could have such dependencies without creating difficulties for the ASF. For example, a checkstyle plugin with the same license as checkstyle and hosted at sourceforgot. (For any who do not know, plugin installation and resolution in maven is a completely runtime activity) 3. Projects which use Maven can explicately declare a dependency of (L)GPL code and maven can download the dependency artifacts and build the project without causing difficulty for the ASF. (Maven should be able to build projects which are themselves GPL right? Ant certainly can). Thanks, James .. [1]: Hopefully I am not the only person who disagrees with this decision, but I understand if the ASF is not willing to take a legal stand on the import == #include issue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Forum Software for Jakarta?
Note the wiki isn't for that purpose or I'd agree with you. Its for creating documentation (something we are still lacking in). I hate it for the purpose of discussion, preferring mail lists for that, and the talking points summed up (I hate searching through 6 years of archive to I'm a big fan of http://c2.com/cgi/wiki?ThreadMode, great for distilling discussion into document content since the refactoring is naturally iterative. find out why a particular decision was made)... Note that the wiki is also not for the pretty stuff. Once the wiki generates a page worth formalizing, it should be dumped into XML (IMHO) for convenient transform. Ugh, turning a succinct readable format like wiki markup into XML? What a shame. (insert plug for reStructuredText here) -- jt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [discussion] jakarta-gump as community property
On Thu, 2002-12-19 at 12:21, Sam Ruby wrote: Gump is now two years old. It has had contributions from over a dozen people, about a half-dozen this month alone. There seems to be a renewed interest in gump (some in response to a little nudging grin). Considering all of this, what I would like to propose is that the contents of jakarta-alexandria/proposal/gump get moved to jakarta-gump, all committers to any jakarta code base be given karma and voting rights on the full contents (descriptors, code, and stylesheets alike) and that a single [EMAIL PROTECTED] mailing be created (we are all devs here, right?) Thoughts? Yes! Big +0 with the emphasis on the + ( Not that I am a big fan of gump, but moving out of the proposal area can only make it better! =) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Short Apache licence for source files
- things being 'easier' when being a member: of course not, and I hope that wasn't the impression that I gave The message I was trying to get across was that the firewall a.k.a. barrier between members and committers exists mostly in people's minds. Membership is not much more than a recognition of one's work plus a stamp of approval for being usually reasonable. Think of membership as even more positive karma in slashdot. From the Foundations perspective membership also entails responsibilities and obligations but that's a different topic. It is a real barrier in that things seem less opaque for members. You can tell people that nothing important happens on the members only lists, but as long as there _are_ members only lists and such, the firewall will always be percieved. -- jt, observing not complaining. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Short Apache licence for source files
I thought that we were also supposed and even encouraged to think for ourselves. No one has suggested to defy the board. I resent the shut- -up-and-do-as-you-are-told attitude which does not characterize you, the ASF, nor anyone on the board. What is going on here? Indeed, this attitude is more than a little upsetting. The board may not have any legal obligation to us committers who assign our code to the foundation, but courtesy demands some explanation for their actions and decisions. Sure, the decision is the final word, but for us to be able to ask why? is vital to maintaining the trust/comfort relationship between the authors of the code and the owner. -- jt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Sun Is Losing Its Way
The Question I have for everybody here is does anyone have any interest in Porting any of the other jakarta projects to C# so that they may be able to run on Mono/Linux/windows .Net/Micorsoft ? what this sppose to mean ppl, why want you to support C#! Sticky issue, but from one perspective you could say that C# / CL* have more potential to be an open platform than java at the moment, considering that Microsoft has submitted most of the base platform to ECMA, while Sun still has a strangle-hold on Java... ok, if so, then long live Mr.Miscro$of and make me suffer for paying you extra money for buggy software :( by the way, don't forget to change it from Apache Software Foundation to .Net Apache Software Foundation :P The foundation is platform and language agnostic already, they own / steward projects written in C / Java / Perl / Python / ... and that run on many many platforms. i will leave Apache system if you used any Micro$oft products. when you support Micro$oft you help in KILLING an open source project :'( To be fair, it may be possible to implement CL* version of various projects without using or requiring any Microsoft product. Especially the many useful server side components that live at Jakarta. You might look at NLucene as an example. I'd investigate the relationship between Microsoft and the pieces of the .NET platform before becoming too upset about this. You might be surprised (or I might be =) But really, as long as someone is interested in doing the work, more quality software that gives more people more options is not a bad thing. --jt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta Logo Committed
On Mon, 2002-11-04 at 08:45, James Taylor wrote: Perhaps you missed my warning that I would -1 this. Oh, to be clear, I'm in favor of a new logo, it just can't look worse than the current one which looks quite nice. (If my vote even counts on site stuff, I'm not sure) The font mismatch on The Apache vs the rest of the text is not good. Also, this is more blurry than the original logo. It my be a cut and paste of the original logo text, but you have applied some scaling which has blurred it -- always a problem when applying a transform after rasterizing text. The current logo is more pleasing to the eyes. If you want a new logo it should use a single font and be be cleaner than this. On Mon, 2002-11-04 at 08:32, Nicola Ken Barozzi wrote: I've committed the new Jakarta logo based on the one of www.apache.org in the jakarta-site2 CVS. I've reduced the smoothing on The Apache and added a trailing slash as requested on this list. This logo is lower in height to have more page space, smaller in kb, and clearly shows that Jakarta is an Apache project. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org
Re: New Jakarta Logo Committed
I changed the The Apache font to one very similar to the Jakarta Project one and deleted by hand the vertical anti-aliasing that was present, to mimic the same thing in the current logo. Does anybody know what the font in the original logo is? It is a common font that I am familiar with, but I can't remember the name... Tell me what you think, I hope we're getting nearer now. Yes! But I still think it looks a little odd. The weights and such aren't quite right. If someone knows what the original font is I can take a stab at recomposing and rasterizing it based on your new layout. (Not trying to make a big ordeal out of this, but let's get it right! =) -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org
Re: Differences between Structs and Turbine ???
On Wed, 2002-10-09 at 14:05, Jon Scott Stevens wrote: on 2002/10/9 10:40 AM, Daniel Rall [EMAIL PROTECTED] wrote: mod_python is looking more and more attractive to me all the time, a clever balance between the two. Not really. This is about as good as plain servlets. http://www.modpython.org/live/mod_python-2.7.8/doc-html/tut-pub.html Notice the HTML embedded in the .py file? There really isn't anything different between that and a servlet and isn't python slower than Java anyway? So, now we just go down the path of re-implementing everything we have spent years implementing in Java...I don't see the gain. For apples to apples: http://webware.sourceforge.net/ http://www.cheetahtemplate.org/ ( God knows why they went with a syntax almost but not quite exactly like velocity, but it is still pretty nice stuff ) +1 for python as a replacement for Perl scripts -0 for python as a replacement for Servlets =) -jon (who thinks Daniel is bitten by the python bug =) ) -- 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: Differences between Structs and Turbine ???
On Sat, 2002-10-05 at 19:36, John McNally wrote: This is not really the correct place, but a short answer is struts is jsp-centric while turbine attempts to be neutral on the actual templating mechanism. Given that most jsp developers gravitate to struts means you get the best support if using velocity within turbine. Struts most certainly has more users, but the turbine developer community is healthy. I'm pretty sure both will survive. Healthy as in active, but not always mentally healthy. You will occasionally hear turbine developers muttering things like the next version will support the struts action resolution mechanism or we need to support JSP as a first class templating option. It is at that point that you should run away. john mcnally On Sat, 2002-10-05 at 11:08, Dominic Gagne wrote: I hope I'm asking the right mailing list ... I'd like to know the differences between Struts and Turbine project. I'm currently using Turbine framework to build a web application and I see that Struts could offer me the same kind of solution, am I right ? I would also like to know which project in moving faster and has more chance the stay alive ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: localhost:8080 vs localhost???
I love how people spend more time getting bent out of shape because there is a wrong posting on an email list by a newbie and spend more effort refering them to the 'idiot' page than if they were to just help them out But the idiot page takes almost no effort at all. That's why it is so great, you can even setup a macro in your mailer to reply with that URL as a message, when you, say, see something that is not only on the wrong list, but is WELL addressed in documentation, FAQs, HOW-TOs mailing list archives, and all that... and politely remind them to next time redirect their questions to the proper list. Can't we all just get along??? My guess would be: no. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
My projects haven't come to a grinding halt. Only on general @ jakarta But this isn't about your projects, it is about the community, and the community is more important than the code. Do you even know why you are here? -Andy -- jt (who is afraid Pier will do a mailing list search on him and realize how little value he brings to the community =) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
while one of the major democracies of the world, the US, doen't surely have one of the highest turnouts. And a lot of people see that as a really bad thing. Turning in an empty ballot is one thing, but not going to the polls because you can't tear yourself away from 'Must See TV' is ignoring your responsibility as a citizen. -- jt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: new volunteer
starting points: maven: http://jakarta.apache.org/turbine/maven I think maven would definitely be interested in your help. We've had a lot of discussions about moving to docbook, and lots of us favor it but we've invested a lot of time in xdoc so far and don't really have the time to convert all the transformations and xdocs right now. The barrier will be the we are mostly using DVSL instead of XSLT. The only place XSLT is being used is for generating XSL:FO (where DVSL just doesn't cut it yet). So if that is something you are interested in, come on over! -- jt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Database Subproject Discussion : creation of DBCommons ?
On Thu, 2002-05-02 at 17:33, 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...) Thank god. 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. Anyone have any comments? I like this idea a lot. It would be great to bring together a lot of these different efforts and look at how they can work together. And you would finally have an excuse to bring poolman over (yay!). My only concern (and this is not meant as an objection) is that we be careful not to dilute/damage the projects we bring into it. OJB is an extensive and solid product on par with any of Jakarta's top level projects. A lot of people feel that torque is also of the same scale. They _can_ coexist, and work is already going on to have them work together in sensible ways and share code (the Torque query code which is moving to commons). I can see them, along with the common code they share, all our connection pools, and so on existing as a distinct organizational unit, but the key is co-existing. If we take a 'MERGE MERGE MERGE' attitude it could cause more harm then good. Merging is sensible sometimes, maybe we decide it makes sense to have only one or two connection pools rather than four, but maybe not. There is definitely room for more than one O/R mapper. But if they can share repetitive components and build community, that would be exciting! -- jt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: You guys are so funny.
Sam, I asked yesterday or the day before on this list what needs to be done. I'm waiting on you for a reply. I'm an active developer on maven. Yesterday we added the nag tags in that were requested. Actually (to keep everything honest) they didn't quite work out the way I expected and have been removed. Still looking at making that work though. -- jt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Quick! convert all your projects to maven!
Yeah, I love wading through GUMP's mess of ant build files, transformed xml, generated perl and shell scripts and such, all of which is barely documented at BEST. Especially when otherwise I'd have to spend that time on things that actually make my project better... Perhaps that's why (from a Maven guy perspective) centipede is so scary. It looks like that nightmare GUMP all over again. Two pages of documentation and a 1.0 beta release?! Bah! -- jt On Wed, 2002-05-01 at 08:33, Andrew C. Oliver wrote: Dude...you seriously need to get in line with GUMP. You want to make sure Maven works and works with other Jakarta stuff, well GUMP + Junit is The Answer. Trust me. I don't feel its sam's job to fix everyone's bugs for them. Sam's pretty good, but I don't think he's that good, I think the rumors of him being omnipresent are exaggerated. Though its rumored that he can be in Redmond, NC and Apache all at once ;-) (not a small feat). (so Sam is that worth those slides you promised?) I'll believe it when I see it here... http://jakarta.apache.org/builds/gump/latest/ - Sam Ruby -- 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!
How interesting, quite a few projects have managed to do it. Obviously we are far less competent, intelligent, or dedicated then those other projects. All things I am perfectly willing to accept as long as you don't make me look at GUMP again. more than it costs. Say I want to use Maven, but one of its dependencies turns out to be incompatible with something I'm using in my project. I think despite the really nice documentation that I'll find it a bigger pain if I can't use a version of a library that I want Just to clarify for the general audience, Maven does not introduce any of its dependencies into the classpath for a project it is building, thus there should be noe problems of this sort. Maven also allows your project to specify dependencies on a specific version of another project without trouble. There are still some kinks to work out with the repository and naming and auto downloading and such, but none of what is outlined here _should_ be a problem. http://www.martinfowler.com/articles/continuousIntegration.html Yes! All of us over in maven land are big fans of continuous integration. We were in discussion with the cruise control folks about working together, and are planning on integrating the best features from it into maven so that any project with a descriptor can immediately be set of for continuous integration (since maven supports version control and unit/integration tests out of the box, this is going to be quite easy (and fun!) to implement. -- jt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Quick! convert all your projects to maven!
I do. They aren't. Example: http://jakarta.apache.org/builds/gump/2002-05-01/jakarta-turbine-stratum.html Was built using http://cvs.apache.org/viewcvs/~checkout~/jakarta-turbine-stratum/jakarta-turbine-stratum.xml If nag entries were added to that definition, then perhaps people could be alerted to issues as they arise. Great idea Sam! I've added an optional nag entry to Maven's generated GUMP descriptor. I've updated the POMs for maven, turbine, startum, torque, and fulcrum. Hopefully we will see some nags the next time GUMP runs =] If these issues could be addressed, I would be a big advocate of Maven. Excellent! -- jt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Centaven and Friends blah blah blah
What do you think? I think that the sanest viewpoint that has been expressed in this thread is that both projects are young and need to incubate. Sure, one project definition format will be nice to have across apache someday, but were still working out the kinks and it's not obvious (well, except to us developers =) which is the better way to go. So, PROPOSAL, if you will... let's stop talking about this and get back to work and then readdress the issue when the projects are more mature. Both certainly need more effort. In mavens case: http://jakarta.apache.org/turbine/maven/tasks.html short term and http://jakarta.apache.org/turbine/maven/musings.html long term. I haven't seen anything similar for centipede but I hope documentation is at the top of that list because... I haven't seen anything similar. Looking forward to seeing the UML generation, happy to steal that if it turns out well. -- jt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [New Subproject Proposal] ObjectBridge
ObjectBridge is one of the most interesting, powerful, and complete O/R mapping projects out there. I would love to see it become a top level Jakarta subproject, so here is my emphatic (but non-binding) +1! -- jt On Mon, 2002-04-29 at 14:41, Jason van Zyl wrote: Hi, I would like to propose ObjectRelationalBridge (http://objectbridge.sourceforge.net/) as a top level subproject of Jakarta. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
You do not have to use an O/R layer that abstracts you away from the database you are using so much that it limits your ability to use the DB's functionality in something resembling a db-natural way. That is like trying to argue that using ECS is the way to write HTML. Sometimes it is. While these may not be accurate summaries, I hope you now do see that CrossDB and Torque are not, in the majority of use cases, alternatives to one another. I'm sorry. I don't see that. Torque can do everything crossdb can do and more. O/R mappers are not always appropriate. For example, in torque's case, when you are dealing with an existing database that was not generated by torque and does not have a structure that is appropriate to O/R mapping. I can see that in such a case having a mechanism to code SQL in a cross database way could be useful. There is room for tools of both sorts. Different levels of database abstraction are appropriate for different use cases. Hence, Village. (No stance on whether this should be a Jakarta project is implied by this message). -- jt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
