Bugzilla – Full Text Bug Listing
| Summary: | Enable compilation of Xpand/Xtend/Check files outside Java classpath | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] M2T | Reporter: | Stephan Eberle <stephaneberle9> | ||||||||
| Component: | Xpand | Assignee: | Karsten Thoms <karsten.thoms> | ||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||
| Severity: | enhancement | ||||||||||
| Priority: | P3 | CC: | ali.akar82, benedikt.niehues, idydieng, karsten.thoms, sven.efftinge | ||||||||
| Version: | 1.0.1 | Flags: | karsten.thoms:
juno+
|
||||||||
| Target Milestone: | M2 | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
Hi Stephane, I'm sorry that people don't like leveraging the Java class path mechanism. Is it the JDT dependency or is it the sometimes unneeded complexity/flexibility? I assume that you are executing the Xpand/Xtend/Check from within the IDE (i.e. triggered by an action or builder)? Otherwise you would still have the Java dependency at runtime, wouldn't you? I have to say, that It will likely never be possible to edit Xtend 2 files without JDT. The language really is just a thin layer on top of Java and we reuse the existing infrastructure intensively. We'll have to check internally who can review and test your contribution. (In reply to comment #1) > I'm sorry that people don't like leveraging the Java class path mechanism. > Is it the JDT dependency or is it the sometimes unneeded > complexity/flexibility? There is no problem with the dependency to JDT. It is perfectly acceptable to ship, e.g. and AUTOSAR tool, with the whole bunch of JDT plug-ins inside. It's just that the users don't want to be fact to any sort of JDT stuff when they use the tool. They have or author AUTOSAR models and want to generate C code from it. In that context, Java is just not meaningful to them. They want to author Xpand templates, potentially complement them by some Xtend extensions, optionally add some Check constraints, and that's it. The case where they need to write Xtend extensions that reach out to self-written Java code is really very rare. And for everything else it should not be necessary to expose JDT specific things in the projects of their workspaces. In particular, these users would find it odd, that they have to create Java source folders and put their Xpand/Xtend/Check file there so as to get them compiled. They would prefer to organize them in ordinary folders instead. > I assume that you are executing the Xpand/Xtend/Check from within the IDE (i.e. > triggered by an action or builder)? That's correct. We have written some sort of extended Xpand/Xtend/Check UI support that invokes Xpand/Xtend/Check via the respective facades and exposes corresponding actions, configuration wizards, and preference pages in the UI. All this is btw. currently contributed to the Sphinx project (in experimental state yet). This UI integration code operates basically at the same level as workflow components. It enables users to select Xpand templates, Check files, outlet folders, etc. visually and relieves them from having to author workflow files for the same purpose. This is certainly less flexible than what you can do with workflows but more convenient for non-workflow aware users. > I have to say, that It will likely never be possible to edit Xtend 2 files > without JDT. The language really is just a thin layer on top of Java and we > reuse the existing infrastructure intensively. As said before, the main point is not to get rid of JDT dependency. So the fact of that Xtend 2 builds on top of JDT should not be any problem for us. The only thing that we would like to get is that Xtend 2 files can be edited without abolutelty having to place them on the Java classpath of the project where you author them. In the current Xtend framework this was achievable by a relatively small modification that enables applications to customize the way how Xtend/Xpand/Check resources get resolved. As explained in the description we have made sure that any such requests is delegated to the StorageFinder interface and that custom implementations of the same that are contributed to the existing ''org.eclipse.xtend.shared.ui.storageFinder'' extension point can take full control over how to handle the resource resolution requests. Btw., in our own project (and the experimental Sphinx code) we have even gone one step further: from our own StorageFinder we delegate to an extended implementation of the MWE ResourceLoader which then actually performs the resolution of the resources. This enables us to have one central point for all Xtend/Xpand/Check resource resolution requests that happen at both incremental built time and Xtend/Xpand/Check facade runtime. At the bottom line, we can now create "lightweight" Xtend/Xpand projects which have just the XtendXpandNature and still provide full support for authoring, compilation and invocation of the Xtend/Xpand/Check file inside. Java nature, classpath, etc. are only needed when users want to write extensions that reach out to self-written Java code that is developed along with these extensions. > We'll have to check internally who can review and test your contribution. Thanks, that would be great! I will do a review next week (April 18-21) Hi Stephan! Your patch extends the interface of the StorageFinder ExtensionPoint. So we would need to increase the major version. But for this release it is not possible anymore. Perhaps we can do it in a future release. (In reply to comment #4) > Your patch extends the interface of the StorageFinder ExtensionPoint. So we > would need to increase the major version. But for this release it is not > possible anymore. Ok, I can understand that. > Perhaps we can do it in a future release. Yes, that would be good. For the time being we work with a patched version of the affected plug-in but we would throw this patch away and replace it by a future version of Xpand as soon the proposed enhancements have been incorporated. *** Bug 353091 has been marked as a duplicate of this bug. *** Created attachment 203999 [details] patch for bug 341921 as the codebase changed sinch stephan posted the patch this patch should work with the new codebase. Created attachment 204014 [details] additional fix for bug 341921 additional fix for bug 341921 to be aware of api conformity Applied and reviewed the patch. Thanks for submitting. Bug resolved before Xpand 1.2 release date => Closing |
Created attachment 192561 [details] Patch for org.eclipse.xtend.shared.ui with implementation for proposed enhancement = Problem description = Xpand/Xtend/Check is a great and versatile set of tools for M2M and M2M. While it gets more and more applied to the production of embedded software (e.g., generation of AUTOSAR BSW configuration code) it remains a bit unhandy that Xpand/Xtend/Check resources have to be located on the Java classpath for being detected by the XtendXpandBuilder. Users working in the embedded field have really liked Xpand/Xtend/Check but are typically not familiar with Java. They would like to organize their Xpand/Xtend/Check in ordinary folders but still be able to benefit from convenience of Xpand/Xtend/Check editor, incremental builder, and navigation within the code (with F3), etc. It therefore would be of great help to remove the current limitation of that Xpand/Xtend/Check must be on the Java classpath. = Resolution proposal = We have thought of and implemented a solution to this problem. It is attached as patch to this bug and based on the following analysis and ideas: * Currently, the Java classpath seems to be leveraged to set the scope of resources to be included in the build process. Everything that is visible on the Java classpath is included in the build, everything else is not. * We would like to see that Xtend/Xpand/Check build infrastructure enables clients to hook in their own resource scoping service which enables non-Java classpath based Xtend/Xpand/Check resource resolution strategies to be implemented. * We have noticed that this is already possible to some extent - clients can contribute ''StorageFinder'' implementations to the ''org.eclipse.xtend.shared.ui.storageFinder'' extension point. * So we have used the ''StorageFinder'' service as a starting point but needed to enhance it in the following wayd to get a fully working solution out of it: ** To introduce a new method ResourceID findXtendXpandResourceID(IJavaProject project, IStorage file) on StorageFinder that does the opposite of the existing method IStorage findStorage(IJavaProject project, ResourceID id, boolean searchJars), i.e., enables the XtendXpandBuilder to look up the ResourceID for a given storage or file. ** To implement this new method in JDTStorageFinder by delegating to corresponding and already existing method on JDTUtil ** To delegate to the StorageFinder service in all locations where it is necessary to calculate the ResourceID from the underlying storage or file (i.e., creation of keys for caching IXtendXpandResources in XtendXpandProject, XtendXpandProject#findXtendXpandResource(), XtendXpandProject#unregisterXtendXpandResource()). ** To tweak XtendXpandBuilder#isXtendXpandResource() so that it no longer ignores Xtend/Xpand/Check resources that are located outside the Java classpath. = Disclaimer = We are aware of the fact that the whole Xpand/Xtend/Check infrastructure is currently being redesigned in the context of Xtend 2, and that the implementation of the enhancement proposed here is therefore likely to be obsolete very soon. We prefer to submit it anyway, so as to make sure that the fundamantal idea behind it finds its way into the new infrastructure.