incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Merge of ODFDOM DOC package and Simple API
Date Fri, 30 Sep 2011 13:11:25 GMT
On Fri, Sep 30, 2011 at 8:38 AM, Yegor Kozlov <yegor.kozlov@dinom.ru> wrote:
> On Fri, Sep 30, 2011 at 4:29 PM, Rob Weir <robweir@apache.org> wrote:
>> On Fri, Sep 30, 2011 at 4:48 AM, Devin Han <devinhan@apache.org> 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:
>>>  https://issues.apache.org/jira/browse/ODFTOOLKIT-49 (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
>> components.
>>
>> 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?
>>
>
> I plan to play with the code on weekend will give my feedback after that.
>

Thanks!  No rush.  It is a Chinese national holiday next week, so
Daisy and Devin will be out.  I'm on vacation next week.  And Svante
said he has a priority report he is working on for the OASIS ODF
Technical Committee.  So it sounds like a quiet week for this project
next week.

-Rob

>> 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?
>>
>
> The breakage of the Simple API becomes a release blocker. I'm for
> fixing ODFDOM , but if it is hard then revert is OK too.
>
> Yegor
>
>> 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.
>>
>> -Rob
>>
>>
>>
>> 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 <devinhan@apache.org>
>>>
>>>> +1
>>>> OK, I agree for a snapshot release with no functional code change.
>>>>
>>>> 2011/9/29 Dennis E. Hamilton <dennis.hamilton@acm.org>
>>>>
>>>> +1 (non-binding [;<).
>>>>>
>>>>> -----Original Message-----
>>>>> From: Svante Schubert [mailto:svante.schubert@gmail.com]
>>>>> Sent: Wednesday, September 28, 2011 15:22
>>>>> To: odf-dev@incubator.apache.org
>>>>> 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
>>>
>>
>

Mime
View raw message