Parent Directory
| 
Revision Log
| Links to HEAD: | (view) (annotate) |
| Sticky Revision: |
TLP related blanket changes: s:jakarta.apache.org/commons:commons.apache.org: s/commons-user@jakarta.apache.org/user@commons.apache.org/ s/commons-dev@jakarta.apache.org/dev@commons.apache.org/ s/Jakarta Commons/Apache Commons/ s:svn.apache.org/viewcvs/jakarta/commons:svn.apache.org/viewvc/commons: s:svn.apache.org/viewcvs.cgi/jakarta/commons:svn.apache.org/viewvc/commons: s:svn.apache.org/viewvc/jakarta/commons:svn.apache.org/viewvc/commons: s:svn.apache.org/repos/asf/jakarta/commons:svn.apache.org/repos/asf/commons: I'd appreciate another pair of eyes on this. There are some categories we probably don't want to change ATM (hopefully, none of these snuck in): * Historicals (proposals etc.) * URLs that shouldn't change (DOCTYPE fragments etc.) * Test cases where namespace URLs matter etc. (I'll track any related nightly failures)
Moving to TLP
Moving back :)
Moving to TLP
apply patch for JELLY-272 from ltheussl
Setting the maven repo - apologies if this borks anything
Fixed copyright header (committing in parts as the full commit timed out)
Changing cvs.apache.org to people.apache.org. None of these locations appear to point to an svn or cvs url
Modify maven build to add two non-standard attributes to the jar's manifest file to indicate the values of "maven.compile.source" and "maven.compile.target". Also modify the build to include an "Implementation-Vendor-Id" of "org.apache" in the jar's manifest. The two non-standard entires created in the manifest file will look something like the following: X-Compile-Source-JDK: 1.3 X-Compile-Target-JDK: 1.3 This change serves two purposes: 1) To provide comfort to users regarding JVM compatibility. 2) Enable releases to be checked more easily for JVM compatibility. The manifest specification indicates that "unknown" entries in the manifest file are ignored. These entries have been prefixed with "X-" which is a sometimes used "convention" for indicating non-standard entries. See thread: http://tinyurl.com/839zh
Ensure junit errors are displayed inline
use agreed commons properties
add '-src' to the directory in a distribution
compile for 1.3, that is the JDK we are targetting.
compile for JDK 1.3
start to prepare a 1.0 pre-release
getting ready for core release
setup deployment properties
svn:keywords correction
remove duplicate
Use SVN changelog
set changelog factory
Add checkstyle properties
Add issue template Remove old checkstyle props
Fork the compile under Maven
Add PMD report
Nav is not aggregate
Start of multiproject build for site
Changed connection so that it can be override by a property and so allow the change log to be correctly generated when using an ssh-agent.
ASL v2
Adding Commons Site Look & Feel configuration to all jakarta-commons/<project>/project.properties
Making the license point to a local file instead of one above. development process is commons-charter and the maven-logo is the feather one. Paul
Add some documentation properties
Add license file
Add maven.test.dest property as it wasn't being seen properly
re-enabled some Task JellyUnit test cases now I've figured out why they stopped working - the junit forking must be enabled for this project when running in Maven to avoid classloader blues.
Fix property and generated build file breaking gump runs
Fixes for the GUMP build. We now use the latest commons-collections library 2.1 to remove deprecation warnings Also moved to OJB 0.9.6 to avoid compile errors
patched the SQL demos so that the demo:sql target now properly demonstrates the SQL tags in action, without the user needing to know anything or mess around with properties, or have a HSQLDB server running or anything. the demo:sql target now creates an in-memory HSQLDB database, creates a table, inserts some data, then demonstrates generating some XML from the result set.
Enhanced the JUnit tag library so that TestSuite and TestCase objects can be created in Jelly script so that unit testing becomes easy to do via Jelly scripts. This also means that Jelly can be integrated easily into existing test runners. See the src/test/org/apache/commons/jelly/junit/ directory for details of how this works; there you'll find a suite.jelly which is the test suite and a TestJUnit.java class which is a simple class to bind the suite.jelly into Ant's default JUnit test runner. This class should be usable in any JUnit test runner, since it provides a class with a static suite() method, yet internally it uses one or more Jelly scripts to actually create the individual TestCase objects. So the new JellyUnit capabilities can be seamlessly integrated with traditional Java test cases. So users can now use either Java or Jelly; intermixing the two to use the best tool for the job. So now Jelly could be used for XML, SOAP, SQL, HTTP & JMS testing and such like.
Added a "dist:install" goal to install Jelly on the user's system.
This creates a ${maven.dist.install.dir} dir, and copies all the files
needed by Jelly to run (which are generated in "dist:build"'s preGoal.
Though, I can't generate the JELLY_HOME and the PATH, so I added a
big warning telling the user that he needs to set those variables.
Note : I defaulted the ${maven.dist.install.dir} to /usr/local/jelly,
which is a Linux path. I should add a system detection, so that
both worlds are happy :)
Lots of tweaks to allow for better jelly+ant integration.
Fixing repo's to use both jakarta and werkz for finding jars.
Added remote repo for fetching werkz jars.
Added Vinay's patch so that the To Do List is now in XML format so that it can be put onto the website. Thanks Vinay!
Added an Ant tag library which can invoke Ant tasks from inside a Jelly script. Invoking Tasks is working fine, though support for Ant DataTypes isn't quite working yet (like nested <classpath> elements). Should have that working soon. Also added a new DynaBeanTagSupport class for developers wishing to use a DynaBean to hold tag attribute values.
Ported the old build system back into the Maven build so that common sample programs can be ran as Ant targets such as ant demo.hw for the hello world script or ant demo.ant for the Ant based demo.
Updated the build to try remove some of the less important check style errors to try highlight the most important errors. Also using Sun rather than Turbine curly bracket notations
Ported the build system to Maven. Also moved the non-core taglibs into src/taglibs where there will be seperate build files for each optional taglib.
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 |