I'm +1 with Polar's suggestions. The samples need to clearly show a "user" how to set up and run a CXF based application. It would be nice if this were done using Maven and had support for at least one IDE, but the more important task is clarity.
> -----Original Message----- > From: Polar Humenn [mailto:[EMAIL PROTECTED] > Sent: Monday, March 12, 2007 12:09 PM > To: [email protected] > Subject: Re: Samples > > Daniel Kulp wrote: > > On Monday 12 March 2007 10:45, Dan Diephouse wrote: > > > >> I think we should consider making some improvements to our samples. > >> Mainly, I would like to make them easy to use in Eclipse. It'd be > >> great IMO if our distribution was simultaneously an Eclipse > >> workspace. Then people could just do "File->Switch Workspace" in > >> Eclipse and point it at our distribution. Another option > would be to > >> convert our builds to Maven so we could easily generate > eclipse workspace information. > >> > >> Thoughts? > >> > > > > Honestly, I'd like to convert them all to Maven. The main > reason is that > > would give us IntelliJ/IDEA support as well. (mvn idea:idea) > > > > There are a few issues though: > > > > 1) Building - they wouldn't build unless maven can find the jars. > > Normally, we just put them in ${installdir}/lib which > wouldn't work too > > well. Thus, the samples wouldn't work until we deploy the > release. (or > > the user builds the source distribution) The OTHER > option here is to > > create a ${installdir}/maven_repo that is a copy of all the > stuff that is > > needed. The 2.2-SNAPSHOT version of assembly can create > this just fine. > > Of course, that would increase the size of the download. > (jars in lib > > and in maven_repo) I'm not sure if the assembly can grab > the sources > > jars as well. If so, that would be great. Then the > created eclipse > > projects could be fully debuggable. > > > I've done this with a couple of samples. It's kind of hard to > make sure you have all the pieces, but it can be done. > > So, if its based on Maven, why do you need to supply the repository? > Maven should retrieve what is needed. To work offline? If > that's the case, then maybe there may be a separate Maven > Repository you may download? > > 2) Executing the samples: maven is very good for building > them. However, > > what do we do for exectuting them? Stick with ant? > Shell/bat scripts? > > Specific profiles in the pom configured to use the exec plugin? > > > > That depends. Sticking with Ant requires Ant to be installed, > which may be a hassle, but not a big one. > > That's okay, at least an Ant target may give you a > specification on which how to run things. > > However, I have separate issues with the current approach, > which I considered mildly annoying. > > First of all, there are two many dependencies and specialized > macros. As a beginning "user" the last thing I want to figure > out when getting one of these things to run, is to chase down > some non-standard macro like "cxf-run" and put the work into > understanding what it does. > > I understand that for the "developers" that's a lot of code > duplication, but illustration is the goal of the samples, not > consolidation. > > To get to there, the sample ant scripts call on "../common_build.xml" > file which has other dependencies in the distribution. This > means that you can't simply "extract" a samples directory and > start to play with it outside of the distribution. > > I suggest that each sample directory be able to run on its > own, with really straight forward target configurations to > get something to run. > Make it as painfully explicit as possible so that somebody > who isn't intimately involved with the distribution can > readily understand how to get his/her own stuff to run. > > Cheers, > -Polar >
