>Here are some small bits and pieces that need to be set free.
XSLT Graphical Editor for Eclipse:
One of the items that is missing from the Eclipse XSL Tools editing suite is a nice Graphical Editor. Something that lets you take two input XML documents and map between them. Then generate a XSLT that will do the work. I’ve seen this done well, and I’ve seen it produce horrible XSLT. However, for many it is a good way to start working with large complicated transformations.
If you are a German college/university student you might be interested in the project that Johannes Nicolai, is sponsoring for InformatiCup. Information on expressing your interest or participating can be found on the InformatiCup website and the project proposal.
PsychoPath XPath 2.0 Processor Standalone Jar/Docs.
For those that are interested in getting the latest and greatest versions of the PsychoPath XPath 2.0 processor jars, but aren’t using eclipse for their development or use of PsychoPath. You can now get the latest builds from the eclipse Hudson server. Note that these are built from head, and all unit tests are run, but they are for development purposes only. Only the official Milestone and Releases that are part of the WTP publication are officially supported. These builds are just a convenient way for those that do not need or want a full set of WST related plugins to get one specific jar.
Using Eclipse MAPS to build from HEAD.
Here is something that may or may not be of interest to those that prefer to build from the latest code in head, but still have to use eclipse MAP files. You have a couple of options.
- Replace the Version Tag (i.e. v20080910) with the word HEAD in the map file. This will make a PDE Build/Athena build pull all information from head if using CVS. Note: One item with Athena is that you will get HEAD as your qualifier instead of the version tag.
- If using Athena, you can also do a force override using the EXTRAFLAGS option. (i.e. EXTRAFLAGS = “-forceContextQualifier -fetchTag HEAD”)
For the PsychoPath build, I’m using option 1.
Hudson Eclipse Tip for Building from HEAD with Maps:
If you follow option 1, you will have very little reason to change the map files, except to add new plugins and features to the map file as you develop your code. So how are your builds triggered then if not updating and building everytime the releng project changes? The solution is to add to your Hudson CVS the bundles, features, fragment projects that you want to monitor for changes. If any of those projects change, then the build will be done and only if those projects have changed. For PsychoPath, I have it monitor the main plugin and the map file. The reason is that the PsychoPath Test plugin is very large, and it takes CVS up to 8 minutes just to verify any changes. CVS is not known for performance on extremly large projects. Hopefully, once the git based repositories are up and running for read access, I can switch this build over to eGit/JGit.
Hudson Tip for Build Work Spaces and Athena:
If using Athena on Hudson, and you see your Disk Usage growing and growing. You may want to move your actual Build Artifacts out of the Build directory that it creates. You can keep your cached dependencies, but should remove the old I, N, R, M based directories before starting the next build. Athena doesn’t by default clean these. If you have very few dependencies, and it doesn’t take a long time to retrieve them, then you can even remove the left over Build directory entirely. I’m sure that anything we can do on the build machine to help reduce the amount of disk space our builds use, would be appreciated by the eclipse foundation networking staff.
Hudson Tip for Build History Retention:
Think about how many builds and how long your project needs to keep those builds available. While it is great to see 3 months worth of build history, as the number of projects grow each of these will require more disk space. Play nice with the build system, and limit your retention history on the number of builds you keep and for how long. You typically only need enough to give your community a good idea of the stability of your project and builds. They can get a good idea based on the defaults that Nick has setup of 5 builds, and 5 days. Keeping any more builds available may or may not provide much value.
Hudson Tip for Unit Tests:
Allow Hudson to Publish and track the results of your unit tests. This is a great way to help show your community the stability of your builds. Hudson provides a nice graphical display of your build history as well as how many unit tests pass and fail. Your community can help use this to gauge whether they want to consume the build.
Most of these tips will probably end up on the eclipse wiki at some point. I’m sure Nick will go through and vet any inconsistencies with Athena and Hudson I may have listed here. Athena based builds are well worth the time to setup and for many projects that just need to build a few plugins and features, it fits in very nicely.