Hi!
Its again me ... somewhat angry, so sorry *g* I CANT SET A
BREAKPOINT IN SHARED ANY MORE - or I have to do it twice in shared_impl
and shared_tomahawk.
Please lets discuss again why this refactoring is needed - PLEASE !!!
Now I propose to get rid of all those class.getName() (or
Mario Ivankovits schrieb:
Hi!
Its again me ... somewhat angry, so sorry *g* I CANT SET A
BREAKPOINT IN SHARED ANY MORE - or I have to do it twice in shared_impl
and shared_tomahawk.
Please lets discuss again why this refactoring is needed - PLEASE !!!
Now I propose to get rid of all
On Thu, 2006-03-09 at 09:58 +0100, Werner Punz wrote:
Mario Ivankovits schrieb:
Hi!
Its again me ... somewhat angry, so sorry *g* I CANT SET A
BREAKPOINT IN SHARED ANY MORE - or I have to do it twice in shared_impl
and shared_tomahawk.
Please lets discuss again why this
Hi!
I'm still very much in favour of *not* shipping a common jar used by
both core and tomahawk (and maybe tobago, ADF, etc); the versioning
issues related to that are nasty.
Why? Once the shared api is stable this should not be a big issue, no?
I've already moved stuff to tomahawk to reach
Mario Ivankovits schrieb:
And - IMHO the killer, the shared is not interoperable, means it cant
put stuff in the request and use it again if called from another package
as they are different classes - different package names.
See my other thread regarding ExtensionsFilter and Dummyform.
Mario,
As mentioned earlier, yes, there is some pain with the new shared
structure. But my feeling is that most of the pain is due to the fact
that we have to break with some (bad) habits.
Please think of the two libs shared_impl and shared_tomahawk as two
*different* things. This affects
Simon Kitching schrieb:
What I had in mind when this was being discussed was not a compilation
pre-processor but instead a tool based on ASM that would post-process a
jarfile to rename all classes from package X to package Y, and change
all references to stuff in package X to the new package
Hi guys,
where things are breaking right now is exactly where we have been too
lenient in the beginning and have made tomahawk to be based on impl
where it shouldn't.
regards,
Martin
On 3/9/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Mario,
As mentioned earlier, yes, there is some pain with
On 3/9/06, Werner Punz [EMAIL PROTECTED] wrote:
Mario Ivankovits schrieb:
And - IMHO the killer, the shared is not interoperable, means it cant
put stuff in the request and use it again if called from another package
as they are different classes - different package names.
See my other
Hi Martin!
where things are breaking right now is exactly where we have been too
lenient in the beginning and have made tomahawk to be based on impl
where it shouldn't.
Ok, but then, lets make it clean NOW. On the trunk - once we are
finished we can restart with the release.
Ciao,
Mario
Martin Marinschek schrieb:
Hi guys,
where things are breaking right now is exactly where we have been too
lenient in the beginning and have made tomahawk to be based on impl
where it shouldn't.
regards,
I do not see it that way, the problem is, that pure JSF is very verbose
in what it
On 3/9/06, Simon Kitching [EMAIL PROTECTED] wrote:
On Thu, 2006-03-09 at 09:58 +0100, Werner Punz wrote:
Mario Ivankovits schrieb:
Hi!
Its again me ... somewhat angry, so sorry *g* I CANT SET A
BREAKPOINT IN SHARED ANY MORE - or I have to do it twice in shared_impl
and
Manfred Geiler schrieb:
On 3/9/06, Werner Punz [EMAIL PROTECTED] wrote:
Mario Ivankovits schrieb:
And - IMHO the killer, the shared is not interoperable, means it cant
put stuff in the request and use it again if called from another package
as they are different classes - different package
Manfred Geiler schrieb:
Please think of the two libs shared_impl and shared_tomahawk as two
*different* things.
OK, I'll restart my brain and try again ;-)
Let's look at the
key of the problem here: Why is it an issue when shared_impl and
shared_tomahawk have different FQN-Strings during
On 3/9/06, Werner Punz [EMAIL PROTECTED] wrote:
Manfred Geiler schrieb:
On 3/9/06, Werner Punz [EMAIL PROTECTED] wrote:
Mario Ivankovits schrieb:
And - IMHO the killer, the shared is not interoperable, means it cant
put stuff in the request and use it again if called from another
I'm completely +1 for what Manfred is saying here. I don't think
there's ever been a clearer explanation of what we're doing and why
with the current setup. In fact, I never completely understood the
details until this mesage.
Note that I'm probably the most-adversely-affected person by this
: warning - use of class.getName() in shared
I'm completely +1 for what Manfred is saying here. I don't think
there's ever been a clearer explanation of what we're doing and why
with the current setup. In fact, I never completely understood the
details until this mesage.
Note that I'm
On Thu, 2006-03-09 at 11:28 +0100, Manfred Geiler wrote:
On 3/9/06, Simon Kitching [EMAIL PROTECTED] wrote:
Personally I don't use breakpoints much; logging works better for me for
debugging.
Maybe you are kind of biased? :-)
Actually, it's the other way around. I work on commons-logging
On Thu, 2006-03-09 at 11:38 -0600, Stan Silvert wrote:
I assume this was all discussed before, but I'm glad the discussion has
been raised again. I have also been having trouble understanding what
is going on and why.
My current understanding is as follows:
1) There is some common code
Another thing I was wondering. Why not make a clean break right
now?
That is, let each project have its own version of the common source
that
gets checked in today? Then they can be maintained independently.
DRY principle! (don't repeat yourself)
We should not have redundant code in
On Thu, 2006-03-09 at 14:01 -0600, Stan Silvert wrote:
Another thing I was wondering. Why not make a clean break right
now?
That is, let each project have its own version of the common source
that
gets checked in today? Then they can be maintained independently.
DRY principle!
Hi!
Currently I put some investigation into the problem that the dummy form
is no longer rendered.
The problem I found is, that some classes use its own class name with
some constant added and but this into e.g. the requestMap.
So in case of the DummyForm this is
22 matches
Mail list logo
