Community
Participate
Working Groups
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
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
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.
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.
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
