Write tracked data directly into XML file

[matpardo]

Definir los métodos que tendrán que tener los eventos que se van agregando para poder guardar correctamente la información a la hora de hacer las conversiones correspondientes a los archivos donde se guarden los datos. (para guardarlos en el xml)

Edit: Hacer que el plugin escriba el log en XML

[JurajKubelka]

Creo que es mejor decir implementar transformación LOG->XML. Parece que te confundí con la idea de interface. Lo podemos hablar mañana. Puedes comenzar con un ejemplo propio para aprender cómo generar un XML. Por ejemplo una "aplicación" Contactos. Contactos tiene lista de personas, y cada lista tiene correo más teléfono. Y aprender guardar esto cómo XML. ¿Te parece?

[matpardo]

Ok, sí, pensé que no estaba muy bien la explicación que puse porque lo puse un poco a la rápida para revisarlo luego. Sí revisaré lo del XML

[JurajKubelka]

Bueno :-) Después lo mejoras para que se entiende el objetivo :-)

[JurajKubelka]

Y me imagina que no es algo grave, que lo podríamos presentar en la primera presentación. Me imagino que es cómo dos veces de 5 horas de trabajo. 5 horas de aprendizaje, 5 horas de implementación. Entonces hay que tener dos tardes libre, una esta semana, una la siguiente :-)

[JurajKubelka]

Fluorite writes information to XML file. You can learn from it and decide if it useful do that way.

[JurajKubelka]

There is an example of Fluorite XML log. You may find out if it is hard to change CodingSpectator that way. Then you can discuss with us and Romain Robbes if it is worth to do it that way.

[reprogrammer]

We didn't store CodingTracker data in XML because XML contains many whitespaces and wastes space. Space seemed important because CodingTracker log files grow rapidly. Nonetheless, if you want to store CodingTracker's log in XML, you can change CodingTracker to do so.

[JurajKubelka]

@reprogrammer: thank you for the comment. The file size could be a significant property. We will discuss it.

[JurajKubelka]

Note: Romain Robbes said today that the advantage to write directly to XML is the ability to simply open XML file in any editor (or import in any language) and do what ever desired queries. There is no required step to do the export.

[JurajKubelka]

Note: As the plug-in grows, some logging events change their properties. And with XML could be easier to manage different file versions. For example information about JUnit execution status now has two more attributes.

Before it was something like this

<timestamp>#B<launch name>#<class name>#<method name>#<OK|FAILED|ERROR|...>#

Now it is

<timestamp>#B<launch name>#<class name>#<method name>#<OK|FAILED|ERROR|...>#<progress>#<stack trace>#

And it will likely change in the future. Moreover <stack trace> does not have sense for green test cases. So we could remove this parameter in XML file version.

In the existing solution there is no way to now what file version we have in hands. So when someone wants to read the file and convert it to another file format, there is no easy way to now how many attributes should be read. For XML solution we could change version number and then it is clear what plug-in version was used.

XML file content could start with

<?xml version="1.0" encoding="UTF-8"?>
<document formatVersion="1" pluginVersion="1.1" releaseDate="2014-05-01">

...

[matpardo]

El plugin escribirá directamente en el formato que deseemos. Para esto haremos un proceso en 3 etapas:

1.- Mover generadores de texto a TextRecorder 2.- Dar la posibilidad de escribir en variados formatos 3.- Implementar formato XML

CONSIDERAR: los logs sean generados por cada vez que se realice una sesión de eclipse, no un log general

Actualmente el plugin está funcionando así:

(más detalles en #19)

1.- Mover generadores de texto a TextRecorder

La idea es hacer que TextRecorder sea quien sabe cómo se escribe todos y cada uno de los eventos que debe guardar, y no que sea cada evento quien sepa como se escribe. Habrá que mover las implementaciones de populateTextChunk que están en cada evento hacia TextRecorder.java, y generateSerializationText que está en UserOperation.java a TextRecorder.java

a) Crear Test La primera parte de este proceso será crear Test para testear todos los TextChunk que están siendo enviados a SafeRecorder, para asegurarse que todo siga funcionando correctamente una vez implementado el movimiento antes descrito.

