[vnbiggs]

Hi, my name is Ivan Biggs and I'm greatly interested in working with the JBoss for my GSoC project this summer. I know it's very late to be making first contact, but the reason for this is that the issue I had previously worked on a proposal for (with another mentoring organization) ended up never being assigned an official mentor. That being said, I'm wondering how to best move forward with submitting a proposal and contacting a potential mentor. As an engineer (at Vanderbilt University) my experience includes basic knowledge of object oriented languages (mainly java), extensive work with MATLAB, some work with LabVIEW, and basic LaTeX fluency, and it also seems to me that running information through I/O streams can be likened to many engineering problems.

Furthermore, I have some questions about the project itself:

First, from what I can tell it seems that java implementations to export the ISO archive format exist but are under the LGPL license. That being said, would be bad practice to build a direct dependency to this sort of code into something distributed under the Apache license (Such as ShrinkWrap)?

Next, to the best of my research it seems that Rar is a proprietary format so I'm not sure how I would (legally) go about adding support to write to this format if it can be done at all. The segues in to my next idea which is could I possibly replace the request for some of the above formats (Primarily Rar) with adding support for archive formats that can be found directly through working with Apache commons compress such as 7zip or arj?

Thanks,

Ivan

[kpiwko]

Hi Ivan,

I'm not a layer, but I believe that LGPL an ASL can be connected if some guidelines are followed. As for the RAR being proprietary, DOC is also proprietary and LibreOffice supports is, same for 7zip and RAR. So it is possible for sure. However, ShrinkWrap is aiming at adding functionality for testing, so there is not that much sense to add RAR, 7zip or arj.

For instance:

• ISO - allows to produce archives to represent VMs
• RPM - allows to test RPM applications
• APK - allows to test Android applications

The other possibilities are formats for KVM, QEMU, Docker, etc. (e.g. virtual machine formats) or IPA (iOS app packaging)

[vnbiggs]

Karel,

Thanks for your prompt reply.

As far as I can tell based off the documentation for cr-3 Shrink Wrap currently only supports basic jars, web archives, Tarz, Tar gz, and zip.

So as for not adding much functionality would you say that goes for something like bzip2 as well?

Another thought I had based on Apache commons functionality was Unix Dump.

I'm only asking so many questions because I want to include work that would be useful in my proposal and avoid proposing to do unwanted tasks

Assuming all goes well I should be on the way to getting a solid proposal out but just for clarity's sake is there someone specifically I should be making sure to get in touch with such as Andrew due to his being listed as the mentor for this issue?

Thanks again,

Ivan.

[kpiwko]

Bzip2 was added in 1.2.0 - https://issues.jboss.org/browse/SHRINKWRAP/fixforversion/12322170. Sorry, but we haven't yet added new documentation to arquillian.org page.

The best thing you can do is to send you proposal idea - e.g. a details to unix dump idea etc to ShrinkWrap Development page. On this page, all SW developers can have a look, including Andrew and me.

We can help you to identify useful goals and get the proposal in better shape before submitted.

Karel

[vnbiggs]

Well I'm not sure an entirely new thread is needed. The basic thought was that Unix dump could have potential for adding functionality since it allows the user to back up a system without going through the file system. At the very least my readings suggest it's a faster way of backing up files for most nix systems. Thus my general idea for what I could do this summer would be to add write support for ISO for the first part of the summer and then make an adapter for Apache Commons Compress such that Unix dump could be used. My reasoning for asking about the usefulness of so many other options is that if I'm already using the commons compress library for something like Unix Dump it wouldn't really be that much more work to add the ability to work with many of the other archive formats it supports. That being said if the primary functionality is to be testing based and adding too many bells and whistles would be bad, any or all of the extra format supports could be scrapped. At the very least though, it seems like having an option to add the functionality available couldn't be a negative thing. Just to be thorough the list of possible formats I could add from that existing library would be ar, cpio, Unix dump, tar, zip, gzip, XZ, Pack200, bzip2, 7z, arj, lzma, snappy and Z files (minus whichever ones are already supported of course). Let me know if this seems like a reasonable proposal and I'll do my bast to make any changes to accommodate the communities needs/preferences.

Thanks!

[kpiwko]

Hi Ivan,

right, adding more functionality is very rarely a negative thing. However, the point of GSoC ShrinkWrap proposal is not only to improve SW abilities but to help "spread the concept" to non Java related testing. And this is what I'm looking for.

Basically it works following way:

* Arquillian manages so called container, that is able to work with archives

* ShrinkWrap prepares so called archive, a testing unit for container.

So, in Java world: Container is for instance JBoss WildFly8; archive is jar, war, ear, etc.

In Android world: Container is Android SDK emulator, mobile device, Genymotion; archive is APK application

In VM world: Container is KVM; archive is ISO

etc.

I'd would be very happy to see you opinions what would be the container for formats you proposed. Basically any combination of container and archive format that helps to "spread the concept" to any environment makes a valid proposal ;-)

Just to be clear GSoC work is usually tied to container or archive enablement. Both together would represent very likely too much work given the timeframe.

Thanks,

Karel

[vnbiggs]

Hi, as the time to make decisions on accepted proposals approaches I just wanted to reiterate that my interest in this project is still strong and that I hope you will consider my proposal completely before deciding. I believe I'm the right candidate for the job and I know that I can do what needs to be done. I hope to get the opportunity to at least be one of the candidates selected to work on this task (since Google technically allows multiple people to attempt the same project separately) so that I can prove this to you, but either way thanks for all you guy's work and time with GSoC.

Ivan