Make more fields/methods of service classes protected

2014-04-30 Thread Michael Wyraz

Hi,

for extending tapestrys internal service classes it's often required to 
copy a lot of code because almost everything is private. Why not 
changing it to protected to allow others to extend those classes?


Examples:
- to temporary fix https://issues.apache.org/jira/browse/TAP5-2219 I had 
to copy the whole class because XMLTokenStream.openStream() is private.
- I'd like to add one more component root that is accessible without 
prefix (like core). This is a trivial change to 
org.apache.tapestry5.internal.services.ComponentClassResolverImpl.locate(String, 
MapString, String) - but I'd have to copy the whole class because the 
method is private.


I had a lot of such situations where I'd like to change minimal 
behaviour of tapestry's service classes and failed because of private 
fields/methods. I while ago I was told that private is choosen because 
the internal classes might change. I think that's a bad reason because 
if one overrided stuff in internal classes, he has to deal with such 
changes when the framwork version changes. If one copies the code to do 
some minimal changes, he'll stuck on the old code when he upgrades 
tapestry which might  cause much more side-effects than overrding just 
one or two methods.



--

Mit freundlichen Grüßen / Kind regards

Michael Wyraz

evermind GmbH
Schorlemmerstraße 1
04155 Leipzig

Tel.:+49 (0)341-25 39 66 - 0  callto:+493412539660
Fax:+49 (0)341-25 39 66 - 1  callto:+493412539661
Funk:+49 (0)177-73 00 00 3  callto:+49177733
E-Mail: michael.wy...@evermind.de

HRB: 21586
Amtsgericht Leipzig

Geschäftsführer:
Christoph Klemm



Re: Build failed in Jenkins: tapestry-trunk-freestyle #1204

2014-04-30 Thread Jochen Kemnade

Am 29.04.2014 21:07, schrieb Jochen Kemnade:

I'll downgrade it tomorrow and get myself a Java 1.5 compiler...


Which is much harder than I thought it was. I managed to find old rt.jar 
and jce.jar files and to make Gradle use them.
Now I'm getting compile errors, e.g. in VirtualResource:88, 
MacOutputStream:45 and others. Mostly, it's Java 6 methods being used.
First of all, do we still want to stick with Java 5 now that Java 8 is 
out and even Java 6 is EOL?

Second, I wonder why it builds in Jenkins. What JDK is used there?

Jochen

-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org



Re: Make more fields/methods of service classes protected

2014-04-30 Thread Thiago H de Paula Figueiredo
On Wed, 30 Apr 2014 06:43:53 -0300, Michael Wyraz  
michael.wy...@evermind.de wrote:



Hi,


Hi!


for extending tapestrys internal service classes it's often required to
copy a lot of code because almost everything is private. Why not
changing it to protected to allow others to extend those classes?


Because it makes keeping backward-compatibility way harder and that's very  
important for the project. Not to mention that protected fields are  
something to be avoided in OOP. In addition, you can use advise or  
overriding for dealing with most problems.


--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org



Re: CI builds

2014-04-30 Thread Jochen Kemnade
Indeed. It took half a day to even start the last build. The build itself
was acceptably fast though.