I need to do frequently code changes in Hybris and test it on the server on my local setup. so every time I need stop the server and perform ant all then again start the server. this process takes at least of 15 minutes.
ant update updates the whole system where i just need to rebuild my java classes. so is there any way I can perform ant all or build java files again while server is running.
You can use JRebel for dynamic class replacement in runtime. JRebel tracking updated class and spring config files and replace them in runtime. Also you can try to use HotSwapAgent for free but JRebel is best option.
Related
Is there a command to build only the administration part of a specified plugin? Right now I am building the whole administration to build the public resources for the plugin, which of course takes more time. Since every plugin has it's own resources, shouldn't it be possible to do this?
Since Shopware 6.4.8.0 it seems to be possible to only build the extensions (not a single one, but at least only extensions) by adding the environment variable SHOPWARE_ADMIN_BUILD_ONLY_EXTENSIONS=1
There are no out-of-the-box scripts to selectively build only one module.
The build is based on one single webpack config in vendor/shopware/administration/Resources/app/administration which includes each extension's code as as submodule.
If you are asking to speed up development, you might want to use bin/watch-administration.sh which should only rebuild changed files when you save them.
I want to package a Groovy CLI application in a form that's easy to distribute, similar to what Java does with JARs. I haven't been able to find anything that seems to be able to do this. I've found a couple of things like this that are intended for one-off scripts, but nothing that can compile an entire Groovy application made up of a lot of separate Groovy files and resource data.
I don't necessarily need to have the Groovy standalone executable be a part of it (though that would be nice), and this is not a library intended to be used by other JVM languages. All I want is a simply packaged version of my application.
EDIT:
Based on the couple of responses I got, I don't think I was being clear enough on my goal. What I'm looking for is basically a archive format that Groovy can support. The goal here is to make this easier to distribute. Right now, the best way is to ZIP it up, have the user unzip it, and then modify a batch/shell file to start it. I was hoping to find a way to make this more like an executable JAR file, where the user just has to run a single file.
I know that Groovy compiles down to JVM-compatible byte-code, but I'm not trying to get this to run as Java code. I'm doing some dynamic addition of Groovy classes at runtime based on the user's configuration and Java won't be able to handle that. As I said in the original post, having the Groovy executable is included in the archive is kind of a nice-to-have. However, I do actually need Groovy to be executable that runs, not Java.
The Gradle Cookbook shows how to make a "fat jar" from a groovy project: http://wiki.gradle.org/display/GRADLE/Cookbook#Cookbook-Creatingafatjar
This bundles up all the dependencies, including groovy. The resulting jar file can be run on the command line like:
java -jar myapp.jar
I've had a lot of success using a combination of the eclipse Fat Jar plugin and Yet Another Java Service Wrapper.
Essentially this becomes a 'Java' problem not a groovy problem. Fat Jar is painless to use. It might take you a couple of tries to get your single jar right, but once all the dependencies are flattened into a single jar you are now off an running it at the command line with
java -jar application.jar
I then wrap these jars as a service. I often develop standalone groovy based services that perform some task. I set it up as a service on Windows server using Yet Another Java Service and schedule it using various techniques to interact with Windows services.
Currently I am busy with a brand new XPages project. I use Java and Managed Beans to access the data.
Till now I don't have to use Lotusscript ;-)
One of the last things is to create a scheduled agent to perform some backend stuff. There is already some logic in Java classes, who are in a directory in the WEB-INF directory.
I son't want rewrite these Java logic to Lotusscript, but reuse.
Is is possible to access these Java classes, from a (scheduled) Java agent??
Assuming that the WEB-INF directory that you are talking about is inside the NSF the answer is going to be NO.
Java Agents in Lotus Domino are self contained and can't see that part of the NSF. You could package those particular classes into a jar file and then attach the jar to the java agent or just copy the classes directly to the java agent. Either way you will have to maintain two sets of code.
Maybe another option for you. I'll post on Monday sample code how to use Eclipse jobs on Domino triggered from XPages. These jobs can run on behalf of the current user. The Eclipse jobs framework also allows scheduling them.
Both XPages and your Eclipse jobs run in the http process and you can access the jobs from your XPages. In other words jobs can use the same code in the WEB-INF directory.
Teaser: http://www.youtube.com/watch?v=uYgCfp1Bw8Q
Update: Posted the sample here http://www.openntf.org/Internal/home.nsf/blogEntry.xsp?permaLink=NHEF-8SJB2R
Yes, if the WEB-INF/classes is on the classpath when the java agent executes. The other way to do it would be to put the classes in there own jar, and distribute the jar with the webapp and the java agent code.
I export my Domino Designer Java code to Eclipse in order to generate JavaDoc but this is cumbersome.
I have tried on several occasions to do the same thing from inside DDE but the process fails and have not found a solution.
Is there a way to generate JavaDoc for managed beans from DDE?
JavaDoc is available as an ANT task. Domino Designer can run ANT tasks manually or as part of the build process. Only catch: ANT doesn't know the Eclipse Virtual File system. You have 2 options to overcome this:
Use the version control connection - this copies all files into a directory - or use the Import/Export plug-in from OpenNTF. It has an ANT interface.
Let us know how it goes.
How should I package and ship my groovy scripts without assuming groovy to be installed (and on PATH) on client machine? However, JDK/JRE will be available on all client machines.
What I'm currently doing is to groovy-compile & bundle related scripts in a jar with groovy-all-xxx.jar included in the lib (Netbeans does this automatically). But the problem with this approach is - with every independent small script (project), I have to bundle the huge groovy-all jar creating a big binary.
Just wanted to know if there is any better way of doing this.
You might be able to use the extension mechanism for this - that way each client machine would have to download groovy-all-xxx.jar just once.