Joel! Welcome back to the program! I wonder if this is a JDK issue - I thoug that the basic XPath APIs were part of the core JDK and that Xalan was not required, but I suppose that, like JAXP/DOM, there may be some discrepancies. Or I may just be wrong. My dev JDK doesn't have Xalan in /lib/endorsed, but I have five JDKs on my system, so I will look into that some more. In the meantime, I will update the build with your fix.
The test cases (unit and other) bring up an important topic. In the past, I have kept all tests/test projects as separate projects or modules. They had a copy of the latest jars from the build, but there were no dependencies between the test projects and the source tree. I did this to make sure that new people could come in and run the tests (and tweak the tests) without setting up the full build. I would like to consider this as we decide how to set up and record the tests in /trunk. Our current test/sample projects are stored in a way that is easy to ship but may not be optimal for daily tests. I'm open to suggestions. Andrew, I know you've thought a lot about the test harness in general - would you like to make a proposal before I make my own? Joel, you may have (will have) OSGi-specific things that need to be considered when setting up the test harness, so be sure to educate us if we're oversimplifying for the Axis2/POJO scenario. Dan "Hawkins, Joel" <[EMAIL PROTECTED]> wrote on 06/27/2006 02:40:45 PM: > Dan, > > I hit a snag when trying to build xml-utils. I found that the following > dependency was needed in the pom in order to build the XPath utility > classes. > > <dependency> > <groupId>xalan</groupId> > <artifactId>xalan</artifactId> > <version>2.7.0</version> > <scope>compile</scope> > </dependency> > > Once I tossed that in, everything went smooth. Am I missing something, > or do you have more mojo in your environment than I do? :-) > > Starting to work on the OSGi build stuff now. Any ideas on how you'd > like to handle unit test cases, etc.? > > Thanks, > Joel > > > > -----Original Message----- > From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 15, 2006 5:43 PM > To: [email protected] > Subject: status of the build > > I have created a Maven-based build for each of the source code modules > in > /trunk/modules. There is a build-all.bat file that ties these together > because it does not appear that Maven 2.0 allows users to tie together > multiple project files into one aggregate project. If I'm wrong about > this, I'd be happy to make the change necessary to create a "pure" Maven > > build. > > Because of Maven's "one jar file per project" rule, I have split some of > > the WS-* modules into two projects - one for API, one for > implementation. > This required a change to the projects' directory structure, so the code > > for those projects will have to be re-commited (under the new > directories). I apologize ahead of time for the extra noise on > muse-commits. I originally thought that Maven would allow me to generate > > multiple jars from a single source tree, but answers to past queries on > [email protected] indicate that "one jar file per project" is the > only way to go. > > My next steps are: > > 1) add the .properties files containing error/log messages to the build > jars > > 2) figure out how to get Maven to stop including its metadata files in > the > build jars > > 2a) if #2 is not possible, update the build-all.bat file to strip them > out > manually > > 3) add the test projects to the build - I'll do this in a way that is > similar to other ws.apache.org projects > > > Dan > > > > Dan Jemiolo > IBM Corporation > Research Triangle Park, NC > > > +++ I'm an engineer. I make slides that people can't read. Sometimes I > eat > donuts. +++ > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > The contents of this e-mail are intended for the named addressee only. It > contains information that may be confidential. Unless you are the named > addressee or an authorized designee, you may not copy or use it, or disclose > it to anyone else. If you received it in error please notify us immediately > and then destroy it. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
