On Dec 13, 2006, at 3:15 AM, Martin Ritchie wrote:
On 13/12/06, Steve Vinoski <[EMAIL PROTECTED]> wrote:
Hi Marnie, today you added the client/example directory, but I'm a
little puzzled by it, because I don't know what it's intended for.
One issue is that it's not part of the main build, so it will not
appear as part of any distribution. Another issue is that I don't
think it should be part of the main build -- only the sources and the
tests should be.
I'd therefore like to suggest that any samples/examples/demos be put
under the distribution directory, so they can be included in qpid
distributions, as I assume we want them to be, without requiring them
to be part of the main build. I'd be happy to move them if you like.
I don't think the examples should be part of the distribution build.
This just seems unintuitive.
How so? I presume that we provide examples not for ourselves, but for
our users. Similarly, the sole purpose of the distribution directory
is to build artifacts for our users. The examples are presumably
always packaged in the distributions as sources, even the binary
distributions, and having them under the distribution directory
facilitates that.
I would have suggested they should either
be in src/examples part of the main build
Do you really want to build the examples every time you do a build?
If so, will the examples have tests that execute in the test phase?
Will an examples jar be produced? If so, does that really make sense,
given that the main value of examples is that users can read and copy
the sources to learn how to use the system?
but then delivered to
everyone
I don't know what you mean by that.
or as they are in a separate sub-module of client. That can
be included in a distribution but can also be distributed separately.
If they're a sub-module of the client, do they build and test as part
of the client's build and test?
The distribution directory is already so full of jars that we never
had or needed pre-maven.
Those are dependencies, both direct and transitive. Maven is
determining all of that. If you feel there are too many dependencies,
then look through the pom files and get rid of any and all
dependencies that are unnecessary, or if a given dependency is used
only for testing, scope it to the test phase only.
I'd like to see us moving towards a set of
distributions that contain the minimal files required to run a broker,
a client and for development that contains everything.
Of course. I don't think anyone would advocate adding unnecessary
stuff to either the build or the distributions.
The only problem I can see currently is that if we include the
examples in the distribution then as they are not part of the main
build the distribution build will fail because it copies whatever
files are in your local repository.
This is again why I suggest that they be part of the distribution.
It's all really a multi-step process: you build the main stuff, then
you create a distribution. You install that distribution, just as a
user would, and then you build and run the examples, just as a user
would.
I don't know maven that well but
is there ANY way we can change this? Only dependencies should be
pulled from the local repository. The qpid code should be compiled
"locally" and included in the distribution.
Why? That would mean that you'd need special rules for finding qpid
artifacts in the file system, which isn't really necessary (see
below) as it would just add complexity.
I can't believe that maven forces you to only work on one "revision"
of the code base at a time.
It doesn't. If you're working on a different version, then you need
to change the version number. The trunk currently is set to version
"milestone 2 snapshot." Every time you build, you build a snapshot of
M2, and you replace in your repository any M2 snapshot that might
have existed before. That's the definition of a snapshot. Once we
decide to go for a milestone 2 release, we'll branch, and then the
trunk will move to M3 snapshot, while the release branch will be
building M2 release candidates, and ultimately will produce M2
(final). At that point, you can build both the branch and trunk, and
the artifacts produced by each build will live side-by-side without
any interference with each other.
I have a number of branches in development
and having to do a main clean and install before I can build a
distribution seems so unintuitive.
Change your version in the poms on each of your branches to reflect
that branch name or purpose. Your branches are, after all, building a
version that's different than what the trunk is building. Then the
artifacts produced by each branch can all coexist.
This issue doesn't seem to bother some on the list but I am finding it
increasingly annoying. Does anyone else share this opinion?
Obviously, I don't. :-)
--steve
