The Jetbrains Kotlin compiler in Eclipse outputs to a hidden folder inside the Eclipse compiler plugin. This hidden folder is then made available through the Eclipse Kotlin classpath container.
In bndtools we need a normal file system folder since bnd can run both from the file system as well as in Eclipse. Since the folder is a linked resource there is no known way to translate it outside Eclipse.
Anybody knows how to tell the Kotlin compiler to just output it in the bin folder?
Currently, this is not possible in the Kotlin Eclipse plugin.
To make it possible that Kotlin code can be used from Java, Kotlin plugin produce so-called lightweight class files to this folder. These class files do not contain bodies for methods and they are stored in memory.
Actual class files, that are used to run an application, are being built only before launch and they are produced to the default output folder. For now, we cannot produce class files on each save reasonably fast as there is no incremental compilation in the plugin yet:
Feel free to upvote for this issue.
From the short analysis of the code of Kotlin plugin, it looks like the proper method is KotlinCompiler.compileKotlinFiles. It is being called in two contexts:
KotlinBuilder.build — this is the one called on the project build; it makes a call stack trick (or rather a hack...) to check if being called from the LaunchConfigurationDelegate, and depending on the results, either compiles whole project (via its own private fun compileKotlinFiles), or just makes stubs in memory.
KotlinCompilerUtils.compileWholeProject — this is in fact being called from 1.; nice static method, perfect for abuse until the problem is correctly solved in the plugin. :)
So, I'd use the method from 2. wrapped in a similar way as compileKotlinFiles from file in 1.
Related
I'm working on a scala sbt project, and I am at a point where I want to assemble the whole thing to share a .jar-file with others, so that they can use it on their side. For my local testing, I'm doing so using the sbt-assembly plugin, that works nicely.
When sharing, I would though prefer to only share the parts that are important for the other party (the project has huge components that irrelevant at the current point, and I'd prefer not to share these for various reasons). Concretely, they will be executing one particular main file, so it would be enough to pack everything that this file depends on.
Is there a way to accomplish this? I'd also be interested in doing this on the code level (i.e., create a copy of the project that only contains dependencies of that main file), but also while assembling or even modifying the jar file after assembly is okay. I did not find the tools to achieve any of these.
As I said, I'm dealing with a scala sbt project, and I'm working with IntelliJ IDEA; I'd also be happy with an IDE tool that does the job.
In my current project I'm working with Java, Spring Boot and .aj files. However, the main problem about work with AspectJ is that there are not a lot of IDEs that supports this feature.
Eclipse (and i think that netbeans too) supports the AspectJ language because I've used it in the past. However, I've worked with IntelliJ and Visual Studio Code IDEs during the last years and I don't really want to come back to Eclipse (or Netbeans). :)
Also, I know that the Ultimate Version of IntelliJ has support to AspectJ. The problem is that you must have an IntelliJ license to use it.
https://www.jetbrains.com/help/idea/enabling-aspectj-support-plugins.html
I started to create a new language server for the Visual Studio Code to manage the .aj files. I'm following this guide.
https://code.visualstudio.com/docs/extensions/example-language-server
The .aj files are now correct colored and shows a valid syntax!
However, I'm getting errors in the Java code. Check this schema about the AspectJ description:
As you could see, I have a .java file called Point and I want to have some methods divided in some .aj files. When the project is compiled, I'll have just one Point.class that includes the methods clone(), compareTo(), etc.
Also, another possible use is that if my .java class implements some interface, I'm able to implements the methods in a .aj file.
Problem: I'm not able to see my Java project without errors because the .java files and the .aj files are not "synchronized", so the .java class says that needs to implements some methods although they're defined in the .aj file.
Someone could help me with tips about language server development?
Regards,
I can't help you with VS Code <> AspectJ integration, but I could recommend a work-around with your issue. If my understanding is correct, you get errors because the methods declared through inter-type declarations by your aspects are not visible to your java code.
In that case you might try to create Java 8 interfaces with default methods that declare and implement those methods. I would try to get rid of the aspects altogether and work with just interfaces with default methods, but if - for some reason unknown to me - you really need to use aspects to implement those methods, you can still leave your default methods empty and move the implementation into the aspects. This way you don't need to use inter-type declarations anymore, so VS Code integration might work better.
Unlike Java, Scala does not require the location of a file to correspond to the file's package declaration - e.g. a file in the package com.company.project need not be in com/company/project. My company's Scala projects have a directory structure that does not correspond to their package structure, and the Scala compiler is quite happy with this.
However, when moving or copying a Scala file, IntelliJ automatically changes the file's package declaration to match its location. To work around this, I have to either manually revert the change or use a separate tool to do these file operations.
Is there a way to disable this behaviour?
(This question is related but doesn't describe the exact behaviour I'm talking about.)
This is not currently possible. A request for this feature has been opened on JetBrains YouTrack here.
I have an exported Eclipse Java Project in my server and I want to be able to compile the project and use ASTParser with JDT.
I'm able to compile the project using BatchCompiler, however it runs on console and gives me PrintWriters instead of an array of problems and errors. Also I want to be able to use proposals in Eclipse and BatchCompiler didn't built for this purpose.
Therefore I tried to use ASTParser, it can be used with either char[] or ICompilationUnit. CompletionProposalCollector and org.eclipse.jdt.internal.compiler.Compiler.Compiler needs ICompilationUnit so I have to create an ICompilationUnit which only can be created by an IJavaProject (https://dl.dropboxusercontent.com/u/10773282/2012/eclipse_workspace.pdf) in order to be able to use these features.
It seems the only way to create IJavaProject is to use ResourcesPlugin.getWorkspace(), however it returns java.lang.IllegalStateException: Workspace is closed. on my computer and it seems the reason is that the program that I coded is not an Eclipse plug-in.
Is there any way to create IJavaProject without Eclipse environment?
From the comments, it looks like you are trying to do more than just parsing, you actually want to get some form of content assist.
I'm afraid that you're asking for too much. There is no simple way to get the power and flexibility of JDT outside of a running Eclipse instance (believe me, I've tried). There's no simple way, but if you are brave and strong willed, you can one of try following:
Run a headless Eclipse on your server that works on top of an actual workspace. This would be the easiest to implement, but would be the most resource intensive and least flexible way of doing things.
Use the jdt core jar, and create alternate implementations of the IResource hierarchy, and the parts of JFace that are used by the the parser and the CompletionEngine. This would likely be the most feature-rich way to go, but also the most brittle. I can't guarantee that this would work as you may need to create some very complex stubs for internal Eclipse non-API classes.
Avoid the CompletionEngine and the ASTParser entirely and just use the batch compiler. You would then need to provide an alternate implementation of org.eclipse.jdt.internal.compiler.env.INameEnvironment. This implementation would be able to find types, files, and compilation units in your actual project structure. You'd need to reimplement support for content assist, but this would most likely work reasonably well.
I am actually fairly interested in doing something like this (but I lack the time to do it). If you are seriously considering creating a headless JDT that can run on a server, feel free to ask for more information. I am quite familiar with JDT internals.
I've had a similar problem. Here is how to use ASTParser without Eclipse (it just needs the core JDT JAR on the classpath): http://blog.pdark.de/2010/11/05/using-eclipse-to-parse-java-code/
First of all, I know how to write a basic/intermediate level
makefile. In my c++ projects I use a makefile that does a lot of stuff
automatically. The most important to me is that it automatically
detects all source files (which are always in the same folder) using
wildcards, uses that to predict the name (and location) of all object files, and compiles appropriately.
Recently I've been trying to achieve the same effect with my scala
projects, but I've hit two obstacles.
Copilled class files which belong to packages are stored inside
subdirectories (like com/me/mypack/). This is a problem because
Make needs to find these files to check the timestamps (and I
have no idea how to do that automatically).
Some source files (such as those defining a package object)
generate class files with different naming standards. Again, Make
needs to know where these class files are and I don't know how to
do that automatically.
The consequence of this is that the "problematic" source files are
recompiled every time I run make (which is aggravated by scala's long
compile times). I'd like to know how to fix that without having to
manually write out the entire list of expected class files.
EDIT As an extra note: I'd like to avoid placing the source files in subdirectories. I like keeping them all in the same directory for several reasons.
You should use sbt or Maven for Scala. These are designed specifically for the way Scala and Java work, and they will be much easier to set up and use. They also provide many more features than make does.
These tools are used for a variety of things. Compiling is a big one, but they are also important for dependency management. Also, sbt (and probably Maven?) does "incremental compilation", so that only classes that have changed are recompiled, which speeds up compilation.
I personally use sbt, but I know people who prefer Maven.