You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Daniel Kulp <dk...@apache.org> on 2007/12/18 04:17:32 UTC
Re: svn commit: r604886 - /incubator/cxf/trunk/distribution/bundle/pom.xml
Glen,
The cxf-bundle module is designed to produce an "uber" jar which is all
the module jar combined into a single jar. That is the jar we put by
default in the lib directory. The issue is that, from maven, there
wasn't a good way to depend on the uber jar if you wanted that
dependency instead of all the individual jars. The new version of
the shade plugin solves that by doing a few things:
1) REMOVES the individual jars from the pom
2) Promotes the transitive dependencies as direct deps of the pom
3) Creates a uber sources jar to match the uber jar.
This basically makes the uber jar usable from maven. For example, if
you take the example off your blog, you have:
<!-- Depending on your requirements you may need more or less
modules from cxf -->
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxws</artifactId>
<version>${cxf.version}</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-http</artifactId>
<version>${cxf.version}</version>
</dependency>
That comment kind of says it all. The user needs to know what they
need. You COULD now just do:
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-bundle</artifactId>
<version>${cxf.version}</version>
</dependency>
and it would get everything.
Dan
On Monday 17 December 2007, Glen Mazza wrote:
> Am Montag, den 17.12.2007, 14:51 +0000 schrieb dkulp@apache.org:
> > Author: dkulp
> > Date: Mon Dec 17 06:51:43 2007
> > New Revision: 604886
> >
> > URL: http://svn.apache.org/viewvc?rev=604886&view=rev
> > Log:
> > Only build shaded source jar with deploy profile (which turns on the
> > source jar building for everything else)
>
> I'm not understanding the purpose of createSourcesJar completely.
> Might this be redundant with the "-DdownloadSources=true" option for
> mvn eclipse:eclipse?[1] I would always need to do this anyway for
> non-CXF dependencies, so isn't the "createSourcesJar" an unnecessary
> moving part?
>
> Thanks,
> Glen
>
> [1]
> http://www.jroller.com/gmazza/entry/using_maven_to_create_a#MVNSOAPCli
>entStep3
>
> > Modified:
> > incubator/cxf/trunk/distribution/bundle/pom.xml
> >
> > Modified: incubator/cxf/trunk/distribution/bundle/pom.xml
> > URL:
> > http://svn.apache.org/viewvc/incubator/cxf/trunk/distribution/bundle
> >/pom.xml?rev=604886&r1=604885&r2=604886&view=diff
> > ====================================================================
> >========== --- incubator/cxf/trunk/distribution/bundle/pom.xml
> > (original) +++ incubator/cxf/trunk/distribution/bundle/pom.xml Mon
> > Dec 17 06:51:43 2007 @@ -36,6 +36,7 @@
> > <properties>
> > <maven.test.skip>true</maven.test.skip>
> > <cxf.version>${pom.version}</cxf.version>
> > + <createSourcesJar>false</createSourcesJar>
> > </properties>
> >
> > <dependencies>
> > @@ -280,7 +281,7 @@
> > <configuration>
> >
> > <shadedGroupFilter>org.apache.cxf</shadedGroupFilter>
> > <shadedArtifactAttached>false</shadedArtifactAttached> -
> > <!--createSourcesJar>true</createSourcesJar--> +
> >
> > <createSourcesJar>${createSourcesJar}</createSourcesJar>
> > <promoteTransitiveDependencies>true</promoteTransitiveDependencies>
> > <createDependencyReducedPom>true</createDependencyReducedPom>
> >
> > @@ -327,6 +328,9 @@
> > <profiles>
> > <profile>
> > <id>deploy</id>
> > + <properties>
> > + <createSourcesJar>true</createSourcesJar>
> > + </properties>
> > <build>
> > <plugins>
> > <plugin>
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
Re: svn commit: r604886 - /incubator/cxf/trunk/distribution/bundle/pom.xml
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 18 December 2007, Glen Mazza wrote:
> Am Montag, den 17.12.2007, 22:17 -0500 schrieb Daniel Kulp:
> > Glen,
> >
> > The cxf-bundle module is designed to produce an "uber" jar which is
> > all the module jar combined into a single jar. That is the jar we
> > put by default in the lib directory. The issue is that, from
> > maven, there wasn't a good way to depend on the uber jar if you
> > wanted that dependency instead of all the individual jars. The
> > new version of the shade plugin solves that by doing a few things:
>
> Thanks for the explanation. BTW, what is the "shade" plugin, and why
> is it called "shade"? Googling isn't being very helpful here.
I just deployed the shade-plugins site. It JUST came out of the maven
sandbox so somethings aren't completely setup for it yet.
http://maven.apache.org/plugins/maven-shade-plugin/
Basically, it can do two things:
1) "roll up" a bunch of jars into an uber jar. This is harder to do
than it sounds. We have a bunch of XML files, extension files, etc...
that need to be merged together during the process.
2) It can "shade" or hide - ie rename - the packages of some of the
dependencies. We don't use this functionality, but basically it would
allow sucking in a jar and having it rename classes and stuff. Maven
is starting to do this for a lot of things. Maven "core" depends on a
certain version of various things like plexus-utils. However, plugins
might need a different version. Thus, with 2.0.7, the core "shades"
plexus-utils into a new package so the other plugins won't see it and
can use the versions they want.
I've THOUGHT about trying to use #2 to convert the saaj-impl jar into one
that would depend on xerces directly instead of the
com.sun.org.apache.xerces versions so that it would work on the IBM JDK.
The issue would be shipping that. I'd have to check the CDDL to see if
that's allowed or not.
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
Re: svn commit: r604886 -
/incubator/cxf/trunk/distribution/bundle/pom.xml
Posted by Glen Mazza <gl...@verizon.net>.
Am Montag, den 17.12.2007, 22:17 -0500 schrieb Daniel Kulp:
> Glen,
>
> The cxf-bundle module is designed to produce an "uber" jar which is all
> the module jar combined into a single jar. That is the jar we put by
> default in the lib directory. The issue is that, from maven, there
> wasn't a good way to depend on the uber jar if you wanted that
> dependency instead of all the individual jars. The new version of
> the shade plugin solves that by doing a few things:
>
Thanks for the explanation. BTW, what is the "shade" plugin, and why is
it called "shade"? Googling isn't being very helpful here.
Glen