How to use lombok with Android project

[Hartmut]

Hi folks,
I am new to working with android and would like to continue using
lombok. I read in the group that it is explicitly meant to be used
with it, but I fail to get it running. So far, no solution presented
itself with googling...

My problem is that in order to use the annotations, lombok.jar must be
in the classpath. If it is there, the application will not deploy to
the phone with this error message

The library 'lobmbok.jar' contains native libraries that will not run
on the device.
[2011-12-14 11:14:07 - androidGui] The following libraries were found:
[2011-12-14 11:14:07 - androidGui] - com/sun/jna/darwin/
libjnidispatch.jnilib
[2011-12-14 11:14:07 - androidGui] - com/sun/jna/freebsd-amd64/
libjnidispatch.so
[2011-12-14 11:14:07 - androidGui] - com/sun/jna/freebsd-i386/
libjnidispatch.so
[2011-12-14 11:14:07 - androidGui] - com/sun/jna/linux-amd64/
libjnidispatch.so
[2011-12-14 11:14:07 - androidGui] - com/sun/jna/linux-i386/
libjnidispatch.so
[2011-12-14 11:14:07 - androidGui] - com/sun/jna/sunos-amd64/
libjnidispatch.so
[2011-12-14 11:14:07 - androidGui] - com/sun/jna/sunos-sparc/
libjnidispatch.so
[2011-12-14 11:14:07 - androidGui] - com/sun/jna/sunos-sparcv9/
libjnidispatch.so
[2011-12-14 11:14:07 - androidGui] - com/sun/jna/sunos-x86/
libjnidispatch.so

Thanks for any help
Hartmut

[Matthew Jaggard]

You do not need to include lombok.jar in your classpath for running, only for compiling. In Netbeans I do this by unticking a box labelled "package" which means that the file is used for compilation but not packaged for distribution.

--
You received this message because you are subscribed to the Google
Groups group for http://projectlombok.org/

To post to this group, send email to project...@googlegroups.com
To unsubscribe from this group, send email to
project-lombo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/project-lombok?hl=en

[Hartmut]

Any clue how to do that in eclipse? The jar is not marked in the build path->export list

[Matthew Jaggard]

Not a clue I'm afraid.

As a work around, you could manually remove the lombok stuff from the output using a standard zip tool. It's an ugly workaround but might get you developing again until someone who uses eclipse replies.

Mat.

On 14 December 2011 11:12, Hartmut <hartmu...@gmail.com> wrote:

Any clue how to do that in eclipse? The jar is not marked in the build path->export list

[Miguel García López]

On Dec 14, 2011, at 12:15 PM, Matthew Jaggard wrote:

> Not a clue I'm afraid.
>
> As a work around, you could manually remove the lombok stuff from the output using a standard zip tool. It's an ugly workaround but might get you developing again until someone who uses eclipse replies.
>
> Mat.
>
> On 14 December 2011 11:12, Hartmut <hartmu...@gmail.com> wrote:
> Any clue how to do that in eclipse? The jar is not marked in the build path->export list

I'm not a regular eclipse user myself either, but these instructions I once followed for a different (but I think analogous) project may help:

http://code.google.com/p/androidannotations/wiki/Configuring

HTH, regards.

--
Miguel García López <miguel.ga...@gmail.com>
http://es.linkedin.com/in/garcialopezmiguel
@mglpia

[Hartmut]

Thanks for this suggestion, but it does not solve the problem. The annotation processing is done all right (I guess), the situation is that

• to use the lombok annotations, lombok.jar must be in the class path,
• but lombok.jar must not be deployed to the apk

My current work-around is to open lombok.jar and delete the following directories in it:

