You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by James Ahlborn <ja...@gmail.com> on 2015/05/01 05:04:49 UTC
Re: Integrating Jackcess with POI?
On Thu, Apr 30, 2015 at 5:12 PM, Nick Burch <ap...@gagravarr.org> 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 general@incubator.a.o
> 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
>
RE: Integrating Jackcess with POI?
Posted by James Ahlborn <ja...@gmail.com>.
So, there doesn’t seem to be a lot of feedback on this. Having some time to think about this more on my end, I really think the best idea is to take things slow. There don’t seem to be any huge, up-front benefits from folding jackcess into poi (but there certainly is some non-trivial effort involved). It seems like simply adding some “cross-selling” to the respective websites would be a good first step. This will hopefully lead to more visibility for jackcess within the broader poi community. If so, and there is more interest expressed from the poi community in the future, we can always re-evaluate closer integration at a later date. Thoughts?
-james
From: Allison, Timothy B. [mailto:tallison@mitre.org]
Sent: Tuesday, May 12, 2015 12:39 PM
To: James Ahlborn; Nick Burch
Cc: POI Developers List; tallison@apache.org
Subject: RE: Integrating Jackcess with POI?
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:jahlborn@gmail.com]
Sent: Sunday, May 10, 2015 9:08 PM
To: Nick Burch
Cc: POI Developers List; tallison@apache.org
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 <ja...@gmail.com> wrote:
On Thu, Apr 30, 2015 at 5:12 PM, Nick Burch <ap...@gagravarr.org> 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 general@incubator.a.o 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
RE: Integrating Jackcess with POI?
Posted by "Allison, Timothy B." <ta...@mitre.org>.
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:jahlborn@gmail.com]
Sent: Sunday, May 10, 2015 9:08 PM
To: Nick Burch
Cc: POI Developers List; tallison@apache.org
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 <ja...@gmail.com>> wrote:
On Thu, Apr 30, 2015 at 5:12 PM, Nick Burch <ap...@gagravarr.org>> 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 general@incubator.a.o<ma...@incubator.a.o> 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
Re: Integrating Jackcess with POI?
Posted by James Ahlborn <ja...@gmail.com>.
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 <ja...@gmail.com> wrote:
>
> On Thu, Apr 30, 2015 at 5:12 PM, Nick Burch <ap...@gagravarr.org> 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 general@incubator.a.o
>> 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
>>
>
>