Missing p2 repo for Jetty 9.4.11

[akurtakov]

Jetty 9.4.11 seems to be released (although no announcement mail but listed as download) but the p2 repo doesn't contain it (http://download.eclipse.org/jetty/updates/jetty-bundles-9.x/) . Please publish it.

[WalkerWatch]

I ran the builds last week for both this and the 9.3 version we released but it looks like they failed. Looking into this now and will let you know when they are available.

[WalkerWatch]

@janbartel I am getting the following error when trying to build any of the P2s:

[ERROR] Picked up JAVA_TOOL_OPTIONS: -Xmx2G -Djava.io.tmpdir=/tmp/genie.jetty

Any thoughts?

https://hudson.eclipse.org/jetty/job/jetty-rt-bundles-9/110/console

[janbartel]

@WalkerWatch looks like the signing tool the build uses is no longer installed on the machine? I've had to open a bug with Eclipse infra: https://bugs.eclipse.org/bugs/show_bug.cgi?id=535786

[guw]

@janbartel I had a look at the build and I'm afraid the changes are larger then anticipated. Your current OSGi build creates an update site, zips it, pushes it through signing and then fixes some checksum in the result.

However, the CBI jar signer plug-in can only sign one jar at a time. It does not sign a whole update size at once. It needs to run when building each jar. Thus, I need to come up with a different approach of building the OSGi site. Is that acceptable?

[joakime]

@guw any improvements to the OSGi / p2 layers are always acceptable. 👍

[janbartel]

@guw starting afresh with the build is totally acceptable :)

[guw]

Ok, I'm working on something using EBR. One question, is there value in keeping the org.eclipse.jetty.osgi artifacts? The versioning seems to be off and I'm wondering who is using this.

[guw]

@janbartel Do you know where I can find the dependencies for an OSGi build?

Specifically I'm failing at this point:

org.eclipse.jetty.annotations requires 'java.package; org.objectweb.asm [6.2.0,7.0.0)'

I tried resolving it from Orbit but Orbit only has version 6.1.1.

[jmcc0nn3ll]

@guw it is issues like that which cause me to think this shouldn't be something we produce ourselves anymore, I suspect we pull it from maven central. We have all the relevant CQ stuff handled but from an osgi functionality perspective if none of us use it for anything then we are only ever going to be playing catchup and wack-a-mole.

Would it make sense for a user like you or @akurtakov to just slurp Jetty into Orbit? That way there would be a place where dependencies actually resolved with the Jetty releases.

[guw]

Some of the dependencies aren't in Orbit. Thus, we have to add them to Orbit, too. I don't actually care where it's published - Orbit downloads or Jetty downloads.

The benefit of running it within the Jetty build would be up-to-date OSGi bundles. The benefit of adding it to Orbit would be a reduced set of artifacts, i.e. we likely won't need to bring in everything. However, we still need to build OSGi artifacts for the dependencies needed by Jetty.

Do you also want to get rid of building the manifests during your regular builds?

@akurtakov Do you have a list of bundles you would like to consume?

[jmcc0nn3ll]

IMO nothing changes with our manifests, we produce those for folks that consume out of maven central for osgi purposes. My comment was specifically in regards to the p2 repositories which we only really ever entered into for the release train which we haven't been involved in for years now. Now that the signing stuff and our old setup has expired it hardly makes sense for us to keep supporting it.

[janbartel]

@guw I'm afraid that a lot of the dependencies do not exist in Orbit: we resolve them during the build against maven central. Currently the jetty jars during the build contain suitable manifest osgi headers. I'd like to keep it that way, rather than produce another whole parallel build of different artifacts - unless there's a great reason to do it that way.

[guw]

@janbartel Understood. The main difference is a change in the signing process. Jetty had a custom Maven plug-in that was able to take an unsigned p2 repo, sign all the jars in it and fix the jar checksums afterwards.

The CBI jarsigner is intended to run as part of the jar build, i.e. it takes a single jar and submits it for signing to the signing service. Thus, the jarsigner would need to run as part of the regular jar build if you don't want to produce another parallel build of signed artifacts.

