cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Polar Humenn <phum...@iona.com>
Subject Re: Samples
Date Mon, 12 Mar 2007 16:09:21 GMT
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

Mime
View raw message