• com
• lombok/*  (=all subdirs of lombok)
  
• org

That works, but is of course slightly annoying.
/Hartmut

[Fabrizio Giudici]

On Thu, 15 Dec 2011 14:11:12 +0100, Hartmut <hartmu...@gmail.com> wrote:

> Thanks for this suggestion, but it does not solve the problem. The
> annotation processing is done all right (I guess), the situation is that
>

> - to use the lombok annotations, lombok.jar must be in the class path,
> - but lombok.jar must not be deployed to the apk

>
> My current work-around is to open lombok.jar and delete the following
> directories in it:
>

> - com
> - lombok/* (=all subdirs of lombok)
> - org

>
> That works, but is of course slightly annoying.
> /Hartmut
>

I can't help you more than it has been said - just for the benefit of
other people who might come to this archived thread with similar problems,
but open to the idea of using different build system, it's worth while to
say that Maven + Android + Lombok work a breeze out of the box.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

[Moandji Ezana]

Maybe you can force proguard to delete those files?

Moandji

[Reinier Zwitserloot]

Huh, never thought about that.

Actually, to use lombok, all you _really_ need on the classpath is the lombok annotations, i.e. all the classes in the lombok package, and that's it (well, for logging, lombok.extern.*). These are _tiny_, the jar for this would be a kb or two, tops.

The full lombok needs to be installed into eclipse of course, and also needs to be on the classpath when using javac to compile.

We can easily make such a jar during our build, but, where would we upload it? It has no place on maven central, of course, but we could offer it as a download on the site. We can also have lombok.jar itself spit it out on request, via e.g.:

java -jar lombok.jar makeJarForEclipse

or some such.

would that help?

[Hartmut]

Why wouldn't you put the annotations-only into maven-central?

1. the tiny annotations-only version (new artifact: lombok-annotations), which one can just drop into every project (android or otherwise)
   
2. the full version in order to install it into eclipse (but who would put this into her project if the jar is not necessary)
• does this version need the annotations definition at all?
• The really cool thing for this would be a lombok-maven-install plugin such that I would never ever have to run lombok.jar again to install it with eclipse (or have it from an eclipse update site) ... or do you have that already and I just missed it

And: yes, it would help (a bit). But removing the 'offending' subdirectories with a reasonable archiver is not such a hassel.

[Reinier Zwitserloot]

Well, for maven, you still need the whole kit and caboodle, because the full lombok needs to be on the classpath when invoking javac. Also, apparently, if you use .m2 things do work out fine, assuming you mark lombok as a build-only dependency (which you should - it IS a build only dependency. Lombok has absolutely no business being on the runtime classpath of any app).

[Fabrizio Giudici]

I don't understand where's the problem with Android + Maven + Lombok. As I
previously said, and Reinier said again, if it's properly configured
there's nothing to do and the jar won't become part of the app.

[Sam]

I'm having the exact same problem and I cannot get it fixed, how exactly should I add the jar to the Android project the "correct way"? 

[Hartmut]

My non-maven way of doing it is
- make a copy of the lombok.jar
- open the jar with a suitable archiver
- delete the directories com, lombok, and org
- save and move the result into the libs dir of your android project

If you do not have an archiver available that allows you to modify the jar in-place, you need to unpack it completely (the jar is actually a gzip archive), remove the directories and re-pack it.

[Reinier Zwitserloot]

Which files should remain in the jar? We could produce an android specific runtime library during the promote-to-release process if it helps. We can make lombok.jar itself capable of emitting such a thing too (`java -jar lombok.jar createAndroidRuntime` or something like it).

[Matt Fowles]

Reinier~

Any files that use JNI. I would very much like this feature.

Matt

[Reinier Zwitserloot]

So the JNI files have to _remain_ but the rest has to go? I'd have expected it to be the other way around, really.

If you're already building jars that work, could you just send me the output of running:

jar tvf thatjar.jar

on it?

Gracias!

 --Reinier Zwitserloot

[Matt Fowles]

Reinier~

Sorry, the JNI files have to go and the rest is ok. I have not built
such jars but am merely reporting what android barks at when I try to
load lombok.jar. I can try and produce a stripped jar shortly...

Matt

[Matt Fowles]

Reinier~

Attached is the simplified jar. I just did:

jar -xvf ../lombok.jar
rm -rf com
jar -cvf ../lombok.jar *

Now it uploads cleanly into android.

Matt

[Ehtesh Choudhury]

Hey that was convenient. Thanks. It'd be cool if you guys outputted a modified Lombok fit for Android consumption.

>>> > To post to this group, send email to project-lombok@googlegroups.com

>>> > To unsubscribe from this group, send email to

>>> > project-lombok+unsubscribe@googlegroups.com

>>> > For more options, visit this group at
>>> > http://groups.google.com/group/project-lombok?hl=en
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups group for http://projectlombok.org/
>>>

>>> To post to this group, send email to project-lombok@googlegroups.com

>>> To unsubscribe from this group, send email to

>>> project-lombok+unsubscribe@googlegroups.com

>>> For more options, visit this group at
>>> http://groups.google.com/group/project-lombok?hl=en
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups group for http://projectlombok.org/
>>

>> To post to this group, send email to project-lombok@googlegroups.com

>> To unsubscribe from this group, send email to

>> project-lombok+unsubscribe@googlegroups.com

[Matt Fowles]

Ehtesh~

I totally agree. I have been using this jar fairly happily ever since I emailed it.

Would it be possible to have a maven artifact for a stripped android compatible jar like this?

Matt

To post to this group, send email to project...@googlegroups.com

To unsubscribe from this group, send email to

project-lombo...@googlegroups.com

[Reinier Zwitserloot]

We spent some time investigating.

When you include lombok.jar in the libs dir like this, the whole shebang is INCLUDED IN YOUR DEX!!

This is obviously not a good thing. We can indeed ship a so-less version which would 'work', so to speak, but it does inflate your DEX considerably and this is bad. Within eclipse you can make a tiny jar with JUST the annotations, but then it won't work from the command line.

We've asked the android team to find a solution for this. In the mean time, we rolled up a workaround.

Can you follow these instructions:

http://projectlombok.org/experimental/android.html

and tell us if it works? The latest official lombok release does not have the publicApi app, but you can download the file that would build from here:

http://projectlombok.org/experimental/lombok-api.jar

It would be nice if you could use dexdump to double check that lombok did not make its way into your APK.

[Matt Fowles]

Reinier~

I will try this when I get home!

Thanks,

Matt

To post to this group, send email to project...@googlegroups.com

To unsubscribe from this group, send email to

project-lombo...@googlegroups.com

[Fabrizio Giudici]

On Mon, 19 Mar 2012 22:36:18 +0100, Matt Fowles <matt....@gmail.com>
wrote:

> Reinier~
>

> I will try this when I get home!
>
> Thanks,
> Matt

... and, for the sake of casual readers, let me recall that (as per the
cited page) with Maven...

.... "You should be able to just follow the normal lombok with maven
instructions."

(you can replace "should be" with "are").

[Reinier Zwitserloot]

So... this has been tested? If you use maven to build your android projects (including maven-eclipse plugin), this 'just works', no changes needed?

 --Reinier Zwitserloot

[Fabrizio Giudici]

On Mon, 19 Mar 2012 23:27:21 +0100, Reinier Zwitserloot
<rei...@zwitserloot.com> wrote:

> So... this has been tested? If you use maven to build your android
> projects
> (including maven-eclipse plugin), this 'just works', no changes needed?

Well, I've been using it since two years, no problems at all. But I can't
speak for Eclipse: my stuff works in plain command line mode and with
NetBeans.

[Matt Fowles]

Reinier~

I have not been able to use maven+lombok+eclipse given the instructions provided.  I use the stripped jar I attached as a work around.

I will try again more carefully, using the experimental stuff tonight.

Matt

[Lenny Primak]

I am using glassfish with great results if that helps. Never used jetty. 

[Matt Fowles]

Reinier~

Let me start by prefacing this with, I am not very good with maven and this is the first thing I have ever used it for.  Most of the time for this app, I use the maven eclipse plugin from within eclipse.  

Using the setup that is suggested on the website 

http://projectlombok.org/mavenrepo/index.html

From the command line:

$ mvn clean install

$ adb install target/verboten-0.0.1.SNAPSHOT.apk

appears to work.

When I look at the project in eclipse, (yes, I have installed lombok).  I get a bunch of compile errors about missing lombok.jar.  When I include lombok.jar on the project build path those errors go away, BUT when I try to run the app I get the error:

[2012-03-19 22:29:01 - verboten] The library 'lombok.jar' contains native libraries that will not run on the device.

[2012-03-19 22:29:01 - verboten] The following libraries were found:

[2012-03-19 22:29:01 - verboten]  - com/sun/jna/darwin/libjnidispatch.jnilib

[2012-03-19 22:29:01 - verboten]  - com/sun/jna/freebsd-amd64/libjnidispatch.so

[2012-03-19 22:29:01 - verboten]  - com/sun/jna/freebsd-i386/libjnidispatch.so

[2012-03-19 22:29:01 - verboten]  - com/sun/jna/linux-amd64/libjnidispatch.so

[2012-03-19 22:29:01 - verboten]  - com/sun/jna/linux-i386/libjnidispatch.so

[2012-03-19 22:29:01 - verboten]  - com/sun/jna/sunos-amd64/libjnidispatch.so

[2012-03-19 22:29:01 - verboten]  - com/sun/jna/sunos-sparc/libjnidispatch.so

[2012-03-19 22:29:01 - verboten]  - com/sun/jna/sunos-sparcv9/libjnidispatch.so

[2012-03-19 22:29:01 - verboten]  - com/sun/jna/sunos-x86/libjnidispatch.so

In eclipse if I replace lombok.jar with lombok-api.jar on the build path.  Then everything works in eclipse (including launching and debugging the app).

Using the api jar, the resulting apk from eclipse is ~1K larger than the one from maven.  This is (in my mind) a small price to pay for easier integration in my UI tools.

Hope that helps,

Matt 

On Mon, Mar 19, 2012 at 6:51 PM, Reinier Zwitserloot <rei...@zwitserloot.com> wrote:

Also, is your configuration broken in general (that would mean mvn from the command line runs into the same issue), or is it specifically the eclipse-maven plugin with android (in which case the mvn stuff off the command line would work fine but you run into errors on eclipse).

 --Reinier Zwitserloot

On Mon, Mar 19, 2012 at 23:50, Matt Fowles <matt....@gmail.com> wrote:

Reinier~

I will try again and report back.

Matt

On Mon, Mar 19, 2012 at 6:45 PM, Reinier Zwitserloot <rei...@zwitserloot.com> wrote:

That <scope>provided</scope> business is _very_ important.

 --Reinier Zwitserloot

[Reinier Zwitserloot]

Sounds like eclipse is incapable of understanding what <scope>provided</scope> means.

In that case, your current workaround (replacing lombok.jar with lombok-api.jar in eclipse) is the correct approach.

[Reinier Zwitserloot]

Okay, documentation updated to highlight the issues with eclipse+android+maven (the workaround: make lombok-api.jar and replace lombok.jar with that in your eclipse project). These changes will be officially available (and the website documentation will be updated at that time) with 0.10.10, although that release might end up being called 0.12.0, if @Accessors goes through.

[Fabrizio Giudici]

On Thu, 22 Mar 2012 16:49:47 +0100, Reinier Zwitserloot
<rein...@gmail.com> wrote:

> Sounds like eclipse is incapable of understanding what
> <scope>provided</scope> means.

Is this confirmed? It's really annoying, beyond Lombok/Android. For
instance, I was at last convinced that all my open stuff was buildable
with Eclipse too, but it seems I need to warn my Eclipse (potential)
followers.

[Reinier Zwitserloot]

No, this hasn't been confirmed yet. I'd love it if someone can also confirm that, indeed, eclipse is evidently incapable of understanding <scope>provided</scope>. We already have one report by Matt (thanks, Matt!). In the absence of others I'm assuming for now that eclipse indeed does not understand <scope>provided</scope>.

This isn't entirely out of left field; eclipse, at the project level and without the maven plugin, just has dependencies. There is no concept of build-only or runtime-only deps. You can add extra deps in a run target (which, thus, are effectively runtime-only deps), but there's no such workaround for build-only deps. There's factory path as a way to effectively have a build-only dep that works for Annotation Processors. The factory path is NOT available to the project itself.

That's why I'm strongly inclined to believe Matt: The eclipse maven plugin would have to hack the concept of build-only deps in from scratch in order to make <scope>provided</scope> work.

[Matt Fowles]

Reinier~

The issue with <scope>provided</scode> in eclipse is as follows:

A jar that is `provided` is NOT included in the compile classpath for eclipse.  It is also NOT put into the resultant package by eclipse (which is the correct behavior).

The workaround is to manually include in Eclipse suitable compile/runtime proxies (in this case the api jar).  The end result is that the compiled result in eclipse will include the api.jar and the compiled result at the command line will not.

Matt

--

You received this message because you are subscribed to the Google
Groups group for http://projectlombok.org/
 

To post to this group, send email to project...@googlegroups.com

To unsubscribe from this group, send email to

project-lombo...@googlegroups.com

[Moandji Ezana]

On Thu, Mar 22, 2012 at 7:51 PM, Matt Fowles <matt....@gmail.com> wrote:

A jar that is `provided` is NOT included in the compile classpath for eclipse

Are you sure about that? For web projects, the servlet-api jar is typically "provided" and is available in Eclipse at compile time. I haven't tried Lombok with Android, so the situation might be different.

Moandji

[Matthew Jaggard]

Moandji, the question is not about whether it's available at compile time, its whether it's available at runtime (it shouldn't be).

--

[Fabrizio Giudici]

On Sat, 24 Mar 2012 10:44:28 +0100, Matthew Jaggard
<mat...@jaggard.org.uk> wrote:

> Moandji, the question is not about whether it's available at compile
> time, its whether it's available at runtime (it shouldn't be).

The questioned statement is:

A jar that is `provided` is NOT included in the compile classpath for
eclipse

--

[Matt Fowles]

Moandji~

The other provided jar for android (android's own runtime).  Is supplied at compile time through a different mechanism to eclipse.  That jar is supplied through Eclipse's concept of a "library" (I didn't choose the name).  Interestingly (and thanks for the idea) if I create a user library for lombok.jar and include that in my project, then the resultant APK doesn't include the lombok jar and I don't need the lombok-api.jar in my project.

Perhaps, the correct answer for eclipse is to have the lombok.jar register itself as a Library (similar to JUnit, the builtin JRE, or the android runtime) when the installer goes.

Matt

--
You received this message because you are subscribed to the Google
Groups group for http://projectlombok.org/

To post to this group, send email to project-lombok@googlegroups.com

To unsubscribe from this group, send email to

project-lombok+unsubscribe@googlegroups.com

[Fabrizio Giudici]

On Sat, 24 Mar 2012 14:32:22 +0100, Matt Fowles <matt....@gmail.com>
wrote:

> Moandji~

>
> The other provided jar for android (android's own runtime). Is supplied
> at
> compile time through a different mechanism to eclipse. That jar is
> supplied through Eclipse's concept of a "library" (I didn't choose the
> name). Interestingly (and thanks for the idea) if I create a user
> library
> for lombok.jar and include that in my project, then the resultant APK
> doesn't include the lombok jar and I don't need the lombok-api.jar in my
> project.
>
> Perhaps, the correct answer for eclipse is to have the lombok.jar
> register
> itself as a Library (similar to JUnit, the builtin JRE, or the android
> runtime) when the installer goes.

So, in the end, if I understand well the Maven integration for Eclipse is
still far to be complete (not referring specifically to Android).

[Reinier Zwitserloot]

0.11.0 was just released, and it included the 'publicApi' workaround for lombok on eclipse for android.

Also includes a few other bugfixes and @Accessors :)