[ANNOUNCE] Announcing general availability of Apache ManifoldCF 0.3-incubating!
Thanks to all who put time and effort into this release! The site and download mirrors should update in a day or so, but if you cannot wait, you can download the release in the interim from http://www.apache.org/dist/incubator/manifoldcf. Karl
[jira] [Commented] (CONNECTORS-257) Input-able response lifetime for Active Directory authority
[ https://issues.apache.org/jira/browse/CONNECTORS-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13108454#comment-13108454 ] Karl Wright commented on CONNECTORS-257: The patch looks technically correct. A couple of things I recommend changing, however: (1) A point of English: Let's call it Cache lifetime in the UI and in the configuration data, not Response lifetime. (2) It's probably better to parse the cache lifetime into a numeric member variable (a long) at either connect() or getSession() time. At getSession() time you can report an error if the number is incorrect. (3) When you parse the cache lifetime, you need to be careful because the parameter may be null (e.g. from an older installation). Input-able response lifetime for Active Directory authority --- Key: CONNECTORS-257 URL: https://issues.apache.org/jira/browse/CONNECTORS-257 Project: ManifoldCF Issue Type: Improvement Components: Active Directory authority Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3 Reporter: Shinichiro Abe Assignee: Shinichiro Abe Priority: Minor Fix For: ManifoldCF 0.4 Attachments: CONNECTORS-257-1.patch The access tokens are cached for one minute, and up to 1000 different users' access tokens will be cached at any one time. The access token's cache per username remains idle before expiring. Its expiration time depends response lifetime, and expiration time is updated after looking up the cache. Currently response lifetime is 1 minute. Since I want not to access Active Directory frequently, I make this response lifetime to be input-able for users. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-257) Input-able response lifetime for Active Directory authority
[ https://issues.apache.org/jira/browse/CONNECTORS-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13108456#comment-13108456 ] Karl Wright commented on CONNECTORS-257: I also found a technical problem - sorry! The line: protected static long responseLifetime = 6L; ... obviously cannot remain the same, since it is a static. Instead you will need to pass the response lifetime as an argument to the AuthorizationResponseDescription class - either that, or make that class non-static and move the responseLifetime variable to be a non-static member variable of the connector class. Otherwise individual authorities will have their cache lifetimes conflated. Input-able response lifetime for Active Directory authority --- Key: CONNECTORS-257 URL: https://issues.apache.org/jira/browse/CONNECTORS-257 Project: ManifoldCF Issue Type: Improvement Components: Active Directory authority Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3 Reporter: Shinichiro Abe Assignee: Shinichiro Abe Priority: Minor Fix For: ManifoldCF 0.4 Attachments: CONNECTORS-257-1.patch The access tokens are cached for one minute, and up to 1000 different users' access tokens will be cached at any one time. The access token's cache per username remains idle before expiring. Its expiration time depends response lifetime, and expiration time is updated after looking up the cache. Currently response lifetime is 1 minute. Since I want not to access Active Directory frequently, I make this response lifetime to be input-able for users. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-223) Tests in project hierarchy do not adhere to maven conventions
[ https://issues.apache.org/jira/browse/CONNECTORS-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13108894#comment-13108894 ] Alex Ott commented on CONNECTORS-223: - I'm not sure, that packages not available at Maven central, or other repositories, should be used in pom's - in Tika project another approach is used - all needed jars are promoted to repository first, and only after it are used... Tests in project hierarchy do not adhere to maven conventions - Key: CONNECTORS-223 URL: https://issues.apache.org/jira/browse/CONNECTORS-223 Project: ManifoldCF Issue Type: Bug Components: Build Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 0.3 Attachments: CONNECTORS-223.patch, CONNECTORS-223_forkMode.patch, CONNECTORS-223_jetty-runner.patch, CONNECTORS-223_tests.patch, test_reset.patch Maven expects unit tests under .../src/test/java, and root-level project tests under tests/xxx/src/test/java (or equivalent, along with their own pom.xml at tests and tests/xxx). This is basically compatible with the ant build except in location detail. The proposal is to move stuff around to make the tests work with maven. -- 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-tabpanelfocusedCommentId=13108928#comment-13108928 ] Alex Ott commented on CONNECTORS-258: - another possibility - setup separate maven repository and server missing jars from it 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
Re: 1.0 release, and graduation
Hello Karl, all 2011/9/19 Karl Wright daddy...@gmail.com 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 as a project. What do others think? All the best. Tommaso [1] : http://incubator.apache.org/clutch.html [2] : http://incubator.apache.org/projects/manifoldcf.html Thanks, Karl
Re: 1.0 release, and graduation
Hi Tommaso, Thanks for your feedback! Are you in a position to update the status page? I don't think I can. 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. (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. (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? Karl On Tue, Sep 20, 2011 at 5:51 PM, Tommaso Teofili tommaso.teof...@gmail.com wrote: Hello Karl, all 2011/9/19 Karl Wright daddy...@gmail.com 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 as a project. What do others think? All the best. Tommaso [1] : http://incubator.apache.org/clutch.html [2] : http://incubator.apache.org/projects/manifoldcf.html Thanks, Karl
