Community
Participate
Working Groups
We should either include the source code with our downloads, or provide alternate zips that include full source. The reason is that a common scenario would be for someone to install our SDK into Eclipse and attempt to develop an MDR. If they are debugging their code and stepping into our classes, they will see no source if they installed from the download zips instead of checking out projects from Eclipse.
David: Do you require the separate download of source code for particular module or for all the modules.
I admit I'm not that familiar with how src code is packaged typically in Eclipse. I hope that Ruth or someone more experienced with TPTP can help you there. The idea is that when you open any class we deliver, you will see the src code, provided that you have installed the optional src download(s).
David: There is the SDK package for resource modelling (http://build.eclipse.org/technology/cosmos/downloads/COSMOS/1.0.0/COSMOS-1.0.0-200803131218/cosmos-rm-incubation-sdk-COSMOS-1.0.0-200803131218.zip) Can you verify if that is what you are looking for?
Yes, that displayed the source correctly. Please do the same for our other download zips. The only question I have is whether we need to provide two versions of our downloads, with & without source, since some people might not want the bigger source downloads. What does TPTP do?
I see TPTP has two downloads for each subproject, Runtime and SDK. Is the only difference between the two that the SDK has source? In our case would there be other things like the SML-IF editor or CMDBf toolkit that wouldn't be included in a runtime?
Yes the difference between the two is SDK contain the source code files. I suppose we require SDK package for Data Collection and Data Reporting. Do we require, this for COSMOS-SDK and Demo also?
yes, the SDK should include source too. I don't think the demo needs to though. I think we will have some confusion if we have "SDK" and "Runtime" versions of the SDK. We would be overloading the SDK term. How about we call the two versions of each package "Binary" and "Binary with Source" or something like that? Maybe look at some other Eclipse projects besides TPTP (e.g. Webtools) for some more ideas.
To avoid confusion for COSMOS-SDK package. We can name it as COSMOS-Runtime (will contain only binaries) and COSMOS-SDK (will contain source code + binaries). What is your opinion?
That would probably work. Though it will be interesting to see what it looks like when it's done. Any of the ex-TPTPers have an opinion on this?
This gets into the discussion about download structure (bug 216771). Let's talk about the requirements of this bug first. We want to have the source code of the COSMOS project be downloadable from the download page. Source code is from all subprojects, some are plugins, some are web applications. The simpliest solution to meet the requirement to zip up code snapshot checked out during the build and make it available for download. But you may decide to pair them up with the runtime zips and build source plugins using PDE where applicable. For runtime zips, I prefer using more descriptive names, such as "MDR Toolkit", "SML Editor", etc., as opposed to "COSMOS-Runtime".
Created attachment 92848 [details] Proposal to modify download page for sdk downloads I am attaching a mockup screenshot as the way we can implement sdk and runtime downloaded features. This is the way webtools bundle their components. Please provide feedback on this.
The basic organization looks good. The wording of the components needs some work. Would the COSMOS SDK download include source by default? I would expect so. Likewise I'd expect the Demo download would not include source. Should we discuss this on the Arch Call?
yes COSMOS SDK will include the SDK for all(SML SDK+DC SDK+DR SDK) and there would be no source code available in COSMOS demo.
For what it's worth: In the short-term, I agree with the proposed changes but in the long-term (i.e. post 1.0) COSMOS packaging should be divided by functions of system management. For example: > Deployment Management > Configuration Management > Resource Management and etc... There will most likely be a common package shared across all other packages which will likely contain the back-bone structure of COSMOS (e.g. management domain, broker, common UI components, and etc..)
Saurabh: I finsihed creating the SDK packages for Resource Modeling, Data collection and COSMOS SDK. Can documentation required for these sdk package be created for COSMOS Download page. Data reporting module is packaged differently than other modules. It does not contain features and plugins. Just wondering, if it makes sense to create SDK package for this.
*** Bug 215613 has been marked as a duplicate of this bug. ***
Saurabh: This enhancement is open for quite a while. Have completed the work, creating the source SDK. Is there any update on creating the documentation. If yes, then we can add documentation and link to SDK packages at the download page and close this bug.
David: To complete working on this bug, should I added this description (as written in the patch) for the Resource Modeling SDK package (This SDK package is for developers who wants to develop and extend cosmos resource modeling framework) or whatever you suggest Hubert: Can you suggest the wording for the Data Collection (both for SDK and non-SDK packages)
"This SDK package is for developers who want source code included with the tooling in order to develop or extend the Resource Modeling framework." does that sound good to you, Ali?
(In reply to comment #19) > does that sound good to you, Ali? Sounds fine.
Jagmit, Can you give me a summary of what source files are available for download and how are they packaged? Thanks, Hubert
Hubert: Data Collection SDK module is packaged as http://build.eclipse.org/technology/cosmos/downloads/COSMOS/1.0.0/COSMOS-1.0.0-200804061200/cosmos-dc-incubation-sdk-COSMOS-1.0.0-200804061200.zip It contains source plugin (org.eclipse.cosmos.dc.source_*), which contains source code for various data collection plugins.
Hubert: Do you input regarding description for data collection sdk package. Jagmit
Hi Jagmit, I was asking for a summary of how source code is packaged in COSMOS, for all subprojects. I want to make sure the source of all COSMOS components are covered. As for the data collection SDK, we may not need this zip at all because the code in the data collection zip may not be part of v1.0. Hubert
I created the SK packages for resource modelling, Data Collection and COSMOS SDK. For all the plugins, which were packaged in these subprojects, created source plugins. And also create the sdk feature, to include these source plugins. In summary I followed the above process to create the SDK packages.
David: Have updated link for Resource modeling SDK package to the download page for the latest build COSMOS-1.0.0-200804081401.
Marking this bug as fixed
I reopened the bug because I think the source code of the data visualization subproject is missing. Sheldon, can you comment on how the UI source code should be packaged? In i10, the data manager framework and data manager are not packaged as plugins. If we want to provide source code for the build, we should include the source for all parts of the project, not just plugins. I am fine with simple solutions like zipping up the source tree in a zip file.
The data visualization java source can be packaged as zip files. The javascript and configuration files should be packaged in a directory structure.
The weekly integration build site did not provide the "with source" (SDK) options for download. IIRC, there is still an additional step to make these zips with source available on the web site. I would think we have to wait until those are visible as part of regular builds before we can mark this as fixed.
Hi Jagmit, Can you add the following plug-ins to the sdk. I modifed the projects to be plugins. I also changed the biuld.properties file to define what should be included in the source plugins. org.eclipse.cosmos.examples.e2e.dr.template org.eclipse.cosmos.dr.drs.service.handler org.eclipse.cosmos.dr.ps.common org.eclipse.cosmos.dr.ps.components org.eclipse.cosmos.examples.e2e.dr.drs.service.handler org.eclipse.cosmos.examples.e2e.dr.views org.eclipse.cosmos.examples.e2e.web.ui You will need to update the souce feature to include these plugins.
Hi Sheldon, Do we need seperate feature for these new reporting plugin. Somehow this is blocking the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=226381 , since "dr.web.ui.viewer" source compilation requires classes from "dr.ps.common" and "dr.ps.common" cannot be built unless it is included in one of the feature. We might also want to bundle the classes of "dr.ps.common" into a jar (by specifying the option in build.properties) so that they could be placed in "dr.web.ui.viewer/WEB-INF/lib" folder.
(In reply to comment #32) > Hi Sheldon, > > Do we need seperate feature for these new reporting plugin. Somehow this is > blocking the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=226381 , since > "dr.web.ui.viewer" source compilation requires classes from "dr.ps.common" and > "dr.ps.common" cannot be built unless it is included in one of the feature. We > might also want to bundle the classes of "dr.ps.common" into a jar (by > specifying the option in build.properties) so that they could be placed in > "dr.web.ui.viewer/WEB-INF/lib" folder. > The "dr.web.ui.viewer" plugin shouldn't be part of the source feature since this is a plugin that contains code that should not be extended.
(In reply to comment #33) > (In reply to comment #32) > > Hi Sheldon, > > > > Do we need seperate feature for these new reporting plugin. Somehow this is > > blocking the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=226381 , since > > "dr.web.ui.viewer" source compilation requires classes from "dr.ps.common" and > > "dr.ps.common" cannot be built unless it is included in one of the feature. We > > might also want to bundle the classes of "dr.ps.common" into a jar (by > > specifying the option in build.properties) so that they could be placed in > > "dr.web.ui.viewer/WEB-INF/lib" folder. > > > > The "dr.web.ui.viewer" plugin shouldn't be part of the source feature since > this is a plugin that contains code that should not be extended. > Right, he's not suggesting that. He's saying that dr.web.ui.viewer prereqs dr.ps.common. However, dr.ps.common is not part of a feature yet. He is asking what feature you want to put it in, now that it's a first class plugin.
(In reply to comment #34) > (In reply to comment #33) > > (In reply to comment #32) > > > Hi Sheldon, > > > > > > Do we need seperate feature for these new reporting plugin. Somehow this is > > > blocking the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=226381 , since > > > "dr.web.ui.viewer" source compilation requires classes from "dr.ps.common" and > > > "dr.ps.common" cannot be built unless it is included in one of the feature. We > > > might also want to bundle the classes of "dr.ps.common" into a jar (by > > > specifying the option in build.properties) so that they could be placed in > > > "dr.web.ui.viewer/WEB-INF/lib" folder. > > > > > > > The "dr.web.ui.viewer" plugin shouldn't be part of the source feature since > > this is a plugin that contains code that should not be extended. > > > > Right, he's not suggesting that. He's saying that dr.web.ui.viewer prereqs > dr.ps.common. However, dr.ps.common is not part of a feature yet. He is > asking what feature you want to put it in, now that it's a first class plugin. > Okay, I guess I thought this bug was related to creating source code bundles associated with a source code feature. David, you added the dr.ps.common dependency to dr.web.ui.viewer. I guess you added that to make the dr.web.ui.viewer compile? We should remove the dr.ps.common dependency from dr.web.ui.viewer. We should bundle dr.ps.common in the WEB-INF/lib directory. It is difficult to make the data visualization code plugin bundles since the code depends on data collection code that are not bundles. Furthermore, it seems that a bundle will on be activated if all its dependency are activated. I found problems with activating the apache-muse bundle since it depends on org.apache.xpath which we don't use.
(In reply to comment #35) > Okay, I guess I thought this bug was related to creating source code bundles > associated with a source code feature. > > David, you added the dr.ps.common dependency to dr.web.ui.viewer. I guess you > added that to make the dr.web.ui.viewer compile? > > We should remove the dr.ps.common dependency from dr.web.ui.viewer. We should > bundle dr.ps.common in the WEB-INF/lib directory. > > It is difficult to make the data visualization code plugin bundles since the > code depends on data collection code that are not bundles. Furthermore, it > seems that a bundle will on be activated if all its dependency are activated. > I found problems with activating the apache-muse bundle since it depends on > org.apache.xpath which we don't use. > I added it there because dr.web.ui.viewer would not compile when Saurabh tried to add it to the build. It seemed logical to add that prereq since you just made dr.ps.common a real plugin (which is why the discussion of this is occurring in this particular bug report). Saurabh, is there a way to dynamically put dr.ps.common on the build path of dr.web.ui.viewer so we don't have to put the hard plugin dependency in?
(In reply to comment #36) > (In reply to comment #35) > > Okay, I guess I thought this bug was related to creating source code bundles > > associated with a source code feature. > > > > David, you added the dr.ps.common dependency to dr.web.ui.viewer. I guess you > > added that to make the dr.web.ui.viewer compile? > > > > We should remove the dr.ps.common dependency from dr.web.ui.viewer. We should > > bundle dr.ps.common in the WEB-INF/lib directory. > > > > It is difficult to make the data visualization code plugin bundles since the > > code depends on data collection code that are not bundles. Furthermore, it > > seems that a bundle will on be activated if all its dependency are activated. > > I found problems with activating the apache-muse bundle since it depends on > > org.apache.xpath which we don't use. > > > I added it there because dr.web.ui.viewer would not compile when Saurabh tried > to add it to the build. It seemed logical to add that prereq since you just > made dr.ps.common a real plugin (which is why the discussion of this is > occurring in this particular bug report). > Saurabh, is there a way to dynamically put dr.ps.common on the build path of > dr.web.ui.viewer so we don't have to put the hard plugin dependency in? We can specify the required packages in "Imported Packages" of Manifest file, but I am not sure if it will start the Activator if the specified package is not found in any of the plugin.
(In reply to comment #37) > We can specify the required packages in "Imported Packages" of Manifest file, > but I am not sure if it will start the Activator if the specified package is > not found in any of the plugin. The package is found because it is contained in a jar file in the Bundle-ClassPath in MANIFEST.MF (which reminds me of a new requirement I need to add to bug 226381 :-)). So the only issue is making sure the classes compile during the build. They definitely work at runtime, since we are able to test this.
Added the plugins mentioned in Comment# 31 in the latest cosmos driver COSMOS-1.0.0-200804142151
Marking this as fixed
