Mailing-List: contact dev-help@excalibur.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Excalibur Developers List" <dev@excalibur.apache.org>
Date: Tue, 13 Jul 2004 17:49:19 -0400
From: "Michael Nash JGlobal.com" <mnash@jglobal.com>
To: "Excalibur Developers List" <dev@excalibur.apache.org>
Cc: bloritsch@d-haven.org
Subject: Re: Concerns about dependency creep
Message-Id: <20040713174919.3c25c31c@jglobal>
In-Reply-To: <40DC23DB.2050207@d-haven.org>
References: <40DC23DB.2050207@d-haven.org>
Organization: JGlobal
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Berin:

I'd agree that the dependancy creep you describe below is generally a bad thing - especially if it only turns up at runtime, that's far worse!

How can we track this down and (if possible and agreeable to all) remove the dependancy? I assume it's not a straight import if it's not happening at compile-time?

I guess that's a long-winded way of saying "+1" :-)

Mike

On Fri, 25 Jun 2004 09:08:43 -0400
Berin Loritsch <bloritsch@d-haven.org> wrote:

> It appears that Fortress is suffering from dependency creep.  For a
> longer explanation of what I am referring to look at:
> 
> http://www.jroller.com/comments/bloritsch/Weblog/dependency_creep
> 
> Specifically, either Fortress Container IMPL or Fortress Container API
> has dependencies on Commons Logging and Commons Bean Util where it
> didn't use to.  I really have no problems with either of these libraries
> except the fact that if you compile an existing project using the new
> Fortress libraries you will receive no compilation problems--but if you
> run it, you will find that it doesn't work.  That's bad.
> 
> I am sure there is a reason for including these libraries, although I
> missed what it was in the past.  The need to include Commons Logging
> or having Fortress fail baffles me beyond reason.  Fortress already
> has a logging abstraction, so why do we need two in the same system?
> 
> Do you think we can make a case to remove any dependency that can easily
> be done in house?  It just seems like building on sand (a Stefano
> complaint) and I don't particularly like having a bazillion things to
> depend on just to build another framework.
> 
> -- 
> 
> "Programming today is a race between software engineers striving to 
> build bigger and better idiot-proof programs, and the Universe trying to 
> produce bigger and better idiots. So far, the Universe is winning."
>                  - Rich Cook
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
> For additional commands, e-mail: dev-help@excalibur.apache.org
> Apache Excalibur Project -- URL: http://excalibur.apache.org/


-- 
Michael Nash

JGlobal Ltd 
Next-Generation Web Application Development and Open Source Support
http://www.jglobal.com

Bahamas Commerce and Trade
Offshore eCommerce Hosting and Business Services
http://www.bahamascommerce.com


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/