[janbartel]

Just to make sure we're all on the same page: if we were to add in the jarsigning step to the main jetty build, then each of our normal jar files will also be signed. We would then change the existing, separate osgi build script to use these pre-signed jars to build the p2 repo with, correct?

Is the jar signing plugin relatively fast I wonder? Our builds have been getting longer and longer so if this is a slow process then that might be an issue. Otherwise, are there any other ramifications to introducing this signing phase into our normal builds?

[guw]

if we were to add in the jarsigning step to the main jetty build, then each of our normal jar files will also be signed. We would then change the existing, separate osgi build script to use these pre-signed jars to build the p2 repo with, correct?

Correct. I believe this will work. I'll do some further testing, though.

Is the jar signing plugin relatively fast I wonder?

It's still an additional roundtrip to the signing service per jar. How/where are you performing release builds? It would be possible to make this a profile that does not run with every verification build (not even snapshots). It only needs to run for release builds that get pushed to Maven Central (or which ever repo you are deploying to).

[jmcc0nn3ll]

@janbartel I don't think we want to add anything that would be specific for Eclipse to the main jetty build, there is no point in putting these signed artifacts into Maven Central on release, they would have to go in as some sort of classifier artifact since they would not be generally interesting. A bespoke build could be created that would checkout Jetty and run some profile that would produce signed builds but again that would all be bespoke. IMO anything that comes out of this should be from the perspective of what someone outside of the Jetty project would go through to put Jetty into their product which is why I was thinking Orbit might be a good fit.

[janbartel]

@guw do we need to pack as well as sign each jar from the normal jetty build, or could we just sign the jar? I don't see the harm in signing the jetty jars that we push up to maven ...

[jmcc0nn3ll]

@janbartel We could sign them with our own keys but the ones that eclipse uses have to be signed by their foundation keys which are only available on their build servers. I opened a bug to allow web of trust style signing years ago where they could sign our build gpg keys but it never went anywhere.

[jmcc0nn3ll]

@guw What would it look like for us to just integrate with you and the osgi world through Orbit? The fact of the matter is that we are really no different than any other third party dependency in maven central when it comes down to it. If we just use orbit as the integration point then we should pick up all the basic requirements by virtue of being assembled in that integration point.

[guw]

@jmcc0nn3ll If you go the Orbit way then nothing needs to be done from your side. It would be a pull setup. Every time someone wants to use a newer Jetty version from within another Eclipse project they would need to update the recipes in Orbit.

I think pack200 is not required in your case. It's still mandatory for the common repository. But that doesn't need to be your concern and pack200 will be deprecated soon anyway. Signing with your own keys should be fine, too.

[gregw]

Gunnar,

So if we don't need to pack200 and we can sign with our own keys, then surely we should be able to simply create p2 repos more or less as we have always done, just not doing the unpacking/packing/eclipse signing steps - ie can't a script be written that takes our signed artifacts from maven and puts them into a p2 update site, which can be run after every release?

Or is this what Orbit is? If our artifacts are put into Orbit will it appear as a jetty update site - ie something you can point a software installer at and it will list the jetty bundles/features?

cheers

On 21 June 2018 at 10:33, Gunnar Wagenknecht notifications@github.com wrote:

@jmcc0nn3ll https://github.com/jmcc0nn3ll If you go the Orbit way then nothing needs to be done from your side. It would be a pull setup. Every time someone wants to use a newer Jetty version from within another Eclipse project they would need to update the recipes in Orbit.

I think pack200 is not required in your case. It's still mandatory for the common repository. But that doesn't need to be your concern and pack200 will be deprecated http://openjdk.java.net/jeps/336 soon anyway. Signing with your own keys should be fine, too.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/eclipse/jetty.project/issues/2639#issuecomment-399021370, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEUrT2FsLzowrjd4JNuaPtKRClmCITYks5t-1pegaJpZM4UflS6 .

-- Greg Wilkins gregw@webtide.com CTO http://webtide.com

[jmcc0nn3ll]

