Bugzilla – Full Text Bug Listing
| Summary: | [maven.eclipse.org] Define how we should handle deployment users | ||
|---|---|---|---|
| Product: | [Technology] Dash | Reporter: | Aaron Digulla <digulla> |
| Component: | Maven | Assignee: | Project Dash Incoming bugs <dash-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | dennis.huebner, stephan.herrmann, t-oberlies, thanh.ha |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 350640, 351206, 360944, 365008, 365899 | ||
|
Description
Aaron Digulla
Wouldn't the group of people having shell access to build.eclipse.org pretty much match the group of people who should be allowed to deploy to maven.eclipse.org? At least for a start? That could mean we wouldn't need yet another set of accounts and credentials etc. Maybe just designate a (non-exported) directory on build where a deployment process would pick up artifacts for deployment, similar to how we do signing? I like the idea, I'm not sure we can implement it this way. I don't like giving everyone (or not enough people) access to the Maven repo but OTOH, the current discussions show that Eclipse developers (people used to OSGi, PDE and p2) don't really understand how Maven works and how it sees the world. So maybe a staged process might work: - To save a lot of work, we will try to convert everything that is part of 3.7 as it is. - A list of bundles should be compiled from this process - When a new conversion is necessary, any bundle not on the list will be eyeballed to check if it works. It would be great if this could be done during the milestone builds (because that would give the chance to discuss some changes in the project's setup which might help in the process). From my current experience, many projects (especially the high level ones like JDT and BIRT) can be converted automatically and they work out of the box. We have a lot of problems with anything from Orbit and low level stuff like SWT. (In reply to comment #2) > - To save a lot of work, we will try to convert everything that is part of 3.7 > as it is. Sounds lovely! :) When you say 3.7, do you mean Eclipse SDK 3.7, or could the approach scale up to the entire Indigo repo? I have no idea, how much work that would be. > It would be great if this could be done during the milestone builds (because > that would give the chance to discuss some changes in the project's setup > which might help in the process). What would you need from the individual projects for this to work during milestone builds? (In reply to comment #3) > (In reply to comment #2) > > - To save a lot of work, we will try to convert everything that is part of 3.7 > > as it is. > > Sounds lovely! :) > > When you say 3.7, do you mean Eclipse SDK 3.7, or could the approach scale up > to the entire Indigo repo? > > I have no idea, how much work that would be. Me neither. The problem is how you define "3.7" and how I can get a copy of it. What I would prefer is an automated solution (so say a URL which returns a list of URLs of bundles to convert). But I'm not sure how to get that from, say, the official p2 repo. > > It would be great if this could be done during the milestone builds (because > > that would give the chance to discuss some changes in the project's setup > > which might help in the process). > > What would you need from the individual projects for this to work during > milestone builds? Here are issues which I've encountered so far which could have been solved better: - A bundles changed but the version wasn't updated (bug 329376) - Some Orbit bundles contain classes they should not (bug 350792) (In reply to comment #4) > Me neither. The problem is how you define "3.7" and how I can get a copy of it. > What I would prefer is an automated solution (so say a URL which returns a list > of URLs of bundles to convert). > > But I'm not sure how to get that from, say, the official p2 repo. What do you need? Can you convert from binary bundles (would be directly available from the repo), or do you need the sources? Would the Eclipse-SourceReferences header in the MANIFEST.MF help? Optionally, during SimRel milestone builds the b3 aggregation files[2][3] could be used as an index. [1] http://wiki.eclipse.org/PDE/UI/SourceReferences [2] http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.juno.build/?root=Callisto [3] http://wiki.eclipse.org/Juno/Contributing_to_Juno_Build (In reply to comment #5) > What do you need? Can you convert from binary bundles (would be directly > available from the repo), or do you need the sources? I need the binary bundles but I need to know which ones belong to which Eclipse release. > Optionally, during SimRel milestone builds the b3 aggregation files[2][3] could > be used as an index. The b3aggrcon files look promising but I'm missing the JDT in there. Equinox is there but it doesn't contain version numbers and I couldn't figure out which version maps to which Indigo release (Indigo, SR1, SR2). (In reply to comment #6) > (In reply to comment #5) > > > What do you need? Can you convert from binary bundles (would be directly > > available from the repo), or do you need the sources? > > I need the binary bundles but I need to know which ones belong to which Eclipse > release. In that case the children of releases/indigo would be of interest for you: http://download.eclipse.org/releases/indigo/201106220900 (Indigo) http://download.eclipse.org/releases/indigo/201109230900 (SR 1) http://download.eclipse.org/releases/indigo/201202240900 (SR 2) > > Optionally, during SimRel milestone builds the b3 aggregation files[2][3] could > > be used as an index. > > The b3aggrcon files look promising but I'm missing the JDT in there. You may have a look at ep.b3aggrcon, it points to the entire Eclipse SDK. > Equinox is > there but it doesn't contain version numbers and I couldn't figure out which > version maps to which Indigo release (Indigo, SR1, SR2). That's right, projects tend to specify their versions loosely so they don't need to update the b3aggrcon for each build. Maybe during milestone builds that's exactly what you need for warm-up conversion based on the latest? If you install the b3 editor you can actually see the resolved versions for each contribution, but I don't know how that info could be automatically processed. OTOH, maybe the aggregation files are not even needed? - For releases fetch everything from the corresponding (child) repo above - For milestone builds there are similar child repos like, e.g.: http://download.eclipse.org/releases/201202030900 (= Juno M5), or, you could synchronize with David Williams to pick up a staging repo from the aggregator build (see https://hudson.eclipse.org/hudson/view/Repository Aggregation/ ) maven.eclipse.org was decommissioned via bug 405750 and replaced with repo.eclipse.org. See: https://wiki.eclipse.org/Services/Nexus |