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