Berin Loritsch wrote:
Stephen McConnell wrote:Peter Donald wrote:On Tue, 11 Feb 2003 16:06, Berin Loritsch wrote:I agree. The current packaging complicates life if you trying to construct
I have improved the framework build some, so that the announcements are
built again. The changes are also back in. I want to provide ample
time for anyone to bring up issues with the build. PLEASE, find any and
all issues and bring them up now--no matter how minor.
I don't recall whether we have separated out impl and interfaces yet. At bare minimum we have to be able to have all xalan/xerces/logkit/log4j/etc classes in separate jars
clean classloader hierachies (you end up duplicating the framework
jar on both internal and external loaders because the framework
classes have implementation dependencies - e.g. use of AvalonFormatter
requires LogKit in the classloader hierachy at or above AvalonFormatter
which means that you canot share the framework jar).
How do others feel about getting this in place now? If we are going to
do it we kind of need to to do ASAP otherwise we should put it down as
an action item for the subseequent release.
The thing is that doing the separation in A4 would cause more problems
than it would solve. Consider the mess we have with "soft" deprecation
already. Now compound that with having to deprecate all the current
implementations and point others to where they are newly implemented.
It is a logistical nightmare.
As I understand things - this is simply a question of breaking out the implementation classes that have strong dependencies and putting them into a separate jar file. The impact on users is to include two jar files instead of one (although an combined jar is still a possible option). This has nothing to do with deprecation (soft or otherwise). I really don't follow your reasoning on this.
Can you explain your concerns more fully?
Already, Cocoon had problems with our
zealous deprecation of the component.* package. Forcing all our users
to change package names just for the sake of separation of
implementation and interface without a major version change will cause
more Public Relations (PR) damage than solving technical problems.
Nobody is suggesting any package name change. What is being suggested is the separation of classes that have strong implementation dependencies from those that are self contained within the framework. In my earlier reply I presented an example - the AvalonFormatter. This is an example of a class that has a strong dependency on LogKit. The existence of this class in the framework creates a strong dependency on LogKit. The suggestion is that such "implementation" classes be moved to an "implementation jar file that can coexist along side a client framework jar file.
The reality is that Merlin and Phoenix are doing more things with the classloaders and other detailed things that most programmers don't delve into. The problems they face aren't the problems the majority of us face.
This is where things get dangerous.
Your putting forward an assumption that may be true in your environment - but is not true in my environment. Your positioning yourself as representing a majority and delegating the "minority-view" to anyone more aligned to the Phoenix/Merlin view of management (a.k.a. != your view). You came up with similar justification on the LogKit release as to why things should not change - and that lead nowhere. Maybe we should avoid this style of rationalization and instead focus on the assumption that the priorities and interests of everyone here are equal?
I think we need to step back - throw away the notion that there is a right point of view - and think about this in terms of the "real" issues. The real issue is "do-we-want-to-do-this-now" as opposed to "doing-it-later". The answer to that question is independent of the "world-view". It is dependent on the priorities that we the commiters have. I can confirm that the current structure of the framework jar file has caused me problems. I'm guessing that I'm probably not alone. I'm confident that Pete has experienced some of the same concerns that I have - and I know that some of the guys on the user list have run into trouble in this area as well.
So - to the question - do it now or do it later? I think its a good idea to do it now. I figure it will take a couple of days to get the changes to the build in place and a couple of days for validation. I also think we could provide a bundled jar that includes the client and the implementation classes that could be used by users such as Cocoon et. al. I.e. I don't think there is a user conflict argument here - in fact I think there is simply a win-win-scenario.
What do you think?
Cheers, Steve.
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
