Does IntelliJ Support Standalone Gorm? In the sense that it offers method completion for domain objects. There is a lot of information out there that says it has been implemented, however, as of March 29, 2017 on YouTrack it appears that it is still unavailable.
Documentation for IntelliJ 13 also explicitly states that GORM standalone is supported, however, it does not seem to work when configured with Spring Boot.
It was also supposedly released with IntelliJ 16.
So has anyone gotten it to work? What do you need to do to configure your project to support standalone gorm?
Does IntelliJ Support Standalone Gorm?
Yes.
So has anyone gotten it to work?
Yes. Nothing special is required to do that. As an example, open the project at https://github.com/grails-samples/gorm-outside-grails in IntelliJ IDEA. That isn't a boot app, but if it were, the relevant behavior still works the same way. To see auto-completion in action, edit the file at https://github.com/grails-samples/gorm-outside-grails/blob/d56e56bc12b2ba9732449fd6779ae0ac0e487ec2/src/test/groovy/domain/PersonSpec.groovy and see the autocompletion you get behind p.<method name goes here>. You get completion for all the normal GORM methods like attach, discard, hasErrors etc. You also get auto completion for things like dynamic finders. It all works quite well.
Related
I have a DMN which calculates (a common unit of work), which I want to plug-in in another DMN. Is there an example for this in kogito examples?
Can someone help me to get me an example.
No, there's no example.
Included models are not supported on DMN editor when it's running on the online version or the VSCode version. This feature will be available soon, so you can keep track of this by looking at KOGITO-697.
However, Included models are supported on DMN editor when it's running on Business Central. So you can create your models there, and execute them on Kogito (just for now) - as #tarilabs said, the runtime already supports it.
After recently updating my project to meteor 1.2 and including the new ecmascript package (to use ES2015 features), I realized that my server debug breakpoints will never run, no matter what I do.
After reading about different ES6 posts on meteor forums and jetbrains , I tried setting up file watchers to create sourcemaps, but:
meteor complains about the generated files(so you have to move them to special folders in order to keep going)
It still doesn't work :(
Setting up spy-js also didn't work (never tried before so maybe I did it wrong)
I could reproduce the problem with the basic TODOs application and debugging with default options.
It is fixed for now in EAP 11 builds.
Known issue, please follow WEB-18074 for updates. Unfortunately I can't offer any workarounds:(
background
I have designed many tools in the past year or so that is designed to help me program for XPages. These tools include primarily helper java classes, extended logging (making use of OpenLogger and my own stuff), and a few other things that I personally feel I cannot work without. It has been discussed with my employer, and we feel that it might be a good idea to start publishing these items to openNTF. Since these tools are made up of about 3 .nsfs, all designed to use the same java code, key javascript classes, css, and even a custom control or two, I would like to consolidate key items into a plug-in that can be installed at the server and client level. I want to do this consolidation before I even think about publishing any of the work I've done so far. It would just be far too much work to maintain, not just for me, but for potential users. I have not really found any information on how to do such a thing in google searches. I also have to make sure that I am able to make use of the ExtLib libraries, openNTF Domino API, and the Notes API.
my questions
How does one best go about designing such plug-ins? Must a designer
use eclipse, or is this it possible to do this directly in the Notes
Designer?
How does a designer best go about keeping a server and client up to date while designing and updating the plug-in code? Is this why GitHub is often used?
Where is the best place to get material to get started in this direction? I sort of feel lost in the woods, knowing I need to head north, but not having a compass for that first step.
Thank you very much for your input.
In my experience, I found that diving into plug-in development is a huge PITA until you get used to it, but it's definitely worth it overall.
As for whether you can use Designer for plugin development: yes, but you will likely eventually want to not do so. I started out by using Designer for this sort of thing for a while, presumably with the same sentiment as you: why bother installing another instance of Eclipse when I'm already sitting in one all day? However, between Designer's age (it's roughly equivalent to, I think, Eclipse 3.4), oddities when it comes to working sets between the "Applications" and "Project Explorer" views, and, in my case, my desire to use a Mac app, I ended up switching.
There are two major starting points: the XSP Starter Kit (http://www.openntf.org/internal/home.nsf/project.xsp?name=XSP%20Starter%20Kit) and Niklas Heidloff's video on setting up Eclipse for XPages development (http://www.openntf.org/main.nsf/blog.xsp?permaLink=NHEF-8RVB5H). The latter mentions the XPages SDK (http://www.openntf.org/internal/home.nsf/project.xsp?name=XPages%20SDK%20for%20Eclipse%20RCP), which is also useful. In my setup, I found the video largely useful, but some aspects either difficult to find (IBM's downloads are shifting sands) or optional (debugging, which will depend on whether or not you're using Eclipse on Windows).
Those resources should generally get you set up. The main thing to worry about when setting up your Eclipse environment will be making sure your Plug-In Execution Environment is properly done. If you're following the SDK setup instructions, that SHOULD get you where you need to be.
The next thing to know about is the way plugins are structured. Each plugin you want to install in Designer or Domino will also be paired with a feature project (a feature can house several plugins), and potentially an update site - the last one is optional if you just want to import the features into an Update Site NSF. That's how I often do my normal plugin development: export the paired feature to a directory and then import the feature into the server's Update Site NSF and then install in Designer from there using Application -> Install. You can also set things up so that you deploy into the server's plugin/feature directories instead of taking the step of installing into an update site if you'd prefer. GitHub doesn't really come into play for this aspect - it's more about sharing/collaborating with your code and also having a remote storage location for your git repositories (which I highly advise).
And as for the "lost in the woods" feeling: yep, you'll have that for a good while. There are lots of moving parts and esoteric concepts to get a hold of all at once. If you mostly follow the above links and then start with some basics from the XSP Starter Kit (which is itself a plugin project that you can pair with a feature) - say, printing text in the Activator class and making an implicit global variable just to make sure it works - that should help get your feet wet.
It's best done in Eclipse. You can debug your code running on the server from there, as well as run it directly from there. The editors are also more up-to-date. You want:
Eclipse for RCP and RAP developers
XPages SDK for Eclipse RCP (from OpenNTF)
XPages Debug Plugin (from OpenNTF - basically allows you to load the plugins to the Domino server dynamically, rather than exporting to an Update Site all the time)
XSP Starter Kit on OpenNTF is a good starting point for a plugin. There are various references to the library id, which has to be unique for your plugin. Basically, references to org.openntf.xsp.starter need changing to whatever you want to call your plugin. You're also best advised to remove what you don't need. I tend to work in a copy of the Starter, remove stuff, build and if there are errors with required classes (Activator.java obviously will be required and some others), then paste them back in from the Starter.
XPages OpenLog Logger is a good cross-reference, that was built from XPages Starter Kit. It's pretty much stripped down and you'll be able to see what had to be changed. A lot of the elements of the XSP Starter Kit correspond to Java classes you'll probably be familiar with from your XPages Java development.
GitHub etc tend to be used as source control, which is useful for working out what's changed from time to time.
I need premake to set the EXCLUDED_SOURCE_FILE_NAMES and INCLUDED_SOURCE_FILE_NAMES variables for my XCode project. Anybody knows how to do this?
There isn't a way to do that directly, but if you provide more details on what you are trying to achieve there might be a workaround. You are already aware of the excludes() API?
In response to additional information in comment: Ah, a unity build then. That isn't directly supported yet, no, though it is coming up quick on the roadmap now. The way most people handle it currently is as a separate project. Not as convenient or elegant, but does allow Debug, Release etc. configurations of the unity build, which can useful too.
Firefox 4 comes soon (ok, next year ;)) and there is a Firefox plugin to sync your bookmarks etc. with Firefox 3.whatever .
I would like to know if anyone has a comprehensive, up-to-date tutorial to integrate Firefox Sync into your own plugin? Or any idea regarding this?
I mainly followed this official "tutorial" and also this blog post, but the information seems to be slightly outdated.
For example, the object is not called Weave anymore but Engines and the weave.engines. preference became services.sync.engines.. I played a little with all the mentioned options, but it does not seems to work (and my plugin does not show up in list where you can select what to sync).
I assume that the Tracker and Store classes are fine, the main problem is to register the engine...
The ClientAPI tutorial you mention is definitely the way to go. I updated it recently so if something's not working, please let us know so I can fix it in the docs. Wladimir's blogpost is definitely quite old and contains some outdated information. We will also make changes to some parts of the API in the upcoming beta releases, so be prepared for some flux...
The Weave namespace is still the canonical way to access Sync related APIs from UI code. It exposes components such as Weave.Service and Weave.Engines. You can import it via Components.utils.import("resource://services-sync/main.js"). If you want to implement your own engine, you'll have to import the actual underlying modules, though (all listed in the ClientAPI tutorial). The tutorial also describes how to register your custom engine implementation. Once it's registered, it won't automatically show up in the preferences UI, though. I suggest building your own UI that flips the services.sync.engine.YOURENGINE pref in your add-on's preferences.
Out of curiosity, what kind of data are you trying to sync?