incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Merge of ODFDOM DOC package and Simple API
Date Fri, 30 Sep 2011 12:29:05 GMT
On Fri, Sep 30, 2011 at 4:48 AM, Devin Han <> wrote:
> I try to add @Deprecated Annotation to the ODFDOM Doc Layer classes. The
> question is that we will just re-release ODFDOM 0.8.7.  If I add the
> annotation based on the newest trunk that means we will release a new
> version different from ODFDOM 0.8.7 and the adoption work must do for
> Simple API caused by this issue:
> (ODFDOM has moved the
> style access methods from the package layer OdfFileDom to OdfStylesDom and
> automatic style access to OdfStylesDom & OdfContentDom after ODFDOM 0.8.7)
> which I have mentioned in other thread.
> What should we do?

I think we want to start working like one project, with one toolkit,
with one build.

This has some consequences:

1) We need to have a top-level builds script or POM that builds the
entire release from the trunk.

2) Simple API, Validator and XSLT Runner should be compiling against
the current trunk version of ODFDOM.  No more using an old 0.8.7 JAR.

3) If you make a change in one component that breaks another
component, then you've broken the build.  We one project, with one
toolkit, with one build.

4) To avoid breaking the build, we need to be compiling and running
the unit tests on all components, not just the one we are currently
working on.  If the code you change in ODFDOM breaks the Validator,
then you should not check in your changes until you've fixed.  Or, for
larger changes, that break a lot of code, we should discuss on odf-dev
list first, and coordinate on how we work together to update the other

The current build breakage occurred before we came to Apache, before
we started thinking of "one project, with one toolkit, with one
build".  No one is too blame.  It was acceptable before.  But now it
is a problem.

What can we do?

1) What is the scope of the breakage?  Is it just Simple API?  Or do
any of the other dependent components fail to compile against the
trunk ODFDOM?

2) What is the impact on the user's code?  Will the ODFDOM changes break them?

3) How much effort will it be to update the Simple API so it works
with trunk version of ODFDOM?

If it is possible to update the Simple API, I think that is the best
way forward.  The alternative would be to revert ODFDOM back to before
these changes were made.


I think adding @deprecated is best when we can point the user to an
alternative function to use.  Otherwise it is not very useful.

> 2011/9/29 Devin Han <>
>> +1
>> OK, I agree for a snapshot release with no functional code change.
>> 2011/9/29 Dennis E. Hamilton <>
>> +1 (non-binding [;<).
>>> -----Original Message-----
>>> From: Svante Schubert []
>>> Sent: Wednesday, September 28, 2011 15:22
>>> To:
>>> Subject: Re: Merge of ODFDOM DOC package and Simple API
>>> Am 28.09.2011 17:55, schrieb Rob Weir:
>>> [ ... ]
>>> > Could we mark the DOC API's as "deprecated" in our initial release,
>>> > and point to the replacements in the Simple API?  We could do that in
>>> > the JavaDoc.  That will give users the opportunity to migrate, but we
>>> > don't break their code immediately.  Then we can remove the DOC API in
>>> > a future release.
>>> >
>>> > Would that work?
>>> >
>>> +1
>>> We might make the initial release a no functional code change snapshot
>>> release.
>>> For us to proof we are able to deliver and sign the users we have
>>> continued here at Apache.
>> --
>> -Devin
> --
> -Devin

View raw message