I am working on a project whose input is XSD.From the input XSD jaxb classes will be generated in a particular package.
There is reflection class which will create class from the ObjectFactory.java (JAXB generated).
Class<?> aClass = Class.forName("pkg.ObjectFactory");
But its throwing class not found exception.
Refreshing the excipse project by right clicking on it resolving the exception.
How to solve this problem automatically?
Though wait for an eclipse-only answer too, maybe you should consider having a nice build infrastructure like maven. If you reached a size where would like to draw the build system in separate parts and pin it on the wall.
I am in favour of many independantly versioned (sub)projects. An explicit structure is best done with a maven build infrastructure, available for all IDEs. Then a project might generate the JAXB source classes, and the main project might depend on that project.
Related
My idea is to write a maven plugin that generates code (just simple json) based on some annotations in my Java code. The annotated classes may be part of a used library or in my own code.
What I want is a plugin that gets a fixed set of class names (by configuration in pom). It walks through these classes, searches it for annotations on properties and generates code based on the gathered information.
Is that possible?
How can I achieve this?
Is there an existing plugin that does something like that?
I've got a project and want to share an API that can be used for building a plugin for my application.
Now I don't want to share the full source code but only class definitions and member declarations without their body.
I've seen dependencies before that without downloading the sources the IDE I'm using already knows the structure. That is what I'm going for.
A jar file already does most of what you want, as it does, if not obfuscated, contain all the class and method names in a format that will be understood by any Java IDE.
The rest can be done by preparing and delivering a javadoc jar.
Our project has started newly and wanted to know some of the best practices followed in industry. We have generated lot of DTOs(getters and setters) code for webservices using JaxB. we keep all the DTO classes along with regular pojos(logic written), its looks like large project due to this auto-generated code, also for code coverage it considers these classes also.
I am keen to know that these classes should be as a jar file in classpath or it should be as classes in project.
Thanks in Advance,
Madhavi
If your project uses Maven (or something similar) I would advise having the code generation and the generated code in a separate module of a multi module project.
This way the generated stuff is out of the way of the hand crafted code. You can also set up your Maven build process to then build this module first and the rest of the code can rely on the resulting artefact, be it a jar or something else.
You could also regenerate the generated code on each new build this way. Although this can be a lengthy process, depending on the service.
Generated files should not be mixed with your written files.
A common approach is to generate them to the target folder, e.g. target/generated-sources or something similiar. Of course, if they are rarely changed, you could also put them in a jar file that you import into your project.
I think its better to keep them in jar. As its auto generated code and no one is supposed to change. Whenever regenerated include new jar.
I'm looking for a possibility to parameterise a multi-module build in a way that I can replace/specify some files (e.g. UML files) that are used during the build in order to produce different output.
The procedure of the build stays the same but I want to be able to produce different output depending on the input UML model.
I have a multi-module project that builds several jars based upon an UML model. The pom structure looks as follows:
+ generation
- mod1
- mod2
- mod3
The root pom (generation) generates java sourcecode (.java) based upon an UML model stored in the directory /uml. Afterwards the modules (mod1...3) compile distinct subsets of this sourcecode and package the output as jar.
I want to reuse this build procedure and apply it to different UML models.
How can I reuse the entire generation, compilation and packaging procedure defined in the multimodule project in other maven projects?
# Generate jars based upon the foo UML model
+ generation-foo
/uml/foo.uml
# Generate jars based upon the bar UML model
+ generation-bar
/uml/bar.uml
Update
I could use profiles in the generation project in order to define the different input uml models and then just activate the relevant one. But I would lose traceability that way.
Perhaps a completely new approach would be a better idea ... any suggestions?
Conceptually, I would say, Maven is designed around the POM file which is a model of the project that is being built. It is not so much a process description that applies a function to an input and results in an output on basis of that.
That being said, there is a lot possible with properties in the POM, which then can be passed along on the command-line: -Dproperty=value. It looks as if you would be able to pass the property to whatever process is generating the source code.
I may express some caution, though. I'm seeing some possible red flags in the overall design that you describe. If modules (regardless of their inheritance relationship) pass along files/folders, that should preferably go through installation.
So, if you were to do that, you end up with a version of the parent project in your local repository of which you don't really know what it is. Which parameters were used? And how will a user of that artifact then deal with that?
I'm not saying this won't work, but it may get hairy and not play entirely well within more traditional Maven implementations.
I'm not entirely sure I understand your use cases but you might want to look at:
POM Inheritance : Defining as much as you can in the parent module (different groups of modules can have the same parent)
Maven profiles : you can activate based on all sort of potential conventions like even the project name.
Maven Archetypes : And finally I think based on what your saying this maybe the only solution of a reusable project template
I am using a 3rd party annotation processor for generating meta-data code (.java files) from the annotated classes in my project.
I have successfully configured the processor through Eclipse (Properties -> Java Compiler -> Annotation Processing) and the code generation works fine (code is automatically created and generated). Also, Eclipse successfully auto-completes the generated classes and their fields, without any errors. Let's say that I have a class "some.package.Foo" and that the generated meta-data class is "some.package.Foo_". By the help of auto-completion, I can get the following code in the Eclipse editor, without any errors:
import some.package.Foo_;
...
public class Test {
void test() {
Foo_.someField = null; // try to access a field from the generated class Foo_
}
}
However, as soon as I actually build the project (or just save the file since Build automatically is enabled), I get the error which tells that "some.package.Foo_" cannot be resolved.
It seems like Eclipse is generating and compiling the some.package.Foo_ at the same time, or more likely.
I found two temporary solutions (which are practically hindering the use of the annotation processor in the first place):
Before each build of that generated classes, right click on every generated file go to Properties and uncheck the "Derived" tick. After that, I do the cleanup of the project and the imports are fine - there are no more errors. However, if I do the cleanup one more time, the errors again show up, because the generation of the files causes the "Derived" tick to be checked again (automatically). So this is really annoying and time-consuming.
I also uncheck the "Derived" tick
from all those files, and this time
I uncheck the "Derived" tick from
the source folder and packages which
contain those files. Then I disable
the annotation processor, and then
do the cleanup. There are no more
import errors, even if I do another
cleanup, but there is no benefit of
using the annotation processor,
because if I was to change something
which would update the model, I need
to turn the annotation processor
back on, and repeat this tedious
procedure to turn it off, after it
has generated the new version of
those files.
Is this a bug in Eclipse? If yes, is there a better workaround or quick-fix than the two I have stated above? If not, what should I try to solve the problem?
I also tried rearranging the order of the libraries on the build path and it doesn't help.
I assume that you are generating sources in the last processor round. This is not recommended way and leads exactly to the problem that you had.
Explanation is here: http://code.google.com/p/acris/wiki/CodeGenerationPlatform_Pitfall_Rounds
So the my advise is to generate sources in regular processing rounds and final round should be used just for notification that processing is over or something like that.
Hopefully this helps you.
I have a similar problem, and the only thing I've found is that it's the imports specifically that don't work, but the references in the class itself do work. The workaround I've used is to use the FQCN in all cases where the generated class is needed (except when the generated class is in the same package, since then the import is obviously not needed).
So to use your example, I'd do:
public class Test {
void test() {
some.package.Foo_.someField = null; // try to access a field from the generated class Foo_
}
}
My only guess then is that the eclipse compiler is processing the imports before doing the annotation processing, which imho must be a bug in eclipse.
I know this question is over a year old, so I'd be interested to know if you've found any other way to fix it.
We were experiencing a similar problem and apparently just solved it, so thought of sharing it at SO, in case it helps someone.
We are using:
Eclipse Indigo (Build id: 20120216-1857)
m2e Connector for maven
openJPA for static metamodel class generation
Our problem:
Say, we have a package named com.abc.xyz and an entity class in there named OurEntity. When we build the projects (JPA, EJB, EAR etc. all together with an mvn clean at the beginning) the metamodel classes get generated. And also get appropriately packaged within the PU jar. But when we try to import the generated metamodel class com.abc.xyz.OurEntity_, Eclipse cannot resolve it. OP apparently got past this point:-). Maven build failed, saying it could not resolve that class. Not much help from google except for a few bug reports such as this one: https://bugs.eclipse.org/bugs/show_bug.cgi?id=350378
That bug report said importing the whole package as opposed to the single class helped. So, tried that, but with no benefit. It also said (and so did David Heitzman) that using the fully qualified class name worked for them. That did not work either.
The solution:
Added the PU jar to Eclipse build path for the project that needed to use the metamodel classes. All of a sudden all the red underlines went away (not a surprise). But the fear was there might be two PUs in the same ear. But maven automagically took care of that.
As this rather old question got some attention without pointing to the very probable eclipse bug the OP was specifically asking for, I'd like to complement the above answers with a pointer to the eclipse bug tracker:
Cannot resolve import for generated class IF processing annotations with parameters referencing constants
The workarounds include
doing a wildcard import of the package defining the generated classes (i.e. import some.package.*;)
using the fully qualified name of your generated class, i.e. referring to some.package.Foo in your code and not using an import
switch to a newer Eclipse. This specific eclipse bug is resolved with Eclipse version 4.4 (aka Luna).