The Artima Developer Community
Sponsored Link

Weblogs Forum
Deployable Units and Layers

15 replies on 2 pages. Most recent reply: Jan 14, 2005 10:15 PM by Dan Perl

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 15 replies on 2 pages [ « | 1 2 ]
Dan Perl

Posts: 28
Nickname: nanov
Registered: Sep, 2004

Re: Deployable Units and Layers Posted: Jan 14, 2005 10:15 PM
Reply to this message Reply
> Users don't care about the layering design, whether it be
> a single unit or multiple. They care about how quickly you
> can make changes correctly, and then deliver those
> changes.

What I hear you saying is: users do not care how many deployment units there are and what's good for the developer is good also for the user. I disagree with both.

> Today, I'm developing mostly Java web applications. With
> Java web apps, you'll still only deploy a single .war or
> .ear file that contains your .jar files.

I know very little about web applications but the way I see it the .war or .ear files are your deployment units and you do have only one such unit.

> It's nice to know
> that if your app is composed of 10 different .jars, and
> you only change 1, when a new bug surfaces you'll know in
> which .jar file the bug exists.

You should know what the changes are at code level and the jar level would not matter anymore. In the extreme case, if you have only one change then you should know where that change is in the code; the deployment structure does not add any information.

> And while you may believe today that the
> same combination of versions are used in all the
> deployments, it may not be that way tomorrow. Instead,
> just assemble your application from the appropriate
> version of separately deployable units (if they never
> change, then so be it).

You don't know what will be tomorrow. When tomorrow comes and you see that you need the change, you refactor again and you break the unit apart. Isn't that what refactoring is about and isn't that the agile way?

> Even back when I was developing mostly client/server
> applications, where we would deploy a single executable
> with multiple other libraries, keeping these libraries
> small and focused was very useful. It helped promote the
> "ilities", and we took a great deal of comfort in knowing
> that when we patched one of these smaller libraries, we
> were only deploying the minimal amount necessary. If a
> problem surfaced after the deploy, we'd know the problem
> was due to the new version of the library. Had we deployed
> one huge unit, we could not be certain that was the case.
> Additionally, we'd be required to deploy that one huge
> unit for even the smallest of changes.

You should just know what changes are in the patch and where they are in the code. Those changes are then the suspects, no matter whether they are in a smaller or a larger library. I don't see the point that having a smaller library was adding any information.

What is the problem with a "huge" deployment unit? That it takes one minute to download it off the net instead of five seconds? Or it takes the whole space of a CD instead of just a fraction? If it takes an hour to download it or it takes more than one DVD, then I see the point of breaking it into smaller units.

Flat View: This topic has 15 replies on 2 pages [ « | 1  2 ]
Topic: Java Generics: Don't Repeat Yourself Previous Topic   Next Topic Topic: Inheriting from Template Parameters: A New Pattern?

Sponsored Links


Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use