Stefano Mazzocchi wrote:
>
> Carsten Ziegeler wrote:
> > First, Stefano, relax - I didn't want to attack you directly.
> > Don't assume that all my comments were hinting at something you did!
>
> Sorry but it looked pretty personal to me.
>
Sorry for that - I really hate writing long emails and perhaps this
leads to more misunderstandings.
> Change line 192 of the current build.xml file from
>
> <!-- [FIXME] THE DEPENDENCY ON DEPRECATED SHOULD GO AWAY!!!! -->
> <path location="${deprecated.src}"/>
> <path location="${build.src}"/>
> <path location="${java}"/>
>
> to
>
> <!-- [FIXME] THE DEPENDENCY ON DEPRECATED SHOULD GO AWAY!!!! -->
> <!--path location="${deprecated.src}"/-->
> <path location="${build.src}"/>
> <path location="${java}"/>
>
> and recompile.
>
> You'll see what I consider a mess.
>
Yes, I know.
> I don't necessarely blame the Source refactoring since it could well be
> that some files were moved to 'deprecated' even if they didn't belong
> there. I would like to hear your opinion on this since you know the
> internals of this stuff more than I do.
>
The reason is simple: compatibility - Apart from some other minor places
that can be changed easily, there are two problem areas:
a) source resolving
b) caching
Both mechanism were replaced by a better/newer/cleaner one. This leads
to the problem, that the old one is deprecated and therefore moved
into the deprecated block. But to maintain compatibility the new code
tests for some now deprecated classes/features; otherwise cacheable
components or components using the source resolver that were written
for 2.0.x were not working properly anymore with 2.1.
When I suggested moving deprecated sources into an own block, I did
not thought about moving the classes that are used by the core into
that package as well - although they are deprecated.
But they were moved, too - and I didn't thought about the impact.
So what's the solution? If we want to maintain compatibility and I
know we want this - we can move *some* of the required but deprecated
core classes back into the core. That's the only solution I currently
see.
>
> Deprecated classes should depend on core (obviously) and should be
> packaged separately for those who need back compatibility, but should
> not block the core compilation.
>
One problem area is the caching algorithm that supports the old deprecated
Cacheable interface and the other one is that we deprecated the source
resolving but unfortunately each sitemap component directly gets a
source resolver and does not have to lookup it up.
> I just want to know if others believed that I did refactoring against
> the will of this community.
>
I don't think that you refactored the build system against the will.
You could have let the old build system first intact and give the
new one a new name, so that everything would still working. But that's
not required, so if we can get the full build up running again
soon, I think it's ok.
Carsten
