Hi folks, As for the last pile of revisions, which download dependencies from Maven or SVN depending, Jukka and I agreed that we'll also need either a dependencies artifact or a source + dependencies artifact. How we get the dependencies in the first place, though, is still unclear, so we decided to put the question to infrastruct...@apache.org to find out their opinion of whether downloading binaries from svn was acceptable. I did not get a clear answer to that, but I can say the following:
(1) There is a clear level of discomfort about storing ANY binaries in apache infrastructure. (2) For patched dependent releases, the recommended process is to download source tar/zip, unpack it, apply patches, and build it, all as part of the build process for the main release. (3) For those releases that simply do not exist at all in Maven, the ideal process is to download the sources and build them. The problems, then, are as follows: (1) ManifoldCF binary distributions include packages which can only be built on specific architectures. For example, the SharePoint 3.0 mcf plugin. (2) Patching of source cannot be done in a standard way on both Windows and Linux, other than within an SVN checkout (via svn patch). (3) There may be some binary dependencies whose sources are hard to get hold of, e.g. jdbcpool-0.99.jar, which are also not found in Maven. Possible solutions include: (1) Only patch sources that we can check out via svn. This implies that, during the build process, instead of checking out a single binary, we check out an entire source tree. Then we can apply the patch. Downside: svn access required during build. (2) Remove the dependency on anything we find we can't get the sources for, such as jdbcpool-0.99. Downside: requires significant code changes. (3) Check in the binaries for all platform-dependent builds into googlecode. Downside: Not clear whether the Incubator will consider this reasonable. (4) Require that builds only take place on Windows machines with appropriate Windows tools and upstream dependencies installed. Downside: Essentially a non-starter. Obviously all of this will greatly complicate the build and release process for ManifoldCF, if indeed there is exists an "acceptable" solution at all. I honestly don't have a workable answer in mind at this point for all of the new constraints we're dealing with. Karl On Mon, Apr 2, 2012 at 10:02 AM, Karl Wright <daddy...@gmail.com> wrote: > My major concern with the release of binaries through the standard > Apache channel is that we then effectively have another release that > must be synchronized with the main release, since the non-maven > binaries are not, by definition, part of the main release. > > I set bin-dist up with that in mind, so that it can effectively remain > unversioned, and be "add only". > > If there is no other choice than parallel releases of binaries and > source, with a separation of binaries and source in the svn tree, then > I will have to think through the best solution. Certainly we will > have to treat binaries from different sources differently. For > example, all of the following would potentially need a different > solution: > > (1) Stuff that's available from maven that is license-compatible with Apache > (2) Stuff that's available from maven that is NOT license-compatible with > Apache > (3) Stuff that's not available from maven that is license-compatible with > Apache > (4) Stuff that's not available from maven that is not > license-compatible with Apache > > We could not package dependencies that are (2) or (4). We would > *have* to package (3), but not necessarily (1). > > Is this making your head spin yet? Mine is... > > An svn-based download is technically little different than a source > checkout, seems to me, which is why I wonder why we would make a > distinction at all. > > Karl > > > > > > On Mon, Apr 2, 2012 at 9:49 AM, Jukka Zitting <jukka.zitt...@gmail.com> wrote: >> Hi, >> >> On Mon, Apr 2, 2012 at 2:31 PM, Karl Wright <daddy...@gmail.com> wrote: >>> The only other potential problem is that the >>> license/notice/dependencies files may not conform strictly to >>> incubator guidelines. Specifically, we are not including a different >>> set of files with a bin release vs. a source release, and also it was >>> unclear whether our format (which was once again based on Lucene/Solr) >>> is still acceptable or not. The thread in general@i.a.o provided some >>> examples, but it is not clear whether those were the ONLY acceptable >>> formats. I am hoping for Jukka and Tommaso's feedback here before we >>> present this artifact to the incubator. >> >> Ideally the licensing metadata (i.e. the LICENSE and NOTICE files) >> should only cover material contained in that specific package. See [1] >> for a related discussion from a few years ago. At least back then it >> seemed acceptable for a project to also only maintain a single set of >> license metadata that covers the contents of both source and binary >> distributions. AFAIUI that approach is in use by many Apache projects. >> >> About the RC more generally, I find the download-via-svn target a bit >> troublesome as it makes the release depend on content in svn. That >> essentially turns the svn server into a release distribution channel, >> which it definitely shouldn't be. >> >> I think it's fine to manage the set of binary dependencies (that >> aren't available in a stable third party location like Maven Central) >> in svn, but a release should not try to access them from there. >> Instead we should for example package them up in a separate -lib or >> -deps archive and make it available for download along with the source >> release through the standard Apache mirroring network. That archive >> should also come with appropriate licensing metadata that's currently >> lacking in bin-dist. >> >> [1] http://markmail.org/message/bttmkavpicxxg7gl >> >> BR, >> >> Jukka Zitting
