I still have fresh memory that we had long discussion about manifest.jar
vs bundle.jar right before M1 release. I guess it must be time for
another milestone release, thus the discussion of packaging again. :-)
By observing all discussions happened on this topic, I would like to
propose a packaging solution that satisfies both sides of world
(manifest.jar and bundle.jar):
-- "lib" directory containing
cxf-bundle.jar
other-third-party dependency jars, such as saaj.jar
a manifest jar
-- "modules" directory containing
cxf-*.jar
Would this work for everyone?
Cheers,
Bo
Dan Diephouse wrote:
On 3/27/07, Ted Neward <[EMAIL PROTECTED]> wrote:
> Ted, maybe we haven't been clear in what we mean by single jar.
>
That's what I get for wandering into the middle of a conversation.
Thanks
for not pointing out the obvious stupidity on the part of the guy who
didn't
read through the entire thread. ;-)
> So given that, what's so bad about one cxf jar file? With regards to
> update, the same rules apply as with any other project. You check the
> release notes and decide if you want the new version or not. This has
> nothing to do with multiple jars, as they don't rev independently of
> each other (and if they did, then sure, they should be separate jars).
>
I guess I have to fall back on the aesthetic principle of modularity. I
agree with Dan's earlier statement that he's seen projects that used a
monolithic jar/.exe/artifact approach that allowed deep "tangling" to
take
place over time--I've seen the same.
That said, though, how hard would it be to keep them in separate jars in
the
development cycle, to help enforce that kind of modularity, and just
have
an
Ant task stitch them together into a single jar as part of the release
process? This doesn't seem like a major showstopper to me.
I believe thats what we're proposing. We'd still want to use Maven for
the
individual modules and to encourage modularity. We'd just package up
most of
the modules into one jar for users to use instead of having to manage
8 or 9
cxf-*.jars
- Dan
