We have a J2EE application that we deploy to eg. tomcat. We use MagicDraw to model and generate our modelcode. We are currently looking at alternatives to MagicDraw.
I have previously used EMF:
http://www.eclipse.org/modeling/emf/
but that was inside an RCP application (handling dependencies through P2, maven/tycho).
Just a quick glance at the mvnrepository does not give too many results (of course we could upload necessary dependencies manually to our own )
http://mvnrepository.com/search.html?query=emf
How well does EMF work in a non RCP/OSGi application and are there any examples out there to get started?
A few resources I found:
http://www.fosslc.org/drupal/content/emf-large-scale-modeling-outside-eclipse
http://www.eclipsezone.com/eclipse/forums/t57389.html
It's not entirely clear if you are asking for a way to define models outside of an RCP app or if you simply want to work with the generated models.
It's relatively easy to work with emf from a regular Java or Java EE application. If you look for the keyword 'standalone' in the EMF FAQ you will find some useful information.
Related
I have built a Eclipse RCP Application and packaged with Maven/Tycho and everything works fine. Now, I want to protect my code and want to obfuscate it.
Here are the list of questions :-
Which free tool to use for Obfuscating RCP application?? I tried
Proguard, but stuck with the configuration file and not able to run
Obfuscation. Unfortunately, I dont have sample Eclipse RCP Proguard
Config file.
When should the obfuscation be done?? After the
complete Maven Install of application or when the application is
packaging.
I have tried all possible Google solutions but in vein. Appreciate if any one could be of help.
Regards,
SDS.
Which free tool to use for Obfuscating RCP application
There are some existing plugins you can search in marketplace which help in Obfuscating for example:
https://marketplace.eclipse.org/content/stringer-java-obfuscator
https://marketplace.eclipse.org/content/java-antidecompiler
When should the obfuscation be done??
I have used Obfuscating my RCP application when I do not want to show my package name, method name while extracting code, the objective behind was that we have write down a very specific tool which had some genius and patent code and we do not want to make it free. Simply, in case when you do not want to show your logic.
Approach:
We did in a way that all package names and method names will appear like "OOOOOMMEEOOOOOOOOO" or "EEEEEXXXXXOOOOXX" while extracting or decompiling. you can also write your own logic to replicate specifically what you need and what you target.
It would be good which API or part of code or jar you want to Obfuscating, in my case, RCP application was combination of four applications and we did Obfuscating for our patent code jar only.
You can also refer this:
https://rcpquickstart.wordpress.com/2007/06/22/obfuscating-an-rcp-application/
I have been working with Eclipse RCP for over a week now, and I've now been given an Eclipse plugin written in 3.x, which I need to migrate to 4.x. I'm using a book called Eclipse 4 RCP by Lars Vogel which has a small section on this, but I can't for the life of me figure out what I'm to do.
I'm trying to do this throught the use of the compatiblity layer. It mentions to add a couple of features for this (org.eclipse.rcp, org.eclipse.emf.ecore, org.eclipse.emf.common) and your ready to go, but I don't exactly know what I'm to do here. Like do I add these to the existing product file of the 3.x plugin I've been given, or do I create a separate e4 project and point to that. Many of the tutorials I read are a bit vague with the details and its a shame there's no proper step by step guide for beginners with this. Any help would be great.
Probably, you should be creating a separate e4 plug-in project for this. And where you have to configure your extensions/extension points in e4 ways.
Basically, like creating a new project.
If you want to migrate your Eclipse 3.x RCP application to the Eclipse 4 programming model, you can't directly reuse existing plugin.xml based user interface components, e.g. Views or Editors based on the definition in plugin.xml .
Components based on the plugin.xml file must be adjusted to avoid inheritance of Eclipse classes and to use the programming model based on #Inject . They also must be contributed to the application model.
Components which are not directly based on the plugin.xml file must be adjusted if they use Eclipse 3.x singletons, as for example Platform or PlatformUI , to access Eclipse API
you may want to take a look at this page: https://www.eclipse.org/community/eclipse_newsletter/2013/february/article3.php
I got a little problem. I want to use hibernate in an eclipse rcp. (i'm new to osgi and eclipse rcp). So I added the jar into the plugin-project folder and the build path and the bundle build path, but when I try to use hibernate from my bundle, it crashes with a ClassNotFoundException.
What is the proper way to do this?
Pls look at eclipse buddy policy. This might help you if you are facing class not getting loaded because of osgi classloading.
Hibernate, and many other classic Java programs (ab)use dynamic class loading to to connect the different parts. They classes they use are read from a file and then loaded with Class.forName. This is fundamentally not-modular since these classes are by definition implementation classes, which should be hidden.
Since OSGi is a modularity framework it puts fences around a module (a bundle) and refuses to load anything that is not properly exported and imported. So if Hibernate does its Class.forName it will run right into this fence, as it should be to get the advantages of modularity.
Eclipse Buddy policy is like a huge hole in this fence, moving things back tot he bad old classpath: linear search. With a buddy policy, Eclipse will just start searching if there is a class somewhere that has that name. Since this ignores versions, you can no longer rely on proper version handling. The good news is that it works most of the time. The bad news is that you loose privacy and when it does not work you get weird errors.
With Hibernate, only solution is to not use the text file setup but use the API and give Hibernate the actual classes. In those cases Hibernate will use the class loader of those classes and that works. In OSGi, as long as you follow the Java language rules there are no problems.
To handle the kind of problems that class loading hacks address OSGi uses services.
I am a newbie to AspectJ and to learn it I am trying to search for some open-source simple applications that use AspectJ for the web but I am unable to retrieve any. I am trying to build a filter through this technology but I am not able to find any working examples that are suited in particular to Eclipse/Tomcat.
You can get (many variations) of a simple e-commerce application built using Spring+AspectJ from http://manning.com/laddad2 (click on "Source Code" link).
Not sure they're specifically targeted at Tomcat, but the examples at
Eclipse AspectJ Sample code ought to give you a start.
I work on a fairly simple but large two-tier application that consists approximately 40 Eclipse RCP plugins. We have a new use case that is taking us to the web for a very small portion of this functionality. I'd like to prototype this using Lift. Clearly, I'm facing a few challenges.
Lift + OSGi. Can Lift get at OSGi bundles? Can it be packaged as an OSGi bundle itself and integrated into a web container?
Build System. We use the archaic Eclipse PDE build (read: Eclipse has no build system) with Cruise Control. Lift uses Maven.
Development Environment. This one I'm not sure anyone can help me with. I've tried to use the Scala plugin with Eclipse and it's still not ready. There are just too many impediments to make it useful. Saying that, I don't see this as a major issue because I can keep all the Lift code in one module, only referencing the Java code a very specific areas.
I'm wondering if anyone has tried anything similar to this and has any advice. Note that I won't be using any of the ORM stuff in Lift because all persistence is managed in the existing plugins behind an API. So, am I barking up the wrong tree? Is there something else I need to be aware of?
I could revert to simply using these instructions but I'd really like to take Lift for a spin because Java is... well... it's Java. :-(
There's thread in google groups about using lift as an OSGi bundle.
For the build system as far as I remember PDE sit's on top of ant, so you can use maven for building lift related stuff first and then call PDE's build.xml