Bugzilla – Full Text Bug Listing
| Summary: | Automatically add required Cactus jars to project | ||
|---|---|---|---|
| Product: | [WebTools] WTP ServerTools | Reporter: | Lawrence Mandel <lmandel> |
| Component: | jst.server | Assignee: | Tim deBoer <deboer> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | david_williams, deboer, dsomerfi |
| Version: | 0.7 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| See Also: |
https://git.eclipse.org/r/107800 https://git.eclipse.org/r/107804 https://git.eclipse.org/r/107834 |
||
| Whiteboard: | |||
| Attachments: | |||
|
Description
Lawrence Mandel
I absolutely agree this is a must, however, it will not work until the cactus stuff resides in its own plugin because otherwise it creates some awkward circular dependencies. If we can get this moved out, I agree we should do this. Actually, I thin I am wrong about this, we don't need a separate plug-in to get this particular feature, but another I was thinking of. What we do need to get the "even better" scenario is permission from the PLT to package Cactus with the plug-in. I will ping the right people and see if we can't get this process going. Great. I think you're right. The stumbling block will be legal approval to redistribute the cactus libraries. Once legal approval is in place the rest should be easy. Daniel, any progress on this? The EMO approved inclusion of the Cactus jars; we are cleared to add them for the 1.5 release. Created attachment 37246 [details]
Patch for automatic library attachment
This patch also requires the forthcoming binaries to be installed. See that attachment for details.
Note: this patch also contains a fix for 106373.
Created attachment 37247 [details]
Additional libraries required for cactus code
These files need to live in the org.eclipse.jst.ui plugin under libraries/cactus/ so the wizard will find and install them when necessary. If there is another convention for binaries dependencies, that is fine with me. Just let me know and we can change the path and the installation code in the wizard.
Incidentally, shipping these jars has been approved.
Hey Tim. Do you mind apply this patch and adding these dependant jars for me? In response to comment #7, our usual approach to redistributing libraries is to create a separate plug-in for the libraries. (Take a look at http://dev.eclipse.org/viewcvs/index.cgi/wst/components/ws/thirdparty/?cvsroot=WebTools_Project for an example with Apache Axis.) In this case I'd say you should probably create a plug-in named org.apache.cactus. Agreed - we should not be repackaging the Cactus jars within this plugin's jar. We'll need to talk to David W. about adding a new plugin. *** Bug 106373 has been marked as a duplicate of this bug. *** BTW, seeing the list of jars in the zip .. I assume all these jars are distributed with Cactus download? Or, are they seperate downloads and projects? FYI, learning from bug 104622, we want to be sure to carefully consider what's listed in but cactus bundle manifest.mf. things like "junit" for example, should not be exposed, or there's risk of conflist with the junit that's shipped with eclipse. FWIW, You may want to study up on http://download.eclipse.org/eclipse/equinox/ Not sure it would be helpful this release ... but, eventually might provide more reuse and less duplication of jars in the distro. >but, eventually might provide more reuse and less duplication of jars in the
>distro.
A very important consideration indeed given the continuous growth in size of Eclipse and Eclipse projects. Good point David.
All the jars are from the cactus distribution. I left some out because they served non-essential tangential purposes. These are the essential dependencies for the cactus runtime. Incidentally, I packaged these in this plug-in because there was considerable reticence to add any new ones because of plug-in bloat. I am happy to put them in a new one if that is the consensus. Is that the case? Assuming it is, I assume someone else will have to put this together for me, since I don’t have committer status. Do I have a volunteer? I would happily do it locally and provide a patch but I have been lead to believe patches don’t deal with binaries too well. (In reply to comment #14) > ... > > Incidentally, I packaged these in this plug-in because there was considerable > reticence to add any new ones because of plug-in bloat. I am happy to put them > in a new one if that is the consensus. Is that the case? Yes, one new org.apache.cactus plugin is the consensus (can you have a consensus of one? :) Our convention is to, as much as possible, to keep third party code seperate from org.eclipse code. > > Assuming it is, I assume someone else will have to put this together for me, > since I don’t have committer status. Do I have a volunteer? I would happily do > it locally and provide a patch but I have been lead to believe patches don’t > deal with binaries too well. > Well, gee Dan, seems like you've got that attaching binaries thing working just fine :) So feel free to create a plugin, zip it up, and attach it here. You can follow the xerces one as an example, if that helps. And you can attach a patch for the modifications to the feature.xml that will be needed. You could probably talk me into creating the map file entry for 'ya though :) Is there any reason to put any of these jars on the classpath or in the manifest? I really only need the jars available in binary form so they can be copied into the WEB-INF/lib of the target web project. Admittedly, this plug-in would be considerably less useful to other plug-ins if it didn't expose anything, but if we are concerned about exposing too much, then it seems to be exposing nothing solves that problem. If someone needs access to the plug-ins externally (which may never happen), then we can expose them piecemeal. BTW, what was the name of the bug you meant to refer to, David? 104622 is this bug. Oh, sorry Dan, it was bug 130292. It talks about same things you are. And, yes, sounds like these jars would be in a resouce-only plugins. And, yes, should not export or list any packages on the manifest.mf And, unless you already have it all worked out, I'd suggest this one not be "packed", as the jars would be easier to copy, or refer to, as files. I had not known this was a "resource-only" jar, but, to me, that actually adds to the "ok-ness" of delivering as a seperate plugin, as it does not add to classpath lookup times. And, btw, I agree we would only want to "expose" cactus classes on a manifest with great (huge) justification. Seems that's a whole different use case. But, I can envision this (quickly?) becomeing a true plugin, (still with no cactus or junit stuff exposed). Long-term we definitely should have our server-core-adapter code unaware of 'cactus' or any specific plugin. Seems there whould be an extension point "test-case-provider" or similar, such that this cactus plugin could provide the interfacing function, so wtp-server stuff could remain blissfully unaware of details. Guess its too late in cycle to make this a firm requirement. Has this ever been coordinated with TPTP? Don't they have a similar functionality? Can you call this bug to their attention and have them comment? Have you installed "callisto" to confirm there's not odd conflicts with "server testing"? Thanks, I guess I have one other question about this. Currently, the new plug-in is not resource-only. I have a tiny bit of code for finding the root directory of the jars via the plug-in class. If it would be better, I can eliminate this, but I need some other way (rather than using the bundle) to find resources from an external plug-in. Is there a standard way of doing that? As far as TPTP, I talked to them a long, long time ago about this and they expressed interest in integrating with the WTP cactus run-time, but no work has been done on this end to accomplish that, and, I think, none on their end. I will let them know about where this and make sure this won't cause any conflicts. It really would be best to have resource only ... and, I think easy to do. (famous last words :) The consuming plugin should be able to "get" the bundle just based on its ID (as a string, semi hard coded in consuming plugin. then there's several methods on "Bundle" to try .. findEntries(....) getLocation()? assigning to dan since he's have such fun with this, so moving tim to cc list. From what I have seen, the only way to do this with a resource-only plug-in is to reach into internal classes. I can get the bundle via InternalPlatform.getBundle(). This seems like the a poor option compared to the others: 1.) Put it back the way it was with the cactus binaries nested inside the plug-in. Unless there is some legal/licensing reason this is a problem, I don't think this is a bad option. 2.) A variation on the above: break out the cactus plug-in into its own containing both the libraries and the eclipse/cactus code. This way the cactus binaries are not sitting in the midst of other jst.server code. 3.) Leave the small bit of code in the org.apache.cactus plug-in. This seems like the least good options since it has the same disadvantage as the above: it mixes 3rd party code with WTP code; not much admittedly, but a little. Opinions? A new consensus of one? Dan, I dont' think internals are needed to get the bundle.
Bundle cactusBundle = Platform.getBundle("cactusPluginBundleSymbolicName");
Should work. That way the only "dependancy" is the string value of the plugin
name ... if versions, change, easy to swap. If some adoptes have qualms about
"shipping" or using that third party code, easy for them to leave out.
I hope I am being helpful, and not missing something obvious you are trying to tell me.
Very helpful. Thanks. I missed that somehow, digging around in internal classes. That should do the job. Created attachment 39084 [details]
Patch for automatic library attachment with external resource plug-in
Created attachment 39085 [details]
Archive of cactus resource project
Ok. Take 2 (or 3 or 4). Tim? Mind trying that again? The patch needs to be installed and there is a new plug-in project in the attached archive. Thanks for your help on this Tim and David. Created attachment 39090 [details]
Patch for automatic library attachment with external resource plug-in
New version of patch. Fixes some NLS warnings. If, by chance, you have already installed the previous patch, don't worry about it. I can create a patch on top of that at some point.
FYI, I've broken the tasks in to steps, and I've added the resource only jar to the build since that's reduces risk of a build breaks. Once you confirm its in the build, you can/should verify all is still ok, and then perhaps Tim can apply the rest of the patch (since I'm not really familiar with the code). Note on the jar: Only substantial change was that I changed version number to 1.7.2.qualifier. (For third party code we have a convention that the plugin version be the same as the underlying third party code version). Other minor changes, such as to add a "provider", externalize two strings, removed empty jar file. I put code in cvs in a new directory, called "thirdparty" under the jst/server component. So, check builds > 4/26 and see if all looks well. Patch applied, fixed JDK 1.5 references and deprecation errors. Checked into 1.5 stream. Will release once the I-build has been declared. Changes released to 1.5 stream. Dan, would appreciate it if you can test on one of the next few builds. Created attachment 40774 [details]
J2EE 1.3 Jar
Assuming it isn't too late to make the change, it would be great if you could replace the current cactus 1.7.2 jar with this one. There are (unfortunately) two cactus-1.7.2.jar files, one for j2ee 1.2 and one for 1.3. We have the earlier one in there now which works, but breaks the tutorial online slightly. If there is time, please replace it with this one. Thanks.
Created attachment 40788 [details]
Fix for Cactus test wizard on latest Eclipse build
Again, assuming it isn't too late, could you run this patch against the latest version of the cactus ui code? There is a problem that is preventing the installation of the jars from working correctly.
Dan, I've released the second patch to 1.5 stream. We shouldn't really keep this bug open for several different things, so please open a new bug to track the new jar file. Since David was running with that part before, please assign the bug to him at least initially. I have created 140889 for the jar, but I do not have permission to assign it to David. David, could you grab it or Tim, could you assign it to him? Either way. Thanks. Verified on 1.5RC3-200605161544. Worked great. Thanks for the help everyone! Verified on wtp-sdk-S-1.5RC3-200605162029. Nice work. Closing bug. New Gerrit change created: https://git.eclipse.org/r/107800 New Gerrit change created: https://git.eclipse.org/r/107804 New Gerrit change created: https://git.eclipse.org/r/107834 |