I'm currently using Eclipse Indigo and I'd like to have my meta-model classes to be automatically generated in a sub-package instead of having them in the same package of my entities.
I've followed the instructions in the JPA User Guide for Canonical Model Generator on Eclipse Galileo, but it's not working at all with Indigo. :(
Does anybody use the static meta-model classes in a sub-package? Is there any way to configure it on Eclipse Indigo?
Maybe you should not change package
I would suggest against it, because having those in sub package (or any other) violates current JPA 2 specification:
• For each managed class X in package p, a metamodel class X_ in
package p is created.[67]
...
[67] We expect that the option of
different packages will be provided in a future release of this
specification.
...
Implementations of this specification are not
required to support the use of non-canonical metamodel classes.
Applications that use non-canonical metamodel classes will not be
portable.
Other way to organize is common JUnit practice: same package in different source directory.
But if you have to, this is how it is done
Following works at least with Eclipse version: Indigo Service Release 1 20110916-0149 and EclipseLink: eclipselink-2.3.0.v20110604-r9504. Names of the JARs can slightly vary from version to another.
If enabled, disable generating to the same package where entities are:
Go to Project Properties - JPA and check that value of Source Folder
is <None>
Adjusting generating to the other package:
Properties - Annotation Processing
[x] Enable project specific settings
[x] Enable annotation processing
[x] Enable processing in editor
Generated source directory: src (or wherever sources live)
New processor option:
key=eclipselink.canonicalmodel.subpackage
value=sub | (desired package name)
Go one level deeper to the Annotation Processing | Factory Path and select Add External JARs and add following jars:
eclipselink/jlib/jpajavax.persistence_2.0.3.v201010191057.jar
eclipselink/jlib/jpaeclipselink-jpa-modelgen_2.3.0.v20110604-r9504.jar
eclipselink/jlib/eclipselink.jar
Let Eclipse rebuild project.
Related
I am new in Acceleo. I use eclipse Mars. I want to getting start and learn with this link. when I want to create a new project and click add in the field of Metamodel URIs I didn't find UML Metamodel. what can I do?
The UML metamodel is only accessible by Acceleo if it is registered in the global EMF ERegistry. It means that it must be either loaded as an EMF plugin in your Eclipse environment or manually added to the global registry of your running Eclipse instance.
For UML, it is quite simple, you need to install the UML2 plugin. It provides the UML metamodel java code and .ecore as well as many tools around UML.
Also, if you want more details about Acceleo syntax, you can use these links:
Language Reference
http://help.eclipse.org/mars/topic/org.eclipse.acceleo.doc/pages/reference/language.html
Operations
https://wiki.eclipse.org/Acceleo/OCL_Operations_Reference
https://wiki.eclipse.org/Acceleo/Acceleo_Operations_Reference
Text production rules
https://wiki.eclipse.org/Acceleo/Text_Production_Rules
And a small tutorial I wrote (only part 1 at the moment):
http://blog.genmymodel.com/build-your-own-php-generator-from-uml-using-acceleo-part-1.html
For curiosity's sake, I'm developing a small experimental platform/environment-agnostic MVP framework-like thing that's supposed to be as much platform independent as possible. Currently it consists of dumb models, platform-independent presenters (defined in a single abstract main application module), and platform-dependent views (currently there are experiments with Swing, Android and terminal-friendly environment). However, I'm in trouble trying to make GWT another available platform because it requires modules inheritance via .gwt.xml files. Is there a good way of inheriting non-GWT modules somehow, and keep that abstract platform-independent module .gwt.xml-free, but still available for the GWT? If it's worthy: all modules are built with Maven, and the project structure is as follows:
[root]
[app] --- platform-independent application
pom.xml -- references fx
[app-gwt] --- GWT-views, entry point, etc
pom.xml --- references app, fx, fx-gwt
.... App.gwt.xml --- references Fx.gwt.xml
[fx] --- the core itself
pom.xml --- references nothing
[fx-gwt] --- GWT-specific adapters for the fx module
pom.xml --- references fx
.... Fx.gwt.xml --- references GWT core
pom.xml
Simply speaking, I don't want either app or fx to be GWT-related in any case. Also, I thought that modifying <source path="..."> (referencing to another module source code) can help, but I can't make it work (if it's possible). Here are some similar questions, not sure they can help:
inherit a non gwt module
Inherit external java source in GWT project (similar concept)
Thanks.
(For simplicity, let's assume that app and fx have no external dependencies)
I've investigated the problem deeper, and the general solution is:
Supply the dependencies source code to the dependency repository using the maven-source-plugin plugin. This step is a must because GWT compiles the dependency source code rather than using JAR.
Define a regular GWT module with inherit elements to make dependencies.
Compile the target application using gwt-maven-plugin with the compileSourcesArtifacts configuration option set to match the dependencies.
See more at http://mojo.codehaus.org/gwt-maven-plugin/user-guide/library.html
In Dependencies tab, I have a choice between plug-ins and packages.
What's the difference between them? For org.eclipse.compare, I have it in imported package and also in plug-ins.
I find the jar file in plugins directory, but I don't know where the package file of org.eclipse.compare is located.
In the export menu, it seems like that there seems to be only exporting to jar, not exporting a plugin or packages. How can I export packages?
ADDED
Based on this post - How to import a package from Eclipse? and shiplu's answer. This is what I came to understand. Please correct me if I'm wrong.
In eclipse, when I use come external class, I can use Quick-Assistant or Organize imports (Ctrl-Shift-O) to resolve the reference. Eclipse adds the package that contains the class in Imported Packages for the project that I'm working on. A package can contain multiple classes (types). Eclipse understands what plugin contains the package, and resolve the reference issues.
A plug-in (jar file) can contain multiple packages. By specifying a required plug-ins in the dependencies tab, we can reference all the packages (and classes in the packages) for all the java projects in the eclipse IDE.
And from my experience, I had to add all the dependencies in order to make headless RCP standalone (http://prosseek.blogspot.com/2012/12/headless-rcp-standalone.html).
An Eclipse plug-in is basically an OSGi bundle with additional plugin.xml file which Eclipse IDE understands and interprets.
So the answer to your question lies in the OSGi specification and the OSGi programming model, since, very simply put, Eclipse is an Application running on implementation of OSGi called Equinox.
OSGi is all about having modular applications and so it defines several levels of modularity.
One such level is a bundle-level (module-level) modularity and more fine grained level is the package level modularity.
So you can have your OSGi application (a set of bundles; eclipse is just that) which consists of db-bundle (which provides data store services), app-domain-bundle (which provides your application domain services) and remote-bundle (which exposes to the web your application via REST for example).
And then you say remote-bundle depends on domain-bundle which depends on db-bundle.
Which is all good, but cripples the inherent modularity OSGi provides, because you are basically restricting your application to specific implementations of db-bundle and remote-bundle i.e. to specific implementations of the services they provide.
Instead, you can establish the above dependencies not between bundles but between packages i.e. establish a service-level dependencies.
Then you say domain-bundle requires dbstore.service package to run, it doesn't care which bundle provides it it just needs an instance of this service to be able to work. So you can have multiple bundles providing implementations of the dbstore.service, and the domain-bundle can pick and choose at runtime what service to use.
It is really hard to explain OSGi concepts in just a several sentences, I'd really suggest you dig around the web on this and maybe even have a look at the OSGi specification.
Another way to explain it is to say that bundle/plug-in is a jar file with specific structure and metadata descriptors (MANIFEST.MF and plugin.xml), which describe its contents in Java language concepts - which java packages and services this specific jar contains and will expose to the OSGi runtime so that they can be consumed by other bundles. I.e. the bundle is the physical deployable entity while the descriptors are metadata about what actually is being deployed.
EDIT:
Package or Service-level dependencies also have some drawbacks, as Lii points out in the comments below, the main one being that it adds complexity and dynamics to the dependency model. Have a look at her or his comment below - it is worth reading!
You use Imported Packages when you want to use a specific package but do not care which plugin provides it. OSGI will choose one for you.
Eclipse plugins is something like extension to the IDE itself. But imported packages are actually packages that you'll use in your current project.
One is for development IDE another is for the project you are coding.
My entities objects are scattered in multiple jars.
In jar A I have a base class name MyBase which is annotated with #MappedSuperclass.
In jar B there is an entity class which derives from MyBase.
The problem is that because the weaving is done in the context of the jar file (I'm using the maven plugin) the base class (MyBase) isn't instrumented (although it should).
If I move the derived class from jar B to A then the weaving process will handle the base as well.
Since I'm working on a large project it is critical for me to develop in a modular way.
Doesn't EclipseLink support such methodology?
The only way I found to override this limitation is to add a temporary entity class to the jar where the #MappedSuperclass base class is defined and remove it after the weaving procedure.
Sad, but true ;-)
I'm not sure on the maven plugin, but you should be able to use the static weaver on both jars, you will need to call it twice to weave both, and will need both jars on the weavers classpath for both calls.
Alternatively you can specify the jar containing your superclass as inpath - as explained here and here:
Managing multiple projects
Building AspectJ source code requires two distinct phases; compiling
the source in .java and .aj files to generate .class files, and then
applying the aspects to the generated .class files. This second phase,
known as weaving, is the key difference between AspectJ and Java
compilers. The Java compilation process is controlled by the classpath
setting, which makes types available for resolution by the compiler.
The same classpath setting is used by the AspectJ compilation process
and it is configured in exactly the same way in Eclipse. However, this
setting is not sufficient to control both the compilation and weaving
steps in all situations. This is why there are two extra settings
available for AspectJ projects.
First, there is the inpath setting. Anything specified here will be
made available to the weaver and so any aspects that apply will be
woven in. Entries can be added to a project's inpath by right-clicking
on the project, selecting Properties, then going to the AspectJ InPath
section. Entries can be either JAR files or directories (class
folders), such as the bin directory of another project. Anything on
the inpath is sent to the project's output, after potentially being
woven with aspects.
The second additional setting is the aspectpath. Whereas the inpath
controls the list of things that get woven, the aspectpath controls
what is woven into that list. In other words, any aspects specified on
the aspectpath are made available to the weaving process, just as if
they were present in source form in the project. This setting is
controlled from the AspectJ Aspect Path property page and can contain
either JAR files or directories.
An output JAR setting is also present in the AspectJ section of each
project's property page. This setting causes the compiler to output
class files directly to a JAR file, instead of to the project's output
folder.
Drove me crazy just like you - hope this helps. ;)
I have two Eclipse projects: one that depends upon a certain library (android.jar) and one that is more abstract and doesn't contain that dependency.
I am in the process of migrating all classes that have no dependencies on the package, in my case android.*, to the more abstract project. Is there a Eclipse feature that can help automate the move?
Ideally, there would be feature that directly lets you automatically search for and move files that can be relocated to a new project. It would find files that that are:
independent of a specified package (with wildcards)
independent of other files within the same project that are dependent on the same package (in other words, no indirect dependencies on the package)
I submitted an Eclipse enhancement request to support such a refactoring. In the meantime, I found some promising tools to help with the decoupling and dependency analysis.
eDepend is a dependency viewer plugin that includes a
Class/Package dependency diagram that displays elements dependencies,
relationships with libraries/other projects and dependency cycles. It
can also list find classes that caused the dependencies.
STAN structure analysis for Java
nWire
Class Dependency Analyzer
Dependency Finder
Related questions: 1