For navigating the dependencies you can, in the meantime, use
JadClipse: http://jadclipse.sourceforge.net/
With regards,
Ramon Havermans
On Feb 5, 2009, at 11:13 AM, Jephte CLAIN wrote:
> Anders Peterson a écrit :
>> Lachlan Deck wrote:
>>> On 01/02/2009, at 8:44 PM, Anjo Krank wrote:
>>>> I don't like it.
>>> Well I'm looking for discussion about how to enhance wolips as a
>>> tool in order to make things workable for those not using ant etc
>>> or allowing wolips to just work with legacy projects... without
>>> adding problems to existing projects.
>>>
>>> Certainly I'm not aiming to make things more difficult.
>> Is there no middle ground?
>> I agree with Mike/Anjo/Chuck that supporting endless
>> configurability is not a very good idea. In this case; if I comply
>> and restructure my project layout I lose 8 years of cvs history -
>> not happy about that!
>> How did you decide which project structure to support? To me a WO
>> project is primarily a Java project. I've seen few Java projects
>> with a layout that match Wonder projects. If I create a new blank
>> Java project in eclipse I get a 'src' and a 'bin' folder. Seems
>> natural to me to have a 'lib' folder...
>> Mike said he will support two project layouts - Wonder and Maven.
>> How will this dual layout be supported?
>> Is it possible to let Wonder/Maven define which things need to be
>> configurable, but let individual users do the actual configuration
>> (it could be something that is neither Wonder nor Maven compliant)?
>> Great tools are not characterized by "zero flexibility" but by
>> careful considerations of requirements and trade-offs.
>
> There is also the case where you have frameworks shared between
> several project types: why should the framework modeled after wolips
> way if it has to be used and/or *maintained* elsewhere?
>
> At least for frameworks, I vote for configurability.
> For applications, I agree that conventions wins over configuration.
>
> with regards,
> jephté clain
>
> PS: my current application/project have two webobjects specific
> frameworks, that I changed to match the wolips way, as I have chosen
> wolips over my previous build tools. But it depends also on 6 other
> frameworks that are not webobjects specific. it is a pain to use
> them with wolips. I ended up deploy them and tell wolips to use the
> binary framework. But I would like to tell wolips to use the
> *source* framework, to be able to fix them directly, or navigate the
> dependencies with eclipse.
This archive was generated by hypermail 2.0.0 : Thu Feb 05 2009 - 06:43:52 EST