b) Mover los populateTextChunk Habrá que buscar todas las implementaciones de populateTextChunk (que es cómo se escribe el evento) y moverlas (de a una) a TextRecorder.java, procurando que los test sigan funcionando.

2.- Dar la posibilidad de escribir en variados formatos

Considerando que generateSerializationText es el formato actual del log, y que TextRecorder se convertirá en una clase muy grande, haremos un refactoring, haciendo una interface EventTextGenerator (o incluso convertir TextRecorder en interface), la cual sus implementaciones serán cada uno de los records que tenemos actualmente y estas sabrán cómo escribir el Evento en cada formato posible (así TextRecorder le pedirá el texto en el formato que necesita a estos generadores de texto).

IMPORTANTE: Es probable que se deba crear archivos similares a OperationSymbols.java para cada formato.

a) Crear EventTextGenerators

Se creará la interface, y solo se obligará por el momento a saber cómo se escribe en el formato actual del log.

b) Implementar la forma de escribir

Los EventTextGenerators serán creados por agrupaciones de argumentos de los record que estarán en TextRecorder. Por ahora solo generarán el texto como se genera actualmente. Cuidado con que los test sigan en funcionamiento.

3.- Implementar formato XML

Para esto en la interfaz EventTextGenerator ahora diremos que todos deberán saber escribir en XML.

a) Implementar la forma de escritura en XML

Esto será para cada evento. Crear también test asociados.

Finalmente Con todo esto quedará implementado la escritura directa en XML, y cada vez que se desee un nuevo formato se debe realizar algo similar a lo del paso 3.-

Esto es el proceso a grandes rasgos, será algo extenso, y cualquier cosa se puede hablar por aquí. Saludos.

[matpardo]

Las implementaciones de populateTextChunk están en el package edu.illinois.codingtracker.operations

Aquí está la lista:

[JurajKubelka]

Great job! :-)

[matpardo]

Los test que debemos hacer para testear los TextChunk estarán en:

Proyecto: edu.illinois.condingtracker.tests

Package: edu.illinois.codingtracker.recording.tests

El package estará creado si se baja del branch, la idea es que vamso implementando lso tests ahí. Yo por ejemplo haré los tests de

ConflictEditorOperation

que cubre a su vez

OpenedConflitEditorOperation SavedConflictEditorOperation

[matpardo]

La idea de los test es que

userOperation.generateSerializationText()

El textChunk que genera esa llamada (que es lo que se escribe en el archivo) siga generando lo que tiene que generar.

Esta llamada está en TextRecorder.java como sigue:

public static void record(UserOperation userOperation) { recorderInstance.record(userOperation.generateSerializationText()); }

Esto es lo que debemos ver en los test.

Esto utiliza de UserOperation.java lo siguiente:

public OperationTextChunk generateSerializationText() { OperationTextChunk textChunk= new OperationTextChunk(getOperationSymbol()); populateTextChunk(textChunk); textChunk.append(timestamp); Debugger.debugTextChunk(getDescription() + ": ", textChunk); return textChunk; }

Si consideramos generateSerializatonText() como la llamada del formato lo que tenemos que ver es populatetextChunk(textChunk), por eso estamos haciendo los test para todos los que implementan populateTextChunk(textChunk).

No sé si quedó claro, en resumen, hay que testear lo que genera esto:

userOperation.generateSerializationText()

Saludos.

PS: puse esto para que los tres tuviéramos más o menos la misma idea, creo que no había quedado mu claro.

[matpardo]

Esta es la lista actualizada, dónde tuvo que implemetarse la Escritura XML

[JurajKubelka]

I have just tried a new code and there are some observations:

