Hi James,
I’m sorry for my delay. I think Nick’s guidance on the incubator issue
applies if we were trying to make Jackcess a new Apache “top level project”.
For the proposal of integrating Jackcess with POI, it looks like we’d have to
at least go through the Incubator for the IP Clearance process [1]. I don’t
know if we’d have to go through the full “sub-project” process [2]. I could
very well be wrong, though.
Nick and others,
Any other feedback to James’s other points or to my paragraph above?
Best,
Tim
[1] http://incubator.apache.org/ip-clearance/index.html
[2] http://incubator.apache.org/incubation/Process_Description.html
From: James Ahlborn [mailto:[email protected]]
Sent: Sunday, May 10, 2015 9:08 PM
To: Nick Burch
Cc: POI Developers List; [email protected]
Subject: Re: Integrating Jackcess with POI?
this thread seemed to die off. unsure where we are with all this. sounds like
it's rather unlikely that jackcess would qualify for incubator status due to
its small size.
On Thu, Apr 30, 2015 at 11:04 PM, James Ahlborn
<[email protected]<mailto:[email protected]>> wrote:
On Thu, Apr 30, 2015 at 5:12 PM, Nick Burch
<[email protected]<mailto:[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]<mailto:[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
