I'm compiling using android tools without eclipse.
I compile launching "ant debug" from command line.
I have found many many instructions around the web about how to remove with annoying warning, but I haven't been able to make any of them work.
I've tried -D option, I've tried randomly tweaking build.* files, I've tried exporting an environment variable... nothing.
I guess some of these methods just don't work, and some others would work but I've been doing them incorrectly. Anything is possible and I can't stand it any more: any advice on how to do it?
I had the same problem. This is how I solved it:
When I launch ant release, there is this line in the output: [setup] Importing rules file: tools/ant/ant_rules_r3.xml. I edited ant_rules_r3.xml and replaced "ascii" with "UTF8".
I have android-10 SDK kit, this is how I fixed an encoding warning while building a project.
* create c:/myproject/build.properties file
* override default ANT variables
## Override default ANT properties
java.encoding=ISO-8859-1
While it is certainly possible to tweak the system defaults in the Android SDK, such attempts may lead to unpredicted and non-standard behaviour of ANT. Some other bit of the system may expect the default behaviour of ANT or an update will undo your changes. Also if you attempt to compile the project on a different system such as a build server or a team member's computer, you will need to remember to tweak every system involved. As such system tweaks should be avoided and are not recommended.
ANT build process accepts per project overrides for system wide defaults. While it does require an additional file for every project, it is likely to give more consistent build behaviour on all development platforms and ease development, diagnostics and maintenance.
I am using ANT 1.8.4 and providing a build.properties file as suggested by Whome didn't work for me but it is a step in the right direction. I had to create an ant.properties file (for every project) and provide overrides just as Whome suggested.
It is however a bad idea to provide these overrides in any other file, such as local.properties or build.xml files. These files are created and modified by the android tool.
I do recommend the reader to read the build.xml file as it is well documented and provides excellent hints and instructions on how to use the Android ANT build system.
The next interesting bit of reading is the root ANT build script located in android-sdk/tools/ant/build.xml. This file will list all overridable properties such as:
java.target=1.6
verbose=true
But the encoding is set just as it was previously suggested by Whome:
## Override default ANT properties
java.encoding=ISO-8859-1
For the swedish character set, I did as fhucho suggested. But I had to use ISO-8859-1 instead of UTF-8. So maybe it is better to use ISO encodings instead.
Anyone who is looking for a solution, setting the following in the gradle.properties solved it for me.
org.gradle.jvmargs='-Dfile.encoding=UTF-8'
Related
I wonder if anyone is using codenameone with lombok in Eclipse. I've googled, but all I could find is an old question of mine.
A tiny success
I've tried it, took a demo project, modified nothing and opened it in my Eclipse configured for Lombok. When compiling, I got the same stacktrace as here. I've added
/usr/lib/jvm/java-8-oracle/lib/tools.jar
to the path under Preferences -> Installed JREs -> Edit -> JRE system libraries (which may be a pure non-sense) and it didn't help.
Then I've replaced compiler="modern" by compiler="extJavac" in build.xml and it compiles. I can even use Lombok annotations and they compile and work in the simulator.
The problem
I'm afraid, this was the simple part. I guess, for submitting, I need to replace the source code by the output of delombok. I've tried to submit it as is and nothing happened (no error, no response).
Has anyone done it already?
Any tips?
You shouldn't change the classpath but if the bytecode has access to the properties then it should "just work". If you look at the build.xml file you will notice that it has targets for every one of the supported platforms and before the target occurs you will see a compilation target that packages the JAR that's sent to the servers.
Steve wrote a post about porting other languages to Codename One. This is simple by comparison.
It actually works! All I had to do was to
add the path to lombok.jar to the Java Build Path1
in the javac call of the jar task
replace compiler="modern" by compiler="extJavac"
add the path to lombok.jar to the classpath
1 This is not recommended as the dependency is unavailable on the build server, but that's exactly right. Lombok is a compile-time only dependency and the build seems to be based on the dist.jar, where Lombok has already done its job.
One year later: There was a problem with my old setup, so I installed everything anew and it seems to work. Just note that there are three javac tasks in the build.xml.
When moving onto IntelliJ, one feature I missed from Eclipse is its ability to export and replace a jar even if that jar is being used by another process.
When working on plugins with an API, this feature was very useful as I could make a change in Eclipse, export and do a simple reload command allowing me to instantly see my changes.
However, in IntelliJ, it complains the jar is being used by another process. This forces me to stop the process, replace the jar and start it again which takes a very long time.
Is there a plugin or a setting I could change in IntelliJ which could bring back this feature?
I've looked around on Google but haven't found anything relating to this feature in Eclipse working in IntelliJ.
Thank you.
You can check idea.jars.nocopy option in the bin/idea.properties file.
Try to uncomment it and set explicitly idea.jars.nocopy=false
#---------------------------------------------------------------------
# IDEA can copy library .jar files to prevent their locking.
# By default this behavior is enabled on Windows and disabled on other platforms.
# Uncomment this property to override.
#---------------------------------------------------------------------
# idea.jars.nocopy=false
We use gradle to build our Java projects, some are based on JDK7 and some on JDK8. I know of the org.gradle.java.home property, but it seems flawed to me.
If I configure it in '~/.gradle/gradle.properties' this will force me to use the same JDK for all my gradle projects.
If I configure it in '/my-git-project/gradle.properties' this will force me to put a reference to a local JDK installation in a shared Git repository. The path to JDK do not belong there.
What I basically would like to have is something similar to this in '~/.gradle/gradle.properties':
systemProp.jdk8=/my/local/path/to/jdk8
systemProp.jdk7=/my/local/path/to/jdk7
And under source control in '/my-git-project/gradle.properties':
org.gradle.java.home=$systemProp.jdk8
What's the best solution/workaround for this?
This is more of a process question than a Gradle or Java question. Ultimately, you have to force everyone to specify their various JAVA_HOMEs without being onerous. You have several options:
Command line: ./gradlew -Dorg.gradle.java.home=/path_to_jdk_directory
But, of course, now everyone has to type some hideous junk into their command line every time they run a build.
gradle.properties and check-in the path. Then, make everyone use the same path.
Not everyone's going to want to use the same path, especially if you have Mac/Unix and PC users.
2b. Instead of using an identical path, everyone could modify their local gradle.properties with their custom values, then never check-in their modifications.
Primary problem: someone's totally going to check-in their local values and screw up CI and everyone else.
gradle.properties.template check-in, everyone creates their own gradle.properties; put gradle.properties in your .gitignore
This might be your best bet. You have a template file that you check-in, but everyone has to copy it to gradle.properties and fill in their specific values. You'll need to setup your CI to do something similar, or check-in something like gradle.ci.properties and have CI use that. But, everyone only has to do this once instead of once per build. Unfortunately, they will have to update their personal file every time the template changes (unless you write some code to do that).
We cope with that problem like this:
The one who starts the build is responsible for properly setting JAVA_HOME
On developer machines that may be brittle. But it works perfectly, if you build and deploy from a dedicated buildserver.
I have written a nice plugin, which incoporates some generated java sources.
I can build the project just fine.
I can run it in a run configuration that launches another eclipse and it works to my liking.
So I thought: time to make it install-able.
Hence I created a feature project and an update site project, and build and export that and it looks like it works fine. I can even "Install" it from my update site, or export the plugin directly in the running workbench. I see that it is installed but if I try to open a file that would activate my plugin, it throws exceptions. Specifically, it tells me there are "unresolved compilation problems".
After long searching, rebuilding (no errors), retesting again and again I find a logs.zip file, with a directory whose name resembles that of my plugin and therein a 54k file (mind you, it's 2011 and disk space is extremely scarce, obviously) with the funny name #dot.log. How desperate one must be to look in such a file?! But, surprise, surprise, it turns out there are 54k error messages like the following:
# 02.12.11 19:58:55 MEZ
# Eclipse Compiler for Java(TM) 0.B76_R37x, 3.7.1, Copyright IBM Corp 2000, 2011. All rights reserved.
----------
1. ERROR in X:\dev\frege\FregIDE\src\frege\IO.java (at line 1451)
final public static Consts ij = new Consts();
^
Syntax error on token "Invalid Character", delete this token
The "Invalid Characters" are, of course, perfectly legal java identifier characters, it's just that they are not ASCII letters. This is why I have all files set to UTF-8, have set UTF-8 as default encoding, and as said before, with normal build it works perfectly.
Is there a way to prevent eclipse from recompiling everything when I export the update site, the feature or the plugin. This is what I would prefer most as everything is already compiled and recompilation takes another minute or so. (There is even a flag "Use class files compiled in the workspace." but it seems to do nothing - it just recompiles.)
Alternative: Can I somehow modify the script it uses to build that? I can't find the ant script he uses to build. If I could look up the javac step and put encoding UTF-8 there (that is what I expect to be the problem.)
There is an "Save as Ant script" checkbox, but the Ant file does only contain:
<?xml version="1.0" encoding="UTF-8"?>
<project default="feature_export" name="build">
<target name="feature_export">
<pde.exportFeatures destination="x:\dev\frege\FregeUpdateSite"
exportSource="false" exportType="directory"
features="FregeFeature" useJARFormat="true"/>
</target>
</project>
How can I make eclipse use the correct settings for the compile build if I can't prevent it from compiling?
If you are using the "pde.exportFeatures" task to export from a workspace, then I believe there is an attribute "useWorkspaceCompiledClasses" to use the binaries from the workspace. This is equivalent to the check box in the export wizard.
Note that the pde.exportFeatures task is an export from the UI and is different from a headless PDE/Build. The properties that Francis refers to are for headless PDE/Build. During an export, PDE/UI manages these for you and you can't change them.
The plug-in and feature specific properties will affect the UI export as well as the headless build. (I got the link incorrect in my comment on Francis' answer).
I would recommend setting the encoding in the plugin's build.properties file instead of reusing the workspace binaries. I would also suggest setting up a real PDE/Build headless build instead of the export from UI task.
You can use the build.properties file that's part of the PDE build to set the compiler options for the compile that's done in the build: http://help.eclipse.org/indigo/topic/org.eclipse.pde.doc.user/reference/pde_builder_config.htm (use the -encoding option)
There is no way that I know of to use the class files from your workspace in the build.
I was working with a project that was saved in linux
I opened it in a windows IDE and the strange thing is that it inserted break lines in all .java .jsp and other text files
I like to remove all those empty lines recursively at the root directory of the project.
Does anybody have some shell script that can I run to change these files?
Thanks in advance, André.
You might just need to run dos2unix on the files. Pass it through a hex viewer to see if the line-endings are 0D 0A (CR/LF) or are actually two newlines or something else. If the former, dos2unix will work. Something like:
find . -name \*.java -exec dos2unix \{\} \;
From your root source directory. Test first, make backups, etc.
Which Windows IDE are you using? Is this Eclipse? If yes.
Window -> Preferences -> Java -> Code Style -> Clean Up -> Edit -> Remove Trailing whitespace
Hopefully this will work
On a sidenote, not directly being an answer to your question (it seems like there already are good answers), I would recommend, if possible, to use a bit of time to uniformly setup your IDE environments so that they are compatible.
I have great experience in using Eclipse as it is available for all major OS platforms, and has the option of saving essential project settings in whichever repository you are using, thus enabling you to have identical setups so that for example line breaks are handled properly.
Also, to ensure everybody has the same Eclipse configuration, plugin versions, even basic workspace configurations, I strongly recommend using Eclipse configuration management tools like Yoxos, as it enables you to specifically configure a Eclipse configuration per project, and distribute said configuration in a simple XML-based file associated with the Yoxos Launcher program which handles dependencies, updates etc.
I have been involved in quite a few projects thus far, and even in teams where we are developing from Linux, Windows and Mac OS X, there are no (or well as minimal as possible anyway) problems with configurations, line breaks, plugin versions, etc. due to the extra effort in streamlining the IDE setups.
You might want to see if you can configure your IDE/editor to deal with the files instead of converting them. If you use source control, changing all your line endings will flag every line in every file as "modified", and that will make it difficult (if not impossible) to track changes if/when you migrate the code back to your Linux system.