Bugzilla – Full Text Bug Listing
| Summary: | Team project set should not generate .source projects as top level projects | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] Orbit | Reporter: | David Williams <david_williams> | ||||
| Component: | releng | Assignee: | DJ Houghton <dj.houghton> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Project Inbox <orbit.releng-inbox> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | dj.houghton | ||||
| Version: | unspecified | ||||||
| Target Milestone: | Juno M5 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
I'm guessing that it is just a side effect. The input file (map file) that we pass to the Ant task to create the project set file contains all of the bundles produced by the build so we just add psf file entries for all of them. Sometimes I have source bundles as "roots" in my workspace but only for testing that they export correctly. I agree that those benefits don't outweigh the confusion from being able to edit the source bundle in 2 places. (I have made mistakes with this setup as well) Does it make sense to ignore all *.source bundles? That would be easy to change. (In reply to comment #1) > ... > Does it make sense to ignore all *.source bundles? That would be easy to > change. That'd be ok with me. I haven't looked at the source that produces this, but if I was going to fix it, my first approach would be to leave the .source bundles "in" but surround that part as a comment, such as look for 'source-bundle' in potential entry and surround that entry <!-- <project reference="1.0,:pserver:anonymous@dev.eclipse.org:/cvsroot/tools,org.eclipse.orbit/javax.el/source-bundle,javax.el.source_2.1.0,v201105211819"/> --> No idea if existing code makes this easy to do ... but, that way, I figured if someone really needed the source-bundle projects, for some reason, it would still sort of easy to get ... sort of like "deprecating" it :) But, glad to hear there's no substantial reason for it I was missing. Thanks, Yep, that should be easy. I'll change it and update the tools.jar and release to the repo. Updated the code to comment out source bundles in the generate PSF file. Updated the tools.jar in the builder project. I didn't tag the builder project or update the build.cfg file to update the builder though. Wasn't sure when you wanted to roll out the change (since we have M4 +0 this week). (In reply to comment #4) > ... since we > have M4 +0 this week). Oh, we in Orbit are -1 ... and if the +0 project hasn't found a problem yet ... :) But, more seriously, I just did a little local test, commenting out all the lines with "source-bundle" in my local psf file and a) import project sets still works! (that was what I wanted to confirm :) and b) makes me see that using the ".source" approach, as you have, might not work for the "prebuilt" bundle case. I would omit those prebuilt ones. I don't recall if we have a "standard" in Orbit, but to take one example, I see the source jar for icu is in org.eclipse.orbit/com.ibm.icu/src and the binary code in org.eclipse.orbit/com.ibm.icu/bin I'm not sure what the expectation would be for "pre-built" source bundles ... or even the binary ones ... to pull them in or not ... I would think "yes" off top of my head ... but, I am not sure how they are "put into" cvs to begin with. Is there just one "com.ibm.icu" directory with a bunch of jars in it? If so, then either including or excluding them would be "wrong" (sort of) so not sure it matters. I'm fine leaving that for the future. I was pretty cool to be able to "import all" without as much messiness. Takes a long time ... but ... pretty cool. So, I'd say you can "release" the builder whenever you'd like, after you've thought about the "pre-built" case. I'm fine with any approach for now. Much thanks! Created attachment 208127 [details]
similar fix keyed off source-bundle
Don't mean to be (too) picky, but I think the 'source-bundle' approach would better match expectations (though, only matters, currently, for the ICU pre-built jars).
Sure, that works too. (as long as everyone is a good citizen and uses source-bundle in their path) Yep, the ICU bundles are just put into a folder and we grab them directly. (nothing generated and nothing assumed about the folder names) (In reply to comment #7) > Sure, that works too. (as long as everyone is a good citizen and uses > source-bundle in their path) > Oh ... I thought that was _required_ ... well, if not, guess one's as good as the other. It is definitely recommended in Bug 184026 and http://wiki.eclipse.org/Orbit_Source_Bundles but I did some searches and can't tell if it is enforced or just a best-practice thing. Either way, I'll use your patch as that might be a step to ensuring people do use the recommended layout. Ok, I've updated the code, regenerated the JAR, put the JAR in the builder, tagged the builder, updated the builder tag in the build.cfg file and kicked off a build to test the change. Hopefully I didn't forget something in that process. :) |
Question mark? Our build scripts generate a "team project set" for each build, which is a nice way to "load up" all the projects being built by Orbit. But, it current treats the semi-auto generated ".source" bundles as "top level" projects in the workspace, but with no .project file. So, for example, some sample projects in the workspace would look like com.jcraft.jsch_0.1.41 com.jcraft.jsch_0.1.44 >> com.jcraft.jsch.source_0.1.41 >> com.jcraft.jsch.source_0.1.44 A "source module" cvs path would be org.eclipse.orbit/com.jcraft.jsch/source-bundle whereas the normal module path would be org.eclipse.orbit/com.jcraft.jsch Is this useful to do? It seems confusing to me, if not "dangerous" (there's two places where "source" changes might be made?). I'm curious if this was done "on purpose" or sort of a side effect of how the script was written. Anyone find the "source" projects useful? Is there a use case?