It is feasible, but then developers would need to know that they need to add this JAR to their classpath. I was thinking we'd just deprecate WTKXSerializer and @WTKX - that way you'll know as soon as you compile that you should upgrade, but at least your app will run.
On Jun 17, 2010, at 10:42 AM, Mike Smorul wrote: > 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 <[email protected]> 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 <[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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >>
