Additionally, smaller pieces means cleaner dependencies, because you can have circular dependencies within a jar, but by separating things out, you force cleaning out such things, which results in better usability. (well, again, if you're using something that disallows circular dependencies, like maven).

Also, smaller code chunks tends to improve testability, because you have smaller independent units of code.

But the big thing, as Paul mentions, is to reduce the volatility of the versions themselves. If hls ships 5.0.9, but all the 3rd party components are linked against 5.0.8, instead of against some blah- api-5.0 which is stable, then you have to wait for the component vendor to update it. I mean you can always do it yourself (which I'm doing in the short term with the redijedi stuff), but in my experience in fortune-500 companies, they have build regulations which do not allow such things. Only things that have been tested and put into a local "safe" repository can be used, and making six updates to that would cause bureaucratic hell and be problematic for a deadline, vs., say, just updating the implementation jar or the "official" components jar.

Or simply - reduce the breadth of the impact of change.

Christian.

On 23-Oct-07, at 8:47 AM, Paul Cooley wrote:

As long as maven is used to handle the dependencies for you, this is
actually the better way to do it. Reason being, if there's a bugfix in say a component, it doesn't require the entire stack to be rebuilt. Instead,
interim releases of certain modules can be made for rapid
development/release rather than having to build/release the entire stack to address critical bug fixes in one module. Think microsoft service pack and
you get an idea of the kind of hell that can result.

Just my 2 cents.

On 10/23/07, Chris Lewis <[EMAIL PROTECTED]> wrote:

A user's perspective: I /loathe/ dependency hell of all incarnations - jar/dll/rpm whatever. They make life difficult and far from enjoyable. I don't know that this conversation is leading down the path of creating
this kind of situation, but I want to preemptively speak against
anything that smells of it. Ease of use, in my opinion, as difficult and worthy a goal as software usability. As long as remains an obvious goal
on the forefront, great, no problem.

sincerely,
chris

Fernando Padilla wrote:
I will support this idea.

specially if components are broken up too, base components, html
components, etc.

Christian Gruber wrote:

Hi,

  I realize that -annotations has already been converted, but I'm
wondering if it wouldn't help reuse and modularity to take the raw APIs (key interfaces) and some other bits, including components and separate
it from core.  This came from looking at the redijedi stuff and how
it's
linked to 5.0.5. It seems to me that there's some raw API stuff that won't change between minor versions (now) and that 3rd party component
libraries or other things would be able to depend on those without
having to re-set or nudge versions numbers every time a bugfix release
is made.

Christian.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







--
Gotta find my destiny, before it gets too late.-- Ian Curtis


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to