JDownloader Community - Appwork GmbH
 

Reply
 
Thread Tools Display Modes
  #1  
Old 24.08.2019, 11:47
darkdragon-001 darkdragon-001 is offline
JD Alpha
 
Join Date: Sep 2018
Posts: 20
Default Debian installer

Install4J supports creation of Debian installer (.deb). Could you please generate such an installer to facilitate installation on Linux?
Reply With Quote
  #2  
Old 24.08.2019, 14:25
raztoki's Avatar
raztoki raztoki is offline
English Supporter
 
Join Date: Apr 2010
Location: Australia
Posts: 16,191
Default

linux does have a installer with bash script. but deb package would make it more idiot proof or should I say user friendly =]
__________________
raztoki @ jDownloader reporter/developer
http://svn.jdownloader.org/users/170

Don't fight the system, use it to your advantage. :]
Reply With Quote
  #3  
Old 26.08.2019, 17:23
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 65,289
Default

We don't have deb package at the moment and I don't think that a install4j deb variant would be good because the standalone installer is *standalone* while I think a deb package should make use the package system and make use of it to install/use java while the *standalone* installer comes with bundled java.

I would prefer to have a native deb package that tells to hava java installed and then just downloads the files from server
and installs them to the right places and installs links to startmenu. Help on creating such a deb package is welcome but I really don't think
that install4j is the right choice for it
__________________
JD-Dev & Server-Admin
Reply With Quote
  #4  
Old 26.08.2019, 21:57
darkdragon-001 darkdragon-001 is offline
JD Alpha
 
Join Date: Sep 2018
Posts: 20
Default

First of all, make sure JD2 is compatible with latest OpenJDK11 which is default on latest OSes. When I tried to run with Java11, I got the following warning:

Quote:
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.appwork.shutdown.ShutdownController (file:/home/USER/jd2/JDownloader.jar) to field java.lang.ApplicationShutdownHooks.hooks
WARNING: Please consider reporting this to the maintainers of org.appwork.shutdown.ShutdownController
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
---

Install4j automatically searches for system java versions. So maybe adding an option in the installer not to install the bundled java version would be a good start.
Further, java version requirements should be relaxed (currently only 1.6 to 2.0).

---

I don't know too much about java build systems nor how your source files need to be assembled together.
General debian packaging is quite straight-forward though:

1. Put all source files in a folder jd2-0.1 (where 0.1 is the version)
2. Create upstream source package: tar czvf jd2-0.1.tar.gz jd2-0.1
3. Run debmake in jd2-0.1 to create a sample "debian" folder
4. Depending on your build system, follow the Javahelper **External links are only visible to Support Staff**guide (Ant, Maven, Gradle) and **External links are only visible to Support Staff**tutorial (no build system; scroll to the end for examples)
5. Build and package via "debuild -b --no-sign"

---

Further, I think the (debian) installer should not download source files, but instead every update should just create a new version. Since hoster-plugins change very often, they should be packaged separately (single SOURCE, multiple PACKAGE in control: **External links are only visible to Support Staff****External links are only visible to Support Staff**).

Last edited by darkdragon-001; 26.08.2019 at 22:39.
Reply With Quote
  #5  
Old 27.08.2019, 16:01
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 65,289
Default

