Samples

[Dan Diephouse <da...@envoisolutions.com>]

Hi All,

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?

- Dan

-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: Samples

[James Mao <ja...@iona.com>]

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)    
>   

I think keep ANT build there will not conflict with adding Maven 
support, i prefer keep ant build, i like ANT more than Maven.

> 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.
>
> 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?
>
>
>
>   

Re: Samples

[Daniel Kulp <da...@iona.com>]

Polar,

On Monday 12 March 2007 12:09, Polar Humenn wrote:
> Daniel Kulp wrote:
> > 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?

The main reason is to test the kits during the "pre-release voting" phase.   
During that time, the poms would be looking for 
version "2.0-incubating-RC", but we aren't allowed to put them into the 
release repository yet as they haven't passed the votes.    There are two 
options:
1) Configure the samples poms to ALSO look in the place where we plan to 
stage them (ex: 
http://people.apache.org/~dkulp/staging_cxf_2.0-incubating-RC) in addition 
to the release area.

2) Provide our own "local" repository (what I suggested above)

3) Parameterize/profile the stuff in (1).  (when in the voting period, you 
have to build with -Pstaged)

4) Require the testers of the kits to have built the source version first 
so it doesn't need to go find it.

etc...


> 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?

To work offline, they can run "mvn dependency:go-offline" while they are 
online.   I'm not too concerned about that one.


-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog

RE: Samples

["Johnson, Eric" <Er...@iona.com>]

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:phumenn@iona.com] 
> Sent: Monday, March 12, 2007 12:09 PM
> To: cxf-dev@incubator.apache.org
> 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
> 

Re: Samples

[Polar Humenn <ph...@iona.com>]

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

Re: Samples

[Daniel Kulp <da...@iona.com>]

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.

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?



-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog