GWT How to Modify default project sample code? - java

When we create a new GWT project using the Eclipse plugin, it gives an option to generate sample source code for the project as shown below:
Selecting the above option, generates sample code structure that looks something like this:
MyTestProject
src/
com/
mytestproject/
MyTestProject.gwt.xml
client/
GreetingService.java
GreetingServiceAsync.java
MyTestProject.java
server/
GreetingServiceImpl.java war/
MyTestProject.css
MyTestProject.html
WEB-INF/
web.xml
classes/
lib/
...GWT JARs...
I wanted to know if there is a way to modify/customize this default code to automatically generate a few more classes to jump start my projects. Any suggestions to get me started in the right direction will be appreciated. For example how do I find the source from where this code is getting generated or more popular approach to create such templates for kick-starting a new project.

You can create your own sample/template project with as many classes as you need, add it to a git/mercurial repository, and import from this repository every time you start a new project.

Related

Use /src/resources as source directory for a new package

I would like to create a new package in Inteliji IDEA (Community Edition) where the source directory is /src/main/resources. I am trying to create a simple forge mod, and need to create several packages in resources for handling textures and other assets. My file structure looks like this:
Main
>Java
>com.mycompany.project
>Package1
>Package2
>Main.java
Resources
>mcmod.info
>pack.mcmeta
Is there any way to create a package in /src/main/resources? I have seen examples of this being done in Eclipse, but I would prefer to not have to use two IDEs.
Please refer to the documentation.
I believe you can do it by right clicking on Resources folder, then New -> Directory and then specify the package com.mycompany.project. Intellij will create the hierarchical package structure.

Factual API and coldfusion

