Re: commons-concoct - new project proposal
Thank you very much Henri. I'm starting a new thread for greater visibility (took some marketing lessons this summer :) Henri Yandell wrote: Giorgio's propsal/code in zip form are uploaded to: http://people.apache.org/~bayard/commons-concoct.zip On 12/1/05, Henri Yandell [EMAIL PROTECTED] wrote: On 12/1/05, Giorgio Gallo [EMAIL PROTECTED] wrote: I've read trough the charter and will post a formal proposal as soon as I get the time to write it down ;) In the meantime, is there anyway I could upload the code (its around 60k, zipped), in a quest for initial committers to include on the proposal? Either attach it to a bugzilla entry, or mail it to me and I'll put it in my ~ space As regards incubation: - The code have never been released, whether on its own or inside a larger application/library - I'm the sole copyright owner of the code - I am (of course) willing to donate it to ASF Does this imply it needs to be incubated? Depends on the people interested. If there are no/few existing committers interested, then yes you'd need to be incubated. If however the majority of interested committers are existing committers, then we'll go with a code grant and goto the sandbox. 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]
commons-concoct: proposal draft and search for supporters
Hi all! As you might know, Henri has been so gentle as to upload the (wannabe) commons-concoct into his ~ space: http://people.apache.org/~bayard/commons-concoct.zip Inside the .zip file you'll find the current project (maven2-enabled and, well, it's more of a prototype than a full-fledged component right now:) as well as a draft of the proposal I wish to post in a few days. Please take a look at the proposal draft and comment on it: I'm not very sure my english is good enough to convey the vision of a new project. -- Giorgio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-concoct - new project proposal
That's most strange: I downloaded it successfully with Firefox... Please ask me and I'll send it to you by email. Matt Benson wrote: I have tried the http DL, as well as trying to check the file out locally via ssh to people@ and I continue to get errors indicating bad file format, etc... Thanks, Matt --- Henri Yandell [EMAIL PROTECTED] wrote: Giorgio's propsal/code in zip form are uploaded to: http://people.apache.org/~bayard/commons-concoct.zip snip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] short critique of site
Might I add: 8) The bug database link should point to a page where an user is advised to look in the sites of the single components instead of pointing to http://jakarta.apache.org/site/bugs.html Henri Yandell wrote: Some thoughts on the site. A] Looking at the front page. 1) Jakarta link on the bar is redundant. We already have a huge logo in the top left. 2) No need to include the direct svn link, just use viewcvs. Simpler for the user. 3) Korea translation link is dead. 4) Japanese translation link is out of date. 5) While the wiki is unofficial documentation, it is an official resource. 6) DB Commons is empty. 7) Contributor page. Is this worth the effort of the maintenance? B] Clicking on sandbox. 1) There are many projects which have become dormant. How should we be changing the site? 2) Corresponding Wiki page needs changing [my fault :) ] Okay, onto something else next. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-concoct - new project proposal
I might be wrong, but I think I've seen an URI implementation in Axis (don't know if it's a strict RFC-2396 implementation, a java.net.URI backport, just something they needed or something that does its best to interpret any messy string passed in) For me, I buy the simply use the : as a delimiter part :-) To be honest, the very first scratch of the library relied on URIs, but on a second thought I think URIs do not fit well in a library like this... java.net.URIs: - They are only available from jdk1.4 - of course ;-) - They don't require the scheme to be specified, and I don't think there's a way to properly implement relative URI semantic in concoct - They don't parse string:a string ( must be escaped with %20) - They don't parse string:## - They don't really provide any useful functionality for the lib, aside for syntax checking - which is not really useful IMHO RFC-2396 URIs: - defaulting to string: when no scheme is specified - a welcome feature IMHO, and one that would ease adoption of the lib in with .properties files - does not fit well with relative URI semantics - the grammar is more strict than needed (see deviations in java.net.URI code) - all the path stuff is irrelevant for the lib - they require escaping beyond that of the scheme used and (possibly) the file format they are stored in (such as entity escape for xml). Mario Ivankovits wrote: Hi Giorgio! Its purpose is to parse URI-like strings (anything in the form somescheme:somestring) into java objects according to a scheme-specific syntax (which is straightforward in most cases) Do you plan to support the full URI specification of do you simply use the : as delimiter ;-) But then the URI stuff of your project should be splitted out into its own project e.g. commons-uri In [vfs] we have needs for a jdk independend URI library. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-concoct - new project proposal
I've read trough the charter and will post a formal proposal as soon as I get the time to write it down ;) In the meantime, is there anyway I could upload the code (its around 60k, zipped), in a quest for initial committers to include on the proposal? As regards incubation: - The code have never been released, whether on its own or inside a larger application/library - I'm the sole copyright owner of the code - I am (of course) willing to donate it to ASF Does this imply it needs to be incubated? Rahul Akolkar wrote: On 11/30/05, Matt Benson [EMAIL PROTECTED] wrote: Oddly enough, I have spent the last week point five working on a similar setup at $work. My syntax is slightly different (extended I would say). If this proposal is accepted in principle, I could query my boss whether we could make any contributions. As an Apache committer, I believe I have the right to work in the Jakarta commons sandbox on such a project. Commons people? snip/ Indeed, the Commons charter says you're welcome :-) Procedurally, its nice to start with a [proposal] thread, in the format specified by the Example Package Proposal section of the charter [1], and obtain feedback from existing Commons committers. If the code was *not* developed in the ASF repository, you will have to incubate [2] it first. Someone with more incubator-related experience will probably clarify once the details are posted in the proposal. -Rahul [1] http://jakarta.apache.org/commons/charter.html [2] http://incubator.apache.org/ -Matt --- Giorgio Gallo [EMAIL PROTECTED] wrote: I've been working on a library I aim to contribute to the commons bazaar (as a standalone lib or maybe as part of commons-transform), but: - I'm not sure mine is a good idea for a commons library - I'm not a commons committer - The lib still needs work (it is a prototype right now) The library, which is named Concoct for now, should come handy in configuration files (that is, I think so :). Its purpose is to parse URI-like strings (anything in the form somescheme:somestring) into java objects according to a scheme-specific syntax (which is straightforward in most cases): for now it can only handle strings like int:189 - new Integer(189) string:foo - new String(foo) null:whatever - null class:oracle.jdbc.driver.OracleDriver - oracle.jdbc.driver.OracleDriver.class and convert expressions like bean:org.example.MyClass(foo=string:foo,bar=null:null) into an instance of MyClass, with attributes set as specified. Plans are to add many other schemes, eg: - jdbc: to produce Connections - jdbc-datasource: to produce DataSources (via commons-dbcp) - singleton: to return the same Object if the expression is evaluated more than once - proxy: to build a dynamic proxy - file:,http:,ftp: to read the specified url into a java.net.URL - deserialize: to read an object from an URL - ... The idea is to enable the combination of different schemes in expressions (such as in the bean: scheme example - above). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
commons-concoct - new project proposal
I've been working on a library I aim to contribute to the commons bazaar (as a standalone lib or maybe as part of commons-transform), but: - I'm not sure mine is a good idea for a commons library - I'm not a commons committer - The lib still needs work (it is a prototype right now) The library, which is named Concoct for now, should come handy in configuration files (that is, I think so :). Its purpose is to parse URI-like strings (anything in the form somescheme:somestring) into java objects according to a scheme-specific syntax (which is straightforward in most cases): for now it can only handle strings like int:189 - new Integer(189) string:foo - new String(foo) null:whatever - null class:oracle.jdbc.driver.OracleDriver - oracle.jdbc.driver.OracleDriver.class and convert expressions like bean:org.example.MyClass(foo=string:foo,bar=null:null) into an instance of MyClass, with attributes set as specified. Plans are to add many other schemes, eg: - jdbc: to produce Connections - jdbc-datasource: to produce DataSources (via commons-dbcp) - singleton: to return the same Object if the expression is evaluated more than once - proxy: to build a dynamic proxy - file:,http:,ftp: to read the specified url into a java.net.URL - deserialize: to read an object from an URL - ... The idea is to enable the combination of different schemes in expressions (such as in the bean: scheme example - above). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[JELLY] scopes and JellyContext.isExport(), plus a bunch of questions
I am wotking on adding a Scope class to make it easier to plugin custom
scopes (as per the TODO list).
I have tought that taking the variable-handling stuff out of
JellyCopntext could be a Good Thing, since that class seems to already
have a whole bunch of responsibilities, so I started to code a
replacement for that part of JellyContext instead of a simple holder
scope with copyToContext(JellyContext) and copyFromContext(JellyScope)
methods.
While doing so I bumped into JellyContext.isExport()... :)
Right now the behaviour of a jelly context with export=true is to live
as a parasitic of its parent and to define its own variables into the
parent scope (context).
The behaviour is now such as:
1)
//parent scope
// no 'foo' defined here
{
// child scope
String foo = bar;
}
// use a in parent scope
System.out.println(foo);
2)
//parent scope
String foo = asdf;
{
// child scope
String foo = bar;
}
// use a in parent scope
System.out.println(foo);
would both output bar
Is this intended behaviour, or was the exporting stuff intended only to
allow for stuff like
//parent scope
String foo = bar;
{
foo = asdf;
}
System.out.println(foo);
to output asdf? (or to prevent it from doing so if export=false)
BTW:
a)
Would features such as:
- knowing whether a certain variable (variable name) is visible from a
given scope
- knowing if a certain variable has been initialized
- checking for variable names to be valid (eg: w/o whitespace,
non-empty, non-null...)
be welcome in a scope implementation?
b)
Would introducing a variable (meaning reference) class be welcome?
IMO it could be nicer to have persistent variables instead of (or in
addition to) persistent scopes.
Thanks,
Giorgio
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [JELLY] exotic URL protocols
Couldn't do it without letting a context's currentUrl be the full url of the script - sorry :) I didn't remove the rootUrl stuff: it's still inferred from currentUrl (although context-relative url resolution uses new URL(URL, String) now) I used jdk 1.3.1 --- TODO: - org.apache.commons.jelly.task.JellyTask needs fixing - org.apache.commons.jelly.test.BaseJellyTest needs fixing (BTW: it's in src/java instead of into src/test) - org.apache.commons.jelly.core.BaseMemoryLeakTest could need fixing --- I took a look at xml-commons-resolver: didn't know xml had a commons project... It looks like an implementation of OASIS xml catalog - AFAIK it is a standard for mapping URNs to URLs (eg: for locating the DTD corresponding to a particular public doctype). I guess it could be helpful for the tag-library stuff: jelly could set-up a catalog based on all the catalog files it finds inside the various META-INF in the classpath and use it for locating taglib descriptors (if they are to be introduced into jelly - or classes otherwise). I imagine we could even let taglibs be defined via doctype declarations instead of xmlns attributes... it could sound a little bit useless but i think it would be really cool :) About exotic URL schemes, what I was trying to say is that URL-to-resource resolution is entirely dependand on the URL scheme (ie: protocol): in the patch I added two tests wich use a custom URL scheme named dummyprotocol that resolves dummyprotocol:a.jelly to the file src/test/org/apache/commons/jelly/core/a.jelly In the same way I could define a scheme to resolve home:///giorgio/a.jelly to the file /home/giorgio/a.jelly All theese custom protocols pose no problems to jelly as long as they have a path-like structure, with path elements separated by '/' and in descending order. Now imagine i want to define a scheme that maps URLs to email messages: your message (ie: the one I am replying to) is assigned and id (I guess from your smtp - but I don't know really who assigns theese ids) of [EMAIL PROTECTED] I could want to resolve emailmessage:[EMAIL PROTECTED] to that message and write an URLStreamHandler that does so. Well, there are really no relative urls inside an email message (besides stuff inside the message itself) so never mind about if this could pose any threat to jelly... :) Let's go back to the home: stuff. Instead of the former usual-way-structured scheme, I could (for whatever reason) want to have URLs like home:[EMAIL PROTECTED] resolved to files inside my home directory - and i could write an URLStreamHandler to do so. What about referring to a file that is beneath my home dir, buryed into tons of subfolders? It could be home:java-stuff/asf/jelly/src/org/[...]/core/[EMAIL PROTECTED] and this would definitely break jelly... Hope to have my point explained a little bit more clearly than yesterday - I was _really_ sleepy when I wrote that message :) PS: Sorry for the crappy examples - I just couldn't think of any widely-used protocol which doesn't use a path-like structure and is commonly used with relative urls... Paul Libbrecht wrote: Giorgio, I am not sure I have grasped the whole picture... Would you be able to make a first patch that only tackles the usage of new URL(url) and then pinpoint the further issues ? I am wondering if the usage of xml-commons-resolver would not help here ? It's a quite small package, it's well licensed (!), and it's very close to our needs. paul Le 11 avr. 05, à 20:30, Giorgio Gallo a écrit : I am trying to write a patch to solve issue JELLY-208 (http://issues.apache.org/jira/browse/JELLY-208) Let me know if you committers prefer to handle this one directly, because of the fact that URLs contain / beeing assumed just about everywhere in jelly... :) Also: Thomas Burns (the issue reporter) mentions a custom url protocol. It is not needed for the specific issue to manifest (think of file:script.jelly) to have a custom protocol, but it could be the case that a protocol does not use the usual URL pattern (protocol://user:[EMAIL PROTECTED]:port/path...) and that therefore we (ie: jelly) cannot resolve relative URLs simply by parsing the string representation of the base URL and assuming it has more meaning that protocol:opaquePart... Besides modifying jelly to ALWAYS use new URL(URL, String) to resolve relative URLs, another fact should/could be addressed: it could be impossible in some protocols to infer the parent URL of a script from the script's own URL (ie: it's what JellyContext#getJellyContextURL does) I see a few options to address this: 1. The protocol:opaquePart thing above comes from some confused corner of my head and I have to read RFCs again :) 2. Declare those exotic protocols unsupported :) 3. Refactor jelly to use a script's very url (eg: file:///dir/dir/script.jelly) to resolve relative URLs and remove
Re: [JELLY] exotic URL protocols
ups! just realised my .classpath got into the patch - sorry :) BTW: shouldn't it be removed from svn? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[JELLY] exotic URL protocols
I am trying to write a patch to solve issue JELLY-208 (http://issues.apache.org/jira/browse/JELLY-208) Let me know if you committers prefer to handle this one directly, because of the fact that URLs contain / beeing assumed just about everywhere in jelly... :) Also: Thomas Burns (the issue reporter) mentions a custom url protocol. It is not needed for the specific issue to manifest (think of file:script.jelly) to have a custom protocol, but it could be the case that a protocol does not use the usual URL pattern (protocol://user:[EMAIL PROTECTED]:port/path...) and that therefore we (ie: jelly) cannot resolve relative URLs simply by parsing the string representation of the base URL and assuming it has more meaning that protocol:opaquePart... Besides modifying jelly to ALWAYS use new URL(URL, String) to resolve relative URLs, another fact should/could be addressed: it could be impossible in some protocols to infer the parent URL of a script from the script's own URL (ie: it's what JellyContext#getJellyContextURL does) I see a few options to address this: 1. The protocol:opaquePart thing above comes from some confused corner of my head and I have to read RFCs again :) 2. Declare those exotic protocols unsupported :) 3. Refactor jelly to use a script's very url (eg: file:///dir/dir/script.jelly) to resolve relative URLs and remove auto-detection of context URLs altoghether (ie: context-relative URLs will be resolved against the script URL unless a different context URL is explicitly specifyed) 4. use null as context url when there are no /s and assume the usual URL pattern if a / is present I would opt for the third possibility (really - can't see any drawback in it, not at 4:00AM at least). Please let me know if such a patch would be welcome or, again, if it's like you committers prefer to handle this on your own. (please pardon me if my english is not very clear) rgds, Giorgio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
