Publish normal jar, not maven-plugin

[hvesalai]

Hi, I would much like to hear why you have chosen to use the maven-plugin packaging instead of the default? The packaging format is causing problems for my project and I'm considering forking the project to publish it as a normal jar. Any reason I shouldn't do this?

[saudet]

Because the BuildMojo class is a maven-plugin. This is only an issue with sbt, right? You could use sbt-javacpp I think. Is there a problem with sbt-javacpp as well?

[hvesalai]

No, the problem is that the ivy generated from our project has

                <dependency org="org.bytedeco" name="javacpp" rev="1.2.2" conf="compile->default(compile)">
                        <exclude org="commons-logging" module="*" name="*" type="*" ext="*" conf="" matcher="exact"/>
                </dependency>

This means that our downstream projects do not know how to handle it and so they don't know how to include the javacpp classes on the runtime classpath.

[hvesalai]

Back to the original point: wouldn't the proper way of releasing javacpp then be for the core to be in one "core" package and the maven-plugin stuff an other package depending on the core?

Then all non-maven projects could use the core directly skipping the maven stuff.

[saudet]

Why do we need to depend on javacpp (or any other "maven-plugin") that way with Ivy? We can't do it the normal? Is this a known limitation of Ivy? This doesn't happen with any of the other build systems that I know of (sbt, Gradle, Maven, etc)

[hvesalai]

Our code uses the javacpp classes at runtime, not just compile time. Hence it is not enought that the build tool understands how to include it. Also all downstream projects need to understand that the jar needs to be included on the runtime classpath.

[saudet]

Yes, I understand that and it works fine on any other build system at runtime. So this is why I would like to know if this is a limitation of Ivy.

[hvesalai]

Yes, it is definitely ivy-related and I am investigating if there is something I can do to ivy to make it understand this.

But I still think the root cause is the wrong javacpp packaging. I don't understand why a maven-plugin type package is needed at runtime. Shouldn't maven plugins be sometihng only maven related code that are only used by maven at compile-time, not by other applications at runtime.

[saudet]

Yeah, it's kind of annoying having to create a project just for 1 file, but with all those buggy build systems out there, we have to compromise...

[hvesalai]

While I still think that this project should publish the core classes as a normal jar (instead of the current fat maven-plugin), I found a workaround for sbt and ivy.

The workaround for sbt is described here: bytedeco/sbt-javacpp#5

The workaround for ivy is to reference the jar artifact explicitly:

<dependency org="org.bytedeco" name="javacpp" rev="1.2.2"  conf="compile->default(compile)">
  <artifact name="javacpp" type="jar" ext="jar" conf="*"/>
</dependency>

[saudet]

I think that's what I'll do for the next release, yes. And while we're at it, I'm thinking of creating a parent pom.xml file that would contain the otherwise duplicated info, but unsure how to go about it yet...

[saudet]

Actually it still seems possible to create a Maven plugin with the jar packaging type! I've made the changes in the latest commit. Let me know if that looks good.

[hvesalai]

Looks good!

One note (not a problem though):

JavaCV has explicit <packaging>jar</packaging>, where as JavaCPP declares no packaging (so defaults to jar).

[saudet]

Great!

Yes, getting rid of that as well. I'm planning on going with what's in the "platform" branches...

[saudet]

Fix is in JavaCPP 1.2.3. Thanks for reporting!