I took the java implementation of the Factual API (reference http://developer.factual.com/) and made a JAR file for factual. I did this by opening a new project in eclipse with the factual java files and then exporting to a new jar file.
I put that jar file in my coldfusion installation's /WEB-INF/lib/ folder.
After restarting Coldfusion, I tried to create a new cfobject like so
<cfscript>
// Initialize the Java class.
factualClass=CreateObject("java", "src.main.java.com.factual.driver.Factual");
</cfscript>
I get an error indicating that it cannot find the Factual class.
Can anybody give me some guidance?
(Summary from comments)
It sounds like you may be exporting the source files ie *.java rather than the compiled class files, ie *.class. In the Jar Export wizard, be sure to select the "Export generated class files and resources" option. (To automatically compile the project sources before expi, enable the setting: JAR packaging > Build projects if not build automatically option). If you prefer you can also find pre-compiled jars in the MVN repository.
put that jar file in my coldfusion installation's /WEB-INF/lib/
folder.
CF10+ also supports dynamic class loading via a new application level setting THIS.javaSettings.
// Initialize the Java class.
factualClass=CreateObject("java", "src.main.java.com.factual.driver.Factual");
Just as a point of interest, src/main/java/ is not actually part of the libary class name. It is a standard directory structure used in Maven projects. It is probably included when exporting the sources, but not the compiled classes.
You can always verify the correct path and class name either by examining the API ie javadocs or by viewing one the source files. Package declarations are always at the top of the source file, such as on line 1 of src/main/java/com/factual/driver/Factual.java:
package com.factual.driver; // ie "com.factual.driver"
.. and the class declaration on line 39.
public class Factual { // ie "Factual"
Combined that gives you the exact (case-sensitive) path to use with createObject:
factualClass=CreateObject("java", "com.factual.driver.Factual");

The class folder is not associated to any output library entry

My Eclipse plugin project which holds libraries used by other OSGi plugins gives me the following warning:
The class folder 'lib/' is not associated to any output library entry.
What does it mean? Can I safely ignore it?
The whole feature consisting from 20 plugins works well, but I do not like to have any warnings in my code.
My build.properties file is:
source.. = src/
output.. = bin/
bin.includes = META-INF/,\
bin/,\
lib/,\
.
The search on google gave me this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=297483, but I'm still not sure how to fix this warning.
I found this hint to be helpfull (first google hit, as of 03-SEP-2013)
http://dev.eclipse.org/mhonarc/lists/pde-dev/msg01822.html
I removed META-INF from my bundle build path, cleaned (rebuilt) the project and the warning disappeared.
About the build.properties:
META-INF/ should be included in the bin.includes because actually this folder includes all the information associated to the classpath and runtime information. If not, another warning appears.
Icons must be added as well in the bin.includes.
Actually, we should try to avoid the addition of icons in the runtime information:
Statically declared plug-in icons are not meant to be in the runtime JAR >because Eclipse wants to load plug-ins lazily. In other words, during >loading of the platform, the platform loader reads only the plugin.xml >file and will use the icons that are declared there.
Taken from: https://wiki.eclipse.org/FAQ_Can_I_add_icons_declared_by_my_plugin.xml_in_the_runtime_JAR%3F
Example of one of my plugins:
Figure 1. Adding information in the bin.includes property
The reason is simple. Think about we want to deploy our plugin somewhere else. Then, we need to maintain a track about all the information that needs our plugin to be executed.
About the MANIFEST.MF:
There is another trick to organize the information that appears in the MANIFEST.MF besides the information that appears in the build.properties:
PDE provides an Organize Manifests wizard to help ensure that the >information in your Manifest is up to date. The wizard is available >through the Plug-in Tools menu after right clicking on a plug-in project's MANIFEST.MF or plugin.xml files.
Taken from: http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fguide%2Ftools%2Fpde_actions%2Forganize_manifests.htm
Example of one of my plugins:
Figure 2. Organizing MANIFEST.MF
I think your issue is that in your MANIFEST.MF the section Bundle-ClassPath does not include a listing of the libraries. This means OSGi will not know if these classes are meant to be on the internal classpath. You will have to provide that information.
If you export everything in lib, every single one has to be listed in the MANIFEST.MF and the wildcard lib/ is fine for the PDE builder.
If you only want some in lib/ then you need to list those only, and the builder will either need an explicit list, or an exclude clause for the ones that you do not want.
If you are just using the libraries internally, but do not want to export them, then the settings for the exported packages are used.
I am unsure what to do in the case where you are packing up a jar file but actually do not want it on the classpath. I am guessing that a source.exclude with the name of the library might help. This is a really unusual corner case.
Bundle-ClassPath: lib/amf-aml_2.12-4.1.19.jar,
lib/amf-core_2.12-4.1.20.jar,
lib/amf-validation_2.12-4.0.3.jar,
lib/amf-webapi_2.12-4.0.3.jar,
lib/antlr4-runtime-4.5.3.jar,
lib/collection-0.7.jar,
lib/commons-beanutils-1.9.3.jar,
lib/commons-cli-1.4.jar,
lib/commons-codec-1.11.jar,
lib/commons-collections-3.2.2.jar,
lib/commons-compress-1.19.jar,
lib/commons-csv-1.5.jar,
lib/commons-digester-1.8.1.jar,
lib/commons-io-2.6.jar,
lib/commons-lang3-3.4.jar,
lib/commons-logging-1.2.jar,
lib/commons-validator-1.6.jar,
lib/handy-uri-templates-2.1.6.jar,
lib/httpclient-4.5.5.jar,
lib/httpclient-cache-4.5.5.jar,
lib/httpcore-4.4.9.jar,
lib/jackson-annotations-2.9.0.jar,
lib/jackson-core-2.9.8.jar,
lib/jackson-databind-2.9.8.jar,
lib/jcl-over-slf4j-1.7.26.jar,
lib/jena-arq-3.11.0.jar,
lib/jena-base-3.11.0.jar,
lib/jena-core-3.11.0.jar,
lib/jena-iri-3.11.0.jar,
lib/jena-shaded-guava-3.11.0.jar,
lib/joda-time-2.9.4.jar,
lib/json-20180130.jar,
lib/json4s-ast_2.12-3.5.4.jar,
lib/json4s-core_2.12-3.5.4.jar,
lib/json4s-native_2.12-3.5.4.jar,
lib/json4s-scalap_2.12-3.5.4.jar,
lib/jsonld-java-0.12.3.jar,
lib/libthrift-0.12.0.jar,
lib/org.everit.json.schema-1.9.2.jar,
lib/paranamer-2.8.jar,
lib/re2j-1.1.jar,
lib/scala-common_2.12-0.5.64.jar,
lib/scalactic_2.12-3.0.5.jar,
lib/scala-java8-compat_2.12-0.8.0.jar,
lib/scalajs-stubs_2.12-0.6.29.jar,
lib/scala-library-2.12.6.jar,
lib/scala-reflect-2.12.8.jar,
lib/scalatest_2.12-3.0.5.jar,
lib/scala-xml_2.12-1.0.6.jar,
lib/scopt_2.12-3.7.0.jar,
lib/shacl-1.3.0.jar,
lib/slf4j-api-1.7.26.jar,
lib/slf4j-simple-1.7.12.jar,
lib/syaml_2.12-0.7.270.jar,
lib/webapi-parser-0.5.0.jar,
lib/webapi-parser-0.5.0-javadoc.jar,
lib/webapi-parser-0.5.0-sources.jar,
.

How to generate package structure from standalone *.java source files?

I've been searching for answer for my problem but I can't find some relevant information, so I'm asking. I've directory which contains thousands of Java classes with source code (*.java files). Each of those files contains information to what package the file belongs, its classnames + code itself of course. I need to find some function of the Eclipse IDE (or maybe of another IDE) which is able to reconstruct packages under the 'src' directory based on the information in the class files and bring to me a good Java project structure so the restored packages and its classes can be easily imported into a new Java project then. Creating the structure of packages manually would take me (maybe) lot of days...
For clarification:
I have:
directory which contains: 1.java, 2.java, 3. java, n.java...
I need:
directory which will contain:
[src] -> [package_1] -> [1.java, 2.java, etc...]
...
[src] -> [package_m] -> [3.java, n.java]
I think this must be possible somehow as the each class file contains information to which package it belongs actually.
Just if you find no better solution: At least you can import all sources into a project in Eclipse and have Eclipse move each file to the right package by means of using the quick fix for each problem. You still need to press 3 keys per wrong package declaration, but it saves you from fiddling with files and folders.

NoClassDefFoundError exception while using external library in EMF plugin project

I'm working on a EMF project where I've created a ecore model from a mdl file. I created the corresponding gencore file and generated the code from the gencore file. While EMF has a own serialization mechanism based on XMI I want to support my project with a own serializiation mechanism.
So far, I've done the necessary steps and if I use the debugger the corresponding methods are called. In order to read and write a file representation of my model I want to use an external library. I've done the following steps
Created a directory lib/ in my plugin project where I've put the external library
Added the library to the build path of the project
Added the directory to the bundle-classpath (Manifest.mf)
Added the directory to the bin.includes of the build.properties
If I try to run my code I get a NoClassDefFoundError exception and I don't know why. I've created a run configuration where I'm starting the project as a eclipse application. So somebody has an idea what I'm missing?
Thanks in advance!
Michael
Edit: Below my Manifest.mf file
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: de.hs_rm.cs.vs.dsm.OWL
Bundle-SymbolicName: de.hs_rm.cs.vs.dsm.owl;singleton:=true
Bundle-Version: 1.0.0
Bundle-ClassPath: lib/,
.
Bundle-Localization: plugin
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Export-Package: owl,
owl.impl,
owl.util,
rdfs,
rdfs.impl,
rdfs.util
Require-Bundle: org.eclipse.core.runtime,
org.eclipse.emf.ecore;visibility:=reexport
Bundle-ActivationPolicy: lazy
and also my build.properties
bin.includes = .,\
model/,\
META-INF/,\
plugin.xml,\
plugin.properties,\
lib/
jars.compile.order = lib/,\
.
source.. = src/
output.. = bin/
source.lib/ = lib/
jars.extra.classpath = lib/owlapi-bin.jar
it's not really a hundred percent solution since I'm not aware what exactly the problem was at all. I've found a link where somebody had the exactly same problem (added a jar as library, NoClassDefFoundError exception during execution). So far, the necessary steps are:
Import JARs using the "Import -> File System"
Add the JAR-file(s) to the classpath section of the Manifest/plugin.xml runtime tab
Press "New..." to add "." library back to the classpath
Check that the binary build exports the new JAR-file(s) on the Build tab
Press save
Select the coressponding project in the project explorer view, right click and select "PDE Tools -> Update classpath". This will add the newly added JAR-file(s) to the project's classpath.
I've had some trouble with the last step since I've added the library by myself to the build path of the project. Every time I did this eclipse removed the library from the build path while executing the "Update classpath command". I've repeated step six without adding the library to the build path by myself and it's now working.
It seems a bit odd to me, but it's now working. Anyway I would like to thank you for your help!
Regards,
Michael
If you are writing Eclipse plugins and not plain old Java project you must add your library in the classpath field of the Runtime tab of the Manifest.mf editor.
Do you get the NoClassDefFoundError when trying to access the lib or when trying to access the Ecore model? If it is the latter case, check, whether your emf package has been registered in the plugin.xml file. Look for something like the following part:
<extension point="org.eclipse.emf.ecore.generated_package">
<package
uri="«package URI here»"
class="«package class name here»"
genModel="«genmodel location here»"/>
</extension>
This part can be missing, if the plugin.xml was generated before the genmodel was used for generation, as neither the manifest, nor the plugin.xml gets updated during the code generation process.
On the other hand, if the library accessing throws the exception, then I would try to remove and re-add the dependency, or clean build a project, but these seem unlikely to solve the exception.

Categories

Resources