[jira] Updated: (CONNECTORS-91) Making the initialization commands more useable
[ https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jettro Coenradie updated CONNECTORS-91: --- Attachment: change_commands.patch Some strange things are happening, not sure what went wrong. I did do an svn up, I am sure of that. Nevertheless, I think I have it working now. You might need to change the depth of which to apply the patch. I recreated the patch with intellij and it uses one folder of my own. The following command strips of this folder patch -p1 -i ~/change_commands.patch I tried it on a clean checkout of the project locally and it seems to work Hope it works now, sorry I did not try it myself before Making the initialization commands more useable --- Key: CONNECTORS-91 URL: https://issues.apache.org/jira/browse/CONNECTORS-91 Project: Apache Connectors Framework Issue Type: Improvement Components: Framework core Reporter: Jettro Coenradie Fix For: LCF Release 0.5 Attachments: change_commands.patch At the moment LCF comes with some classes that can be used to run command line to interact with the system. Examples are DBCreate, DBDrop and LockClean. I wanted to create a class that rebuilds my complete environment. So dropping a database, creating a database, cleaning the synch folder, registering agents, etc. Due to the structure of the classes with all the logic in the main method, I could not easily reuse these classes. In the patch I submit with issue I have refactored the current solution in a better reuseable solution that can still be called command line. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CONNECTORS-91) Making the initialization commands more useable
[ https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jettro Coenradie updated CONNECTORS-91: --- Attachment: (was: changesToCommandClasses.patch) Making the initialization commands more useable --- Key: CONNECTORS-91 URL: https://issues.apache.org/jira/browse/CONNECTORS-91 Project: Apache Connectors Framework Issue Type: Improvement Components: Framework core Reporter: Jettro Coenradie Fix For: LCF Release 0.5 Attachments: change_commands.patch At the moment LCF comes with some classes that can be used to run command line to interact with the system. Examples are DBCreate, DBDrop and LockClean. I wanted to create a class that rebuilds my complete environment. So dropping a database, creating a database, cleaning the synch folder, registering agents, etc. Due to the structure of the classes with all the logic in the main method, I could not easily reuse these classes. In the patch I submit with issue I have refactored the current solution in a better reuseable solution that can still be called command line. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CONNECTORS-91) Making the initialization commands more useable
[ https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jettro Coenradie updated CONNECTORS-91: --- Comment: was deleted (was: sorry, pushed the wrong button I guess) Making the initialization commands more useable --- Key: CONNECTORS-91 URL: https://issues.apache.org/jira/browse/CONNECTORS-91 Project: Apache Connectors Framework Issue Type: Improvement Components: Framework core Reporter: Jettro Coenradie Fix For: LCF Release 0.5 Attachments: change_commands.patch At the moment LCF comes with some classes that can be used to run command line to interact with the system. Examples are DBCreate, DBDrop and LockClean. I wanted to create a class that rebuilds my complete environment. So dropping a database, creating a database, cleaning the synch folder, registering agents, etc. Due to the structure of the classes with all the logic in the main method, I could not easily reuse these classes. In the patch I submit with issue I have refactored the current solution in a better reuseable solution that can still be called command line. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CONNECTORS-91) Making the initialization commands more useable
[ https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jettro Coenradie updated CONNECTORS-91: --- Comment: was deleted (was: Some strange things are happening, not sure what went wrong. I did do an svn up, I am sure of that. Nevertheless, I think I have it working now. You might need to change the depth of which to apply the patch. I recreated the patch with intellij and it uses one folder of my own. The following command strips of this folder patch -p1 -i ~/change_commands.patch I tried it on a clean checkout of the project locally and it seems to work Hope it works now, sorry I did not try it myself before) Making the initialization commands more useable --- Key: CONNECTORS-91 URL: https://issues.apache.org/jira/browse/CONNECTORS-91 Project: Apache Connectors Framework Issue Type: Improvement Components: Framework core Reporter: Jettro Coenradie Fix For: LCF Release 0.5 Attachments: change_commands.patch At the moment LCF comes with some classes that can be used to run command line to interact with the system. Examples are DBCreate, DBDrop and LockClean. I wanted to create a class that rebuilds my complete environment. So dropping a database, creating a database, cleaning the synch folder, registering agents, etc. Due to the structure of the classes with all the logic in the main method, I could not easily reuse these classes. In the patch I submit with issue I have refactored the current solution in a better reuseable solution that can still be called command line. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-91) Making the initialization commands more useable
[ https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901309#action_12901309 ] Karl Wright commented on CONNECTORS-91: --- This patch file worked properly. Since the automated tests do not exercise the commands, it would be good to set up a database instance from scratch using the changed code. If you have already done this, please let me know and I will go ahead and commit the changes. Making the initialization commands more useable --- Key: CONNECTORS-91 URL: https://issues.apache.org/jira/browse/CONNECTORS-91 Project: Apache Connectors Framework Issue Type: Improvement Components: Framework core Reporter: Jettro Coenradie Fix For: LCF Release 0.5 Attachments: change_commands.patch At the moment LCF comes with some classes that can be used to run command line to interact with the system. Examples are DBCreate, DBDrop and LockClean. I wanted to create a class that rebuilds my complete environment. So dropping a database, creating a database, cleaning the synch folder, registering agents, etc. Due to the structure of the classes with all the logic in the main method, I could not easily reuse these classes. In the patch I submit with issue I have refactored the current solution in a better reuseable solution that can still be called command line. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Need an opinion, on whether to change package or not
+1 for a complete change On Mon, Aug 23, 2010 at 6:34 AM, Mark Miller markrmil...@gmail.com wrote: +1 to renaming the package - nows the time. - Mark http://www.lucidimagination.com (mobile) On Aug 22, 2010, at 8:01 PM, Jack Krupansky jack.krupan...@lucidimagination.com wrote: +1 -- Jack Krupansky -- From: Karl Wright daddy...@gmail.com Sent: Sunday, August 22, 2010 1:49 PM To: connectors-dev connectors-dev@incubator.apache.org Subject: Need an opinion, on whether to change package or not Consider this an official request for a vote. +1 indicates you think we should change the following in the source code, as soon as is practical: org.apache.lcf.xxx - org.apache.acf.xxx All classes LCF.java and LCFException.java should change to ACF.java and ACFException.java Bear in mind that users of ACF/LCF who currently have existing database instances will need to reinitialize those instances if we do this change. This is because the class names of connectors are stored in the database when the connector is registered. (FWIW, my vote on this is -1. It doesn't seem worth the disruption. But I will of course abide by the consensus.) Vote will be considered closed by Wednesday evening, so vote early (and often. ;-)) Karl -- Jettro Coenradie http://www.gridshore.nl
Re: Need an opinion, on whether to change package or not
On Mon, Aug 23, 2010 at 10:35 AM, Jettro Coenradie jettro.coenra...@gridshore.nl wrote: If we are changing stuff can we also use more descriptive names. Not Use LCF 4 to 5 times in a different Package. Use something like ACFAgent and ACFCrawler +1 for that too! simon On Mon, Aug 23, 2010 at 10:33 AM, Jettro Coenradie jettro.coenra...@gridshore.nl wrote: +1 for a complete change On Mon, Aug 23, 2010 at 6:34 AM, Mark Miller markrmil...@gmail.comwrote: +1 to renaming the package - nows the time. - Mark http://www.lucidimagination.com (mobile) On Aug 22, 2010, at 8:01 PM, Jack Krupansky jack.krupan...@lucidimagination.com wrote: +1 -- Jack Krupansky -- From: Karl Wright daddy...@gmail.com Sent: Sunday, August 22, 2010 1:49 PM To: connectors-dev connectors-dev@incubator.apache.org Subject: Need an opinion, on whether to change package or not Consider this an official request for a vote. +1 indicates you think we should change the following in the source code, as soon as is practical: org.apache.lcf.xxx - org.apache.acf.xxx All classes LCF.java and LCFException.java should change to ACF.java and ACFException.java Bear in mind that users of ACF/LCF who currently have existing database instances will need to reinitialize those instances if we do this change. This is because the class names of connectors are stored in the database when the connector is registered. (FWIW, my vote on this is -1. It doesn't seem worth the disruption. But I will of course abide by the consensus.) Vote will be considered closed by Wednesday evening, so vote early (and often. ;-)) Karl -- Jettro Coenradie http://www.gridshore.nl -- Jettro Coenradie http://www.gridshore.nl
[jira] Commented: (CONNECTORS-91) Making the initialization commands more useable
[ https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901312#action_12901312 ] Karl Wright commented on CONNECTORS-91: --- Another thing I had not noticed before is that this patch removes all stderr success confirmation messages for those folks who use the commands, and replaces them with log output. The log output is perfectly fine, but removing the feedback that the command was successful is, I think, not great. If the log were going to stderr typically that would be OK, but it typically is not, so I think you are going to want to do both. You would, obviously, want to do the stderr output within the main() method. Would it be possible to fix that up before I commit this? Making the initialization commands more useable --- Key: CONNECTORS-91 URL: https://issues.apache.org/jira/browse/CONNECTORS-91 Project: Apache Connectors Framework Issue Type: Improvement Components: Framework core Reporter: Jettro Coenradie Fix For: LCF Release 0.5 Attachments: change_commands.patch At the moment LCF comes with some classes that can be used to run command line to interact with the system. Examples are DBCreate, DBDrop and LockClean. I wanted to create a class that rebuilds my complete environment. So dropping a database, creating a database, cleaning the synch folder, registering agents, etc. Due to the structure of the classes with all the logic in the main method, I could not easily reuse these classes. In the patch I submit with issue I have refactored the current solution in a better reuseable solution that can still be called command line. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-91) Making the initialization commands more useable
[ https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901316#action_12901316 ] Jettro Coenradie commented on CONNECTORS-91: Hmm, I think the logging option is better, if people provide the right configuration you have what you need and even more. But I understand what you mean with the main method implementation. I'll add it back and provide a new patch. I also tried the sample with the new classes and it all seems to work. Is that good enough? Making the initialization commands more useable --- Key: CONNECTORS-91 URL: https://issues.apache.org/jira/browse/CONNECTORS-91 Project: Apache Connectors Framework Issue Type: Improvement Components: Framework core Reporter: Jettro Coenradie Fix For: LCF Release 0.5 Attachments: change_commands.patch At the moment LCF comes with some classes that can be used to run command line to interact with the system. Examples are DBCreate, DBDrop and LockClean. I wanted to create a class that rebuilds my complete environment. So dropping a database, creating a database, cleaning the synch folder, registering agents, etc. Due to the structure of the classes with all the logic in the main method, I could not easily reuse these classes. In the patch I submit with issue I have refactored the current solution in a better reuseable solution that can still be called command line. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CONNECTORS-91) Making the initialization commands more useable
[ https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jettro Coenradie updated CONNECTORS-91: --- Attachment: change_commands_with_system_err_println.patch added system err println lines back to the main methods Making the initialization commands more useable --- Key: CONNECTORS-91 URL: https://issues.apache.org/jira/browse/CONNECTORS-91 Project: Apache Connectors Framework Issue Type: Improvement Components: Framework core Reporter: Jettro Coenradie Fix For: LCF Release 0.5 Attachments: change_commands.patch, change_commands_with_system_err_println.patch At the moment LCF comes with some classes that can be used to run command line to interact with the system. Examples are DBCreate, DBDrop and LockClean. I wanted to create a class that rebuilds my complete environment. So dropping a database, creating a database, cleaning the synch folder, registering agents, etc. Due to the structure of the classes with all the logic in the main method, I could not easily reuse these classes. In the patch I submit with issue I have refactored the current solution in a better reuseable solution that can still be called command line. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Need an opinion, on whether to change package or not
In any open-source project there is expected to be some differences in individual coding styles. There is often also incomplete understanding of the reasoning behind the multitude of architectural decisions made during development, or the history of the project. It is thus important to be pragmatic, and therefore each issue or question is basically its own topic, evaluated on its own merits. Probably the best way to deal with each *individual* concern or question is to open a jira ticket expressing that concern. Discussion should then be done within the context of that ticket. There is no guarantee, of course, that the ticket will be acted upon, but at least it will be discussed. Karl From: jettro.coenra...@gmail.com [jettro.coenra...@gmail.com] On Behalf Of ext Jettro Coenradie [jettro.coenra...@gridshore.nl] Sent: Monday, August 23, 2010 5:17 AM To: connectors-dev@incubator.apache.org Subject: Re: Need an opinion, on whether to change package or not I can understand that it is harder to do. Therefore it is better notto do it right now. I do not agree with you that it is easier to move files from one package to another. The fact that these classes have different impact should make you think before moving the classes. I would like to discuss on some of these design/code issues more as well. What is the best way to do this? Ask a question per topic to share opinions? thanks Jettro On Mon, Aug 23, 2010 at 10:54 AM, karl.wri...@nokia.com wrote: Unfortunately that is way harder to do using the python scripts I have developed for this purpose. Also, the reason the LCF root class appears in different packages has to do with the relative ease that grants to moving classes between the various acf jars. So I'd consider this proposed change to be controversial, and I don't think we should layer it in without separate consideration. Karl From: ext Simon Willnauer [simon.willna...@googlemail.com] Sent: Monday, August 23, 2010 4:40 AM To: connectors-dev@incubator.apache.org Subject: Re: Need an opinion, on whether to change package or not On Mon, Aug 23, 2010 at 10:35 AM, Jettro Coenradie jettro.coenra...@gridshore.nl wrote: If we are changing stuff can we also use more descriptive names. Not Use LCF 4 to 5 times in a different Package. Use something like ACFAgent and ACFCrawler +1 for that too! simon On Mon, Aug 23, 2010 at 10:33 AM, Jettro Coenradie jettro.coenra...@gridshore.nl wrote: +1 for a complete change On Mon, Aug 23, 2010 at 6:34 AM, Mark Miller markrmil...@gmail.com wrote: +1 to renaming the package - nows the time. - Mark http://www.lucidimagination.com (mobile) On Aug 22, 2010, at 8:01 PM, Jack Krupansky jack.krupan...@lucidimagination.com wrote: +1 -- Jack Krupansky -- From: Karl Wright daddy...@gmail.com Sent: Sunday, August 22, 2010 1:49 PM To: connectors-dev connectors-dev@incubator.apache.org Subject: Need an opinion, on whether to change package or not Consider this an official request for a vote. +1 indicates you think we should change the following in the source code, as soon as is practical: org.apache.lcf.xxx - org.apache.acf.xxx All classes LCF.java and LCFException.java should change to ACF.java and ACFException.java Bear in mind that users of ACF/LCF who currently have existing database instances will need to reinitialize those instances if we do this change. This is because the class names of connectors are stored in the database when the connector is registered. (FWIW, my vote on this is -1. It doesn't seem worth the disruption. But I will of course abide by the consensus.) Vote will be considered closed by Wednesday evening, so vote early (and often. ;-)) Karl -- Jettro Coenradie http://www.gridshore.nl -- Jettro Coenradie http://www.gridshore.nl -- Jettro Coenradie http://www.gridshore.nl
[jira] Commented: (CONNECTORS-91) Making the initialization commands more useable
[
https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901336#action_12901336
]
Karl Wright commented on CONNECTORS-91:
---
I looked at this. The patch seems correct for some classes, but for others it
is clearly incorrect, e.g. SynchronizeAll:
{
System.err.println(Usage: SynchronizeAll);
System.exit(1);
+ System.err.println(Successfully synchronized all agents);
}
Can you review your change for accuracy please?
Also, responding to the logging change - the log settings are global, and we
are trying for the least amount of setup work necessary to achieve a functional
system. Clearly, all log messages to stderr is not going to be reasonable for
people doing real crawls, so we'd need some way to segregate command output in
order to direct it differently than everything else, which implies at the least
you'd want a different logger, and then you'd also want to revise the
documented log4j properties, if you think we should go that route.
Re: testing. The testing you've done so far is best we can do at the moment,
unless you'd also like to write some unit tests. I don't think this would be
terribly difficult, but once again it would be time consuming. ;-)
Making the initialization commands more useable
---
Key: CONNECTORS-91
URL: https://issues.apache.org/jira/browse/CONNECTORS-91
Project: Apache Connectors Framework
Issue Type: Improvement
Components: Framework core
Reporter: Jettro Coenradie
Fix For: LCF Release 0.5
Attachments: change_commands.patch,
change_commands_with_system_err_println.patch
At the moment LCF comes with some classes that can be used to run command
line to interact with the system. Examples are DBCreate, DBDrop and
LockClean. I wanted to create a class that rebuilds my complete environment.
So dropping a database, creating a database, cleaning the synch folder,
registering agents, etc. Due to the structure of the classes with all the
logic in the main method, I could not easily reuse these classes. In the
patch I submit with issue I have refactored the current solution in a better
reuseable solution that can still be called command line.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CONNECTORS-91) Making the initialization commands more useable
[ https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jettro Coenradie updated CONNECTORS-91: --- Attachment: change_commands_with_system_err_println_v2.patch Sorry about the errors, I was a little bit to quick. I double checked all locations of printing the messages and the messages themselves. They should all be fine now. Making the initialization commands more useable --- Key: CONNECTORS-91 URL: https://issues.apache.org/jira/browse/CONNECTORS-91 Project: Apache Connectors Framework Issue Type: Improvement Components: Framework core Reporter: Jettro Coenradie Fix For: LCF Release 0.5 Attachments: change_commands.patch, change_commands_with_system_err_println.patch, change_commands_with_system_err_println_v2.patch At the moment LCF comes with some classes that can be used to run command line to interact with the system. Examples are DBCreate, DBDrop and LockClean. I wanted to create a class that rebuilds my complete environment. So dropping a database, creating a database, cleaning the synch folder, registering agents, etc. Due to the structure of the classes with all the logic in the main method, I could not easily reuse these classes. In the patch I submit with issue I have refactored the current solution in a better reuseable solution that can still be called command line. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CONNECTORS-91) Making the initialization commands more useable
[ https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright reassigned CONNECTORS-91: - Assignee: Karl Wright Making the initialization commands more useable --- Key: CONNECTORS-91 URL: https://issues.apache.org/jira/browse/CONNECTORS-91 Project: Apache Connectors Framework Issue Type: Improvement Components: Framework core Reporter: Jettro Coenradie Assignee: Karl Wright Fix For: LCF Release 0.5 Attachments: change_commands.patch, change_commands_with_system_err_println.patch, change_commands_with_system_err_println_v2.patch At the moment LCF comes with some classes that can be used to run command line to interact with the system. Examples are DBCreate, DBDrop and LockClean. I wanted to create a class that rebuilds my complete environment. So dropping a database, creating a database, cleaning the synch folder, registering agents, etc. Due to the structure of the classes with all the logic in the main method, I could not easily reuse these classes. In the patch I submit with issue I have refactored the current solution in a better reuseable solution that can still be called command line. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CONNECTORS-91) Making the initialization commands more useable
[ https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright resolved CONNECTORS-91. --- Resolution: Fixed Patch committed. r988101. Making the initialization commands more useable --- Key: CONNECTORS-91 URL: https://issues.apache.org/jira/browse/CONNECTORS-91 Project: Apache Connectors Framework Issue Type: Improvement Components: Framework core Reporter: Jettro Coenradie Assignee: Karl Wright Fix For: LCF Release 0.5 Attachments: change_commands.patch, change_commands_with_system_err_println.patch, change_commands_with_system_err_println_v2.patch At the moment LCF comes with some classes that can be used to run command line to interact with the system. Examples are DBCreate, DBDrop and LockClean. I wanted to create a class that rebuilds my complete environment. So dropping a database, creating a database, cleaning the synch folder, registering agents, etc. Due to the structure of the classes with all the logic in the main method, I could not easily reuse these classes. In the patch I submit with issue I have refactored the current solution in a better reuseable solution that can still be called command line. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Question about the json library
The sources were downloaded from www.json.org, and are licensed accordingly. There is no build available from www.json.org. If you know of a prebuilt version of these sources, by all means point us at it. Mavenization is a different issue, and will have to be done independently. Karl -Original Message- From: jettro.coenra...@gmail.com [mailto:jettro.coenra...@gmail.com] On Behalf Of ext Jettro Coenradie Sent: Monday, August 23, 2010 10:04 AM To: connectors-dev@incubator.apache.org Subject: Question about the json library I am looking at the classes that come with the current trunk checkout and I see that a custom jar of json is created. Can someone explain why this is? Could we also take one from a maven repository? thanks, Jettro -- Jettro Coenradie http://www.gridshore.nl
Re: Question about the json library
I know maven is another issue, but it is nice if the version is available through a maven repository. Than other build tools can find it as well. It is available for download through: http://mvnrepository.com/artifact/org.json/json or from the central maven repo: http://repo2.maven.org/maven2/org/json/json/20090211/json-20090211.jar Jettro On Mon, Aug 23, 2010 at 4:16 PM, karl.wri...@nokia.com wrote: The sources were downloaded from www.json.org, and are licensed accordingly. There is no build available from www.json.org. If you know of a prebuilt version of these sources, by all means point us at it. Mavenization is a different issue, and will have to be done independently. Karl -Original Message- From: jettro.coenra...@gmail.com [mailto:jettro.coenra...@gmail.com] On Behalf Of ext Jettro Coenradie Sent: Monday, August 23, 2010 10:04 AM To: connectors-dev@incubator.apache.org Subject: Question about the json library I am looking at the classes that come with the current trunk checkout and I see that a custom jar of json is created. Can someone explain why this is? Could we also take one from a maven repository? thanks, Jettro -- Jettro Coenradie http://www.gridshore.nl -- Jettro Coenradie http://www.gridshore.nl
[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: Screen shot 2010-08-23 at 16.31.07.png idea of the directory structure 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 Attachments: 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.
Re: improving the build
That is a good idea, maven can call ant to execute tasks. The jars are available in the maven repository and should therefore not be to hard to make available to the ant build. Would be nice to have an idea of the amount of scripts that we need to alter to make this happen. I also see a lot of shell scripts that might need attention if we change this. - Jettro On Mon, Aug 23, 2010 at 4:52 PM, karl.wri...@nokia.com wrote: Re: build preferences Continuing to have an ant build is actually pretty important for some modes of delivery. I'm specifically thinking of debian and Ubuntu packaging here. Maven does not work well with these packaging schemes because it's too all-encompassing. We therefore need a way of doing builds locally, without pulling things down from a mirror. My original thought was that we'd have multiple layers - ant being the most basic, with a maven wrapper available to pull down what the ant build needed, and have the maven build call ant underneath. I don't know how realistic that is, but it does solve all the problems if it can be done that way. Karl From: jettro.coenra...@gmail.com [mailto:jettro.coenra...@gmail.com] On Behalf Of ext Jettro Coenradie Sent: Monday, August 23, 2010 10:43 AM To: connectors-dev@incubator.apache.org Subject: Re: improving the build 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 mail Jettro On Mon, Aug 16, 2010 at 3:12 PM, Jettro Coenradie jettro.coenra...@gridshore.nlmailto:jettro.coenra...@gridshore.nl wrote: We could use something like profiles in maven. That way you can easily configure which projects to compile and which not. That would include tests. I will have a look at it and come up with a proposal. On Mon, Aug 16, 2010 at 2:49 PM, karl.wri...@nokia.commailto: karl.wri...@nokia.com wrote: Re maven: There is a wiki page describing the Maven dependencies; somebody needs to tackle this. If you want to volunteer, we'd love to hear your proposal. However, please remember that you really must be sure to retain the connector conditional compilation structure as is currently in place, for license reasons. Re unit tests: The Junit test code was actually placed carefully based on the above considerations. In other words, you can't run a test that requires connectors x,y,z unless those connectors have actually been built. Similarly, you may think in terms of testing a specific connector by including tests for that connector, but those tests cannot use any OTHER connectors or you will break the build, which is why any tests that use multiple connectors must be at the module level. Karl -Original Message- From: jettro.coenra...@gmail.commailto:jettro.coenra...@gmail.com [mailto:jettro.coenra...@gmail.commailto:jettro.coenra...@gmail.com] On Behalf Of ext Jettro Coenradie Sent: Monday, August 16, 2010 8:21 AM To: connectors-dev@incubator.apache.orgmailto: connectors-dev@incubator.apache.org Subject: improving the build Hi, I think the current download is pretty big. Is there is good reason that we do not use something like maven. Or at least, if you do not like maven, ivy to share dependencies between projects. Also enforces you to use libraries that are generally available. I would also love to have the (unit)tests closer to the actual code, hard to locate the tests at the moment Would like to hear the thoughts of the developers regards -- Jettro Coenradie http://www.gridshore.nl -- Jettro Coenradie http://www.gridshore.nl -- Jettro Coenradie http://www.gridshore.nl -- Jettro Coenradie http://www.gridshore.nl
[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=12901432#action_12901432 ] Karl Wright commented on CONNECTORS-92: --- This proposed change has a number of features I don't understand the reasons for: (1) Breaking up modules and putting pieces of that all over the place (2) Taking jetty-runner out of framework (3) Introducing a src directory under each of the framework components (4) Moving the tests so far away from the code they are related to Can you describe your logic for this reorganization? 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 Attachments: 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=12901436#action_12901436 ] Karl Wright commented on CONNECTORS-92: --- Re: build preferences Continuing to have an ant build is actually pretty important for some modes of delivery. I'm specifically thinking of debian and Ubuntu packaging here. Maven does not work well with these packaging schemes because it's too all-encompassing. We therefore need a way of doing builds locally, without pulling things down from a mirror. My original thought was that we'd have multiple layers - ant being the most basic, with a maven wrapper available to pull down what the ant build needed, and have the maven build call ant underneath. I don't know how realistic that is, but it does solve all the problems if it can be done that way. 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 Attachments: 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.
Wiki space name
Hi, I've discovered where, at least, you are supposed to change the name of a Wiki space. There's a browse project icon from the Dashboard page, and within that there's an Advanced tab. That tab shows the Space name as part of the Space details. Unfortunately, I don't seem to have the ability to edit the Space details for the CONNECTORS space. The person who set this up was Jukka (Zitting). Jukka, do you want to do this? Does anyone else have permission? Karl
change the format of CHANGES.txt
Hello, I wanted to suggest that we slightly alter the format of CHANGES.txt. Most important I think is to add the names of non-committers who contribute any patches, JIRA comments, reports of bugs on the user list, etc to the issue. This is how the CHANGES.txt is formulated for Lucene and Solr and I think it encourages contributors to come back, because they get some credit for their contributions. Any thoughts? I think it would be really good to add all contributors to any jira issues before the first release especially. -- Robert Muir rcm...@gmail.com
Re: change the format of CHANGES.txt
On Aug 23, 2010, at 4:04 PM, Robert Muir wrote: Hello, I wanted to suggest that we slightly alter the format of CHANGES.txt. Most important I think is to add the names of non-committers who contribute any patches, JIRA comments, reports of bugs on the user list, etc to the issue. This is how the CHANGES.txt is formulated for Lucene and Solr and I think it encourages contributors to come back, because they get some credit for their contributions. Any thoughts? I think it would be really good to add all contributors to any jira issues before the first release especially. +1. We definitely should be giving credit to those who help.
Re: change the format of CHANGES.txt
ok I created https://issues.apache.org/jira/browse/CONNECTORS-93 https://issues.apache.org/jira/browse/CONNECTORS-93I can start going thru mail archives and issues that are resolved and look for contributors. If you have some free time and want to help, please feel free and just comment/upload on the issue. I think this is really important before any release happens. On Mon, Aug 23, 2010 at 4:31 PM, Simon Willnauer simon.willna...@googlemail.com wrote: +1 On Mon, Aug 23, 2010 at 10:18 PM, Grant Ingersoll gsing...@apache.org wrote: On Aug 23, 2010, at 4:04 PM, Robert Muir wrote: Hello, I wanted to suggest that we slightly alter the format of CHANGES.txt. Most important I think is to add the names of non-committers who contribute any patches, JIRA comments, reports of bugs on the user list, etc to the issue. This is how the CHANGES.txt is formulated for Lucene and Solr and I think it encourages contributors to come back, because they get some credit for their contributions. Any thoughts? I think it would be really good to add all contributors to any jira issues before the first release especially. +1. We definitely should be giving credit to those who help. -- Robert Muir rcm...@gmail.com
RE: change the format of CHANGES.txt
+1 from me. Karl -Original Message- From: ext Robert Muir [mailto:rcm...@gmail.com] Sent: Monday, August 23, 2010 4:05 PM To: connectors-dev@incubator.apache.org Subject: change the format of CHANGES.txt Hello, I wanted to suggest that we slightly alter the format of CHANGES.txt. Most important I think is to add the names of non-committers who contribute any patches, JIRA comments, reports of bugs on the user list, etc to the issue. This is how the CHANGES.txt is formulated for Lucene and Solr and I think it encourages contributors to come back, because they get some credit for their contributions. Any thoughts? I think it would be really good to add all contributors to any jira issues before the first release especially. -- Robert Muir rcm...@gmail.com
Re: change the format of CHANGES.txt
I think this also underscores something we as an Incubating community should think about in terms of process. Obviously, it is great to give credit, but sometimes we also need to give people a chance to contribute, too. Even on seemingly trivial things (I don't have anything specific in mind) sometimes it makes sense to wait before making the change. For instance, say someone opens an issue, it might work to say something like Hey, great catch. Could you generate a patch? See https://cwiki.apache.org/confluence/display/CONNECTORS/HowToContribute for info on how to do that. If they do give one, then commit it promptly and give them credit. If not, let it sit for a few days before making the change to see if someone else steps up. Sure, it slows down some things, but it gives people a chance to help out and be involved. These smaller issues are also a great way for us newbie committers to get our hands dirty with the code. -Grant On Aug 23, 2010, at 4:46 PM, karl.wri...@nokia.com wrote: +1 from me. Karl -Original Message- From: ext Robert Muir [mailto:rcm...@gmail.com] Sent: Monday, August 23, 2010 4:05 PM To: connectors-dev@incubator.apache.org Subject: change the format of CHANGES.txt Hello, I wanted to suggest that we slightly alter the format of CHANGES.txt. Most important I think is to add the names of non-committers who contribute any patches, JIRA comments, reports of bugs on the user list, etc to the issue. This is how the CHANGES.txt is formulated for Lucene and Solr and I think it encourages contributors to come back, because they get some credit for their contributions. Any thoughts? I think it would be really good to add all contributors to any jira issues before the first release especially. -- Robert Muir rcm...@gmail.com
