[GSoC] GUI for jar tool

[Tomek Maciejewski <to...@gmail.com>]

Hi,

I have got an email from Mark that it was not your intention to propose 
jar tool as a part of GSoC program, because of the simplicity of this 
task. I agree with you that it is quiet simple task, maybe too simple 
;-) However I was asked to provide some detailed information about the 
GUI tool I was intended to provide (as an addition to console one). I 
have written down some major functionality of such interface. I must 
mention that you can find some of the descriptions not complete, that’s 
because I have planned it earlier, only as a small addition and haven’t 
had enough time to create a coherent vision. I would like to know what 
do out think about it? Will Apache Harmony benefit from such kind of 
tool? Or maybe it is completely unnecessary? ;)

	This tool would consist of two main parts: file navigator and main 
window. As a file navigator I understand the directories tree, as a main 
window – the normal window to display files (similar to the one from “My 
computer”, etc.). There would be also some toolbar and some menu. Below, 
you can find major use cases I have thought about:

1. Creating JAR file
This is one of the basic functionalities. User will be able to select 
proper file and directories he wants to pack into archive. Then he will 
choose ‘Create JAR’ option from menu or toolbar. The settings window 
will appear and user will be able to specify several options, like:
- Name and location of output file
- JAR index creation (yes/no)
- JAR signing settings
- Set Manifest and entry point values
- Create optional JAD descriptor

2. Listing JAR file
When user marks the JAR file in navigator, he will see its content 
(included files and directories) in main window, and will be able to 
navigate through it.

3. Extracting from JAR
Extracting process will be similar to the JAR listing. But, user will be 
able to mark whole JAR or just a subset of included resources, and 
choose “Extract from” button. He will be also able to specify desired 
location.

4. Updating the JAR file
User will be able to drag&drop additional files to JAR archive or remove 
the existing ones. It will be also possible to change Manifest, generate 
or remove index or sign a JAR.

5. Find class in JAR
GUI will provide option to search existing JAR files for some specified 
class. User will select JARs and specify name of the class he want to 
search for. If program finds the specified class, it will notify user 
about its location.

6. JAR repositories
The last functionality will be possibility to group JAR files into JAR 
repository. User will be able to create one or more virtual repositories 
aggregating JAR archives. Such solution will be quiet comfortable for 
end users, and will also provides fast way to search JARs for specified 
class, because it will be possible to invoke search on logic repository 
(all JARs in repository).


Summing up, I think that for some cases console interface (like the one 
provided by Sun) is slightly better, especially if you are familiar with 
it. But there exist some cases where additional GUI tool can make 
difference. The most popular case is when you want to integrate 
functionality of several tools like jar, jarsigner, jar preverification 
tool etc. The next advantage is possibility to save your preferred 
settings to reuse them in future (like information about JAR 
repositories). Additionally GUI may be a good start point for users, who 
start with Java. In Sun’s JVM you can find several GUI tools, like 
jconsole or visualvm. Of course these tools are little different, and it 
would be hard to imagine console version of visualvm ;-) But it is 
commonly known that GUI tools are quiet attractive for people (more than 
console).

Cheers,
Tomek

Re: [GSoC] GUI for jar tool

[Tomek Maciejewski <to...@gmail.com>]

Hi,

The purpose was to send you more detailed description of the additional 
GUI tool and to hear your comments on it:) I have already applied for 
jar tool and it is rather too late to send application for another one.

Cheers,
Tomek


Alexei Fedotov pisze:
> Hello Tomek,
> This is an interesting letter, though I feel that I miss the purpose
> of the post. If Mark asked you to use a mail list for discussing
> technical details, this was a good start. If you want to convince Mark
> to be your mentor, then it worth asking him which tools he believes
> are worth to be developed.
> Thanks!
> 
> 
> On Thu, Apr 9, 2009 at 1:29 AM, Tomek Maciejewski
> <to...@gmail.com> wrote:
>> Hi,
>>
>> I have got an email from Mark that it was not your intention to propose jar
>> tool as a part of GSoC program, because of the simplicity of this task. I
>> agree with you that it is quiet simple task, maybe too simple ;-) However I
>> was asked to provide some detailed information about the GUI tool I was
>> intended to provide (as an addition to console one). I have written down
>> some major functionality of such interface. I must mention that you can find
>> some of the descriptions not complete, that's because I have planned it
>> earlier, only as a small addition and haven't had enough time to create a
>> coherent vision. I would like to know what do out think about it? Will
>> Apache Harmony benefit from such kind of tool? Or maybe it is completely
>> unnecessary? ;)
>>
>>        This tool would consist of two main parts: file navigator and main
>> window. As a file navigator I understand the directories tree, as a main
>> window - the normal window to display files (similar to the one from "My
>> computer", etc.). There would be also some toolbar and some menu. Below, you
>> can find major use cases I have thought about:
>>
>> 1. Creating JAR file
>> This is one of the basic functionalities. User will be able to select proper
>> file and directories he wants to pack into archive. Then he will choose
>> 'Create JAR' option from menu or toolbar. The settings window will appear
>> and user will be able to specify several options, like:
>> - Name and location of output file
>> - JAR index creation (yes/no)
>> - JAR signing settings
>> - Set Manifest and entry point values
>> - Create optional JAD descriptor
>>
>> 2. Listing JAR file
>> When user marks the JAR file in navigator, he will see its content (included
>> files and directories) in main window, and will be able to navigate through
>> it.
>>
>> 3. Extracting from JAR
>> Extracting process will be similar to the JAR listing. But, user will be
>> able to mark whole JAR or just a subset of included resources, and choose
>> "Extract from" button. He will be also able to specify desired location.
>>
>> 4. Updating the JAR file
>> User will be able to drag&drop additional files to JAR archive or remove the
>> existing ones. It will be also possible to change Manifest, generate or
>> remove index or sign a JAR.
>>
>> 5. Find class in JAR
>> GUI will provide option to search existing JAR files for some specified
>> class. User will select JARs and specify name of the class he want to search
>> for. If program finds the specified class, it will notify user about its
>> location.
>>
>> 6. JAR repositories
>> The last functionality will be possibility to group JAR files into JAR
>> repository. User will be able to create one or more virtual repositories
>> aggregating JAR archives. Such solution will be quiet comfortable for end
>> users, and will also provides fast way to search JARs for specified class,
>> because it will be possible to invoke search on logic repository (all JARs
>> in repository).
>>
>>
>> Summing up, I think that for some cases console interface (like the one
>> provided by Sun) is slightly better, especially if you are familiar with it.
>> But there exist some cases where additional GUI tool can make difference.
>> The most popular case is when you want to integrate functionality of several
>> tools like jar, jarsigner, jar preverification tool etc. The next advantage
>> is possibility to save your preferred settings to reuse them in future (like
>> information about JAR repositories). Additionally GUI may be a good start
>> point for users, who start with Java. In Sun's JVM you can find several GUI
>> tools, like jconsole or visualvm. Of course these tools are little
>> different, and it would be hard to imagine console version of visualvm ;-)
>> But it is commonly known that GUI tools are quiet attractive for people
>> (more than console).
>>
>> Cheers,
>> Tomek
>>
> 
> 
> 

