cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johnson, Eric" <>
Subject RE: Samples
Date Mon, 12 Mar 2007 16:21:15 GMT
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 [] 
> Sent: Monday, March 12, 2007 12:09 PM
> To:
> 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

View raw message