Bugzilla – Full Text Bug Listing
| Summary: | Need a single jar for deploying ARM instrumented applications | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Ashish Patel <ashishp> |
| Component: | TPTP | Assignee: | Joel Cayne <jcayne> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P1 | CC: | jkubasta, mmings, samwai, sluiman, smith |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 173202 | ||
|
Description
Ashish Patel
Dave, I remember you once said merging jar files was not a good idea. Can you please read the proposal by Ashish and let me know if you want to implement this? Thanks. Dave/Hubert, can we get an update regarding this request? Matt and I don't see it fit to ask our users to put 15 jars manually into their server configuration, which will break when the AC is updated requiring an update to their configuration (due to build version numbers in the folder paths). In addition, this is a very hard to use configuration and a single jar will make installation, configuration, and enhance the over all consumability of TPTP by folds for users and product consumers. This is also specially important when considering a distributed environment where users will have to make server configurations on numerous disparate machines. Adding Andrew as per Joanna's recommendation for assistance in this request. Andy, is this containable in 4.4? I don't think this is a good idea. For one thing Eclipse legal approval is required to repackage code from other projects. Adding another package to TPTP will increase maintenance effort, for example when creating patch drivers. How will this mega jar be included with TPTP? Will it be a separate download? Will it be shipped with the Agent Controller? I can see this would be useful and convenient for a user. Other possible solutions are: 1)provide a script to generate the classpath entry 2)Provide a tool to create the consolidated jar that a user can run. This would still require Eclipse legal approval I believe. This topic probably needs input from a wider audience. The plugins involved are in the Platform and Trace Projects. I don't think this consolidation of plugin jars has been done before in TPTP. Okay, thanks. I will defer to future so that we have time to weigh the options available. Proposal, as I understand it, is to write java code that will automatically find the needed jar files, extract them, and repackage as a single jar and then save in a lib or bin directory. This code will be invoked as part of SetConfig.sh (ie. a modification of the existing Setconfig.java of org.eclipse.tptp.trace.arm). Will save the user the pain of having to manually handle. Proposal has been reviewed by Legal and no issues raised as we are not modifying any jars (ie. not taking subsets of any jars). (In reply to comment #7) > Proposal, as I understand it, is to write java code that will automatically > find the needed jar files, extract them, and repackage as a single jar and then > save in a lib or bin directory. This code will be invoked as part of > SetConfig.sh (ie. a modification of the existing Setconfig.java of > org.eclipse.tptp.trace.arm). Will save the user the pain of having to manually > handle. > Proposal has been reviewed by Legal and no issues raised as we are not > modifying any jars (ie. not taking subsets of any jars). This doesn't address Dave's support/maintainence concerns. having a tool to do the bundling is ok, but it is a matter of when this is done and how it is refreshed. setconfig is likely the wrong time to do this. There is also the issue of raw bloat and path sequence when some of the content is already on the target environment. Maybe we should provide a "project" (or an add ARM to your project wizard)that has all this stuff in it, which can be used during build and unit testing, and also contains the script to create this special bundle. (In reply to comment #8) > This doesn't address Dave's support/maintainence concerns. having a tool to do > the bundling is ok, but it is a matter of when this is done and how it is > refreshed. setconfig is likely the wrong time to do this. AP: The strategy here is not to be adding any more support/maint with this single jar, than we already have. Our goal should be to keep the same amount of support/maint or reduce it. I would imagine that we have more support/maint issues with our current approach (asking users to find 17 jars in different folders inthe AC plugin folder) than actually making the 1 dependency jar that is needed - which I have already seen with customers and had to step them through the process over the phone! We are proposing that the jar be generated when SetConfig is run (rather than having a separate package/plugin for it altogher or having some custom script in the build system to make it) since we already have code that is invoked by SetConfig when our trace.arm plugin is configured. Therefore, if you patch/update any of the jars in the AC plugins directory, the user will run SetConfig again and the single jar will be rebuilt using the patched jars. Having said that, what are the specific support/maint concerns TPTP/Dave is worried about? > There is also the issue of raw bloat and path sequence when some of the content > is already on the target environment. > Maybe we should provide a "project" (or an add ARM to your project wizard)that > has all this stuff in it, which can be used during build and unit testing, and > also contains the script to create this special bundle. AP: The targeted environment for this jar is for distributed server environments (no eclipse/tptp on that machine just an AC). The problem right now is that we can't expect customers to pick up 17 jars from different folders and piece it together. I would imagine that we have more support/maint issues with our current approach than actually making the 1 dependency jar that is needed. If the user has the workbench, we already have a BTM Library that can be added to the build path - so for developers its already easy to get the depenencies onto their path - we need a good soln for non-developers that is easy to config. AP: I don't think we'll have a problem when some of the content is already on the target environment. I've already found environments that have previous versions of TPTP content (ie. WAS). So what I have already done is made all the BTM pieces load on a separate classloader so it is contained away from the execution env that depends on the older versions of the TPTP content. I also got blessing from WAS JVM/Core team that this was the right approach to take - it has already been tested in TPTP 441 and works nicely without breaking the rest of the server (which is the case in pre 441 versions). Any comments on our approach is valued in my attempt to make customer and product support easier. I don't think we are in much dissagreement, perhaps a short direct conversation will work ;-) (In reply to comment #9) > (In reply to comment #8) > Having said that, what are the specific support/maint concerns TPTP/Dave is > worried about? When a customer is sitting with version x and the bundled jar reflects version x content, when X+ comes along with a fix/change in one of those jars, the customer will need to know how and what to do to update the packaged jar. I gather one approach proposed is that we actually provide this as part of our release packaging and not require even a setconfig. There is also the issue that some of the jars may already be in the path of the server. Using the "me first" strategy may create problems for the users of the older jars/classes. > AP: The targeted environment for this jar is for distributed server > environments (no eclipse/tptp on that machine just an AC). Understood. However TPTP is the project we are discussing here so it is at least being used in a unit test or BtM way. After all, why is the jar needed with all the AC connections if it is not ever to be used? ;-) I am suggesting some work/thought be done to make WTP scenarios work seamlessly as well, which require runtime deployment/configurations, and in that context give the user a way to export the runtime for standalone deployment. > I would imagine that we have more support/maint issues > with our current approach than actually making the 1 dependency jar that is > needed. No argument that something needs to be done. We just need to make sure we are being optimal for the use cases we are a part of. > AP: So what I have already done is made all > the BTM pieces load on a separate classloader so it is contained away from the > execution env that depends on the older versions of the TPTP content. This is a good way to configure a solution and we should consider how to streamline it or even get transparent. A jar with the plug-ins requested has been created in buildToManageLibrary.jar. I created an about.html with the Third Party content and legal has reviewed it. The buildToManageLibrary.jar is in a zip called buildToManageLibrary-<releaseDate>.zip along with armLoader.jar and armProbes.jar. A link has been added in the standalone offerings section to download the zip file. cls |