[jira] Updated: (CONNECTORS-92) Move from ant to maven or other build system with decent library management
[ https://issues.apache.org/jira/browse/CONNECTORS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jettro Coenradie updated CONNECTORS-92: --- Attachment: patch-connectors.zip Not a patch, but a zip containing a few poms for the connectors. The null connector and the jdbc connector have a pom Move from ant to maven or other build system with decent library management --- Key: CONNECTORS-92 URL: https://issues.apache.org/jira/browse/CONNECTORS-92 Project: Apache Connectors Framework Issue Type: Wish Components: Build Reporter: Jettro Coenradie Assignee: Karl Wright Attachments: maven-poms-including-start-jar.patch, maven-poms-problem-starting-jetty-and-derby.patch, maven-start-jar.patch, move-to-maven-acf-framework.patch, patch-connectors.zip, Screen shot 2010-08-23 at 16.31.07.png I am looking at the current project structure. If we want to make another build tool available I think we need to change the directory structure. I tried to place a suggestion in an image. Can you please have a look at it. If we agree that this is a good way to go, than I will continue to work on a patch. Which might be a bit hard with all these changing directories, but I'll do my best to at least get an idea whether it would be working. So I have three questions: - Do you want to move to maven or put maven next to ant? - Do you prefer another build mechanism [ant with ivy, gradle, maven3] - Do you have an idea about the amount of scripts that need to be changed if we change the project structure The image of a possible project layout (that is based on the maven standards) is attached to the issue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-92) Move from ant to maven or other build system with decent library management
[ https://issues.apache.org/jira/browse/CONNECTORS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12907908#action_12907908 ] Jettro Coenradie commented on CONNECTORS-92: I think maven is not the right tool at the moment due to the libraries that are used that are not available in any repository, the way the sample is started. The dependencies that seem to be copied to each project. I am spending a lot of time on creating an assembly, but that is not really the part where maven shines. Move from ant to maven or other build system with decent library management --- Key: CONNECTORS-92 URL: https://issues.apache.org/jira/browse/CONNECTORS-92 Project: Apache Connectors Framework Issue Type: Wish Components: Build Reporter: Jettro Coenradie Assignee: Karl Wright Attachments: maven-poms-including-start-jar.patch, maven-poms-problem-starting-jetty-and-derby.patch, maven-start-jar.patch, move-to-maven-acf-framework.patch, patch-connectors.zip, Screen shot 2010-08-23 at 16.31.07.png I am looking at the current project structure. If we want to make another build tool available I think we need to change the directory structure. I tried to place a suggestion in an image. Can you please have a look at it. If we agree that this is a good way to go, than I will continue to work on a patch. Which might be a bit hard with all these changing directories, but I'll do my best to at least get an idea whether it would be working. So I have three questions: - Do you want to move to maven or put maven next to ant? - Do you prefer another build mechanism [ant with ivy, gradle, maven3] - Do you have an idea about the amount of scripts that need to be changed if we change the project structure The image of a possible project layout (that is based on the maven standards) is attached to the issue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be pure RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12907934#action_12907934
]
Karl Wright commented on CONNECTORS-98:
---
There are currently no restrictions on characters in ACF fields, and I'd be
loathe to start adding them just to support one person's idea of the proper URL
over another's.
As for bypassing GetPathInfo, I don't think that's a good idea either. The
purpose of that decoding step is to handle non-legal URI characters and non
7-bit-ascii, both of which we really need.
I think the choice will be between putting all such keys at the end of the URL,
or double-escaping them. But I still have not decided which I prefer.
API should be pure RESTful with the API verb represented using the HTTP
GET/PUT/POST/DELETE methods
-
Key: CONNECTORS-98
URL: https://issues.apache.org/jira/browse/CONNECTORS-98
Project: Apache Connectors Framework
Issue Type: Improvement
Components: API
Affects Versions: LCF Release 0.5
Reporter: Jack Krupansky
Fix For: LCF Release 0.5
(This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
It has come to my attention that the API would be more pure RESTful if the
API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the
input argument identifier represented in the context path.
So, GET outputconnection/get \{connection_name:_connection_name_\} would
be GET outputconnections/connection_name
and GET outputconnection/delete \{connection_name:_connection_name_\}
would be DELETE outputconnections/connection_name
and GET outputconnection/list would be GET outputconnections
and PUT outputconnection/save
\{outputconnection:_output_connection_object_\} would be PUT
outputconnections/connection_name
\{outputconnection:_output_connection_object_\}
What we have today is certainly workable, but just not as pure as some
might desire. It would be better to take care of this before the initial
release so that we never have to answer the question of why it wasn't done as
a proper RESTful API.
BTW, I did check to verify that an HttpServlet running under Jetty can
process the DELETE and PUT methods (using the doDelete and doPut method
overrides.)
Also, POST should be usable as an alternative to PUT for API calls that have
large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be pure RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12907942#action_12907942
]
Karl Wright commented on CONNECTORS-98:
---
Actually, I realize that I *have* decided. Double-encoding will be too
confusing. There is furthermore no reason not to put the connection name at
the end of the url in all cases - in fact, it naturally works best that way, in
my view. Your comment about not using slashes in names may not apply to
end-users, who will be creating these names, but it certainly *does* apply to
the one case I was worried about: creating connector-specific command names.
So I think it's settled.
The final proposal, which I think is the only one that's going to work in all
dimensions, is the following:
outputconnection/get (connection_name) - GET
outputconnection/connection_name ()
outputconnection/save (output_connection_object) - PUT outputconnection
(output_connection_object)
outputconnection/delete (connection_name) - DELETE
outputconnection/connection_name ()
outputconnection/list () - GET outputconnections ()
outputconnection/checkstatus (connection_name) - GET
status/outputconnection/connection_name ()
outputconnection/execute/command (connection_name, arguments) - GET
info/command/outputconnection/connection_name ()
There will, of course, be similar status and info urls for all other
connection types. The constant here is whenever you see /outputconnection/
it is followed by the output connection name. That is why I did not suggest
list/outputconnection, because that breaks that consistency, but I could be
convinced to do that instead of using the plural. I could have turned the
whole thing around but then we would have either parsing conflicts or you'd
need to add more to the url:
outputconnection/get (connection_name) - GET
outputconnection/instance/connection_name ()
... and I didn't think you'd like that.
This will, of course, set the style for all of the rest of the URLs too. I'll
create the full proposal today, just to be sure there are no gotchas.
Note that the things we must GIVE UP for REST are:
(1) Arbitrarily complex JSON arguments to individual connector commands
(2) Commands with / in them, to individual connectors
API should be pure RESTful with the API verb represented using the HTTP
GET/PUT/POST/DELETE methods
-
Key: CONNECTORS-98
URL: https://issues.apache.org/jira/browse/CONNECTORS-98
Project: Apache Connectors Framework
Issue Type: Improvement
Components: API
Affects Versions: LCF Release 0.5
Reporter: Jack Krupansky
Fix For: LCF Release 0.5
(This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
It has come to my attention that the API would be more pure RESTful if the
API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the
input argument identifier represented in the context path.
So, GET outputconnection/get \{connection_name:_connection_name_\} would
be GET outputconnections/connection_name
and GET outputconnection/delete \{connection_name:_connection_name_\}
would be DELETE outputconnections/connection_name
and GET outputconnection/list would be GET outputconnections
and PUT outputconnection/save
\{outputconnection:_output_connection_object_\} would be PUT
outputconnections/connection_name
\{outputconnection:_output_connection_object_\}
What we have today is certainly workable, but just not as pure as some
might desire. It would be better to take care of this before the initial
release so that we never have to answer the question of why it wasn't done as
a proper RESTful API.
BTW, I did check to verify that an HttpServlet running under Jetty can
process the DELETE and PUT methods (using the doDelete and doPut method
overrides.)
Also, POST should be usable as an alternative to PUT for API calls that have
large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be pure RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12907957#action_12907957
]
Karl Wright commented on CONNECTORS-98:
---
Created the full cwiki proposal:
https://cwiki.apache.org/confluence/display/CONNECTORS/REST+API+proposal
API should be pure RESTful with the API verb represented using the HTTP
GET/PUT/POST/DELETE methods
-
Key: CONNECTORS-98
URL: https://issues.apache.org/jira/browse/CONNECTORS-98
Project: Apache Connectors Framework
Issue Type: Improvement
Components: API
Affects Versions: LCF Release 0.5
Reporter: Jack Krupansky
Fix For: LCF Release 0.5
(This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
It has come to my attention that the API would be more pure RESTful if the
API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the
input argument identifier represented in the context path.
So, GET outputconnection/get \{connection_name:_connection_name_\} would
be GET outputconnections/connection_name
and GET outputconnection/delete \{connection_name:_connection_name_\}
would be DELETE outputconnections/connection_name
and GET outputconnection/list would be GET outputconnections
and PUT outputconnection/save
\{outputconnection:_output_connection_object_\} would be PUT
outputconnections/connection_name
\{outputconnection:_output_connection_object_\}
What we have today is certainly workable, but just not as pure as some
might desire. It would be better to take care of this before the initial
release so that we never have to answer the question of why it wasn't done as
a proper RESTful API.
BTW, I did check to verify that an HttpServlet running under Jetty can
process the DELETE and PUT methods (using the doDelete and doPut method
overrides.)
Also, POST should be usable as an alternative to PUT for API calls that have
large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be pure RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908125#action_12908125
]
Karl Wright commented on CONNECTORS-98:
---
It turns out that arguments to some existing connector info methods are also
potentially names that can have / characters in them. That's unfortunate
because I cannot then avoid double-encoding *something*.
API should be pure RESTful with the API verb represented using the HTTP
GET/PUT/POST/DELETE methods
-
Key: CONNECTORS-98
URL: https://issues.apache.org/jira/browse/CONNECTORS-98
Project: Apache Connectors Framework
Issue Type: Improvement
Components: API
Affects Versions: LCF Release 0.5
Reporter: Jack Krupansky
Fix For: LCF Release 0.5
(This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
It has come to my attention that the API would be more pure RESTful if the
API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the
input argument identifier represented in the context path.
So, GET outputconnection/get \{connection_name:_connection_name_\} would
be GET outputconnections/connection_name
and GET outputconnection/delete \{connection_name:_connection_name_\}
would be DELETE outputconnections/connection_name
and GET outputconnection/list would be GET outputconnections
and PUT outputconnection/save
\{outputconnection:_output_connection_object_\} would be PUT
outputconnections/connection_name
\{outputconnection:_output_connection_object_\}
What we have today is certainly workable, but just not as pure as some
might desire. It would be better to take care of this before the initial
release so that we never have to answer the question of why it wasn't done as
a proper RESTful API.
BTW, I did check to verify that an HttpServlet running under Jetty can
process the DELETE and PUT methods (using the doDelete and doPut method
overrides.)
Also, POST should be usable as an alternative to PUT for API calls that have
large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be pure RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908148#action_12908148
]
Jack Krupansky commented on CONNECTORS-98:
--
I am still pondering this embedded slash issue and checking into some things
related to it. Maybe Monday I'll have something more concrete to say.
For example, I want to make sure I understand the rules for what a path can
have in it in a URI and whether simply placing a name at the tail of the path
means it can have slashes or other reserved characters in it. My model is that
a name should occupy only a single path component.
API should be pure RESTful with the API verb represented using the HTTP
GET/PUT/POST/DELETE methods
-
Key: CONNECTORS-98
URL: https://issues.apache.org/jira/browse/CONNECTORS-98
Project: Apache Connectors Framework
Issue Type: Improvement
Components: API
Affects Versions: LCF Release 0.5
Reporter: Jack Krupansky
Fix For: LCF Release 0.5
(This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
It has come to my attention that the API would be more pure RESTful if the
API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the
input argument identifier represented in the context path.
So, GET outputconnection/get \{connection_name:_connection_name_\} would
be GET outputconnections/connection_name
and GET outputconnection/delete \{connection_name:_connection_name_\}
would be DELETE outputconnections/connection_name
and GET outputconnection/list would be GET outputconnections
and PUT outputconnection/save
\{outputconnection:_output_connection_object_\} would be PUT
outputconnections/connection_name
\{outputconnection:_output_connection_object_\}
What we have today is certainly workable, but just not as pure as some
might desire. It would be better to take care of this before the initial
release so that we never have to answer the question of why it wasn't done as
a proper RESTful API.
BTW, I did check to verify that an HttpServlet running under Jetty can
process the DELETE and PUT methods (using the doDelete and doPut method
overrides.)
Also, POST should be usable as an alternative to PUT for API calls that have
large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be pure RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908154#action_12908154
]
Karl Wright commented on CONNECTORS-98:
---
bq. My model is that a name should occupy only a single path component.
That implies double encoding, because even if your standard,
illegal-character-escaping single level of encoding happens to convert / into
%2F, the app server will turn it back into / before you get to see it.
FWIW, there is nothing that stops you from saying this first part of the path
is parsed by me, and the rest of the path is interpreted as a string that can
contain slash characters. Remember, slash characters are LEGAL in URLs. I
don't know what you are reading but a quick glance at just about any url should
convince you of this.
API should be pure RESTful with the API verb represented using the HTTP
GET/PUT/POST/DELETE methods
-
Key: CONNECTORS-98
URL: https://issues.apache.org/jira/browse/CONNECTORS-98
Project: Apache Connectors Framework
Issue Type: Improvement
Components: API
Affects Versions: LCF Release 0.5
Reporter: Jack Krupansky
Fix For: LCF Release 0.5
(This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
It has come to my attention that the API would be more pure RESTful if the
API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the
input argument identifier represented in the context path.
So, GET outputconnection/get \{connection_name:_connection_name_\} would
be GET outputconnections/connection_name
and GET outputconnection/delete \{connection_name:_connection_name_\}
would be DELETE outputconnections/connection_name
and GET outputconnection/list would be GET outputconnections
and PUT outputconnection/save
\{outputconnection:_output_connection_object_\} would be PUT
outputconnections/connection_name
\{outputconnection:_output_connection_object_\}
What we have today is certainly workable, but just not as pure as some
might desire. It would be better to take care of this before the initial
release so that we never have to answer the question of why it wasn't done as
a proper RESTful API.
BTW, I did check to verify that an HttpServlet running under Jetty can
process the DELETE and PUT methods (using the doDelete and doPut method
overrides.)
Also, POST should be usable as an alternative to PUT for API calls that have
large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
