Showing posts with label Eclipse. Show all posts
Showing posts with label Eclipse. Show all posts

Tuesday, April 1, 2014

Setup your Java 8 Eclipse Project

If the time had come and you can easily download and install Eclipse with Java 8 support, great... if not, try this out: Setup Eclipse with Java 8 and Lambda expressions

Setup a Java 8 project:
  • Create a Java project
  • Make sure you have a Java 8 JDK installed in Eclipse goto: window > preferences > Java > Installed JREs, and if not add it!
  • If you would like your entire workspace to be configured to work with Java 8 perform the flowing action in window > preferences. Otherwise perform these on the project properties.
  • You would have to make sure that your compiler compliance level match 1.8:
    **> Java Compiler, and make sure the compliance level is set to 1.8.
  • Make sure the Java library used in the project is the Java 8 JDK at: **> Java Build Path
  • Go to this link and this link, copy the classes as string(Yeah simply mark it all and copy it)

    And now...
  • Click on a package in your project and paste the text(Yeah simply paste the "text" onto the package in the Package Explorer!)
  • Poof... you have a two classes in that package(I just love Eclipse don't you!?).
  • It should compile and be executable.

Let me know if you had issues, so I can make this better!

Setup Eclipse with Java 8 and Lambda expressions

I thought this would be a walk in the park... but this was annoying as F***, I've spent a half a day searching Google only to find a pile of rubbish that lead to dead links and wrong instructions to download versions of Eclipse that don't do the trick or take over 3 hours to download(DEAR GOD 3 HOURS), and a bunch instruction about a pre-release Eclipse versions which does not work!

So... what does work:


Took exactly a couple of minutes to get it all set up...

Sunday, September 30, 2012

Making Eclipse, Maven and Tomcat to play nice

Hi,

So I've been struggeling with this for hours, till I found one ultimate solution to run and debug a tomcat servlet in Eclipse, so here it is:


First a parent pom should look something like this:

<project
 xmlns="http://maven.apache.org/POM/4.0.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <parent>
  <groupId>com.nu.art.software</groupId>
  <artifactId>nu-art-maven-deploy-project</artifactId>
  <version>0.0.1</version>
 </parent>

 <groupId>com.nu.art.software</groupId>
 <artifactId>tomcat-servlet-maven-parent</artifactId>
 <version>0.0.1</version>
 <packaging>pom</packaging>

 <name>Tomcat Servlet Parent Pom</name>
 <dependencies>
  <dependency>
   <groupId>org.apache.tomcat</groupId>
   <artifactId>tomcat-catalina</artifactId>
   <version>7.0.27</version>
   <scope>provided</scope>
  </dependency>
 </dependencies>

 <build>
  <plugins>
   <plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>tomcat-maven-plugin</artifactId>
    <version>1.1</version>
    <configuration>
     <webXml>src/main/webapp/WEB-INF/web.xml</webXml>
    </configuration>
   </plugin>
  </plugins>
  <finalName>${project.name}</finalName>
 </build>
</project>

Note the location of the web.xml & project name...

Next is the child project pom, which should like something like this:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
 <parent> 
  <artifactId>tomcat-servlet-maven-parent</artifactId>
  <groupId>com.nu.art.software</groupId>
  <version>0.0.1</version> 
 </parent> 
    
    <modelVersion>4.0.0</modelVersion>
 <groupId>com.nu.art.software.cyborg.androidServicesUtility</groupId>
 <artifactId>android-services-utility-server</artifactId>
 <packaging>war</packaging>
 <version>0.1.0</version>
 <name>Android-Services-Utility-Server</name>
 <url>http://maven.apache.org</url>

 <dependencies>
  <dependency>
   <groupId>junit</groupId>
   <artifactId>junit</artifactId>
   <version>3.8.1</version>
   <scope>test</scope>
  </dependency>
  <dependency>
   <groupId>com.nu.art.software.arttpServer</groupId>
   <artifactId>arttp-servlet</artifactId>
   <version>0.0.1</version>
   <scope>compile</scope>
  </dependency>
  <dependency>
   <groupId>com.nu.art.software</groupId>
   <artifactId>dbator</artifactId>
   <version>0.0.1</version>
   <type>jar</type>
   <scope>compile</scope>
  </dependency>
  <dependency>
   <groupId>com.nu.art.software.cyborg</groupId>
   <artifactId>cyborg-crash-report-core</artifactId>
   <version>0.0.1</version>
   <type>jar</type>
   <scope>compile</scope>
  </dependency>
  <dependency>
   <groupId>com.nu.art.software.cyborg.server</groupId>
   <artifactId>cyborg-server-module-crash-report</artifactId>
   <version>0.0.1</version>
   <type>jar</type>
  </dependency>
   <dependency>
   <groupId>com.nu.art.software.cyborg.server</groupId>
   <artifactId>cyborg-server-module-c2dm</artifactId>
   <version>0.0.1</version>
   <type>jar</type>
  </dependency>
 </dependencies>
</project>

And finally goto Project -> Properties -> Deployment Assembly, And remove all the content from it. Add the following folder to the assembly: target/${project.name}

This would result in debugging the latest servlet build by Maven. so in order to launch it install your project, and Run/Debug on server...

NOTE!!! 
This is not a perfect working setup, but if you are struggling with the bugger, and want to be able to quickly evaluate your project, this works fine.

Tuesday, March 27, 2012

ADT 17 Build issues

Google, Google, Google... What should I do with you??? Don't you ever think a bit outside the scope, or is this some sort of a grand master plan to muscle us all to work your way?

I can tell you right now that your main issue regarding the build process of the Android projects in Eclipse is due to the fact that there are two class paths for the same project, one is the Android libs, the other is the IDE classpath. I think that as programmers you should know this is BAD PRACTICE!!!

I came across two major issues, the NoClassDefFoundException, and the terribly annoying jarlist.cache file.
  1. In the previous versions of the ADT the dependent jars where automatically exported, which caused the dalvik issues in the build, with the "duplicate files" error. So their solution was to cancel the export completely and leave the export management to Eclipse, which is a step in the right direction... Personally, I would simply resolve the dependencies and not import a duplicate dependency.

    SO, if you experience the NoClassDefFoundException, it is because your .class files from the project dependencies were not imported to the output folder of the final Android application project.

    Maven, Eclipse, Ant could all have a different dependencies resolution, and different hierarchy structure, plus your own projects hierarchy, brings one to the conclusion that to understand the export  dependencies  feature, you must know what the hell you are doing, and understand projects hierarchy, your build tool, and how it resolves its project's dependencies.

    In general it is always best to enable the export on project D, but there are some cases exporting on project A would be preferred. For example:

    I.  Projects A, B, C, uses an XML library, where would you export the library? See Answer 1.
    II. Project A is a framework module project that projects B, C uses? See Answer 2.

    Nuts ha? but there is no other way to be 100% sure you would not export the same .class file twice!
    It may be that Eclipse resolves this issues, but I've started to trust no one! I have an intermittent Android lib project with most of the dependencies, which are also marked as export, and the final project depend on it.

    To enable export for dependencies you go to:  Project -> Right Click -> Properties -> Java Build Path -> Export tab -> check the project you want to export.

    And as for this solution, I think it is a bad idea... very bad idea, why? just because, I don't feel like writing another 100 rows about how you should work, this is my advice, you can take it or leave it :)
  2. The second most annoying issue with ADT 17, is the jarlist.cache file. Brilliantly the ADT team decided they need some file for god knows whatever reason, (it is really beside the point)  and they have decided to place that file hard coded at ${ ProjectFolder}/bin/jarlist.cache, and because some of us Eclipse users, are used to the fact that the default output folder is ${ ProjectFolder}/bin/, we experience this issue. Problem is that this build action does not effect only Android projects builds, but also pure Java projects, which eventually causes the mess. Android default output folder is at ${ProjectFolder}/bin/classes, you can verify it, go to your android project .classpath file and change the output to "/blah/blah" and see what happens once you clean build... like magic the adt nature returns it to "/bin/classes".

    The solution for this mess: point the output of all your projects in the workspace to "/bin/classes", this solves it!

If you encounter more issues with the ADT 17 let me know, I'll add reference to it.

In general, it is a step in the right direction, but this is annoying as hell, they change the freaking project management every version... can't they formulate something stable? I really hope the next version would be better, I mean they turn 18 soon... ;)


Answer 1: Project D
Answer 2: The dependencies whom are unique to Project A, would be exported. common used dependencies would not, they would be exported in Project D!!    << == (This is the conclusion!!)