Re: [POLL] Future Of Turbine-JCS
robert burrell donkin wrote: On 12 Dec 2003, at 09:28, Henning Schmiedehausen wrote: On Thu, 2003-12-11 at 21:07, robert burrell donkin wrote: hi henning you don't need to be a committer to act as a mentor. from what i've heard, i'd say that you'd be an ideal candidate :) Hi, thanks. :-) I'm willing to subscribe to JCS for watching the developers there and help them getting out a release. We should try to get genuine interest from their side to push JCS ahead. it'll either have to go forward or go back. the pmc can't really allow it to drift any more. if there isn't any activity then we'll reluctantly have to think about taking action. what do you mean? the code works. it is used by other projects .. and basically development slowed down as the developers are waiting for the jcache spec ... so i don't think there is any problem as long as there are developers maintaining the code Just as you I'm currently spread out between a few hats but I'll try to squeeze in some time to help here. great :) i know that i've been pushing very, very hard recently but i really have the new year in my mind as a significant landmark. i'd really like to be able to face the new year with the major fundamental issues basically fixed. i'm certainly no willing to continue to be this stretched for much longer. i'm hoping that the current period is just a transitionary phase. i've been worried about oversight of turbine for some time (and i know some other people have as well) but JCS seems like it's the only real issue left (providing that turbineers are willing to serve on the pmc). if possible i'd like to see if we can't some kind of release (0.9?) out very soon and then push for promotion very soon in the new year. +1 martin - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
Andrew C. Oliver wrote: So far it sounds to me like JCS is only used by Turbine and that only the Turbiners really care about it. it is indirectly used by turbine ... that's why the discussion started ... it is used by torque, ojb, hibernate, ok, they are all db related .. but i still do not think jcs is db related .. Thus I don't see why it doesn't just get flattened into Turbine and just consider it one more turbine service. please go to the jcs site and RTFM However, if it DOES have a community or at the very least someone who loves cares and feeds it, then commons sounds like a reasonable place to build a community. As far as oversight, who on the PMC is on this sub-sub-subproject? i am From a Jakarta PMC perspective, I think that we should cease to support Sub-sub-projects with the exception of commons.* we should only support sub-sub project if there is a strong relation to the sub-project ... e.g turbine-fulcrum (avalon components for turbine) -Andy * before it is mentioned, on POI we call POIFS and HSSF subprojects but they're really just components. They're called subprojects by tradition, granted it is ambiguous but I'll leave language pedantry to RMS. ;-) what is the definition of a sub-sub project?? martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
Daniel Rall wrote: Henri Yandell wrote: On Thu, 4 Dec 2003, robert burrell donkin wrote: (i'm a little inclined towards db but) i'd support a proposal from the JCS team for a future in either db or jakarta (along the lines outlined above). guys - have you come to any opinions about what's the best option yet? My only worry with a Commons other than JC is that there's a lot less chance of community. AC and DC need communities to move to them, whereas JCS needs community and JC is the best place to get such a thing. Given Robert's description of his experience with the Incubator, I'm for the Jakarta Commons to gather some community (direct drop rather than sandbox route), with the goal of an eventual promotion to a full sub-project. - Dan +1 martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Future Of Turbine-JCS
[ ] leave it within turbine [ ] move it to apache commons [ ] move it to jakarta commons [ ] move it to incubator [ ] something else (please specify)... [1] move it to jakarta [2] move it to db from my point of view jcs should be a jakarta (or db) subproject. martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PMC VOTE] PMC Nominations
robert burrell donkin wrote: On Friday, February 14, 2003, at 12:26 AM, Sam Ruby wrote: Charles Burdick wrote: Selection criteria aside, I nominate Morgan for the PMC. Now that I think of it, let me just skim through the Jakarta-Announcements archive from various points last year. - Danny Angus - Peter Carlson - Morgan Delagrange - Pier Fumagalli - Ceki Gülcü - Dmitri Plotnikov - Phillip Rhodes To add to the list, I'd like to nominate these active committers: - James Strachan - Jason van Zyl - Ted Husted - Rod Waldhoff +1 martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Maven as a top-level apache project]
Steve Downey wrote: From: [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Thursday, February 06, 2003 8:07 PM Subject: Re: [Fwd: Maven as a top-level apache project] BTW, given the license discussions it seems unlikely a solution that includes all the jars in the same place will work. So the repository will be not only a storage for jars, but a set of tools to deal with downloading from different locations with different methods ( and mirror lists, etc ). Again - I think this part can only be apache-wide. Sure, but let's not lose focus of what this is for. Distribution? Building? A company/individual can set up their own repository of jars (we all do) that they've accepted licenses for. The 'tools' should be able to work with that set up, similar to how Maven does today. One thing that has annoyed me is that Maven will download jars from the ibiblio repository with no regard to the license of them. It's an easy way for jars to come into a build without formal review and acceptance of the license. My company's policy is to use only BSD, ASF, or similar licenses. No GPL. And based on recent discussions here, we may prohibit LGPL. We do also use commercially licensed software, and review carefully the redistribution clauses. It's particularly troubling that the jars show up without supporting documentation. why don't you setup your own private repository where you can control which jars are stored there ... you don't need to use the ibiblio repo martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRAFT2] Jakarta Newsletter - November 2002
could you please add the following section about turbine? thanx Martin Turbine == The Turbine Team released the final releases of Turbine 2.2 and Torque 3.0. A list of changes can be found on the web-site http://jakarta.apache.org/turbine/turbine-2/changes.html http://jakarta.apache.org/turbine/torque/changes.html The distributions are available at: http://jakarta.apache.org/builds/jakarta-turbine/turbine-2/release/2.2/ http://jakarta.apache.org/builds/jakarta-turbine/torque/release/3.0/ http://jakarta.apache.org/builds/jakarta-turbine/tdk/release/2.2/ Rob Oxspring wrote: Jakarta Newsletter == Issue: 5 Date: November 2002 Url: http://jakarta.apache.org/site/news/200211.html It has been a quiet month. Commons has killed on old component and welcomed a new one, while other components have kept up fixes, features and releases. Elsewhere there has been more discussion about the infrastructure and community at Apache, and an attempt to be helpful to those developers using IDEs As always, I want to thank those who contributed and hope that you enjoy the read. If you would like to comment further on any of the highlighted discussions then please do so on the appropriate list, if you want to comment on the newsletter itself then please point your comments to [EMAIL PROTECTED] Rob Oxspring Contents General Ant Commons Jetspeed Lucene General === Ideas, suggestions, and comments on the overall Jakarta project Editor: Rob Oxspring Andrew Oliver decided to do something about the Java developers who cut their teeth on IDEs and don't understand the intricacies of the command line tools that are used under the hood. The page [1] was welcomed by many and was rapidly expanded [2] and should hopefully be a resource useful to a wide range of developers. Duplicated or pointless import statements appear over time in most Java code. This is an issue that Tom Copeland wanted to tackle, and sparked a few iterations [3] of the bad imports report [4]. [1] - http://archives.apache.org/eyebrowse/BrowseList?[EMAIL PROTECTED]from=281536to=281536count=39by=threadpaged=f alse [2] - http://jakarta.apache.org/site/idedevelopers.html [3] - http://archives.apache.org/eyebrowse/BrowseList?[EMAIL PROTECTED]by=threadfrom=271386 [4] - http://cvs.apache.org/~tcopeland/jakarta_bad_imports.htm Ant === Apache Ant is a Java-based build tool Editor: Stefan Bodewig The biggest news in Ant land is that Ant has been promoted to a top-level project at the board meeting in November. Much of the discussion on ant-dev has been centered around the proposed board resolution, the formation of the initial PMC and similar issues during the last months. [1,2,3] While Ant is leaving the oversight of the Jakarta PMC with this move, Ant's committers are not necessarily leaving the Jakarta community, many of us will still be around and contribute where we see fit. After the release of Ant 1.5.1 at the beginning of October, we've kept on fixing smaller bugs in the 1.5 branch, so a 1.5.2 release is getting more likely. At the same time, development in the HEAD branch is picking up momentum again as we start adding new features and experiment with some stuff [4,5] The Ant GUI, Antidote, is being revived and discussions are getting underway on the Ant-dev mailing list. If anyone wants to get involved in this project, they are most welcome. [1] - http://marc.theaimsgroup.com/?t=10365883356r=1w=2 [2] - http://marc.theaimsgroup.com/?t=10370221362r=1w=2 [3] - http://marc.theaimsgroup.com/?t=10377858962r=1w=2 [4] - http://marc.theaimsgroup.com/?t=10383492934r=1w=2 [5] - http://marc.theaimsgroup.com/?t=10383442511r=1w=2 Commons === creating and maintaining reusable Java components Editor: Henri Yandell Releases November saw the release of two new projects from Jakarta Commons, and the release of a bugfix for another project. Commons Validator 1.0 was mentioned in the previous newsletter. It was released on November 1st and is a validation framework from the Struts people. Commons CLI 1.0 was released on the 6th of November and is an API for parsing command line arguments. It is the direct descendant of 3 older argument parsing APIs and other APIs have affected it over mail list discussions. This gives it a very high pedigree and makes it a great choice for handling the command line. Commons Lang 1.0.1 is the first bugfix release for the Lang project. There are no new APIs or deprecated functionality, so all Commons Lang users are advised to upgrade, although the bugfixes are not earth-shattering. [1] - http://jakarta.apache.org/builds/jakarta-commons/release/commons-validator/v1.0/RELEASE-NOTES.txt [2] - http://jakarta.apache.org/builds/jakarta-commons/release/commons-cli/v1.0/RELEASE-NOTES.txt [3] - http://jakarta.apache.org/builds/jakarta-commons/release/commons-lang/v1.0.1/RELEASE-NOTES.txt Gossip -- November was quiet for Commons, as it was for all of Apache.
Re: Short Apache licence for source files
Ceki Gülcü wrote: I was trying to convey that the word should has different meanings. It can be interpreted as a recommendation or alternatively as an obligation. For example, 1) One should brush one's teeth. Otherwise, you'll get bad teeth. However, not brushing your teeth does not make you a bad citizen. 2) One should be respectful of others. Being disrespectful or violent makes you a bad citizen. In 1) SHOULD is a recommendation whereas in 2) SHOULD really means MUST. Thus, in the sentence, we should use include the license in each file, does SHOULD mean MUST or is it just a recommendation? You are free to take my word for it, or if you deem it necessary, go ask directly and eventually report back. Michael A. Smith actually went to the board a few weeks ago. I did not see a closure. As long as an ASF official (board, PMC) does not officially take a position on this, or until there is an official document on this topic, one should not make absolute affirmations. My words: Currently we should use the full version. Should or must? :-) taken from the license: * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. _must_ martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: db@apache.org
Ray Tayek wrote: hi, there was a general list for some new db stuff. but it seems to have moved. does anyone know where it lives these days? [EMAIL PROTECTED] martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Database Subproject Discussion : creation of DBCommons ?
James Strachan wrote: From: Stefan Bodewig [EMAIL PROTECTED] On Thu, 02 May 2002, Geir Magnusson, Jr. [EMAIL PROTECTED] wrote: Costin suggested, and I supported, that a subproject of wider scope be created to allow the collection of similar technologies into one larger subcommunity. First of all, I like the idea. But in general I think this should not be something we (we as in general@jakarta) should decide but the committers of the current (sub(sub))projects that would make up this new subproject had to decide. If the people working on Torque, commons-dbcp or the Avalon database stuff (I'm sure I'm missing something) as well as the people of Onjectbridge want to create this new subproject, I'll be all for it - but it should be their decision IMHO. +1. I think db.apache.org is a good idea but lets give the OJB folks time to settle in first. Lets bring OJB here, see how well some of the Torque stuff can be moved into commons and get shared across both projects. (Geir you can bring poolman to commons too if you like). Then let the dust settle a bit and see if the communities want to move. While I like the idea of taking the database related stuff out of the 'frameworks' (avalon/turbine) and into a database-related top level project that can work with other frameworks - its maybe a bit early to start db.apache.org. +1 there are only 2 apache developers on the ojb developer list (Jason van Zyl and me) i think it would be good to give the other ojb developers some time to see how everything works here . i think axion-db (http://axion.tigris.org/servlets/ProjectHome) is another candidate for db.apache.org Who knows, maybe Torque and OJB could merge completely over time then just a single top level project at Jakarta would be good too. i'm not sure if the 2 will merge completely, but i'm sure torque and ojb will share ideas and code in the near future ;-) martin ps: ojb uses maven! ;-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
summary: [New Subproject Proposal] ObjectBridge
Jason van Zyl wrote: Hi, I would like to propose ObjectRelationalBridge (http://objectbridge.sourceforge.net/) as a top level subproject of Jakarta. the voting so far: Stefan Bodewig +1 Craig McClanahan +1 Diane Holt not voted yet Conor MacNeill +1 Geir Magnusson Jr. +1 Costin Monolache +1 Sam Ruby not voted yet diane, sam could you please send your votes. i think it is fantastic for both communities to have ojb here at jakarta! martin For those not familiar with ObjectBridge it is arguably one of the most advanced persistence layers available, commercial or otherwise. It is accompanied by an extensive, current documentation set which includes a quick start guide, tutorials, a FAQ, design documentation describing how certain features of OJB have been implemented, and deployment guides. The developer community is incredibly strong and currently consists of 17 inviduals: three of whom are Jakarta committers, and one of the core Castor developers. So the project has the numbers and has displayed some collaboration with other projects. There are developers from the Torque team (the simple table-object persistence tool within the turbine subproject) too so there is obvious interest in OJB. The current list of developers can be found here: http://sourceforge.net/project/memberlist.php?group_id=13647 I would also like to note that David Taylor, a Jetspeed fellow, also contributed to the internal transaction mechanism. So again, another point of interest within Jakarta. OJB is currently being used in the Jetspeed project, and integration is well underway in the Turbine project and Thomas Mahler, the author of OJB, uses OJB in conjunction with Struts as part of some of the solutions his company provides for clients. Thomas is also a user of TopLink, which is the only product that is even remotely comparable with OJB, so he is very familiar with both and reports that OJB is on par with TopLink with to respect to performance and available features. I won't go into a complete list of features, but here are some of the features that set OJB apart: o Pluggable APIs: Currently there is the native PersistenceBroker API, a full ODMG API (which provides enhanced transaction isolation) and a JDO implementation is in the works. OJB has been designed to allow different front-end APIs for maximum flexibility. The ODMG API, for example, is a small set of classes layered over top the core of OJB. The JDO implementation will be very similiar in nature. o Pluggable query APIs: currently supported are a criteria based API (AST based mechansism), OQL and SODA. But again they are pluggable, so for example the query mechanism in Torque could easily be made to work with OJB. These two features alone make OJB attractive as different APIs can be made so that existing users of different systems can use OJB without forcing clients to change code. Trying this with Torque is going to be one of my first exercises to see how well this mechanism works. There are many tools like Torque and OJB can be made to work with the APIs of these projects so that greater collaboration can occur within OJB itself. One can take a look at the source and design of OJB and quickly determine that OJB stands in a class of its own, is very reliable, very flexible and very performant. The greatest feature with respect to development is the extensive regression testing features and the testbed. There are currently 130+ test cases and a regression test that compares the performance of OJB with native JDBC calls. A full list of features can be found here: http://objectbridge.sourceforge.net/features.html OJB also makes use of many Jakarta packages: Ant, Maven, Crimson, and Log4j. There are also plans to use more of the commons utilities where possible so the project is already Jakarta friendly :-) Another interesting note is that OJB is one of the top 100 projects on SourceForge (rank 89) with about 15,000 hits and 3,500 downloads per month. So there is a very healthy user community that complements the strong developer community. Currently the license of OJB is LGPL but in discussion with Thomas he feels that a BSD style license like Apache's is actually a better model and has no problem with changing the license if the donation of OJB is accepted by the Jakarta PMC. This is really a one-of-a-kind project, and is definitely one of the cases where an OSS implementation is close, if not better than its commercial counterpart. The developer community is keen, there are great number of users and we think that OJB would be a fabulous addition to the set of projects that are currently housed at Jakarta. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [New Subproject Proposal] ObjectBridge
Jason van Zyl wrote: Hi, I would like to propose ObjectRelationalBridge (http://objectbridge.sourceforge.net/) as a top level subproject of Jakarta. For those not familiar with ObjectBridge it is arguably one of the most advanced persistence layers available, commercial or otherwise. It is accompanied by an extensive, current documentation set which includes a quick start guide, tutorials, a FAQ, design documentation describing how certain features of OJB have been implemented, and deployment guides. The developer community is incredibly strong and currently consists of 17 inviduals: three of whom are Jakarta committers, and one of the core Castor developers. So the project has the numbers and has displayed some collaboration with other projects. There are developers from the Torque team (the simple table-object persistence tool within the turbine subproject) too so there is obvious interest in OJB. The current list of developers can be found here: http://sourceforge.net/project/memberlist.php?group_id=13647 I would also like to note that David Taylor, a Jetspeed fellow, also contributed to the internal transaction mechanism. So again, another point of interest within Jakarta. OJB is currently being used in the Jetspeed project, and integration is well underway in the Turbine project and Thomas Mahler, the author of OJB, uses OJB in conjunction with Struts as part of some of the solutions his company provides for clients. Thomas is also a user of TopLink, which is the only product that is even remotely comparable with OJB, so he is very familiar with both and reports that OJB is on par with TopLink with to respect to performance and available features. I won't go into a complete list of features, but here are some of the features that set OJB apart: o Pluggable APIs: Currently there is the native PersistenceBroker API, a full ODMG API (which provides enhanced transaction isolation) and a JDO implementation is in the works. OJB has been designed to allow different front-end APIs for maximum flexibility. The ODMG API, for example, is a small set of classes layered over top the core of OJB. The JDO implementation will be very similiar in nature. o Pluggable query APIs: currently supported are a criteria based API (AST based mechansism), OQL and SODA. But again they are pluggable, so for example the query mechanism in Torque could easily be made to work with OJB. These two features alone make OJB attractive as different APIs can be made so that existing users of different systems can use OJB without forcing clients to change code. Trying this with Torque is going to be one of my first exercises to see how well this mechanism works. There are many tools like Torque and OJB can be made to work with the APIs of these projects so that greater collaboration can occur within OJB itself. One can take a look at the source and design of OJB and quickly determine that OJB stands in a class of its own, is very reliable, very flexible and very performant. The greatest feature with respect to development is the extensive regression testing features and the testbed. There are currently 130+ test cases and a regression test that compares the performance of OJB with native JDBC calls. A full list of features can be found here: http://objectbridge.sourceforge.net/features.html OJB also makes use of many Jakarta packages: Ant, Maven, Crimson, and Log4j. There are also plans to use more of the commons utilities where possible so the project is already Jakarta friendly :-) Another interesting note is that OJB is one of the top 100 projects on SourceForge (rank 89) with about 15,000 hits and 3,500 downloads per month. So there is a very healthy user community that complements the strong developer community. Currently the license of OJB is LGPL but in discussion with Thomas he feels that a BSD style license like Apache's is actually a better model and has no problem with changing the license if the donation of OJB is accepted by the Jakarta PMC. This is really a one-of-a-kind project, and is definitely one of the cases where an OSS implementation is close, if not better than its commercial counterpart. The developer community is keen, there are great number of users and we think that OJB would be a fabulous addition to the set of projects that are currently housed at Jakarta. i am a torque and ojb developer. here's my non-binding +1 :-) martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [New Subproject Proposal] ObjectBridge
Jon Scott Stevens wrote: on 4/30/02 11:11 AM, Gerhard Froehlich [EMAIL PROTECTED] wrote: PS: hmm curious if takes the jon hurdle ;-). +1. The proposal and project clearly meet ALL of the requirements set out on the newproject page. I would really like to see some sort of commitment to torque-obj integration/use/conversion/whatever though. - torques sql generation stuff will go to commons and will be used by ojb - i started to write a generator for ojb based on the torque one (generating the repository.xml for ojb) - there will be a migration path torque - ojb as i want to move my torque projects to ojb ;-) martin -jon -- 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: [PATCH] /home/cvspublic/jakarta-site2/xdocs/site/mail2.xml
Andrew C. Oliver wrote: Hi, I'm pretty sure this is the right place to post this. Just a little nit to pick. (Worse for Marc who wondered where his posts had gone to and why it wasn't refreshing). Changed it so that archive for commons points to the current archive and yet you can still get the old. Why? Its easy to be confused for those of us who subscribe to too many mail lists already and rely on the online archives. Also fits more in with the tone set by the rest of the entries. Thanks, -Andy the Insomniac applied, thanx martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: FAQ links...
Pier Fumagalli wrote: Hey folks... I moved the OLD Jyve FAQ from daedalus to nagoya too (re, FreeBSD and it's VM don't go well along together, let's see if Solaris 8 can solve the intermittent VM crash problems). Can someone with some spare cycles change the links from jakarta.apache.org:8080/jyve-faq/ to nagoya.apache.org:8080/jyve-faq/ ? i fixed the link on the faq page .. martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
