Hi,
as the maven folks seem to be keen on "breaking unsuspecting
applications which are forced to use our beta releases in new and
different ways", the jakarta-turbine-2 build now breaks if you use the
beta-10 release in a new and exciting way.
To be exact, you get errors like this:
/home/henning/jakarta-turbine-2/target/src/org/apache/turbine/services/security/torque/om/${basePrefix}TurbinePermission.java:29:
class $basePrefixTurbinePermission is public, should be declared in a file named
$basePrefixTurbinePermission.java
public abstract class $basePrefixTurbinePermission extends BaseObject
^
/home/henning/jakarta-turbine-2/target/src/org/apache/turbine/services/security/torque/om/${basePrefix}TurbineRole.java:29:
class $basePrefixTurbineRole is public, should be declared in a file named
$basePrefixTurbineRole.java
public abstract class $basePrefixTurbineRole extends BaseObject
^
/home/henning/jakarta-turbine-2/target/src/org/apache/turbine/services/security/torque/om/${basePrefix}TurbineGroup.java:29:
class $basePrefixTurbineGroup is public, should be declared in a file named
$basePrefixTurbineGroup.java
and lots more.
Of course this should not happen, because these errors come from the
fact that this maven release suddently decided _not_ to respect the
defaults set by a plugin (namely the maven-torque plugin) in its
plugin.properties file. The fact that this didn't immediately pulled a
beta-11 or beta-10.1 release with exact this one bug fixed, says much.
So if you're actually using maven beta-10 and want to build the
turbine code base, add the following lines to your build.properties,
(which simply copy the defaults from the torque plugin and should be
read by maven when starting the plugin. At least it did so in all
releases up to beta-9).
--- cut ---
torque.addGetByNameMethod = true
torque.addIntakeRetrievable = false
torque.addSaveMethod = true
torque.addTimeStamp = true
torque.basePrefix = Base
torque.complexObjectModel = true
torque.useManagers = false
torque.useClasspath = true
torque.saveException = Exception
--- cut ---
I refuse to add this yet-another-work-around-our-buggy-build-tool fix
to the CVS. I'm sick and tired of this.
Oh, and while I'm ranting:
If you're building this with a non-Sun, non-1.4 JDK (like one would do
on e.g. daedalus.apache.org host), don't worry about this:
[junit] [ERROR] TEST
org.apache.turbine.services.avaloncomponent.TurbineAvalonComponentServiceTest FAILED
with
Testcase: testGetAndUseTestComponent took 0.452 sec
Caused an ERROR
org.apache.avalon.excalibur.component.ComponentHandler: method initialize()V not found
java.lang.NoSuchMethodError: org.apache.avalon.excalibur.component.ComponentHandler:
method initialize()V not found
This happens, because the powers that control the central ibiblio
repository chose in their infinite wisdom to put jars on this central,
for all, worldwide repository that are built with the JDK 1.4 or
better. And as, anyone seriously working with java knows, some 3rd
party (and even Sun!) 1.3 JDKs choke on jars built with 1.4
JDKs. These JDKs emit errors just like the one above.
Gee, the power of breaking all 1.3 based builds in a single place is
really amazing.
Simply rebuild "avalon-excalibur/component" with a 1.3 JDK, put the
jar in you're local repo and rerun.
You don't believe me? Check out
http://jakarta.apache.org/~henning/excalibur-component-1.1.jar-ibiblio
vs.
http://jakarta.apache.org/~henning/excalibur-component-1.1.jar-with-1.3
Result a)
[junit] Running
org.apache.turbine.services.avaloncomponent.TurbineAvalonComponentServiceTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.704 sec
[junit] [ERROR] TEST
org.apache.turbine.services.avaloncomponent.TurbineAvalonComponentServiceTest FAILED
Result b)
[junit] Running
org.apache.turbine.services.avaloncomponent.TurbineAvalonComponentServiceTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.568 sec
% java -version
java version "1.3.1-p7"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-p7-brian-021014-16:41)
Classic VM (build 1.3.1-p7-brian-021014-16:41, green threads, nojit)
"lowest common denominator" seems to have gotten lost in all the
"eXtreme programming" hype lately.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"You are being far too rational for this discussion."
--- Scott Robert Ladd in <[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
