Unify with RPM plugin

would be great if you could unify with rmp plugin as much as possible
http://mojo.codehaus.org/rpm-maven-plugin/example1.html
so there is no need to call same things by different names

[tcurdt]

maybe an inspiration for the next major release - but no promisses

cool!

I would prefer that you looked at Red Line RPM Java Library instead of the one carrot-garden suggested.

[hapylestat]

nope, "Red Line RPM Java Library" is not so powerful like one from mojo and is not compatible with full-set of possible jdeb configuration possibilities.As result i disagree gouessej suggestion, but like carrot-garden one 👍

@hapylestat Which features of jdeb aren't supported by Red Line RPM Java Library? Does rpm-maven-plugin support support them all? Why do you claim that the one from mojo is more powerful? I suggested to look at Red Line RPM Java Library because it is probably one of the most used library to create RPMs in Java, it doesn't rely on native build tools and it can make source RPMs unlike rpm-maven-plugin:
"source RPMs can not be generated"
http://mojo.codehaus.org/rpm-maven-plugin/index.html

Moreover, Red Line RPM Java Library can be used without Maven. Some jdeb users don't want or can't use Maven because it is too much rigid for certain kinds of projects. Maven support is still a nice thing to have anyway but if it becomes mandatory in jdeb 2.0, I'll switch to jpkg:
https://github.com/leplastrier/jpkg-library

[tcurdt]

@gouessej jdeb will never go maven only. Rather will it support gradle and friends, too. Under the hood it's already abstracted and if anyone wanted to he/she could add support for other build systems, too - today. jdeb just happens to have more maven contributors. Which let to a few more features on that side.

The plan for 2.0 is to clean up the code base, make some usecases easier and get features in line for all supported build systems. Feature requests and suggestion are much welcome.

This gist https://gist.github.com/tcurdt/9275523 is the starting point.

[muuki88]

This is an interesting point. I'm a commiter on the sbt-native-packager project. I use jdeb for my maven projects and really like it. Sbt-native-packager relies on native build tools, which is nice in the first place as you have every feature. However colleges with windows are screwed.

If you abstract away the api in a separate project ( like jgit ) and plugins have there own projects, it would be easy to use jdeb as the building core.

[tcurdt]

jdeb is that core (plus a maven and an ant plugin alongside). we could separate those plugins out but it seemed easier to handle them in one repo.

[muuki88]

Yeah, that's true. If you add jdeb as a normal library dependency the maven/ant stuff just stays unused.

For API docs the build plugins are the first place to look, or are there written docs on how to use the Java API?

[tcurdt]

Sorry, no docs beside the javadocs. But I would check out how the DebMojo assembles the producers and passes them to the DebMaker.

https://github.com/tcurdt/jdeb/blob/master/src/main/java/org/vafer/jdeb/maven/DebMojo.java#L503

[hapylestat]

@gouessej general problem is that Redline is only Java oriented plugin. I'm interesting not only in building of java rpm's, additionally i need to be able to create custom configuration to build rpm's for non-java modules. And that redline can't do.

jpkg-library - this library look like unsupported one(last commit was a year ago), so it's a dangerous to use it in production. Yes, u can use it for some "home" thinks but it's all.

I will stick to MojoRPM and jDeb as they realize all functionality which i need.

@hapylestat Actually, Redline can be used for non-java modules but I'm not sure it is the best tool to do that to be honest. jpkg-library has no community and the project doesn't seem very active anyway, I'll probably stick to jdeb.