Page MenuHomeSolus

JDownloader
Closed, WontfixPublic

Description

Name: JDownloader
Homepage: https://jdownloader.org/
Open Source: yes
Source: https://aur.archlinux.org/cgit/aur.git/snapshot/jdownloader2.tar.gz

JDownloader is a free, open-source download management tool with a huge community of developers that makes downloading as easy and fast as it should be. Users can start, stop or pause downloads, set bandwith limitations, auto-extract archives and much more. It's an easy-to-extend framework that can save hours of your valuable time every day!

Event Timeline

chiraag created this task.Sep 23 2016, 6:39 PM
chiraag updated the task description. (Show Details)Sep 23 2016, 6:43 PM
  1. Site can't be reached.
  2. Source location isn't acceptable.
underskore added a subscriber: underskore.EditedSep 24 2016, 7:56 AM

The working URL is http://jdownloader.org/
Looks like the site where the sources should be is down.

chiraag updated the task description. (Show Details)Sep 24 2016, 8:41 AM
DataDrake closed this task as Wontfix.Sep 24 2016, 12:48 PM
DataDrake claimed this task.
DataDrake added a subscriber: DataDrake.

So, no source tarballs and the binary installer is linked from mega.nz. Even for Third-Party this doesn't meet our criteria. Not going in.

If you look here you can see the SVN, they're finished going fully source:

http://beta.jdownloader.org/developmentquicktutorial

@pandinusimp you linked outdated mirror, here is updated: https://github.com/mirror/jdownloader

DataDrake, can you reconsider given this it servers an important purpose without competition and the source is available? Also we should be building from the SVN they use, not the github repo

svn://svn.jdownloader.org/jdownloader/trunk

MoDzCatZ reopened this task as Open.Apr 18 2018, 9:59 PM

Is possible obtain the packtage ?

MoDzCatZ updated the task description. (Show Details)Apr 18 2018, 10:19 PM
MoDzCatZ updated the task description. (Show Details)Apr 18 2018, 10:23 PM
JoshStrobl closed this task as Wontfix.Apr 18 2018, 10:31 PM

"So, no source tarballs and the binary installer is linked from mega.nz. Even for Third-Party this doesn't meet our criteria. Not going in." as stated by @DataDrake. That Arch linux is not remotely valid.

JoshStrobl changed the edit policy from "All Users" to "Triage Team (Project)".Apr 18 2018, 10:31 PM

How do you want to attract people to your distribution if you do not wear this parquet which is more than necessary as a download manager?

ermo added a subscriber: ermo.EditedApr 19 2018, 9:36 AM

@JoshStrobl, @DataDrake:

If either of you have the time, could you perhaps share (some of) the thoughts behind the policy that makes you both reach for the big red NOPE! button here?

From my perspective, it appears as if the users requesting this package don't quite understand/appreciate the amount of hassle it would be to maintain this properly on their behalf?

(when I looked at the JDownloader dev wiki and the build steps involved, I looked for the NOPE! button too...)

EDIT: Holy crap that arch package looks kludgy! ⛔

I don't see an easy way for ypkg to automate the build from source for this...

@ermo - > "no source tarballs and the binary installer is linked from mega.nz"

@kyrios123 @JoshStrobl @DataDrake

As I said earlier and have messaged DataDrake about, the actual source is fully publicly available, and not in a tarball form. The person who submitted the original post for JDownloader2 linked to the wrong location. It's entirely hosted via SVN, and fully complies with all relevant packaging requirements for the distro.

It's factored into 3 SVN repos:
svn://svn.jdownloader.org/jdownloader/browser
svn://svn.jdownloader.org/jdownloader/trunk
svn://svn.jdownloader.org/jdownloader/MyJDownloaderClient

Guide to using and building from SVN repos:
http://jdownloader.org/knowledge/wiki/development/get-started

Given that this package does in fact comply with your inclusion guidelines, can the original request for this be amended and can the package be added as there's clearly legitimate demand?

@DataDrake Can you take a look at what I said above since you're around?

This does NOT comply with our inclusion guidelines:

  1. There are no tarballs to download and the are no SVN branches for tagged versions. Ergo, the only way to build this would be to make tarballs of specific SVN revisions. That is way more maintenance than I am willing to allow for a package in the repo.
  2. Even if 1 were no the case, this requires Eclipse be used for builds, which is a hard no as far as Java packages are concerned.

Both of these points are addressed by the following clause of this Package Inclusion Policy:

Certain requests may tick all the boxes, but introduce a level of complexity or require a level of engagement not possible to balance for the packaging team. Under certain situations, a request will be frozen until it has a dedicated maintainer.

In this particular case, due to the complexity and time necessary to double-check the work of even a dedicated maintainer, we have decided not to solicit maintainership.

Given that the upstream has provided an installer, surely there is a way to work around us not including this.