Last time I looked at Orbit you needed to check in the binary files and the manifest files in a certain way in CVS and then the orbit build would do its magic to prepare the p2 repository. I am pretty sure they move to git sometime back. My biggest issue is the specific step of the creation of that p2 repository, I do not feel comfortable with the Jetty project producing it anymore and have not for some time since we left the release train, there are people relying on it for production use cases and we have no horse in that race. Far better for someone with a vested interest in using p2 repositories to curate Jetty's presence based on the content we deploy into maven central. I am all for signing jars if that helps the process and it is meaningful (and not just stripped away to be later signed by eclipse foundation keys via some other process which is what I thought Orbit did).

I think I am still an orbit committer and am happy to help get the first deployment into orbit going for Jetty if that is the best integration point. Would being there fulfill the normal osgi requirements @guw and @akurtakov?

[akurtakov]

Orbit has been designed for non-Eclipse.org projects with CQs (IP-team intervention) and etc. for each addition to it. IMHO having a plain recipes built producing p2 repo would be nice and as Gunnar is the main power behind it and Roland will help with this one too can't we convince Jetty project to still keep this build but fixes and etc. to it being done from the current Orbit maintainers in the same way Orbit builds ?

[jmcc0nn3ll]

I think the moral here is that we are happy to support a domain expert in their usage of p2 in making sure that Jetty is exposed properly for osgi users. If @guw will be on point as subject matter expert on p2 for Jetty then just give us some marching orders on how you want to see it done and we'll help get things there. I had thought orbit might be the best approach since it seems to be a common collection point for projects not producing p2 repositories but we are not married to any one way to do it. This really shouldn't be that complex of a problem to solve and starting over with new process might be the best approach since all the old cruft associated with the release train is no longer relevant or even supported.

So, experts on p2 and consuming things from an osgi perspective...how do you want to see it done? Once we know how you want to consume jetty we can iron out the technical details.

[nickboldt]

If the core problem is "we can't do signing anymore because the commandline jarsigner was removed in favour of the maven plugin" then perhaps the solution is "use maven, configured with the eclipse jar signer mojo, to sign each plugin as it's built."

That way your update site build is just an aggregation of the already-built artifacts. Whether you then decide to push bundles to Orbit or publish your own update site, you'll have signed artifacts, done the Official Supported Eclipse Way.

Point me at your Jenkins job (where you build) and the maven config (ie., the root/orchestrator pom.xml in github), and I'll have a look at updating your 9.4.x build to use the new mojo.

Here's how you enable eclipse's signing process (via the eclipse-sign profile):

http://git.eclipse.org/c/datatools/org.eclipse.datatools.git/tree/pom.xml#n279

[jmcc0nn3ll]

@nickboldt We don't build release artifacts on eclipse infrastructure so a requirement to do that would be a non-starter and will not happen. However, If the jar can be signed by non-foundation developer keys we can likely accommodate, we can put that into our existing release process and push those artifacts into maven central (after a bit of validation that it doesn't impact anything else in our pipeline). I brought up the idea of distributed signing many years ago in this issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=354756 here. However, Wayne had said in that issue that signing jars was not a requirement so I am not sure we even need to do that here unless I am missing something?

Anyway, the existing, now defunct, way was to pull the artifacts from maven central and then massage them into a form suitable for a p2 repository.

The stock jetty build is this repository, but the current p2 generator is:

http://git.eclipse.org/c/gerrit/jetty/org.eclipse.jetty.releng.bundles.git/

The jetty p2 builds are here:

https://ci.eclipse.org/jetty/

[guw]

@jmcc0nn3ll @nickboldt Signing is a formal requirement when participating in the release train repository. Jetty is not by itself but Platform/Equinox is using it. Thus, someone has to do the signing. :)

Anyway, I was looking into a couple different options.

1. Continue with the current approach but skip sining.
2. Continue with the current approach but use externally signed artifacts from central.
3. Separate EBR build that fetches jars from central and signs them with Eclipse certificate
4. New CBI Maven extension that can (recursively) sign a whole p2 repository (and then extend scenario 1 with that)

I'm not sure how option 2 behaves. The Eclipse signing certificate uses a root CA that is part of the JRE and therefore trusted out-of-the-box. I guess developer keys will not.

