You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by "Allison, Timothy B." <ta...@mitre.org> on 2015/04/20 21:32:46 UTC
Integrating Jackcess with POI?
All,
With many thanks to Brian O'Neill at Health Market Science and James Ahlborn, Jackcess was relicensed to ASL 2.0. I received favorable feedback on private@poi when I posed this question a month or so ago.
What do people think of integrating Jackcess into POI?
Best,
Tim
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
>>
>
>
Re: Integrating Jackcess with POI?
Posted by James Ahlborn <ja...@gmail.com>.
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 Nick Burch <ap...@gagravarr.org>.
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.
> 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
> 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
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
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: Integrating Jackcess with POI?
Posted by Andreas Beeker <ki...@apache.org>.
Hi Tim,
> So, upon further thought, we propose not integrating Jackcess with POI for now, but we do propose adding links from each other's websites to the other so that users of POI will learn about Jackcess and vice versa.
>
>
> How does this sound?
I don't mind having links to Jackcess in POI - so +1 from me.
Imho, it's a pity that they've decided otherwise.
I totally respect their decision and I probably would have also other points not to join,
e.g. if I would program for OSS @ work, my main reason not to join would be,
that the namespace is a kind of figurehead for my employer.
> I'd like to share the points from our conversation to elicit public feedback.
Not sure if it makes sense to argue, but here are my two cents:
> 2) We'd have to redesign the maven build process to ant for Jackcess (not hard, I know).
Actually I think this would be the most effort for the beginning.
> 1) From a use standpoint, current users of Jackcess would have to migrate their code (if we changed the namespace)
So the users would have to press ctrl+shift-o in the Eclipse package explorer?
> 4) Further, Jackcess would be tied to POI's release schedule.
Currently we have betas every 2-4 months, depending on the amount of changes.
I think this is reasonable.
> 3) From an integration standpoint ...
ACK.
> 5) ... there is no decrease in learning cost simply because of a change in namespace.
Just because it's not an advantage, this is not automatically a disadvantage of joining poi.
Best wishes,
Andi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
RE: Integrating Jackcess with POI?
Posted by "Allison, Timothy B." <ta...@mitre.org>.
All,
James Ahlborn and I had further discussions on what the actual implementation would require to integrate Jackcess into POI, and we discussed the advantages and potential drawbacks of integrating Jackcess into POI. I'd like to share the points from our conversation to elicit public feedback.
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.
Some potential disadvantages:
1) From a use standpoint, current users of Jackcess would have to migrate their code (if we changed the namespace)
2) We'd have to redesign the maven build process to ant for Jackcess (not hard, I know).
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.
4) Further, Jackcess would be tied to POI's release schedule.
5) New users of Jackcess within POI would still have to learn its API whether or not it was within POI or remained as is - there is no decrease in learning cost simply because of a change in namespace.
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.
So, upon further thought, we propose not integrating Jackcess with POI for now, but we do propose adding links from each other's websites to the other so that users of POI will learn about Jackcess and vice versa.
How does this sound?
Best,
Tim
-----Original Message-----
From: Nick Burch [mailto:apache@gagravarr.org]
Sent: Monday, April 27, 2015 5:47 PM
To: POI Developers List
Cc: James Ahlborn; tallison@apache.org
Subject: Re: Integrating Jackcess with POI?
On Mon, 20 Apr 2015, Allison, Timothy B. wrote:
> With many thanks to Brian O'Neill at Health Market Science and James
> Ahlborn, Jackcess was relicensed to ASL 2.0. I received favorable
> feedback on private@poi when I posed this question a month or so ago.
>
> What do people think of integrating Jackcess into POI?
It'd be great to be able to add another area of the Microsoft file formats
to POI, so I'd be +1!
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: Integrating Jackcess with POI?
Posted by Nick Burch <ap...@gagravarr.org>.
On Mon, 20 Apr 2015, Allison, Timothy B. wrote:
> With many thanks to Brian O'Neill at Health Market Science and James
> Ahlborn, Jackcess was relicensed to ASL 2.0. I received favorable
> feedback on private@poi when I posed this question a month or so ago.
>
> What do people think of integrating Jackcess into POI?
It'd be great to be able to add another area of the Microsoft file formats
to POI, so I'd be +1!
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: Integrating Jackcess with POI?
Posted by Yegor Kozlov <ye...@dinom.ru>.
+1
Yegor
On Mon, Apr 20, 2015 at 10:32 PM, Allison, Timothy B. <ta...@mitre.org>
wrote:
> All,
>
> With many thanks to Brian O'Neill at Health Market Science and James
> Ahlborn, Jackcess was relicensed to ASL 2.0. I received favorable feedback
> on private@poi when I posed this question a month or so ago.
>
> What do people think of integrating Jackcess into POI?
>
>
> Best,
>
> Tim
>
>
>
Re: Integrating Jackcess with POI?
Posted by Andreas Beeker <ki...@apache.org>.
Hi Tim,
> What do people think of integrating Jackcess into POI?
same as on private@ ... I'm +1 for it and looking forward to their joining.
Best wishes,
Andi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org