Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 355031

Summary:	Refactor context externalizing to allow adding other resources to the context ZIP file
Product:	z_Archived	Reporter:	Manuel Doninger <manuel.doninger>
Component:	Mylyn	Assignee:	Project Inbox <mylyn-triaged>
Status:	CLOSED MOVED	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	shawn.minto, steffen.pingel
Version:	unspecified
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:
Bug Depends on:
Bug Blocks:	345661

Description Manuel Doninger

2011-08-18 03:41:49 EDT

Build Identifier: 

While working on Bug 345661, i faced some problems with the handling of the creation of the context ZIP file. Currently if i want to add a file to the ZIP file, in my code i would have to open and extract the ZIP, search for a file with the filename which i want to store, replace the content if it exists or add the content and write a new ZIP file. It would also be necessary to change the code of the InteractionContextExternalizer to do the same.

So i was thinking of refactoring the whole code and architecture of this (because i assume, changing to Java 7 will take some time), but i wanted to ask for comments first, before i start.

My idea was to use some kind of a contributor model, where the ContextStore manages a list of contributors like the InteractionContextExternalizer, my PSF provider or any other class, which would want to store a file in the zip. These contributors would provide a method with a Byte stream, which returns the content, and the ContextStore then creates the ZIP file with all these files. The creation of the contents and the creation of the ZIP file would then be decoupled (opposed to the current state, where the InteractionContextExternalizer creates the ZIP).


Reproducible: Always

Comment 1 Steffen Pingel

2011-08-18 06:21:14 EDT

That sounds like a good idea. Shawn, do you have any comments?

I implemented a similar approach in a patch on bug 226618 that allows externalizers to contribute to a context specific memento which. I haven't gotten around to finishing the patch though

Comment 2 Shawn Minto

2011-08-25 11:20:02 EDT

I think that this sounds like the right approach to me.  We may need to consider adding support when uploading context to allow users to exclude some information as it will not all be visible from the context page anymore, but it seems correct to store this information beside the context iteself.

Comment 3 Steffen Pingel

2011-08-25 15:19:23 EDT

That's a very good point along the lines of bug 272088.

What if we separated the local context store from the format that is externally shared? I'm thinking something like this:

pre. 
 .mylyn/data/bugs.eclipse.org/1234/
   attachments/
     unsubmitted-patch.txt
   activity.xml
   changesets.xml
   context.xml
   notes.txt
   task-edits.xml
   version.psf
   workspace-state.xml

The cached data could be separated in another directory to make it easier to manually free disk space for instance.

pre. 
 .mylyn/cache/bugs.eclipse.org/1234/
   attachments/
     screenshot.png
   task-data.xml   
   task-lastread.xml
   
A context attachment would essentially be a zip version of the data task folder only including parts the user wants to share.

Manuel, in terms of API it would probably look the same as to what you suggested in the description.

Comment 4 Eclipse Webmaster

2022-11-15 11:45:08 EST

Mylyn has been restructured, and our issue tracking has moved to GitHub [1].

We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub.

[1] https://github.com/orgs/eclipse-mylyn