Niall, > Is a "binary only" release acceptable at the ASF? I always thought as > an "open source" organization the minimum requirement for a release > was a source distro from which someone could build it themselves - and > a binary distro was a nice to have convience as an optional extra. >
I'm sorry but you misinterpreted my (and also by transitivity Jukka's) suggestion. By releasing Tika as a "jar file" I didn't mean that the only visible release of the system will be a "jar file". It simply means that the build target rather than a deployment bin struct, with say, a directory layout (e.g., /bin /etc /logs scripts/ conf/), would be a jar file. That's the only suggestion. The mvn assembly:assembly goal simply builds the jar deliverable anyways (and packages them up as the "-bin".* files). Of course, the source code is built as the "-src".* files as well and any release would have to include src as well. > > The real issue though is whether the IPMC will accept just a jar as a > release - since as an incubating project Tika can't actually release > anything without their approval. I would be surprised if they didn't > make the same comment as I did. I'm not too familiar with the Incubator PMC, but people like Jukka, and Bertrand, who sit on it, I'm guessing are. So we'll see what they think. Cheers, Chris > > Niall > >> I can work on the release as soon as I get a go-ahead from the rest of you >> guys. Should we call a vote? I think that the only blocker issue is TIKA-91 >> that needs to be fixed pre-release. The rest of the issues (8 major and 12 >> minor) are all such that they can be cast for the 0.2 release. >> >> Cheers, >> Chris >> >> >> >> On 11/11/07 3:56 PM, "Jukka Zitting" <[EMAIL PROTECTED]> wrote: >> >>> Hi, >>> >>> I don't think we'll have the 0.1 release out for ApacheCon (it's >>> probably even procedurally too late already), but it would still be >>> nice to target for a release in a relatively near future. I think >>> we're already at a point where quite a few people would find a frozen >>> snapshot of Tika useful (even if the API still isn't stable). >>> >>> There are a number of API and implementation improvements I have in >>> mind (I'll try to offload them to Jira), but generally I'm reasonably >>> happy with the current state. The main thing I'm worried about is >>> packaging (and documentation, but that's not so important yet). >>> >>> Are we happy with releasing Tika just as a jar file with a related POM >>> to be published in the Maven repository, or should we come up with >>> some packaging that perhaps bundles also all the dependencies? I'd be >>> fine with just a jar artifact unless we want to make Tika runnable >>> just by itself (either as a webapp or a CLI application). >>> >>> BR, >>> >>> Jukka Zitting >> >> ______________________________________________ >> Chris Mattmann, Ph.D. >> [EMAIL PROTECTED] >> Cognizant Development Engineer >> Early Detection Research Network Project >> _________________________________________________ >> Jet Propulsion Laboratory Pasadena, CA >> Office: 171-266B Mailstop: 171-246 >> _______________________________________________________ >> >> Disclaimer: The opinions presented within are my own and do not reflect >> those of either NASA, JPL, or the California Institute of Technology. >> >> >> ______________________________________________ Chris Mattmann, Ph.D. [EMAIL PROTECTED] Cognizant Development Engineer Early Detection Research Network Project _________________________________________________ Jet Propulsion Laboratory Pasadena, CA Office: 171-266B Mailstop: 171-246 _______________________________________________________ Disclaimer: The opinions presented within are my own and do not reflect those of either NASA, JPL, or the California Institute of Technology.
