JNAerator Maven Pom Relies on org.eclipse.jdt

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Try to compile a maven artifact with a dependency on jnaerator runtime

What is the expected output? What do you see instead?

Error from unresolved depenency.

What version of the product are you using? On what operating system?

0.9.4

Is the problem still present in the latest SVN version ? (you can easily
build from sources with these instructions : yes.

Please provide any additional information below.

In general providing dependencies on artifacts which aren't commonly packaged 
as pom files is poor form. It makes the artifact difficult to use, and is 
unreliable because transitive dependencies aren't resolved properly when the 
artifact is resolved by hand.

I would recommend using maven 3 and tycho for this. If there's no opposition to 
using maven 3 I'd be happy to spend some time hacking on the pom to get this 
working better.

Original issue reported on code.google.com by ekohl...@gmail.com on 24 Aug 2010 at 9:30

[GoogleCodeExporter]

Hello,

While the com.jnaerator:jnaerator:0.9.4 artifact indeed relies on some bad ecj 
distribution, this is not the "runtime" artifact.

Have you tried using that one (ecj-free):
com.jnaerator:jnaerator-runtime:0.9.4

Anyway, I know I shouldn't have packaged ecj by my own, that was nasty... But 
what do you think of this seemingly commonly packaged artifact :
http://mvnrepository.com/artifact/org.eclipse.jdt.core.compiler/ecj

(I've just updated jnaerator's latest svn version's pom with it)

Anyway, I don't know about Tycho but I would certainly welcome some help with 
maven 2 / 3... or buildr / sbt for that matter, since Maven is soooo slow :-(

Cheers

Original comment by olivier.chafik@gmail.com on 25 Aug 2010 at 6:35

[GoogleCodeExporter]

As for the issue with the com.jnaerator:jnaerator:0.9.4 artifact, I've uploaded 
the missing ecj home-made artifact to nativelibs4java's repository. FYI I've 
had issues with that repo, which I had to reset (loosing many "precious 
artifacts" :-( )

But again, for the runtime you should rather use 
com.jnaerator:jnaerator-runtime:0.9.4 artifact.

Cheers

Original comment by olivier.chafik@gmail.com on 25 Aug 2010 at 6:48

• Changed state: Fixed

[GoogleCodeExporter]

Hi, thanks for uploading the artifact. The issue was actually that the 
jnaerator maven plugin depends on the jnaerator artifact, so you can't use 
maven to generate sources.

A few notes:

1. I didn't realize this is something being packaged commonly. If thats the 
case, is there a reason not to simply use the ECJ packaged in central? It makes 
your repository a bit messy to have artifacts which you're not actually 
managing. 

2. As far as maven vs other build systems goes, I think there's not much you 
can do about it. Maven sacrifices some of its own speed to make tasks that a 
developer does faster (like building and resolving a dependency graph). While 
there's room for some speed improvements (apparently maven 3 is 50-400% 
faster), there's a fundamental trade-off that exists there. Ivy, for instance, 
makes ant builds slow as molasses too.

3. Tycho is a maven plugin that generates maven metadata for OSGi artifacts and 
can resolve OSGi dependencies through p2 repositories. If you depend on other 
OSGi artifacts in the future this might be a better approach.

Original comment by ekohl...@gmail.com on 25 Aug 2010 at 11:40

[GoogleCodeExporter]

Hi again,

The fact that maven-jnaerator-plugin depends on jnaerator does not preclude 
users from generating sources, as the plugin correctly adds the generated 
sources to the list of Java sources to compile. The plugin is used for instance 
by the Mono4Java and OpenCL4Java projects (using the jnaerator:jnaerate goal). 
Maybe I didn't get what you mean...

1. -> As I said, I've just updated jnaerator to use this artifact 
(http://code.google.com/p/nativelibs4java/source/diff?spec=svn1176&r=1176&format
=side&path=/trunk/libraries/jnaerator/jnaerator/pom.xml), but this will only 
affect versions 0.9.5-SNAPSHOT and later (won't change 0.9.4).

2. -> Buildr seems to offer continuous compilation. It also removes the need to 
pre-package dependencies as poms (you can give it a JAR URL and have it install 
it into your local repository in one or two lines).
The real issue here is that Maven does not do build and downloads in parallel 
until version 3, and version 3 seemed buggy last time I tried (but beta 2 looks 
okay today :-) ).

3. -> Still haven't caught the OSGi train, but I believe I'll have to learn 
about it... (maybe BridJ could benefit from being OSGi-zed... ?)

Cheers

Original comment by olivier.chafik@gmail.com on 25 Aug 2010 at 11:55