Parent Directory
|
Revision Log
| Links to HEAD: | (view) (annotate) |
| Sticky Revision: |
Re-licensed all stuff according to new rules
Updated licenses
move runtime in place
copy runtime
ASL 2.0
add some properties for ojb tests
use maven.repo.local to get the path for the jdbc driver
cleanup build for runtime tests
prepare 3.1-alpha1
sync jar versions
We're in 2003 now. PR: Obtained from: Submitted by: Reviewed by:
brought jars.list in line with default.properties The current consensus says "xmlParserAPIs" from "xerces". So fixed up the jar references to be like project.xml PR: Obtained from: Submitted by: Reviewed by:
Dion put Snapshots for dbcp and configuration on ibiblio. Tested legacy build with these. Changed deprecation to be like maven. PR: Obtained from: Submitted by: Reviewed by:
upgrade dependencies: o commons-beanutils-1.5.jar o commons-collections-2.1.jar o commons-dbcp-1.1-dev-20021215.jar o commons-lang-1.0.1.jar
change version to 3.1-dev
prepare 3.0 release
rc2
upgrade village to 2.0-dev (including the Value.asBooleanObj() method)
Updated version so test suite will run.
prepare 3.0-rc1 build
jar updates: commons-lang-1.0 commons-logging-1.0.2 commons-beanutils-1.4.1 ant-1.5 junit-3.8.1
Part of the patch by Scott Eade <seade@backstagetech.com.au> to get build-torque.xml working again (requires maven.home to be set).
sync jar names with project.xml
If we have release versions of various packages, we should use them... - log4j to 1.2.6 - commons-beanutils to 1.4 - commons-logging to 1.0.1 PR: Obtained from: Submitted by: Reviewed by:
stephanh reverted my previous change (which works fine with Scarab)... http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-torque/src/conf/build-torque.xml.diff?r1=1.44&r2=1.45 this is no good...it has to work this way because otherwise torque will not work with ant 1.5 and that is not acceptable either...so, given that things work fine with scarab, something must be up with the way that stephanh was doing things. i also cleaned up the jars again... -jon
The new pool in commons-jdbc2pool was moved to dbcp. There is little reason to keep the sandbox project open for torque's pool, so I am putting it back into the torque source tree. It is a functional pool, but I would not recommend further development on it. Also reverted the log4j dependency as the new one was not in turbine/jars or turbine/jars2 and the build works with the older version. PR: Obtained from: Submitted by: Reviewed by:
hack things together so that the legacy build system will work with the new maven repo directory structure and make sure that all of the jars are latest greatest and correct. this is ugly, but necessary until maven actually works right... -jon
1. Fixed the maven-b5 build to cope over the default.properties file correctly. 2. Changed the managers so that the syntax to specify an alternate manager for a class uses the fully qualified classname. Old: torque.managers.FooManager.classname = org.company.FooManager New: torque.managed_class.org.company.Foo.manager = org.company.FooManager This change allows multiple OM classes with the same name (from several different legacy databases, for example) to use the managers without conflicting with one another.
Updated beanutils and stratum versions to match project.xml.
stratum 1.0-b3 does not exist and b2 works. PR: Obtained from: Submitted by: Reviewed by:
post b3 update
jar updates
switch to velocity 1.3 final
Patch by Stephen Haberman <stephenh@chase3000.com>: The default.properties hasn't been updated to the standardized file names that are in the project.xml, so the ant test fails. I've attached the simple patch that just renames a few and adds all the right version numbers.
sync jar name for tomcat-naming with project.xml
merge of the JDBC2POOL branch. PR: Obtained from: Submitted by: Reviewed by:
Now developing 3.0-b2.next
Tagging Torque 3.0 beta 2.
The build directory is now "target" instead of "bin".
Moving to commons-configuration
Updating Torque to use the separated JCS classes.
use latest village version
switch to use the commons pool instead of the one in stratum. PR: Obtained from: Submitted by: Reviewed by:
use latest stratum jar
Working towards second beta.
Set version for tag.
classes from commons-util have moved to commons-collections and commons-lang
- use the final xerces-2.0.0 jars - add stratum.jar (needed for configuration and lifecycle)
switch to using the jaxp api. Lost the ability to have conditional validation, but that feature tended to lead to more questions from new users that were not validating. So I am not worried about losing it. If it is an issue we could possibly add a property to shut off validation. updating to xerces2, whose release is imminent. PR: Obtained from: Submitted by: Reviewed by:
use latest versions of xerces and village
make torque into a real version. i had someone get confused with torque-1.0 being older than torque-2.1 which comes with turbine-2.1...thus, i'm upping it to be 3.0-dev to show that it is in development and will be a newer version. -jon
use velocity-1.3-dev and remove the requirement for logkit (velocity now uses log4j if logkit is not found :-))
- the runtime tests are now independent of the distribution
- added the start of an sql testbed for making sure the sql generated
for each supported database is correct. i will steal the testbed in
velocity that is uses to test generated output. so far i've found
problems with primary keys. these are not automated yet but the
base is there.
- all the test classes are now in the org.apache.torque.test package
- tried to get rid of most of the ${project} references but there
are still some in the standard build file. my changes got nuked
when we started the testbed. all the targets should use <filesets>
now and not individual files.
PR:
Obtained from:
Submitted by:
Reviewed by:
use latest released libraries (logkit is no longer included in velocity.jar, so we have to add it)
smal fixes for runtime test
- move runtime tests to its own directory (to make rt and junit test independend) - change bookstore-schema to make it usefull for tests
- remove testing specifics from the default.properties and place them into my personal profile for testing. PR: Obtained from: Submitted by: Reviewed by:
- adding some properties for testing. i use plug in a profile type system like there is in the tdk so that everyone can test easily but i'm just trying to get this thing off the ground. PR: Obtained from: Submitted by: Reviewed by:
- more steps toward a complete test bed. PR: Obtained from: Submitted by: Reviewed by:
build against latest velocity PR: Obtained from: Submitted by: Reviewed by:
I noticed you were still copying src to intermediate directory before compiling. This is not needed as far as I can see as the only filter item defined (VERSION) is not used in the source code. This patch removes the unecessary copying and makes it a little easier to work with. Peter Donald <donaldp@apache.org> PR: Obtained from: Submitted by: Reviewed by:
Updated comment for current build.xml file.
implement dlr's default.properties stuff PR: Obtained from: Submitted by: Reviewed by:
This form allows you to request diffs between any two revisions of this file. For each of the two "sides" of the diff, enter a numeric revision.
| apache@apache.org | ViewVC Help |
| Powered by ViewVC 1.1.2 |