[jira] [Commented] (CONNECTORS-258) pom.xml refers to jars not available in public repositories
[ https://issues.apache.org/jira/browse/CONNECTORS-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109431#comment-13109431 ] Karl Wright commented on CONNECTORS-258: bq. Regarding modified versions of xerces and httpclient - do patches MCF-specific, or they are already submitted to upstream? If already submitted, then we can use SNAPSHOT versions of them, taking them from Apache repository The patches are not mcf specific, but we've had only limited success getting them into upstream code. I've actually lost track of all of the issues now. I know that commons-httpclient 4.1 included our NTLM patches but no idea if the other issues still remain. Plus there would be work involved moving to 4.x from 3.x which there's a ticket for but nobody has had the time for (nor the testing platforms). The xerces patches were more limited but all of them were submitted and only some of them were accepted - and that was about a year after I submitted the patch. > pom.xml refers to jars not available in public repositories > --- > > Key: CONNECTORS-258 > URL: https://issues.apache.org/jira/browse/CONNECTORS-258 > Project: ManifoldCF > Issue Type: Bug > Components: Build >Affects Versions: ManifoldCF 0.4 > Environment: all supported platforms >Reporter: Alex Ott >Priority: Minor > Labels: maven > Attachments: mvn-bootstrap.sh > > > Maven's pom.xmls refers to jars that aren't available in public repositories, > as maven central, apache repository, etc. This includes: > - com.bitmechanic:jdbcpool > - org.hsqldb:hsqldb:jar:2.2.5.6-9-2011 (at maven central only version 2.2.4 > is available right now) > I think, that ManifoldCF should adopt the same approach as other Apache > projects, like Tika, when all needed jars first promoted to public > repositories, and only after that, they are used as dependency... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-258) pom.xml refers to jars not available in public repositories
[ https://issues.apache.org/jira/browse/CONNECTORS-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109430#comment-13109430 ] Karl Wright commented on CONNECTORS-258: r1173584 Committed script for setting up maven build, in both .sh and .bat forms. > pom.xml refers to jars not available in public repositories > --- > > Key: CONNECTORS-258 > URL: https://issues.apache.org/jira/browse/CONNECTORS-258 > Project: ManifoldCF > Issue Type: Bug > Components: Build >Affects Versions: ManifoldCF 0.4 > Environment: all supported platforms >Reporter: Alex Ott >Priority: Minor > Labels: maven > Attachments: mvn-bootstrap.sh > > > Maven's pom.xmls refers to jars that aren't available in public repositories, > as maven central, apache repository, etc. This includes: > - com.bitmechanic:jdbcpool > - org.hsqldb:hsqldb:jar:2.2.5.6-9-2011 (at maven central only version 2.2.4 > is available right now) > I think, that ManifoldCF should adopt the same approach as other Apache > projects, like Tika, when all needed jars first promoted to public > repositories, and only after that, they are used as dependency... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-261) Maven build needs to be conditionalized in order to handle proprietary connectors
[ https://issues.apache.org/jira/browse/CONNECTORS-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109422#comment-13109422 ] Karl Wright commented on CONNECTORS-261: Alex Ott says: "I think, that problem with conditional dependencies/compilation could be solved using "Maven profiles", so user could use them when working with code" > Maven build needs to be conditionalized in order to handle proprietary > connectors > - > > Key: CONNECTORS-261 > URL: https://issues.apache.org/jira/browse/CONNECTORS-261 > Project: ManifoldCF > Issue Type: Improvement > Components: Build >Affects Versions: ManifoldCF 0.4 >Reporter: Karl Wright > > The maven build currently does not handle proprietary connectors, but should. > This involves figuring out how to conditionalize it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Long running tests
There's no rush - next release isn't until December. ;-) Seriously, any and all contributions and ideas are very very welcome. Karl On Wed, Sep 21, 2011 at 7:48 AM, Alex Ott wrote: > I'll try to refactor poms to use failsafe plugin, but I don't expect > that I'll have time until weekend > > On Wed, Sep 21, 2011 at 12:41 PM, Karl Wright wrote: >> I've created a ticket (CONNECTORS-263) for this work. Anybody who >> wants to submit a patch would be very welcome... >> >> Karl >> >> >> On Wed, Sep 21, 2011 at 6:04 AM, Alex Ott wrote: >>> Hello >>> >>> We can put following script (in attachment) to simplify setup of >>> missing maven dependencies that are fetched using 'ant >>> download-dependencies' command. After using this script I was able to >>> build everything using maven. >>> >>> One more comment is on tests - maybe it's better to put long-running >>> tests, like filesystem tests, etc. into integration-test build stage >>> (https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html)? >>> Maven Failsafe plugin >>> (https://maven.apache.org/plugins/maven-failsafe-plugin/usage.html) >>> provides useful functionality to implement this. I think, that this >>> could make developer's life easier >>> >>> On Wed, Sep 21, 2011 at 9:52 AM, Alex Ott wrote: Hello On Wed, Sep 21, 2011 at 9:43 AM, Tommaso Teofili wrote: >> (2) I'm not sure it is reasonable to go with one build system over >> another. Lucene/Solr has been having this battle for years. I >> thought we might just learn from that experience and try to be more >> flexible. There are excellent technical reasons to have each - for >> instance, building Debian packages works much better with Ant, and >> Eclipse works much better with Maven. >> > > I don't like "wars" as well about which one *is* better, maybe it's just a > matter of use case and personal preferences. > However I like what you say about trying to be more flexible so I am +1 to > your position. > I have some experience with Maven so let me know if you need my help in > tweaking that part of the build. I also have some experience with Maven, and I'm interested in MCF's development, so I can try to fix some problems. The first thing, that should be achieved - building with Maven out of box, without manual work (or at least with minimum of it). -- With best wishes, Alex Ott http://alexott.net/ Tiwtter: alexott_en (English), alexott (Russian) Skype: alex.ott >>> >>> >>> >>> -- >>> With best wishes, Alex Ott >>> http://alexott.net/ >>> Tiwtter: alexott_en (English), alexott (Russian) >>> Skype: alex.ott >>> >> > > > > -- > With best wishes, Alex Ott > http://alexott.net/ > Tiwtter: alexott_en (English), alexott (Russian) > Skype: alex.ott >
Re: Long running tests
I'll try to refactor poms to use failsafe plugin, but I don't expect that I'll have time until weekend On Wed, Sep 21, 2011 at 12:41 PM, Karl Wright wrote: > I've created a ticket (CONNECTORS-263) for this work. Anybody who > wants to submit a patch would be very welcome... > > Karl > > > On Wed, Sep 21, 2011 at 6:04 AM, Alex Ott wrote: >> Hello >> >> We can put following script (in attachment) to simplify setup of >> missing maven dependencies that are fetched using 'ant >> download-dependencies' command. After using this script I was able to >> build everything using maven. >> >> One more comment is on tests - maybe it's better to put long-running >> tests, like filesystem tests, etc. into integration-test build stage >> (https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html)? >> Maven Failsafe plugin >> (https://maven.apache.org/plugins/maven-failsafe-plugin/usage.html) >> provides useful functionality to implement this. I think, that this >> could make developer's life easier >> >> On Wed, Sep 21, 2011 at 9:52 AM, Alex Ott wrote: >>> Hello >>> >>> On Wed, Sep 21, 2011 at 9:43 AM, Tommaso Teofili >>> wrote: > (2) I'm not sure it is reasonable to go with one build system over > another. Lucene/Solr has been having this battle for years. I > thought we might just learn from that experience and try to be more > flexible. There are excellent technical reasons to have each - for > instance, building Debian packages works much better with Ant, and > Eclipse works much better with Maven. > I don't like "wars" as well about which one *is* better, maybe it's just a matter of use case and personal preferences. However I like what you say about trying to be more flexible so I am +1 to your position. I have some experience with Maven so let me know if you need my help in tweaking that part of the build. >>> >>> I also have some experience with Maven, and I'm interested in MCF's >>> development, so I can try to fix some problems. The first thing, that >>> should be achieved - building with Maven out of box, without manual >>> work (or at least with minimum of it). >>> >>> -- >>> With best wishes, Alex Ott >>> http://alexott.net/ >>> Tiwtter: alexott_en (English), alexott (Russian) >>> Skype: alex.ott >>> >> >> >> >> -- >> With best wishes, Alex Ott >> http://alexott.net/ >> Tiwtter: alexott_en (English), alexott (Russian) >> Skype: alex.ott >> > -- With best wishes, Alex Ott http://alexott.net/ Tiwtter: alexott_en (English), alexott (Russian) Skype: alex.ott
RE: Maven build
I created a ticket for this too - connectors-261. Afaik, documentum dfc remains under a proprietary license and may not be redistributed. i don't know about livelink lapi but if you have a link please share it. Karl -Original Message- From: ext Alex Ott Sent: 21/09/2011, 6:30 AM To: connectors-dev@incubator.apache.org Subject: Re: Maven build I think, that problem with conditional dependencies/compilation could be solved using "Maven profiles", so user could use them when working with code P.S. License for Livelink & Documentum allows their inclusion into open source projects, so their could be distributed? On Wed, Sep 21, 2011 at 12:20 PM, Karl Wright wrote: > Part of the problem, for me, is learning what the issues are with > Maven that maven developers will find problematic. > > One of the problems we're going to have is that the Maven central > repository simply cannot provide the proprietary building materials > for the connectors that need them, for instance Livelink and > Documentum. These materials will always need to be pushed into a > local repository, and it is also true that conditional compilation > will also always be required, since any one builder will not have > access to all proprietary libraries. Anyone have a good Maven > solution to that? > > Karl > > On Wed, Sep 21, 2011 at 3:52 AM, Alex Ott wrote: >> Hello >> >> On Wed, Sep 21, 2011 at 9:43 AM, Tommaso Teofili >> wrote: (2) I'm not sure it is reasonable to go with one build system over another. Lucene/Solr has been having this battle for years. I thought we might just learn from that experience and try to be more flexible. There are excellent technical reasons to have each - for instance, building Debian packages works much better with Ant, and Eclipse works much better with Maven. >>> >>> I don't like "wars" as well about which one *is* better, maybe it's just a >>> matter of use case and personal preferences. >>> However I like what you say about trying to be more flexible so I am +1 to >>> your position. >>> I have some experience with Maven so let me know if you need my help in >>> tweaking that part of the build. >> >> I also have some experience with Maven, and I'm interested in MCF's >> development, so I can try to fix some problems. The first thing, that >> should be achieved - building with Maven out of box, without manual >> work (or at least with minimum of it). >> >> -- >> With best wishes,Alex Ott >> http://alexott.net/ >> Tiwtter: alexott_en (English), alexott (Russian) >> Skype: alex.ott >> > -- With best wishes,Alex Ott http://alexott.net/ Tiwtter: alexott_en (English), alexott (Russian) Skype: alex.ott
[jira] [Created] (CONNECTORS-263) Long-running tests should all be moved to Maven's integration-test phase
Long-running tests should all be moved to Maven's integration-test phase Key: CONNECTORS-263 URL: https://issues.apache.org/jira/browse/CONNECTORS-263 Project: ManifoldCF Issue Type: Improvement Components: Build Affects Versions: ManifoldCF 0.4 Reporter: Karl Wright Fix For: ManifoldCF 0.4 Long-running tests should be moved to Maven's integration-test phase. (which are all in root-level "tests" directory) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Long running tests
I've created a ticket (CONNECTORS-263) for this work. Anybody who wants to submit a patch would be very welcome... Karl On Wed, Sep 21, 2011 at 6:04 AM, Alex Ott wrote: > Hello > > We can put following script (in attachment) to simplify setup of > missing maven dependencies that are fetched using 'ant > download-dependencies' command. After using this script I was able to > build everything using maven. > > One more comment is on tests - maybe it's better to put long-running > tests, like filesystem tests, etc. into integration-test build stage > (https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html)? > Maven Failsafe plugin > (https://maven.apache.org/plugins/maven-failsafe-plugin/usage.html) > provides useful functionality to implement this. I think, that this > could make developer's life easier > > On Wed, Sep 21, 2011 at 9:52 AM, Alex Ott wrote: >> Hello >> >> On Wed, Sep 21, 2011 at 9:43 AM, Tommaso Teofili >> wrote: (2) I'm not sure it is reasonable to go with one build system over another. Lucene/Solr has been having this battle for years. I thought we might just learn from that experience and try to be more flexible. There are excellent technical reasons to have each - for instance, building Debian packages works much better with Ant, and Eclipse works much better with Maven. >>> >>> I don't like "wars" as well about which one *is* better, maybe it's just a >>> matter of use case and personal preferences. >>> However I like what you say about trying to be more flexible so I am +1 to >>> your position. >>> I have some experience with Maven so let me know if you need my help in >>> tweaking that part of the build. >> >> I also have some experience with Maven, and I'm interested in MCF's >> development, so I can try to fix some problems. The first thing, that >> should be achieved - building with Maven out of box, without manual >> work (or at least with minimum of it). >> >> -- >> With best wishes, Alex Ott >> http://alexott.net/ >> Tiwtter: alexott_en (English), alexott (Russian) >> Skype: alex.ott >> > > > > -- > With best wishes, Alex Ott > http://alexott.net/ > Tiwtter: alexott_en (English), alexott (Russian) > Skype: alex.ott >
Re: Maven build
I think, that problem with conditional dependencies/compilation could be solved using "Maven profiles", so user could use them when working with code P.S. License for Livelink & Documentum allows their inclusion into open source projects, so their could be distributed? On Wed, Sep 21, 2011 at 12:20 PM, Karl Wright wrote: > Part of the problem, for me, is learning what the issues are with > Maven that maven developers will find problematic. > > One of the problems we're going to have is that the Maven central > repository simply cannot provide the proprietary building materials > for the connectors that need them, for instance Livelink and > Documentum. These materials will always need to be pushed into a > local repository, and it is also true that conditional compilation > will also always be required, since any one builder will not have > access to all proprietary libraries. Anyone have a good Maven > solution to that? > > Karl > > On Wed, Sep 21, 2011 at 3:52 AM, Alex Ott wrote: >> Hello >> >> On Wed, Sep 21, 2011 at 9:43 AM, Tommaso Teofili >> wrote: (2) I'm not sure it is reasonable to go with one build system over another. Lucene/Solr has been having this battle for years. I thought we might just learn from that experience and try to be more flexible. There are excellent technical reasons to have each - for instance, building Debian packages works much better with Ant, and Eclipse works much better with Maven. >>> >>> I don't like "wars" as well about which one *is* better, maybe it's just a >>> matter of use case and personal preferences. >>> However I like what you say about trying to be more flexible so I am +1 to >>> your position. >>> I have some experience with Maven so let me know if you need my help in >>> tweaking that part of the build. >> >> I also have some experience with Maven, and I'm interested in MCF's >> development, so I can try to fix some problems. The first thing, that >> should be achieved - building with Maven out of box, without manual >> work (or at least with minimum of it). >> >> -- >> With best wishes, Alex Ott >> http://alexott.net/ >> Tiwtter: alexott_en (English), alexott (Russian) >> Skype: alex.ott >> > -- With best wishes, Alex Ott http://alexott.net/ Tiwtter: alexott_en (English), alexott (Russian) Skype: alex.ott
[jira] [Created] (CONNECTORS-262) Ant build could download WSDL's for SharePoint, if the public Microsoft SharePoint site has them
Ant build could download WSDL's for SharePoint, if the public Microsoft SharePoint site has them Key: CONNECTORS-262 URL: https://issues.apache.org/jira/browse/CONNECTORS-262 Project: ManifoldCF Issue Type: Improvement Components: Build, SharePoint connector Affects Versions: ManifoldCF 0.4 Reporter: Karl Wright Assignee: Shinichiro Abe Fix For: ManifoldCF 0.4 There is a public Microsoft SharePoint site. If we can get at it, we might be able to download the Microsoft WSDL's we need from it automatically during the "download-dependencies" target. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CONNECTORS-261) Maven build needs to be conditionalized in order to handle proprietary connectors
Maven build needs to be conditionalized in order to handle proprietary connectors - Key: CONNECTORS-261 URL: https://issues.apache.org/jira/browse/CONNECTORS-261 Project: ManifoldCF Issue Type: Improvement Components: Build Affects Versions: ManifoldCF 0.4 Reporter: Karl Wright The maven build currently does not handle proprietary connectors, but should. This involves figuring out how to conditionalize it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONNECTORS-258) pom.xml refers to jars not available in public repositories
[ https://issues.apache.org/jira/browse/CONNECTORS-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Ott updated CONNECTORS-258: Attachment: mvn-bootstrap.sh Script to prepare clean system for maven build > pom.xml refers to jars not available in public repositories > --- > > Key: CONNECTORS-258 > URL: https://issues.apache.org/jira/browse/CONNECTORS-258 > Project: ManifoldCF > Issue Type: Bug > Components: Build >Affects Versions: ManifoldCF 0.4 > Environment: all supported platforms >Reporter: Alex Ott >Priority: Minor > Labels: maven > Attachments: mvn-bootstrap.sh > > > Maven's pom.xmls refers to jars that aren't available in public repositories, > as maven central, apache repository, etc. This includes: > - com.bitmechanic:jdbcpool > - org.hsqldb:hsqldb:jar:2.2.5.6-9-2011 (at maven central only version 2.2.4 > is available right now) > I think, that ManifoldCF should adopt the same approach as other Apache > projects, like Tika, when all needed jars first promoted to public > repositories, and only after that, they are used as dependency... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Maven setup script
done On Wed, Sep 21, 2011 at 12:16 PM, Karl Wright wrote: > Hi Alex, > > Can you attach this to the CONNECTORS-258 ticket? Be sure to click > the "grant license to ASF" button when you do... > > Thanks! > Karl > > On Wed, Sep 21, 2011 at 6:04 AM, Alex Ott wrote: >> Hello >> >> We can put following script (in attachment) to simplify setup of >> missing maven dependencies that are fetched using 'ant >> download-dependencies' command. After using this script I was able to >> build everything using maven. >> >> One more comment is on tests - maybe it's better to put long-running >> tests, like filesystem tests, etc. into integration-test build stage >> (https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html)? >> Maven Failsafe plugin >> (https://maven.apache.org/plugins/maven-failsafe-plugin/usage.html) >> provides useful functionality to implement this. I think, that this >> could make developer's life easier >> >> On Wed, Sep 21, 2011 at 9:52 AM, Alex Ott wrote: >>> Hello >>> >>> On Wed, Sep 21, 2011 at 9:43 AM, Tommaso Teofili >>> wrote: > (2) I'm not sure it is reasonable to go with one build system over > another. Lucene/Solr has been having this battle for years. I > thought we might just learn from that experience and try to be more > flexible. There are excellent technical reasons to have each - for > instance, building Debian packages works much better with Ant, and > Eclipse works much better with Maven. > I don't like "wars" as well about which one *is* better, maybe it's just a matter of use case and personal preferences. However I like what you say about trying to be more flexible so I am +1 to your position. I have some experience with Maven so let me know if you need my help in tweaking that part of the build. >>> >>> I also have some experience with Maven, and I'm interested in MCF's >>> development, so I can try to fix some problems. The first thing, that >>> should be achieved - building with Maven out of box, without manual >>> work (or at least with minimum of it). >>> >>> -- >>> With best wishes, Alex Ott >>> http://alexott.net/ >>> Tiwtter: alexott_en (English), alexott (Russian) >>> Skype: alex.ott >>> >> >> >> >> -- >> With best wishes, Alex Ott >> http://alexott.net/ >> Tiwtter: alexott_en (English), alexott (Russian) >> Skype: alex.ott >> > -- With best wishes, Alex Ott http://alexott.net/ Tiwtter: alexott_en (English), alexott (Russian) Skype: alex.ott
[jira] [Issue Comment Edited] (CONNECTORS-258) pom.xml refers to jars not available in public repositories
[ https://issues.apache.org/jira/browse/CONNECTORS-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109390#comment-13109390 ] Alex Ott edited comment on CONNECTORS-258 at 9/21/11 10:24 AM: --- Some of dependencies (hsqldb, jcifs) already exist in central maven repository - you only need to ask developers to upload latest versions. There is guide on submitting jars to central repository - https://maven.apache.org/guides/mini/guide-central-repository-upload.html, there are some requirements to jars, described separately (https://docs.sonatype.org/display/Repository/Central+Sync+Requirements). Regarding modified versions of xerces and httpclient - do patches MCF-specific, or they are already submitted to upstream? If already submitted, then we can use SNAPSHOT versions of them, taking them from Apache repository P.S. I think, that Jukka has some experience in uploading jars to maven repository was (Author: alexott): Some of dependencies (hsqldb, jcifs) already exist in central maven repository - you only need to ask developers to upload latest versions. There is guide on submitting jars to central repository - https://maven.apache.org/guides/mini/guide-central-repository-upload.html, there are some requirements to jars, described separately (https://docs.sonatype.org/display/Repository/Central+Sync+Requirements). Regarding modified versions of xerces and httpclient - do patches MCF-specific, or they are already submitted to upstream? If already submitted, then we can use SNAPSHOT versions of them, taking them from Apache repository > pom.xml refers to jars not available in public repositories > --- > > Key: CONNECTORS-258 > URL: https://issues.apache.org/jira/browse/CONNECTORS-258 > Project: ManifoldCF > Issue Type: Bug > Components: Build >Affects Versions: ManifoldCF 0.4 > Environment: all supported platforms >Reporter: Alex Ott >Priority: Minor > Labels: maven > > Maven's pom.xmls refers to jars that aren't available in public repositories, > as maven central, apache repository, etc. This includes: > - com.bitmechanic:jdbcpool > - org.hsqldb:hsqldb:jar:2.2.5.6-9-2011 (at maven central only version 2.2.4 > is available right now) > I think, that ManifoldCF should adopt the same approach as other Apache > projects, like Tika, when all needed jars first promoted to public > repositories, and only after that, they are used as dependency... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-258) pom.xml refers to jars not available in public repositories
[ https://issues.apache.org/jira/browse/CONNECTORS-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109390#comment-13109390 ] Alex Ott commented on CONNECTORS-258: - Some of dependencies (hsqldb, jcifs) already exist in central maven repository - you only need to ask developers to upload latest versions. There is guide on submitting jars to central repository - https://maven.apache.org/guides/mini/guide-central-repository-upload.html, there are some requirements to jars, described separately (https://docs.sonatype.org/display/Repository/Central+Sync+Requirements). Regarding modified versions of xerces and httpclient - do patches MCF-specific, or they are already submitted to upstream? If already submitted, then we can use SNAPSHOT versions of them, taking them from Apache repository > pom.xml refers to jars not available in public repositories > --- > > Key: CONNECTORS-258 > URL: https://issues.apache.org/jira/browse/CONNECTORS-258 > Project: ManifoldCF > Issue Type: Bug > Components: Build >Affects Versions: ManifoldCF 0.4 > Environment: all supported platforms >Reporter: Alex Ott >Priority: Minor > Labels: maven > > Maven's pom.xmls refers to jars that aren't available in public repositories, > as maven central, apache repository, etc. This includes: > - com.bitmechanic:jdbcpool > - org.hsqldb:hsqldb:jar:2.2.5.6-9-2011 (at maven central only version 2.2.4 > is available right now) > I think, that ManifoldCF should adopt the same approach as other Apache > projects, like Tika, when all needed jars first promoted to public > repositories, and only after that, they are used as dependency... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CONNECTORS-260) Maven build should download jtds.jar automatically, and maybe the mysql jdbc driver jar too, as part of JDBC connector build
Maven build should download jtds.jar automatically, and maybe the mysql jdbc driver jar too, as part of JDBC connector build Key: CONNECTORS-260 URL: https://issues.apache.org/jira/browse/CONNECTORS-260 Project: ManifoldCF Issue Type: Improvement Components: Build Affects Versions: ManifoldCF 0.4 Reporter: Karl Wright Fix For: ManifoldCF 0.4 The JDBC connector build under Maven should download all the supported JDBC drivers that it can, including jtds.jar and maybe mysql's jdbc driver jar. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Maven build
Part of the problem, for me, is learning what the issues are with Maven that maven developers will find problematic. One of the problems we're going to have is that the Maven central repository simply cannot provide the proprietary building materials for the connectors that need them, for instance Livelink and Documentum. These materials will always need to be pushed into a local repository, and it is also true that conditional compilation will also always be required, since any one builder will not have access to all proprietary libraries. Anyone have a good Maven solution to that? Karl On Wed, Sep 21, 2011 at 3:52 AM, Alex Ott wrote: > Hello > > On Wed, Sep 21, 2011 at 9:43 AM, Tommaso Teofili > wrote: >>> (2) I'm not sure it is reasonable to go with one build system over >>> another. Lucene/Solr has been having this battle for years. I >>> thought we might just learn from that experience and try to be more >>> flexible. There are excellent technical reasons to have each - for >>> instance, building Debian packages works much better with Ant, and >>> Eclipse works much better with Maven. >>> >> >> I don't like "wars" as well about which one *is* better, maybe it's just a >> matter of use case and personal preferences. >> However I like what you say about trying to be more flexible so I am +1 to >> your position. >> I have some experience with Maven so let me know if you need my help in >> tweaking that part of the build. > > I also have some experience with Maven, and I'm interested in MCF's > development, so I can try to fix some problems. The first thing, that > should be achieved - building with Maven out of box, without manual > work (or at least with minimum of it). > > -- > With best wishes, Alex Ott > http://alexott.net/ > Tiwtter: alexott_en (English), alexott (Russian) > Skype: alex.ott >
Maven setup script
Hi Alex, Can you attach this to the CONNECTORS-258 ticket? Be sure to click the "grant license to ASF" button when you do... Thanks! Karl On Wed, Sep 21, 2011 at 6:04 AM, Alex Ott wrote: > Hello > > We can put following script (in attachment) to simplify setup of > missing maven dependencies that are fetched using 'ant > download-dependencies' command. After using this script I was able to > build everything using maven. > > One more comment is on tests - maybe it's better to put long-running > tests, like filesystem tests, etc. into integration-test build stage > (https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html)? > Maven Failsafe plugin > (https://maven.apache.org/plugins/maven-failsafe-plugin/usage.html) > provides useful functionality to implement this. I think, that this > could make developer's life easier > > On Wed, Sep 21, 2011 at 9:52 AM, Alex Ott wrote: >> Hello >> >> On Wed, Sep 21, 2011 at 9:43 AM, Tommaso Teofili >> wrote: (2) I'm not sure it is reasonable to go with one build system over another. Lucene/Solr has been having this battle for years. I thought we might just learn from that experience and try to be more flexible. There are excellent technical reasons to have each - for instance, building Debian packages works much better with Ant, and Eclipse works much better with Maven. >>> >>> I don't like "wars" as well about which one *is* better, maybe it's just a >>> matter of use case and personal preferences. >>> However I like what you say about trying to be more flexible so I am +1 to >>> your position. >>> I have some experience with Maven so let me know if you need my help in >>> tweaking that part of the build. >> >> I also have some experience with Maven, and I'm interested in MCF's >> development, so I can try to fix some problems. The first thing, that >> should be achieved - building with Maven out of box, without manual >> work (or at least with minimum of it). >> >> -- >> With best wishes, Alex Ott >> http://alexott.net/ >> Tiwtter: alexott_en (English), alexott (Russian) >> Skype: alex.ott >> > > > > -- > With best wishes, Alex Ott > http://alexott.net/ > Tiwtter: alexott_en (English), alexott (Russian) > Skype: alex.ott >
[jira] [Commented] (CONNECTORS-258) pom.xml refers to jars not available in public repositories
[ https://issues.apache.org/jira/browse/CONNECTORS-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109388#comment-13109388 ] Karl Wright commented on CONNECTORS-258: In order for me to do this, I have to figure out/get permissions to promote jars into the central maven repository. Can you tell me how this is done? Or, better yet, do you have these permissions yourself? > pom.xml refers to jars not available in public repositories > --- > > Key: CONNECTORS-258 > URL: https://issues.apache.org/jira/browse/CONNECTORS-258 > Project: ManifoldCF > Issue Type: Bug > Components: Build >Affects Versions: ManifoldCF 0.4 > Environment: all supported platforms >Reporter: Alex Ott >Priority: Minor > Labels: maven > > Maven's pom.xmls refers to jars that aren't available in public repositories, > as maven central, apache repository, etc. This includes: > - com.bitmechanic:jdbcpool > - org.hsqldb:hsqldb:jar:2.2.5.6-9-2011 (at maven central only version 2.2.4 > is available right now) > I think, that ManifoldCF should adopt the same approach as other Apache > projects, like Tika, when all needed jars first promoted to public > repositories, and only after that, they are used as dependency... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
JDBC connector support for MySQL
Hi Tobias, Supporting MySQL in the JDBC connector is useful but not I think what Tommaso meant. Nevertheless, here's a ticket for that: CONNECTORS-259 Feel free to attach a patch! Also helpful would be the preferred URL for downloading the JDBC driver for MySQL; we can do that automatically before building. Karl On Wed, Sep 21, 2011 at 3:30 AM, Wunderlich, Tobias wrote: > (1) If MySQL support is something important then I will triage the > appropriate ticket accordingly. I'm curious where this requirement comes > from, though. > > For my part, I'd realy like MySQL support. At the moment I just modified the > jdbc-connector for my purposes, but an out of the box connector for mysql-dbs > would be much appreciated. > > Tobias >
[jira] [Created] (CONNECTORS-259) Support MySQL in the JDBC connector
Support MySQL in the JDBC connector --- Key: CONNECTORS-259 URL: https://issues.apache.org/jira/browse/CONNECTORS-259 Project: ManifoldCF Issue Type: New Feature Components: JDBC connector Affects Versions: ManifoldCF 0.4 Reporter: Karl Wright Fix For: ManifoldCF 0.4 A couple of folks would like to see the JDBC connector support MySQL. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: 1.0 release, and graduation
Hello We can put following script (in attachment) to simplify setup of missing maven dependencies that are fetched using 'ant download-dependencies' command. After using this script I was able to build everything using maven. One more comment is on tests - maybe it's better to put long-running tests, like filesystem tests, etc. into integration-test build stage (https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html)? Maven Failsafe plugin (https://maven.apache.org/plugins/maven-failsafe-plugin/usage.html) provides useful functionality to implement this. I think, that this could make developer's life easier On Wed, Sep 21, 2011 at 9:52 AM, Alex Ott wrote: > Hello > > On Wed, Sep 21, 2011 at 9:43 AM, Tommaso Teofili > wrote: >>> (2) I'm not sure it is reasonable to go with one build system over >>> another. Lucene/Solr has been having this battle for years. I >>> thought we might just learn from that experience and try to be more >>> flexible. There are excellent technical reasons to have each - for >>> instance, building Debian packages works much better with Ant, and >>> Eclipse works much better with Maven. >>> >> >> I don't like "wars" as well about which one *is* better, maybe it's just a >> matter of use case and personal preferences. >> However I like what you say about trying to be more flexible so I am +1 to >> your position. >> I have some experience with Maven so let me know if you need my help in >> tweaking that part of the build. > > I also have some experience with Maven, and I'm interested in MCF's > development, so I can try to fix some problems. The first thing, that > should be achieved - building with Maven out of box, without manual > work (or at least with minimum of it). > > -- > With best wishes, Alex Ott > http://alexott.net/ > Tiwtter: alexott_en (English), alexott (Russian) > Skype: alex.ott > -- With best wishes, Alex Ott http://alexott.net/ Tiwtter: alexott_en (English), alexott (Russian) Skype: alex.ott mvn-bootstrap.sh Description: Bourne shell script
Re: 1.0 release, and graduation
Hi, On Mon, Sep 19, 2011 at 9:06 PM, Karl Wright wrote: > (a) what we are still missing as far as incubator graduation is concerned There's still quite a bit to be done for community diversity. The drive to get new committers in is definitely a step in the right direction, but we'll need to follow up on that to make keep at least some of the new people as active members of the community. This is an area where mentors should be able to help (I'll try to increase my involvement here). To put things in perspective, since the beginning of this year Karl has made over 96% of all ManifoldCF commits. This makes the bus factor [1] of the project pretty high, and suggests that a more diverse development community is needed. The solution is not to have Karl commit less, but to get other people to more actively join the fun. The situation here is roughly similar to what we experienced during the incubation of Apache Tika. In the last year before graduation (2008) I was responsible for about 87% of all commits, which raised similar concerns about diversity [2]. The solution then was to graduate into a Lucene subproject instead of a full TLP, so that the larger project could still provide oversight and continuity in case things went wrong. Since then Lucene has shed out most subprojects to avoid being too large to manage, and by the time Tika in 2010 became a TLP by itself my share of all commits had shrunk to a still high but much more reasonable 62%. Today I'm still the most active committer, but my share of all the activity is down to 44%. I'd like to see ManifoldCF follow a similar trajectory. Graduating into a Lucene subproject is probably out of the question given the structural changes in Lucene, so for now my recommendation would be to remain in the Incubator until the community balance gets better. Some of the key things I did in Tika to help reduce my central role there were to lower the barriers of entry by working on things like the Getting Started page [3] and adding tools like the runnable tika-app jar and the simple GUI interface that make it trivially easy for someone to get started using Tika. The Build and Deploy guide in ManifoldCF [4] and the start.jar mechanism are good steps in this direction, but I think we could streamline quite a few of those steps. As Tommaso and others already mentioned, things like a simpler build process and a nicer UI can be quite useful. These are things that don't usually mean much to people already familiar to the system, but for potential new users and contributors with a short attention span they matter a lot. Thus I think these are areas that we should try to focus on in near future. [1] http://en.wikipedia.org/wiki/Bus_factor [2] http://markmail.org/message/bvqs2zv762fmlyv5 [3] http://tika.apache.org/0.9/gettingstarted.html [4] http://incubator.apache.org/connectors/how-to-build-and-deploy.html BR, Jukka Zitting
Re: 1.0 release, and graduation
Hello On Wed, Sep 21, 2011 at 9:43 AM, Tommaso Teofili wrote: >> (2) I'm not sure it is reasonable to go with one build system over >> another. Lucene/Solr has been having this battle for years. I >> thought we might just learn from that experience and try to be more >> flexible. There are excellent technical reasons to have each - for >> instance, building Debian packages works much better with Ant, and >> Eclipse works much better with Maven. >> > > I don't like "wars" as well about which one *is* better, maybe it's just a > matter of use case and personal preferences. > However I like what you say about trying to be more flexible so I am +1 to > your position. > I have some experience with Maven so let me know if you need my help in > tweaking that part of the build. I also have some experience with Maven, and I'm interested in MCF's development, so I can try to fix some problems. The first thing, that should be achieved - building with Maven out of box, without manual work (or at least with minimum of it). -- With best wishes, Alex Ott http://alexott.net/ Tiwtter: alexott_en (English), alexott (Russian) Skype: alex.ott
Re: 1.0 release, and graduation
Hello Karl 2011/9/21 Karl Wright > Hi Tommaso, > > Thanks for your feedback! > > Are you in a position to update the status page? I don't think I can. > I should be able to do it, will try and see if I can get that updated finally :) > If you disagree please point me in the right direction.. > > > As far as the technical aspects: > (1) If MySQL support is something important then I will triage the > appropriate ticket accordingly. I'm curious where this requirement > comes from, though. > this requirement just comes from my little experience; since I started mentoring here I tried to see if/where ManifoldCF would fit a particular business case (dealing almost always with managing communication between some source and Solr) and quite always I got asked if it could be used with MySQL instead of PostgreSQL. Personally I always prefer the latter for it's just faster (at least where I've seen meaningful comparisons) but often MySQL gets chosen as a DBMS maybe just for the reason that it's more popular. So this comes from some people asking me about the possibility of using ManifoldCF with MySQL instead of PostgreSQL. However this is not a 'blocker', just I think that it should give much architecture flexibility (and, thus, adoption) to the project. > (2) I'm not sure it is reasonable to go with one build system over > another. Lucene/Solr has been having this battle for years. I > thought we might just learn from that experience and try to be more > flexible. There are excellent technical reasons to have each - for > instance, building Debian packages works much better with Ant, and > Eclipse works much better with Maven. > I don't like "wars" as well about which one *is* better, maybe it's just a matter of use case and personal preferences. However I like what you say about trying to be more flexible so I am +1 to your position. I have some experience with Maven so let me know if you need my help in tweaking that part of the build. > (3) I would love to have the UI look cooler. Stylistic work on the UI > is definitely not the right job for me though. Now, Piergiorgio > mentioned going to a spring-based UI but I'm not sure that will fix > anything stylistically, and it might well require redefinition of the > connector interfaces, which would be a bad thing at this point, so I > don't see much benefit to this architectural change proposal. Is this > what you were thinking of, or were you more thinking of look and feel? > My concern at the moment with this point is more related to the look and feel than on the appropriate (MVC) framework since I am not sure I'd want to inject another framework (I think l&f can be better than the current one just using servlets and some JS). However if changing the framework would fasten the process of enhancing the UI style I'm ok for that too, on the contrary if that would affect connector interfaces it maybe a huge work to do right now. I'd love to hear other opinions on this and other topics as I'm sure MySQL and UI aren't the only open points the community would like to get sorted. Have a nice day you all. Cheers, Tommaso > > Karl > > > On Tue, Sep 20, 2011 at 5:51 PM, Tommaso Teofili > wrote: > > Hello Karl, all > > > > > > 2011/9/19 Karl Wright > > > >> Folks, > >> I'd like to begin discussion about the next release, currently labeled > >> 0.4, and also our potential for graduation from the incubator. What > >> I'd like is a sense of: > >> > >> (a) what we are still missing as far as incubator graduation is > concerned, > > > > > > at the moment I think we're in the right direction towards the graduation > > (see the clutch report [1] which however doesn't count the new > > committers/mentors as our page on Incubator website has to be updated). > > > > > >> and > >> (b) what a 1.0 release might look like to everyone > >> > > > > my point here relates also to the graduation: I think we're building a > nice > > community and the ManifoldCF code is being bettered every day but it > seems > > to me there are some (few) parts which need some refactoring as they > can't > > work as they are now (i.e.: support to MySQL DBs), also in my opinion we > > should choose one of Maven or Ant and drop the other building system as I > > fear this could confuse new users/devs. > > A minor thing in my opinion is that a restyle of the UI would make > > ManifoldCF some more "nice" to use, however this can be pretty personal > and > > less important than functional requirements. > > > > > > > >> > >> Please try to be as concrete as possible. My own personal goal is to > >> see this happen by the end of the year, more or less > > > > > > +1 > > > > > >> To that end > >> I've already begun triaging JIRA tickets for the 0.4 release that I > >> think would be appropriate for a 1.0 release. > >> > >> It's entirely possible that some things that people feel strongly > >> about may not be doable in that time frame, but so be it. This may > >> also be true of our status
AW: 1.0 release, and graduation
(1) If MySQL support is something important then I will triage the appropriate ticket accordingly. I'm curious where this requirement comes from, though. For my part, I'd realy like MySQL support. At the moment I just modified the jdbc-connector for my purposes, but an out of the box connector for mysql-dbs would be much appreciated. Tobias
