Yeah, OK. The main problem is that many developers aren't going to read the
release notes, and they won't know why their app suddenly doesn't compile.
There's an easy fix, but it would be good to avoid that initial frustration if
possible.
Let me prototype it and see how it looks.
On Jun 17, 2010, at 9:49 AM, Noel Grandin wrote:
> Hi
>
> It's the difference between
> (a) having to do a big-bang conversion when switching to Pivot2.0
> and
> (b) being able to get things running quickly, and then make the updates
> piece-meal.
>
> Personally, I have no real problem either way, because I don't have any
> WTKX files to convert of my own.
>
> I just think gradual upgrade paths are a good habit to get into.
> I personally hate it when I upgrade one of my dependencies and have to
> spend ages just getting the thing compiling before I can even start testing.
>
> Just my 2c,
> Noel Grandin
>
> Greg Brown wrote:
>> I understand the desire to provide a more "backwards-compatible" solution.
>> However, I see two main issues with it:
>>
>> 1) As you noted, it is still a bit of a hack, even if we do something along
>> the lines of what you suggest.
>>
>> 2) It provides an incentive for developers to not update their code to use
>> the new conventions. At some point, we'll need to drop the backwards
>> compatibility and they will have to upgrade - I don't think it really makes
>> a difference if we do that for version 2.0 or version 2.1.
>>
>> I created an Ant script yesterday that will perform the conversion. It's
>> really easy to run - just point it at the directory you want to update. I
>> used it to convert the tests and tutorials projects and the only issue I ran
>> into was how to bulk-add the new .bxml files to SVN. However, the one-line
>> shell command Mike S. provided took care of that:
>>
>>
>>> find ./ -name \*.bxml -exec svn add {} \;
>>>
>> G
>>
>> On Jun 17, 2010, at 3:30 AM, Noel Grandin wrote:
>>
>>
>>> Hi
>>>
>>> I had an idea while out cycling yesterday.
>>> How about we add code that looks something like this:
>>>
>>> for (java.lang.annotation.Annotation ann :
>>> field.getAnnotations()) {
>>> if
>>> (ann.annotationType().getName().equals("org.apache.pivot.wtkx.WTKX")) {
>>> ....process as if we hit the BXML annotation...
>>> }
>>> }
>>>
>>> It's a bit of a hack, but it will allow BeanSerializer to decode "old"
>>> files while not having an explicit reference to the WTKX annotation.
>>>
>>> Then we can mark WTKX as deprecated and give people some grace to port
>>> their files.
>>>
>>> Regards, Noel.
>>>
>>> Greg Brown wrote:
>>>
>>>> That's the problem - we can't easily support backwards compatibility. I
>>>> had originally hoped to have WTKXSerializer extend BeanSerializer in Pivot
>>>> 1.6, and then drop WTKXSerializer in 2.0. However, we can't do that with
>>>> @WTKX/@BXML, because annotations can't inherit. So, we're kind of stuck
>>>> with an all-or-nothing approach, unless we introduce a cross-project
>>>> dependency such that BeanSerializer also looks for WTKX annotations, which
>>>> I really don't want to do. That is why I am suggesting that we go to
>>>> version 2.0.
>>>>
>>>> I was thinking that we could provide a script that will do a
>>>> search/replace/rename so developers don't need to do this manually. That
>>>> should at least make the transition a little easier.
>>>>
>>>> On Jun 15, 2010, at 3:53 AM, Noel Grandin wrote:
>>>>
>>>>
>>>>
>>>>> Sure, but surely we can provide aliases for those things internally so
>>>>> existing files continue to work?
>>>>> Maybe with a runtime warning to System.out so people know that they need
>>>>> to upgrade at some point.
>>>>>
>>>>> It just seems a little harsh to dump that amount of work on people when
>>>>> we can reasonably easily provide a gradual upgrade path.
>>>>>
>>>>> -- Noel
>>>>>
>>>>> Greg Brown wrote:
>>>>>
>>>>>
>>>>>> Files with a .wtkx extension will still work fine. However, the "wtkx"
>>>>>> namespace prefix will change to "bxml", the annotation will change to
>>>>>> @BXML, and the serializer will change to BeanSerializer, so for
>>>>>> consistency I think we'd want to recommend changing the file extension
>>>>>> as well.
>>>>>> Greg
>>>>>>
>>>>>>
>>>>>> On Jun 14, 2010, at 4:52 PM, Noel Grandin wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> I don't have a problem with the version numbering, but is there any
>>>>>>> reason why you can't continue to support the WTKX extension for
>>>>>>> backwards compatibility?
>>>>>>>
>>>>>>> -- Noel
>>>>>>>
>>>>>>> On Mon, Jun 14, 2010 at 02:13, Greg Brown <[email protected]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I'd really like to refactor WTKXSerializer to BeanSerializer and move
>>>>>>>> it to Pivot Core for the next release. However, I think this change is
>>>>>>>> too disruptive for the 1.x line. As a developer, I don't think I would
>>>>>>>> be too pleased to discover that I need to update all of my WTKX files
>>>>>>>> to BXML when migrating from Pivot 1.5 to Pivot 1.6. As a result, I'd
>>>>>>>> like to suggest that the next major version of Pivot be 2.0.
>>>>>>>>
>>>>>>>> We currently have Pivot 1.5.1 in the pipeline and can do additional
>>>>>>>> point releases for 1.5 as needed. We'll reshuffle the items currently
>>>>>>>> assigned to 1.6 and 2.0 into 2.0, 2.1, etc. as appropriate. Any
>>>>>>>> objections?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Greg
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
