Maven Dependency Behaviour Orbit Package Type

There is a bunch of logic that Ivy uses to determine the correct extension as I understand it (and obviously mvnrepository.com is using comparable logic). There is a bug here...

https://issues.apache.org/jira/browse/IVY-899

...although I'm not sure whether it applies in this case.

yes, that looks like the issue to me, resolving as there is little we can do about it at the moment

I'm using this as a workaround
<dependency org="org.eclipse.jetty.orbit" name="javax.servlet" rev="2.5.0.v201103041518">
<artifact name="javax.servlet" type="orbit" ext="jar"/>
</dependency>

<dependency org="org.eclipse.jetty.orbit" name="javax.transaction" rev="1.1.1.v201105210645" >
<artifact name="javax.transaction" type="orbit" ext="jar"/>
</dependency>

<dependency org="org.eclipse.jetty.orbit" name="javax.mail.glassfish" rev="1.4.1.v201005082020" >
<artifact name="javax.mail.glassfish" type="orbit" ext="jar"/>
</dependency>

<dependency org="org.eclipse.jetty.orbit" name="javax.activation" rev="1.1.0.v201105071233" >
<artifact name="javax.activation" type="orbit" ext="jar"/>
</dependency>

I'm using Groovy's Grape so the workaround above isn't usable for me but I found out that using artifacts from the aggregate group instead works. This is my final configuration:

@Grapes([
    @Grab('org.eclipse.jetty.aggregate:jetty-server:8.1.2.v20120308'),
    @Grab('org.eclipse.jetty.aggregate:jetty-servlet:8.1.2.v20120308'),
    @Grab(group='javax.servlet', module='javax.servlet-api', version='3.0.1')])

I kinda disagree with the outcome here. Clearly the <packaging>orbit</packaging> is an abuse of the type of packaging. It is a jar packaging so it should be jar not orbit.

Maven documentation states:
"The valid types are Plexus role-hints (read more on Plexus for a explanation of roles and role-hints) of the component role org.apache.maven.lifecycle.mapping.LifecycleMapping. The current core packaging values are: pom, jar, maven-plugin, ejb, war, ear, rar, par. These define the default list of goals which execute to each corresponding build lifecycle stage for a particular package structure."

the packaging associated with 'jar' would not produce the jar in question here, the jar is built through an entirely different and somewhat alien incantation unique to eclipse orbit project...while I would like it to be jar it was not that easy to make happen an this approach addressed out immediate issues.

ideally at some point we'll have orbit goop published to central (which is a whole other nightmare of issues) so we can just use those, but for now this works fine and only mucks up other tooling which have ways to address it

its not ideal, but it is a whole lot better and brings us back to a reproducible build state that doesn't involve downloading jars with antrun scripting from non-durable orbit p2 repositories

I don't like this approach anymore then anyone else, but its functioning

Any ideas on this issue? Since I can't use this with ivy (my build system is sbt, which sits on top of ivy) I'm stuck back on Jetty 7.6.0.v20120127. So far I've been unsuccessful downloading the jar and faking out sbt. I don't have any issues resolving other jetty package dependencies.

Greg,

Are you sure you can't use the same workaround posted by Filipe Souza on 10th March? Looks like its a snippet from ivy, but it appears that you can inline ivy in sbt:

https://github.com/harrah/xsbt/wiki/Library-Management

Jan

I'd also like to see a workaround for this - I can not get it work with any of the hints above or elsewhere.

I tried it like this:
ivyXML :=
<dependency org="org.eclipse.jetty.orbit" name="javax.servlet" rev="2.5.0.v201103041518">
<artifact name="javax.servlet" type="orbit" ext="jar"/>
</dependency>
<dependency org="org.eclipse.jetty.orbit" name="javax.transaction" rev="1.1.1.v201105210645" >
<artifact name="javax.transaction" type="orbit" ext="jar"/>
</dependency>
<dependency org="org.eclipse.jetty.orbit" name="javax.mail.glassfish" rev="1.4.1.v201005082020" >
<artifact name="javax.mail.glassfish" type="orbit" ext="jar"/>
</dependency>
<dependency org="org.eclipse.jetty.orbit" name="javax.activation" rev="1.1.0.v201105071233" >
<artifact name="javax.activation" type="orbit" ext="jar"/>
</dependency>

libraryDependencies ++= Seq(
"org.eclipse.jetty" % "jetty-server" % "8.1.4.v20120524" intransitive(),
"org.eclipse.jetty" % "jetty-webapp" % "8.1.4.v20120524" intransitive(),
...
)

as well as using exlude() and many other possible combinations but either it does not find the orbit stuff or the servlet api jars doesn't make to the classpath.

For anyone else who is looking for a workaround with sbt 0.11.3. Further information can be found here: https://github.com/harrah/xsbt/issues/499