Community
Participate
Working Groups
Build Identifier: When implementing the koji connector, I must determine whether the build is a scratch build or a normal build. For a scratch build, which will not be included in the upcoming fedora release, a koji task will not be kept by koji. In this way, I must map the build ID to the Build object's ID and hence a resubmission of the task for rebuilding is not possible. For a normal build, on the other hand, due to the presence of the task, I can map the task ID to the Build's ID and resubmit the task easily. So I think it will be much easier for a connector developer to have access to an extra generic data structure to the Build class (such as a HashMap). Then he can fit his server's data model into Mylyn Builds without losing important information (my plan is to use that hash map to store the task ID if it exists, so checking the size of the map should allow me to determine whether a task resubmission is possible). Reproducible: Always
That makes sense to me. I would propose that we add a simple key/value map. It's not a perfect solution since we loose the benefit of having a schema for all data that stored in the map but making the builds model extensible would require a significant effort.
One think that I was wondering about: If bug 354624 was resolved would it be possible to represent the build/sub-build (build/task/sub-task) relation ship in the core model without the need for additional attributes?
(In reply to comment #2) > One think that I was wondering about: If bug 354624 was resolved would it be > possible to represent the build/sub-build (build/task/sub-task) relation ship > in the core model without the need for additional attributes? Hi Mr. Pingel: In fact, I really am not sure whether that will fix the issue of Koji... The problem with koji is that scratch builds will break the connection between task and packages as the build data is not created/persisted in the database. (In fact, I am having a hard time how to query the package with just a task ID and vice versa, which is necessary for the BuildEditor's getConsole method call.) But I believe that solving bug 354624 will certainly ease the mapping of other data models as build plan hierarchies are unavoidable. I should've paid more attention to the emf framework, but unfortunately, without a wsdl, I spent tremendous amount of time learning how to interact with the koji web service and handle its returns. I really hate myself that I cannot help with how to make the current model extensible.... (especially I find this project increasingly interesting to work with....) Ken Leung
Hi Mr. Pingel, I noticed that I made a mistake with the bug report, instead of adding the hash map to Build class, I actually meant the BuildPlan class. My apologizes. Ken Leung
Hi Mr. Pingel: I forgot to mention, considering that we need to use getWorkingCopy(), I believe that we should force the data structure to store Cloneable type so users can use their own way of object deep copying (if we are going for a generic structure for now). Ken Leung
I have pushed a change that pulls the attributes map up to IBuildElement. That allows storing of key-values pairs in builds, build plans and artifacts. Can you take a look and let me know if that addresses your request? The code review is here: http://review.mylyn.org/#change,5 You will need to convert the data you want to store into strings. The persistence mechanism that the builds framework will not support serializing of objects. Can you explain in more detail why you want to store objects?
(In reply to comment #6) > You will need to convert the data you want to store into strings. The > persistence mechanism that the builds framework will not support serializing of > objects. Can you explain in more detail why you want to store objects? Hi Mr. Pingel: I since I am prepared to make everything serializable, I think that will be great to have a <String, String> map that I can serialize/deserialize my objects into. The reason for a general purpose data storage is that, in case of koji, there are build/task records that are imported from other koji instances (like database backups/restores), so I often find that the data are broken and and some of the Mylyn Builds operations becomes impossible to perform (such as getConsole() and build()). So I need a way to figure out what is the situation and handle them properly. Ken Leung
Hi Mr. Pingel: I am sorry that I was wrong, instead of using <String, String> can we use <string, byte[]> instead? I wrote a class trying to serialize and deserialize the objects and it turns out that the java string encoding decoding will introduce steam corruption (a bit of online forum reading shows that its caused by UTF8). Ken Leung
That would make the API more difficult to use since strings are much more common for managing properties than byte arrays. Have you looked at the GSon? It might be alternative persistence mechanism that is also more robust than Java serialization.
Otherwise you can also consider using an encoding such as Base64 to convert the byte array to a string.
(In reply to comment #10) > Otherwise you can also consider using an encoding such as Base64 to convert the > byte array to a string. Mr. Pingel: Thanks for reminding me about base64, I forgot to try other encoding. Ken Leung
Hi Mr. Pingel: Sorry that I have to ask such a stupid question, I looked at the patch and I saw the new EMap field of the BuildElement class. I can also find the getter of the attributes field, but I suppose that simply changing the map returned by getAttribute() will not change the content of the 'real' EMap, am I correct? Should I be calling eSet() and pass a new HashMap in? Or modifying the result of the getter will actually change the content of attributes? Ken Leung
Mr. Pingel: Finally I figured that out, so the Map() actually returns an inner class of the Emap, so I guess simply calling getAttributes().put/remove will do, thank you very much! Ken Leung
Pushed changes and tests to master.