JDownloader is compatible with Java 1.6 up to Java 14. Those warnings are normal as some *workarounds*/*tricks* we make use of, no longer work/are compatible with newer Java versions.
__________________
JD-Dev & Server-Admin
Reply With Quote
  #6  
Old 27.08.2019, 16:08
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 65,289
Default

I'm sorry but in case we provide a deb package, it will be very similiar to current installation process. It will contain the start/neccessary parts that are required for self update of JDownloader that finally installs the correct version for current OS/OS-bitness/CPU/CPU-bitness/evironment.

We won't have a 2nd deployment system in parallel use. Deb packages don't support incremental updates/background updates. JDownloader supports nearly 8 thousand different sites and heavily depends on an update system that supports those features. It's not feasible to have several thousand deb packages to reduce update traffic and packaging plugins into one big deb will require vast amounts of traffic
__________________
JD-Dev & Server-Admin
Reply With Quote
  #7  
Old 27.08.2019, 16:14
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 65,289
Default

Quote:
Originally Posted by darkdragon-001 View Post
Install4j automatically searches for system java versions. So maybe adding an option in the installer not to install the bundled java version would be a good start.
The current install4j installer already requires Java to run as we make heavily use of it. Reusing system java fails when it's different bitness. Can't use 32bit system java on 64bit executable and vice versa. Most Win/Mac systems don't have java installed in system.

Once we rebuild/work on installers, we will provide installers that bundle java and versions that make use of system java if available or download if required.
__________________
JD-Dev & Server-Admin
Reply With Quote
  #8  
Old 28.08.2019, 21:01
darkdragon-001 darkdragon-001 is offline
JD Alpha
 
Join Date: Sep 2018
Posts: 20
Default

Quote:
Originally Posted by Jiaz View Post
Once we rebuild/work on installers, we will provide installers that bundle java and versions that make use of system java if available or download if required.
Looking forward to this!

---

If you tell me how your JDownloader.jar installer is built, I could help you with the package.
Reply With Quote
  #9  
Old 29.08.2019, 17:18
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 65,289
Default

@darkdragon-001: I don't see why the *how* is important? JDownloader.jar is build via ant script

Feel free to contact me in chat (irc, freenode, #jdteam) or via support@jdownloader.org if you have questions/want to talk about this.
__________________
JD-Dev & Server-Admin
Reply With Quote
  #10  
Old 29.08.2019, 20:13
darkdragon-001 darkdragon-001 is offline
JD Alpha
 
Join Date: Sep 2018
Posts: 20
Default

Source packages are preferred over binary packages. Therefor building the jar as part of the packaging process would be better. This also allows rebuilds for new distribution versions etc.

Is it possible to tell the jar that it should use a different working directory?
Debian packages will install e.g. in /etc/share/jdownloader2 where root access is required. So updating needs root, while running the application should not be done as root! So telling the jar, to download/update files in the user's home folder ~/.jdownloader2 would be recommended.
Reply With Quote
  #11  
Old 30.08.2019, 11:27
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 65,289
Default

Quote:
Originally Posted by darkdragon-001 View Post
Source packages are preferred over binary packages. Therefor building the jar as part of the packaging process would be better.
I'm sorry but that's not possible. For example the update system is not part of the open source. Doesn't make any sense in connecting a self/3rd party compiled version
to the official release. Also there are non open source parts like key material.

Quote:
Originally Posted by darkdragon-001 View Post
Is it possible to tell the jar that it should use a different working directory?
So telling the jar, to download/update files in the user's home folder ~/.jdownloader2 would be recommended.
That's not possible/supported and there are not plans to change this.
JDownloader is supporting many different OS/CPU.. and we don't do special stuff for each combination.
JDownloader works exactly the same on every OS/CPU.... Each user must have it's own installation
__________________
JD-Dev & Server-Admin
Reply With Quote
  #12  
Old 30.08.2019, 11:34
darkdragon-001 darkdragon-001 is offline
JD Alpha
 
Join Date: Sep 2018
Posts: 20
Default

Quote:
I'm sorry but that's not possible. For example the update system is not part of the open source. Doesn't make any sense in connecting a self/3rd party compiled version
to the official release. Also there are non open source parts like key material.
You are not completely open source?
If no working version of JDownloader can be built using the published source code, then your statements about an open source download manager are misleading!

Quote:
That's not possible/supported and there are not plans to change this.
JDownloader is supporting many different OS/CPU.. and we don't do special stuff for each combination.
JDownloader works exactly the same on every OS/CPU.... Each user must have it's own installation
I thought having a single system JDownloader.jar and having all other file installed for the user might work. If there is no constant component, then creating a Debian package is not possible.

Last edited by darkdragon-001; 30.08.2019 at 11:38.
Reply With Quote
  #13  
Old 30.08.2019, 11:41
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 65,289
Default

Quote:
Originally Posted by darkdragon-001 View Post
I thought having a single system JDownloader.jar and having all other file installed for the user might work. If there is no constant component, then creating a Debian package is not possible.
JDownloader.jar itself only contains mainly the update client and base dependencies. That's why it is enough to have this file to install/fix a JDownloader installation. The client first updates itself (JDownloader.jar) and then installs/updates JDownloader.

Quote:
Originally Posted by darkdragon-001 View Post
if there is no constant component, then creating a Debian package is not possible.
I agree and I really would prefer an updated Install4J installer for GUI users and maybe sort of installation/helper script for headless/server users.
__________________
JD-Dev & Server-Admin
Reply With Quote
  #14  
Old 30.08.2019, 11:42
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 65,289
Default

Quote:
Originally Posted by darkdragon-001 View Post
If no working version of JDownloader can be built using the published source code, then your statements about an open source download manager are misleading!
That's not what I wrote. The non closed source parts are not required to build/run JDownloader.
__________________
JD-Dev & Server-Admin

Last edited by Jiaz; 30.08.2019 at 11:52.
Reply With Quote
  #15  
Old 30.08.2019, 11:59
darkdragon-001 darkdragon-001 is offline
JD Alpha
 
Join Date: Sep 2018
Posts: 20
Default

Quote:
Originally Posted by Jiaz View Post
The client first updates itself (JDownloader.jar) and then installs/updates JDownloader.

I agree and I really would prefer an updated Install4J installer for GUI users and maybe sort of installation/helper script for headless/server users.
Adding run arguments to only update and not start JDownloader would allow creating such an installation/helper script as discussed here.
Reply With Quote
  #16  
Old 30.08.2019, 12:03
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 65,289
Default

Quote:
Originally Posted by darkdragon-001 View Post
Adding run arguments to only update and not start JDownloader would allow creating such an installation/helper script as discussed here.
I completely agree on this and it makes indeed perfect sense to have such a *install/setup* parameter available. Maybe even one step further to specify sort of *setup configuration* and then read *install to*, *basic setup information like download folder...* and *username/password*. such a file can be genrated by script/tools then and makes it much easier to install JDownloader in headless/docker/xy environments
__________________
JD-Dev & Server-Admin
Reply With Quote
  #17  
Old 30.08.2019, 12:04
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 65,289
Default

btw, feel free to join chat (irc, freenode, #jdteam) if oyu want to talk about this in live
__________________
JD-Dev & Server-Admin
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT +2. The time now is 13:23.
Provided By AppWork GmbH | Privacy | Imprint
Parts of the Design are used from Kirsch designed by Andrew & Austin
Powered by vBulletin® Version 3.8.10 Beta 1
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.