On Nov 10, 2008, at 2:08 PM, Henrique Prange wrote:
> 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.
Actually... I recall a LOT of complaints about all three of those
decisions.
Chuck
> 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
>
>
-- Chuck Hill Senior Consultant / VP DevelopmentPractical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects
This archive was generated by hypermail 2.0.0 : Mon Nov 10 2008 - 17:15:03 EST