Re: WOLips Development prefs

From: Ramon Havermans (ramon.centri..mail.com)
Date: Thu Feb 05 2009 - 06:42:56 EST

  • Next message: Mike Schrag: "Re: WOLips Development prefs"

    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