Would it be feasible to release a pivot-compat.jar that could include
support for older wtkx files while still making it pretty clear this
is not standard?
On Thu, Jun 17, 2010 at 10:35 AM, Greg Brown <gkbr...@mac.com> wrote:
> 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 <gkbr...@mac.com> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