1. you cannot write to file codechanges.txt, it should be called *.xml,
2. I have just opened and closed the Eclipse and the XML output is not valid. See my output.
3. I have proposed an example here. You should follow something similar.
4. To write populateXMLTextChunk method is inconvenient. There should not be code like \t, n. For now the populateTextChunk method is better. The writer should format the XML.
5. You should also use parameters, for example like this <DetectFocusGainsWorkbench timestamp="1401913003424" />. I think it will be much more readable. Just a long values like file name, package name, source code output should have their own tag.
6. I am pretty sure there are frameworks which facilitate to write XML output. Try Google, see 1, 2, 3, The Java Tutorials.

[matpardo]

1.- Como se dijo en el otro post por ahora se llaman igual, pero se pueden cambiar (la idea original era que se iba a escribir en un solo output, ¿verdad?).

2.- Si no es válido por el encabezado, es algo que hay que revisar (sabemos que falta el encabezado de comienzo de XML y el de fin) por una pregunta compleja, sabemos cuándo se empieza a escribir, pero no cuándo se termina, también la escritura en el log se hace de cada operación, no es como que se escriba primero el formato (encabezado) y luego se escriban las operaciones. Es algo que se puede revisar.

3.- No sé a qué va esta observación, si es que la idea es que prefieres que se escriba hacia un lado, o si quieres que volvamos a poner los # que eran del formato anterior.

4.- estabamos usando concat que es más general (en el caso de algún día se quiera agregar otro formato) en vez de lso append (que agregan gatos). Podriamos intenar hacer algo similar para quitar los /t y n el problema era la profundidad (no estábamos seguros de que todos estuvieran a la misma profundidad).

5.- Podemos hacer ese cambio, habiamos visto otro tipo de formato xml que era de la forma que pusimos por eso está así, pero es algo que podemos cambiar.

6.- No sé qué decir aquí, aún no los reviso, pero los revisaré.

Si alguno de los output de XML se ve un poco extraño y es de los que se implementaron en el curso pido por favor que los revisen o los revisemos juntos, para asegurarnos que el output esté correcto (hicimos los populateXML a partir de lo que observamos en la clase por eso es mejor que les den una mirada si están correctas). Eso, Saludos

[SanchezSeba]

Verifiqué que las issue #13 y #12 aun funcionan de forma correcta. Obviamente ahora se escribe el texto en XML

[matpardo]

Estuve revisando los tutoriales que puso Juraj.

Además estuve revisando la información de XML de la w3c http://www.w3schools.com/xml/default.ASP

Luego de haber visto todo esto, hay un par de cosas que hacer sobre el formato XML actual.

• Poner encabezado. (es solo encabezado, un xml tiene un inicio, pero no un cierre).
• Cambiar todos los atributos para que no tengan un salto de línea.

El archivo XML tiene encoding, se usará UTF-8.

Por tener que usar encoding (hay que transformar al encoding), tener que escapar caracteres ilegales en XML (no se había considerado), y para evitar poner tantos "/t" y "/n" en vez de usar el concat actual, se deberá usar un appendXML (nombre tentativo, se necesitará uno para root y otro para element), la idea de fondo es hacer un append solo para XML para asegurarse que esté bien el encoding.

Otro detalle, no se puede usar las bibliotecas de java para XML, porque esas están diseñadas para enviar el documento listo y generarlo una vez, y la idea que está implementada en el proyecto es ir actualizando continuamente el documento, así que por ahora la idea está descartada (pero se intentará usar algo similar como fue descrito en el párrafo anterior).

• Finalmente hay que generar el log en archivos.XML, con un timestamp, la idea es generar cada vez un archivo XML distinto.y que no sea el mismo del log anterior (ya sé como hacerlo). La investigación y revisión de esto fue lo que hice hoy. Pronto tendré más novedades) el método de trabajo será el mismo que el anterior. Saludos

[matpardo]

la branch masterIssue29 debe ser ignorada porque quedó corrupta por muchos cambios que se trataron de hacer a la vez.

Faltó poner bien la version del plugin en el USerOperation que indica inicio de Eclipse, pero es un detalle y es mejor no ponerse a hacer cambios ahora.

Hicimos estos cambios paulatinamente en fixesIssue29. Lo que está funcionando está en master ya. Lo que no está en master es que no será presentado (no funcionaba bien). Saludos