[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: maven-poms-problem-starting-jetty-and-derby.patch This is a patch that addes poms to the framework part. It runs after you have installed the one missing jar. In the end the mvn clean install should be successful in the root of the framework directory In the crawler-ui project you can do : mvn clean jetty:run-war This will start up the crawler-ui, only after you have copied the conenctors that you need to the src/config/local/connector-lib Than asking for a list of connectors results in a database error. I just cannot get the Derby instance to run. The database is created but if seems not to be running. Any help in this area would be appreciated. Caused by: ERROR 42Y07: Schema 'ACF' does not exist at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(Unknown Source) at org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(Unknown Source) at org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(Unknown Source) at org.apache.derby.impl.sql.compile.FromBaseTable.bindTableDescriptor(Unknown Source) at org.apache.derby.impl.sql.compile.FromBaseTable.bindNonVTITables(Unknown Source) at org.apache.derby.impl.sql.compile.FromList.bindTables(Unknown Source) at org.apache.derby.impl.sql.compile.SelectNode.bindNonVTITables(Unknown Source) at org.apache.derby.impl.sql.compile.DMLStatementNode.bindTables(Unknown Source) at org.apache.derby.impl.sql.compile.DMLStatementNode.bind(Unknown Source) at org.apache.derby.impl.sql.compile.CursorNode.bindStatement(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) ... 4 more 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: maven-poms-problem-starting-jetty-and-derby.patch, move-to-maven-acf-framework.patch, 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=12904205#action_12904205 ] Karl Wright commented on CONNECTORS-92: --- Jettro, If you are using maven to start jetty directly, it will not work. You are missing the jetty runner, which only starts jetty at the end of a number of steps, including creating the database properly and setting up the schema and registering the connectors. Then, the crawler itself is started as a separate thread. It took me many weeks to get everything to work properly using jetty. Changing all this stuff around does not seem either warranted or useful at this time. I strongly recommend that you concentrate on using maven to actually build the software, and not try to re-engineer the example right now. 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: maven-poms-problem-starting-jetty-and-derby.patch, move-to-maven-acf-framework.patch, 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=12904209#action_12904209 ] Karl Wright commented on CONNECTORS-92: --- I've had a cursory glance at the pom files and they all look reasonable. I'm going to play around with this a bit locally to see how it behaves, and then if all seems OK I am happy to commit those. 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: maven-poms-problem-starting-jetty-and-derby.patch, move-to-maven-acf-framework.patch, 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=12904219#action_12904219 ] Karl Wright commented on CONNECTORS-92: --- bq. I am still thinking about why this is so hard. Would be nice to have something like a servlet or filter that initializes everything that you do in your special runner now. The issues have to do with these facts: - Embedded derby is single-process. You cannot run more than one process against a given database at a given time. - ACF supports both single-process and multi-process models, but IF you're going to use single-process, you need to have a main class that starts up all the threads that would otherwise be different processes. That's what jetty-runner does, in part. So, obviously, something like jetty-runner needs to exist if you are going to use derby. I don't think maven magic will suffice to replace the code that does that. Furthermore, I think trying to get maven to do this for us is overkill. I'm open to suggestions, but I still don't think you need to solve this problem in order to have ACF be built effectively by maven. What I think we need to build at the framework level are all the jars and wars (which it looks like you have pretty well specified), PLUS a start.jar (which I didn't see anywhere - did I miss it?). Then your example execution will not be a jetty instance per se, but will simply fire off the equivalent of java -jar start.jar. I can't believe there isn't a maven plugin for that. This, of course, must happen at the modules level, because no connectors will be available at the framework level. 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: maven-poms-problem-starting-jetty-and-derby.patch, move-to-maven-acf-framework.patch, 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: About name change
Open Connectors Framework is good, but suffers from the same broadness issue that Apache Connectors Framework has, no? Yukon is fine but is already used - see https://devel.neopsis.com/projects/yukon/ Here are my thoughts about a more restricted CF-style name: Repository Connectors Framework CM Connectors Framework Combining an abstract name plus the descriptive name may get us somewhere: Yukon Connectors Framework Acromantula Connectors Framework (this is actually great because I don't have to rename the bloody source packages again!) I'm not too keen on just a simple abstract name - too meaningless for me. Karl On Mon, Aug 30, 2010 at 12:50 PM, Grant Ingersoll gsing...@apache.orgwrote: So, there were some other suggestions on the Incubator list. What do people think of the Open Connector Framework? OCF? (Granted, it is silly to me given it will be the Apache Open Conn. Framework, which still implies it is the Apache one.) Any other suggestions? On Aug 26, 2010, at 9:04 AM, Jack Krupansky wrote: Personally, I'd rather see a traditional, Apache-style name, but I can certainly live with whatever the PMC (?) endorses. I agree with the general@ criticism that the ACF name comes across as being the ultimate end-all connector framework for Apache land (land grab). We should acknowledge that in the future there might be other projects that seek to offer connector frameworks in Apache land. There really should be a handle to qualify the purely descriptive portion of the name - and we had one: Lucene, but it wasn't unique and even there did not acknowledge that in the future there could be other connector frameworks. Note: We effectively have a handle name today: LCF or ACF, but it is a distinctly non-Apache style of name. Why not go with an Apache-style name. That said, I do see that there are a minority of Apache Projects that have descriptive names, including HttpComponents, OpenWebBeans, TrafficServer, Web Services, XML Graphics. Well, there is also HTTP Server as well, but that is an anomaly since it is really just the original Apache itself. Maybe the question is what the current consensus preference is in Apache land and trying to go with the flow rather than try to go against the flow. In short, even if Connectors Framework remains the tail end of the name, a handle prefix is needed. Apache is the general prefix for ALL Apache projects and not a handle for any of them. If that handle is Connecto, the full name could be Connecto Connectors Framework, and the official project name would be Apache Connecto Connectors Framework. That said, I am not a fan of trying to put the project description into the name in raw English form. So, my preference there would be to drop Connectors Framework from the name and stick with Connecto, or whatever other handle is chosen. As I said, I will defer to the PMC (?) endorses, but I would hope that there is some consistency with current and traditional Apache project naming conventions. -- Jack Krupansky -- From: Simon Willnauer simon.willna...@googlemail.com Sent: Thursday, August 26, 2010 7:50 AM To: Grant Ingersoll gsing...@apache.org Cc: connectors-dev@incubator.apache.org Subject: Re: About name change On Thu, Aug 26, 2010 at 12:42 PM, Grant Ingersoll gsing...@apache.org wrote: On Aug 26, 2010, at 6:14 AM, Karl Wright wrote: Is it clear that ACF is dead? The concern raised was that it implied something that connected lots of stuff together, and that's not what it was. But I think that that IS what it is, so the poster knew little or nothing about the project, and was operating from ignorance. Does it make sense to clarify what ACF does to the general list first? I think it is worthwhile. You want to take a crack at it? Absolutely +1 - I just have the impression that people are already biased by Tomcat Connector etc. but I will be a supporter of Apache Connector FW, no doubt. If it is not an option we can still discuss here! simon Karl On Thu, Aug 26, 2010 at 5:26 AM, Simon Willnauer simon.willna...@googlemail.com wrote: Hey folks, I was following the discussion about changing the name to Apache Connector Framework and the late response from people on gene...@. Obviously we need to decide on something else than Apache Connectors Framework since many people had concerns about the name and possible confusion. I have the impression we should first collect some suggestions about alternative names here before we continue discussion on the gene...@. Once we have a name we all agreed on and doesn't apply to the concerns others had we should go back and discuss further. Some folks suggested a more abstract name like Apache Connecto which I personally like (not necessarily Connecto but a more abstract name. Such names have many advantages as people remember short
Re: About name change
snip - Consider using functional names, especially for products of existing projects, e.g. for an Apache Foo project, the product name Apache Foo Pipelines. -snip Granted, Lucene Connectors Framework fills this to a T, but this would imply that functional names are OK for top-level projects too. Karl On Mon, Aug 30, 2010 at 1:24 PM, Mark Miller markrmil...@gmail.com wrote: On 8/30/10 1:05 PM, Karl Wright wrote: I'm not too keen on just a simple abstract name - too meaningless for me. It works for countless Apache projects (that's really the standard) - not really buying it would be a problem here. Also, I havn't been following closely, so if someone hasn't pointed it out yet, fyi on some recommendations: http://www.apache.org/dev/project-names.html - Mark
Re: About name change
I think the first order of business should be to decide whether the name is going to be descriptive or abstract. Exactly what that abstract name or descriptive name is should be the second order of business, I think. Some might disagree, but I don't think the first decision should be predicated on the exact list of name choices for the second decision. Should there be a vote on whether to vote for abstract vs. descriptive or just proceed to vote directly? -- Jack Krupansky -- From: Grant Ingersoll gsing...@apache.org Sent: Monday, August 30, 2010 12:50 PM To: connectors-dev@incubator.apache.org Subject: Re: About name change So, there were some other suggestions on the Incubator list. What do people think of the Open Connector Framework? OCF? (Granted, it is silly to me given it will be the Apache Open Conn. Framework, which still implies it is the Apache one.) Any other suggestions? On Aug 26, 2010, at 9:04 AM, Jack Krupansky wrote: Personally, I'd rather see a traditional, Apache-style name, but I can certainly live with whatever the PMC (?) endorses. I agree with the general@ criticism that the ACF name comes across as being the ultimate end-all connector framework for Apache land (land grab). We should acknowledge that in the future there might be other projects that seek to offer connector frameworks in Apache land. There really should be a handle to qualify the purely descriptive portion of the name - and we had one: Lucene, but it wasn't unique and even there did not acknowledge that in the future there could be other connector frameworks. Note: We effectively have a handle name today: LCF or ACF, but it is a distinctly non-Apache style of name. Why not go with an Apache-style name. That said, I do see that there are a minority of Apache Projects that have descriptive names, including HttpComponents, OpenWebBeans, TrafficServer, Web Services, XML Graphics. Well, there is also HTTP Server as well, but that is an anomaly since it is really just the original Apache itself. Maybe the question is what the current consensus preference is in Apache land and trying to go with the flow rather than try to go against the flow. In short, even if Connectors Framework remains the tail end of the name, a handle prefix is needed. Apache is the general prefix for ALL Apache projects and not a handle for any of them. If that handle is Connecto, the full name could be Connecto Connectors Framework, and the official project name would be Apache Connecto Connectors Framework. That said, I am not a fan of trying to put the project description into the name in raw English form. So, my preference there would be to drop Connectors Framework from the name and stick with Connecto, or whatever other handle is chosen. As I said, I will defer to the PMC (?) endorses, but I would hope that there is some consistency with current and traditional Apache project naming conventions. -- Jack Krupansky -- From: Simon Willnauer simon.willna...@googlemail.com Sent: Thursday, August 26, 2010 7:50 AM To: Grant Ingersoll gsing...@apache.org Cc: connectors-dev@incubator.apache.org Subject: Re: About name change On Thu, Aug 26, 2010 at 12:42 PM, Grant Ingersoll gsing...@apache.org wrote: On Aug 26, 2010, at 6:14 AM, Karl Wright wrote: Is it clear that ACF is dead? The concern raised was that it implied something that connected lots of stuff together, and that's not what it was. But I think that that IS what it is, so the poster knew little or nothing about the project, and was operating from ignorance. Does it make sense to clarify what ACF does to the general list first? I think it is worthwhile. You want to take a crack at it? Absolutely +1 - I just have the impression that people are already biased by Tomcat Connector etc. but I will be a supporter of Apache Connector FW, no doubt. If it is not an option we can still discuss here! simon Karl On Thu, Aug 26, 2010 at 5:26 AM, Simon Willnauer simon.willna...@googlemail.com wrote: Hey folks, I was following the discussion about changing the name to Apache Connector Framework and the late response from people on gene...@. Obviously we need to decide on something else than Apache Connectors Framework since many people had concerns about the name and possible confusion. I have the impression we should first collect some suggestions about alternative names here before we continue discussion on the gene...@. Once we have a name we all agreed on and doesn't apply to the concerns others had we should go back and discuss further. Some folks suggested a more abstract name like Apache Connecto which I personally like (not necessarily Connecto but a more abstract name. Such names have many advantages as people remember short names and they are less ambiguous. Any suggestions, thoughts? simon
Re: About name change
I meant decide the abstract vs. descriptive issue first. Whether we need to decide to vote whether to hold a vote on that or just vote immediately on the abstract vs. descriptive question. Either way is fine with me. I'd prefer to hold off on deciding the exact name until the abstract vs. descriptive issue is resolved. -- Jack Krupansky -- From: Karl Wright daddy...@gmail.com Sent: Monday, August 30, 2010 3:20 PM To: connectors-dev@incubator.apache.org Subject: Re: About name change I think we should vote directly. Perhaps we can save time by supplying our top three choices, in order. Karl On Mon, Aug 30, 2010 at 2:12 PM, Jack Krupansky jack.krupan...@lucidimagination.com wrote: I think the first order of business should be to decide whether the name is going to be descriptive or abstract. Exactly what that abstract name or descriptive name is should be the second order of business, I think. Some might disagree, but I don't think the first decision should be predicated on the exact list of name choices for the second decision. Should there be a vote on whether to vote for abstract vs. descriptive or just proceed to vote directly? -- Jack Krupansky -- From: Grant Ingersoll gsing...@apache.org Sent: Monday, August 30, 2010 12:50 PM To: connectors-dev@incubator.apache.org Subject: Re: About name change So, there were some other suggestions on the Incubator list. What do people think of the Open Connector Framework? OCF? (Granted, it is silly to me given it will be the Apache Open Conn. Framework, which still implies it is the Apache one.) Any other suggestions? On Aug 26, 2010, at 9:04 AM, Jack Krupansky wrote: Personally, I'd rather see a traditional, Apache-style name, but I can certainly live with whatever the PMC (?) endorses. I agree with the general@ criticism that the ACF name comes across as being the ultimate end-all connector framework for Apache land (land grab). We should acknowledge that in the future there might be other projects that seek to offer connector frameworks in Apache land. There really should be a handle to qualify the purely descriptive portion of the name - and we had one: Lucene, but it wasn't unique and even there did not acknowledge that in the future there could be other connector frameworks. Note: We effectively have a handle name today: LCF or ACF, but it is a distinctly non-Apache style of name. Why not go with an Apache-style name. That said, I do see that there are a minority of Apache Projects that have descriptive names, including HttpComponents, OpenWebBeans, TrafficServer, Web Services, XML Graphics. Well, there is also HTTP Server as well, but that is an anomaly since it is really just the original Apache itself. Maybe the question is what the current consensus preference is in Apache land and trying to go with the flow rather than try to go against the flow. In short, even if Connectors Framework remains the tail end of the name, a handle prefix is needed. Apache is the general prefix for ALL Apache projects and not a handle for any of them. If that handle is Connecto, the full name could be Connecto Connectors Framework, and the official project name would be Apache Connecto Connectors Framework. That said, I am not a fan of trying to put the project description into the name in raw English form. So, my preference there would be to drop Connectors Framework from the name and stick with Connecto, or whatever other handle is chosen. As I said, I will defer to the PMC (?) endorses, but I would hope that there is some consistency with current and traditional Apache project naming conventions. -- Jack Krupansky -- From: Simon Willnauer simon.willna...@googlemail.com Sent: Thursday, August 26, 2010 7:50 AM To: Grant Ingersoll gsing...@apache.org Cc: connectors-dev@incubator.apache.org Subject: Re: About name change On Thu, Aug 26, 2010 at 12:42 PM, Grant Ingersoll gsing...@apache.org wrote: On Aug 26, 2010, at 6:14 AM, Karl Wright wrote: Is it clear that ACF is dead? The concern raised was that it implied something that connected lots of stuff together, and that's not what it was. But I think that that IS what it is, so the poster knew little or nothing about the project, and was operating from ignorance. Does it make sense to clarify what ACF does to the general list first? I think it is worthwhile. You want to take a crack at it? Absolutely +1 - I just have the impression that people are already biased by Tomcat Connector etc. but I will be a supporter of Apache Connector FW, no doubt. If it is not an option we can still discuss here! simon Karl On Thu, Aug 26, 2010 at 5:26 AM, Simon Willnauer simon.willna...@googlemail.com wrote: Hey folks, I was following the discussion about changing the name to Apache Connector Framework and
Re: About name change
I know what you meant. For me, anyway, the choices don't slice cleanly along that dimension. e.g., I'd vote for a combination first, a purely descriptive name second, and an abstract name third. FWIW, this would be my vote in order of preference (with the current Apache Connectors Framework implicitly preceding this): Apache Acromantula Connectors Framework Apache CM Connectors Framework Apache Manifold Karl On Mon, Aug 30, 2010 at 3:27 PM, Jack Krupansky jack.krupan...@lucidimagination.com wrote: I meant decide the abstract vs. descriptive issue first. Whether we need to decide to vote whether to hold a vote on that or just vote immediately on the abstract vs. descriptive question. Either way is fine with me. I'd prefer to hold off on deciding the exact name until the abstract vs. descriptive issue is resolved. -- Jack Krupansky -- From: Karl Wright daddy...@gmail.com Sent: Monday, August 30, 2010 3:20 PM To: connectors-dev@incubator.apache.org Subject: Re: About name change I think we should vote directly. Perhaps we can save time by supplying our top three choices, in order. Karl On Mon, Aug 30, 2010 at 2:12 PM, Jack Krupansky jack.krupan...@lucidimagination.com wrote: I think the first order of business should be to decide whether the name is going to be descriptive or abstract. Exactly what that abstract name or descriptive name is should be the second order of business, I think. Some might disagree, but I don't think the first decision should be predicated on the exact list of name choices for the second decision. Should there be a vote on whether to vote for abstract vs. descriptive or just proceed to vote directly? -- Jack Krupansky -- From: Grant Ingersoll gsing...@apache.org Sent: Monday, August 30, 2010 12:50 PM To: connectors-dev@incubator.apache.org Subject: Re: About name change So, there were some other suggestions on the Incubator list. What do people think of the Open Connector Framework? OCF? (Granted, it is silly to me given it will be the Apache Open Conn. Framework, which still implies it is the Apache one.) Any other suggestions? On Aug 26, 2010, at 9:04 AM, Jack Krupansky wrote: Personally, I'd rather see a traditional, Apache-style name, but I can certainly live with whatever the PMC (?) endorses. I agree with the general@ criticism that the ACF name comes across as being the ultimate end-all connector framework for Apache land (land grab). We should acknowledge that in the future there might be other projects that seek to offer connector frameworks in Apache land. There really should be a handle to qualify the purely descriptive portion of the name - and we had one: Lucene, but it wasn't unique and even there did not acknowledge that in the future there could be other connector frameworks. Note: We effectively have a handle name today: LCF or ACF, but it is a distinctly non-Apache style of name. Why not go with an Apache-style name. That said, I do see that there are a minority of Apache Projects that have descriptive names, including HttpComponents, OpenWebBeans, TrafficServer, Web Services, XML Graphics. Well, there is also HTTP Server as well, but that is an anomaly since it is really just the original Apache itself. Maybe the question is what the current consensus preference is in Apache land and trying to go with the flow rather than try to go against the flow. In short, even if Connectors Framework remains the tail end of the name, a handle prefix is needed. Apache is the general prefix for ALL Apache projects and not a handle for any of them. If that handle is Connecto, the full name could be Connecto Connectors Framework, and the official project name would be Apache Connecto Connectors Framework. That said, I am not a fan of trying to put the project description into the name in raw English form. So, my preference there would be to drop Connectors Framework from the name and stick with Connecto, or whatever other handle is chosen. As I said, I will defer to the PMC (?) endorses, but I would hope that there is some consistency with current and traditional Apache project naming conventions. -- Jack Krupansky -- From: Simon Willnauer simon.willna...@googlemail.com Sent: Thursday, August 26, 2010 7:50 AM To: Grant Ingersoll gsing...@apache.org Cc: connectors-dev@incubator.apache.org Subject: Re: About name change On Thu, Aug 26, 2010 at 12:42 PM, Grant Ingersoll gsing...@apache.org wrote: On Aug 26, 2010, at 6:14 AM, Karl Wright wrote: Is it clear that ACF is dead? The concern raised was that it implied something that connected lots of stuff together, and that's not what it was. But I think that that IS what it is, so the poster knew little or nothing about the project, and was
[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=12904324#action_12904324 ] Karl Wright commented on CONNECTORS-92: --- Another way you can determine what's supposed to be a dependency is to look at the start.jar produced by the ant build: attribute name=Class-Path value=lib/commons-codec.jar lib/commons-collections.jar lib/commons-el.jar lib/commons-fileupload.jar lib/commons-httpclient-acf.jar lib/commons-io.jar lib/commons-logging.jar lib/derbyclient.jar lib/derby.jar lib/derbyLocale_cs.jar lib/derbyLocale_de_DE.jar lib/derbyLocale_es.jar lib/derbyLocale_fr.jar lib/derbyLocale_hu.jar lib/derbyLocale_it.jar lib/derbyLocale_ja_JP.jar lib/derbyLocale_ko_KR.jar lib/derbyLocale_pl.jar lib/derbyLocale_pt_BR.jar lib/derbyLocale_ru.jar lib/derbyLocale_zh_CN.jar lib/derbyLocale_zh_TW.jar lib/derbynet.jar lib/derbyrun.jar lib/derbytools.jar lib/eclipse-ecj.jar lib/jasper-6.0.24.jar lib/jasper-el-6.0.24.jar lib/jdbcpool-0.99.jar lib/jetty-6.1.22.jar lib/jetty-util-6.1.22.jar lib/jsp-api-2.1-glassfish-9.1.1.B60.25.p2.jar lib/json.jar lib/acf-agents.jar lib/acf-core.jar lib/acf-jetty-runner.jar lib/acf-pull-agent.jar lib/acf-ui-core.jar lib/log4j-1.2.jar lib/postgresql.jar lib/serializer.jar lib/servlet-api-2.5-20081211.jar lib/tomcat-juli-6.0.24.jar lib/xalan2.jar lib/xercesImpl-lcf.jar lib/xml-apis.jar/ Note that commons-httpclient-acf.jar is our own version of commons-httpclient, and must therefore NOT be an external dependency. 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, move-to-maven-acf-framework.patch, 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: About name change
On 8/30/10 1:37 PM, Karl Wright wrote: snip - Consider using functional names, especially for products of existing projects, e.g. for an Apache Foo project, the product name Apache Foo Pipelines. -snip Granted, Lucene Connectors Framework fills this to a T, but this would imply that functional names are OK for top-level projects too. FYI, these are listed as guidelines, so I don't think they are meant to determine what is OK or not. A guideline is by definition not mandatory. It would seem to me that the reason this is emphasized for subprojects of foo even more so than foo, is that foo will already be a unique simple abstract name. After you have that, it's best to be descriptive for sub projects. If you don't have a unique simple abstract 'component' of the name for a top level project, many of the other guidelines are not met very well. Below are some current Apache project names - you start to see a pattern - notice that most of them will be the top hit on google using simply the name (yes, including ant, tiles and felix surprisingly ;) ). This isn't always the case of course - many different historical issues factor into these names - but as you can see - even just more than one word for the name is extremely uncommon. HTTP Server Abdera ActiveMQ Ant APR Archiva Avro Buildr Camel Cassandra Cayenne Click Cocoon Commons Continuum CouchDB CXF DB Directory Excalibur Felix Forrest Geronimo Gump Hadoop Harmony HBase HttpComponents Jackrabbit Jakarta James Lenya Logging Lucene Mahout Maven Mina MyFaces Nutch ODE OFBiz OpenEJB OpenJPA OpenWebBeans PDFBox Perl Pivot POI Portals Qpid Roller Santuario ServiceMix Shindig Sling SpamAssassin STDCXX Struts Subversion Synapse Tapestry Tika TCL Tiles Tomcat TrafficServer Turbine Tuscany UIMA Velocity Wicket Web Services Xalan Xerces XML XMLBeans XML Graphics Karl On Mon, Aug 30, 2010 at 1:24 PM, Mark Miller markrmil...@gmail.com wrote: On 8/30/10 1:05 PM, Karl Wright wrote: I'm not too keen on just a simple abstract name - too meaningless for me. It works for countless Apache projects (that's really the standard) - not really buying it would be a problem here. Also, I havn't been following closely, so if someone hasn't pointed it out yet, fyi on some recommendations: http://www.apache.org/dev/project-names.html - Mark
Re: About name change
TrafficServer? OpenWebBeans? XMLBeans? There are actually a *lot* of names that are multiple words. They're just mashed together. ;-) Karl On Mon, Aug 30, 2010 at 4:44 PM, Mark Miller markrmil...@gmail.com wrote: On 8/30/10 1:37 PM, Karl Wright wrote: snip - Consider using functional names, especially for products of existing projects, e.g. for an Apache Foo project, the product name Apache Foo Pipelines. -snip Granted, Lucene Connectors Framework fills this to a T, but this would imply that functional names are OK for top-level projects too. FYI, these are listed as guidelines, so I don't think they are meant to determine what is OK or not. A guideline is by definition not mandatory. It would seem to me that the reason this is emphasized for subprojects of foo even more so than foo, is that foo will already be a unique simple abstract name. After you have that, it's best to be descriptive for sub projects. If you don't have a unique simple abstract 'component' of the name for a top level project, many of the other guidelines are not met very well. Below are some current Apache project names - you start to see a pattern - notice that most of them will be the top hit on google using simply the name (yes, including ant, tiles and felix surprisingly ;) ). This isn't always the case of course - many different historical issues factor into these names - but as you can see - even just more than one word for the name is extremely uncommon. HTTP Server Abdera ActiveMQ Ant APR Archiva Avro Buildr Camel Cassandra Cayenne Click Cocoon Commons Continuum CouchDB CXF DB Directory Excalibur Felix Forrest Geronimo Gump Hadoop Harmony HBase HttpComponents Jackrabbit Jakarta James Lenya Logging Lucene Mahout Maven Mina MyFaces Nutch ODE OFBiz OpenEJB OpenJPA OpenWebBeans PDFBox Perl Pivot POI Portals Qpid Roller Santuario ServiceMix Shindig Sling SpamAssassin STDCXX Struts Subversion Synapse Tapestry Tika TCL Tiles Tomcat TrafficServer Turbine Tuscany UIMA Velocity Wicket Web Services Xalan Xerces XML XMLBeans XML Graphics Karl On Mon, Aug 30, 2010 at 1:24 PM, Mark Miller markrmil...@gmail.com wrote: On 8/30/10 1:05 PM, Karl Wright wrote: I'm not too keen on just a simple abstract name - too meaningless for me. It works for countless Apache projects (that's really the standard) - not really buying it would be a problem here. Also, I havn't been following closely, so if someone hasn't pointed it out yet, fyi on some recommendations: http://www.apache.org/dev/project-names.html - Mark
Re: About name change
I'm not going to go head-to-head with you trying to split hairs. ;-) Can we agree that something like ContentCF is a possibility under your guidelines? (I'm not proposing that, I'm just trying to open the field up a bit.) Karl On Mon, Aug 30, 2010 at 5:14 PM, Mark Miller markrmil...@gmail.com wrote: Heh - only with an extremely liberal definition of multiword. The list really speaks for itself here. (I'm not including commons or jakarta in this, because they are multiple projects) They are each a single top level project with many sub projects. On 8/30/10 5:06 PM, Karl Wright wrote: Ok, let's do a count. Single word: 49 Multiword: 26 (I'm not including commons or jakarta in this, because they are multiple projects) Karl On Mon, Aug 30, 2010 at 4:59 PM, Mark Miller markrmil...@gmail.com wrote: Right - mashed together into one word - not multiple words. And if you look, it's not even a 'lot' without the bold around it ;) On 8/30/10 4:50 PM, Karl Wright wrote: TrafficServer? OpenWebBeans? XMLBeans? There are actually a *lot* of names that are multiple words. They're just mashed together. ;-) Karl On Mon, Aug 30, 2010 at 4:44 PM, Mark Miller markrmil...@gmail.com wrote: On 8/30/10 1:37 PM, Karl Wright wrote: snip - Consider using functional names, especially for products of existing projects, e.g. for an Apache Foo project, the product name Apache Foo Pipelines. -snip Granted, Lucene Connectors Framework fills this to a T, but this would imply that functional names are OK for top-level projects too. FYI, these are listed as guidelines, so I don't think they are meant to determine what is OK or not. A guideline is by definition not mandatory. It would seem to me that the reason this is emphasized for subprojects of foo even more so than foo, is that foo will already be a unique simple abstract name. After you have that, it's best to be descriptive for sub projects. If you don't have a unique simple abstract 'component' of the name for a top level project, many of the other guidelines are not met very well. Below are some current Apache project names - you start to see a pattern - notice that most of them will be the top hit on google using simply the name (yes, including ant, tiles and felix surprisingly ;) ). This isn't always the case of course - many different historical issues factor into these names - but as you can see - even just more than one word for the name is extremely uncommon. HTTP Server Abdera ActiveMQ Ant APR Archiva Avro Buildr Camel Cassandra Cayenne Click Cocoon Commons Continuum CouchDB CXF DB Directory Excalibur Felix Forrest Geronimo Gump Hadoop Harmony HBase HttpComponents Jackrabbit Jakarta James Lenya Logging Lucene Mahout Maven Mina MyFaces Nutch ODE OFBiz OpenEJB OpenJPA OpenWebBeans PDFBox Perl Pivot POI Portals Qpid Roller Santuario ServiceMix Shindig Sling SpamAssassin STDCXX Struts Subversion Synapse Tapestry Tika TCL Tiles Tomcat TrafficServer Turbine Tuscany UIMA Velocity Wicket Web Services Xalan Xerces XML XMLBeans XML Graphics Karl On Mon, Aug 30, 2010 at 1:24 PM, Mark Miller markrmil...@gmail.com wrote: On 8/30/10 1:05 PM, Karl Wright wrote: I'm not too keen on just a simple abstract name - too meaningless for me. It works for countless Apache projects (that's really the standard) - not really buying it would be a problem here. Also, I havn't been following closely, so if someone hasn't pointed it out yet, fyi on some recommendations: http://www.apache.org/dev/project-names.html - Mark
Re: About name change
I suspect those multi-word names kind of sneaked in without the naming police having a chance to point out the naming guidelines early in the project process. For the record, I am okay with XYZ Open Connectors Framework or XYZ Content Connectors Framework or XYZ Connectors Framework as the full name, with XYZ as the official Apache name (or handle as I call it), where XYZ is a placeholder for a name as yet to be determined. And Apache gets stuck on the front of the name, by convention. -- Jack Krupansky -- From: Karl Wright daddy...@gmail.com Sent: Monday, August 30, 2010 4:50 PM To: connectors-dev@incubator.apache.org Subject: Re: About name change TrafficServer? OpenWebBeans? XMLBeans? There are actually a *lot* of names that are multiple words. They're just mashed together. ;-) Karl On Mon, Aug 30, 2010 at 4:44 PM, Mark Miller markrmil...@gmail.com wrote: On 8/30/10 1:37 PM, Karl Wright wrote: snip - Consider using functional names, especially for products of existing projects, e.g. for an Apache Foo project, the product name Apache Foo Pipelines. -snip Granted, Lucene Connectors Framework fills this to a T, but this would imply that functional names are OK for top-level projects too. FYI, these are listed as guidelines, so I don't think they are meant to determine what is OK or not. A guideline is by definition not mandatory. It would seem to me that the reason this is emphasized for subprojects of foo even more so than foo, is that foo will already be a unique simple abstract name. After you have that, it's best to be descriptive for sub projects. If you don't have a unique simple abstract 'component' of the name for a top level project, many of the other guidelines are not met very well. Below are some current Apache project names - you start to see a pattern - notice that most of them will be the top hit on google using simply the name (yes, including ant, tiles and felix surprisingly ;) ). This isn't always the case of course - many different historical issues factor into these names - but as you can see - even just more than one word for the name is extremely uncommon. HTTP Server Abdera ActiveMQ Ant APR Archiva Avro Buildr Camel Cassandra Cayenne Click Cocoon Commons Continuum CouchDB CXF DB Directory Excalibur Felix Forrest Geronimo Gump Hadoop Harmony HBase HttpComponents Jackrabbit Jakarta James Lenya Logging Lucene Mahout Maven Mina MyFaces Nutch ODE OFBiz OpenEJB OpenJPA OpenWebBeans PDFBox Perl Pivot POI Portals Qpid Roller Santuario ServiceMix Shindig Sling SpamAssassin STDCXX Struts Subversion Synapse Tapestry Tika TCL Tiles Tomcat TrafficServer Turbine Tuscany UIMA Velocity Wicket Web Services Xalan Xerces XML XMLBeans XML Graphics Karl On Mon, Aug 30, 2010 at 1:24 PM, Mark Miller markrmil...@gmail.com wrote: On 8/30/10 1:05 PM, Karl Wright wrote: I'm not too keen on just a simple abstract name - too meaningless for me. It works for countless Apache projects (that's really the standard) - not really buying it would be a problem here. Also, I havn't been following closely, so if someone hasn't pointed it out yet, fyi on some recommendations: http://www.apache.org/dev/project-names.html - Mark
Re: About name change
Why not just stick with Apache Connector Framework? After all, that is exactly what this is... a connector framework. It has a short and simple acronym, ACF, and best of all requires no additional effort, no refactoring, no website updates, etc! Just my $0.02, not that it really matters -- Thanks, Matt Weber 2:20 PM, Karl Wright daddy...@gmail.com wrote: I'm not going to go head-to-head with you trying to split hairs. ;-) Can we agree that something like ContentCF is a possibility under your guidelines? (I'm not proposing that, I'm just trying to open the field up a bit.) Karl On Mon, Aug 30, 2010 at 5:14 PM, Mark Miller markrmil...@gmail.com wrote: Heh - only with an extremely liberal definition of multiword. The list really speaks for itself here. (I'm not including commons or jakarta in this, because they are multiple projects) They are each a single top level project with many sub projects. On 8/30/10 5:06 PM, Karl Wright wrote: Ok, let's do a count. Single word: 49 Multiword: 26 (I'm not including commons or jakarta in this, because they are multiple projects) Karl On Mon, Aug 30, 2010 at 4:59 PM, Mark Miller markrmil...@gmail.com wrote: Right - mashed together into one word - not multiple words. And if you look, it's not even a 'lot' without the bold around it ;) On 8/30/10 4:50 PM, Karl Wright wrote: TrafficServer? OpenWebBeans? XMLBeans? There are actually a *lot* of names that are multiple words. They're just mashed together. ;-) Karl On Mon, Aug 30, 2010 at 4:44 PM, Mark Miller markrmil...@gmail.com wrote: On 8/30/10 1:37 PM, Karl Wright wrote: snip - Consider using functional names, especially for products of existing projects, e.g. for an Apache Foo project, the product name Apache Foo Pipelines. -snip Granted, Lucene Connectors Framework fills this to a T, but this would imply that functional names are OK for top-level projects too. FYI, these are listed as guidelines, so I don't think they are meant to determine what is OK or not. A guideline is by definition not mandatory. It would seem to me that the reason this is emphasized for subprojects of foo even more so than foo, is that foo will already be a unique simple abstract name. After you have that, it's best to be descriptive for sub projects. If you don't have a unique simple abstract 'component' of the name for a top level project, many of the other guidelines are not met very well. Below are some current Apache project names - you start to see a pattern - notice that most of them will be the top hit on google using simply the name (yes, including ant, tiles and felix surprisingly ;) ). This isn't always the case of course - many different historical issues factor into these names - but as you can see - even just more than one word for the name is extremely uncommon. HTTP Server Abdera ActiveMQ Ant APR Archiva Avro Buildr Camel Cassandra Cayenne Click Cocoon Commons Continuum CouchDB CXF DB Directory Excalibur Felix Forrest Geronimo Gump Hadoop Harmony HBase HttpComponents Jackrabbit Jakarta James Lenya Logging Lucene Mahout Maven Mina MyFaces Nutch ODE OFBiz OpenEJB OpenJPA OpenWebBeans PDFBox Perl Pivot POI Portals Qpid Roller Santuario ServiceMix Shindig Sling SpamAssassin STDCXX Struts Subversion Synapse Tapestry Tika TCL Tiles Tomcat TrafficServer Turbine Tuscany UIMA Velocity Wicket Web Services Xalan Xerces XML XMLBeans XML Graphics Karl On Mon, Aug 30, 2010 at 1:24 PM, Mark Miller markrmil...@gmail.com wrote: On 8/30/10 1:05 PM, Karl Wright wrote: I'm not too keen on just a simple abstract name - too meaningless for me. It works for countless Apache projects (that's really the standard) - not really buying it would be a problem here. Also, I havn't been following closely, so if someone hasn't pointed it out yet, fyi on some recommendations: http://www.apache.org/dev/project-names.html - Mark -- Thanks, Matt Weber
Re: About name change
On 8/30/10 5:20 PM, Karl Wright wrote: I'm not going to go head-to-head with you trying to split hairs. ;-) Can we agree that something like ContentCF is a possibility under your guidelines? (I'm not proposing that, I'm just trying to open the field up a bit.) Karl From my end, most of that was off topic haggling - I'm not saying it should be one way or other per seh. I personally see the benefit of having a good unique word in the name of the project - and of trying to follow the guidelines / feel of previous projects. I'd be perfectly fine with something like Apache Manifold Connector Framework. But push come to shove I wouldn't even vote against keeping things as is with the Apache Connector Framework. - Mark
