> -----Original Message----- > From: Stian Soiland-Reyes [mailto:st...@apache.org] > Sent: Friday, October 28, 2016 5:26 PM > To: Maven Users List <users@maven.apache.org> > Subject: Re: Strange result between "bundle" and "jar" type wrt javadoc > and dependency resolution > > Bundle is a special type used by the maven bundle plugin, which replaces > the normal jar with one augmented with OSGi metadata. > > It is also possible to augment the replaced JAR further, e.g. shadow > classes from other dependencies. > > When deployed, the result is still a *.jar, so it can be used as a > <type>jar dependency. To use the <type>bundle dependency would require > the maven bundle Plugin to intervene to still look up the jar, otherwise > Maven would look for a *.bundle file, which would not exist in the maven > repository. > > Therefore I think you should never need to specify <type>bundle within a > <dependency>.
At least this part confirms everything I thought I knew, so good. > httpclient-osgi is such a shadowed package, bundling several of the > httpclient libraries. One thing to be careful with on this particular > bundle is that it is not very useful from other Maven OSGi projects, as > the httpclient-osgi pom also has transitive dependencies on the > libraries which are also inside the httpclient-osgi jar. That might > cause some confusion for Javadoc with duplicate classes, or problems I'd > you get version mismatches. > > In > https://github.com/apache/jena/blob/master/apache-jena-osgi/jena- > osgi/pom.xml#L153 > we therefore had to use lots of exclusions. Ironically the o e > dependency of httpclient-osgi that *is* needed, httpcore-osgi, is NOT > declared in the pom of httpclient-osgi, so that must also be added with > similar exclusions. > > Now if your project is not itself an OSGi project and don't use > <packaging>bundle in its own pom, then you probably don't need > httpclient-osgi and can exclude it and use the regular httpclient > dependencies instead. This is an OSGi project, and the subproject with this dependency is producing a bundle. Besides httpclient-osgi, we also have a httpcore-osgi dependency (curiously, version 4.4, not 4.5.2). > On 28 Oct 2016 5:40 pm, "KARR, DAVID" <dk0...@att.com> wrote: > > > I have a subproject in a large multi-module project with the following > > dependency: > > -------------- > > <dependency> > > <groupId>org.apache.httpcomponents</groupId> > > <artifactId>httpclient-osgi</artifactId> > > <version>4.5.2</version> > > <type>bundle</type> > > </dependency> > > -------------- > > > > The project builds without error. > > > > I was working on implementing Javadoc generation in this tree. When I > > ran the "aggregate-jar" goal from the toplevel, it gave me an error > > saying it couldn't find this artifact. This was initially mystifying > > (and still is somewhat). > > > > We use an intranet Maven repo, so it's pulling from that instead of > > mavencentral. When I looked in the repo itself, I noticed that it had > > that artifact, but not the "bundle" type. It just had the plain jar > > (I assume I would see something in the directory saying it was a > bundle). > > > > When I looked in my local repo, it also only had the plain jar (I even > > cleared out the local repo and reran the build to regenerate it). > > > > I then tried commenting out the "type" property and also cleared out > > that section of the local repo. As before, the subproject built > without error. > > In addition, the toplevel Javadoc generation did not fail. > > > > It seems like the regular Maven dependency mechanism was happy with > > getting just the "jar" artifact, even though the dependency specified > > the "bundle" type, but the Javadoc generation would only work with the > > exact type as specified. > > > > I don't know if there's a bug here, but there's certainly something > > odd going on here. > > > > Can anyone explain what happened here? > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > >
