David Jencks wrote:
On Jul 18, 2008, at 10:35 AM, Joe Bohn wrote:
In the past we had asserted that a user should be able to pick up an
individual sample and build it. Because of a recent change in the
samples this is no longer possible (at least not until we release some
artifacts that can be downloaded without building locally - see
details on the issue below).
I personally think it is acceptable to provide some general directions
on building samples that require a user (at least the first time) to
checkout the entire samples svn tree and build from the top level. It
takes about 5 minutes to build all of the samples. Following that
initial build a user could choose to build just one sample at a time.
We can also provide some more complicated directions for users that
have some issue with building all of the samples. If I don't hear any
strong objections (along with solutions to the current issue that
requires a top level build) then I will go ahead and change the doc
accordingly.
I'm fine with this except I don't think we need to provide error-prone
instructions that are likely to stop working soon for people who don't
want to build all the samples.
I'm fine with eliminating the more complicated directions.
Specifics on why this is an issue:
- We had to add in the building of a tomcat utility (Txt2Html included
in buildutil). This is used to generate html from java source and jsp
files. The html is then included with the jsp & servlet samples and
can be displayed when running the samples (we might want to consider
this for some of our other samples as well). The utility is run via
ant and so we are using the maven-antrun-plugin. When the
configuration for the execution of the utility was included in the
specific sample it worked great for just that one sample but produced
errors when attempting to build from a higher level. This is
apparently because of the way the the maven plugin is resolved and
loaded. To get the build working from the top level we had to move
the dependency of the antrun-plugin on buildutil up under
pluginmanagement. However, this has the effect of now requiring
buildutil to be available for all samples even if it is not used
(since most samples use the antrun-plugin for other purposes). There
is a maven issue that describes our problem (and indicates that it is
fixed in maven 2.1.* but not 2.0.*) - MNG-1323
(http://jira.codehaus.org/browse/MNG-1323).
I wonder if we should write a maven plugin to do this text to html
conversion? I haven't looked at what is going on or the problem at
all. It's hard to believe there is no solution available now.
In addition to the issue above, there are other general build steps
required which will benefit from a common build process rather than
including them in each sample description. For example, we need to
make the svn repository artifacts for the specific server release
available in the user's local maven repo. I'd rather not have to
include those steps in each sample but rather point to a common build.
Maybe we should rethink our svn repository strategy. It doesn't really
work with the idea of plugins. How about if we do something like
shading the tomcat jars to another package and releasing them with our
groupId?
I think it would be great if we could release these images under some
other package so that they can be downloaded. However, I wonder if
there are dependencies that might be broken if we did something like
that (I mean apart from dependencies we create). At the moment we only
change the version # for our artifacts so any reference from poms would
not be affected unless the version number itself was included in the
reference.
thanks
david jencks
Thanks,
Joe
