Community
Participate
Working Groups
With the new b3.aggregator it is possible to turn on a switch that turns the aggregated result into a hybrid repository that contains both p2 and Maven meta-data. The purpose of this bugzilla is to discuss and come to a conclusion if we should use this. If we decide to do use a hybrid, there is one issue that we need to resolve. In Galileo, the Helios repository copies all meta-data from the platform but it uses a composite artifact repository to reference the platform artifacts. This means that none of the platform artifacts needs to be copied. Maven doesn't have this separation between meta-data and artifacts and cannot contain references to other repositories. This means that we need to make a decision when it comes to the platform repository. Alternative 1. Make a full copy of the platform repository into the Helios repository. Pros, it's clean and simple. Cons, it takes up a fair amount of disk space. Alternative 2. Mavenize the platform repository and don't copy it. This means that all maven users that wants to use Helios must reference both the platform repository and the Helios repository. Alternative 3. Don't create a hybrid at all. Instead, rely on that all Maven users that want access to the Helios repository will use Tycho and p2. Suggestions and opinions are welcome.
To cross reference, see also bug 283745.
I do see some value in creating the initial Helios repository as a copy of everything that it aggregates (since that shields from probably unwanted modifications in the input). But I'm unsure about how such an approach would allow evolving the repository for SR1 and SR2. In my mind, one of the bigger advantages of doing an aggregate was that the "Release", "SR1" and "SR2" repos could each be completely separate and self-contained. How would that work if we start copying stuff again. Could the "Release", "SR1" and "SR2" repos each be mavenized separately, with a complete aggregate built by p2 reference?
(In reply to comment #2) > How would that work if we start copying stuff again. Could the "Release", "SR1" > and "SR2" repos each be mavenized separately, with a complete aggregate built > by p2 reference? We can either mavenize each repository individually and thus, put the burden on the maven user, or aggregate everything into one repository. My preference would be the former for the reasons you mention.
For what its worth, I set up an "experimental" job on build server "runHybrid" that turns on the "mavenResult" flag and produced one of these p2+maven repos. It is a "manual build" only we can run from time to time. Its results will (for now) always remain on build machine, as its examined, and only if we decide "go" would I move anything to "downloads". It is not quite usable (it failed) due to bug 314603 (where there are invalid pack.gz files coming from the Eclipse project). But, I hope interested parties can start to get an idea of what it is. Its directory structure is radically different (to my untrained eye). I guess it has to be for Maven, and p2 doesn't care (as long a metadata correctly "points" to it.) See http://build.eclipse.org/helios/hybrid/final/aggregate/ This hybrid repo takes up 1300 Meg on disk, the plain p2 one takes 930M. This build took around 2.5 hours. the plain p2 one takes about 1.1 hours. [remember, small sample size].
One maven question ... how do maven users take advanage of mirrors? Can/do they go through download.php script? Do they just have to pick one mirror up front, and their builds/installs go through that one mirror? I'm just curious what the bandwidth implications are.
To give my view, it is too late to do this for Helios release. My concern is it'd just be a distraction as we try to finish the release in the next few weeks. In addition, it doesn't seem many maven users would have time to "test it out" ahead of the release. (Which is pretty fundamental). But, I am the last person in the world 1) to know how to test it or verify its correct and useful, and 2) last to be able to judge how important this is. So, quite glad to hear others opinions.
The repository at http://build.eclipse.org/helios/hybrid/final/aggregate has no .pom files and no source/javadoc artifacts, so it is not useful as a maven repository. I'm still looking for some public repository location where I can add maven dependencies for org.eclipse.uml2.uml v3.0 release to my non-Eclipse maven project. For now, a skeleton pom file containing only group, artifact, version will be fine, enough to avoid the maven error when downloading, but for eventual replication to the maven central repository a whole lot more information will have to be added (see http://www.sonatype.com/people/2010/04/uploading-artifacts-to-the-central-maven-repository-diy).
(In reply to comment #7) > The repository at http://build.eclipse.org/helios/hybrid/final/aggregate has no > .pom files This is caused by a general failure of the task (the aggregation job was not finished). Some of the poms were generated while others not. We need to investigate the cause of the problem. [exec] Adding maven metadata [exec] Build failed! Exception was org.eclipse.core.runtime.CoreException: Error creating digest for file:/shared/helios/hybrid/final/aggregate/org/eclipse/pde/org.eclipse.pde.api.tools/1.0.201.v20100526-1600/org.eclipse.pde.api.tools-1.0.201.v20100526-1600.jar [exec] Caused by: java.io.FileNotFoundException: /shared/helios/hybrid/final/aggregate/org/eclipse/pde/org.eclipse.pde.api.tools/1.0.201.v20100526-1600/org.eclipse.pde.api.tools-1.0.201.v20100526-1600.jar (No such file or directory)
> > We need to investigate the cause of the problem. > > [exec] Adding maven metadata > [exec] Build failed! Exception was org.eclipse.core.runtime.CoreException: > Error creating digest for > file:/shared/helios/hybrid/final/aggregate/org/eclipse/pde/org.eclipse.pde.api.tools/1.0.201.v20100526-1600/org.eclipse.pde.api.tools-1.0.201.v20100526-1600.jar > [exec] Caused by: java.io.FileNotFoundException: > /shared/helios/hybrid/final/aggregate/org/eclipse/pde/org.eclipse.pde.api.tools/1.0.201.v20100526-1600/org.eclipse.pde.api.tools-1.0.201.v20100526-1600.jar > (No such file or directory) See bug 314603. It related to invalid pack.gz files. Well, that, and the aggregator not "copying" the jars :) [bug 312976].
Yes, you are right! The problem stems from unsuccessful unpack. This needs to be solved somehow (see related bugs). However, if the unpack fails, maven metadata generator should not fail but it should report a contribution related error instead and continue. This has been done and checked in trunk.
> > However, if the unpack fails, maven metadata generator should not fail but it > should report a contribution related error instead and continue. This has been > done and checked in trunk. Ok ... good for maven ... is this true for P2 repo also? And, by "continue" do you mean it would just get the jar instead, and continue? Or ... something else? Lastly, when you say "checked in trunk" be sure to be explicit when 'built and rolled out to b3 aggregator repo" so I know if/when to update helios build. (And, should probably wait until RC3 is done late this week before updating anything). Thanks,
Assigning to myself just to avoid so many mail notices. Add yourself to CC if interested in following.
(In reply to comment #11) > > > > However, if the unpack fails, maven metadata generator should not fail but it > > should report a contribution related error instead and continue. This has been > > done and checked in trunk. > > Ok ... good for maven ... is this true for P2 repo also? > And, by "continue" do you mean it would just get the jar instead, and continue? > Or ... something else? It does not get the jar - it only reports an error (the unpacked jar is missing), does not generate a checksum for that jar and goes on. The final result of the whole aggregation is "FAILED" anyway. To make the hybrid aggregation succeed we need to solve the bug 314603. > Lastly, when you say "checked in trunk" be sure to be explicit when 'built and > rolled out to b3 aggregator repo" so I know if/when to update helios build. > (And, should probably wait until RC3 is done late this week before updating > anything). It has been checked in with rev 1045. The update site is being built right now. If it does not fail it should be published in an hour or so. I will run a test build with maven result on our testing machine as soon as the new build is available.
Well ... after bug 315383 fixed, there certainly is more error messages printed out during the build. So many, I'm not even sure where to start. Maybe b3 aggregator team can take a look? https://build.eclipse.org/hudson/view/Repository%20Aggregation/job/helios.runHybrid/4/consoleFull
(In reply to comment #14) > Well ... after bug 315383 fixed, there certainly is more error messages printed > out during the build. So many, I'm not even sure where to start. Maybe b3 > aggregator team can take a look? > I'll take a look.
Fixed (see bug 315569). The problem (newly introduced with recent changes regarding artifact properties) was in unpacking artifacts into non-existing folders. Changes have been published on the update site. Hopefully we'll get a successful build on next run :-) When that's done, it would be good if someone could take a look at the maven result (to review if more information should be stored in maven metadata and, if so, where to get them from p2 artifacts).
Progress? https://build.eclipse.org/hudson/view/Repository%20Aggregation/job/helios.runHybrid/5/consoleFull but no cigar. No offense ... but you all have a test machine ... right? :)
Looks about the same: https://build.eclipse.org/hudson/view/Repository%20Aggregation/job/helios.runHybrid/6/ Now the bad news. I think we need to end this effort, and make no more changes to the aggregator, unless to fix a bug in the p2 repo. We are starting our final week, and can't afford regressions (like the one broadcasting all the failed-build mail today). You can continue your own tests and development, though, and we can revisit during SR1 maintenance, as far as I know, and certainly for next release. But, I would suggest you leave "the most recent" version of the aggregator in your repo at http://download.eclipse.org/modeling/emft/b3/headless-3.6/ as being reserved for our final push towards Helios, and not make other, potentially regressive changes. If you decide to push ahead with "head", be sure to create a branch for Helios required fixes, and let me know exact feature version to install (normally I "take the latest", but that would be a bad idea, from here on out, unless you tell me its steady. Thanks for the efforts though. I think this is important work, and we (I?) just got to it a little late this cycle.
Problem analysis: The last fix had no influence on aggregator's functionality for the Helios build. It cannot happen that two jars would share the same folder in maven structure. The problem stems from inconsitency between metadata and artifacts in http://download.eclipse.org/eclipse/updates/3.6milestones. The bundles org.aspectj.weaver and org.aspectj.runtime are in the metadata (including artifact keys) but they cannot be found in appropriate artifact repositories. When this happens, the aggregator ignores the artifact not being found and continues. Unless maven metadata is required, this error is not discovered and the whole process is considered as successful. Should a missing artifact in the artifact repository be an error? If not, should we look for the artifact anywhere else (e.g. in all other known aggregated artifact repositories)? In addition to this, I have made several optimizations in the aggregator (maven metadata generator tried to look for the same IU several times). I haven't checked it in yet since we must decide what to do next (branch off?).
> Should a missing artifact in the artifact repository be an error? If not, > should we look for the artifact anywhere else (e.g. in all other known > aggregated artifact repositories)? Sounds like it should/could be part of the repo consistency checks. (That is, at least print out a warning). The reason being that a repository should not say it has something, if it can not provide it. But, not sure it should be an "error" per se, resulting in a "failed build", especially not now (this late). I assume the current situation means no one currently ever needs those artifacts, hence currently no error to report. But, this is similar to what we've encountered before ... a repo should not say it has pack.gz files, if it really does not have them (even though p2 itself will ignore that error and still install the jars).
Created attachment 171256 [details] Better control over mirrored artifacts Recent Aggregator news: 1) I created a new option in the b3 hudson build named "create.sites". This option creates p2 sites without promoting them to the public location. They are available here: https://build.eclipse.org/hudson/view/Modeling/job/emft-b3-build/lastSuccessfulBuild/artifact/site/eclipse https://build.eclipse.org/hudson/view/Modeling/job/emft-b3-build/lastSuccessfulBuild/artifact/site/headless Using this kind of build we can freely test individual builds until we agree on promoting to the "official" update site. 2) I am including a patch solving the missing artifacts problem (the patch is suitable for review of the changes, but in fact it has already been applied). If an artifact cannot be found in the artifact repository, it is reported as an error. This patch also improves performance - units to aggregate are processed only once in each step (it may have happened that a single unit was processed several times). 3) I will run the whole hybrid Helios aggregation on our testing machine. Although it is expected to fail (because of missing artifacts), I'd like to see that it does exactly what we expect. I wonder if it still hangs on mirroring some of the artifacts. The "eclipse.p2.mirrors" property is set to false by <jvmarg value="-Declipse.p2.mirrors=false" /> (is that correct?) but it has been there since I wrote the hudson job. Even though, it got always stuck (let's see what it does today). Regarding missing artifacts - David suggested that it should be a warning only. I am not sure - I think that if it does not cause fatal failures on non-maven output (since the broken repositories are not mirrored), I think we should consider it as an error. The question is - when and how do we create a valid maven repo for Helios?
(In reply to comment #20) > Sounds like it should/could be part of the repo consistency checks. (That is, > at least print out a warning). The reason being that a repository should not > say it has something, if it can not provide it. But, not sure it should be an > "error" per se, resulting in a "failed build", especially not now (this late). The source repository is corrupt. IMO, this must be a hard error and the repository should be fixed in time for the Helios release. It's more serious then the problem with the missing pack.gz files because p2 cannot recover from the error. It will fail hard on any attempt to install a feature that somehow includes these artifacts. Please note that it doesn't matter i the artifacts are optional. The planner will not consult the artifact repository at all during planning and once it's made it's decision to include (optional or not), that decision stands. From that point on, p2 has to find what it's looking for. Is the platform team aware that they have a problem with the aspectj artifacts?
How about... 1. Publish a released version of the 3.5 artifacts in a public maven repository. 2. Publish the released version of the 3.6 artifacts in a public maven repository, once final. 3. When everybody agrees that the created artifacts look OK and when the artifacts all pass the sonatype synch requirements, synch the artifacts to the maven central repository. The above would be a one-time only process, except to fix issues. Once published and finalized and synchronized to central, the disk space can be recovered. 4. After the release artifacts have been successfully mavenized, create the process to publish the next release SNAPSHOT artifacts to a public snapshot repository, for every build. Or better yet - use multiple staging repositories for different levels of artifact milestones - initial build, integration tested, pre-release, etc. Set this up when the next release Eclipse platform branch is created.
> > Is the platform team aware that they have a problem with the aspectj artifacts? > Who are you asking? I've added Kim and John to CC. (I am not sure what the issue is, haven't looked ... just passing on information) Seems odd the platform would have any aspectj bundles/metadata in their repo. But suppose it would be some earlier "weaving" work?
I've some newbie questions about "the maven world". Are the artifacts used only for builds? Or installations also (like p2 does)? How do maven users deal with mirrors? Is it pretty ingrained in the mindset, tools or APIs? or will all these request for a maven artifact come back to eclipse.org? Thanks for the education.
"maven world" example: I have a maven project with dependencies on eclipse 3.5 artifacts, in my case org.eclipse.uml2.uml and emf. Dependencies have multiple scopes: i.e. compile (used for compilation, bundled with war/ear build artifacts), test (used for test compilation, not bundled with artifacts), provided (used for compilation, not bundled with artifacts because they are provided by the deployment platform), runtime (not required for compilation, bundled with build artifacts). See http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html. This is one of the deficiencies of the Eclipse IDE (single project classpath) BTW. I can specify external repositories where dependencies can be downloaded, both globally (maven configuration settings) and at the project level. Whatever repositories I specify are searched for dependent artifacts. The ibiblio (maven central) repository is always automatically searched for downloads. There is a process for synching (replicating) release artifacts to central, facilitated by sonatype, i.e. no non-central repository dependencies, source/javadoc artifacts included, SCM/Bug/Developer metadata included. This should be the ultimate goal of any built artifact, so that it is available to the entire world automatically. Release artifacts are considered 'set in stone' for dependencies/versions and other metadata. SNAPSHOT artifacts are work in progress, not replicated to central, typically hosted in completely separate snapshot repositories, so I can always get the latest built/tested version if I want (that would be the function of the helios/tycho repository, which I would have to specify in the maven/project configuration). Repositories typically have a repository manager (i.e. Sonatype Nexus) to handle things like mirroring/caching artifacts for other repositories, publishing indexes of available artifacts, staging artifacts after build / before release, security, developer provisioning, etc. Hopefully I answered the question completely, let me know if there are additional questions. Thanks for all the work on implementing this.
FYI, the platform updated their repository URL to "released" repo, so didn't include the old, invalid milestone repos, so ... aggregation was successful, and there is now a testable hybrid site at http://build.eclipse.org/helios/hybrid/final/aggregate (For testing only ... it won't be permanent, and is not on a production download server). I suggest we figure out what to do about maven artifacts by Helios SR1 (this hybrid repo is already a little different than exactly what was released in Helios, since one project updated one feature version already). Just wanted to let interested parties know there was something there to look at and test.
Looks like the repository is actually at http://build.eclipse.org/helios/hybrid/final (no /aggregate as part of the URL). The couple places I checked don't have -sources or -javadocs artifacts attached, and there's still a lot of pom metadata missing such as organization, issue management, source control, developers, etc. so they won't be able to be synched to maven central. Would it be possible to add that information - I can provide sample values if needed. It looks like the dependencies contain version ranges such as [3.5.0,4.0.0) rather than absolute release values. Absolute numbers are preferred for build stability purposes. Note that ,4.0.0) means that the latest version earlier than 4.0.0 will be selected as a dependency, which will select 4.0.0-alpha releases because qualified releases are considered to be earlier than unqualified releases. Something like ,3.6.9) would be preferable if a range must be used, otherwise use an absolute release value such as 3.6.0.v20100505. Also, all the artifacts depend on org.eclipse.core.runtime, however that is not really required to compile or run the projects using the artifacts. I have to exclude that dependency from my projects because I run UML2 in standalone mode. A better scope for that dependency would be 'provided'.
(In reply to comment #28) > Looks like the repository is actually at > ... > synched to maven central. Would it be possible to add that information - I can > provide sample values if needed. Yes, we can add any information that is needed and that is available in p2 metadata. Current implementation of maven support is a proof of concept. If you have the knowledge and ideas what is missing and where to get the missing information (i.e. how to map it to the p2 metadata) it will help us a lot.
Created attachment 174885 [details] Updated *.pom files with metadata and Eclipse parent pom. It would be easiest to have a global parent pom for Eclipse with the general metadata information, which can be overridden for each subproject with information like project URL, developer/contributor lists, mailing lists, and SCM URL. Developer information is required for sync to maven central, I don't know where developer information can be obtained for each project, perhaps a single point of contact address in the parent pom. I attached updated examples with the parent at org\eclipse\org.eclipse.eclipse, with as much information as I could figure out.
(In reply to comment #29) > (In reply to comment #28) > > synched to maven central. Would it be possible to add that information - I can > > provide sample values if needed. > > Yes, we can add any information that is needed and that is available in p2 > metadata. Current implementation of maven support is a proof of concept. If you > have the knowledge and ideas what is missing and where to get the missing > information (i.e. how to map it to the p2 metadata) it will help us a lot. I don't know anything about what p2 metadata is available or how to map it, couldn't find any references on google or Eclipse, sorry. If you could point out some resources on available p2 metadata that would be helpful, i.e. from http://wiki.eclipse.org/P2. Does the p2 metadata specify a range of version dependencies like appears in the pom files? A single dependency version is much preferred for build stability reasons. Also the eclipse.runtime should be a provided dependency. See http://maven.apache.org/pom.html for reference info on the maven metadata. Meanwhile, if the helios hybrid repository artifacts could be updated to include the source artifacts, that would be very helpful, right now I have to add them manually. For example, I map eclipse\plugins\org.eclipse.uml2.uml.source_3.1.0.v201006071150.jar to org\eclipse\uml2\org.eclipse.uml2.uml\3.1.0.v201006071150\org.eclipse.uml2.uml-3.1.0.v201006071150-sources.jar which lives in the same directory as the runtime artifact. Once we get the metadata/developer info figured out, would it be OK if I submitted the attached poms plus artifacts to sonatype for updating to maven central (https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+Maven+Central)? I'd like to use the artifact dependencies in a released version of my own project (andromda).
(In reply to comment #28) > It looks like the dependencies contain version ranges such as [3.5.0,4.0.0) > rather than absolute release values. Absolute numbers are preferred for build > stability purposes. Note that ,4.0.0) means that the latest version earlier > than 4.0.0 will be selected as a dependency, which will select 4.0.0-alpha > releases because qualified releases are considered to be earlier than > unqualified releases. Something like ,3.6.9) would be preferable if a range > must be used, otherwise use an absolute release value such as 3.6.0.v20100505. A little further testing shows a major bug in the current maven release, where the version ranges can't handle the four part Eclipse version identifier. This has been fixed in maven3 beta, see http://docs.codehaus.org/display/MAVEN/Versioning, but with maven 2.2.1 you see: Couldn't find a version in [3.6.0.v20100517, 3.2.0-v20060601] to match range [3.5.0,4.0.0) org.eclipse.osgi:org.eclipse.osgi:jar:null If at all possible, please use exact version numbers instead of version ranges in the pom files. If that's too hard, please convert the four part identifier to a three part plus -qualifier, i.e. 3.6.0.v20100517 becomes 3.6.0-v20100517. This version will not be selected by [3.6.0,) because a qualified version is considered to be earlier than a released version, but will be selected by [3.5.0,) or [3.5.0-!,), so the version range start has to be for the previous release or with a -! qualifier.
Created attachment 174984 [details] Testcase: maven repository failure (In reply to comment #32) > A little further testing shows a major bug in the current maven release, where > the version ranges can't handle the four part Eclipse version identifier. Here's a very simple failure test case referencing the uml2 artifacts (the ones I need for my project). To run: - Download maven latest release 2.2.1 from http://maven.apache.org/download.html. - Unzip to a local directory - Add environment variable M2_HOME pointing to that directory - Add M2_HOME\bin to the PATH - Unzip the attached project, change to the unzipped directory - Run 'mvn install'
Could you either confirm that this URL location will be available permanently, let me know where a permanent maven repository URL is located, or allow me to synch the needed org.eclipse.uml2 artifacts to another permanent repository such as sonatype? I want to update the dependencies for my snapshot project, but I don't want to do that if the dependency repository will go away, causing errors when people try to use the andromda application because the dependencies can't be downloaded. Is anybody working on this for SR1?
(In reply to comment #34) > Could you either confirm that this URL location will be available permanently, I can confirm that it will _not_ be permanent. It is, after all, on the 'build machine'! > Is anybody working on this for SR1? As far as I know, no one is. I was surprised to see I had assigned this to myself, and that may be a little mis-leading. (I suspect I did simply as I did the "hudson job" part of the work). Thomas, are you a better "owner"? Someone to drive to resolution? My own personal feeling is its a bit late to be trying to work this into SR1 ... since it changes the directory structure, etc., seems like we would want a longer time to confirm all is ok, compatible, etc. Perhaps we should focus the effort on 'indigo' and if that all goes swimingly for M2, M3, then consider a "backport" for SR2? Someone needs to sort this out and propose the
OK, I'll ask again - is it OK to take the version of the artifacts and pom.xml files that I created, which work in both maven 2.x and 3.x, and update those artifacts to maven central (just the EMF/UML2 related artifacts)? SR1 and SR2 are considered separate independent releases with separate version numbers and dependencies. The Eclipse artifacts have not been updated to Central (or in any other stable repository) since 2007, see http://repo2.maven.org/maven2/org/eclipse/uml2. I need a stable repository location/artifacts in order to create a release for my project which depends on those artifacts.
My comments from bug 283745 comment #153 just to continue the discussion about Helios. I ran a quick test using the b3 aggregator to generate a maven repo for Helios. If we were going to publish helios, could we just host the converted repo on download.eclipse.org for a milestone or two and get feedback on what works and what doesn't work? - The default behavior for b3 is a group id of org.eclipse.<segment> ... that seems reasonable. >> Artifact IDs are the bundle symbolic name. ex: groupId org.eclipse.ui artifactId org.eclipse.ui.ide - It generates ranges in the dependencies, it's true, but that wouldn't prevent using the repo for now (since it's only one slice of eclipse releases). Maybe an enhancement to b3 could write out the specific versions for the dependencies to what's in that slice during pom generation. Some things I saw that might cause problems: - I didn't notice anything platform-filter like generated for the SWT fragments. Not sure what information would need to be there for someone to build a windows SWT app vs a linux SWT app in a more general way than directly including the artifact id for the fragment itself (which worked for a non-OSGi JFace test app) >> there is a way to specify properties to make things platform dependent. - the dependencies don't seem to include anything (like the derived bundle) from an Import-Package >> this means that there are some artifacts that when materialized, will not pull in the full list of other dependencies they really need to run. - most of helios was generated with the new "Eclipse-SourceReferences: scm:cvs:..." header ... is that something that can be surfaced in poms? >> see http://maven.apache.org/pom.html#SCM PW
If we resurrect the hudson job, then wouldn't we have a public location for groups to test against? PW
I'm closing this bug as "won't fix" for now. I think most of the discussion has/is/should be done in bug 283745 and so far there's nothing "mechanical" to do. That is, this bug is concerned with mechanical "how to" issues, and bug 283745 concerns more "what" issues. From what I can tell, the effort in general lacks some focused "leadership" to drive open issues to conclusion. I know the Architecture Council is trying trying to find people to form a "working group" to come up with a plan and proposal for Eclipse in general. So, any interested parties that can volunteer, please contact your friendly Architecture Council representative :) Once that's done, we can start to revisit what to do for any specific release using any specific tools or techniques. This issue was discussed at 12/9 Arch. Council call, so for reference, see also http://wiki.eclipse.org/Architecture_Council/Meetings/December_9_2010
To close the loop here: this was resolved for Neon.2 via bug 484004.
