incubator-wadi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Dudney <bdud...@apache.org>
Subject Re: moving forward...
Date Thu, 05 Jan 2006 14:55:58 GMT
Hi Jules,

On Jan 4, 2006, at 3:42 AM, Jules Gosnell wrote:

>
> So, there seem to be several threads that need discussion and  
> prioritising.
>
> Here is my shot at it,
>
> in order of priority:
>
> 1. Geronimo Integrations (Jules, Jan, Jeff?).
>
> Still top of my list. Geronimo-1.0 is still pending and we still  
> have time to ensure that our Jetty and TC integrations are actually  
> working, preferably with the webapp from a WADI release, worst case  
> scenario, with a specially hacked version of the webapp. If someone  
> d/ls G1.0 and follows the README to wadi.codehaus.org I want them  
> to find enough doc and code to easily run up the wadi-webapp and  
> run through the 'Getting Started' doc. This has been my priority  
> since well before ApacheCon and will remain so until it is done.
>
> Jeff is convinced that this will involve no code changes and could  
> run in tandem with (2). I am not and will not - sorry Jeff. Jeff  
> also seems to have issues with making his ?working? integration  
> available to the rest of us  (see his mail). If that is the case,  
> then I/we will just have to reinvent the wheel. I hope that this  
> will not be the case.
>
>

I just finished chatting with Jan and I think the problem is simply  
an additional dependency that crept in after I made the list of  
dependencies. I'll post again once I have confirmation that we have  
success with the new list of dependent jars (the additional jar file  
is backport-util-concurrent-2.0_01_pd.jar if you are dying to try  
now :).

> 2. Project migration (Jules (codebase), Bill (website), ...)
>
> See my mails of the 23rd and 24th Dec. Probably more bits and  
> pieces to discuss here.
>
>

Web site is complete and even a bit simplified (to build that is)  
with improvements in Maven 2.0.1 and the updated surefire, javadoc  
and site plugins. As we discussed before the break the codehaus site  
is hosed and since I did not know how to deploy there I put our site  
on the incubator space (http://incubator.apache.org/wadi).

> 3. Configuration discussions/actions (Jules, Greg, Jan, Jeff, ...)
>
> I will respond to this thread today... It will need more space than  
> is available here.
>
>
> 3. AMQ and AC upgrades (Bill)
>
> Bill - I've looked at AC now and see that they have repackaged it.  
> So, you are right, the changes are incompatible and WADI has no  
> further layer of abstraction behind which to retreat. I suggest  
> that we hold off on the upgrade until we have (1) and (2) done and  
> Geronimo has moved up to these versions. At that point, we may then  
> move our code onto the new AC/AMQ platform. For the time being, I  
> think the best thing would be to identify the top and bottom  
> versions which encapsulate your changes and generate a patch, to be  
> applied when these constraints are fulfilled (or you could take a  
> branch, once we have migrated - but then you will be responsible  
> for keeping it up to date until it can be merged). How does that  
> sound ?
>

Everything except 'I'm responsible' sounds great :-)

 From what I recall with the AMQ & G teams the thinking is the sooner  
they can move to  AMQ 4 the better. I'll check around again for  
timeframes.

Any thoughts on additional work we should/need to do on the AMQ  
integration with the 3.2 code? Seems that things work now with tcp://  
instead of peer:// so we are good to go with the 3.2 code base now  
right? IOW - you have worked around all the outstanding issues in 3.2  
and I don't need to try to come up with any other workarounds right?

Agreed that we should wait on at least (2) for sure, that is one of  
the reasons I'm so antsy to get our code base in SVN.

On another note - we will likely have to have a branch of WADI that  
supports G 1.0 - that branch will never get the AMQ 4.0 changes  
applied anyway. I think this is another great reason to move to SVN  
ASAP (even if we can't verify that everything we want working is  
working). Trying to manage all this in CVS is a pain in the neck and  
will all have to be redone as soon as we make the move to SVN anyway.  
I have done lots of SVN stuff with myfaces and would be happy to  
manage our SVN stuff once we make the move.

I know the lack of repeatability of Geroniomo working bits is  
disconcerting but IMO managing getting everything working properly  
again would be much easier in SVN, esp the branch and G 1.0 branch vs  
G trunk.

> AOB ?
>
> In terms of timeline, things will take as long as they take. The  
> G1.0 integration was meant to take 1/2 an hour and is still  
> ongoing, so I'm not committing to any deadlines.
>
> I'm finding that having to debate what I consider insignificant  
> issues at great length on this list is really detracting from the  
> time that I can spend actually working on WADI. I'm new at the  
> business of being involved in a project with this many people on  
> board, so I am not sure how to resolve this. I am hoping that  
> things will calm down when (2) is completed. I apologise for any  
> frustration that may have 'leaked' into my mails. Now that the  
> 'history' thread appears to be drawing to a close, I look forward  
> to more productive times ahead.
>

I don't recall seeing anything from Bruce on moving things over to  
SVN, from what I recall we had consensus on moving the history it was  
merely a matter of the work of kicking off the migration.

Bruce what is the scoop on that? Am I wrong, if not is it possible to  
get an ETA on getting the history into SVN?

>
> Jules
>
> -- 
>
> "Open Source is a self-assembling organism. You dangle a piece of
> string into a super-saturated solution and a whole operating-system
> crystallises out around it."
>
> /**********************************
> * Jules Gosnell
> * Partner
> * Core Developers Network (Europe)
> *
> *    www.coredevelopers.net
> *
> * Open Source Training & Support.
> **********************************/
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message