| Re: [tycho-user] how to force tycho to use a specific set of plugins from the local maven repo? |
> 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:
https://wiki.eclipse.org/Tycho/Target_Platform#Locally_ built_artifacts
just in case you may find that helpful.
Regards,
Jan
On 02.10.17, 17:23, "tycho-user-bounces@eclipse.org on behalf of Tom Bryan (tombry)" <tycho-user-bounces@eclipse.org 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:
foo.core;bundle-version="8.3"
On dev branch:
foo.core;bundle-version="8.4"
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:
foo.core;bundle-version="[8.3.0,8.4.0)"
On dev branch:
foo.core;bundle-version="[8.4.0,8.5.0)"
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.
---Tom
From: <tycho-user-bounces@eclipse.org > 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.
---Tom
> 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
tycho-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user