ant elder wrote:
On Feb 16, 2008 12:56 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:

<snip>

For now I have to make a copy of the contribution code without this
stuff to make progress. Could the people who worked on this classloading
code please help clean it up and move it out of the core contribution
modules?


This doesn't feel good to me, we've had so much trouble in the past with
code forks, isn't there some way to work with whats there instead of just
starting afresh with your own version?

We should not confuse nonlinear development and forking, or confuse starting afresh and copying existing code and refactoring it to reuse it without some of its dependencies or coupling with classloading.

What do you intend to do with the
"copy of the contribution code"?  Is the copy going to be functionally
equivalent to whats there at the moment? What is it that you're trying to
do, is there some specific functionality you're trying to add or enhance?

   ...ant


I'm trying to implement the contribution workspace described in [1]. I need to reuse some of the logic in contribution-impl but that code is coupling reading/processing/classloading/resolving, which I need to decouple and provide as separate functions.

If there's no objection I'm planning to commit an implementation of the contribution workspace described in [1] to trunk in the next two days, implemented with a mix of code copied from contribution-impl and new code.

If you have objections I'll do it outside of trunk and ask the community to review it later. However, I'd prefer to do this work in trunk as it has already been discussed on this list and trunk is where new development happens.

[1] http://marc.info/?l=tuscany-dev&m=120202180130866
--
Jean-Sebastien

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to