commons-fileupload 1.1-dev to maven repo?
Can someone associated w/ file upload get the 1.1-dev jar to maven? We're using it in Geronimo now, and want to make it easy. If no one cares, I'll be happy to do it, but wanted to ask first. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-fileupload 1.1-dev to maven repo?
Right, and there is nothing there for fileupload. I'll take the one from the tarball and put it there. Please yell if you object. geir On Jul 20, 2005, at 4:43 AM, Brett Porter wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 unreleased files should go to http://cvs.apache.org/repository, which I believe you already have in your remote repo settings? BTW, have you guys tried the Maven 1.1-beta with Geronimo? It should lessen the extent of your SNAPSHOT issues. - - Brett Geir Magnusson Jr. wrote: Can someone associated w/ file upload get the 1.1-dev jar to maven? We're using it in Geronimo now, and want to make it easy. If no one cares, I'll be happy to do it, but wanted to ask first. geir -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC3g6vOb5RoQhMkRMRAm+sAJ4rKwCfngAlpEgG9mKZjYAJ4fNSjwCeN3eH lKUwYLZqCVqao1sgTleMebw= =+Fms -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] Commons Runtime API for Persistence
a.k.a. Commons Persisting Motivation -- There are an increasing number of viable APIs for persisting objects to data stores. We currently have JDO, a JCP spec, Hibernate, a popular open source project, OJB, an Apache open source project, EJB3, a new JCP spec for object persistence, commercial products such as Toplink, and many others such as Abra, BasicWebLib, Castor, Cayenne, DataBind, DBVisual Architect, EnterpriseObjectsFrameworks, Expresso, FireStorm, iBATIS, Infobjects, InterSystems Cache, JULP, Jaxor, JDX, Kodo, LiDO, O/R Broker, Planet J's WOW, intelliBO, SimplOrm, Spadesoft XJDO, Sql2Java, PE:J, VBSF and others. Each of these solutions have strengths and weaknesses and are chosen by developers based on specific project needs, political considerations, or quality of golf outings provided by the technology salesperson. Like the situation that developed a few years ago with logging, in which developers were forced to choose between the de-facto standard, Apache Log4J, or the JCP-defined spec, java.util.logging, we believe that we have a similar situation today - developers are forced to commit to an API or product for persisting objects which may limit usefulness to users who may have a legacy persisting technology, or choose an different technology than the software was developed for. Further, there is no way to insulate software from API lock-in, to allow software to be used with different persisting APIs as style, fads and technology concerns dictate. Finally, there is no way to ensure that arbitrary dependencies that a project uses can, in an ad-hoc way, find and write to the application's data store. In the same way that components using commons-logging never cease to delight and surprise users, we think that commons persisting should just enhance the mystery and intrigue of adding apparently innocuous dependencies to a project. Proposal Following the successful model of Commons Logging, we propose to create a single API, to be known as Commons Persisting which allows isolation from the fashions and trends in persisting technology. This API will not : - define a query language similar to any other - define a query language conforming to standard set thEory - define an O/R mapping metadata syntax - define rules for object lifecycle with respect to the methods in this API - use insert favorite unproven technology here - constrain the types of objects and object models that a given plug-in might support - keep Hani quiet This API will : - allow users to use one set of simple interfaces for persisting objects - allow different providers to be plugged-in - define an API for execution of queries - piss off various and sundry expert group members Comments? -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java name Re: What is Jakarta Commons?
On Dec 24, 2003, at 12:03 PM, Morgan Delagrange wrote: I believe (but I Am Not A Lawyer) that we can use the term Java to describe something on the homepage, but that it cannot be the title of a project, nor could it be used as a domain name. Most sourceforge projects that do so are probably in error from a legal standpoint. That is correct. You couldn't have JavaLogging or such, but could describe it as 'logging solution for Java'. geir Anyway, that old domain name was cheesy. :) - Morgan --- Henri Yandell [EMAIL PROTECTED] wrote: Any idea how exactly the java trademark works with respect to our usage of it? For example, if we're talking about language based portals/foundries, can we actually call it the 'Apache Java Portal'? Or some such. How do Sourceforge get away with: http://java.foundries.sourceforge.net/ ? Presuming Jakarta remains as is, but some kind of Java-ASF-portal is also created, I'm just wondering how the word 'Java' can be linked to the name etc. Hen On Tue, 23 Dec 2003, Greg Stein wrote: We started with java.apache.org, but had to toss it for trademark reasons. Thus, Jakarta was born. No going back now... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] = Morgan Delagrange http://jakarta.apache.org/commons http://axion.tigris.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [All] License change
On Mar 1, 2004, at 7:18 AM, [EMAIL PROTECTED] wrote: Geir Magnusson Jr [EMAIL PROTECTED] wrote on 27/02/2004 10:35:29 PM: As you know, the board of directors of the ASF has approved a new license, v2.0, and has mandated that the entire ASF codebase be moved to it. Specifically, they require that any code released after March 1, 2004 be placed under this new license. However, given that snapshots of commons components are created and placed in repositories, and people use sandbox components, which by definition don't have an actual release, it behooves us to not wait until something get released to move to the new license. This process, applied to the Geronimo and it's 26 modules, took 2 minutes and 33 seconds, according to the kind soul who did the change. By my math, it should take *5* minutes to do the entire commons. FYI, it appears to be incomplete. Several maven files (project.xml, maven.xml, project.properties) for example are license-less. Thanks for bringing that up :) geir -- dIon Gillard, Multitask Consulting -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [releases] lacking releases for .... Was: [sandbox] report
On Feb 29, 2004, at 11:26 AM, Henri Yandell wrote: In addition, we have commons-proper projects without a release: IO Jelly Jexl Launcher Math Does anyone have estimated release dates for these? and who is release manager for each one? [something we should probably make a clause of sandbox-proper promotion]. If the release manager then vanishes, we should demote if no one else volunteers. Subtle point - should there be a required release to get to commons out of sandbox? One issue we're discussing is that code shouldn't depend on sandbox code, as it's supposed to be just a 'play area'. That said, having users is a great way to clean, refactor and evolve code, so if you can only get to commons from sandbox w/ a release, then we are imposing a bit of a chicken-egg problem, or just releasing for the sake of release, which I think is pointless. *** To get started, I'm currently viewing myself as IO release manager and have been slowly moving along. All code is now javadoc'd as much as needs be and classes that will not go in 1.0 have been identified. 3 Unit tests remain to be finished. I'll do jexl... geir Hen On Sat, 28 Feb 2004, Henri Yandell wrote: I've asf 2.0'd the sandbox. All modules that are mavenised either build, or if they don't, they didn't before. I've moved all mavenised projects over to the sandbox-build structure but not run the maven-build.xml yet, so might see some gumps if any of these are in gump. Also prepared a report on sandbox in general: DEAD altrmi util joran pattern primitives SANDBOX-PLAY cli ?? lang TO-DELETE = jexl el MAVENISED+BUILD === attributes cache compress convert email events functor grant graph2 jrcs jux mapper messenger reflect resources sql threadpool workflow xo MAVENISED+FAILING = chain - needs portlet api/jsf clazz - tests fail codec-multipart - has bad codec dependency id - test fails [sys clock] jjar - lacks ant-tools periodicity - bad maven deps scaffold - does not compile - missing class vfs - bad maven deps NOT-MAVENISED = feedparser filters http jpath servlet rupert services simplestore tbm threading xmlunit SPECIAL === hivemind - ignoring as it is leaving commons jex - legacy maven issues, needs figuring out Hen - 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] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/jexl/src/test/org/apache/commons/jexl/junit AsserterTest.java
On Feb 28, 2004, at 8:45 AM, [EMAIL PROTECTED] wrote: yoavs 2004/02/28 05:45:22 Modified:jexl LICENSE.txt [SNIP] Thank you! geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpClient] Moving to Jakarta
Go for it... +1 (supportive non-participant) :) geir On Feb 28, 2004, at 2:51 PM, Martin Cooper wrote: On Sat, 21 Feb 2004, Michael Becke wrote: Below is a message I recently posted to commons-httpclient-dev. The input of other commons developers would be greatly appreciated. I look forward to hearing from you. There seems to be a deafening silence on this subject, but just for the record, and in case it's not obvious from the message below, I am +1 on this. -- Martin Cooper Thanks, Mike Original Message: Now that 2.0 has been released I think it's time to again discuss moving HttpClient to a Jakarta level project. As suggested by Martin Cooper I suggest that we proceed as follows: 1) Continue discussing the move for the next few days (perhaps a week) until we are sure this is what we want. 2) Have an official vote on the move. and assuming we vote to move... 3) Submit a proposal to the Jakarta PMC. 4) Move to Jakarta with help from the PMC. If anyone has an questions, doubts, or suggestions please bring them up now. Also, any help with the format and content of the proposal to the PMC would be greatly appreciated. Mike - 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] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Removal of committers from commons-avail
On Feb 27, 2004, at 1:30 AM, Henri Yandell wrote: I believe the following committers are all in a situation of having not committed to Commons, or having committed files which are now dead. knielsen plynch smor mjohnson paulo catlett leonardr amyroh dweinr1 jariw Any chance we could remove them from the avail? Trying to be clean. We can remove them. We should give them a day or so to respond. I recognize a few names and will ask them directly. geir [apologies if anyone on the list is a new committer or something] Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[All] License change
As you know, the board of directors of the ASF has approved a new license, v2.0, and has mandated that the entire ASF codebase be moved to it. Specifically, they require that any code released after March 1, 2004 be placed under this new license. However, given that snapshots of commons components are created and placed in repositories, and people use sandbox components, which by definition don't have an actual release, it behooves us to not wait until something get released to move to the new license. This process, applied to the Geronimo and it's 26 modules, took 2 minutes and 33 seconds, according to the kind soul who did the change. By my math, it should take *5* minutes to do the entire commons. So please - lets be proactive and Just Do It. Decide among the committers for a component who will do it, or maybe have a group volunteer to do all for efficiency. Lets just get this done. geir P.S. The Board isn't kidding about the CLAs either - so if you haven't gotten them in, please do so. If you are having problems or questions, please contact [EMAIL PROTECTED] If they are not in you will a) have your commit privs suspended and b) it's possible code will be yanked from CVS, although actions following a) are yet to be decided by the board. -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Relicensing to the Apache License 2.0 ?
On Feb 4, 2004, at 5:30 PM, Martin Cooper wrote: On Wed, 4 Feb 2004, robert burrell donkin wrote: On 4 Feb 2004, at 17:51, Emmanuel Bourg wrote: robert burrell donkin wrote: snip if you have any further concerns relating to possible ASF claims may i politely suggest that you take them to a more appropriate forums where those with authority to speak for the ASF will be able to provide goods answer. What mailing list could be contacted to address this concern? license at apache dot org is ASF wide (and contains - or contained - some very big guns). I sent a message to license@ a couple of days ago, suggesting that a message about usage, sent to all committers, might be appropriate, given the amount of discussion I'm seeing on so many lists. I have not had any response so far, though. Maybe they're holed up somewhere, wordsmithing something to guide us all. ;-) A message will be forthcoming, either from the board, or the Jakarta PMC. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Relicensing to the Apache License 2.0 ?
On Feb 4, 2004, at 4:51 PM, robert burrell donkin wrote: On 4 Feb 2004, at 17:51, Emmanuel Bourg wrote: robert burrell donkin wrote: snip if you have any further concerns relating to possible ASF claims may i politely suggest that you take them to a more appropriate forums where those with authority to speak for the ASF will be able to provide goods answer. What mailing list could be contacted to address this concern? license at apache dot org is ASF wide (and contains - or contained - some very big guns). or possibly if you want to raise this with the jakarta pmc then either direct to pmc at jakarta dot apache dot org (for private discussions) or general at jakarta dot apache dot org (allowing public discussion). it's nothing personal but the jakarta commons team simple don't have the authority to decide legal matters such as these. it's very important that all matters such as these are raised with the ASF officers (or at the very least with ASF committees that have legal standing). What's the legal matter to be decided? geir - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bugzilla Admin request
On Jan 12, 2004, at 6:47 AM, peter royal wrote: On Jan 11, 2004, at 11:58 PM, Noel J. Bergman wrote: Tim O'Brien wrote: Could someone with access add a new component configuration under the program commons in Bugzilla? Would Jakarta Commons like to migrate into Jira? We're in the process (literally in the process) of bringing it live tonight. Jelly is already in there, and we can import from Bugzilla selectively. I'd like to see jexl move over.. That would be fine by me too. I hate Bugzilla. geir -pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Re: [jexl] - checking for unresolved variables
On Jan 11, 2004, at 3:28 PM, peter royal wrote: On Jan 11, 2004, at 2:54 PM, Bill Horsman wrote: On Sun, 2004-01-11 at 20:46, peter royal wrote: So if implement the Map interface (or expose it) then you run the risk of another class just calling get() instead of getVar() and bypassing my strict variable check. Unless the new exception was a subclass of RuntimeException :) Yep, that's true. Well, I can be persuaded either way. To extend Map or just to use it. My gut instinct still says the composition is better. Your gut is right, I just worry about the change to the client contract.. This would no longer be a drop-in upgrade. I'll ping Geir and get his opinion on this too.. Ok - I read the thread, and I think it's not a good idea to totally break usage because Map can't throw an exception (and no, I don't think a RuntimeException is the right way either, as that also has far reaching complications for dropping into existing uses) To be clear, I *really* don't think it's a good idea to break usage. :) Having getVars() return a j.u.Map means that it's easy to use and simple to implement for alternative backing stores Now, I certainly agree that this would be darn useful, and I see two ways (offhand) to approach it : 1) Your solution, where the context implementation has to understand and know about all this magic jexl stuff or 2) A different approach, where the context is simple (allowing recycling w/o much effort of other backing impls) and Jexl is smart Regarding #2, I can see 2 approaches. One is to do it during evaluate(), like you proposed, which will change the state of some of the objects in the context, and not all if something is wrong : nuclearReactor.start(); nuclearReactor.setTemparature(temp); nuclearReactor.stop(); Granted, I know that you can't always ensure you get through, but still, adding another way causes concern. On the flipside, it's simple The other would be to have a checker that takes an expression and figures out if it will go given a context. That leads to a two step execution process, where you'd first run the check and then evaluate() Comments? geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jexl] - checking for unresolved variables
Getting to this thread a few days late. Will read. Initial comments - you need to be sure that you don't get fooled by a sequence of expressions that will resolve ok - IOW, an assignment a = b; w/ 'b' in the context should result in 'OK' for an unresolved check even though a isn't in the context to start. I'm sure that's occurred to someone - I'll read the thread now :) geir On Jan 9, 2004, at 12:03 PM, Bill Horsman wrote: Hi, I'm successfully using JEXL to evaluate formulae that my users write. It works well, but the default behaviour is to ignore any variable that is not defined. I would like it to a) throw an exception and b) provide structured feedback on what variables were unknown. For instance, if I define a = 3 and then evaluate the expression a + b I get the answer 3. What I want is an exception with a method like: String[] getUnresolvedVariables(); That would give me [b] back. I'm quite happy to code the changes myself, but I just wanted to check whether: a) this functionality already exists (I've looked but I can't find it) b) there's a better way of doing this c) anyone can provide any hints about where to start (I'm confident enough to launch into this unaided, but wise enough to know that I will do it better with a little guidance). Cheers, Bill Horsman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote io from commons-sandbox to commons-proper
-- - Vote: Promote commons-io to commons proper [ ] +1 I am in favor of the move, and will help support it [ X ] +0 I am in favor of the move, but am unable to help support it [ ] -0 I am not in favor of the move [ ] -1 I am against this proposal (must include a reason). -- - -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jexl] String concatination
On Dec 29, 2003, at 7:52 PM, Robert wrote:
Geir Magnusson Jr wrote:
On Dec 20, 2003, at 10:22 PM, Robert wrote:
I actually thought this was in the spec, my fault! I was trying to
do string building, which of course didn't work, which lead me to
look at the JavaDoc this class says either integer addition or
string concatenation and the CVS entry says something about string
concatenation not working anymore, so I did this quick patch.
I even tried string literal addition and it doesn't work either. It
would be nice so one does have to do ${hello.concat(' world')} to
build strings, but I'll understand if it isn't added.
What doesn't work? I don't understand.
I'll double check but 'hello' + 'world' wouldn't work either. Perhaps
I should just write a junit test!!
I added a unit test when I did the patch
Robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Geir Magnusson Jr 203-247-1713(m)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Author tags redux
On Dec 28, 2003, at 10:39 PM, Phil Steitz wrote: The subject of @author tags has been discussed on and off here and elsewhere with no apparent consensus. In a recent post to general@, Ted Husted pointed to this post http://tinyurl.com/yrlhu by Greg Stein to community at apache.org, which raises some disturbing legal and community issues around the use of @author tags. I am convinced by his arguments that we should eliminate @author tags uniformly once we clean up the web site and get the process of updating and publishing contributor lists routinized (read: complete the mavenization of the j-c web site). I'm not sure I buy the legal argument, as our CVS logs are public also, and it's easy to figure out who did what in a piece of questionable code. So you haven't really don't anything by removing the author tag - the author is still easily discoverable. I think author tags are good as some/many/all people are proud to have their name on things that they work hard on and contribute. I'll be the first to admit the sense of pride that I felt when contributing something for the first time, and seeing my name on it. The valid point (IMO) I've heard in favor of removing them is that not having them can help the sense of group ownership and community. if I had to decide, as long as there is no additional liability in having the tag in the code, I'd be for letting people/components/etc choose to do what they feel is right. geir I assume that this needs to be decided for each of the components separately. With that in mind, I would like to start by removing/omitting @author tags from [uid] and I would like to propose that we pull them out of [collections] and [lang] as and when we complete mavenization of the websites for these components (or otherwise publish a full and up-to-date contributors list). Now would be a good time to act on [collections], since we are about to cut a release. So...what do we think about pulling out the @author tags from [collections] and pushing out the maven site with 3.0? If we want to hold off on the mavenization until we have worked out the larger j-c site issues, we can just add a contributors page to the existing site to acknowledge contributors. If others are in favor, I will volunteer to grep out the @authors and do this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving up to JVM 1.4+
On Dec 30, 2003, at 3:41 PM, David Graham wrote: --- Noel J. Bergman [EMAIL PROTECTED] wrote: This has come up in regards to using some of java.nio in Commons/Net also. I say we leave the last release as 1.1 compatible and move on to using 1.4+ for new versions. Personally, I use JVM 1.4+, myself. However, everytime we do a survey on server-user, we get emphatic feedback from our users to preserve support for JVM 1.3.1. Before dropping support for pre-1.4 systems, perhaps it would be a good idea to raise the question on the user list? There will always be users that will complain when changing Java versions. The only semi-valid reason I've heard to not upgrade to 1.4 is that product X requires 1.3 and product X is expensive. IMO, if the component needs 1.4 then you should move to 1.4. The previous 1.3 compatible version of the component will still work after the change. Product X shouldn't stand in the way of innovation :-). Don't forget that not all platforms have 1.4 or a mature 1.4 that people trust. it too a while for apple to get 1.4 out to OS X - I wouldn't use OS X in production of course, but it's my development platform... geir David There are also ways to support pre-1.4 while still gaining the advantage of 1.4+ systems when available. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Virtual Commons!!!!! (was Re: What is Jakarta Commons?)
Why don't the various commons groups in the ASF just have the AC PMC add things on the A-C site and 'federate' that way? The respective PMCs would still do what they do - oversee the projects - and the AC PMC can maintain the website. geir On Dec 23, 2003, at 4:44 PM, Noel J. Bergman wrote: Mark R. Diggory wrote: I personally think that the idea of Commons should become more Virtual and Evolutionary in nature. if theres ever the case that xml commons and jakarta commons could become a shared community, it would produce the following benefits Mark, what you are saying is basically supporting the notion of decoupling web presence from project oversight, and supporting the idea of federation instead of containment. A PMC oversees the code, resources, community for a project. There is nothing that prevents them from federating to produce portals as you describe. I have suggested it recently as one good approach. Without going into details right now comparing various plans, let me note that Federation is one approach being discussed on Jakarta General as part of a larger reorganization discussion. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons - TLP
On Dec 21, 2003, at 3:20 PM, Paul Libbrecht wrote: I might have overlooked something in the whole flood about this topic. Allow me to add that a move into Apache Commons might have our Java flavour sort of shaded. A move out of Jakarta Commons, however, might free our projects from the server-only orientation of Jakarta project in general. Does anyone really keep that in mind ? I mean, anything can be used on a server. I think that we (the community) should address this in our charter as soon as we get the bigger CLA and oversight issues squared away. If we asked nicely, I'm sure that we could drop the 'server-only' aspect of the charter. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons - TLP
On Dec 18, 2003, at 7:50 PM, Phil Steitz wrote: Stephen Colebourne wrote: I too stick with the Java-centric theme. I don't want to seem overly anti other programming languages, its just that IMO j-c is better of as just Java. a) Code standards, guidelines, packaging, naming, integration with JDK - all are very Java specific, and are usefully captured in the charter. b) j-c is already very busy, and if we add BCEL and perhaps some others, (which we probably should), it could get busier. c) There is no easy division within j-c. I've tried on many occasions to find one, and always fail. However there is the potential for some to leave* Stephen I agree with all of these points, and others made by Dirk and Morgan elsewhere on this thread related to the Java community aspects of Jakarta in general and Jakarta Commons in particular. One thing that I would personally be very sad to lose in j-c is the regular comments and discussion from Java developers (many from other Jakarta projects) on Java language-related issues that come up frequently. If we were to lose or dillute the Java-identity of j-c, I am afraid that the signal to noise ratio on the lists might get too low to maintain the interest of some of these folks. One more point. While I have not participated much in the general@ and pmc@ discussions of where Jakarta may be headed, I think that we can solve the oversight and organization problems without turning all projects into TLPs and I would like to see Jakarta maintain its identity and community, with j-c an important part of both. +1 Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jexl] String concatination
Intresting. This is not what the JSP EL does. Not that we really
care, but it's an interesting extension. It follows Java, I suppose :)
Patch in - lets see what people think.
geir
On Dec 15, 2003, at 8:55 PM, Robert wrote:
Attached is a patch for the ASTAddNode class that will do a string
concat if the coercion to a double and long fails.
Thanks!
Robert McIntosh
Index: ASTAddNode.java
===
RCS file:
/home/cvspublic/jakarta-commons/jexl/src/java/org/apache/commons/jexl/
parser/ASTAddNode.java,v
retrieving revision 1.2
diff -u -r1.2 ASTAddNode.java
--- ASTAddNode.java 17 May 2002 12:13:22 - 1.2
+++ ASTAddNode.java 16 Dec 2003 01:47:01 -
@@ -119,12 +119,18 @@
}
/*
- * otherwise to longs with thee!
+ * attempt to use Longs
*/
-
-Long l = Coercion.coerceLong(left);
-Long r = Coercion.coerceLong(right);
-
-return new Long(l.longValue() + r.longValue());
+try {
+Long l = Coercion.coerceLong(left);
+Long r = Coercion.coerceLong(right);
+return new Long(l.longValue() + r.longValue());
+}
+catch( java.lang.NumberFormatException nfe ) {
+/*
+ * Well, use strings!
+ */
+return left.toString().concat( right.toString() );
+}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Geir Magnusson Jr 203-247-1713(m)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
On Sunday, November 9, 2003, at 05:39 PM, Tim O'Brien wrote: On Sun, 2003-11-09 at 14:24, robert burrell donkin wrote: snip/ so - is there a positive alternative? i'd like to propose that common-maths continues to be affiliated with jakarta-commons but becomes managed by apache commons. +1, I think that now is the right time to move commons math to Apache Commons. What does 'affiliated' mean? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
On Sunday, November 9, 2003, at 10:52 PM, Craig R. McClanahan wrote: Regarding separate DEV list -- as I said in my earlier comments, that's totally up to the MATH developers if they want it or not. The fact that it might make my life easier certainly isn't binding. Note also that the httpclient guys were not pushed out; they deliberately chose to have a separate DEV list. That's the way it should work -- being up to the developers involved. +1 Hen Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN][hivemind] hivemind has been temporarily taken offline
On Friday, November 7, 2003, at 11:05 AM, Harish Krishnaswamy wrote: Hi Danny, I don't deny the recommedation that the PMC should be notified of situations such as this although I don't know why the PMC list is private. Because there may be things that it wouldn't be appropriate to discuss in public. To that end, though, the PMC tries to hold all non-sensitive discussions in public. But it seems like all this confusion is due to the lack of proper protocols defined in a public place that people can follow, or have I not looked around well enough. May be this is the first such situation and something may spring out of here, I don't know. It could be. Thanks, Harish Danny Angus wrote: Harish, There isn't very much traffic on the PMC list at all, most business, and all votes, is transacted on the general list. If anyone has any item which they wish to draw to the specific attention of the PMC it is always a good idea to post to PMC@ because you will then know that your message has been read. Further discussions could be carried out on the general list or in private, whichever was more appropriate. By which I don't mean that the PMC would reach its decisions in secret but that issues of individual privacy may make it more acceptable to keep the discussion out of the spotlight. d. ** * The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Li mited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - 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] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OT: Re: was [ANN] hivemind has been temporarily taken offline, NOW: Geronimo code onwership
On Friday, November 7, 2003, at 05:53 PM, Vic Cekvenich wrote: Danny Angus wrote: 3/ Geronimo is not under the jurisdiction of this PMC. The Geronimo situation was explained to you at the time . Would you please refresh my memory a link the message explaining the source of Geronimo source? I think that most people believe, including me, that it is refactored jBoss code, how else could so much code apear. Come on, Vic. Take this to the geronimo list if you have accusations. Remember, many of the core Geronimo developers were core JBoss developers. They are free to re-license their code if they choose to, just like you can take code *you* contribute to the ASF and relicense if you wish to. They are also focused and dedicated and working on this full time, in an area that they have expertise in. Re-writing something you have done before is generally much faster the 2nd time around. or just ignore this post, no need for another flame war on Geronimo. I think Geronimo is a shamefull part of ASF. Take it to the members list or the Geronimo list. geir tia, .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OT: Re: was [ANN] hivemind has been temporarily taken offline, NOW: Geronimo code onwership
On Sunday, November 9, 2003, at 12:15 PM, Noel J. Bergman wrote: Take it to the members list or the Geronimo list. He can't take it to the members list. He's not a Member. Which also means that he's not privy to whatever, if any, discussion occured on that list regarding Geronimo or any other project, as the content of that list is confidential. True, but the member discussion is irrelevant because the project was initiated with as much fanfare as possible, with open invitations to anyone and everyone to review the code as posted. Judging from his messages on Incubator General (http://nagoya.apache.org/eyebrowse/ SearchList?listId=[EMAIL PROTECTED] bator.apache.orgsearchText=CekvenichdefaultField=senderSearch=Search ), I can see why he is upset that Geronimo project got green lighted, and his basicPortal messages were ignored. basicPortal looks interesting. One problem is that far too many messages have been, and continue to be, ignored on Incubator. Incubator needs more resources. That's all well and good, but the reason to be mad at Apache can't be because of some imagined hijacking of someone else's IP, in this case JBoss's with Geronimo. There are probably a lot of criticisms that can be debated about Apache, but respect for IP isn't one of them. I think that we are in violent agreement :) geir --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [hivemind] what exactly is the issue here?
On Thursday, November 6, 2003, at 12:35 AM, Noel J. Bergman wrote: Rodney Waldhoff wrote: On Wed, 5 Nov 2003, Noel J. Bergman wrote: We're not the ones whom Howard needs to discuss this with. Yes and no. I'm on the Jakarta PMC, you're an ASF member, we're both jakarta commons committers, so I belive and as I understand it, we are among the ones Howard needs to discuss this with. In your capacity as a Jakarta PMC member, yes. And there are other PMC members here, such as Craig, Danny, and Howard, himself, IIRC. I don't care if he talks with me about this situation or not; the Board are our elected Officers, with the experience to resolve such matters, or bring them to the membership if they felt the need. However, Howard has an obligation to notify the Foundation when an IP issue arises. Even though there is reason to believe that this situation will work out fine, and even if the PMC and Board would delegate to him the ability to work out the plan within some guidelines, keeping them out of the loop is not his decision to make. I am honestly not sure what he's thinking in terms of why he has not brought the issue to the PMC and/or Board. Some of his messages seem to imply that he feels that if he did, there would be drastic action. If this continues this way, there probably will be drastic action, namely removing material of questionable IP provenance from Apache CVSs (temporarily) while the issues are resolved. I think that while there are many PMC members here, I think a note to the PMC outlining the issues and status would be a great start. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [hivemind] what exactly is the issue here?
On Wednesday, November 5, 2003, at 06:48 PM, [EMAIL PROTECTED] wrote: I'll admit I haven't read every [hivemind] message on this, but I've read quite a few of them, and the precise situation still isn't quite clear to me. If I understand it correctly, all of the code in HiveMind was either: 1) moved to the j-c-sandbox from tapestry or 2) created new in the j-c-sandbox by Howard the trouble being that some of the work under #2 was done on WebCT's dime, and that while Howard believed that was acceptable to WebCT at the time, now there seems to be some ambiguity in the matter. Is that correct? Howard, can you explain in more detail: A) What exactly is WebCT asserting with respect to HiveMind? They assert that any contribution of the code to the ASF should originate with them, rather than soley with me. That's reasonable if it was a work-for-hire, isn't it? B) What exactly WebCT would like to do/plans to do/would like the ASF to do as a result of that? The proposal for HiveMind will note the generous donation of code to the ASF. Just in the proposal? I can't imagine that there would be a problem with that, although any requirements after that would most likely be problematic. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jexl] removing sandbox version
Fine by me, as long as it remains in the attic. On Monday, October 13, 2003, at 03:53 AM, robert burrell donkin wrote: jexl has been promoted to the commons proper for sometime now. a version still exists in the sandbox. the tradition is that components are removed from the sandbox (but not from the attic) when they are promoted. unless someone posts an objection before 12 noon GMT thursday 16th october. i'll remove the sandbox version some time after then. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jexl] size method unit test failing
I guess we were going to figure out if we want to add the artificial notion of the length field, or just ask people to use size(). 'length' is really weird, as it doesn't really exist as a field, and only applies to arrays. Why confuse the syntax with an additional way to get size? geir On Tuesday, September 9, 2003, at 06:40 AM, Mark H. Wilkinson wrote: On Sun, 2003-09-07 at 03:28, Tim O'Brien wrote: JexlTest line 443: assertExpression(jc, array.length, new Integer(5)); This is failing because (from what I'm seeing), length isn't given any special treatment in Parser.jjt. Any ideas? I proposed the attached fix a few months back, but geir wanted to discuss other possible ways of implementing the length function so he didn't apply it. There's been no progress since then though. -Mark. array- length.patch-- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jexl] size method unit test failing
On Tuesday, September 9, 2003, at 08:25 AM, Tim O'Brien wrote: On Tue, 2003-09-09 at 06:58, Geir Magnusson Jr. wrote: I guess we were going to figure out if we want to add the artificial notion of the length field, or just ask people to use size(). 'length' is really weird, as it doesn't really exist as a field, and only applies to arrays. Why confuse the syntax with an additional way to get size? People may expect length to work, but as long as it is properly documented for users I see no problem with asking people to use size() instead of length. length is a public final field in all array types, It's not actually a field right? (in that it's artifically generated by the compiler, IIRC) [] aren't objects. but from what I see ASTIdentifier just delegates to ASTArrayAccess which then decides how to deal with an identifier (isMap - isList - isArray - bean prop). We could just as easily add a step after accessing a bean property in ASTArrayAccess which tried to access a public field. What do you think? I think that just using size() is the right way to go. We want to avoid the situation where you have to know the exact type of the referent to use it. Conversely, you'd want the data model to be able to change (say substitute a j.u.List for an []) w/o the script using jexl having to change. If you believe that those two reasons are good, then either you have to make length behave exactly like size(), having two 'methods' that do the exact same thing, or ditch one for clarity and simplicity. I'm for the latter. geir -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jexl] size method unit test failing
On Tuesday, September 9, 2003, at 10:00 AM, Tim O'Brien wrote:
On Tue, 2003-09-09 at 07:51, Geir Magnusson Jr. wrote:
On Tuesday, September 9, 2003, at 08:25 AM, Tim O'Brien wrote:
On Tue, 2003-09-09 at 06:58, Geir Magnusson Jr. wrote:
I guess we were going to figure out if we want to add the artificial
notion of the length field, or just ask people to use size().
'length'
is really weird, as it doesn't really exist as a field, and only
applies to arrays.
Why confuse the syntax with an additional way to get size?
People may expect length to work, but as long as it is properly
documented for users I see no problem with asking people to use
size()
instead of length.
length is a public final field in all array types,
It's not actually a field right? (in that it's artifically generated
by
the compiler, IIRC) [] aren't objects.
According to the JLS, 2nd ed. {4.3.1} an object is a class instance or
an array . Then according to {10.7} With a public field length - it
goes on to demonstrate that an type resembles a class with a public
member length. My problem with the JLS is that I think section 10.7 is
a lie ( or at least an unkept promise ). Type creating a double[]
array it is certainly an object, but calling
array.getClass().getFields() returns a zero-length array.
So to answer your question, from a *strict* reading of the JLS spec, it
is a field [Class.getFields() should return length], but in reality
it
is not a field.
Ah. Thanks. I had just seen it as a creation by the compiler. Sounds
like it should be a field then according to the spec, and javac is
doing it wrong?
but from what I see
ASTIdentifier just delegates to ASTArrayAccess which then decides how
to
deal with an identifier (isMap - isList - isArray - bean prop).
We could just as easily add a step after accessing a bean property in
ASTArrayAccess which tried to access a public field. What do you
think?
I think that just using size() is the right way to go.
We want to avoid the situation where you have to know the exact type
of
the referent to use it. Conversely, you'd want the data model to be
able to change (say substitute a j.u.List for an []) w/o the script
using jexl having to change.
I agree, once I get Generics - I'm going to forget Object[] altogether
and change my code to using collections.
Sometimes I miss C++ :)
If you believe that those two reasons are good, then either you have
to
make length behave exactly like size(), having two 'methods' that do
the exact same thing, or ditch one for clarity and simplicity.
clarity and simplicity plus documentation and we're done.
Shall I remove the offending line from the unit test then?
I think so, if no one else has a problem with not having 'length'.
Speaking of documentation, any objections to updating JEXL's site,
documentation, and changing the commons like to go to the mavenized
project site?
Well, I do, but I realize I'm swimming upstream here. :)
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
[EMAIL PROTECTED] 203-247-1713(m)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jexl] arrays?
This would be of much use, wouldn't it...
On Friday, March 28, 2003, at 06:38 PM, Mark R. Diggory wrote:
Maybe if I give brief example I can get an answer, I have the
following situation where I'd like to use a double[] to instantiate
into a property of a target.
j:set target=${model} property=landReproductionTable
value=${LR0}, ${LR1}, ${LR2}, ${LR3}, ${LR4}/
currently, I've been handing it in as a string and parsinging it
internally in the object back into a double[]. Since JEXL's site is
limited in its documentation, I cannot see if it is possible to do
something like the following instead:
j:set target=${model} property=landReproductionTable value=${[
LR0, LR1, LR2, LR3, LR4]}/
Yes, we can add the [ ref [, ref]* ] (whatever :) - I can't see
much of a downside there. We do the same thing in Velocity and it's
very useful.
We also allow ranges with similar notation -
[1..10]
returns an ArrayList with Integers 1..20 inclusive
the one question I'd ask is what would the array be? In vel we use an
j.u.ArraList as the implementation, rather than an array [], which I
think is much nicer.
Comments?
-Mark
Mark R. Diggory wrote:
Is there a way to deal with creating arrays in jexl?
I'm used to doing things like this in java inlines
new String[]{foo,bar};
Something similar in JEXL would be very powerfull.
-Mark
-
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]
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
[EMAIL PROTECTED] 203-247-1713(m)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jexl] div
On Thursday, March 6, 2003, at 05:10 PM, bob mcwhirter wrote: Howdy-- Jexl seems to implement 'div' as simple division, instead of the pair with 'mod'. I'd like to correct it. Was this a design though, for 'div' to be divison, and not the typical div operator? -bob It's supposed to be /. There is supposed to be a pairing of / and div, % and mod as far as I can read the JSTL spec. However, if you need both / and the real div, we should consider it. It's a break from JSTL, something that worries me. (Although it can be fairly argued we aren't compatible, I am hoping to get that way...) geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] [jexl] ${in} ?
On Thursday, March 6, 2003, at 10:30 PM, bob mcwhirter wrote:
This is probably in the same boat as the 'size' lexing issue,
but I'm finding impossible to use a variable named ${in}.
G. Ok - I'll add a test case and get it.
Thanks!
'bamphf'?
Onamonapia... the sound made when your hand collides
with the side of my head.
Hm. Try as hard as I might, I keep hitting myself and it doesn't sound
like that. let me see if it sounds that way when when I try it on
someone else.
whack
Nope. More like a 'whack'.
Uh oh - they look mad. Gotta go...
geir
-bob
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
[EMAIL PROTECTED] 203-247-1713(m)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jexl] div
On Friday, March 7, 2003, at 10:39 AM, bob mcwhirter wrote: Jexl seems to implement 'div' as simple division, instead of the pair with 'mod'. I'd like to correct it. Was this a design though, for 'div' to be divison, and not the typical div operator? -bob It's supposed to be /. There is supposed to be a pairing of / and div, % and mod as far as I can read the JSTL spec. Yah, the semantics of '/' seem right, in that they perform division where ( int / int ) yields a float. But 'div' should do real div, at least in my mind (though, I can understand if you're following a broken spec) and yeild an integer from (int div int), but it doesn't. I have no real knowledge, but am guessing that the tokens 'div' and 'mod' are there to give people an alternative to having '/' in XML-ish looking things. So, we have 2 ways to mod, 2 ways to divide, an 0 ways to div. However, if you need both / and the real div, we should consider it. It's a break from JSTL, something that worries me. (Although it can be fairly argued we aren't compatible, I am hoping to get that way...) I think division is obviously needed, but I don't know if we need 2 tokens to do it. Having 'div' to what most folks consider to be 'div' would be a Good Thing. Then we should shoot 'mod' if we are going to break. Hm. Would a idiv or something be sufficient? We'd have to document. I'm going to re-read the JSTL spec to see if I messed this up. geir -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Pressing on with core release
On Tuesday, February 18, 2003, at 03:25 PM, Morgan Delagrange wrote: Hey all, So, what's the next step? I think we need to fix or at least document the remaining bugs, maybe figure out how to structure the distribution. Should we do an official beta release now, or should we skip that step and go right to RC? My only big release concern at the moment is the state of our dependencies. Some of those dependencies (e.g. Jexl) look like they are early beta. Is it OK to release Jelly with some beta dependencies, and if not what are we going to do about it? I'm working on the big problems in Jexl now - I would think that you have to just go with it as beta until they are resolved. - Morgan = Morgan Delagrange http://jakarta.apache.org/taglibs http://jakarta.apache.org/commons http://axion.tigris.org http://jakarta.apache.org/watchdog __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need JJAR for VelTags ASAP
On Sunday, February 16, 2003, at 01:42 AM, Hanasaki JiJi wrote: downloaded the nitely src for velocity and need to build the veltags. Do you mean the velocity JSP tag? ant getjars tries to contact and fails becuase I am behind a firewall. anyay to tell ant to use an http proxy? doesnt really matter since this link doesnt respond to a web browser either http://207.138.188.222/jjar/jjar.jar So... How can I get jjar? or at least get to my goal of a working veltags.jar? Thanks -- = = Management is doing things right; leadership is doing the = = right things.- Peter Drucker= =___= = http://www.sun.com/service/sunps/jdc/javacenter.pdf = = www.sun.com | www.javasoft.com | http://wwws.sun.com/sunone = = - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need JJAR for VelTags ASAP
Lets take this over to the Velocity list - it doesn't really involve JJAR On Sunday, February 16, 2003, at 01:18 PM, Hanasaki JiJi wrote: yes. check the link I posted below. I am trying to get the tools to use a velocity macro in a jsp. The project is all jsp/struts/tiles and I will be adding a single jsp with one simple vel: tag + a #parse this should give me velocity marcos and only require the jsp to be compiled one, right? Geir Magnusson Jr. wrote: On Sunday, February 16, 2003, at 01:42 AM, Hanasaki JiJi wrote: downloaded the nitely src for velocity and need to build the veltags. Do you mean the velocity JSP tag? ant getjars tries to contact and fails becuase I am behind a firewall. anyay to tell ant to use an http proxy? doesnt really matter since this link doesnt respond to a web browser either http://207.138.188.222/jjar/jjar.jar So... How can I get jjar? or at least get to my goal of a working veltags.jar? Thanks -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jexl] empty operator
Fabulous :) thx On Thursday, February 13, 2003, at 01:21 PM, O'brien, Tim wrote: There was some talk on taglibs-user about EL empty only working with java.util.Map and java.util.List. here's a (simple) patch for jexl that makes ASTEmptyOperator work for all Collections. Tim O'Brien ASTEmptyFunction_patch.txt--- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jexl] I assume that the build.xml came from maven?
On Saturday, February 8, 2003, at 08:20 AM, [EMAIL PROTECTED] wrote: Geir, Geir Magnusson Jr. [EMAIL PROTECTED] wrote on 08/02/2003 10:22:47 AM: Suggestion - might be nice to have a header in it, something like : !-- build.xml generated by maven from project.xml version VERSION on date -- or something. This has just been added to Maven's CVS, so that any build files generated from now on will have version, date and time in the comment. Cool! -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jexl] I assume that the build.xml came from maven?
On Friday, February 7, 2003, at 06:32 PM, bob mcwhirter wrote: Does jexl support div/mod? My experiments suggest not. Or would you consider them not working to be a bug? Yes. Will fix. geir -bob On Fri, 7 Feb 2003, Geir Magnusson Jr. wrote: Suggestion - might be nice to have a header in it, something like : !-- build.xml generated by maven from project.xml version VERSION on date -- or something. I guess that I should just go suggest that in maven-land Working on fixing the failing test cases. geir -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Bob McWhirter[EMAIL PROTECTED] The Werken Company http://werken.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jexl] commons website
On Thursday, February 6, 2003, at 01:49 PM, robert burrell donkin wrote: On Thursday, February 6, 2003, at 03:29 AM, Geir Magnusson Jr. wrote: On Wednesday, February 5, 2003, at 02:51 PM, robert burrell donkin wrote: i've updated the website. or downdated :) Can we either keep it the way it was, like the commons site, or make the commons site like it? It's a visual shock to switch between them. sorry about that geir - i couldn't find a jexl.xml in jakarta- commons/xdocs so i assumed that you were using maven. i've copied jakarta-commons/jexl/xdocs/index.html to jakarta-commons/xdocs/ jexl.xml and regenerated the commons site - so hopefully now it should be more to your liking. My liking is just one data point. I was excited to see jexl promoted to be with the 'adult projects' :) and went to the commons site, and then clicked into jexl. The whole 'feel' changed. No judgment offered on the maven look but it was the abrupt transition that got me. I've been rather busy* lately, and haven't been tracking things - was there discussion about making the looks of mavenized things to be like commons, or commons to be like maven, or have I just tossed a match into something I shouldn't have? geir * statement nominated for Understatement of the Year -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jexl] I assume that the build.xml came from maven?
Suggestion - might be nice to have a header in it, something like : !-- build.xml generated by maven from project.xml version VERSION on date -- or something. I guess that I should just go suggest that in maven-land Working on fixing the failing test cases. geir -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote jexl from commons sandbox to commons
I thought we had this vote already. +1 On Monday, January 27, 2003, at 01:00 PM, robert burrell donkin wrote: jexl is a simple expression language for accessing java objects. it is used extensively by jelly. jexl has been (relatively) stable for a while. jelly is pushing towards it's first release. the time therefore seems right for jexl to be promoted to the commons. - 8 - Vote to promote the Jexl component from Commons Sandbox to Commons Proper: [ ] +1 I am in favor of this action and will help [ ] +0 I am in favor of this action but cannot help [ ] -0 I am not in favor of this action [ ] -1 I am opposed to this action and here is why: - 8 - here's my +1 - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jexl] commons website
On Tuesday, February 4, 2003, at 02:06 PM, robert burrell donkin wrote: i'm keen to get jexl a proper commons website now that it's been promoted. i need to modify a few files in jexl and so i'm going to add myself to the list of committers unless - that is - someone wants to jump in with an objection about now... Go for it - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jexl] commons website
On Wednesday, February 5, 2003, at 02:51 PM, robert burrell donkin wrote: i've updated the website. or downdated :) Can we either keep it the way it was, like the commons site, or make the commons site like it? It's a visual shock to switch between them. jexl's site has some features which are a bit unusual for a maven generated commons site. it's side bar is an old copy of the main commons navigation bar. also, it's project.xml does not extend ../project.xml. i'm not too bothered about the second bit but i'd like to remove the commons-style elements from the jexl navigation bar since i think that we' ll be fighting a losing battle to keep them up consistent with the main site. if no one shouts, i'll probably do this sometime. - robert On Wednesday, February 5, 2003, at 12:18 PM, Geir Magnusson Jr. wrote: On Tuesday, February 4, 2003, at 02:06 PM, robert burrell donkin wrote: i'm keen to get jexl a proper commons website now that it's been promoted. i need to modify a few files in jexl and so i'm going to add myself to the list of committers unless - that is - someone wants to jump in with an objection about now... Go for it - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-247-1713(m) [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] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] release issue - jexl dependency
Heh. +1 And I'll have to get off my keister and knock those bugs off :) On Monday, January 27, 2003, at 06:53 AM, James Strachan wrote: +1 James --- http://radio.weblogs.com/0112098/ - Original Message - From: Morgan Delagrange [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Saturday, January 25, 2003 9:52 PM Subject: Re: [jelly] release issue - jexl dependency +1 on promoting jexl to commons. - Morgan --- robert burrell donkin [EMAIL PROTECTED] wrote: AFAIK jelly depends on jexl. jelly has been promoted (but hasn't yet been transferred). i don't think that jexl has been promoted - it's certainly still in the sandbox. i don't think that jelly should have rely on an unreleased version of a component - and jexl can't have a release since it's in the sandbox. should we start pushing for jexl to be promoted and (at least an alpha) jexl release created? - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] = Morgan Delagrange http://jakarta.apache.org/taglibs http://jakarta.apache.org/commons http://axion.tigris.org http://jakarta.apache.org/watchdog __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr 203-355-2219(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] moving Jelly to the commons proper
On Friday, December 6, 2002, at 09:13 AM, James Strachan wrote: The Jelly code base has been stable for some time and it'd be good to get a stable release of Jelly out so other projects like Maven, Cactus and Latka can depend on a stable, supported release. So I'd like to propose that Jelly be moved to the commons proper where we can start work on getting things in place for an official release. I'm +1 - Cut Here - I vote as follows on moving Jelly to the Commons Proper: [ ] +1 - I support this move and am willing to help [X] +0 - I support this move, but cannot assist [ ] -0 - I don't support this move [ ] -1 - I vote against this move (requires valid *technical* reasoning) - Cut Here - James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr 203-355-2219(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: moving to a top-level project (was: [Ant nudge STATUS] Betterthanwe thought...)
On 10/29/02 12:15 AM, Michael A. Smith [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: On 10/28/02 8:23 AM, Greg Stein [EMAIL PROTECTED] wrote: On Sun, Oct 27, 2002 at 04:08:02PM -0500, Michael A. Smith wrote: ... So, to clarify, committers on jakarta-commons voted for creating a management body of the code within the jakarta-commons cvs repository. Costin calls this the commons PMC, although the distinction should be made that this is not a board-recognized PMC. And to prevent confusion, I would highly suggest that the jakarta-commons committers find and use a different name than pmc. Otherwise, there will always be a to clarify when talking about it :-) Sorry - I missed something. What did we vote on? I saw some discussion, but I didn't see a vote for anything... I must have missed it. Search for subject Proposal: httpd-like PMC organisation First in thread was [EMAIL PROTECTED] (Message-ID: ap4a0j$lf5$[EMAIL PROTECTED]) Your response in the thread can be found at [EMAIL PROTECTED] (Message-id: [EMAIL PROTECTED]) regards, michael And that was considered a *vote*?? -- Geir Magnusson Jr. [EMAIL PROTECTED]+1-203-355-2219 (w) Adeptra Inc. +1-203-247-1713 (m) -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: moving to a top-level project (was: [Ant nudge STATUS] Betterthanwe thought...)
On 10/29/02 2:42 PM, Michael A. Smith [EMAIL PROTECTED] wrote: On Tue, 29 Oct 2002, Geir Magnusson Jr. wrote: On 10/29/02 12:15 AM, Michael A. Smith [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: On 10/28/02 8:23 AM, Greg Stein [EMAIL PROTECTED] wrote: On Sun, Oct 27, 2002 at 04:08:02PM -0500, Michael A. Smith wrote: ... So, to clarify, committers on jakarta-commons voted for creating a management body of the code within the jakarta-commons cvs repository. Costin calls this the commons PMC, although the distinction should be made that this is not a board-recognized PMC. [SNIP] Sorry - I missed something. What did we vote on? I saw some discussion, but I didn't see a vote for anything... I must have missed it. And that was considered a *vote*?? It was discussion on a proposal in which many of the respondents replied with a vote (i.e. +1). Thus, those respondants voted on the proposal. Whether you call that a vote or not, I don't particularly care, as I never said there was a vote. Just said that people voted. Sorry if the terminology is a bit misleading. Ok. It's really important that it isn't misleading. Voting is the primary way we decide things, and 'vote' has specific meaning to the wider Apache community. You could also say that There was a discussion that some people were supportive of... which is a bit more accurate than committers on Jakarta-commons voted for... geir -- Geir Magnusson Jr. [EMAIL PROTECTED]+1-203-355-2219 (w) Adeptra Inc. +1-203-247-1713 (m) -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: moving to a top-level project (was: [Ant nudge STATUS] Betterthanwe thought...)
On 10/29/02 2:53 PM, Costin Manolache [EMAIL PROTECTED] wrote: On Tue, 2002-10-29 at 11:22, Geir Magnusson Jr. wrote: And that was considered a *vote*?? It was more of an opinion poll - and most people were positive about this ( and expressed that with a +1 ). In a later message I asked to postpone this - until the issues become clear ( naming, legal, etc ) Great. Perfect description. Not disputing the general sentiment (I still think it's moving deck chairs around if you move every committer into the PMC). My problem was simply that representing to reorg@ that there was a vote in which the jakarta commons committers decided to form a PMC-ish structure was not correct. The open questions are: - can jakarta PMC recognize jakarta-commons SPMC and delegate oversight officially ? Good question, and I don¹t see why we couldn't ask, although - if that's not possible, can jakarta-commons form a PMC and ask the ASF board to recognize it ? ( it seems implied that tomcat or ant could do that easily ). If so, can it remain part of jakarta ( and eventually extend/merge with xml.apache.org ) Yes, it could. I would really be against J-C separating from jakarta in any way. Renaming all committers to be members of the PMC again seems like window dressing until you educate those committers about their responsibilities - where I then wonder if there is education to be done, why don't we just do it? - technical details: who is part of the SPMC ( my initial proposal was 'all active committers who like to be', maybe with a 1-2 month delay for very new committers ). I'm sure other opinions will be raised on this. This is why I think it's window dressing - why would you *not* allow a committer to be participant in the PMC? Would that reason, whatever it is, be a reason for them not to be a committer? Don't we believe that when we make someone a committer, its because they have shown they share the vision and are willing to take responsibilty? It's more than just the ability to 'cvs commit'. Just curious - I am asking the same questions about HTTPD and APD, as it sounds like it's pretty much the same thing. They assure me it's not, for example the HTTPD PMC election is based on 'merit', where the Jakarta PMC is a 'popularity contest', but no one has yet to define the difference. To me, merit would be objective, popularity would be subjective. However, there are no objective measures of merit here, only opinions of those voting. (HTTPD has the curious feature that only the existing PMC can vote in new members, not the rest of the community... I have yet to ask about that) My work in Velocity is really valuable to some people (like myself :), but someone else, say someone working on Jasper, might not think so and believe it is anti-Apache, for example, as one of it's benefits is to 'undermine' a standard, JSP, through the offering of an alternative. -- Geir Magnusson Jr. [EMAIL PROTECTED]+1-203-355-2219 (w) Adeptra Inc. +1-203-247-1713 (m) -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: moving to a top-level project (was: [Ant nudge STATUS] Betterthanwe thought...)
On 10/29/02 4:04 PM, Costin Manolache [EMAIL PROTECTED] wrote: On Tue, 2002-10-29 at 12:13, Geir Magnusson Jr. wrote: Great. Perfect description. Not disputing the general sentiment (I still think it's moving deck chairs around if you move every committer into the PMC). I think it's more about a consistent naming and organization with the rest of apache ( and the httpd project where all things started ). Ok - that's fine. But note that httpd and jakarta are different (for what I know of httpd...). I don't think Jakarta is all bad, and think that changes should be made to improve things. It is also a good opportunity to improve few things: - find who's tracking what component. That would be good, but don't we know that from the status files ? - better tracking of who's active ( if we use 'active committer' def. ) How? Once on the PMC, your are on, right? - a way to better pass the message and get people involved in the monitoring activity I don't see how a new title and mail list will change anything. If we have to start changing the values of the community, we can do it directly. If there are things we have to change, it's our responsibility as committers to do it. My view was a global 'SPMC' file listing all the people _and_ the components he's volunteering to monitor ( even if he's not actively working on it ). STATUS tracks who's working on what. Ok - why not just make the file then? I am sure that every active committer will step up to do this. The thing that we do get out of this is a formal accountability to the ASF - but it strikes me as strange that we take all (or most) committers, define them to be the PMC, and all of a sudden accountability happens. Do you see what I mean? Seems like we have a problem if our committers aren't responsible and willing to be held accountable. We can create some rules so that any committer can join the SPMC by volunteering for some components and participating in some sort of load distribution, and use this as a way to pass information. What information? Why not the usual list? We wouldn't want this to be closed, would we? The open questions are: - can jakarta PMC recognize jakarta-commons SPMC and delegate oversight officially ? Good question, and I don¹t see why we couldn't ask, although - if that's not possible, can jakarta-commons form a PMC and ask the ASF board to recognize it ? ( it seems implied that tomcat or ant could do that easily ). If so, can it remain part of jakarta ( and eventually extend/merge with xml.apache.org ) Yes, it could. I would really be against J-C separating from jakarta in any way. Renaming all committers to be members of the PMC again seems like window dressing until you educate those committers about their responsibilities - where I then wonder if there is education to be done, why don't we just do it? I'm not very sure what education - I suspect we all know the rules. We do need probably a bit more formal organization - and some explicit procedures/rules/plans. Regarding 'separating from jakarta' - I do think that j-c is in a way the 'core' of jakarta ( I don't know any other jakarta sub-project to bring so many people together ). Bingo. +1. Exactly. That was the intent, and that is what we achieved. To break it up or move it in the name of 'community' means someone is missing the point (not you, Costin) But I wouldn't mind opening it up to xml.apache.org people - we already have few great committers from xml working on j-c, and I think it would be great to expand this. Fine - our hurdles for becoming a committer aren't very high. Do we have a problem where XML people aren't being allowed to contribute? I mean, if someone showed up with patches or new code, I think there is enough mixing of the communities that the person would be granted committer status, just like we automatically let in committers from other Jakarta projects, right? - technical details: who is part of the SPMC ( my initial proposal was 'all active committers who like to be', maybe with a 1-2 month delay for very new committers ). I'm sure other opinions will be raised on this. This is why I think it's window dressing - why would you *not* allow a committer to be participant in the PMC? Would that reason, whatever it is, be a reason for them not to be a committer? Don't we believe that when we make someone a committer, its because they have shown they share the vision and are willing to take responsibilty? It's more than just the ability to 'cvs commit'. I think a 1-2 month delay is just reasonable - to let him get used with the environment and the rules. But I'm ok with dropping it ( again, this is my understanding of httpd procedures ). Using 'active' is a way to make sure we have things covered up and to track the people who are involved. If some European committer takes a 3-month vacation he should remove himself from
Re: moving to a top-level project (was: [Ant nudge STATUS] Betterthanwe thought...)
On 10/28/02 8:23 AM, Greg Stein [EMAIL PROTECTED] wrote: On Sun, Oct 27, 2002 at 04:08:02PM -0500, Michael A. Smith wrote: ... So, to clarify, committers on jakarta-commons voted for creating a management body of the code within the jakarta-commons cvs repository. Costin calls this the commons PMC, although the distinction should be made that this is not a board-recognized PMC. And to prevent confusion, I would highly suggest that the jakarta-commons committers find and use a different name than pmc. Otherwise, there will always be a to clarify when talking about it :-) Sorry - I missed something. What did we vote on? I saw some discussion, but I didn't see a vote for anything... I must have missed it. -- Geir Magnusson Jr. [EMAIL PROTECTED]+1-203-355-2219 (w) Adeptra Inc. +1-203-247-1713 (m) -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: Proposal: httpd-like PMC organisation
What's the point? I mean, what problem are we having that this will solve? I know we noted having an oversight committee in the charter, but we seem to have never needed it. Any problems got civilly discuss and solved. geir On 10/22/02 3:45 PM, Costin Manolache [EMAIL PROTECTED] wrote: We already have a line in our charter about having a jakarta-commons specific PMC. Right now it is modeled after jakarta, with 3 members. I would like to propose changing this number to include more people - I think the right solution is more closer to what httpd and apr projects are doing, where the PMC is composed of most active commiters. My proposal is to modify the charter so that a jakarta-commons PMC is composed of all active commiters. This will be volunteer-based, in the sense that any active commiter who wants to become part of the PMC will announce his willingness to participate. Questions: - should we vote on the volunteering offer ? What is httpd doing ? - Should we impose a 2-3 month wait period for new commiters ? ) - should the pmc have a separate mail list ? ( I personally don't think so - but that's how other pmcs are organised ) The commons PMC members will split the task of monitoring the files. All decisions will continue to be taken by majority vote of all jakarta-commons commiters. Not that this is not a proposal to form a top-level project - just to better organise ourself. Jakarta-commons is IMO at the core of jakarta - with the most diverse set of commiters from almost all jakarta projects. Any major issue will be forwarded to the Jakarta PMC. -- Geir Magnusson Jr. [EMAIL PROTECTED]+1-203-355-2219 (w) Adeptra Inc. +1-203-247-1713 (m) -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: What should we do about sandbox ? RE: License and copyright issues
On 10/22/02 12:01 AM, Costin Manolache [EMAIL PROTECTED] wrote: Martin Cooper wrote: I found a few things not yet mentioned: 1) In codec\Metaphone.java, Copyright 1997, William B. Brogden, which is clearly a problem. 2) In scaffold, numerous instances of Copyright (c) 2002 Synthis Corporation., also clearly a problem. Acording to jakarta-commons rules, the sandbox is just a CVS repository where experiments may happen. I see it similar with commiters using their homes or public_html pages on jakarta - or with the commiters cvs repository. The sandbox is open to any jakarta commiter. The question is: do we have to police it and monitor all forms of activities that happen on apache servers ? Because as far as I can see, there is no difference between a file placed by a jakarta commiters on his public_html or home and the files in commons-sandbox. We made it very clear that sandbox code can't be released, and the fact that it is accessible using public cvs and viewcvs is similar with the public_html files. I would propose to ask the sandbox to be removed from viewcvs and the eventually discuss what to do about the public cvs. As a way to protect ourself. I wouldn't mind if this is voted down :-) What do you think about this issue ? Any other proposed solutions ? Kick out any committer that violates this? How about that? It doesn't matter if it can't be released, the fact is that we are offering copyrighted code (not by us) on a public server. There should be no reason to put in the sandbox any code that is copyright someone else. We shouldn't have to change how we use the sandbox - I am sure we have attracted many people with it and helped build the commons community - just because someone screwed up. This is basic stuff. -- Geir Magnusson Jr. [EMAIL PROTECTED]+1-203-355-2219 (w) Adeptra Inc. +1-203-247-1713 (m) -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [commons] Reflection code
On 9/22/02 5:35 AM, Stephen Colebourne [EMAIL PROTECTED] wrote: I took a brief look at the velocity link and its mostly about introspection. I will take a fuller look in a few days. The code for [lang] will be simple reflection helpers, not introspection. However, the fact that you want to do introspection differently from velocity shows to me that we need a commons [introspect] or [clazz] project. That's not what it shows me. :) It shows me I wanted to keep jexl and velocity separate. Velocity has some required behaviors that aren't general (actually, weird..) and I didn't want to work around them in Jexl nor force velocity to change. What I plan to do is sort things out in Jexl, and if indeed it remains general and not specific to Jexl functionality, sure - I'll happily roll it out to a commons component. What I don't want to do is have the tail wag the dog - the introspection functionality is core to Jexl, and as we found out recently, the desire of the many don't always match the requirements of the few. This would hopefully gather together the introspection code from velocity and jexl. It could also enable betwixt and digester to be more flexible in matching property methods. This is currently next on my list after [lang] reflection. Interested? Right now, the Jexl code is the Velocity code, and when I dig out of the current pile of rubble I'm in, the Jexl code will be cleaned up. That would be a good candidate for a general package. So let me see how it works out - again, I don't want Jexl's core functionality be dictated by the requirement of generalization. I am all for generalization if it can be done, but there are some things in the pipeline for jexl that I'm not sure will work out in a general package. Stephen - Original Message - From: Geir Magnusson Jr. [EMAIL PROTECTED] On 9/21/02 12:37 PM, robert burrell donkin [EMAIL PROTECTED] wrote: take a look at package org.apache.velocity.util.introspection (http://jakarta.apache.org/velocity/api/index.html is the api url.) I've also pulled it out and put in jexl, as I want to do thing differently in Jexl than in Velocity. - robert On Saturday, September 21, 2002, at 01:33 PM, Stephen Colebourne wrote: I have started writing the reflection code for the new [lang] reflection subpackage. A fair bit of the basic stuff is now done (its in lang sandbox if you're looking). It still needs tests. What I'm looking for is - any code that already exists for assisting with reflection (I've already got beanutils) - any code that can match classes against the Java LanguageSpecification rules for widening - any tests that already exist for reflection Any code from within commons or elsewhere is welcome to be looked at ;-) Hyperlinks, not attachments, if possible please. Stephen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]. org For additional commands, e-mail: mailto:[EMAIL PROTECTED]. org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. Research Development, Adeptra Inc. [EMAIL PROTECTED] +1-203-247-1713 -- 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] -- Geir Magnusson Jr. Research Development, Adeptra Inc. [EMAIL PROTECTED] +1-203-247-1713 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] James Turner as Committer for Validator
On 9/18/02 11:48 AM, Craig R. McClanahan [EMAIL PROTECTED] wrote: Commons Folks, I'd like to propose James Turner [EMAIL PROTECTED] as a committer on the Commons Validator project (and a new committer to Apache). He has taken the time to understand the Validator code base quite well, submitted many useful bug reports and patches, and has the itch to improve the quality of this component, and has shown remarkable forebearance and persistence in getting paid attention to :-). Here's my +1. Craig McClanahan +1 from a Validator non-participant -- Geir Magnusson Jr. Research Development, Adeptra Inc. [EMAIL PROTECTED] +1-203-247-1713 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JEX wants to play in the sandbox
On 6/12/02 8:49 AM, Dmitri Plotnikov [EMAIL PROTECTED] wrote: Folk, I need your opinion on something. Check out JEX: www.plotnix.com/jex/index.html It is a set of APIs that unifies the use of expression languages. Out of the box it is integrated with the expression language used in BeanUtils (I gave it a nickname Bexl), with Javascript and JXPath. It will also soon be integrated with Jexl. Other possible candidates are Jaxen, SPEL and JPath. The idea is that when you need to evaluate an expression, you provide the name of the language as a prefix, sort of like in the html event handlers: javascript:2+2, jxpath:/foo/bar. You can also have a default language that is used in the absence of a prefix. Check out the APIs and let me know if you believe there is room for JEX in the sandbox. I'll be happy to contribute and maintain it. Any jakarta committer is free to put things in the sandbox, so you can just do this. From the POV of votes of support : go for it. Sounds interesting. -- Geir Magnusson Jr. Research Development, Adeptra Inc. [EMAIL PROTECTED] +1-203-247-1713 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jexl again...
On 6/12/02 1:06 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
The hassle I had with Jexl was using the context to set a variable to a
value to be evaluated later. With Jexl, it meant I couldn't have a string
with the same value as a variable name, i.e. setting 'name' to 'value'
meant if I evaluated 'name' I always got 'value'. Good except that I'm
trying to fit in with ant's property / value naming style.
Ah. I think I understand what you mean. Jelly adds the ${foo} decorations
to allow the distinction between references and constants, and to not
inflict one kind of indicator. So jelly uses ${foo}, but others could do
$foo, %foo, foo, etc... Jexl accomodates all by not inflicting one way on
the user.
If you wanted a constant string 'name', then just put single or double
quotes around it...
'name'
Does that address what you were saying? (I am wondering if I missed your
point...)
Geir
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
Geir Magnusson Jr. [EMAIL PROTECTED]
06/13/02 12:59 AM
Please respond to Jakarta Commons Developers List
To: Jakarta Commons Developers List [EMAIL PROTECTED]
cc:
Subject:Re: jexl again...
On 6/12/02 11:09 AM, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
CoolI've just started the move to Jelly to handle this. It seems a
much cleaner implementation...?
Much cleaner than? Jelly uses Jexl...
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
James Strachan [EMAIL PROTECTED]
06/12/02 08:05 PM
Please respond to Jakarta Commons Developers List
To: Jakarta Commons Developers List
[EMAIL PROTECTED]
cc:
Subject:Re: jexl again...
From: [EMAIL PROTECTED]
1) Are expressions cacheable? i.e. if I create an expression and
execute
it
once, can I store it away in a Map and reevaluate it, rather than
recreating it?
FWIW Jelly creates Expression objects and caches them so that they are
reused inside a Script. The same Expression instance could be reused in
multiple threads too.
James
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
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]
--
Geir Magnusson Jr.
Research Development, Adeptra Inc.
[EMAIL PROTECTED]
+1-203-247-1713
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [vote] CVS access for Martin van den Bemt
On 6/12/02 7:18 PM, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, Martin has been really active providing patches for Betwixt so how about we let him apply the next patch himself. +1 +1 from a non-betwixt contributor -- Geir Magnusson Jr. Research Development, Adeptra Inc. [EMAIL PROTECTED] +1-203-247-1713 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jexl again...
On 6/12/02 7:06 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: 1) Are expressions cacheable? i.e. if I create an expression and execute it once, can I store it away in a Map and reevaluate it, rather than recreating it? Yes -- Geir Magnusson Jr. Research Development, Adeptra Inc. [EMAIL PROTECTED] +1-203-247-1713 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Logging: more classloader problems.
On 6/6/02 2:08 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Solution: Split commons-logging.jar in commons-logging-api.jar ( only the API and the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar. :) -- Geir Magnusson Jr. Research Development, Adeptra Inc. [EMAIL PROTECTED] +1-203-247-1713 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Logging: more classloader problems.
On 6/6/02 3:18 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Thu, 6 Jun 2002, Geir Magnusson Jr. wrote: On 6/6/02 2:08 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Solution: Split commons-logging.jar in commons-logging-api.jar ( only the API and the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar. :) If you knew that keeping the adapter in the same jar will brake tomcat, why didn't you say so ??? :-) I remember all kind of crazy arguments - but never saw this one. I wanted to split out the factory impl from the api jar for other reasons, feeling that the clean break between API and impl was good, but wondered about the classloader implications. Of course, I didn¹t realize it would break tomcat. I would have said something specific if I had. The :) is just because the idea makes me happy. Actually the default logger ( used if no 'real' logger is found ) and the JDK1.4 adapter will have to remain in the main jar ( unless we want to support an alternate impl. for JDK1.4 logging - is it even possible ? ) Why would it have to remain? (I'll stop the xposting after this one and keep it on commons...) -- Geir Magnusson Jr. Research Development, Adeptra Inc. [EMAIL PROTECTED] +1-203-247-1713 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Logging: more classloader problems.
On 6/6/02 3:47 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Thu, 6 Jun 2002, Geir Magnusson Jr. wrote: Actually the default logger ( used if no 'real' logger is found ) and the JDK1.4 adapter will have to remain in the main jar ( unless we want to support an alternate impl. for JDK1.4 logging - is it even possible ? ) Why would it have to remain? (I'll stop the xposting after this one and keep it on commons...) The 'simple' logger ? Because it's very possible ( even likley ) to not find any other logger, and it's important to get at least something on stderr to know that things don't work. It would be very bad to have major errors but see nothing because a logger was not found. Plus for simple apps you don't need a real logger. Sorry - was thinking about the jdk1.4. Agreed with the default stdout logger... For JDK1.4 ? I don't know, it seems it doesn't work otherwise, probably I'm doing something wrong. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. Research Development, Adeptra Inc. [EMAIL PROTECTED] +1-203-247-1713 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters)
+1 from a non-participant... On 6/5/02 6:49 AM, James Strachan [EMAIL PROTECTED] wrote: - Original Message - From: Jason van Zyl [EMAIL PROTECTED] It now looks like the bugs have been squashed so how about we propose to move Betwixt up to the commons proper and do a release? Sounds good with me. Lets do it in 2 stages, move to commons proper first, then leave it a couple of days to check that noone can find any more bugs, then lets call another vote to release it. So here's the first vote, to move betwixt to commons proper. Already there's 4 developers and several projects using betwixt so I think it passes all the conditions. http://jakarta.apache.org/commons/sandbox/betwixt/developer-list.html I'm +1 James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. Research Development, Adeptra Inc. [EMAIL PROTECTED] +1-203-247-1713 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JJar via authenticating proxy
On 6/3/02 7:22 AM, Ross Gardler [EMAIL PROTECTED] wrote: (copied back to jakarta-commons in case anywone there has a better idea) I assume that you didn't guess I sent it privately for a reason? I didn't want there to be any expectation of delivery, as I have an awful track record lately on this... But I am working to use for a client, so I expect it'll roll soon. sigh Geir Magnusson Jr. wrote: Is it possible to use the JJar ANT task via an authenticating proxy? It works fine through a non-authenticating proxy using the http.proxyHost and http.proxyPort system properties, but with an authenticating proxy a 407 (authentication failure) is returned. Working on JJAR now, and will be posting code back to commons in the next week or so. How would this work? How do you specify the auth info? This issue has come about on the Centipede build system which uses JJar (www.krysalis.org/centipede). The following code snippet illustrates how to connet to an authenticating server: [SNIP] That is what I thought - the standard HTTP basic auth stuff. I have the same code elsewhere I can roll in. 1. Put the username and password in the ANT build file and pass them to the JJAR test 2. Have ant ask for the username and password interactively and pass the values to the JJAR task 3. Define our own System propoerties to hold the username and password and have JJAR extract them from there 1 3 have a problem in that we either have to force the user to encode the values before setting them or we create a security problem by storing them unencoded. Well, uuencoding doesn't make anything secret, just gibberish at first glance. And since we would be sending what is effectively cleartext anyway... 2 is perhaps the best. We could set a property in the build file indicating whether we are connecting through an authenticating proxy or not, thus prompting the user for username and password. Furthermore, using this method we allow the user to decide if they want to store the username/password in the build file and thus prevent the need to type them each time. What do you think? The problem with 2 is that it doesn't work for anything automated - for example a build system that is run automatically for testing would need to have the values somewhere. I think what we need is to give people the choice - one option to specify the values like #1, and one for #2, so if you want to keep it secret and do interactively, you can. Since we are talking about a security system that does everything in cleartext, doing something fancier doesn't make sense at first. -- Geir Magnusson Jr. Research Development, Adeptra Inc. [EMAIL PROTECTED] +1-203-247-1713 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [commons committer vote II]
On 5/24/02 12:46 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Again, my +1. I've seen only 2 patches from Richard on commons-logging, but he is a commiter on axis, and I think it's important that other apache projects that use/depend on our stuff and want to contribute and make fixes can do that with minimal pain. I think that's the base idea of 'commons', and I will vote +1 on any apache commiter who has patches and is interested to become a commiter in commons. (and no, I don't want to open another flame war with Geir :-) No flame war required. He's involved in the community here, cares about what happens to the component he is involved in, is a Jakarta committer elsewhere, and contributes code to the subcomponent here. Why would I have a problem? +1 to Richard from me. geir Costin On Fri, 24 May 2002, Richard Sitze wrote: costin nominated me a few days back, but not under a 'vote' subject line - so I'm hoping that the lack of votes was due to unawareness of the vote occuring... I'd like to proceed with some changes that I submitted earlier, so may I be so forward as to reopen the vote with a new subject line? *** Richard A. Sitze[EMAIL PROTECTED] CORBA Interoperability WebServices IBM WebSphere Development -- 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] -- Geir Magnusson Jr. Research Development, Adeptra Inc. [EMAIL PROTECTED] +1-203-247-1713 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [jexl] double array lookups not quite working yet...
On 5/20/02 6:52 AM, James Strachan [EMAIL PROTECTED] wrote:
I've just added a test case to jexl in the sandbox that double array lookups
are not quite working properly. Double array lookups can be useful when
using the SQL tags from JSTL.
e.g. in Jelly I hit this problem when trying to output the first field of
the first row using...
sql:query var=results
select * from foo
/sql:query
j:expr value=${results.rowsByIndex[0][0]}/
Indeed. Will get that in shortly.
--
Geir Magnusson Jr.
Research Development, Adeptra Inc.
[EMAIL PROTECTED]
+1-203-247-1713
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Resisting the temptation
On 5/10/02 9:17 AM, James Strachan [EMAIL PROTECTED] wrote: Hi Ceki Anyone who uses the digester needs digester, beanutils, collections and logging. Its a shame there's not just a single jar for all these 4 (very common) things. How about we bundle these 4 things into a single 'uber-jar'? Say, commons-core.jar. We could maybe ensure that whenever we release one of these 4 jars, we release the whole bundle (commons-core) together too. Or we could just get jjar/maven rocking... :-) The real problem is the digester dependency on logging, isn't it? A solution I can think of is for log4j to have a services entry in their jar's META-INF to be the logger factory for logging. geir -- Geir Magnusson Jr. Research Development, Adeptra Inc. [EMAIL PROTECTED] +1-203-247-1713 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Resisting the temptation
On 5/10/02 10:49 AM, Richard Sitze [EMAIL PROTECTED] wrote: Ceki, You don't need complete dependence on commons-logging. About a month back there was a discussion on separating the interface from the implementation (separate packages and probably separate jar files), and really making the interface independent. The possibility of obtaining a truly independent common interface shared by (that is implemented by both) commons logging and Log4J might lend enough weight to push such an idea through. LOL. I love this. You are the wind beneath my wings on a down day. No matter what comes out of this, you made my afternoon. :) geir -- Geir Magnusson Jr. Research Development, Adeptra Inc. [EMAIL PROTECTED] +1-203-247-1713 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Promote Modeler from Sandbox to Commons, Release 1.0
On 4/30/02 12:15 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: The modeler package in jakarta-commons-sandbox provides easy APIs to create Model MBeans (see the JMX Specification) in server-side applications, based on configuration data loaded from an XML document. It is used in the nightly builds of Tomcat 4 (and in the Tomcat 4.1.0 test release) to provide the back-end JMX MBeans required for the new administrative web application in Tomcat. The code has been stable for several months, and there are no outstanding bug reports against it. I am calling this vote to (a) promote the modeler package from the sandbox to commons proper (with the initial developers as listed in the STATUS.html file), and (b) release the current modeler code base as a 1.0 release (I will act as release manager). Because these are two different actions, I've listed the votes separately in case people have different opinions about the two actions (although the first is a prerequisite for the second). -- Cut Here -- Vote to promote the modeler package from Sandbox to Commons proper [ ] +1 I am in favor of this action and will help [X] +0 I am in favor of this action but cannot help [ ] -0 I am not in favor of this action [ ] -1 I am opposed to this action and here is why: Vote to release Commons Modeler 1.0: [ ] +1 I am in favor of this action and will help [X] +0 I am in favor of this action but cannot help [ ] -0 I am not in favor of this action [ ] -1 I am opposed to this action and here is why: -- Cut Here -- I am +1 on both of these. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting They that can 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: [VOTE] Promote Modeler from Sandbox to Commons, Release 1.0
On 4/30/02 1:16 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Tue, 30 Apr 2002, Craig R. McClanahan wrote: Vote to promote the modeler package from Sandbox to Commons proper [X] +1 I am in favor of this action and will help [ ] +0 I am in favor of this action but cannot help [ ] -0 I am not in favor of this action [ ] -1 I am opposed to this action and here is why: I think the text and will help is not needed in this case, it's just about promoting the component. And I believe that a sandbox component that is actively used in one jakarta project ( with an aproved plan of release ) shouldn't even need a vote to get into common proper and be released. I think it should. Suppose I wanted to do my own , even if there is a perfectly good one in commons... Take for example logger. I had an idea, proposed it, we discussed it, and it didn't happen. (I still have a follow-up for the list... But it's been busy lately.) I have no problem with this, and I think it was good to go through the discussion. I still don't agree 100% with all the views expressed, but I respect all of them, and see the merits. Now, suppose I didn't like that outcome, and did a logger copy with some slight change, and called it TheLogger. According to your suggestion, I could incorporate in Velocity or make available as a component in Turbine, drop into sandbox, and keep moving it right through to Commons. I don't like this - I think multiple solutions to the same problem is a good thing, but I think the community should have a chance to decide what is appropriate for commons and has therefore must support. I will always hope that duplication is supported by commons as long as that duplication has a 'positive' point (different approaches to solve the same problem, for example). The hypothetical example above really has no positive outcome for the community, and would be confusing to anyone looking at whats available in commons. I realize that in every case encountered so far, there has been no problem. Just wanted to point out a possibility. Vote to release Commons Modeler 1.0: [ ] +1 I am in favor of this action and will help [X] +0 I am in favor of this action but cannot help [ ] -0 I am not in favor of this action [ ] -1 I am opposed to this action and here is why: Can't help ( and I prefer Dynamic MBeans ) :) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting They that can 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: [VOTE] Promote Modeler from Sandbox to Commons, Release 1.0
On 4/30/02 5:09 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Tue, 30 Apr 2002, Geir Magnusson Jr. wrote: one jakarta project ( with an aproved plan of release ) shouldn't even need a vote to get into common proper and be released. Now, suppose I didn't like that outcome, and did a logger copy with some slight change, and called it TheLogger. According to your suggestion, I could incorporate in Velocity or make available as a component in Turbine, drop into sandbox, and keep moving it right through to Commons. Nothing can stop you from writing TheLogger - except other Turbine or Velocity commiters who may -1 it. If the Turbine/Velocity community believes it is indeed needed and benefical for them to create another logger - and this becomes a part of the release, then I think it doesn't matter too much if you release it as a component of Turbine or commons. Except I think that the committers of Commons should have the say in what happens in their community, rather than letting another subproject decide for them. And if you think other projects may be interested and use TheLogger, I think it is perfectly justified to have it in commons. It won't be called commons-logging ( you need another name ), and it won't replace commons-logging. But Velocity can continue to use whatever logger they choose. I think you are missing my point -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Community (was: Re: You make the decision (was Re: Quick!convertall yourprojects to maven!))
On 4/30/02 6:21 PM, Amir D. Kolsky [EMAIL PROTECTED] wrote: I am very weary of any NIH type sentiment, is it might eventually lead to massive wastes of effort. I am aware of neither Maven nor Krysalis, so I can't comment on anything but the dogfood sentiment. Dogs don't really care where their food come from, they just eat it... I think that depends on the dog... -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting You're going to end up getting pissed at your software anyway, so you might as well not pay for it. Try Open Source. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Commons-API (was Re: [pool] PROPOSAL: add collectingof statistics to pool implementations)
On 4/26/02 2:54 PM, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: I have tried myself to make projects cooperate on Jakarta, and there are cases in which one part simply refuses to do it. This is the reason why there are duplicate projects, and why projects keep making subprojects that have less an less to do with the original project. That's *one* reason why. Sometimes just taking a different path to solutionof the problem is the reason, and that's good enough. (See Turbine + Struts) It seems to me, and to many outside viewers, that there is a sort of anarchy in the way subprojects are created, making code duplication a reality. Which I think has some very positive qualities. There is not a unified vision, if not the Apache license and the server mission. Indeed. I can live with this, and I see that it can bring good things. If projects compete, they can benefit from each other, since the source is there to see and the license permits it. The downside is how we are seen from the outside... -oOo- IMHO Jakarta should favor the use of common interfaces. No. I think subprojects should do whatever the participants in the subproject decide. If there is a compelling set of interfaces or components and they wish to use them, that's great. If not, that's great. Interfaces can become standards, and this is how Apache can create de-facto APIs. This way projects can give the user functionality without locking him into their API for common functionality. What about *Commons-API*? Kinda smells like a framework. :) We have a de-facto commons API. That's what the components are, all independent, and the overlap in the community means that there tends to be quite a bit of interdependence between them, which strengthens those that seem to work well. So I would say that in a sense, we already have one. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting We will be judged not by the monuments we build, but by the monuments we destroy - Ada Louise Huxtable -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-commons-sandbox/jexl/examples ArrayExample.class ArrayExample.java MethodPropertyExample$Foo.class MethodPropertyExample.class MethodPropertyExample.java
On 4/26/02 12:50 AM, Tim Vernum [EMAIL PROTECTED] wrote: Did you really intend to checkin the class files ? geirm 02/04/25 21:47:04 Added: jexl/examples ArrayExample.class ArrayExample.java MethodPropertyExample$Foo.class MethodPropertyExample.class MethodPropertyExample.java Whoops - sorry. Thanks! NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. NOTICE This e-mail and any attachments are *not* confidential as it's going to a public list. :) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting You're going to end up getting pissed at your software anyway, so you might as well not pay for it. Try Open Source. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JJAR] Status? Jar Repository?
On 4/17/02 6:23 PM, James Strachan [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Scott Sanders [EMAIL PROTECTED] wrote on 17/04/2002 07:32:44 AM: Gier is correct. In the end jjar gets jars. Maven is an entire build methodology. JJAR is a tool, with no meaning unless used in a larger context. Thanks for clearing that up. I was really confused :-) I was just about to check out the build process in JJar Maven could be a consumer of JJAR's work. And vice versa. JJar could use Maven to get it going faster Agreed. Maybe JJAR could suck out the dependency information from Maven project.xml files? That's possible - it could be an alternate repository that's supported to allow a mavenized project to just have one dependency declaration... -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting The greatest pleasure in life is doing what people say you cannot do. - Walter Bagehot -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JJAR] Status? Jar Repository?
On 4/16/02 8:31 AM, Tomasz Pik [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: Yes, I did a bit of cleanup that I have to commit. The big change will be the namespace of jar/project names to try and avoid collisions. Two problems that appears during using of JJar: 1 there soluld be a possibility to specify full url to jar file (maybe something like xml:base) 2 there should be a possibility to specify more than one jar file (batik has a lot of jar files). I thought that was handled - for example, ant would depend on JAXP, which has two jars (jaxp.jar and crimson.jar). Will review. Also, when you say 'full URL to JAR file' where do you mean? I think a very good example of xml representation of repository is XML Catalogs specification (and xml.commons resolver as an implementation) On the other way, I found that JJar is a very good tool for 'continous integration with ant' developing process. Thanks for this tool. Tomek Pik [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting The cost of synchronization is much less that the cost of stupidity. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JJAR] Status? Jar Repository?
On 4/16/02 8:47 AM, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: From: Geir Magnusson Jr. [EMAIL PROTECTED] On 4/16/02 8:16 AM, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: As for the jar repository, is it possible to anhance the jjar repository with uptodate versions. I can do it myself for the jars I use by putting them in the jjar repo, just want to know if it's ok. Yes - Just Do It :-D :-? Ok, but I've just realized that I dont know where to do the update! http://jakarta.apache.org/jjar/repository.xml where do I update this? I just put that there for visibility :) The real version should be in CVS. Is this the right place to put a repository (just curious of the available options)? Since we will start to use it seriously, does this still apply? Further this is currently not an official Jakarta Commons project, but a well-organized sandbox project. Therefore, production dependencies are discouraged. Of course :) 'discouraged', not 'forbidden' :) I still think it's too sucky for proposal as a real project, but if we start to use it heavily, I think we'll learn much. Right now it's a bit of handwaving and dreaming. Thanks a bunch :-D -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting We will be judged not by the monuments we build, but by the monuments we destroy - Ada Louise Huxtable -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JJAR] Status? Jar Repository?
On 4/16/02 9:00 AM, Tomasz Pik [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: Geir Magnusson Jr. wrote: Two problems that appears during using of JJar: 1 there soluld be a possibility to specify full url to jar file (maybe something like xml:base) Also, when you say 'full URL to JAR file' where do you mean? As I remember it was impossible to specify: jarfile://somewhere/in/filesystem/file1.jar/jar jarhttp://somewhere.over.the.net/file2.jar/jar All files were loaded as thery are located in the same directory as 'repository.xml' or in sub(+)directory of this directory. Ah, right. There is no reason why not, I suppose. I guess the thinking was that each project could own it's jjar repo/entry to distribute the load around rather than centralize it, so you wouldn't go leaping to 'other places' but get the jar from the same place as the repo descriptor. However, I guess that restriction isn't really valid. And that doesn't account for the need for the file: URL as well. Tomek -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting The cost of synchronization is much less that the cost of stupidity. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JJAR] Status? Jar Repository?
On 4/16/02 9:06 AM, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: From: Geir Magnusson Jr. [EMAIL PROTECTED] On 4/16/02 8:47 AM, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: http://jakarta.apache.org/jjar/repository.xml where do I update this? I just put that there for visibility :) The real version should be in CVS. Oh. And the Jars? Download them with viewCVS? Are you kidding? -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting They that can 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: [JJAR] Status? Jar Repository?
On 4/16/02 10:30 AM, Morrison, John [EMAIL PROTECTED] wrote: From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] I don't think there is a problem, as they are different. JJAR doesn't come close to what Maven does. There may be overlap in the functionality in that Maven needed to have similar functionality as a part of itself, but that's a different issue. Could Maven make use of JJAR? Yes. Should it now? I don't think so. Should gump? Yes. Should it now? I don't think so. Right now, I think that the needs of Gump and Maven aren't supported by JJAR in the way that Gump and Maven need them. In the future, as things are clearer, I hope that things can come together But I can't see why it would be forced now. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting He who throws mud only loses ground. - Fat Albert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JJAR] Status? Jar Repository?
On 4/16/02 9:55 AM, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: From: Geir Magnusson Jr. [EMAIL PROTECTED] On 4/16/02 9:06 AM, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: From: Geir Magnusson Jr. [EMAIL PROTECTED] On 4/16/02 8:47 AM, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: http://jakarta.apache.org/jjar/repository.xml where do I update this? I just put that there for visibility :) The real version should be in CVS. Oh. And the Jars? Download them with viewCVS? Are you kidding? If you don't tell me where to put them and how to get them, I could go on for ages ;-P Apparently. Are you asking where to put the jars? For now, I was putting them in jakarta.apache.org/jjar/ It's not really clear we want to dump them into CVS just yet. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JJAR] Status? Jar Repository?
On 4/16/02 5:18 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Henri Yandell [EMAIL PROTECTED] wrote on 17/04/2002 12:08:06 AM: I think we're working towards having a real problem towards the consumer as to the difference between Maven and Jjar and why there are two tools with such an overlap. I'd recently flipped my 'consumer' demands over to Maven. Do you see any forseeable solutions? Choice. At the moment Maven is a lot wider scope than JJar, and a lot more mature. That's like saying Tomcat is a lot wider scope than Ant and a lot more mature. :) My point is that we are comparing apples to oranges - they aren't intended to solve the same problem. Yes, Maven needs to know about dependencies and have jars to satisfy the dependencies, but so does a classloader... Here's a limited list of what maven does, and given the development frenzy surrounding it, I can say this is accurate only as of 17:18EST 20020416 : *Change log document created directly from repository information. *Cross referenced sources *Source metrics *Mailing lists *Developer list *Dependency list *Unit test reports including coverage *Article Collection *Software Development References *Software Development Process Documentation *Distribution publication based on the POM. JJAR gets jars and dependency jars. That's it. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting The cost of synchronization is much less that the cost of stupidity. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JJAR] Status? Jar Repository?
On 4/16/02 5:32 PM, Scott Sanders [EMAIL PROTECTED] wrote: Gier is correct. In the end jjar gets jars. Maven is an entire build methodology. JJAR is a tool, with no meaning unless used in a larger context. Maven could be a consumer of JJAR's work. Scott (Waiting for those jjar commits ;-) Remember, as Jason Hunter put it to the EC proposing Pier and myself for something : The hint to their names: i before e except after g :-) -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 2:19 PM To: Jakarta Commons Developers List Subject: Re: [JJAR] Status? Jar Repository? On 4/16/02 5:18 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Henri Yandell [EMAIL PROTECTED] wrote on 17/04/2002 12:08:06 AM: I think we're working towards having a real problem towards the consumer as to the difference between Maven and Jjar and why there are two tools with such an overlap. I'd recently flipped my 'consumer' demands over to Maven. Do you see any forseeable solutions? Choice. At the moment Maven is a lot wider scope than JJar, and a lot more mature. That's like saying Tomcat is a lot wider scope than Ant and a lot more mature. :) My point is that we are comparing apples to oranges - they aren't intended to solve the same problem. Yes, Maven needs to know about dependencies and have jars to satisfy the dependencies, but so does a classloader... Here's a limited list of what maven does, and given the development frenzy surrounding it, I can say this is accurate only as of 17:18EST 20020416 : *Change log document created directly from repository information. *Cross referenced sources *Source metrics *Mailing lists *Developer list *Dependency list *Unit test reports including coverage *Article Collection *Software Development References *Software Development Process Documentation *Distribution publication based on the POM. JJAR gets jars and dependency jars. That's it. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting The cost of synchronization is much less that the cost of stupidity. -- To unsubscribe, e-mail: mailto:commons-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] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting The obvious solutions are challenging -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JJAR] Status? Jar Repository?
On 4/16/02 5:45 PM, Scott Sanders [EMAIL PROTECTED] wrote: That's the second time I have done that. I must formally apologize now. Sorry G-E-I-R :) The apology wasn't necessary, of course. At all. I just have been waiting for a chance to re-use Jason's clever line... Scott -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 2:41 PM To: Jakarta Commons Developers List Subject: Re: [JJAR] Status? Jar Repository? On 4/16/02 5:32 PM, Scott Sanders [EMAIL PROTECTED] wrote: Gier is correct. In the end jjar gets jars. Maven is an entire build methodology. JJAR is a tool, with no meaning unless used in a larger context. Maven could be a consumer of JJAR's work. Scott (Waiting for those jjar commits ;-) Remember, as Jason Hunter put it to the EC proposing Pier and myself for something : The hint to their names: i before e except after g :-) -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 2:19 PM To: Jakarta Commons Developers List Subject: Re: [JJAR] Status? Jar Repository? On 4/16/02 5:18 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Henri Yandell [EMAIL PROTECTED] wrote on 17/04/2002 12:08:06 AM: I think we're working towards having a real problem towards the consumer as to the difference between Maven and Jjar and why there are two tools with such an overlap. I'd recently flipped my 'consumer' demands over to Maven. Do you see any forseeable solutions? Choice. At the moment Maven is a lot wider scope than JJar, and a lot more mature. That's like saying Tomcat is a lot wider scope than Ant and a lot more mature. :) My point is that we are comparing apples to oranges - they aren't intended to solve the same problem. Yes, Maven needs to know about dependencies and have jars to satisfy the dependencies, but so does a classloader... Here's a limited list of what maven does, and given the development frenzy surrounding it, I can say this is accurate only as of 17:18EST 20020416 : *Change log document created directly from repository information. *Cross referenced sources *Source metrics *Mailing lists *Developer list *Dependency list *Unit test reports including coverage *Article Collection *Software Development References *Software Development Process Documentation *Distribution publication based on the POM. JJAR gets jars and dependency jars. That's it. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting The cost of synchronization is much less that the cost of stupidity. -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting The obvious solutions are challenging -- To unsubscribe, e-mail: mailto:commons-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] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting We will be judged not by the monuments we build, but by the monuments we destroy - Ada Louise Huxtable -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JJAR] Status? Jar Repository?
On 4/16/02 5:54 PM, Scott Sanders [EMAIL PROTECTED] wrote: I was hoping the apology might light some kindred flame in which we might both see some commits to the jjar repo in CVS. Yes, I'm quite inspired now... Just a thought. Scott -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 2:49 PM To: Jakarta Commons Developers List Subject: Re: [JJAR] Status? Jar Repository? On 4/16/02 5:45 PM, Scott Sanders [EMAIL PROTECTED] wrote: That's the second time I have done that. I must formally apologize now. Sorry G-E-I-R :) The apology wasn't necessary, of course. At all. I just have been waiting for a chance to re-use Jason's clever line... Scott -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 2:41 PM To: Jakarta Commons Developers List Subject: Re: [JJAR] Status? Jar Repository? On 4/16/02 5:32 PM, Scott Sanders [EMAIL PROTECTED] wrote: Gier is correct. In the end jjar gets jars. Maven is an entire build methodology. JJAR is a tool, with no meaning unless used in a larger context. Maven could be a consumer of JJAR's work. Scott (Waiting for those jjar commits ;-) Remember, as Jason Hunter put it to the EC proposing Pier and myself for something : The hint to their names: i before e except after g :-) -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 2:19 PM To: Jakarta Commons Developers List Subject: Re: [JJAR] Status? Jar Repository? On 4/16/02 5:18 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Henri Yandell [EMAIL PROTECTED] wrote on 17/04/2002 12:08:06 AM: I think we're working towards having a real problem towards the consumer as to the difference between Maven and Jjar and why there are two tools with such an overlap. I'd recently flipped my 'consumer' demands over to Maven. Do you see any forseeable solutions? Choice. At the moment Maven is a lot wider scope than JJar, and a lot more mature. That's like saying Tomcat is a lot wider scope than Ant and a lot more mature. :) My point is that we are comparing apples to oranges - they aren't intended to solve the same problem. Yes, Maven needs to know about dependencies and have jars to satisfy the dependencies, but so does a classloader... Here's a limited list of what maven does, and given the development frenzy surrounding it, I can say this is accurate only as of 17:18EST 20020416 : *Change log document created directly from repository information. *Cross referenced sources *Source metrics *Mailing lists *Developer list *Dependency list *Unit test reports including coverage *Article Collection *Software Development References *Software Development Process Documentation *Distribution publication based on the POM. JJAR gets jars and dependency jars. That's it. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting The cost of synchronization is much less that the cost of stupidity. -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting The obvious solutions are challenging -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting We will be judged not by the monuments we build, but by the monuments we destroy - Ada Louise Huxtable -- To unsubscribe, e-mail: mailto:commons-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] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting The bytecodes are language independent. - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] Need interface... VOTE
On 4/5/02 10:30 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote: It's not that I don't like the static methods - I *love* your static methods. I adore them! I adore them so much, I want to write an implementation of LogFactory myself for a new kind of logger I have. Can I do that and use it with commons-logging package? Yep. See the JavaDocs for org.apache.commons.logging for three different ways (system property, commons.logging.properties file, and the services interface protocol of a file in META-INF of a jar file) to request the use of your own custom LogFactory subclass. Yep - I'm doing that. I'm trying the Service provider approach (can't find the 'Service' class anywhere in the 1.3.1 docs, but that's a different issue...) by making an alternative impl of LogFactory and putting the proper META-INF/services path in the jar. I still can't see how classpath order for alternate LogFactory impls isn't going to be a problem with something canonical like Digester or other commons components, but at this point I trust that y'all have thought this through and I just need to go convince myself. Still seems like magic, but we all know what Arthur C Clark said about magic.. Thanks all. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Java : the speed of Smalltalk with the simple elegance of C++... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] Need interface...
On 4/5/02 3:23 AM, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: Plase, can commons and Avalon stop picking at each other and make a UNIFIED logging wrapper that can be used as push, pull, or whatever?!? Or do you want me to add a commoncommonslogging package in the sandbox? AFAIK, nothing prevents me from doing it. I just proposed this earlier - I called naturallog - just have a set of interfaces, policy free -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting The obvious solutions are challenging -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] Need interface... VOTE
On 4/4/02 5:15 PM, Richard Sitze [EMAIL PROTECTED] wrote: OK then, let's see what happens: I PROPOSE that the classes in commons logging be rearranged as follows: no change: org.apache.commons.logging.Log org.apache.commons.logging.impl.Jdk14Loger.java org.apache.commons.logging.impl.Log4JCategoryLog.java org.apache.commons.logging.impl.LogKitLogger.java org.apache.commons.logging.impl.NoOpLog.java org.apache.commons.logging.impl.SimpleLog.java rename package, and add JavaDoc to explain or confuse as appropriate: org.apache.commons.logging.factory.LogFactory org.apache.commons.logging.factory.LogSource (deprecate?) org.apache.commons.logging.factory.impl.LogFactoryImpl org.apache.commons.logging.factory.impl.LogConfigurationException org.apache.commons.logging.factory.impl.Log4jFactoryImpl Isn't this just rearranging the deck chairs? The problem, for me anyway, still exists... All I want is a base 'commons component' with two interfaces (ok maybe more than two - three) o.a.c.genericlog.Log o.a.c.genericlog.LogUser o.a.c.genericlog.LogFactory Where Log and LogFactory are just like the o.a.c.l interfaces, and LogUser has a single method setLogFactory( LogFactory ); That's it. Then, if this gives me what I think it does, and if people grok what I was trying to do, I would then propose o.a.c.l.Log extends o.a.c.genericlog.Log o.a.c.l.LogFactory extends o.a.c.genericllog.LogFactory So thus, nothing changes for anyone or anything using o.a.c.l, but then there would exist : 1) o.a.c.gl : a generic, lightweight contract for logging with the marker interface I think would be useful. 2) o.a.c.l : multi-impl implementation of o.a.c.gl -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting The question is : What is a Mahnamahna? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] Need interface... VOTE
On 4/5/02 9:07 AM, Richard Sitze [EMAIL PROTECTED] wrote: Well... yes... I was rearranging the deck chairs.I move all implementation out of the one package, and into another (btw, LogFactory is an abstract class with some code specified, it's not an interfact). How is that significantly different than what you proposed, other than your proposal may preserve backwards compatibility which is goodness. What I propose is a separate package - so that you include the o.a.c.gl jar when you just want the interfaces, and both (or just o.a.c.l) when you want the actual impl. Remember, I am coming from the POV that I already have logging (which could be based on log4j, logkit, system.out.println...) and just want a generic interface to it. Also, I really dislike LogUser in that context... what's wrong with LogEnabled as per Avalon (I know we are, again, circling back over old ground :-), or LogEnablable :-). I don't care about the name. LogEnabled is fine, but I was keeping the 'LogUser' moniker just so people who saw the first post have a clue... For the real impl, we'll change it. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting The bytecodes are language independent. - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] Need interface... VOTE
On 4/5/02 11:25 AM, Christoph Reck [EMAIL PROTECTED] wrote: Geir, could you agree in having the o.a.c.l build file pop out an logifc.jar with what you want instead of creating another o.a.c.gl package with practically the same interfaces as in o.a.c.l ? I'm the one groveling for change :) I'll agree to anything (well, most things...) I would think that would work, but there is still the problem of opposition to the marker interface as a first class citizen... Also, it would be good to somehow be clear about when it's ok to pull from the aether... Right now that's assumed all the time in o.a.c.l Just my 0.02c: If you look at the commons(-sandbox) its hard to identify what you need - you don't see the forest because of the many trees. Imagine -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting My inner cowboy needs to yodel. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] Need interface... VOTE
On 4/5/02 12:24 PM, Morgan Delagrange [EMAIL PROTECTED] wrote: Now, if we can't meet somewhere in o.a.c.l, I am happy to do an interface package o.a.c.gl, which I hope wouldn't be -1'd when proposed to commons proper because of the existance of o.a.c.l... geir I'm -0 on a backwards-compatible change that does not affect performance. That's fair. Not sure why '-', but ok. I am -1 on integrating this with existing commons components because of the performance impact of non-static Log objects in the classes. At no time have I suggested that any component, existing or in the future, be required to change. It wouldn't make any sense unless you wanted that component to have the option of getting a log pushed to it. (And you can do both if you want...) And what's the performance impact of implementing an interface? This is particularly important since we are already guaranteed a level of indirection. Also I'm decidedly -1 on changes to existing components that do not provide backward-compatible default Log objects. Again, I have never, ever suggested changing any existing components. At worst, o.a.c.l interfaces would implement o.a.c.gl interfaces, but the change there would be one import statement and the addition of 'implements XXX' - no other changes as the interfaces are identical, and again, only in the o.a.c.l package. Components wouldn't care - they would go on happily using o.a.c.l as they do now... That's a real kicker for me wrt. integration in other Commons components. You would have to instantiate a default Log for each instance of a class, and then if you utilize that interface you would instantiate _another_ Log. Why? Remember : there are no requirements to use the marker interface That's quite a bit of potential overhead. The proposed interface might work acceptably in an environment that does not require default Log implementations. Repeat : For users of o.a.c.l, *nothing* changes. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Be a giant. Take giant steps. Do giant things... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] Need interface... VOTE
On 4/5/02 1:25 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote: In o.a.c.l with some implicit assumptions (which I am trying to dodge...) It's quite explicit, and your proposal seem to hava a LogFactory too. The assumptions are *not* explicit - the assumption I am talking about is that you must get the log via a pull from a singleton in o.a.c.l. Again, nothing wrong with that, but wanted to be clear. There is no must. The static method and the discovery is a helper, nothing require you to use it. But from what I've heard, everyone *expects* it to be there, as it's in the o.a.c.l jar. You've seem to have coupled a generic logging interface o.a.c.l.Log to the expectation of a pull-able implementation, and all I am suggesting is that maybe the interface can be separate from the pull impl. The name-based registration of components is pretty widespread in java - and most people know how to use it and how to not use it if they want to. Almost all APIs in use today are using it - JDBC, JNDI, JAXP - even servlets ( you get a servlet by name, and web.xml is full of crap to simplify the configuration of name-based resources). I'm not complaining about it! However nothing in the API prevent you to instantiate a DOM parser yourself and add setDOMParser in your code. BTW, are you going to also propose a o.a.c.genericxmlparser, o.a.c.genericjdbc, etc ? After all, there are few dozen APIs using the same pattern with common-logging, do you feel confused when using them too ? Nope. JDBC doesn't come with an impl, does it? Don't I go and use the mm.sql MySQL driver package throuh which getConnection() will return an object that implements Connection? That's what I am trying to get to here - an implementation free interface spec. Ok, the 'implementation' you talk about is the println() fallback if log4j, logkit, jdk1.4 or any other impl is detected. JAXP does come with a default implementation as well, same for JMX and JNDI. ( JDBC was not the best example, my mistake :-). But one I was able to deftly capitalize on! :) And the JNDI impl as great as long as you don't want to do anything with it. Sorry :) Serious question : how do I implement a new LogFactory? Do I have to rely on classpath order? (no thanks...) BTW, JDBC does include the registration code ( also pull based - you don't have to call mm.sql.Driver directly except to make it register itslef in DriverManager ). And it also include a second pull and name based mechansim - JNDI. :) Then the basic implementation is commons-logging for the pull crowd, (and maybe push) and anyone who has another idea can do what they want. You can do what you want anyway - there are already a dozen interfaces for Log besides o.a.c.logging.Log. The current Log interface is good enough and used in several packages, and I don't plan to use any other log interface in any code I write. I thought you got it. There is no need to be defensive here - I am not trying to disrupt o.a.c.l, force any behavior on anyone, force implementation on anyone, etc... I am not trying to do another Log interface because there is a problem with o.a.c.l. There isn't any problem with the *interface* o.a.c.l.Log. It's beautiful! Perfect! I salute the vision! and the code formatting is just immaculate. And the comments... Mere words don't do them justice... :) OK? The problem I have is that there is implementation support built into the package, and that leads to the expectation that if I am in o.a.c.l there is a working LogFactory I can reach via a singleton. Or put another way, commons logging has pull discovery implicit in the model. That's all. It's the *expectation* - I understand now that it's explicit because if you want to use the generic Log interface, that log factory impl is *always* going to be around somewhere, so just try... I was proposing the same interfaces with no promises about the existence of factories. If you want to pull - be my guest and use o.a.c.l. And if public interface Log implements o.a.c.gl.Log then they are 100% compatible with each other. (not bidirectionally, but that could be fixed :) You guys say you don't want this interface in the Logging package, and then make fun of me when I propose a generic interface package that fully supports the existing and includes it? You can create 10 interfaces if you want - what matter is what we use in our code, and for now it seems most of us are using commons-logging as the interface for logging. Right - because you wanted a COMMON interface for logging. I am not asking anyone to use anything different. Why you seem to be saying that the generic logging interface can't be separate from the pull-compatible implementation is beyond me... Utterly. See what I'm saying? However, I would think you would want to separate the interfaces, to prevent a *component* from calling
Re: [logging] Need interface... VOTE
On 4/5/02 4:45 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote: But the 'push interface' has no implementation associated with it... I would expect, for example that I would write an app that uses the pull interface to get a factory, and then give that factory to my components...) Of course it doesn't - it's an interface that has to be implemented by every component that wants to use that discovery mechansim, and by any application that uses components using it. The pull is 'popular' exactly because it has a base implementation. If you remove it - it'll not be as easy to use. Wow - you just won't give up with this. I am not advocating removing it. I am not advocating removing it. I am not advocating removing it. Clear? In the future, I will denote the above block as '***' as to not waste bits... So again, I'm not advocating creating a new or different logger - just separating the generic interface apart from the *truly excellent* implementation of that interface in o.a.c.l. For those using 'pull', the discovery implementation is essential in order to use o.a.c.l. Those using push can ignore it. That's how pull works, the API provides the basic implementation and components use it, you can't change that without affecting people who use pull. ( by making their life harder - not as hard as implementing a push interface on each component, but not as easy as it is today ). does, then we automatically have another valid mechansim to get a Log in a servlet environment - pushed by the 'deployer' via JNDI and web.xml. Class.forName() also works. Pushed in how? Using the magical Admin interfaces for web applications, which allows you to use the descriptions in web.xml and associate real impls. with the various names ( i.e. JDBC Connections, etc ). So that's not automatic, is it? There are lots of things I don't have a problem with - I just don't think they all belong in the same place... Those using pull seem to need it there - so it is easy to use. We like to log using a single import statement and one line of code ( or just one line of code ) to set the logger. Is this some sort of joke I don't get? *** - that's the bit where I tell you that I am not advocating removing the pull model... If you prefer implementing a marker and require an application that supports that and configures each component - your itch, your solution, no problem with me. As long as you don't remove what I need. *** So you can have multiple LogFactory implementations available at the same time? I still don't get it - I looked at digester - it does the ususal Log logger = LogFactory Initializer. Now, if there were several impls of LogFactory in the classpath, which one wins? Digester isn't using Service.providers() approach... Each class loader may have a different LogFactory implementation. That mean each application can use its LogFactory, by just including the favorite jar in WEB-INF/lib ( or equivalent ). With a classloader that has available multiple implementations, which is used? The first that it finds? If any logger has the manifest - it wins. If not, we try to look for few 'well-known' loggers. This is what we did in Velocity a while ago - I am familiar with the pattern If you have multiple logger implementations in the classpath (each with a service manifest ) - that's your problem, you either make up your mind or use a different mechanism, like Class.forName(). We can't guess what you want. Doesn't this get confusing? Don't get me wrong : 1) *** 2) I like the pull model How do I prevent someone from using the discovery mechanism to get the default impl? You can't. If someone wants to use the discovery - it's his choice and he'll be able to do it. But he can implement a getResource( WEB-INF/services/org ) anyway in his code and get the same effect - you can't prevent that either. The point isn't to stop the determined, it's to prevent the accidental. Right now, it sounds like with multiple LogFactory implementations in the classpath, you spin the wheel and pray you get the right loader. If one component uses formal discovery, they get one loader, if another tosses care to the wind and does Log logger = LogFactory.getLog() It appears that the results are really indeterminate. Our goal is not to prevent people - but to help them do what they need to. 'Prevent people' what? No one's goal is to prevent people from doing anything. In the case where you split up the impl from the interface, if you want to use a generic log interface, put o.a.c.gl in the classpath. If you want to use pull discovery, put o.a.c.l in the classpath. Can't see how that 'prevents people' from doing things. ( we could use a Factory impl that uses sandbox and Permission to fine-tune who can do what - but it's not yet implemented ). Would this be solved
[logging] LogFactory tangent : was Re: [logging] Need interface...VOTE
On 4/5/02 4:48 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote: I don't know if that's fair - because the application has setup and pushed into the context the Log.. In the o.a.c.l model, I can't even replace the static LogFactory Replace it with what ? The javadoc for the static LogFactory.getLog() is pretty clear, the method must implement what's in the doc. My own implementation? (You know, that choice thing?) Before I summarize my understanding : I am not advocating removing the pull model. Ok. Here's my understanding of the LogFactory issue - please correct me where it's wrong : 1) if the Log, LogFactory interfaces are kept in the same jar the .impl.LogFactory, then there are challenges to clearly implement an alternative LogFactory because of the issues surrounding the discovery method. 2) If Log and LogFactory interfaces were separated from the .impl that is in commons now, into two separate packages, o.a.c.l - commons-logging.jar (contains the interfaces) o.a.c.li - commons-loggingimpl.jar (contains the impl) then a) Nothing would change for users, developers, existing components, future components as all code would still work. The only requirement is that the two commons-logging jars would have to be added to the classpath. Not a big deal. b) Alternative LogFactory implementations are easy to deploy as it just means dropping the lightweight interface jar into the classpath, and the alternative factory impl jar. c) o.a.c.l becomes a truly generic logging interface (which is how many people interpret it) that can be implemented by anyone, supporting any pull model you choose, and any push model you choose... Is the above correct? geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Be a giant. Take giant steps. Do giant things... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] LogFactory tangent : was Re: [logging] Needinterface... VOTE
On 4/5/02 5:59 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote: 2) If Log and LogFactory interfaces were separated from the .impl that is in commons now, into two separate packages, o.a.c.l - commons-logging.jar (contains the interfaces) o.a.c.li - commons-loggingimpl.jar (contains the impl) then b) Alternative LogFactory implementations are easy to deploy as it just means dropping the lightweight interface jar into the classpath, and the alternative factory impl jar. It doesn't matter where the LogFactory sits - if we define the helper ( org.apache.foo.LogFactory ) and it uses a static method it can't be reimplemented. I see now - because the discovery functionality (the static method) and the interface you are trying to discover (LogFactory) are combined, via o.a.c.LogFactory being an abstract class with the static method, rather than an interface, we're screwed if you want to replace LogFactory. Is that it? That's why I would have to remove o.a.c.LogFactory from the jar and replace with my own? So the LogFactory itself isn't really generic, as it presumes the helper? And everyone who writes to this does import o.a.c.l.LogFactory; ... Log logger = LogFactory.getLogger(); Ok - so there's no point in continuing. It seems like the only way to offer a generic set of interfaces for logging is to do a different package... Otherwise, the the basic interfaces (Log, LogFactory) can't be implemented freely? Hm -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting You're going to end up getting pissed at your software anyway, so you might as well not pay for it. Try Open Source. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
