Re: [tycho-user] can tycho be configured that the target that is configu

[Johan Compagner <jcompagner@xxxxxxxxxx>]

i like to build everything in dependently 

so i want to have different jobs not 1 big single job

Also if you do that with jenkins that would mean that locally the build would be again totally different

How todo it there

i just like to have a single build thing that you can do that i or any of my team can build a product locally (for testing stuff if they want)

or jenkins should be able to do this 

Also our product build is not done very often (only once at night for a nightly full build installer)

Normally we just build the plugins and generate a quick "update.zip" thats way faster, that only has some artifacts (plugins.jars) of the different repo's

update site creation (or usage) is really only done when we make an actual release..

also not every project that we have is really an eclipse plugin by itself (build fully the tycho way)

the manifest is osgi aware, has all the right properties, and later that is just used as a plugin.

So many git repo's don't really have a p2 site as output, but just a jar.. (plugin)

On Thu, 23 Apr 2020 at 14:07, Christoph Läubrich <laeubi@xxxxxxxxxxxxxx> wrote:

I'm still a bit uncertain about the setup, but maybe instead of
different jobs and workspace you could use one Jenkinsfile with multiple
checkouts inside?

Beside that, from a Jenkins point of view, your different jobs should
use archiveArtifacts (aka updatesites) as a build artifact and then
other jobs should pick them up via copyArtifacts, place them in the
local workspace and then use them as apropiate.

You might need different settings.xml for deifferent usage scenarios
(local vs CI-Server), I don't know if this is sufficent for your setup
but I often produces some kind of composite-update site that includes
everything that is build and deploy that on a central server.
Developers can this as a special "dev-target" and only need to import
the plugins they actually want to change.

Am 23.04.2020 um 13:57 schrieb Johan Compagner:
> problem with that is a bit that on jenkins and locally
> the git checkout is completely different..
>
> locally i have
>
> user.home\git\master\ all git repos here
> user.home\git\release\ all git repos here
>    user.home\git\special_branch\ all git repos here
>
> but on jenkins thats all in folders and folders have jobs and jobs have
> workspaces and in that workspace here is the checkout
>
> the first "folder" is the branch like master,release, special_branch
>
> so all the relative paths don't work over the 2 different things here
> what is in your example for me the $workspace? that can't be the root (
> user.home\git\master\) because then the path to the actual git repo is
> completely different locally then on jenkins...
>
> what you are trying to do could be solved transparently by Tycho....
> All the artifacts are with "install" installed to a predefined location
> per branch for me
> like the maven "<classifier>something</classifier>"
>
> so 1 shared branch all the git repo's have a parent pom that has that
> clasifier set, tycho uses that to install stuff into and get stuff from
>
>
> On Thu, 23 Apr 2020 at 13:48, Christoph Läubrich <laeubi@xxxxxxxxxxxxxx
> <mailto:laeubi@xxxxxxxxxxxxxx>> wrote:
>
>     I'd just like to add another option I used successfully with another
>     project of mine:
>
>     - define a target platform that uses the published p2-updatesites
>     - inside your branch/whaterver build use a settings.xml
>     - inside the settings.xml define for each of the p2 updatesites a
>     mirror-url that references your localy build update-site for example as
>     file:${workspace}/git-repo1/my-updatesite/target/site
>
>     Am 23.04.2020 um 12:25 schrieb Mickael Istria:
>      > If you want to constrain some versions between branches, I think
>     it's up
>      > to your plugin to define the right dependencies. If you use `mvn
>      > install`, then you break isolation and you let p2/tycho decide
>     what it's
>      > going to use. "Porosity" is a risk of `mvn install`; using it has
>     always
>      > been discouraged by Tycho developers since Tycho 0.1 and has been
>      > discourage by Maven developers has well for several months now
>      > If you need to orchestrate builds, then either you use "mvn
>     install" but
>      > with different p2 repos to have some isolation; or you can just
>     not use
>      > "mvn install" and build intermediary p2 repos (1 for each Git
>     repo) so
>      > the build can interoperate by reference the p2 repo from the other
>      > repository, or you can have a super pom to build everything at once.
>      > I really think that both p2 and Maven already have some means to
>     provide
>      > some isolation that you're looking for; so I don't think Tycho
>     needs to
>      > change here.
>      >
>      > _______________________________________________
>      > tycho-user mailing list
>      > tycho-user@xxxxxxxxxxx <mailto:tycho-user@xxxxxxxxxxx>
>      > To unsubscribe from this list, visit
>     https://www.eclipse.org/mailman/listinfo/tycho-user
>      >
>     _______________________________________________
>     tycho-user mailing list
>     tycho-user@xxxxxxxxxxx <mailto:tycho-user@xxxxxxxxxxx>
>     To unsubscribe from this list, visit
>     https://www.eclipse.org/mailman/listinfo/tycho-user
>
>
>
> --
> Johan Compagner
> Servoy
>
> _______________________________________________
> tycho-user mailing list
> tycho-user@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tycho-user
>
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tycho-user

--

Johan Compagner

Servoy