Re: buildtools vs. tools

> At the moment buildtools comes first in the reactor, and there's a reason
> for it - any codestyle checks and resources for the build are made
> available
> _before_ anything else. I'm not sure we can preserve that once it's moved
> under tools, though I haven't tried it.
>
> In addition, scripts need to be updated if this refactoring takes place,
> which is an extra burden I personally wouldn't like to have at the moment.
>
> Andrew
>
> On 6/17/07, andrew cooke <acooke@...> wrote:
>>
>>
>> Would (2) keep dependencies non-cyclic and be a partial solution (with a
>> JIRA for more later)?
>>
>> (I only suggest this because I have been trying recently to think how my
>> own work could improve and one of the things I identified was that I
>> wasn't making enough small refactorings to improve things.  So I'm now
>> looking for examples where that approach might work.)
>>
>> Cheers,
>> Andrew
>>
>> > I'm afraid the real problem is cyclic dependencies. That's why there's
>> > buildtools which has minimum mule dependencies. I wouldn't shake that
>> boat
>> > now, but we can definitely make an effort later. JIRA?
>> >
>> > Andrew
>> >
>> > On 6/17/07, Travis Carlson <tcarlson@...> wrote:
>> >>
>> >> Hi guys,
>> >> I was just looking at the fact that we have both "buildtools" and
>> >> "tools"
>> >> as root-level directories.  This seems a bit messy.  I propose we do
>> one
>> >> of
>> >> the following:
>> >>
>> >>   1. Merge the contents of "buildtools" into "tools" and just exclude
>> >> the
>> >> non-user-facing tools from the distro.
>> >>
>> >>   2. Make 2 subdirectories under "tools": "tools/build" and
>> "tools/user"
>> >>
>> >>   3. Move "buildtools" under "distributions"
>> >>
>> >> Also, shouldn't "mule-assembly-verifier" (and perhaps "bobberplus")
>> go
>> >> under "buildtools" instead of "tools"?
>> >>
>> >> Any opinions?
>> >>
>> >> Travis
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe from this list please visit:
>> >>
>> >>     http://xircles.codehaus.org/manage_email
>> >>
>> >>
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>