As explained in IM, for the Javadocs there are a number of solutions. But the best *overall* solution (I think) is to create stubs. It solves the problem of the release engineer needing access to proprietary libraries also.
Karl On Fri, May 25, 2012 at 5:41 AM, Simon Willnauer <[email protected]> wrote: > hey karl, > > maybe I misread this but can't your remote link the javadocs or 3rd party > libs? > > simon > > On Fri, May 25, 2012 at 11:16 AM, Karl Wright <[email protected]> wrote: >> I think that would want to be a separate INFRA ticket. We can't >> really create it until our svn area is moved, and I'm still waiting on >> that. >> >> Thanks, >> Karl >> >> On Fri, May 25, 2012 at 2:35 AM, Alex Ott <[email protected]> wrote: >>> Hi Karl >>> >>> Can we create git mirror for manifoldcf (as part of graduating >>> activities)? I'm working on several computers and that would be handy >>> to have "official" git repository instead of maintaining my own via >>> git-svn >>> >>> On Mon, May 21, 2012 at 11:24 AM, Karl Wright <[email protected]> wrote: >>>> Hi all, >>>> >>>> The Apache IT folks have an additional requirement which we will need >>>> to fulfill at some point as part of the graduation process. It is >>>> apparently a requirement that at least the site be completely >>>> buildable using only materials that we can obtain a zero-cost license >>>> for. We've been publishing our site including javadoc including the >>>> documentum, filenet, livelink, and meridio connectors, which >>>> technically violates this principle. >>>> >>>> There are two ways to address the problem. The first way is to check >>>> into trunk somewhere the javadocs, and periodically regenerate/check >>>> in changes. The second way is to write stubs for all of the >>>> proprietary libraries, and build and javadoc against those stubs >>>> rather than against the actual libraries themselves. >>>> >>>> After thinking about this a while, I concluded that it might be >>>> feasible to create stubs, and there would be additional benefits to >>>> the approach. Specifically, it would no longer be necessary for our >>>> release engineer to obtain the necessary proprietary materials in >>>> order to produce a release, and that would be a huge benefit in the >>>> long run. Also, Apache IT communicated that they were concerned that >>>> some of the proprietary materials might have javadoc restrictions such >>>> that we could not legally release javadoc for code that compiled >>>> against these jars. I do not think this is true but in the interests >>>> of trying to be a good Apache citizen we should eliminate this concern >>>> if it is reasonably possible to do so. >>>> >>>> I've therefore created a ticket, CONNECTORS-474, and a corresponding >>>> branch, and am working away on this. It will, of course, take some >>>> time. There will also need to be some testing of the proprietary >>>> connectors needed before the branch is committed, because building >>>> against stubs might inadvertantly introduce linkage errors. In the >>>> interim I've been assured that the migration to our TLP resources will >>>> continue as planned. >>>> >>>> Thanks, >>>> Karl >>> >>> >>> >>> -- >>> With best wishes, Alex Ott >>> http://alexott.net/ >>> Tiwtter: alexott_en (English), alexott (Russian) >>> Skype: alex.ott
