Presently I work in eclipse plugin development project. Here, there is a need to persist the domain objects. Can hibernate be used for Java persistency in the existing ecore based model classes? If yes, what are the challenges has to be taken into consideration?
Thanks in advance.
http://www.eclipse.org/cdo/
That's probably what are you looking for.
Related
If I wanted to build a website which used Kotlin both on the back-end, and in the browser - how would I set this up? Is there a Maven archetype or a Gradle template that captures best-practices for something like this?
The easiest way is to keep the modules separate, and I guess conceptually you'd probably want to do that also. While IntelliJ IDEA for instance doesn't natively support the ability to output to JS and JVM with Kotlin, in principle with Gradle/Maven you could. Here are instructions on targeting JVM and JavaScript for Gradle http://kotlinlang.org/docs/reference/using-gradle.html
We've an RCP application based on 3.x api we are trying to migrate it to eclipse 4.x.
The problem is some part of the code was using eclipse internal classes present in the workbench.jar . SO i added the workbench.jar JAR from the previous eclipse(HELIOS) to my new eclipse(KEPLER) this resolved the errors .But my application is not able to start.So just wanted to know is it the correct approach
1.Can I have two workbench.jar JARS(3.105 and 3.6) in my application.
2.If no then is there a way to search for the internal classes which I was using previously in the new jars I was mainly using the internal classes related to layout and prespectives(like : org.eclise.ui.internal.layyoutPart ,org.eclipse.internal.ui.perspectives)
3.Is there a way using which I can avoid rewriting the code.
Eclipse 4.x is a very substantial rewrite so there is very little chance that internal classes from 3.x are going to work. Multiple workbench jars is not going to work in any case.
The layout and perspective classes you mention do not exist in Eclipse 4.x, you are going to have to rewrite your code.
See also Eclipse API Rules of Engagement
I am experimenting with Groovy Griffon development and I am wondering what IDE to use.
I am trying to use NetBeans 6.5, and I found this post
https://blogs.oracle.com/geertjan/entry/notes_on_converting_netbeans_grails
essentially it describes forking the NetBeans trunk and hacking the Grails support; I was hoping for something more lightweight.
Are there any simple tools to create eclipse, netbeans or pom.xml's from Griffin Apps?
Or is it best to use a simple text editor?
There is a NetBeans Griffon plugin already available at http://plugins.netbeans.org/PluginPortal/faces/PluginDetailPage.jsp?pluginid=18664
Griffon apps have some rudimentry hooks already for IDE integration.
First, a .classpath and .project file are generated that mark the expected source and test directories for Eclipse. Both IntelliJ and NetBeans have importers for these eclipse files (and they work, I use them regularly).
Second, Griffon 0.1.1 adds more targets to the parallel build.xml so that more of the common scripts can be used as though they were ant tasks (run-app, compile, debug-app, etc.)
Third, there is some better IDE support in the works form some of the IDE vendors. As mentioned in the article you linked because Griffon is grails derived it is fairly easy to re-purpose existing Grails support. IntelliJ has the only specific tracked feature request I am aware of.
IntelliJ Idea has very good Griffon support.
This question usually comes with a next question:
How to debug Griffon?
Just in case someone still requires a helping hand trying to figure out how to debug Griffon in Eclipse/STS I've written a simple step by step guide to get it done:
http://ivo43.blogspot.com/2012/02/debugging-griffon-in-eclipsests.html
Hope it helps someone someday, :D
PD: I've tried Netbeans and even though it looks great am still with STS, call me a maniac!
My company starts a new project next week. We have planned to develop the application with eclipse rcp. The build process should be fully automated, so we're prepared to set up a continuous integration environment (e.g. Continuum). For the build-automation-part I intended to use maven2, because I want use its dependency management.
I have used maven2 for a small old-style java project, but have never set up maven for using it with eclipse rcp.
What's the best way to do this? Basic concepts? Common traps? Are any tutorials or book's around there? The tutorials and informations I found, seemed outdated or incomplete.
PS: The main project will be divided into sub-project's (plug-in's). But I think this is typical for eclipse rcp projects.
You should take a look at Tycho:
the-future-of-maven-osgi-join-the-tycho-users-mailing-list
the-next-generation-of-build-tools-for-eclipse-plugins-and-rcp-applications
Like most Maven questions, this is solved by a link to a plug-in:
"pde-maven-plugin"
Other advice:
use the assembly plug-in to build
the update site
consider using hudson rather than
Continuum
I've been battling maven2/Eclipse RCP integration for some time. The key is not so much getting your setup right: You can get it to work - eventually - by reverse-engineering Eclipse's build process in maven.
In my experience, the hard part is keeping everything up to date. Every time Eclipse revs their libs, you'll find yourself re-writing a bunch of pom files for that newest RCP widget or SWT lib. Naturally, CI helps with this somewhat. The problem is that Eclipse and maven are very particular about the way they do the business of building, and their approaches are quite different. To make matters worse, PDE dev (and Eclipse dev, more generally) is powered by a lot of wizard code, which is sometimes quite opaque as to what's happening behind the scenes.
The question you really need to ask yourself is if it's worth the effort. In my particular case, I believe it has been. (CI is too good to live without.) But the trade-off is that you may find yourself being the "build guy", which can take valuable time away from actual development, which is probably what you enjoy most.
I've got recently the same problem : build eclipse RCP application through continuous integration.
I haven't applied them yet but I've found some interesting articles :
Here's the documentation for Tycho
Building Eclipse Plugins with Maven 2 on eclipse.org
Build Eclipse RCP products using Maven 2 - how hard can it be? from Immo Hüneke's blog
Here's an article about PDE build automation
Here's a shell script to automate JUnit test launch
We have a Java codebase that is currently one Web-based Netbeans project. As our organization and codebase grows it seems obvious that we should partition the various independent pieces of our system into individual jars. So one Jar library for the data access layer, one for a general lib, one for a specialized knowledge access, etc. Then we'd have a separate project for the web application, and could have one for a command line tools app, another web app eventually, etc.
What is the recommended practice for doing and managing this? Is it Maven? Can it all be effectively done with just Netbeans alone by simply creating individual projects and setting the dependecies of one project on the jar files of the others?
I'd agree with SteveG above on using Maven2 to help you modularise your code base, but I'd use Nexus as the local repository for Maven instead of Archiva. The guys at Sonatype also have an excellent (free html/pdf) book on how to use Maven, Nexus, and integrate it into IDEs.
Be careful on how you decide to partition up your projects, though. There's no sense in over-complicating your dependencies just for the sake of it.
I would definitely say check Maven(2) out. It is very good for doing this sort of thing. You can define individual models and version then very easily. Netbeans also does a decent job of integrating with.
Also I suggest you set up Archiva which will let you be dependent upon binaries of other artifacts that your company generates internally. This also acts as a proxy and will keep a local copy of any external dependencies your projects might have so its very quick to get the new versions internally.
I would create ant scripts to build the pieces and for deployment. Then you are not depending on your IDE for build/deployment.
It sounds like your code is getting to the point where you're graduating from the WAR approach and have entered into the EAR level.
An EAR is just another archive that contains all the other JARs and WARs that get combined to create an application. There are four types of modules that can reside inside it, Web, EJB, Connectors and Utilities. Most people only use Web and Utilities so they go with using the WEB-INF/lib approach.
But if you're starting to get a lot of interdependencies what you do create an EAR project and make your web project a child of it. Each Utility JAR which is just straight Java code used by other modules also becomes a child of the EAR. Finally in each of your projects there should be a META-INF/manifest.mf file that just has the name of the JARs that JAR/WAR depends on.
I'm an eclipse guy and most of this gets taken care of for you in eclipse, but I'm sure netbeans has very similar functionality.
Now the only problem is that you have to use a full Java EE server to deploy an EAR so I don't think you can use Tomcat if that's what you're currently using.