[tycho-user] how to force tycho to use a specific set of plugins from the local maven repo?

[Johan Compagner]

Hi,

i have this as a setup (i have even more git repo's but to keep it simple)

1> Git repo A eclipse plugins with version 1

2> Git repo B eclipse plugins with version 1 (this has also the .product
and .feature files)

B depends on plugins from A


maven is all setup, and mvn install will build all the plugins from A or B
And when i build B maven pickes up the plugins i build from A just fine

But now the problem, now i make a new branch on both git repo's and on both
i up the version to 2

With the product build itself i can fix the versions in feature.xml (and
use partly the tycho version push and my own regexp to fix all the the
versions in that)

If i now build version 2 of A and B that works,

But if i now go back to V1 branch and build B
Then B will pick up the latest versions of A (so version 2 plugins of A)
But it still should pickup version 1 of A because i am in version 1 of B

it seems that i only can fix that to set in the manifest of all the plugins
of B hardcoded:

*;bundle-version="[1.0.0,1.0.1)",*

where that 1.0.1 is a non existing version
But this is kind of horrible to maintain, or i need to write quite some
regexp to change all those bundle-versions of all the manifest files
(upping to a specific version and then also have a bogus version number
that is just 1 micro version up of the other...

Is there just not an easier way?
Like forcing the version in the (parent)pom.xml?
Which is also using the full version string so 1.0.0.somequalifier
Because that is what i now also use


For example tycho version push on the feature.xml does work for the plugins
of there own git repo, but it doesn't really just up all the plugins with
that version.
But that last one is fixable by going over it with a regexp find/replace


In Eclipse workspace itself this is all very easy, you just have that
workspace that tied everything together, P2 just builded a workspace what
was checked out there.
But with Tycho this is just different, how can you configure such a set of
many plugins over many git repo's all with specific versions? (and be able
to up those easy)

[Henrik Steudel]

Hi,

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.

Steps:

* mvn verify instead of mvn install
* adding a P2-repository definition (<repository>) into parent pom
which points to a URL file:/<PathToGeneratedRepository> (I used a
Maven profile for this to make it optional)
* -Dtycho.localArtifacts=ignore [2] (not necessarily required if
install goal is not executed anyway)


[1] https://wiki.eclipse.org/Tycho/eclipse-repository
[2] https://wiki.eclipse.org/Tycho/Target_Platform

Hope this helps/suits your usecase.
Kind regards
Henrik

Post by Johan Compagner
Hi,
i have this as a setup (i have even more git repo's but to keep it simple)
1> Git repo A eclipse plugins with version 1
2> Git repo B eclipse plugins with version 1 (this has also the
.product and .feature files)
B depends on plugins from A
maven is all setup, and mvn install will build all the plugins from A or B
And when i build B maven pickes up the plugins i build from A just fine
But now the problem, now i make a new branch on both git repo's and on
both i up the version to 2
With the product build itself i can fix the versions in feature.xml
(and use partly the tycho version push and my own regexp to fix all
the the versions in that)
If i now build version 2 of A and B that works,
But if i now go back to V1 branch and build B
Then B will pick up the latest versions of A (so version 2 plugins of A)
But it still should pickup version 1 of A because i am in version 1 of B
it seems that i only can fix that to set in the manifest of all the
*;bundle-version="[1.0.0,1.0.1)",*
 where that 1.0.1 is a non existing version
But this is kind of horrible to maintain, or i need to write quite
some regexp to change all those bundle-versions of all the manifest
files (upping to a specific version and then also have a bogus version
number that is just 1 micro version up of the other...
Is there just not an easier way?
Like forcing the version in the (parent)pom.xml?
Which is also using the full version string so 1.0.0.somequalifier
Because that is what i now also use
For example tycho version push on the feature.xml does work for the
plugins of there own git repo, but it doesn't really just up all the
plugins with that version.
But that last one is fixable by going over it with a regexp find/replace
In Eclipse workspace itself this is all very easy, you just have that
workspace that tied everything together, P2 just builded a workspace
what was checked out there.
But with Tycho this is just different, how can you configure such a
set of many plugins over many git repo's all with specific versions?
(and be able to up those easy)
--
Johan Compagner
Servoy
_______________________________________________
tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user

--
Entimo AG
Stralauer Platz 33 - 34 | 10243 Berlin | Germany
Tel: [phone] | Fax: [phone]
***@entimo.com | http://www.entimo.com/

Vorstand: JÃŒrgen Spieler (Vors.), Marianne Neumann
Aufsichtratsvorsitzender: Erika Tannenbaum

Sitz der Gesellschaft: Berlin, Germany | Handelsregister: HRB Berlin-Charlottenburg 85073

[Johan Compagner]

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)

Post by Henrik Steudel
Hi,
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.
- mvn verify instead of mvn install
- adding a P2-repository definition (<repository>) into parent pom
which points to a URL file:/<PathToGeneratedRepository> (I used a
Maven profile for this to make it optional)
- -Dtycho.localArtifacts=ignore [2] (not necessarily required if
install goal is not executed anyway)
[1] https://wiki.eclipse.org/Tycho/eclipse-repository
[2] https://wiki.eclipse.org/Tycho/Target_Platform
Hope this helps/suits your usecase.
Kind regards
Henrik
Hi,
i have this as a setup (i have even more git repo's but to keep it simple)
1> Git repo A eclipse plugins with version 1
2> Git repo B eclipse plugins with version 1 (this has also the .product
and .feature files)
B depends on plugins from A
maven is all setup, and mvn install will build all the plugins from A or B
And when i build B maven pickes up the plugins i build from A just fine
But now the problem, now i make a new branch on both git repo's and on
both i up the version to 2
With the product build itself i can fix the versions in feature.xml (and
use partly the tycho version push and my own regexp to fix all the the
versions in that)
If i now build version 2 of A and B that works,
But if i now go back to V1 branch and build B
Then B will pick up the latest versions of A (so version 2 plugins of A)
But it still should pickup version 1 of A because i am in version 1 of B
it seems that i only can fix that to set in the manifest of all the
*;bundle-version="[1.0.0,1.0.1)",*
where that 1.0.1 is a non existing version
But this is kind of horrible to maintain, or i need to write quite some
regexp to change all those bundle-versions of all the manifest files
(upping to a specific version and then also have a bogus version number
that is just 1 micro version up of the other...
Is there just not an easier way?
Like forcing the version in the (parent)pom.xml?
Which is also using the full version string so 1.0.0.somequalifier
Because that is what i now also use
For example tycho version push on the feature.xml does work for the
plugins of there own git repo, but it doesn't really just up all the
plugins with that version.
But that last one is fixable by going over it with a regexp find/replace
In Eclipse workspace itself this is all very easy, you just have that
workspace that tied everything together, P2 just builded a workspace what
was checked out there.
But with Tycho this is just different, how can you configure such a set of
many plugins over many git repo's all with specific versions? (and be able
to up those easy)
--
Johan Compagner
Servoy
_______________________________________________
To change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/tycho-user
--
Entimo AGStralauer Platz 33 <https://maps.google.com/?q=Stralauer+Platz+33&entry=gmail&source=g> - 34 | 10243 Berlin | Germany
Vorstand: JÃŒrgen Spieler (Vors.), Marianne Neumann
Aufsichtratsvorsitzender: Erika Tannenbaum
Sitz der Gesellschaft: Berlin, Germany | Handelsregister: HRB Berlin-Charlottenburg 85073

[Tom Bryan (tombry)]

Post by Henrik Steudel
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

Date: Wednesday, September 27, 2017 at 7:21 AM
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..
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)

[Matthew Piggott]

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.

Post by Johan Compagner

Post by Henrik Steudel
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

Post by Henrik Steudel
version 1. As this generated repo only includes exactly the plugin

versions

Post by Henrik Steudel
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

Date: Wednesday, September 27, 2017 at 7:21 AM
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..
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
https://dev.eclipse.org/mailman/listinfo/tycho-user

[Tom Bryan (tombry)]

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-***@eclipse.org> on behalf of Matthew Piggott <***@sonatype.com>
Reply-To: Tycho user list <tycho-***@eclipse.org>
Date: Monday, October 2, 2017 at 9:42 AM
To: Tycho user list <tycho-***@eclipse.org>
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.

Post by Henrik Steudel
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

Date: Wednesday, September 27, 2017 at 7:21 AM
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..
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-***@eclipse.org<mailto:tycho-***@eclipse.org>
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user

[Matthew Piggott]

I believe Tycho (and maven generally) prefers artifacts from the same
reactor. In general I think you do need specific version requirements on
your own plugin, otherwise on install p2 could resolve an invalid set of
bundles.

In case we're talking at cross-purposes, I'll give a suggested setup based
on ours:

- use a repository manager (Nexus, I work for Sonatype so biased here),
don't have a shared local m2 repo across all builds
- only builds from real (e.g. master, 4.x) branches should deploy to the
RM and should not allow concurrent builds
- use a share a local m2 between build stages and downstream jobs

I don't believe we have any explicit downstream jobs setup so I don't know
how easily you can configure build servers to consume from a feature but
not deploy, maybe you'd need them setup as stages or end up with job
duplication.

Post by Tom Bryan (tombry)
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.
foo.core;bundle-version="8.3"
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
foo.core;bundle-version="[8.3.0,8.4.0)"
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
*Date: *Monday, October 2, 2017 at 9:42 AM
*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.

Post by Henrik Steudel
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

Post by Henrik Steudel
version 1. As this generated repo only includes exactly the plugin

versions

Post by Henrik Steudel
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

Date: Wednesday, September 27, 2017 at 7:21 AM
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..
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
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user

[Tom Bryan (tombry)]

Date: Monday, October 2, 2017 at 12:03 PM

...

use a share a local m2 between build stages and downstream jobs

Thanks for the advice. Let me make sure that I understand this suggestion. Who shares the local m2 repository? All build jobs running on the same CI server? Or just an individual build job for the various artifacts generated and consumed during a single reactor? That is, are you saying that this local m2 repository is basically empty at the start of the build, and then it could be wiped at the end of the CI build process? That way, everything that gets installed to the local m2 repository is coming from your “repository manager” or from artifacts generated by the reactor.

Thanks,
---Tom

[Matthew Piggott]

Unfortunately build server terminology is ambiguous and varies by product
so here is what I'm using:

- Job - discrete top level object that has configuration for running a
build
- Build - an execution of a job
- Phase - step within a job (e.g. build, test, release)
- Downstream Job - job triggered by completion of another


Job configuration in build servers usually allows you to share folders
between phases of the build execution e.g. build & test. We don't really
use downstream jobs, but I assume build servers should allow you to share
downstream too but you should be careful the downstream job(s) don't deploy
(just a guess - downstream jobs may need to be duplicated or have a
variable to avoid deploying, see docs or lists for your build server).

Yes, the m2 repository should be wiped at the end of a build, the only time
the local m2 repository should be shared is when the job/stage needs to
explicitly consume the content that was produced in the previous step.
(e.g. test phase needs to consume the artifacts in build phase). With a
local repository manager proxying remotes there shouldn't be a significant
impact on build times.

Post by Tom Bryan (tombry)

Date: Monday, October 2, 2017 at 12:03 PM

...

use a share a local m2 between build stages and downstream jobs

Thanks for the advice. Let me make sure that I understand this
suggestion. Who shares the local m2 repository? All build jobs running on
the same CI server? Or just an individual build job for the various
artifacts generated and consumed during a single reactor? That is, are you
saying that this local m2 repository is basically empty at the start of
the build, and then it could be wiped at the end of the CI build process?
That way, everything that gets installed to the local m2 repository is
coming from your “repository manager” or from artifacts generated by the
reactor.
Thanks,
---Tom
_______________________________________________
tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user

[Sievers, Jan]

Post by Tom Bryan (tombry)
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-***@eclipse.org on behalf of Tom Bryan (tombry)" <tycho-user-***@eclipse.org on behalf of ***@cisco.com> 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-***@eclipse.org> on behalf of Matthew Piggott <***@sonatype.com>
Reply-To: Tycho user list <tycho-***@eclipse.org>
Date: Monday, October 2, 2017 at 9:42 AM
To: Tycho user list <tycho-***@eclipse.org>
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.

Post by Tom Bryan (tombry)

Post by Henrik Steudel
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

Post by Tom Bryan (tombry)
Date: Wednesday, September 27, 2017 at 7:21 AM
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..
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-***@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user

[Johan Compagner]

Hi,

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:

foo.core;bundle-version="[8.3.0,8.4.0)"

On dev branch:

foo.core;bundle-version="[8.4.0,8.5.0)"


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..



johan

Post by Tom Bryan (tombry)

Post by Tom Bryan (tombry)
The CI system starts a build of master, but when foo.ui looks for the

foo.core plug-in,

Post by Tom Bryan (tombry)
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.

Post by Tom Bryan (tombry)
That’s the version it’s going to use.

I didn't follow the full discussion but Tycho has a switch to ignore
https://wiki.eclipse.org/Tycho/Target_Platform#Locally_built_artifacts
just in case you may find that helpful.
Regards,
Jan
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.
foo.core;bundle-version="8.3"
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
foo.core;bundle-version="[8.3.0,8.4.0)"
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
Date: Monday, October 2, 2017 at 9:42 AM
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.

Post by Tom Bryan (tombry)

Post by Henrik Steudel
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

Post by Tom Bryan (tombry)

Post by Henrik Steudel
version 1. As this generated repo only includes exactly the plugin

versions

Post by Tom Bryan (tombry)

Post by Henrik Steudel
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

Post by Tom Bryan (tombry)
Date: Wednesday, September 27, 2017 at 7:21 AM
Subject: Re: [tycho-user] how to force tycho to use a specific set of

plugins

Post by Tom Bryan (tombry)
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

Post by Tom Bryan (tombry)
same local p2 repository (so constantly updating 1)?
For now i just fixed it differently, in the manifest for a specific

branch i

Post by Tom Bryan (tombry)
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

Post by Tom Bryan (tombry)
so nice..
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

Post by Tom Bryan (tombry)
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

Post by Tom Bryan (tombry)
it once in the parent pom of a git repo like normal maven dependencies.

That

Post by Tom Bryan (tombry)
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
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user

[Johan Compagner]

Hi,

thx for that link, the thing is that that "locally_build_artificats" is not
directly usefull to me
But then i did see the the section just below that:

https://wiki.eclipse.org/Tycho/Target_Platform#Filtering

that's exactly what i want and i describe in my previous email..

And i tested this and that works just fine, the thing is that for all the
git repo's i use for many plugins the same version (and i have a version
push over all the git repo's to set the project version and the manifest
stuff)
So i can just do for most of my plugins this:

<filter>
<type>eclipse-plugin</type>
<id>sablo</id>
<restrictTo>
<version>${project.version}</version>
</restrictTo>
</filter>

So the project version of my main parent pom.xml of 1 git repo just fixes
all the plugins to its own version.
This way i only have to push a new version for my specific branches or
feature branches and the
: <artifactId>target-platform-configuration</artifactId>
will force that tycho uses the right plugins for compiling this, and i
guess it will also use that for building the product

So this way i don't need to have it in all the different manifest of all
the plugins, but just in 1 place of a parent git. (and i kind of never have
to change those version that can just be the same as the parent pom version)
I only need to make sure that that does list all the stuff that all the
plugins do reference, but that doesn't change that often.

johan

Post by Tom Bryan (tombry)

Post by Tom Bryan (tombry)
The CI system starts a build of master, but when foo.ui looks for the

foo.core plug-in,

Post by Tom Bryan (tombry)
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.

Post by Tom Bryan (tombry)
That’s the version it’s going to use.

I didn't follow the full discussion but Tycho has a switch to ignore
https://wiki.eclipse.org/Tycho/Target_Platform#Locally_built_artifacts
just in case you may find that helpful.
Regards,
Jan
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.
foo.core;bundle-version="8.3"
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
foo.core;bundle-version="[8.3.0,8.4.0)"
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
Date: Monday, October 2, 2017 at 9:42 AM
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.

Post by Tom Bryan (tombry)

Post by Henrik Steudel
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

Post by Tom Bryan (tombry)

Post by Henrik Steudel
version 1. As this generated repo only includes exactly the plugin

versions

Post by Tom Bryan (tombry)

Post by Henrik Steudel
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

Post by Tom Bryan (tombry)
Date: Wednesday, September 27, 2017 at 7:21 AM
Subject: Re: [tycho-user] how to force tycho to use a specific set of

plugins

Post by Tom Bryan (tombry)
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

Post by Tom Bryan (tombry)
same local p2 repository (so constantly updating 1)?
For now i just fixed it differently, in the manifest for a specific

branch i

Post by Tom Bryan (tombry)
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

Post by Tom Bryan (tombry)
so nice..
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

Post by Tom Bryan (tombry)
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

Post by Tom Bryan (tombry)
it once in the parent pom of a git repo like normal maven dependencies.

That

Post by Tom Bryan (tombry)
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
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user