On Thu, Apr 30, 2015 at 5:12 PM, Nick Burch <[email protected]> wrote:
> On Thu, 30 Apr 2015, Allison, Timothy B. wrote: > >> We see advantages: >> 1) "It just makes sense" to have one centralized MSOffice parsing library >> 2) Increasing public awareness of each other's projects >> 3) sparking more cross-project, well, inner-project, collaboration among >> the POI and Jackcess developers. >> > > All of these make sense to me! > > Some potential disadvantages: >> >> 1) From a use standpoint, current users of Jackcess would have to migrate >> their code (if we changed the namespace) >> > > Whether the code came to POI, or into the incubator, the namespace would > need to chance either way. However, it should be possible to produce a > compatibility jar with @deprecated classes extending from the renamed ones, > to minimise the pain for users, either semi-manually, or possibly via some > sort of dynamic class generation / invoking wizardry. > This seems possible after some superficial thought, however i feel like it may end up running into some java limitations... > 2) We'd have to redesign the maven build process to ant for Jackcess (not >> hard, I know). >> > > Not necessarily. POI already has a few maven bits in the build, which ant > calls out to. No reason why Jackcess couldn't be another > > (At some point, we may find ourselves needing to move from Ant to Maven + > quite a few custom maven plugins, but for now a hybrid approach works well > for letting us do some nifty but very complex stuff in Ant for the build, > whilst giving Maven poms for use in Maven land) > > 3) From an integration standpoint, Jackcess doesn't rely on POI at all so >> there would be no immediate decrease in source code/maintainability; we >> might find some areas, but we'd have to find them. >> > > There's probably some utils we could share, but initially I'd expect the > integration would be more user / committer than code > > 4) Further, Jackcess would be tied to POI's release schedule. >> > > Maybe, maybe not. As an example, the Tomcat project has distributions of > Tomcat, Tomcat Connections, Tomcat Native Connector and Taglibs, all on > their own independent release cycles and packaging. > > We'd probably just need to see how the communities gell'd/not, and decide > from that > is that a near term thing, or would that require a large re-factor? poi seems to currently be mostly one big jar. In short, we'd break Jackcess for its users, add work for Jackcess and POI >> developers, and then have no immediate payoff from cleaner/less code or >> performance or anything else. >> > > However, it'd gain wider use, and have a wider pool of potential developers > Do you think that's the case (at least regarding the wider use part)? Do you think that renaming the classes and including the jackcess class in the poi jar is necessary to make that happen? after all, both poi and jackcess are currently available from the central maven repository. if jackcess was part of poi but did have its own release schedule, it would still be a separate jar in the central repository, just in a different group from where it is now. if jackcess was listed in the poi documentation alongside the other modules, wouldn't that effectively achieve the same thing? i could potentially see the wider pool of potential developers, but that could be achieved by sharing a repository but still keeping jackcess as a separate module without all the other changes. as already mentioned, there's probably fairly little "common code" overlap. > As it stands, I fear that if you took a Jackcess proposal to the Apache > Incubator with only one active developer, it would struggle. It could be > worth checking with the experts though, on the [email protected] > list, to see what they suggest based on their past experiences > sounds like at the end of it, you don't think it'll actually happen anyway! :) > Nick >
