Logging / Binary compatibility?

[Andreas Beeker <ki...@apache.org>]

Hi,

I've just changed something in POILogger for #58040 and additionally refactored the various methods to a varags method.
This works when code gets compiled but fails if only the binary is replaced.

What is our guideline regarding ...?
- binary compatibility
- deprecated objects, i.e. org.apache.poi.openxml4j.opc.Package

Nicks posts [1] says:
"Backwards compatibility - if possible we maintain binary compatibility, if
not source, and only break things if really needed."

So binary compatibility means our dependencies?
and "if not source" means, it's ok when user code doesn't need to be changed, but needs to be recompiled?

How about allowing to remove deprecated stuff after 2 years (i.e. ages) after it has been marked deprecated?

Regarding the POILogger - I sometimes wonder, why we need to keep (historical) things which in
the meantime exist in common. How about replacing POILogger by SLF4J?
(it seems to be compatible with ASL [2])

Best wishes,
Andi

[1] http://apache-poi.1045710.n5.nabble.com/Advice-for-new-and-potential-committers-td5718862.html
[2] http://www.slf4j.org/license.html

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org

Re: Logging / Binary compatibility?

[Andreas Beeker <ki...@apache.org>]

Hi again,

> I don't think any users actually use POILogger in their code,or?
Timewise in parallel I thought the same and applied the patch.

> e.g. by stating that after 2 releases in deprecated state we can remove things for good.
+1

> Regarding slf4j, we could also look at commons-logging
at my $dayjob we had a websphere 8 migration some time ago and I'm not sure, if
it was because someone put commons-logging in the shared-library which all the
portal projects had to use or if it was in the server lib path [1] ... in the end,
all the projects had to remove their own commons-logging.jar and stick with the
global version. Classloading-order was also an issue. Don't know how configuration was handled.
We usually worked with our own log4j.jar and PARENT_LAST, but not all projects
were allowed to.
So since then JCL sticks with some negative memory, although it's not JCLs fault.

Maybe another note to POILogger ... usually the NullLogger will be used,
so even if we sparsely log warnings/errors, they will be ignored by default ...
that's my main motivation for this, to log more and to know that the user will eventually
see it in the log ... and system.properties to activate a feature is not so practically ...

A similar topic is the usage of other libs - of course this might be a license issue and
if it is really necessary, i.e. if we should use JDK features vs. another/reference impl.
I don't think that's a problem nowadays (e.g. sizewise) for standalone/web applications,
but don't know about Android apps - maybe someone can shed a light on it?
Is there a good page about what to look for when providing a library for Android apps?

Andi.


[1] http://blog.xebia.com/2009/04/10/logging-in-websphere-application-server-using-apache-commons-logging-and-log4j/




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org

Re: Logging / Binary compatibility?

[Dominik Stadler <do...@gmx.at>]

Hi,

I also think that we should be able to break binary compatibility in
rare cases where it is cumbersome to maintain full compatibility. Also
replacing things that likely only very few people use outside of POI
(e.g. I don't think any users actually use POILogger in their code,
or?) should be possible, either by announcing the de-support by
deprectating it or by describing easy steps to adjust user-code.

What would help in the long run would be a notion of "internal"
classes which we don't expect people to use on the outside. Some other
projects use this and can then break stuff in these "internal"
packages as needed.

Also an official guideline to our users for how long we keep
deprecated code would help to free the code from cruft, e.g. by
stating that after 2 releases in deprecated state we can remove things
for good. Many other projects do it this way successfully.

Regarding slf4j, we could also look at commons-logging, this way we
would stay with Apache managed projects and their license here and
avoid the hassle with a custom license that is not approved/verified.

Dominik.

On Sun, Jun 21, 2015 at 12:46 AM, Andreas Beeker <ki...@apache.org> wrote:
> Hi,
>
> I've just changed something in POILogger for #58040 and additionally refactored the various methods to a varags method.
> This works when code gets compiled but fails if only the binary is replaced.
>
> What is our guideline regarding ...?
> - binary compatibility
> - deprecated objects, i.e. org.apache.poi.openxml4j.opc.Package
>
> Nicks posts [1] says:
> "Backwards compatibility - if possible we maintain binary compatibility, if
> not source, and only break things if really needed."
>
> So binary compatibility means our dependencies?
> and "if not source" means, it's ok when user code doesn't need to be changed, but needs to be recompiled?
>
> How about allowing to remove deprecated stuff after 2 years (i.e. ages) after it has been marked deprecated?
>
> Regarding the POILogger - I sometimes wonder, why we need to keep (historical) things which in
> the meantime exist in common. How about replacing POILogger by SLF4J?
> (it seems to be compatible with ASL [2])
>
> Best wishes,
> Andi
>
> [1] http://apache-poi.1045710.n5.nabble.com/Advice-for-new-and-potential-committers-td5718862.html
> [2] http://www.slf4j.org/license.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org