Thanks for the reply. Figured you were busy with something. :)
 

> You are right, the extraction happens in FilePath. In the Jenkins project 
> we rely on the implementation in org.apache.commons.compress.archivers. It 
> supports endian bits at least for unarchive operations. 
>
Yes and no, we rely on the library. So for the Jenkins project it's 
> "automatic"
>

I'll look up the endian compatibility with SevenZ and JUnrar (libraries for 
.7z and .rar respectively).
I've been looking into what you mentioned about Extra Tool Installers, but 
not quite sure how do approach it anyway. Please do correct the following 
proposals if they are wrong. Either way, I need to extend hudson's 
FilePath.java in order to recognize the format of the installation files. 
The following code is from FilePath.java in installIfNecessary(...), where 
the blue code is where I think I'll add the format check. Next I think I'll 
try to imitate the unzip methods' structure in that class as much as 
possible when implementing the rar extractor. (Adding "unrar" methods where 
the extraction is done).

try { if(archive.toExternalForm().endsWith(".zip")){
unzipFrom(cis); *}else if(archive.toExternalForm().endsWith(".rar")){ 
unrarFrom(cis);* 
}else{
untarFrom(cis,GZIP); }
} catch (IOException e) {
throw new IOException(String.format("Failed to unpack %s (%d bytes read of 
total %d)",
archive,cis.getByteCount(),con.getContentLength()),e);
}
 
What do you think about this approach? Any other ideas?

RAR has its own issues. For your case I'd recommend to stick to a 
> particular format and to implement it. Not every tool needs permission 
> bits. The advantage is that there is a big number of Windows tools being 
> delivered by RAR. Hence such installer provides much more added alue than 
> 7zip.
>

I'm able to extract both .rar and .7z files, so I think I'm quite flexible 
on that point. If RAR is preferred, I could implement support for that 
format.
 

> I would also like to mention that Jenkins' FilePath implementation 
> supports files with size >8Gb (starting from 1.627) via LONGFILE_GNU 
> extension. The most of the bits have been implemented here: 
> https://github.com/jenkinsci/jenkins/commit/b6c7b83e7ba1a7538382d220d044626f2b2e65be
>  
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Fcommit%2Fb6c7b83e7ba1a7538382d220d044626f2b2e65be&sa=D&sntz=1&usg=AFQjCNEUEog-_tI9c19nPTwk5zsW9XzxJA>
>  
> . I would expect the tar installer to work on big files, but it does not 
> decrease the potential added value of adding new installers , especially in 
> the case of RAR files.
>

Aha, interesting. How does that work? Is there a way to select some sort of 
long name option before compressing files? Not familiar with it. Good to 
hear that the work won't be in vain at least.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/82bbc2ca-ff49-405e-8471-3f2ea5115765%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to