Re: Dependeny on javax.swing

I've been thinking myself for some time now that I would like to make some non-BWC changes myself to the 2.3 line; i.e. upgrade ancient dependencies (JDOM beta, anyone?). I wanted to do that for years, but 2.4 does stand in the way. Doing a bunch of non-BWC changes to 2.3 codebase, releasing that as 2.4, and pushing current SVN head to be "2.5" sounds viable to me. I'd be willing to expend effort on getting that done, and seeing it gets through to completion.

Again, I'm imminent for a leave on a vacation (wife is looking cross at me for not helping her with packing but instead typing this :-) ), so let's pick this up next week.

Attila.

On 2009.12.28., at 18:10, Brian Pontarelli wrote:

> 
> I checked out the code and indeed this is painful because TreePath and other classes in Swing are publicly available in FM. Unfortunately this makes it very difficult to remove the dependency without breaking someone. Seems like it makes sense  as a first step to deprecate all the methods in 2.3 that return Swing classes. Next, I would probably re-order the releases quite a bit and get a release out in the short-term that works on GAE and start forcing folks to upgrade. I personally would stop most 2.3 development and branch 2.3 for any major fixes. Then I would change the 2.4 branch to 2.5 or 3.0. Last, I would copy 2.3 into a new 2.4 branch and fix things there and release 2.4.0.
> 
> The upgrade for most people from 2.3 to 2.4 would be completely unnoticeable and only a select few using the Swing APIs would need to make some minor modifications (if you retain the general contracts inside a new class). You could then keep chugging away at 3.0 after merging the 2.4 changes into that branch.
> 
> Anyways, something along those lines seems to be the simplest method of accelerating GAE support without waiting-for/battling-with Google and still maintaining 2.3 compatibility. This forces people to upgrade to 2.4 for GAE apps, but in most cases, that would simply be a new JAR and no re-compilation or code changes.
> 
> -bp
> 
> 
> 
> 
> On Dec 28, 2009, at 9:32 AM, Daniel Dekany wrote:
> 
>> Monday, December 28, 2009, 4:37:26 PM, Jeremy Chone wrote:
>> 
>>> I have seen that 2.4 faith is uncertain, but this could be a good
>>> milestone to break backward compatibility. 
>> 
>> You mean we should introduce this BC breaking in what is now called
>> FreeMarker 2.4? Unfortunately 2.4 is non-BC on several other ways, so
>> even if it would be ready for release right now, we still had to
>> address the issue for the 2.3.x users.
>> 
>>> About the contact in Google, I can definitely introduce someone
>>> from the freemarker team to them, but I do not think I can be an
>>> effective mediator (given my limited understanding of the
>>> internals). Let me know if someone wants an introduction. 
>> 
>> Certainly that will be Attila. He is the one who wrote all the
>> BeansWrapper (reflection) stuff.
>> 
>>> Jeremy,
>>> 
>>> 
>>> On Mon, Dec 28, 2009 at 4:30 AM, Daniel Dekany <[email protected]> wrote:
>>> Monday, December 28, 2009, 12:07:31 PM, Guo Du wrote:
>>> 
>>>> 2009/12/28 Daniel Dekany <[email protected]>:
>>>>>> javax.swing.tree.*, that'd be a start. As I said, something similar
>>> [snip]
>>>>> So can that be worked around in FreeMarker (and of so, with how much
>>>> 
>>>> I have two concern for work around javax.swing.tree.* package reference.
>>> 
>>> Note that above I referred to the reflection issue.
>>> 
>>>> 1. Backword compatibility, we don't want break the stable release
>>>> stream in 2.3.X. Even NORMAL freemarker usecase won't be involved with
>>>> the swing.
>>> 
>>> Since Java language is quite static (which I like in general but these
>>> are the situations where it clearly backfires), the only
>>> backward-compatible work-around I can imagine is to create a separate
>>> release for each FreeMarker version that specifically targets GWE. But
>>> that's not that easy for the *users* as it may sound, as components
>>> that were not written specifically for GWE may pull in "plain"
>>> FreeMarker via automated dependency management (Maven, OSGi, etc.). I
>>> know, at least ideally that can be overridden, but I guess the way we
>>> upset the least number of users is by breaking the backward compatibly
>>> promise in this case, and blame Google.
>>> 
>>>> 2. The simple/safe way to get away from javax.swing.tree.* is to
>>>> duplicate the used classes/interface insides freemarker such as
>>>> freemarker.core.tree. It may have copyright concern to the source
>>>> code.
>>> 
>>> I didn't look into this, but most certainly we will have to re-write
>>> these from scratch, only by looking at the javax.swing Java docs.
>>> 
>>>> P.S. There are only 4 direct reference in freemarker 2.3.15, so not a
>>>> big deal to just copy them to freemarker :)
>>>> ./freemarker/template/Template.java:57:      import javax.swing.tree.TreePath;
>>>> ./freemarker/core/FreeMarkerTree.java:56:   import javax.swing.JTree;
>>>> ./freemarker/core/FreeMarkerTree.java:57:   import
>>>> javax.swing.tree.DefaultTreeModel;
>>>> ./freemarker/core/TemplateElement.java:57: import javax.swing.tree.TreeNode;
>>>> 
>>>> -Guo
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> This SF.Net email is sponsored by the Verizon Developer Community
>>>> Take advantage of Verizon's best-in-class app development support
>>>> A streamlined, 14 day to market process makes app distribution fast and easy
>>>> Join now and get one step closer to millions of Verizon customers
>>>> http://p.sf.net/sfu/verizon-dev2dev
>>>> _______________________________________________
>>>> FreeMarker-user mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/freemarker-user
>>>> 
>>> 
>>> --
>>> Best regards,
>>> Daniel Dekany
>> 
>> -- 
>> Best regards,
>> Daniel Dekany

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev