jdeb 2.0 #195

tcurdt · 2015-02-15T16:40:26Z

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

The text was updated successfully, but these errors were encountered:

Ordiel · 2015-12-18T19:59:18Z

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 · 2015-12-18T20:29:50Z

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

tcurdt · 2015-12-18T20:40:20Z

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 · 2016-05-18T16:44:04Z

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 · 2016-05-19T14:55:57Z

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

ebourg · 2016-05-19T14:57:18Z

+1 for Java 7

tcurdt · 2016-05-19T14:58:36Z

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

dbyron0 · 2016-05-20T02:06:13Z

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 · 2016-05-20T08:17:29Z

@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 · 2016-05-20T19:51:09Z

created #238

Sami32 · 2018-08-28T12:58:58Z

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 #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 · 2023-01-09T03:27:51Z

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 · 2023-01-09T08:58:18Z

@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 · 2023-03-06T20:59:45Z

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 · 2023-03-06T21:13:59Z

Totally agree @aalmiray

aalmiray · 2023-03-06T21:28:32Z

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 · 2023-03-06T21:59:42Z

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 · 2023-03-06T22:03:56Z

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 · 2023-03-07T16:57:20Z

@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 · 2023-03-07T17:06:01Z

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

aalmiray · 2023-03-07T17:08:05Z

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

tcurdt · 2023-03-07T17:14:33Z

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.

tcurdt · 2024-03-02T14:43:08Z

I still think this would be nice. But I don't have the time or need to put effort into this. There is no one sponsoring this.
So unless someone else steps up I don't think 2.0 will see the day of light.
Closing for now.

tcurdt added improvement waiting for feedback labels Feb 15, 2015

tcurdt added this to the 2.0 milestone Feb 15, 2015

tcurdt mentioned this issue Feb 21, 2015

Add support for boot script #197

Open

tcurdt mentioned this issue May 29, 2015

Depends field should be left empty if a package depends on no other #208

Closed

tcurdt mentioned this issue Nov 23, 2015

Possible issue with different encodes #155

Closed

tcurdt mentioned this issue Jan 24, 2016

investigate switching the build to gradle #228

Closed

dbyron0 mentioned this issue May 20, 2016

use UTC for timestamp in convertToDebianVersion #238

Closed

tcurdt mentioned this issue Aug 28, 2018

Suggestion: implement "rules" #275

Open

tcurdt closed this as completed Mar 2, 2024

Repository owner deleted a comment from Gemrav Apr 5, 2024

Repository owner deleted a comment from Gececi665 Jul 15, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

jdeb 2.0 #195

jdeb 2.0 #195

tcurdt commented Feb 15, 2015

Ordiel commented Dec 18, 2015

ebourg commented Dec 18, 2015

tcurdt commented Dec 18, 2015

dbyron0 commented May 18, 2016

tcurdt commented May 19, 2016

ebourg commented May 19, 2016

tcurdt commented May 19, 2016

dbyron0 commented May 20, 2016

tcurdt commented May 20, 2016

dbyron0 commented May 20, 2016

Sami32 commented Aug 28, 2018 •

edited

Loading

brianhks commented Jan 9, 2023

tcurdt commented Jan 9, 2023

aalmiray commented Mar 6, 2023

tcurdt commented Mar 6, 2023

aalmiray commented Mar 6, 2023 •

edited

Loading

tcurdt commented Mar 6, 2023

aalmiray commented Mar 6, 2023

aalmiray commented Mar 7, 2023

tcurdt commented Mar 7, 2023 •

edited

Loading

aalmiray commented Mar 7, 2023

tcurdt commented Mar 7, 2023

tcurdt commented Mar 2, 2024

jdeb 2.0 #195

jdeb 2.0 #195

Comments

tcurdt commented Feb 15, 2015

Generate the package meta data

Inline data configurations

Ordiel commented Dec 18, 2015

ebourg commented Dec 18, 2015

tcurdt commented Dec 18, 2015

dbyron0 commented May 18, 2016

tcurdt commented May 19, 2016

ebourg commented May 19, 2016

tcurdt commented May 19, 2016

dbyron0 commented May 20, 2016

tcurdt commented May 20, 2016

dbyron0 commented May 20, 2016

Sami32 commented Aug 28, 2018 • edited Loading

brianhks commented Jan 9, 2023

tcurdt commented Jan 9, 2023

aalmiray commented Mar 6, 2023

tcurdt commented Mar 6, 2023

aalmiray commented Mar 6, 2023 • edited Loading

tcurdt commented Mar 6, 2023

aalmiray commented Mar 6, 2023

aalmiray commented Mar 7, 2023

tcurdt commented Mar 7, 2023 • edited Loading

aalmiray commented Mar 7, 2023

tcurdt commented Mar 7, 2023

tcurdt commented Mar 2, 2024

Sami32 commented Aug 28, 2018 •

edited

Loading

aalmiray commented Mar 6, 2023 •

edited

Loading

tcurdt commented Mar 7, 2023 •

edited

Loading