jdeb 2.0

[tcurdt]

Generate the package meta data

This should be based on build system inputs. This could look like this for `maven':

<control>
  <package>(default from pom)</package>
  <version>(default from pom)</version>
  <section>(default 'misc')</section>
  <priority>(default 'low')</priority>
  <architecture>(default 'all')</architecture>
  <maintainer>(default from pom)</maintainer>

  <pre-inst src="${basedir}/someshell.sh"/>
  <pre-rm src="${basedir}/someshell.sh"/>
  <post-inst src="${basedir}/someshell.sh"/>
  <post-rm src="${basedir}/someshell.sh"/>
</control>

and for ant:

<control>
  <package>(no default)</package>
  <version>(no default)</version>
  <section>(default 'misc')</section>
  <priority>(default 'low')</priority>
  <architecture>(default 'all')</architecture>
  <maintainer>(no default)</maintainer>

  <pre-inst src="${basedir}/someshell.sh"/>
  <pre-rm src="${basedir}/someshell.sh"/>
  <post-inst src="${basedir}/someshell.sh"/>
  <post-rm src="${basedir}/someshell.sh"/>
</control>

Of course we could us attributes for ant instead. While that makes things more ant like it does not make things much easier to read IMO. Maybe we could allow both - not sure how I feel about supporting both though. MIght be more confusing than it helps.

Inline data configurations

We could use explicit nesting to define the virtual file system properties inside a debian archive tree. We would then map it to the sources. Here attributes would cut down the verboseness immensely. Unfortunately maven still doesn't support this. Which could be a point for a custom descriptor. For now the proposal looks like this:

<!-- defaults:
  dir:  own=root:root mod=750
  file: own=root:root mod=640 filter=no compress=no
-->
<data>
  <dir>
    <dir>
      <name>usr</name>
      <own>root:root</own>
      <mod>755</mod>

      <dir>
        <name>bin</bin>
        <file>
          <name>test</test>
          <own>root:root</own>
          <mod>755</mod>
          <src>${basedir}/someshell.sh</src>
          <filter>yes|no</filter>
        </file>
        <file>
          <name>test-as-link</test>
          <own>root:root</own>
          <mod>755</mod>
          <type>symbolic</type>
          <target>test</target>
        </file>
      </dir>

      <dir>
        <name>lib</bin>
        <file>
          <name>${project.build.finalName}.jar</test>
          <mod>755</mod>
          <src>${project.build.directory}/${project.build.finalName}.jar</src>
        </file>
        <file>
          <name>${project.build.finalName}.man.gz</test>
          <mod>755</mod>
          <src>somepath</src>
          <compress>gzip</compress>
        </file>
      </dir>

      <dir>
        <name>doc</bin>
        <src>${basedir}/docs</src>
        <own>auto</own>
        <mod>auto</mod>

        <dir>
          <name>examples</bin>
          <src>${basedir}/examples.tgz</src>
          <own>auto</own>
          <mod>auto</mod>
        </dir>
    </dir>
  </dir>
</data>

In ant we could use filesets to provide the be src of dir elements. To make the the mapping less verbose we could use pattern matching to define default values to specify owner, permissions and so on - or fall back to the defaults or the permissions (since java7) on disk. I assume this would break cross platform buildability though. (Could a windows user confirm?)

Question is whether we need this to be a little more dynamic and allow for generating sub trees base on some kind "generator".

<data id="root">
  <dir>
    <each>
      <id>item</id>
    </each>

<data id="item">
  <dir>
    <dir>
      <name>...</name>

But is that really needed? One could also just prepare the dir on disk like before and then just map the dir and apply patterns for permissions. For now I would omit this.

Based on the old gist https://gist.github.com/tcurdt/9275523

[Ordiel]

Would it be posible to create multiple deb packages? i.e. the same application configured for multiple clients?, i was wondering if it is possible to do that with the current version and I have not found enough info about it, I tried adding multiple packages in the control file but it only generates one pkg at the end

[ebourg]

For this level of customization I would recommend using the Ant task combined with the maven-antrun-plugin.

[tcurdt]

This issue is basically the wish list for jdeb2 - but I yet have to understand the need for multiple packages better. That said this is probably more a maven question as maven only really creates one artifact. As @ebourg already suggested - for example ant can call jdeb multiple times.

[dbyron0]

I'm motivated to have the timestamp in convertToDebianVersion be in UTC. Not sure this is a big enough thing by itself to wait for 2.0, though it is an interface change in one way of looking at it.

Also curious if there's a reason to move to java 8, or maybe better...a reason to stick with 6.

[tcurdt]

@dbyron0 plenty of good reasons to move beyond java 6 (one is access to file permissions)

[ebourg]

+1 for Java 7

[tcurdt]

For convertToDebianVersion in UTC we would need to clarify the consequences. I could possibly see that land in a pre-2 version.

[dbyron0]

Hmmm, how can I help clarify the consequences? I'm hoping we can end up using the same format (yyyyMMddHHmmss), so the only consequence to the user would be the switch to UTC. Not quite sure the best way to implement it in java 6 though off the top of my head. A java 8 way (or I suppose a joda time way with java 6) might involve changing the timestamp argument from a Date to an Instant.

[tcurdt]

@dbyron0 The implementation should not be the problem - but those are not the consequences. This is about consequences of people upgrading. They would appear to experience a time-shift and question is whether that can be a problem for them or not. But this is getting too detailed in the wrong issue. Please open a new issue for that.

[dbyron0]

created https://github.com/tcurdt/jdeb/issues/238

[Sami32]

The great enhancement will be to have the control informations able to be set without having to create a file sperately, using an other plugin or creating it manually. It is definitively an important missing feature in that pluging.

An alternative approach to the rules implementation that i suggested in https://github.com/tcurdt/jdeb/issues/275 is to implement a permission set:

<permissionSets>
  <!-- <gid> and <uid> -->
  <permissionSet>
    <includes>
      <include>**/plugins/**</include>
      <include>**/renderers/**</include>
      <include>**/examples/**</include>
    </includes>
    <fileMode>0666</fileMode>
  </permissionSet>
  <permissionSet>
    <includes>
      <include>**/*.sh</include>
    </includes>
    <fileMode>0755</fileMode>
  </permissionSet>
</permissionSets>

More limited but very handy as it make the configuration shorter and more simple to implement IMO.

That was my 2 cents.

[brianhks]

I'm looking at this from a different perspective. I would like to see the api a little easier to use. I've been using RedlineRPM (https://github.com/craigwblake/redline) to build RPM files and the api is very easy to use. It would be nice if you had a builder api similar for people who want to integrate it into projects. Just a thought for 2.0.

[tcurdt]

@brianhks I very much agree on the easier API part. Thanks!

I honestly start to believe the building of a virtual directory tree would even make sense as its own library.

That said: It used to be that my work was allowing me to spend the time. That's no longer the case. Given the lack of contributions and me just mostly maintaining jdeb, I am sceptical 2.0 will ever happen without sponsors.

[aalmiray]

Would be great to split the source into 3 distinct modules if possible:

• core
• maven-plugin
• ant-tasks

As it currently stands both Maven and Ant are explicit dependencies.

[tcurdt]

Totally agree @aalmiray

[aalmiray]

I could figure out a way to make the split. My concern would be that each module will have a unique artifactId that should not clash with the existing jdeb. Given that the current version is se to 1.10 and this would constitute a breaking change I'd like to know what are your thoughts on this.

Would it make sense to push for a module split in 1.x, perhaps making the next release 1.11[.0]?

[tcurdt]

TBH I would not split the current code base as such.

I would start with a 2.0 that is split. And then I would port functionalities over. That said I don't think 2.0 should be a 1:1 replacement. So much cruft and so much learned over the years.

Is it just the dependency that bothers you? I am wondering if we could instead mark those deps as provided as another simpler first step. In the end we just really need them for the build and then the runtime could provide them.

[aalmiray]

I see. As long as the "core" is independent from Maven and Ant APIs I can simply consume it by excluding both Maven and Ant. That's OK.

Marking them as provided wouldn't be enough as they will still be transitively required for building in the consumer's side. provided + optional would be the ticket as that marks them as "compile only".

[aalmiray]

@tcurdt FWIW Ant is still a required dependency due to some utility classes. In my case I need no filtering 😞

Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/filters/FixCrLfFilter
	at org.vafer.jdeb.utils.FilteredFile.parse(FilteredFile.java:49)
	at org.vafer.jdeb.utils.FilteredFile.<init>(FilteredFile.java:33)
	at org.vafer.jdeb.ControlBuilder.createPackageControlFile(ControlBuilder.java:182)
	at org.vafer.jdeb.DebMaker.createSignedDeb(DebMaker.java:505)
	at org.vafer.jdeb.DebMaker.createDeb(DebMaker.java:472)
	at org.vafer.jdeb.DebMaker.makeDeb(DebMaker.java:347)
	at org.jreleaser.assemblers.DebAssemblerProcessor.doAssemble(DebAssemblerProcessor.java:151)

[tcurdt]

That is a little unfortunate. But as a quick fix this could easily be solved by shading. That's already setup anyway.

[aalmiray]

Technically yes, but it would mean still carrying the whole of Ant for just a few classes. Have to think more about this.

[tcurdt]

Technically yes, but it would mean still carrying the whole of Ant for just a few classes. Have to think more about this.

Nope. This is the important bit:

https://github.com/tcurdt/jdeb/blob/master/pom.xml#L323

This way only used classes get included in the shade.