Hi Brian,

On Tue, Aug 23, 2011 at 11:04 AM, Brian Topping <[email protected]> wrote:
> I agree with Martin's POV here, but with the additional caveat that API 
> changes and module changes are the same thing, they break backwards 
> compatibility and should be treated the same. Micro releases are bugfix 
> releases.  Plain and simple.

What is bad with the module changes or more correctly said module additions ?
>From my POV it is just a new jar in the distro. For most of the users
there is no change until they decide to deploy in OSGi container or to
use Weld.

>
> Cleaning up the module structure so *anything* can be added should be a 
> priority.  OSGi holds very little difference from the transition from C to 
> C++ for people who were there for that.  It was a PITA to do it, but once it 
> was done, life got so much better.
Anything *can* be added. Just the timing is not that good ATM.
>
> If 1.6 is going to happen fast, holding off on weld until then is no big 
> deal.  If weld goes in to 1.5, it just looks like "business as usual" and the 
> risk that OSGi never makes it in continues to grow.  If OSGi never makes it 
> in, big waste of time, would have been easier to start anew today instead of 
> play "kick the can" with everyone and end up empty handed.  I don't want any 
> regrets, that just leads to frowns.
>
> Small releases, early and often.
>
> On Aug 23, 2011, at 3:46 AM, Martin Grigorov wrote:
>
>> -1 to add Weld now
>>
>> +1 to add Weld and OSGi in 1.5.(1|2) if they don't need API changes to
>> be able to work. If they need API changes then they'll have to wait
>> for 1.6.
>> I also hope 1.6.0 will need less time than 1.4->1.5.
>>
>> I'll revert WICKET-3976 soon.
>>
>> On Tue, Aug 23, 2011 at 10:37 AM, Igor Vaynberg <[email protected]> 
>> wrote:
>>> bleh, this is turning into another prolonged discussion....
>>>
>>> why dont we just do this...release 1.5 and call it a day. weld can
>>> come in as a 1.5.1 or 1.5.2 addition - it doesnt touch any core code.
>>> osgi can wait for 1.6 where it can be implemented properly.
>>>
>>> i am changing my vote to -1 to include weld and -1 to include osgi.
>>> they all came in too late for 1.5 and i think i would rather push it
>>> out and worry about these things later.
>>>
>>> martin, revert the pom change you made for the osgi issue and i will
>>> build rc6 tomorrow. i think it has a good chance to become 1.5.0.
>>>
>>> -igor
>>>
>>> On Tue, Aug 23, 2011 at 12:23 AM, Brian Topping <[email protected]> 
>>> wrote:
>>>> News flash:
>>>>
>>>> If you're going to include OSGi, go ahead and add Weld.  They are equally 
>>>> important.  Maybe not to you, but to some of us.
>>>>
>>>> Wicket 1.5 is not release candidate.  Features do not get added to release 
>>>> candidates.  Features do not even get added to alpha versions.  Read the 
>>>> Release Lifecycle 101 at 
>>>> http://en.wikipedia.org/wiki/Software_release_life_cycle.
>>>>
>>>> If Wicket is not RC, then the features Wicket needs to be a viable release 
>>>> should be added.  OSGi is one of them, regardless of whether it's one of 
>>>> your personal favorites or not (and your opinions are pretty clear in the 
>>>> public record).
>>>>
>>>> I pushed for OSGi in 1.5 knowing full well that the RC moniker was a 
>>>> charade and that I am just as uneasy of waiting for it as you guys appear 
>>>> to be uneasy of waiting for Weld integration.
>>>>
>>>> If 1.5 is released, the next opportunity to add features that would cause 
>>>> the modules to be restructured is 1.6, not 1.5.1.
>>>>
>>>> The reality is the RC fantasy should be aborted and the cycle set back to 
>>>> "development mode" so features like Weld can be added and the *proper* 
>>>> work done to add OSGi -- both with necessary module restructurings.
>>>>
>>>> Then when that is done, freeze features and start fixing bugs.  That's 
>>>> called "alpha".  Etc etc.
>>>>
>>>> I'll be clear, I think the Apache process has failed on Wicket and if 
>>>> preferential treatment is given to Weld without proper OSGi support also 
>>>> going in, it's going to be an unmitigated disaster that is worthy of a 
>>>> review by the Apache board.  It may be worthy of a review in any event.
>>>>
>>>> Back to the regularly scheduled programming....
>>>>
>>>> On Aug 22, 2011, at 6:11 PM, Martijn Dashorst wrote:
>>>>
>>>>> Wicket Weld is a really nice to have for wicket 1.5 and would increase
>>>>> the importance of our release pretty considerably. The issue with
>>>>> wicket-weld is that it requires java 6, and it is late in the release
>>>>> game for 1.5 final.
>>>>>
>>>>> We have experience with building mixed java releases (see our 1.3
>>>>> history), though the build process was not pretty.
>>>>>
>>>>> In order to enable wicket-weld we need to do the following IMO:
>>>>> - create java5 and java6 modules in trunk, each configured with the
>>>>> correct java version
>>>>> - commit wicket-weld as a submodule for the java 6 module
>>>>> - move wicket-examples to java 6 module
>>>>> - move all other wicket modules to the java 5 module
>>>>> - fix the wicket parent pom to have a java 5 profile and a java 6 profile
>>>>> - fix the build script to run different maven setups utilizing a java
>>>>> 5 home directory and a java 6 home directory
>>>>> - fix the build script to run java 5 compilation first and then only
>>>>> java 6 for packaging (without clean) this will keep the java 5
>>>>> compiled classes and re-package them during the java 6 run
>>>>>
>>>>> This is some work, and as I said, we are late in the release game. If
>>>>> 1.5 final was this week I wouldn't propose to do this, but perhaps do
>>>>> it in 1.5.1 or 1.5.2. However, since 1.5-rc6 is still not complete we
>>>>> might do this now. I'm open to suggestions on whether to include
>>>>> wicket-weld or not.
>>>>>
>>>>> Martijn
>>>>>
>>>>> --
>>>>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

Reply via email to