Dan, Thanks - good to be back (well, sort of!).
http://maven.apache.org/guides/mini/guide-archive-configuration.html has some info on suppressing maven's metadata in archive files, in case you haven't found it yet. I'm trying to figure out how to get maven to do something as simple as unjar an archive so that I can update it's manifest (repackaging for OSGi). I feel like I'm wandering in the woods looking for breadcrumbs! I'm afraid to even think about how to do automated testing under Maven. Andrew, I'm all ears at this point. Ah well, back to searching. Cheers, Joel -----Original Message----- From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 27, 2006 3:15 PM To: [email protected] Subject: RE: status of the build 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] 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]
