When I am using Eclipse I just configure a project in seconds and create classes in seconds. In intelliJ however, I have to be looking all over the place on how ro create a simple Java class. I swear it is not in the new drop down list. Its giving me options for html and leaves out the class for a Java project! Anything would be accepted.
You just right click on the package you want to create a Java Class in, then select New->Java Class
You need to make sure you have your source tree marked as a sources root (IntelliJ usually does a good job detecting this on its own for existing sources). If not you will need to mark it as a sources root before you are able to create a Java class. Right click on the sources root then Mark Directory As->Sources Root
It depends on the kind of project you're doing. For example, if you're in a maven project, creating a file should be done in src/main/java. If you right click on this folder, you'll have the possibility to create a java class.
In general, the context menu depends on the context you're calling it.
Hope it helps
Related
I would like to find the library specification for a class opened in the editor. I have a Maven project which is quite big with a lot of modules. When I navigate to a class which is referenced from the source code I can see a module origin in the title bar of Intellij Idea like this "HttpServlet [Maven: org.apache..."
However I am not able to see where exactly this Maven library is included from, I can guess this example above as part of an Web Service and I can think of where it is nested in, but this is a hard process sometimes especially if it is a nested include somewhere...
Moving to intellij i'm trying to understand properly the logic behind the its project structure. I come from eclipse. After reading for a while i understood the relation between workspace and project, then between project and modules. However something that is puzzling me is the logic of the default project configuration in Intellij. Indeed, when you create a project there is an initial module which to a certain extend is equivalent to the Project itself. To be more precise, the initial module folder is the Project folder. This is kind of confusing to me. Then when you add more module they are sub-module of that module.
My first question is what is the rationale of making this first module equivalent to the project folder ?
Following this, i would further ask, what the point of having modules as sub-module of others.
In eclipse i use to have simply different project (i.e. module) independent from each other and adding the dependency as necessary. So how does the Idea solution makes it better, if not what is the rational here ?
I saw that one can start an empty project and then add modules to it. However in that case, the modules added are added as subfolder of the Project and therefore there is no initial module equivalent to the Project folder ? So why this difference and what is the rationale behind it ?
What would be the better approach, the first or second ?
Would it be ok to have this first initial module with no src or test folder but just with the proper facet so as to spread it to the sub-module?
I would appreciate if someone could explain a bit the rational of all of it ?
I will move to SBT soon (i.e. maven structure which I suppose inspired all modern IDE project Structure) if one want to explain within that context fine, nevertheless i want to understand the rationale in intelliJ first.
Many thanks,
-M-
PS: What i'm looking for is some advise for some multi-module project structure in Intellij as i'm moving my eclipse workspaces to it.
I think that it's not uncommon for projects to be relatively small, so they don't need fancy modules with dependency management etc. In that case, I find the default project created by IntelliJ to fit perfectly my needs: no need to add submodules, everything is directly in the parent project, it reduces the structure to its bare minimum.
On the other hand, big projects with submodules will likely resemble the structure of a Maven multimodule project (perhaps SBT too, but I don't know this tool at all). You have a parent root which acts as a container for submodules. The parent project may also store configuration (a default SDK, a language level etc. that will be inherited by the submodules). The actual code will be contained in the submodules.
Regarding your questions, it all depends on the kind of project you are developing. For a small codebase, you could keep a simple project with no submodule. For bigger codebases, you can either create modules manually, or import an existing Maven/SBT/whatever project, which will automatically create modules reflecting the imported structure.
I need to add fields into JDK Classes. e.g java.lang.String
First I tried:
declare parents: ( * && !java.lang.Object ) implements VistaInt;
public String[] VistaInt.abc;
this however doesn't work.
It throws a warning
this affected type is not exposed to the weaver:
org.aspectj.lang.Signature [Xlint:typeNotExposedToWeaver]
So I researched it on internet and find out, that it is harder as it seems to be and
AspectJ doesn't support intrumenting JDK classes directly says here:
http://www.inf.usi.ch/faculty/binder/documents/pppj08.pdf
But there is proposed something callse FERRARI framework, tool for AspectJ that should allow injecting JDK classes.
So I kept searching for it and get here:
http://dev.eclipse.org/mhonarc/lists/aspectj-dev/msg02520.html
But none of these links work and I was not able to find any other source, or tool or anything that would help me.
Do you have any idea, where to find this library, or how to inject java JDK types??
Thank you!
First you need to locate the rt.jar that your Eclipse project is using. This is most likely the default for your machine but to check you can right-click on the JRE system library icon in your project, click on Properties and Installed JREs. The rt.jar file is under lib.
Once you have it you will need to weave it from the command line (you might need to download separate ajc compiler). Say you want to weave MyAspect.aj you would run
ajc -inpath rt.jar MyAspect.aj -outjar newrt.jar
You then need to make sure that your code uses this library by putting newrt.jar on the bootclasspath ahead of rt.jar. Running from the command line you do this
java -Xbootclasspath/<path to newrt.jar> MyApplication
In Eclsipse you add -Xbootclasspath/<path to newrt.jar> to the Run configuration.
However, I would not recommend modifying java.lang.String as JVMs often treat this class specially. But you can give it a go if you want :)
Note
I believe that the FERRARI framework that you refer to is for LTW (Load Time Weaving) and this discussion has been for a CTW (Compile Time Weaving) solution. If you want to do LTW then you're going to have difficulties as custom class loaders can't load java.* classes so you can't weave these at load time. Your link suggests that people have attempted a workaround but I don't know anything about this.
My project was created from an maven project, with additional external maven modules added as I discovered that it was useful to have other source files at hand.
The source for interface X lives in module-library. If I navigate to the source file, highlight the X.execute() signature, and then invoke Find Usages (Project Files), a get a list of the usages in module-library.
The source for the application Y lives in module-app. If I navigate to the source file, find a place where X.execute is invoked, highlight that usage, and then invoke Find Usages (Project Files), I get a list that includes usages in module-app, and also the usages in module-library.
Shouldn't these be the same? Does the fact that they are different imply that I've somehow screwed up the creation/configuration of my project?
It looks like a bug, I've reported it in YouTrack. Please login to the tracker and provide more details (like your IDEA version/build number). Sample project to reproduce this problem would help a lot.
You can also check if File | Invalidate caches helps.
I'm currently working an Eclipse plug-in to provide iPOJO manipulation support.
The principle of iPOJO is to modify the .class files generated by the Java compiler to inject some methods and to add/update an entry to the Manifest.mf file.
Currently, my plug-in provides a project Nature and adds a Builder, added at the end of a project builder list, that calls the iPOJO Manipulator.
I use it on PDE projects.
The complete process works but I have a problem :
When my builder has finished its job (and the building process), the whole building process restarts, erasing the output folder and calling my builder again.
If I don't add a safety trick, it makes the building process loop over and over.
As I work on IResource, an IResourceDeltaEvent must be sent at the end of the building process, so I think the best way to avoid that kind of problem is to hide the fact that the resource has changed.
To be clear, I'm looking for a way to modify the class files after a PDE build, without inducing a new build, and without disabling the workspace auto-build property.
Thanks for answers.
I am a little unclear as to what you are describing.
You mention that you want this to work for PDE builds, but PDE builds happen largely outside of the workspace using ant scripts. They do not use IResource, Builder, or IResourceDeltaEvent.
I am guessing that you don't really mean PDE builds, but rather the building of plugin projects inside of the workspace.
In general, Eclipse (JDT in particular) expects that it has complete control over the output folders. However, there is an option in Preferences -> Java -> Building -> Output Folder called "Rebuild class files generated by others". Ensure that this is disabled. Eclipse should not try to rebuild class files that you touch. If your builder only touches class files then it will not trigger other builds after it changes the class files. The only thing is that you need to be careful not to compile things twice (and I think this is the problem that you are describing).
Alternatively, it may be easier for you to implement a CompilationParticipant (and the org.eclipse.jdt.core.compilationParticipant extension point). This will allow you to know exactly when JDT calls a compilation and exactly what it compiles.
Additionally, you will be notified of reconcile operations (ie- changes in working copies that have not been saved). This may be useful for you if you wanted to manipulate files as-you-type.