Re: dependency changes

From: Henrique Prange (hprang..mail.com)
Date: Mon Nov 10 2008 - 17:08:49 EST

  • Next message: Chuck Hill: "Re: dependency changes"

    Hi Mike,

    Mike Schrag wrote:
    >>> Which would require jar-based frameworks, but jar-based frameworks
    >>> don't support nested jars.
    >>
    >> Why do you need a nested jar? If you have a description of transitive
    >> dependencies, couldn't you just download everything required to build
    >> the project and put it together? Do you have a use case where this
    >> solution doesn't work?
    > An issue of perspective, I suppose ... There's something nice about
    > being able to distribute a framework that has its dependencies packaged
    > nicely inside of it. I recognize there are definitely potential
    > conflict issues with this, though.
    >

    Sure. I agree with you. I've seen a discussion in another mailing list
    about the same subject (separated jars or all-in-one). Most people seems
    to prefer the one package solution, even knowing about the possible
    problems it causes. I believe those people are not familiar with
    dependency management mechanisms. But I agree we should provide a
    solution that support both.

    >>> Q has a WOBootstrap that does, but we're still talking about changing
    >>> the way a large number of people deploy their apps. Not to mention
    >>> we have to then integrate Ivy with WOLips, not to mention it has to
    >>> work in Eclipse also.
    >>
    >> What about IvyDE [2]? Maybe it can solve almost all of your problems.
    >> :) (Again, I've never used this tool).
    > :) Always just a dance -- balancing wheel reinvention against nice
    > integration. It's often really hard to integrate these separate tools
    > in effectively. Our HTML editor is a great example of this. There are
    > like 10 HTML editor plugins for Eclipse, but it wasn't until we slurped
    > it in and hacked the hell out of it that we got (well, are getting) an
    > experience that doesn't suck. I'm also always mindful of new people
    > coming to the platform. Eclipse plugin management is a very confusing
    > thing for people, and to the extent that we can minimize dependencies of
    > the tools, I think we end up with a smoother deployment process. I
    > appreciate the VERY fine line between this and madness, though.
    >

    Sure. Keep it simple is the rule. Often, reuse something doesn't mean
    less work. I agree with you in this point too. Sometimes it is easier to
    make our own solution and solve only the problems that must be solved.

    >>> That and I'm not even really sold on jar frameworks, though the
    >>> better split install build.xml makes it slightly better I guess. I
    >>> still come back to "make it easy for people" .... Ivy's certainly an
    >>> option, and I'm not at all
    >>> ruling it out, but I'm always sort of skeptical of the final result
    >>> of these things actually being a better experience for endusers of
    >>> the system.
    >>
    >> I'm not trying to sell Ivy or Maven Ant Tasks, because I have never
    >> used any of them. But I'm a long time Maven user. I cannot imagine how
    >> people can develop nowadays without a good tool for dependency
    >> management. And when I say dependency management, I mean all
    >> dependencies of a project. Not only WO frameworks. If I was an Ant
    >> user, I'll prefer to have a complete solution for the dependency
    >> management problem, even if I have some trouble to learn it in the
    >> beginning.
    > The problem is that all these tools suck ... The ramp up time is totally
    > obnoxious. I feel like I'm a reasonably smart dude, and every time
    > people start explaining Maven, my eyes glaze over. I'm sure once you
    > get over the hump it does its job quite well, but WO itself is so
    > complicated that I think we really need to focus on making the "zero
    > state" of the tools help the process, and telling people they need to
    > understand Ivy or Maven dependency management in order to deploy their
    > apps is this huge uphill battle we shove into the experience. I don't
    > have a good answer to all these issues .... I mean, I really don't want
    > to reinvent Maven (or Ivy), but on the flip side, I want WebObjects
    > developers to both be able to start working relatively easily as well as
    > support power users. Oh well ...
    >

    I don't want to create problems neither for you nor for WO users. And
    I'm not saying using those tools will be the best way. But I still think
    it is worth evaluating existing solutions. "Forcing" people to use a
    tool is not evil if we provide good reasons (and good integration).
    Someone chose Eclipse as IDE, Ant as the build tool, Java as programming
    language.. And nobody is complain about those decisions.

    For those who don't want to make their environment complex, there is
    always the simplified option: "you can still develop, but you have to
    take care of dependencies and transitive dependencies manually"... This
    is exactly how things work now. And you have already provided a way to
    reduce the gap between dependencies declared for development and those
    really packaged on deployment.

    Sorry if I'm bothering you with this subject... I promise this is the
    last e-mail. :)

    Cheers,

    Henrique



    This archive was generated by hypermail 2.0.0 : Mon Nov 10 2008 - 17:10:01 EST