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:Driver"
-Driver.class
and convert expressions like
"bean:org.example.MyClass(foo=string:foo,bar=null:n ull)"
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 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: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

11/30/05, Matt Benson <gudnabrsam (AT) yahoo (DOT) comwrote:
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]
[2] http://incubator.apache.org/

-Matt

Giorgio Gallo <giorgiga (AT) overlord (DOT) itwrote:
--
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:Driver"
-Driver.class

and convert expressions like
--
"bean:org.example.MyClass(foo=string:foo,bar=null:n ull)"
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 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:
commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail:
commons-dev-help (AT) jakarta (DOT) apache.org
>
>
>
>
>
>
>

Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
--

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

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: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

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 IMH

RFC-2396 URIs:
- defaulting to "string:" when no scheme is specified - a welcome
feature IMH, 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: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

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:
11/30/05, Matt Benson <gudnabrsam (AT) yahoo (DOT) comwrote:
>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]
[2] http://incubator.apache.org/


>-Matt
>>
>Giorgio Gallo <giorgiga (AT) overlord (DOT) itwrote:
>>
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:Driver"
-Driver.class

and convert expressions like


>"bean:org.example.MyClass(foo=string:foo,bar=null:n ull)"
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 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:
commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail:
commons-dev-help (AT) jakarta (DOT) apache.org


>>
>>
>>
>>
>
>Yahoo! Mail - PC Magazine Editors' Choice 2005
>http://mail.yahoo.com
>>
>
>To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
>For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
>>
>>

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

12/1/05, Giorgio Gallo <giorgiga (AT) overlord (DOT) itwrote:

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: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

Giorgio's propsal/code in zip form are uploaded to:

http://people.apache.org/~bayard/commons-concoct.zip

12/1/05, Henri Yandell <bayard (AT) apache (DOT) orgwrote:
12/1/05, Giorgio Gallo <giorgiga (AT) overlord (DOT) itwrote:

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: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

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

12/1/05, Henri Yandell <bayard (AT) apache (DOT) orgwrote:
>12/1/05, Giorgio Gallo <giorgiga (AT) overlord (DOT) itwrote:
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: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org