Bugzilla – Full Text Bug Listing
| Summary: | Eclipse signing Plug-in | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Technology] Dash | Reporter: | Jesse McConnell <jesse.mcconnell> | ||||
| Component: | Maven | Assignee: | David Carver <d_a_carver> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | caniszczyk, david_williams, d_a_carver, kaloyan, pwebster, wayne.beaton, webmaster | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Jesse McConnell
Created attachment 192881 [details]
eclipse signing plugin
To make life easier, can we just say this is only available under the EPL? Or does it being dual licensed is important to you? btw, thanks Jesse! I could not care less, its just what was on it and since it was written/'cobbled together' entirely by eclipse committers imo there is little reason for the CQ process, that and it could be clean roomed in an hour easy. Is the embedded org.eclipse.equinox.p2.jarprocessor modified in any way, or is it just taken directly from p2? its stock, I used it to get around the hassle of finding a copy on the build server and originally to support packing and repacking in place to speed things up when there was remote signing support (In reply to comment #5) > its stock, I used it to get around the hassle of finding a copy on the build > server and originally to support packing and repacking in place to speed things > up when there was remote signing support Great. We can pull this in as part of the build, but I'll exclude it from the contribution. I'm checking with Sharon to see what we need to do regarding making this exclusively EPL (I think she's at lunch). Jesse, can you list the names of the folks who contributed along with an estimate of the percentage they contributed to this code? I'll look up the rest of the contact information from our database (you said that they were all committers). We'll need this information as part of the provenance check. Hugues Malphettes 5% Michael Gorovoy 5% both jetty committers pretty much just a couple of lines here and there, this thing isn't that complex (In reply to comment #8) > Hugues Malphettes 5% > Michael Gorovoy 5% > > both jetty committers > > pretty much just a couple of lines here and there, this thing isn't that > complex Can I assume you mean 50% ? Or is it 90% template (I have no experience with Maven Plug-ins)? oh, I wrote the rest, sorry Check-in is approved. Who wants to create the Git repo and do the check-in? Anyone? I'd do it but I don't think I'm a dash committer. Getting this in place is a high priority for me because I don't want to sign things manually anymore :) (In reply to comment #13) > I'd do it but I don't think I'm a dash committer. Getting this in place is a > high priority for me because I don't want to sign things manually anymore :) Wayne what's the Dash git repository location. Do we have one created? If not can you create an initial blank repo, and I'll move the signing plugin in, and we probably should have a build for this on Hudson as well. I can then look at setting up the necessary deployment items to the Nexus instance to make the snapshot available for testing by Chris. We have some space on /gitroot/ to create repo of our choosing. Unfortunately, neither Chris nor Dave are committers on Dash. Please confirm that you will be the ones who will support this component moving forward and I'll initiate the necessary elections. I think we'll use this opportunity to structure how we present Dash a bit. I really don't want to create a new project for every bit of committer-related technology we create, so creating and maintaining new technology directly under the Dash banner makes sense to me... (In reply to comment #15) > We have some space on /gitroot/ to create repo of our choosing. > > Unfortunately, neither Chris nor Dave are committers on Dash. Please confirm > that you will be the ones who will support this component moving forward and > I'll initiate the necessary elections. I will support this code as it's needed by EGit/JGit and other eclipse.org projects I'm involved with. > I think we'll use this opportunity to structure how we present Dash a bit. I > really don't want to create a new project for every bit of committer-related > technology we create, so creating and maintaining new technology directly under > the Dash banner makes sense to me... Makes sense to me. (In reply to comment #15) > We have some space on /gitroot/ to create repo of our choosing. > > Unfortunately, neither Chris nor Dave are committers on Dash. Please confirm > that you will be the ones who will support this component moving forward and > I'll initiate the necessary elections. > > I think we'll use this opportunity to structure how we present Dash a bit. I > really don't want to create a new project for every bit of committer-related > technology we create, so creating and maintaining new technology directly under > the Dash banner makes sense to me... Yep, I'll help support it as well. Dave ditto I have started three committer elections. Once the election is complete, one of you can commit the code. Does that work? (In reply to comment #19) > I have started three committer elections. Once the election is complete, one of > you can commit the code. Does that work? Yes, works for me. I've crated the necessary git repository, and pushed the signing plugin to the repo. git://git.eclipse.org/dash/org.eclipse.dash.maven.git I've also requested a hudson build job be created so we can run this there. We have some work to do yet on creating a parent pom for this, but for now it can be run and created standalone. I'll keep this open until we have this pushed to the Nexus snapshots repo so that others can start to use it and test it. Since there is no guarantee of the nexus repo yet, we should just have a place on download.eclipse.org that we can point people to. I'd like to spin a 1.0 soon and ensure it supports eclipse-update-site and eclipse-repository tycho types. (In reply to comment #22) > Since there is no guarantee of the nexus repo yet, we should just have a place > on download.eclipse.org that we can point people to. > > I'd like to spin a 1.0 soon and ensure it supports eclipse-update-site and > eclipse-repository tycho types. As soon as I get the admin password, I'll get the snapshots deployed to the nexus repo. I just forgot what the admin password was to Nexus. (In reply to comment #23) > (In reply to comment #22) > > Since there is no guarantee of the nexus repo yet, we should just have a place > > on download.eclipse.org that we can point people to. > > > > I'd like to spin a 1.0 soon and ensure it supports eclipse-update-site and > > eclipse-repository tycho types. > > As soon as I get the admin password, I'll get the snapshots deployed to the > nexus repo. I just forgot what the admin password was to Nexus. I should have this deployed to the nightly nexus repo tonight. As part of bug 345734 I created a settings.xml file that projects can use during their build to pull artifacts from the repo. This is now deployed to the Nexus snapshot repo. http://maven.eclipse.org/nexus/content/repositories/nightly-indigo/ There is a settings.xml file that projects can use to retrieve artifacts. http://git.eclipse.org/c/dash/org.eclipse.dash.maven.git/tree/settings.xml Please report any issues to this bug report. If everything looks good, I'll do an initial deployment to the Indigo Milestone once we are comfortable. Information on using the new plugin: http://wiki.eclipse.org/Minerva#Signing Alright, how do I use this bad boy? https://hudson.eclipse.org/hudson/job/egit-github/107/console https://hudson.eclipse.org/hudson/job/egit-github/106/console Put the plugin signing on your Site/Repository module, not your parent. You'll want to set a phase so it happens after the repository artifacts are created and the site zip is assembled, I'm assuming. So put the profile in the appropriate module, and you should get a bit farther. progress, https://hudson.eclipse.org/sandbox/job/egit-github.gerrit/10/console no access to /usr/bin/sign from the looks of it... (In reply to comment #29) > progress, > > https://hudson.eclipse.org/sandbox/job/egit-github.gerrit/10/console > > no access to /usr/bin/sign from the looks of it... This looks like a similar issue to bug 324380. I'm ccing the webmasters on this as well. This works for me now. https://hudson.eclipse.org/hudson/job/egit-github/115/console Shall we find a permanent home for this plug-in now or will we ensure where it's at, it's going to remain there? (In reply to comment #31) > This works for me now. > > https://hudson.eclipse.org/hudson/job/egit-github/115/console > > Shall we find a permanent home for this plug-in now or will we ensure where > it's at, it's going to remain there? If this looks good, I'll deploy it to the indigo milestone (release) repository on Nexus. I'd like to have a few more people try it to be sure before we take the -SNAPSHOT off of it. Feel like blogging about it Chris? The signing plug-in also works for LinuxTools. I'll deploy this to the milestone release for Indigo repository sometime tomorrow. It may eventually move to an official release area. I'll remove the snapshot extension, and post the version number when done. Eclipse singing plugin has been staged to the milestone/indigo repository. This will be it's permanent home. Staged versions is 1.0.0. Chris you should be able to use it now, as well as any project that needs to have their p2 artifacts signed. Resolving this issue. Repository location: http://maven.eclipse.org/nexus/content/groups/public/ Thanks David, I blogged about it. http://aniszczyk.org/2011/05/18/eclipse-org-signing-support-for-maven-tycho/ Hopefully this helps people as we get close to Indigo release time... now to update the Minerva example... |