Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-user] how to force tycho to use a specific set of plugins from the local maven repo?


I don't really see how that would help

What i need is that i can say in the parent pom of my git repo (and i have about 10 repo's that will build 1 product)
What version it really should use of the other repo's where it depends on

I don't want to wipe everytime, beause then i need to build all the repo's constantly, that is horrible and would take quite some time (i only want to build repo's that are changed an then trigger out dependency jobs in jenkins to also build)

I now can work by adding that specific version in all of the manifest, so this stuff:

On master branch:


On dev branch:


and also the feature.xml has fixed versions.

But tycho should really find a way to be able to do what a local eclipse workspace product build also can do.

I think that can only be done if tycho would use the normal dependencies tag of maven, where i can say in a parent pom, IF you resolve foo.core then THIS is the version you need to get

Because if i can do this in a parent pom i only have to do it in 1 place not in many many manifest of all the plugins in that git repo.

I still don't see how all these other solutions would work, because on our jenkins i have multply branches and all those branches have multiply git repo's and they are all building when ever they want and see changes so many of them can build at the same time...

So clearing out stuff i don't see how that would help. 

Maybe a Nexus setup could help that all branches had there own p2 repo where they put stuff in and get from there? and all the parent poms of a branch have a specific p2 repo that they include to get the build artifacts of the other git repo's

Is there a good documentation how to set this up and how to use this?

Because in the end you really want to have feature builds also, so i can say to jenkinks quickly build and test a product that is build from these repo's with that branch and those repo's with that feature branch (not all repo's are touched by this feature only part)

This is really easy to do in a workspace like setup but in tycho this is just very hard if not quite impossible to do quickly

In my local eclipse environment i just branch 1 or 2 git repo's (that i know will change) keep the rest to "branchX" and then do the changes and commit, then with P2 export that we had i could build exactly that product in no time...

If i could just change parent poms of a git repo to fix dependencies, i could just also branch all the git repo's (like the one with the product/feature file)  and change only the parent pom in that one to use the version of the feature branch of the others..


On 4 October 2017 at 09:13, Sievers, Jan <jan.sievers@xxxxxxx> wrote:
> The CI system starts a build of master, but when foo.ui looks for the foo.core plug-in,
> it finds that the latest with version 8.3+ is the foo.core-8.4.0 that was built from dev in the local Maven repository.
> That’s the version it’s going to use.

I didn't follow the full discussion but Tycho has a switch to ignore locally installed artifacts:

just in case you may find that helpful.


On 02.10.17, 17:23, " on behalf of Tom Bryan (tombry)" < on behalf of tombry@xxxxxxxxx> wrote:

Yes, I do that, but that’s what causes the potential problem of picking up the wrong artifacts.  The confusing thing for Eclipse developers is that when I’m working locally in the IDE, all of the plug-ins are built from my local Eclipse
 workspace.  If I have multiple plug-ins (in my case, they’re from different Git repositories), I’ll get the version of all of those plug-ins from my local workspace.  On the other hand, when Tycho starts building a product, it builds all of the plug-ins separately
 and installs them to the local repository.  Then, as far as I understand, it builds the feature and packages the product, pulling plug-ins from the local Maven repository.  That means that the product may end up containing plug-in JAR files that we not built
 from the local workspace, such as in the example above. This is not a theoretical problem: my product definitely hit this issue.  We actually shipped our product with the wrong version of some of the dependent plug-ins.

I’ll try to explain what I think I’m seeing.

For example, let’s say that I have a foo.product file and a build job that builds the product and the other main plug-ins in the product: foo.ui, foot.core.tests, and foo.core.

Now, let’s say that I’ve released version 8.3 of the Foo product.  My master branch is basically still at that commit.  I’m working on an 8.4 maintenance release for Foo.  The code for this release is now on my dev branch. More importantly,
 version 8.4 of foo.core has some changes that won’t work correctly in the 8.3 release. The intent is for foo.ui-8.4.0 and foo.core-8.4.0 to ship together.

Let’s say that the foo.ui plug-in has the following dependency:
On master branch:
On dev branch:

Now, if a developer commits a new feature to dev, the CI system builds the Foo product and its plug-ins, all of which have Bundle-Version: 8.4.0. That builds fine, and I have a new Foo product version 8.4.0 that will be used in the unit
 tests.  The plug-ins with Bundle-Version: 8.4.0 are now installed to my local maven repository.

After that, a customer reports a critical bug on my 8.3.0 release.  We fix that bug and commit the hotfix to master, bumping the plug-in version to 8.3.1.  The CI system starts a build of master, but when foo.ui looks for the foo.core plug-in,
 it finds that the latest with version 8.3+ is the foo.core-8.4.0 that was built from dev in the local Maven repository.  That’s the version it’s going to use.

Actually, if you’re relying on the local maven repository, it’s easy to end up with a Foo 8.3.1 product build that includes foo.core-8.4.0. At least, that’s what we started seeing, and we worked around the problem by setting our dependencies
 in the MANIFEST.MF files like this:
On master branch:
On dev branch:

That’s the type of problem (and workaround) Johan Compagner was originally talking about. When I first hit this problem, the version management tooling didn’t really help with this type of dependency range specification, and I ended up
 writing my own scripts to bump versions across my MANIFEST.MF, feature.xml, and product files.

But even that approach doesn’t work well when I start looking at the possibility of multiple short-lived feature branches off of dev that need to be built and tested, where all of the plug-ins show version 8.4.0 even though I’m building
 different branches of code.  I really need to build the entire product from the branch that I just checked out without reference to the local maven repository.  That’s why I was interested in the approach that Henrik Steudel mentioned with the local p2-repository.


From: <> on behalf of Matthew Piggott <mpiggott@xxxxxxxxxxxx>
Reply-To: Tycho user list <tycho-user@xxxxxxxxxxx>
Date: Monday, October 2, 2017 at 9:42 AM
To: Tycho user list <tycho-user@xxxxxxxxxxx>
Subject: Re: [tycho-user] how to force tycho to use a specific set of plugins from the local maven repo?

I think you have to do this by configuring your CI to share artifacts between builds so Tycho can use artifacts found in the local maven repository.

On 1 October 2017 at 22:07, Tom Bryan (tombry) <tombry@xxxxxxxxx> wrote:

> > On 27 September 2017 at 11:59, Henrik Steudel <hst@xxxxxxxxx> wrote:
> >
> > did you already try to use P2-Repositories[1] as dependency source for
> > plugins from repo A instead of local Maven repository?
> >
> > So, build A in version 1 builds a P2 repo which is then fed to build B with
> > version 1. As this generated repo only includes exactly the plugin versions
> > you want, build B will not accidentially take version 2 bundles anymore.

Is that the recommended approach for avoiding this kind of version trouble?

I ended up using the approach that Johan outlines below, where I set the upper limit of the version.  That works well enough for now since my CI system only builds the dev and release branches, and I generally only have a few of those branches live at any given
 time, and they all have distinct version numbers.

But I imagine that my approach would break down quickly if I tried to make our CI system build all feature branches before they’re merged to dev (i.e., using a more standard git-flow / CI workflow).  In that case, setting the upper bound on the dependencies
 is going to be a little unworkable.  I think that I would still want to set the upper bounds on the dependencies to prevent the dependencies from drifting to the latest release, but I don’t think that we’d advance the version on each feature branch off of
 dev.  So, in that case, if the dev Bundle-Version: 8.3.0, then so are all of the feature branches off of dev. I want to make sure that the build for branch feature/bug-1234 is going to use the dependencies built from that same branch instead of the code from
 the feature/bug-4567 branch, even if the plug-ins on those two feature branches have the same.  You’re saying that you have the CI system build local, file-based p2-repositories for each plug-in and then have Tycho dependencies set up to use those p2 repositories
 instead of the local maven-based cache?

I’m assuming here that we’re talking about dependencies built from the same repository, such as foo.ui and foo.test depending on foo.core.


> From: Johan Compagner <jcompagner@xxxxxxxxxx>
> Reply-To: Tycho user list <tycho-user@xxxxxxxxxxx>
> Date: Wednesday, September 27, 2017 at 7:21 AM
> To: Henrik Steudel <hst@xxxxxxxxx>
> Cc: Tycho user list <tycho-user@xxxxxxxxxxx>
> Subject: Re: [tycho-user] how to force tycho to use a specific set of plugins
> from the local maven repo?
> Problem with that is that multiply git repo's with eclipse plugins (which
> normally would be in a workspace) are constantly being build and updated
> Those are going into the git repo, and for that i also need to push them
> constantly to a p2 repository?
> What is the maven/tycho command to really push all kinds of git repo's to the
> same local p2 repository (so constantly updating 1)?
> For now i just fixed it differently, in the manifest for a specific branch i
> now always include the bundle-version with a lower (including) and upper
> (excluding) bound version I need to do that for many plugins so that is not
> so nice..
> So for example if i have a branch:
> 8.2
> and
> 8.3
> then all the plugins in 8.2 will have references as: [8.2.0,8.3.0)
> that seems to work as far as i can test now.
> And i only need to change that once when i make a new main branch (but thats
> 1 time in half to a full year)
> As i said this is not so nice, what i would like to have that i can specify
> it once in the parent pom of a git repo like normal maven dependencies. That
> i can say exactly if you want to lookup this plugin use that version (or
> version range)

tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Johan Compagner

Back to the top