We probably will be able to resolve 1) issue if current
shade-maven-plugin is improved to support resources merge through plugin
configuration, the 2) issue can probably be worked around around also.
However, we do have another issue: how are we going to generate manifest
jar with cxf modules jars and third-party jars located in two different
directories? anyone has any idea on manifest jar creation under this
situation?
Thankss,
Bo
Daniel Kulp wrote:
Just to bring up a complication that Dan and I kind of thought about
yesterday:
1) What will happen with all the files that are in "multiple modules".
I'm thinking about the files like:
META-INF/cxf/cxf-property-editors.xml
META-INF/tools-plugin.xml
META-INF/spring.handlers
etc....
Those will all need to be merged together. That's not going to be fun
and will definitely be a maintenence issue if it's not something that
can be automated.
2) The NOTICE file for the bundle will also need to be a merge of the
automated NOTICE as well as all the appended information.
Dan
On Thursday 29 March 2007 06:40, Bozhong Lin wrote:
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
