Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-user] [EXTERNAL] Re: Need info about mirroring maven artifacts in a p2 mirror with Nexus

You could use the maven-dependency-plugin to dynamically pull those dependencies from a standard M2 repo, and then package them into your bundle jar with a Bundle-Classpath header to include those extra jar files. This also requires setting Eclipse-BundleShape header to "dir" in your manifest so your plugin is extracted into a folder when installed into a product.

The Nexus P2 metadata feature is useful if you're doing a 'mvn deploy' of an OSGi compliant bundle or feature jar. It reads the metadata in the jar files and publishes them to a P2 repo inside the Maven repo. It doesn't support extra p2.inf requirements though (at least it didn't in my case), and the bug I field was closed as WONTFIX because that functionality was only beta and the comment implied a big internal rewrite that would obviate it. However they wouldn't provide any further information. 

To use pomDependencies=consider the dependencies in the Maven repo have to already be OSGi bundle jars. You can have a separate Maven project which depends on the non-OSGI jar, uses bundle-maven-plugin to produce an OSGi version, 'mvn deploy' that, and then your eclipse-plugin project can list the modified version as a standard maven pom dependency in conjunction with pomDependencies=consider. There is no transitive resolution of these dependencies, and you'll still have to list the dependency in your manifest too.

> -----Original Message-----
> From: tycho-user-bounces@xxxxxxxxxxx [mailto:tycho-user-
> bounces@xxxxxxxxxxx] On Behalf Of David M. Karr
> Sent: Tuesday, March 08, 2016 12:49 PM
> To: Tycho user list
> Subject: [EXTERNAL] Re: [tycho-user] Need info about mirroring maven
> artifacts in a p2 mirror with Nexus
> On 03/08/2016 10:28 AM, Tom Bryan (tombry) wrote:
> > I don't remember your original use case, but is the problem you're
> > hitting similar to this user's situation?
> >
> 3A__stackoverflow.com_
> > questions_35346113_using-2Dthird-2Dparty-2Dlibraries-2Din-
> 2D&d=CwICAg&
> > c=PskvixtEUDK7wuWU-
> tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OV
> > ZL1uyui4QoEmBCjCmEiTk&m=5KhxhnQhnyctf3V1EaF89bva189AfbJ-
> cixX8Rplgy4&s=
> > lXkou9wjJu-b6MRCwKJbKLpLF0QCXw3WlFT0f-iiuto&e=
> > eclipse-rcp-tycho-app/
> > I think that my reply on that thread explains the current state of
> > affairs and the problem bridging between Eclipse and Tycho on one hand
> > and normal Maven artifacts and dependencies on the other.
> I guess my situation is similar to that, yes.
> The present build just "hard-stores" the jars in the project and references
> them in the classpath in the manifest. I need to remove them from the
> project itself and replace them with some sort of declarative dependencies,
> as I can't store jars in our git repo (it's a project policy, but I agree with it).
> >
> > The problem is that even if you could automatically convert a JAR to
> > an Eclipse plug-in and add it to the Maven repository, you're still
> > going to have to reference that specific plug-in in your Eclipse
> > plug-in that uses that library, right?  Are you just hoping to create
> > some automation that follows the Maven dependency tree for some
> > specific artifact and then creates an equivalent set of Eclipse
> > "library plug-ins" with the correct transitive references?  Once you
> > do that, your developers will still need all of those plug-ins in their local
> development environments, right?
> I had assumed that once the jars I need are properly OSGi-configured into
> the Nexus p2 repo, I can specify that repo in my target platform, along with
> the dependencies I need, and then my code will be able to use those classes.
> Is there anything else I need?
> >
> > Tycho is great for handling Eclipse bundles, but as soon as you try to
> > include a complex third party (JAR) library into your RCP application,
> > you hit this problem.  It would be great if Tycho users could help
> > articulate what a workable solution would look like.  That way, maybe
> > someone can solve that problem so that we don't have a bunch of
> > different software teams having to work around this disconnect between
> > the Maven world and the Eclipse-tycho world.
> >
> > ---Tom
> >
> > On 3/8/16, 12:53 PM, "tycho-user-bounces@xxxxxxxxxxx on behalf of David
> M.
> > Karr" <tycho-user-bounces@xxxxxxxxxxx on behalf of
> > davidmichaelkarr@xxxxxxxxx> wrote:
> >
> >> A while ago, I asked questions in here (and other channels) about my
> >> Eclipse plugin build, using Tycho, which was "hard-storing" some
> >> maven artifacts in the project instead of specifying them
> >> "declaratively".  I tried for quite a while to figure out how to
> >> specify them as Maven dependencies, but I never got it to work.
> >>
> >> I started to understand that the only way to get this to work was to
> >> be able to access those artifacts in a p2 repository, so I can
> >> specify those dependencies in my target platform.  The administrator
> >> of the Nexus server that I use has been working on this, but he's
> >> telling me that the artifacts mirrored in this repository have to be OSGi
> bundles.
> >> A "plain" Maven artifact jar won't work.
> >>
> >> I'm now understanding that it's straightforward to "augment" an
> >> existing Maven artifact with the appropriate META-INF/MANIFEST.MF
> >> file to have it be recognized and properly used as an OSGi bundle.
> >> This can be done at build time with the "maven-bundle-plugin", but
> >> Nexus also has the ability (I don't know the details yet) to
> >> semi-automatically add manifest info to artifacts so they can be used in a
> p2 repo.
> >>
> >> However, I'm also hearing that even if the artifact is a valid OSGi
> >> bundle, it won't properly work in a p2 repo unless it can somehow see
> >> "features".  What do I have to do to plain Maven artifact jars to
> >> make them usable in an Eclipse plugin build as repository targets in
> >> a target platform specification?
> >>
> >> _______________________________________________
> >> tycho-user mailing list
> >> tycho-user@xxxxxxxxxxx
> >> To change your delivery options, retrieve your password, or
> >> unsubscribe
> > >from this list, visit
> >>
> >> mailman_listinfo_tycho-2Duser&d=CwICAg&c=PskvixtEUDK7wuWU-
> tIg6oKuGYBR
> >>
> brMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk
> &m=5Khxh
> >> nQhnyctf3V1EaF89bva189AfbJ-
> cixX8Rplgy4&s=ni2u4HPqgrBZTJ7T0YDLFXCOOBsZ
> >> vWVu6ULTBdsWOeg&e=
> >>
> >
> > _______________________________________________
> > tycho-user mailing list
> > tycho-user@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or
> > unsubscribe from this list, visit
> >
> 3A__dev.eclipse.org_m
> > ailman_listinfo_tycho-2Duser&d=CwICAg&c=PskvixtEUDK7wuWU-
> tIg6oKuGYBRbr
> >
> MXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&
> m=5KhxhnQh
> > nyctf3V1EaF89bva189AfbJ-
> cixX8Rplgy4&s=ni2u4HPqgrBZTJ7T0YDLFXCOOBsZvWVu
> > 6ULTBdsWOeg&e=
> _______________________________________________
> tycho-user mailing list
> tycho-user@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> 3A__dev.eclipse.org_mailman_listinfo_tycho-
> 2Duser&d=CwICAg&c=PskvixtEUDK7wuWU-
> tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoE
> mBCjCmEiTk&m=5KhxhnQhnyctf3V1EaF89bva189AfbJ-
> cixX8Rplgy4&s=ni2u4HPqgrBZTJ7T0YDLFXCOOBsZvWVu6ULTBdsWOeg&e=

Back to the top