[rgrunber]

I've created a jetty-releng job (https://ci.eclipse.org/linuxtools/job/jetty-releng/) (temporarily under the linuxtools jobs) that : 1) Clones jetty.project, applies a patch to support signing on enablement of "eclipse-sign" property. 2) Builds/Installs the modified jetty.project locally with bundle signing 3) Clones org.eclipse.jetty.releng.bundles and modifies references to point to the versions of the installed jetty.project bundles now available in the local repository 4) Builds the releng project and archives the resulting repository

I don't have it uploading to a downloads location yet but that could easily be done since the JIPPs have access.

Is https://ci.eclipse.org/linuxtools/job/jetty-releng/lastSuccessfulBuild/artifact/org.eclipse.jetty.releng.bundles/jetty.bundles.repo/target/site/ more or less what's needed for update site consumers ?

If I could get permissions to a JIPP under the jetty project, I could set this up.

[jmcc0nn3ll]

@rgrunber Neat! To be clear though the artifacts produced by this would be what was based on a specific git tag and not the published artifacts in Maven Central right? They are technically the same thing from a source perspective but compiled with different JVMs, etc.

I would also like to know if consumers of these things are fine with that distinction as well? If so then I don't see it being difficult to get you access.

[rgrunber]

@jmcc0nn3ll, Yes. The artifacts of this build are rebuilds of a specific tag (in jetty.project) and not the ones from maven central. Open to hearing what people think of this approach (at least for the time being..)

[joakime]

Is this P2 repository expected to contain the Java 9+ specific code and artifacts? (such as the Java 9+ ALPN support libraries?)

[akurtakov]

@jmcc0nn3ll From Eclipse Platform POV there is slight preference towards having the same artifacts signed. On the other side in Fedora we are using Jetty rebuilt from source for years without any issues. Also 9.4.11 fixes CVEs so whatever we can take now is better than waiting for some theoretical better solution. :)

[akurtakov]

Reopened as I closed it by mistake.

[akurtakov]

Is there a chance that we can get 9.4.11 repo with Roland's current proposal and discussion for the future can continue? It would be nice if we can ship 4.9 M2 without the CVEs in 9.4.10.

[jmcc0nn3ll]

I am fine with it, @janbartel?

[janbartel]

Apologies but I don't have access to a proper development environment at the moment, but from what I can tell the proposed build looks ok. So long as it contains as a minimum the same artifacts as the old build it should be good.

[akurtakov]

So can someone give Roland access to Jetty jipp so he can copy the job? It must be there for the sake of access to download location.

[akurtakov]

For the record what Roland needs access to is https://ci.eclipse.org/jetty/

[joakime]

This was setup for https://ci.eclipse.org/jetty/job/jetty-rt-bundles-9/

Will that work?

[rgrunber]

Yes, I believe it should. I can configure this job to serve as builder + publisher for jetty 9 branch. Also if ever required, the configuration for the current (failing) job can always be restored or copied over if it's ever needed.

[rgrunber]

I've built 9.4.11 and simply re-used the post-tycho.sh script to publish it at http://download.eclipse.org/jetty/updates/jetty-bundles-9.x/9.4.11.v20180605/

Development builds can also take place now at http://download.eclipse.org/jetty/updates/jetty-bundles-9.x/development/ . The parameters to the build for now, are the branch/tag and the jetty_release_version which is basically the name of the folder that will contain the build (if empty, it'll be a development build).

There's still one patch I need to push into jetty.releng (currently applied in the JIPP) to complete things.

[jmcc0nn3ll]

@rgrunber anything else here we need to do or can we close this issue out? And thank you for your efforts here, happy to see the progress!

[rgrunber]

I think this issue can be closed out as there now exists a 9.4.11 p2 repository with signed bundles hosted at Eclipse under the Jetty project, and we now have a way to generate them more easily.

The situation can certainly be improved by consuming the jetty bundles deployed to maven central but for now rebuilding should provide pretty much the same thing.

[jmcc0nn3ll]

Sounds good, thanks @rgrunber!