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 - 05:14:05 EST