I'm working on a project which inspects Eclipse Java projects and getting some information of source files, using Eclipse AST. Right now it's an Eclipse plugin, but we need to make it independent from Eclipse, we are using only AST libraries of Eclipse.
I've tried copying required JAR's and run the project as a normal Java app(not an Eclipse plugin, not dependent to Eclipse) but then I started getting some errors, because when I run the app outside of Eclipse, AST can't get needed information(project data) from Eclipse and returning null for some cases. For example, when I visit a method invocation(MethodInvocationNode class), I need to know which class's method is this, but I can't because of AST errors I explained(MethodInvocationNode.resolveMethodBinding() returns null in this case).
I think I need to get an IProject, in Eclipse plugin I'm getting that from IWorkspace(ResourcesPlugin.getWorkspace()) which I think available in all Eclipse plugins.
Now, I think if I can make an OSGi app of it, maybe I can somehow get that IProject but I have no idea how can I do that. Documentations and tutorials didn't help much. It's also high probability that I'm missing some fundamental points about Eclipse projects and/or OSGi apps :) .
In short, how can I get IProject data within an OSGi app?
First, every Eclipse application is an OSGi-application, so there is no difference in doing things in a pure OSGi environment or Eclipse.
Second the "Workspace" is an Eclipse specific construct, so making your application "independent" from Eclipse makes no sense at all, the contents of a project, especially Java projects are eclipse specific (so you also have to parse the .classpath files with API from Eclipse to know which resources have to be compiled, parse .project files, etc).
The workspace mechanism is part of the bundle org.eclipse.core.resources. You need to include that in your OSGi application. Like already mentioned you can access all things the same way like in an Eclipse environment.
Related
I am converting an application from Flex to Javascript. My workflow within Eclipse for Flex was to use Maven to start my Java web app in Tomcat and then have Eclipse configured to compile edited Actionscript files to a SWF and save it to my exploded WAR directory (that Maven/Cargo uses).
It worked very well for a long time allowing me to edit actionscript source code, flip over the browser, refresh the screen and see the changes.
I am new to Javascript however, and am struggling to get the same workflow up and running. The part I don't understand is how to tell Eclipse that I would like my edited Javascript files to be written out to a particular directory (that contains the exploded WAR). In my WAR project (a WTP dynamic web project) there is something that looks like a Javascript build path called "Javascript resources", but there is no output directory.
I would really like to continue to run Tomcat and Jetty via Maven if at all possible. I realize I can do what I want via WTP (M2E-WTP), but would prefer to use Maven/Cargo.
Denis's suggestion to create custom builder is probably best solution if you want to continue using pure Maven/Cargo approach with Eclipse.
If you are deploying to an exploded war directory, then another similar idea would be to use a File Synchronization plugin. These will automatically copy modified files to configured folders. See:
http://andrei.gmxhome.de/filesync/
https://wiki.onehippo.com/display/CMS7/Use+Filesync+Eclipse+plugin+for+faster+turn+around
-------------
FWIW, I don't think Maven:Tomcat/Cargo plugins are ideal for real-time web development, especially on the frontend side of things. They are useful mainly for controlled deployments or bootstrapping a server without initial setup. My thoughts:
Eclipse WTP used to be great for real-time web development, but I stopped using it a few years back as it just got way too hard to make it work correctly in a Maven environment. Fwiw, my preferred approach these days looks like this:
Do not install or use Eclipse WTP.
Use m2eclipse to integrate Maven with Eclipse.
Use Maven to do clean builds and generate exploded WAR directory in target folder.
Setup independent Tomcat server to load webapp from the exploded target folder.
I suspect the tomcat setup/startup could be integrated into Maven. It's not worth the extra complexity to me though.
Then, I configure JRebel (automatically via Maven) to handle java and web resource file changes. With this setup, I almost never have to redeploy or restart Tomcat. All changes (java, html, js, etc.) are seen immediately.
I think the same setup could be used without JRebel (for non-java files only) by configuring the web source folders as source folders in Eclipse with custom target output path being the corresponding directory in the exploded war directories. If that didn't work, then it would definitely work by using the custom builder or file synchronization solutions mentioned above.
Eclipse introduces the concept of "builder" to build a project. It comes with hardcoded builders such as the java compiler or the war builder of WTP.
But eclipse also enable to setup your own Builder using ant files : on your project, right click the project properties, go to section Builders, click on the new button.
You can use arguments to your ant file and use variables defined in by eclipse to build them
Do not forget to fill the refresh tab if you want eclipse to by notified of the produced files.
Do not forget the fill the Build options tab, section "Specify working set of relevant resources" in order to have your builder called each time a source used by the build file is changed inside eclipse.
Also go to the "targets" tab to specify during which type of build phase your ant file is called and which target is called.
I knwo this solution may not be the best for you since your build process will be described more than once but it may help you achieve your goal.
I feel like a 4-year old who has a slice of bread with pb and a slice with jelly and is asking how to make a sandwich..
I've been given the responsibility of maintaining a javaEE website that was done by our parent company that no loner supports us. I'm relatively new to JavaEE and I'm trying to figure out how to recompile the files that need to be modified from within the root folder of the site.
I downloaded NetBeans to help me with this, but still can't figure it out. My problem is that the java files can't find any of the packages and resources they are dependent on. As far as I know, the resources are there.. although, I do see some packages starting with "com." and "javax.", and I don't see a 'com' or 'javax' folder anywhere.. I believe my problem has something to do with setting the class path in the project properties in NetBeans.. I tried that but either I'm not doing it right, or its not working. This whole Java compilation is so foreign to me, it'd be really great if someone could lead me in the right direction of getting this website compiled.
I posted a pick of the folder hierarchy of the website to help:
I'm trying to compile the RecordAdd.java file here specifically at the moment. Some of the packages it is trying to import come from its parent folder, asp, of the folder it is in, easp. The file is also trying to import com.icesoft.faces.component.*; where '*' consists of several different imports of the parent packages. I don't see a com folder like I mentioned, but I do see icefaces.jar files in the lib folder in WEB-INF folder. I've tried putting these folders in NetBeans Library-Compile category classpath, but that didn't do anything.
I'm not doing something right, that is probably a basic knowledge of compiling java projects, but I'm just not getting it. I really appreciate any help, just please don't be too harsh. Thanks!
Try to find out which IDE the original devs used. I see a nbproject folder which indicated Netbeans (unless that was created by you) so try opening the project in Netbeans as a Java EE project. I'd also try to open it in Eclipse, it has good importing capabilities and can sometimes figure out the classpath on it's own. Download the Java EE version of Eclipse and install the Web Tools Project. You can also try to see if there is a build file that will compile and generate a war file for you (something like build.xml).
It should be simple if the project was created in netbeans. Just go to File -> Open Project. Navigate to where the project is located. You will know if the folder is a project, because netbeans recognizes it and a different icon is displayed instead of a regular folder icon. Once you open your project, you can right click compile the project.
You don't use java compiler yourself to compile java files in a project. Compiling and building are done by tools like ant, maven... It's automated.
Importing existing projects into netbeans is a great way to loose a half a day.
I'm assuming that since there's a nbproject directory, this was built through netbeans, which should give you a leg up.
In the "Open Project" wizard, the top level of your application (not necessarily the sources) should have a friendly globe icon for a web application (.war) or a triangle for EE application (.ear). Open the triangle if there is one. Web applications can be packaged with EE applications through netbeans, so if the Web App you're trying to compile belongs to one, some of the build properties may be associated with it.
Looking at the file nbproject/build-impl.xml should give you hints about where your libraries folder was located. Make sure this path matches in your project properties under the Libraries header. These libraries can be shared among projects and therefore likely out of this projects directory structure and referenced or native to this project alone in which case jars are copied in to your lib folder.
There may be additional reference or server issues that netbeans detects (and gives a paltry error message for) which can be found in the project context menu under "Resolve Reference Issues" or "Resolve Missing Server". In netbeans projects are built against the servers they're run on right in the IDE. Check that you have the servers you want configured under Tools-> Servers, then ensure that server is linked in your project properties under Run.
This may not solve all your problems, but is a good start. Good Luck!
First off I'm not a Java expert by any stretch, nor am I a regular Eclipse user. Due to personal circumstances of a member of our team I have had to step into the breach and fix some bugs in two java applications currently under development.
We have a core application (CORE) and an API which includes a reference to that CORE. What I need to do is debug the API but step into the CORE code. I have all the source code for both projects loaded into the IDE but I can't hit breakpoints in the CORE. I'm assuming it is using the jar version of the CORE included in the API as opposed to the code in the CORE.
I hope that makes sense.
Cheers
Define a breakpoint in the API by clicking on the left side column of the editor. Then, try to step into a function of CORE. Eclipse will complain that it cannot find the sources to debug. However, a button will appear that will let you define where to find these sources: either in a jar file or in an external directory.
If you were to include the sources of CORE along with the classes of CORE, normally eclipse will find it automatically as well.
Cheers
I have all the source code for both projects loaded into the IDE but I can't hit breakpoints in the CORE. I'm assuming it is using the jar version of the CORE included in the API as opposed to the code in the CORE.
Change the build path of the second project so that instead of referring to a packaged JAR of the first project, it refers to the project itself.
In the properties of the second project, go to Java Build Path, remove the JAR from the Libraries tab, and add the first project under the Projects tab.
What you need to do is remote debugging. Here is one (of several) articles covering that topic and showing how to set up a remote debugging session. (near to the end of the text)
Basically you start the application with some extra parameters while on eclipse you have a projects that contains the source code. Then you start a remote debugging session and can set breakpoint, inspect variables, etc. on the remote JVM.
You probably have the CORE java classes which are compiled by Eclipse to byte code and present in the IDE. THat means that the code invoked by the API is most likely NOT the code you think as it is probably present in jar files next to the API.
What you need to to is to attach the sources to the jar files instead in their properties. Either zip them up and attach that zipfile or attach the folder where the "com"/"org" etc package names start.
I'm a C# guy trying to learn Java. I understand the syntax and the basic architecture of the Java platform, and have no problem doing smaller projects myself, but I'd really like to be able to download some open source projects to learn from the work of others. However, I'm running into a stumbling block that I can't seem to find any information on.
When I download an open source .NET project, I can open the .sln file with visual studio and everything just loads. Sure, there's occasionally a missing reference or something, but there's really very little configuration required to get things going. I'm not sensing the same ease of use with Java. I'm using eclipse at the moment, and it feels like for every project I have to create a brand new Eclipse project using "create from existing source", and almost nothing compiles properly without significant reconfiguration. In the case of web projects, it's even worse, because Eclipse doesn't appear to support creating a web project from existing source. I have to create a standard Java project from source, then then apparently modify the project file to include the bindings for the web toolkit stuff to work properly.
Assuming I want to be able to contribute to a project later on, I shouldn't have to be making such drastic changes to the file structure to get my IDE to a workable state. What am I missing?
The best way to go about this, is to first remove the IDE from the equation. In C# there is only one environment, so the presence of the default IDE is assumed. In Java a default IDE does not exist.
In the end Java is all about java source files and supporting jars. If you figure out what those are, your 99% of the way home. Then you can apply you favorite build system for the set. Some project require a runtime environment, like a webserver to handle the JSP files. If you understand what the basic setup is (as specified by the specification) you can quickly setup your IDE to handle that.
If I get a project with java files and supporting jars, I fire up Eclipse, create a new project, point it to the project's base directory and Eclipse will automatically detect what it finds and set up the project accordingly.
But projects often come with a build environment included. The trick is to figure out which one:
if a build.xml file is present, it is using ANT. This is a "make" like tool. You can execute "ant" in the directory where the build file is (if you have ANT installed) and it will try to compile. All IDE's like Eclipse and NetBeans recognize the build.xml file and allow for starting ant from inside the IDE. There is no guarantee the supporting jars will be present.
if a pom.xml file is present, it is using Maven. Maven is also a make like tool, but enforces a much stricter build cycle. Plus (and this probably is its biggest advantage) it automatically downloads supporting jars. If you have Maven installed you will be amazed at what it downloads... just sit tight, it'll work out in the end. IDE's usually require a plugin to support pom.xml, but then you automatically have the whole project setup at once.
if a .project file is present, it usually is a Eclipse project
if a nbproject directory is present, it is a NetBeans project
Getting to know a build environment / IDE is more work that trying to setup a project in the one you know. So I always try to get it running in Eclipse. Usually projects are quite simple to get running once you know your IDE.
Having multiple ways of doing things is not always pleasant, but it's the cost of having an open community. If there is only one IDE it makes things easier, but I like the fact that there are more people trying to figure out what the best way is to get things done.
In some cases you really may have to make drastic changes. A well-designed build system will require no configuration at all on most platforms and perhaps a few changes on exotic platforms. However, there is no single standard build system for Java; some people use Eclipse, some people use Apache Ant, and others use Apache Maven or Apache Maven2. If you were to create a project from scratch, then Maven or Ant is probably the ideal way to go. If you use the NetBeans IDE, projects that you create will automatically contain an Ant build file (so that it can be built on all systems using Ant), but will add additional metadata so that it is recognized by NetBeans IDE. If you create a Maven project, either using Maven directly or using an IDE such as Eclipse or NetBeans, then that same project can be loaded in either NetBeans or Eclipse without any additional configuration changes (although you may need to install a plugin for Eclipse for it to recognize Maven projects; NetBeans recognizes Maven projects out of the box). If you are starting a project from scratch, you may be interested in the Java Project Template. If you are contributing to an existing project, how you view/edit the project depends on the build system chosen; if the project already uses Maven or Ant, loading it with other IDEs should be fairly simple, while if the project uses a specific IDE's quirks or uses some more exotic build system, it may be harder.
I've finally managed to create a Netbeans project out of an old standalone (not Web-) Java application which consisted only out of single .java sources. Now I have basically two questions regarding Netbeans Subversion interaction and application deployment:
Do you check in all the Netbeans project files into the repository, normally?
If I build the project using Netbeans (or ant) I get a .jar file and some additional jar libraries. In order for the app to run properly on the server, some additional config files and directories (log/ for example) are needed. The application itself is a J2SE application (no frameworks) which runs from the command line on a Linux platform. How would you deploy and install such an application? It would also be nice if I could see what version of app is currently installed (maybe by appending the version number to the installed app path).
Thanks for any tips.
No, not usually. Anything specific to NetBeans (or Eclipse, IntteliJ, etc), I don't check in; try to make it build from the command line with your ant script and produce exactly what you want. The build.xml is something that can be used for other IDEs, or in use with Anthill or CruiseControl for automated builds/continuous integration, so that should be checked in. Check in what is needed to produce/create your artifacts.
You don't specify what type of server, or what exact type of application. Some apps are deployed via JNLP/WebStart to be downloaded by multiple users, and have different rules than something deployed standalone for one user on a server to run with no GUI as a monitoring application. I cannot help you more with that unless you can give some more details about your application, the server environment, etc.
Regarding the config files, how do you access those? Are they static and never going to change (something you can load using a ResourceBundle)? ? You can add them to the jar file to look them up in the ResourceBundle, but it all depends on what you are doing there. If they have to be outside the jar file for modification without recompiling, have them copied with an installer script.
As for directories, must they already exist? Or does the application check for their existence, and create them if necessary? If the app can create them if absent, you have no need to create them. If they need to be there, you could make it part of the install script to create those folders before the jar files are installed.
Version number could be as simple as adding an about box somewhere in the app, and looking up the version string in a config/properties file. It has to be maintained, but at least you would be able to access something that would let you know you have deployed build 9876.5.4.321 (or whatever version numbering scheme you use).
Ideally, you should not tie down your application sources and config to a particular IDE.
Questionwise,
I suggest you do not. Keep you repository structure independent of the IDE
You might have to change your application so that it's structure is very generic and can be edited in any IDE.
Is this a web app? A standalone Java app? If you clarify these, it would be easier to answer your query.
We don't check in the /build or the /dist directories.
We tend to use this structure for our Netbeans projects in SVN:
/project1/
/trunk
/tags/
/1.0
/1.1
/binaries/
/1.0
/1.1
When a change is need we check out the netbeans project from trunk/ and make changes to it and check it back in. Once a release of the project is needed we do an SVN copy of the netbeans project files to the next tag version. We also take a copy of the deployable (JAR or WAR) and place it in the version directory under binaries along with any dependencies and config files.
By doing this we have a clean, versioned deployable that is separate from the source. Are deployables are version in the name - project1-1.0.jar, project1-1.1jar and so on.
I disagree with talonx about keeping your source non-IDE specific - by not storing IDE files in SVN along with you source you are adding extra complication to the checkout, change, checkin, deploy cycle. If you store the IDE project files in SVN you can simply check out the project, fire up the IDE and hit build. You don't have to go through the steps of setting up a new project in the IDE, including the files you SVNed, setting up dependencies etc. It saves time and means all developers are working with the same setup, which reduces errors and discrepancies. The last thing you want is for a developer to check out a project to make a small bug fix and have to spend time having to find dependencies and set stuff up.
To answer question #2 -- who's your consumer for this app?
If it's an internal app and only you (or other developers) are going to be deploying it, then what you have is perfectly all right. Throw in a README file explaining the required directories.
If you're sending it out to a client to install, that's a different question, and you should use an installer. There are a few installers out there that wrap an ant script and your resources, which is a nice approach particularly if you don't need the GUI... just write a simple ant script to put everything in the right place.
Version number is up to you -- naming the JARs isn't a bad idea. I also have a habit of printing out the version number on startup, which can come in handy.