Re: [GSoC] GUI for jar tool

[Alexei Fedotov <al...@gmail.com>]

Hello Tomek,
This is an interesting letter, though I feel that I miss the purpose
of the post. If Mark asked you to use a mail list for discussing
technical details, this was a good start. If you want to convince Mark
to be your mentor, then it worth asking him which tools he believes
are worth to be developed.
Thanks!


On Thu, Apr 9, 2009 at 1:29 AM, Tomek Maciejewski
<to...@gmail.com> wrote:
> Hi,
>
> I have got an email from Mark that it was not your intention to propose jar
> tool as a part of GSoC program, because of the simplicity of this task. I
> agree with you that it is quiet simple task, maybe too simple ;-) However I
> was asked to provide some detailed information about the GUI tool I was
> intended to provide (as an addition to console one). I have written down
> some major functionality of such interface. I must mention that you can find
> some of the descriptions not complete, that's because I have planned it
> earlier, only as a small addition and haven't had enough time to create a
> coherent vision. I would like to know what do out think about it? Will
> Apache Harmony benefit from such kind of tool? Or maybe it is completely
> unnecessary? ;)
>
>        This tool would consist of two main parts: file navigator and main
> window. As a file navigator I understand the directories tree, as a main
> window - the normal window to display files (similar to the one from "My
> computer", etc.). There would be also some toolbar and some menu. Below, you
> can find major use cases I have thought about:
>
> 1. Creating JAR file
> This is one of the basic functionalities. User will be able to select proper
> file and directories he wants to pack into archive. Then he will choose
> 'Create JAR' option from menu or toolbar. The settings window will appear
> and user will be able to specify several options, like:
> - Name and location of output file
> - JAR index creation (yes/no)
> - JAR signing settings
> - Set Manifest and entry point values
> - Create optional JAD descriptor
>
> 2. Listing JAR file
> When user marks the JAR file in navigator, he will see its content (included
> files and directories) in main window, and will be able to navigate through
> it.
>
> 3. Extracting from JAR
> Extracting process will be similar to the JAR listing. But, user will be
> able to mark whole JAR or just a subset of included resources, and choose
> "Extract from" button. He will be also able to specify desired location.
>
> 4. Updating the JAR file
> User will be able to drag&drop additional files to JAR archive or remove the
> existing ones. It will be also possible to change Manifest, generate or
> remove index or sign a JAR.
>
> 5. Find class in JAR
> GUI will provide option to search existing JAR files for some specified
> class. User will select JARs and specify name of the class he want to search
> for. If program finds the specified class, it will notify user about its
> location.
>
> 6. JAR repositories
> The last functionality will be possibility to group JAR files into JAR
> repository. User will be able to create one or more virtual repositories
> aggregating JAR archives. Such solution will be quiet comfortable for end
> users, and will also provides fast way to search JARs for specified class,
> because it will be possible to invoke search on logic repository (all JARs
> in repository).
>
>
> Summing up, I think that for some cases console interface (like the one
> provided by Sun) is slightly better, especially if you are familiar with it.
> But there exist some cases where additional GUI tool can make difference.
> The most popular case is when you want to integrate functionality of several
> tools like jar, jarsigner, jar preverification tool etc. The next advantage
> is possibility to save your preferred settings to reuse them in future (like
> information about JAR repositories). Additionally GUI may be a good start
> point for users, who start with Java. In Sun's JVM you can find several GUI
> tools, like jconsole or visualvm. Of course these tools are little
> different, and it would be hard to imagine console version of visualvm ;-)
> But it is commonly known that GUI tools are quiet attractive for people
> (more than console).
>
> Cheers,
> Tomek
>



-- 
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://www.telecom-express.ru/
http://people.apache.org/~aaf/
http://harmony.apache.org/
http://code.google.com/p/openmeetings/