Stephen McConnell wrote:
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?
I do prefer having a combined jar, along with the broken up jars. That
way folks who want the status quo aren't inconvenienced, and folks who
want the flexibility of the new can take advantage of it.
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.
And that was the source of the confusion.
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 you are reading more into what I said than what is there. All
I was saying is that for Merlin and Phoenix (the two larger, more
powerful containers) they do more with the ClassLoader than the other
containers we have. This is truth, is it not?
Most Java developers that have not delved into the areas we deal with
as container writers are intimidated by classloaders. Perhaps this
is a trend that I alone see here in the East Coast of the U.S.?
Read nothing more into it than that.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
