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
