Look for useful changes on other forks

[beothorn]

Because the main project is unmaintained there is a lot of fragmentation.
Lots of forks with different improvements https://github.com/edmund-wagner/junrar/network/members
It would be nice to scan them and reproduce improvements on this fork.

[beothorn]

Some interesting changes

geometer/junrar@c44496d

awaters1@28be41d

https://github.com/NitroXenon/JUnRAR

https://github.com/Cheetozz/junrar

https://github.com/sseide/junrar/commit/5ccda759d68a8f5c489fb20e1a7bfa49f66d82f7

vaemendis@28663a4 (some interesting but difficult to assess changes, see below)

koroshiya/junrar@06bdd47 (is being looked at in #40)

https://github.com/phax/junrar/commits/master (some interesting but difficult to assess changes, see below)

vsubhash/junrar@9831bed

https://github.com/DarkSupremo/junrar/commits/master

https://github.com/RDamman/junrar/commits/master (some interesting but difficult to assess changes, see below)

[befora]

geometer/junrar@c44496d

This commit is extremely more performant on Android. PipedInputStream just doesn't work that well for us.

[rednoah]

Adding META-INF/vfs-providers.xml to the JAR would be nice as well, so vfs2 can find the RAR plugin, since vfs2 support is implemented already:

<providers>
	<provider class-name="com.github.junrar.vfs2.provider.rar.RARFileProvider">
		<scheme name="rar" />
	</provider>
	<extension-map extension="rar" scheme="rar" />
	<mime-type-map mime-type="application/rar" scheme="rar" />
</providers>

[beothorn]

Added geometer/junrar@c44496d changes

[beothorn]

Added META-INF/vfs-providers.xml

[gotson]

Adding META-INF/vfs-providers.xml to the JAR would be nice as well, so vfs2 can find the RAR plugin, since vfs2 support is implemented already:

<providers>
	<provider class-name="com.github.junrar.vfs2.provider.rar.RARFileProvider">
		<scheme name="rar" />
	</provider>
	<extension-map extension="rar" scheme="rar" />
	<mime-type-map mime-type="application/rar" scheme="rar" />
</providers>

@rednoah Would you be able to provide some context on this ? I don't really know VFS nor what it brings. I was thinking of removing it, but if it's useful we can keep it?

[theobisproject]

Adding META-INF/vfs-providers.xml to the JAR would be nice as well, so vfs2 can find the RAR plugin, since vfs2 support is implemented already:

<providers>
	<provider class-name="com.github.junrar.vfs2.provider.rar.RARFileProvider">
		<scheme name="rar" />
	</provider>
	<extension-map extension="rar" scheme="rar" />
	<mime-type-map mime-type="application/rar" scheme="rar" />
</providers>

@rednoah Would you be able to provide some context on this ? I don't really know VFS nor what it brings. I was thinking of removing it, but if it's useful we can keep it?

@gotson This was already added by @beothorn (see the linked commit above his comment)

[gotson]

Adding META-INF/vfs-providers.xml to the JAR would be nice as well, so vfs2 can find the RAR plugin, since vfs2 support is implemented already:

<providers>
	<provider class-name="com.github.junrar.vfs2.provider.rar.RARFileProvider">
		<scheme name="rar" />
	</provider>
	<extension-map extension="rar" scheme="rar" />
	<mime-type-map mime-type="application/rar" scheme="rar" />
</providers>

@rednoah Would you be able to provide some context on this ? I don't really know VFS nor what it brings. I was thinking of removing it, but if it's useful we can keep it?

@gotson This was already added by @beothorn (see the linked commit above his comment)

I know, i'm wondering what's the use and if we should keep it or remove it.

[beothorn]

Adding META-INF/vfs-providers.xml to the JAR would be nice as well, so vfs2 can find the RAR plugin, since vfs2 support is implemented already:

<providers>
	<provider class-name="com.github.junrar.vfs2.provider.rar.RARFileProvider">
		<scheme name="rar" />
	</provider>
	<extension-map extension="rar" scheme="rar" />
	<mime-type-map mime-type="application/rar" scheme="rar" />
</providers>

@rednoah Would you be able to provide some context on this ? I don't really know VFS nor what it brings. I was thinking of removing it, but if it's useful we can keep it?

Someone a long time ago wanted to use junrar from inside a hadoop cluster. I don't think that this is a common usage and there are probably other ways to work around this without vfs.

[gotson]

vsubhash/junrar@9831bed is breaking tests. Some of our test files do have windows separators, and extract fine on Mac and Linux, so this is probably not needed.

[gotson]

It seems there is some interesting change here about PPM error handling, but i have no idea if those changes make sense or not.

Files concerned:

• Unpack.java
• Decode.java
• ModelPPM.java

[gotson]

Some more changes that are difficult to assess: phax/junrar@2b0dc09

[gotson]

And this one too: vaemendis@28663a4

[gotson]

I finished combing the changes listed above. I found only 3 that i cannot really assess (the 3 comments directly above this one).

@sunny-shu if you are up to the challenge, you can have a look at the 3 changes and see if they make sense, and if yes we can port them to our version.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.