Migración de Localización Argentina de ADempiere 361.Final a iDempiere
155 views
Skip to first unread message
Emiliano Pereyra
Mar 12, 2021, 9:47:21 AM3/12/21
to iDempiere-es
Buenos días comunidad!
Les cuento que hace un tiempo estamos evaluando la posibilidad de migración de ADempiere 361.Final a iDempiere, y este año tomamos la decisión de avanzar en ese sentido.
Este proceso nos implica la migración de la Localización Argentina (LAR) que venimos desarrollando desde hace varios años, la cual incluye la impresión fiscal, manejo de impositivo y contable completo para la legislación Argentina y la facturación electrónica en las 2 modalidades que existen en nuestro país (tradicional y de crédito MiPyME), por mencionar algunas.
Respecto a iDempiere, tenemos ciertos conocimientos de OSGi y vemos que en líneas generales, los procesos de negocios y las operaciones que tanto desarrolladores como usuarios llevamos a cabo en ADempiere son similares en este nuevo ERP (como era de esperar dado el origen de iD). Pero a pesar de esto, nos surgen algunas dudas para poder iniciar este proceso de migración que espero nos puedan ayudar a evacuarlas.
1. Estructura de Proyectos
--------------------------------------------
En AD, manejamos esta estructura para realizar la implementación y desarrollo, tanto de la localización, como de las personalizaciones que cada cliente requiere:
workspace
|_ adempiere361.final > Codigo base del ERP
|_ lar_361 > Localización Argentina
|_ lar_cliente > Personalización para el cliente
En esta estructura, tenemos 99 clases soreescritas en LAR y algunas de esas, sobreescritas a su vez en los proyectos personalizados de cada cliente.
Y acá viene las primeras dudas, porque por lo que he leido, este concepto "sobreescritura" ya no es válido en iDempiere, entonces:
- ¿cómo se llevaría a cabo estas personalizaciones?
- ¿Solo utilizando los mecanismo de "validación/manejo de eventos" de iD?
- Y en lo casos en que este mecanismo no sea suficiente, ¿existe alguno otro mecanismo en iDempiere para lograr esta "sobreescritura"?
2. Localización Colombia
-----------------------------------------
Nuestra LAR está basada en la LCO desarrollada por Carlos Ruiz y a raíz de esto nos surgen la siguiente duda:
- ¿Existe el plug-in LCO para iDempiere? Porque solo vi el plui-in "LCO Detailed Names" en el catálogo disponible, pero no me queda claro si es algo adicional o es la LCO completa.
Esto lo consulto para saber si en el plug-in LAR que estamos planificando realizar (migrando lo existente) vamos a "depender" de otro plug-in (LCO) o directamente incluir la funcionalidad que tenemos adaptada de dicha LCO tal como lo tenemos ahora.
3. Campos Adicionales en Tablas
-------------------------------------------------------
Veo que en la definición de nuevas tablas para iDempiere, además de los campos clásicos de ADempiere (ad_client_id, ad_org_id, etc) se incorpora la utilización de uno nuevo: el UUID en la forma <nombre_de_tabla>_uu.
¿Es necesario modificar todas las tablas que creamos dentro de LAR?
4. Cambio de ModelValidator a EventHandler
Les cuento que hace un tiempo estamos evaluando la posibilidad de migración de ADempiere 361.Final a iDempiere, y este año tomamos la decisión de avanzar en ese sentido.
Este proceso nos implica la migración de la Localización Argentina (LAR) que venimos desarrollando desde hace varios años, la cual incluye la impresión fiscal, manejo de impositivo y contable completo para la legislación Argentina y la facturación electrónica en las 2 modalidades que existen en nuestro país (tradicional y de crédito MiPyME), por mencionar algunas.
Respecto a iDempiere, tenemos ciertos conocimientos de OSGi y vemos que en líneas generales, los procesos de negocios y las operaciones que tanto desarrolladores como usuarios llevamos a cabo en ADempiere son similares en este nuevo ERP (como era de esperar dado el origen de iD). Pero a pesar de esto, nos surgen algunas dudas para poder iniciar este proceso de migración que espero nos puedan ayudar a evacuarlas.
1. Estructura de Proyectos
--------------------------------------------
En AD, manejamos esta estructura para realizar la implementación y desarrollo, tanto de la localización, como de las personalizaciones que cada cliente requiere:
workspace
|_ adempiere361.final > Codigo base del ERP
|_ lar_361 > Localización Argentina
|_ lar_cliente > Personalización para el cliente
En esta estructura, tenemos 99 clases soreescritas en LAR y algunas de esas, sobreescritas a su vez en los proyectos personalizados de cada cliente.
Y acá viene las primeras dudas, porque por lo que he leido, este concepto "sobreescritura" ya no es válido en iDempiere, entonces:
- ¿cómo se llevaría a cabo estas personalizaciones?
- ¿Solo utilizando los mecanismo de "validación/manejo de eventos" de iD?
- Y en lo casos en que este mecanismo no sea suficiente, ¿existe alguno otro mecanismo en iDempiere para lograr esta "sobreescritura"?
2. Localización Colombia
-----------------------------------------
Nuestra LAR está basada en la LCO desarrollada por Carlos Ruiz y a raíz de esto nos surgen la siguiente duda:
- ¿Existe el plug-in LCO para iDempiere? Porque solo vi el plui-in "LCO Detailed Names" en el catálogo disponible, pero no me queda claro si es algo adicional o es la LCO completa.
Esto lo consulto para saber si en el plug-in LAR que estamos planificando realizar (migrando lo existente) vamos a "depender" de otro plug-in (LCO) o directamente incluir la funcionalidad que tenemos adaptada de dicha LCO tal como lo tenemos ahora.
3. Campos Adicionales en Tablas
-------------------------------------------------------
Veo que en la definición de nuevas tablas para iDempiere, además de los campos clásicos de ADempiere (ad_client_id, ad_org_id, etc) se incorpora la utilización de uno nuevo: el UUID en la forma <nombre_de_tabla>_uu.
¿Es necesario modificar todas las tablas que creamos dentro de LAR?
4. Cambio de ModelValidator a EventHandler
---------------------------------------------------------------------------
Por lo que vengo leyendo, iDempiere incorpora una nueva forma de realizar "validaciones", cambiando el modelo de ModelValidator por EventHandlers debido a que este último utiliza características nativas de OSGi.
¿Nos recomiendan "migrar" esta forma de validación de modelos para este nuevo plug-in LAR?
Bueno, espero haber sido claro y no tan extenso. Y desde ya les comento que este plug-in que vamos a desarrollar/migrar, también será público para que la comunidad de iDempiere pueda hacer uso de él (tal como lo es la actual LAR).
Saludos,
Emiliano Pereyra
Saludos,
Emiliano Pereyra
Carlos Antonio Ruiz Gomez
Mar 12, 2021, 5:23:06 PM3/12/21
to idempi...@googlegroups.com
Hola Emiliano, bienvenidos a iDempiere.
> 1. Estructura de Proyectos
> ...
> - ¿cómo se llevaría a cabo estas
personalizaciones?
Lo ideal es que revises el por qué de
las personalizaciones, si es algo que el core no soporta es
probable:
* que a todo el mundo le sirva y
entonces la sugerencia es debatirlo y contribuirlo al core
* que haya una forma de hacerlo
mediante un plugin - para esto puedes consultar en foros o
mattermost y te podemos colaborar caso por caso
* que al core le falte alguna forma de
hacerlo más extensible - en ese caso también podemos considerar
hacer los cambios en el core
> - Y en lo casos en que este
mecanismo no sea suficiente, ¿existe alguno otro mecanismo
> en iDempiere para lograr esta
"sobreescritura"?
El mecanismo es que hagas tu propio
fork, pero insisto, lo recomendable es lo que digo arriba. Si
decides hacer tu propio fork vas a tener problemas a futuro para
mantenerte en las versiones de iDempiere.
Si haces un fork, debate con la
comunidad el por qué y qué podemos hacer para evitarlo.
> 2. Localización Colombia
La localización Colombia está
completa. Aquí encuentras los 4 plugin compilados:
Y aquí los fuentes:
> 3. Campos Adicionales en Tablas
Si, este proceso sirve para este
propósito:
> 4. Cambio de ModelValidator a
EventHandler
Aunque el modelo anterior probablemente
es soportado, si, es recomendable que migres a EventHandler, el
cambio no es muy complicado.
Saludos,
Carlos Ruiz
El 12/3/21 a las 15:47, Emiliano
Pereyra escribió:
Emiliano Pereyra
Mar 13, 2021, 9:43:18 AM3/13/21
to iDempiere-es
Hola Emiliano, bienvenidos a iDempiere.
Hola Carlos, muchas gracias.
> 1. Estructura de Proyectos> ...
> - ¿cómo se llevaría a cabo estas personalizaciones?
Lo ideal es que revises el por qué de las personalizaciones, si es algo que el core no soporta es probable:* que a todo el mundo le sirva y entonces la sugerencia es debatirlo y contribuirlo al core* que haya una forma de hacerlo mediante un plugin - para esto puedes consultar en foros o mattermost y te podemos colaborar caso por caso* que al core le falte alguna forma de hacerlo más extensible - en ese caso también podemos considerar hacer los cambios en el core
Entiendo lo que decís, de hecho, tenemos planificado en el proceso de migración revisar las personalizaciones por sobreescritura para determinar si es posible realizar sin ese mecanismo.
Y bueno, en caso de que los mecanismos de extensión (callouts, event handler, etc) nos queden cortos, veremos de debatirlo por acá para ver la posibilidad de sortear el inconveniente.
> - Y en lo casos en que este mecanismo no sea suficiente, ¿existe alguno otro mecanismo> en iDempiere para lograr esta "sobreescritura"?
El mecanismo es que hagas tu propio fork, pero insisto, lo recomendable es lo que digo arriba. Si decides hacer tu propio fork vas a tener problemas a futuro para mantenerte en las versiones de iDempiere.
Si haces un fork, debate con la comunidad el por qué y qué podemos hacer para evitarlo.
Si, la verdad que esta idea del fork no es algo que busquemos, porque entendemos perfectamente las implicancias de esto. La principal razón para migrar desde ADempiere 361.Final es justamente no quedar estancados en una determinada versión.
> 2. Localización Colombia
La localización Colombia está completa. Aquí encuentras los 4 plugin compilados:
Y aquí los fuentes:
Muchas gracias por la referencia. Estuvimos analizando esto, y entendemos que no vamos a necesitar una dependencia directa de este plugin, ya que lo que en su momento utilizamos de la LCO no ha cambiado y en caso de hacerlo, actualizaremos directamente lo que tenemos incorporado en nuestra implementación.
Lo que si vamos a hacer es estudiar la estructura del plugin para realizar el nuestro de una forma similar.
> 3. Campos Adicionales en Tablas
Si, este proceso sirve para este propósito:
Clarísimo, vamos a utilizar esto para actualizar nuestras estructura de datos personalizada de LAR.
> 4. Cambio de ModelValidator a EventHandler
Aunque el modelo anterior probablemente es soportado, si, es recomendable que migres a EventHandler, el cambio no es muy complicado.
Perfecto, avanzaremos en la migración al manejo de EventHandlers.
Una vez, gracias por las recomendaciones y seguimos en contacto.
Saludos,
Emiliano Pereyra
Orlando Curieles
Mar 13, 2021, 11:12:27 AM3/13/21
to idempi...@googlegroups.com
Hola Emiliano, te recomiendo tomar este plugin scaffold que tiene toda la estructural https://github.com/ingeint/idempiere-plugin-scaffold
En el canal de Youtube de idempiere presento como utilizarlo, bienvenido
Saludos
Orlando
--
Has recibido este mensaje porque estás suscrito al grupo "iDempiere-es" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a idempiere-es...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/idempiere-es/268bc85d-0da9-4d72-bb57-a2374a786b07n%40googlegroups.com.
Emiliano Pereyra
Mar 14, 2021, 5:44:53 PM3/14/21
to iDempiere-es
Hola Emiliano, te recomiendo tomar este plugin scaffold que tiene toda la estructural https://github.com/ingeint/idempiere-plugin-scaffoldEn el canal de Youtube de idempiere presento como utilizarlo, bienvenido
Hola Orlando, muchas gracias por la sugerencia, lo voy a ver.
Saludos,
Emiliano Pereyra
Emiliano Pereyra
Mar 17, 2021, 11:13:15 PM3/17/21
to iDempiere-es
Hola a todxs!
Les comento que estamos avanzando con la migración, en particular con la actualización de la estructura de datos de ADempiere 361.Final + LAR a iDempiere 8.2.
Hasta el momento no hemos tenido mayores inconvenientes durante este proceso, salvo algunos que no estamos seguros si pueden representar algún problema futuro y por eso se los consulto. Aplicando los scripts ubicados en migration-historic y migration, desde 360lts-i1.0a (solo los que no estaban en AD361.Final) hasta 8.2z, nos encontramos con esto:
Y por último, 2 consultas más allá de los scripts de migración:
Desde ya, muchas gracias.
Les comento que estamos avanzando con la migración, en particular con la actualización de la estructura de datos de ADempiere 361.Final + LAR a iDempiere 8.2.
Hasta el momento no hemos tenido mayores inconvenientes durante este proceso, salvo algunos que no estamos seguros si pueden representar algún problema futuro y por eso se los consulto. Aplicando los scripts ubicados en migration-historic y migration, desde 360lts-i1.0a (solo los que no estaban en AD361.Final) hasta 8.2z, nos encontramos con esto:
- 360lts-i1.0.a/933_CreditCardsOnline.sql: Este script incorpora las columnas Processed On y Reversal ID a la solapa principal de la ventana Payment y en nuestro caso ya los habíamos incorporado.
psql:933_CreditCardsOnline.sql:554: ERROR: llave duplicada viola restricción de unicidad «ad_field_column»
DETALLE: Ya existe la llave (ad_tab_id, ad_column_id)=(330, 59039).
psql:933_CreditCardsOnline.sql:564: ERROR: llave duplicada viola restricción de unicidad «ad_field_column»
DETALLE: Ya existe la llave (ad_tab_id, ad_column_id)=(330, 55309).
Esto es algo que se repite con otras columnas más, y se debe a que cuando hemos incorporado columnas personalizadas para LAR, al ejecutar el proceso "generar columnas desde bd", además de recuperarnos las nuestras, lo hizo también con otras columnas en las tablas que no estaba en el Diccionario de Aplicación y las dejamos.
¿Esto podría generarnos algún inconveniente a futuro? - i1.0a-i1.0b/201212211841_TICKET-1001758.sql: Mismo problema de columnas agregadas que menciono arriba. En este caso las columnas son de la ventana Order: Volume, Weight, Linked Order, Processed On. Misma pregunta: ¿Esto podría generarnos algún inconveniente a futuro?
- i1.0a-i1.0b/201303191127_TICKET-1001025.sql: Este script modifica 3 vistas que fueron tocadas por nuestra LAR. Las vistas son: c_invoice_v, c_payment_v y rv_bpartneropen.
Entiendo que esta corrección no sería compleja, ya que lo que falla es el orden de los campos, por lo que vamos a tocar el scripts para ordenarlo. Por lo general, cuando necesitamos modificar una vista lo que hacemos es copiarla con el prefijo "lar_" y modificar esa (acá se ve que no se cumplió), pero quiero aprovechar la oportunidad para consultar si esta es una buena práctica para estas situaciones o si tienen algún procedimiento superador para manejar estas modificaciones. - i1.0z/201307182355_PendingSequences.sql: No se pudieron insertar 2 registros en ad_sequence por restricción de unicidad. Evidentemente en ADempiere 361.Final ya existían estos registros.
psql:201307182355_PendingSequences.sql:24: ERROR: llave duplicada viola restricción de unicidad «ad_sequence_name»
DETALLE: Ya existe la llave (ad_client_id, name)=(11, DocumentNo_C_CashPlan).
psql:201307182355_PendingSequences.sql:100: ERROR: llave duplicada viola restricción de unicidad «ad_sequence_name»
DETALLE: Ya existe la llave (ad_client_id, name)=(0, DocumentNo_C_CashPlan).
Para corregir esto ¿alcanza con actualizar el campo ad_sequence_uu de cada uno con uuid_generate_v4()? - i7.1z/202008171626_IDEMPIERE-4426.sql: En este caso no se pudieron eliminar funciones y operadores debido a que están en uso por funcionalidad personalizada para LAR.
psql:202008171626_IDEMPIERE-4426.sql:9: ERROR: no se puede eliminar operador -(timestamp with time zone,numeric) porque otros objetos dependen de él
DETALLE: vista lar_rv_bpartneropenbalance depende de operador -(timestamp with time zone,numeric)
psql:202008171626_IDEMPIERE-4426.sql:11: ERROR: no se puede eliminar función subtractdays(timestamp with time zone,numeric) porque otros objetos dependen de él
DETALLE: operador -(timestamp with time zone,numeric) depende de función subtractdays(timestamp with time zone,numeric)
vista lar_rv_bpartneropenbalance depende de operador -(timestamp with time zone,numeric)
psql:202008171626_IDEMPIERE-4426.sql:52: ERROR: no se puede cambiar el tipo de retorno de una función existente
SUGERENCIA: Use DROP FUNCTION subtractdays(timestamp with time zone,numeric) primero.
psql:202008171626_IDEMPIERE-4426.sql:77: ERROR: el operador - ya existe
¿Es posible que ignorar este error o es necesario dropear nuestras funciones, ejecutar el script y rehacer las mismas con estas nuevas funciones/operadores?
Y por último, 2 consultas más allá de los scripts de migración:
- ¿Es necesario que actualicemos todos los campos *_uu de los registros que hemos incorporado por la configuración de LAR en distintas tablas del DA (ad_table, ad_sequence, ad_column, etc)?
- ¿Que significa la "z" en los directorios de los scripts de migración? (por ejemplo i8.2z)
Desde ya, muchas gracias.
Saludos,
Emiliano Pereyra
Carlos Antonio Ruiz Gomez
Mar 18, 2021, 7:14:15 AM3/18/21
to idempi...@googlegroups.com
Hola Emiliano,
Te cuento cómo es que yo normalmente
hago el proceso cuando estoy migrando bases de datos tan antiguas.
La mayoría de esto ya lo hiciste pero pues lo describo completo:* cargar la base de producción en
pruebas
* aplicar TODOS los scripts de
migración (en ocasiones hago un solo script gigantesco, en
ocasiones los hago uno por uno)
* analizar los errores, esto puede
llevar a:
** crear scripts pre-migración que
corrigen los problemas que están dando errores
*** por ejemplo en esos casos que
encuentras normalmente intento cambiar el _ID y el _UU de los
registros con problema
*** cambiar el _UU no es de impacto,
pero cambiar el _ID si lo es, tienes que hacer un script que
cambie el ID en todas las tablas que lo tienen como llave foránea
dentro de una transacción
*** la otra posibilidad es que
simplemente tomes nota del registro y pospongas esta tarea para
hacerlo con el programa Migrate ID
** en algunos casos los scripts no se
pueden ejecutar antes de la migración sino en medio de y pues lo
que hago es, o corregir el script (dejando documentada la razón) o
añadir un script intermedio
** darme cuenta que el error se puede
ignorar, tomo nota, y decido si pongo en comentarios esa parte del
script o simplemente ignoro el error
* este ciclo lo repito varias veces
hasta que no tenga errores (o todos los errores sean controlados)
** esta parte puede tomar bastante
tiempo si la base tiene muchos registros, hay scripts que toman
demasiado tiempo, y como haces varias iteraciones pues es un
proceso demasiado dispendioso, aquí también toca tomar decisiones
si las tablas muy grandes se recortan durante las pruebas, o si se
analiza cada script para hacerlo más veloz (a veces creando
índices temporales)
También es imporante:
* Leer las notas de migración
https://wiki.idempiere.org/en/NF6.2_Migrate_ID
* En algunos casos cuando el
diccionario ha sido cambiado - entonces comparo el diccionario
original vs el diccionario modificado ANTES de aplicar scripts
para decidir si es necesario reaplicar cambios al final (una
herramienta que me ha servido para comparar datos dentro de tablas
es DB
Solo)
Uno puede optar por dejar los IDs y UUs
sin modificar, pero podría tener consecuencias, tocaría revisar si
el ID oficial no es usado en iDempiere en algún programa
hardcoded, hemos tratado de recopilarlos todos en la clase
org.compiere.model.SystemIDs
Yo soy más bien perfeccionista entonces
nunca me gusta dejar los IDs diferentes. Ya entrados en gastos de
la migración es mejor hacerla perfecta.
Sobre las vistas, si, la forma como lo
estás haciendo también es como intento llevarlo yo, nuevas
vistas. Y también debes asegurar que los cambios a las vistas se
apliquen o muchas cosas puede que no funcionen.
> ¿Es necesario que actualicemos
todos los campos *_uu de los registros que hemos incorporado por
la configuración de
> LAR en distintas tablas del DA
(ad_table, ad_sequence, ad_column, etc)?
Si, eso también lo hace el proceso UUID
Generator
> ¿Que significa la "z" en los
directorios de los scripts de migración? (por ejemplo i8.2z)
Significa "scripts de la siguiente
versión después de la 8.2" - cuando liberamos una versión (por
ejemplo la 8.2) aún no sabemos cómo se va a llamar la próxima
(probablemente sea 9.1, pero de pronto podría ser 8.3, o cualquier
otra notación que decidamos) - entonces como aún no sabemos qué
nombre ponerle al folder simplemente lo llamamos i8.2z - la z
implicando que es la siguiente versión a 8.2
Saludos,
Carlos Ruiz
El 18/3/21 a las 04:13, Emiliano
Pereyra escribió:
Emiliano Pereyrac8287594dce0n%40googlegroups.com.
Emiliano Pereyra
Mar 18, 2021, 2:40:07 PM3/18/21
to iDempiere-es
Hola Carlos,
Una vez más, muchas gracias por estas aclaraciones. Vamos a iterar la tarea de migración siguiendo estas recomendaciones que nos haces.
Saludos,
Emiliano Pereyra
Emiliano Pereyra
Mar 19, 2021, 4:16:58 PM3/19/21
to iDempiere-es
Hola Comunidad!
*** la otra posibilidad es que simplemente tomes nota del registro y pospongas esta tarea para hacerlo con el programa Migrate ID
Carlos, te hago una consultar respecto a esto. Ya estoy levantando iDempiere con la base preliminar de migrada de ADempiere+LAR para poder corregir los IDs como lo sugeriste, pero me encuentro con el inconveniente de que en el menú no están las entradas completas de las nuevas funcionalidades del DA, y en particular no está el proceso "Migrate ID".
¿Existe alguna forma de actualizar las entradas de menú de iDempiere o esto es algo que debemos realizar manualmente?
Desde ya, muchas gracias.
Saludos,
Emiliano Pereyra.
Carlos Antonio Ruiz Gomez
Mar 23, 2021, 4:38:52 AM3/23/21
to idempi...@googlegroups.com
Hola Emiliano,
Si no está el proceso Migrate ID en el
menú entonces algo falló en la migración, o no estás en el role
System Administrator.
Saludos,
Carlos Ruiz
Am 19.03.21 um 21:16 schrieb Emiliano
Pereyra:
--
Emiliano Pereyra
Mar 23, 2021, 8:17:08 AM3/23/21
to iDempiere-es
Hola Carlos,
Gracias por tu respuesta. Efectivamente esta todo OK, mi error fue no ejecutar el proceso de actualización de accesos del rol para System.
Una vez hecho hecho, tengo todas las entradas de menú de iDempiere.
Saludos,
Emiliano Pereyra
Emiliano Pereyra
Apr 14, 2021, 8:52:35 AM4/14/21
to iDempiere-es
El sábado, 13 de marzo de 2021 a las 13:12:27 UTC-3, Orlando Curieles escribió:
Hola Emiliano, te recomiendo tomar este plugin scaffold que tiene toda la estructural https://github.com/ingeint/idempiere-plugin-scaffoldEn el canal de Youtube de idempiere presento como utilizarlo, bienvenido
Buenos días comunidad!
Orlando, te cuento (y les cuento a todos) que estamos comenzando a probar lo que sería la construcción de los plugins OSGi para iDempiere, con el objetivo de iniciar la migración del código de LAR (la base creo que ya quedó correctamente migrada, aunque todavía faltan pruebas más exaustivas), y como me recomendaste, estoy usando el plugin scaffold.
Cree el plugin ar.com.comit.lar.base, y cuando ejecuto el build fallá porque uno de los test no pasa. Entiendo que debe ser algo relacionado al idioma del SO/JVM (Locale), pero no logro determinar como corregirlo:
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.37 s <<< FAILURE! - in ar.com.comit.lar.base.util.FileTemplateBuilderTest
[ERROR] ar.com.comit.lar.base.util.FileTemplateBuilderTest.createFileTemplate Time elapsed: 0.273 s <<< FAILURE!
java.lang.AssertionError:
Expecting:
<"<invoice>
<name>Mohamed Macejkovic</name>
<id>123-73-4373</id>
<lines>
<line>
<product name="iNWkS" price="8,079"/>
</line>
</lines>
</invoice>">
to contain:
<"<product name="iNWkS" price="8.079"/>">
at ar.com.comit.lar.base.util.FileTemplateBuilderTest.createFileTemplate(FileTemplateBuilderTest.java:57)
Por otro lado, revisando la estructura del plugin generado por scanffold, hay algo que no termino de entender para que sirve: el módulo (se llama así?) ar.com.comit.lar.base.targetplatform.
Pregunto esto porque estuve revisando/"estudiando" casi todos los videos del canal "evenos Consulting GmbH" (que por cierto me resultaron muy útiles para comenzar a entender como funciona iD) vi que crean directamente los plugins desde eclipse y al momento de probarlos directamente los activan en la configuración de ejecución del iDempiere y listo. Entiendo que esto es más para un propósito didactico y no describe el proceso de despliegue de los plugins en un entorno real, pero me pareció importante mencionarlo para seguir entendiendo como es la dinámica de desarrollo en el este nuevo entorno.
Orlando, te cuento (y les cuento a todos) que estamos comenzando a probar lo que sería la construcción de los plugins OSGi para iDempiere, con el objetivo de iniciar la migración del código de LAR (la base creo que ya quedó correctamente migrada, aunque todavía faltan pruebas más exaustivas), y como me recomendaste, estoy usando el plugin scaffold.
Cree el plugin ar.com.comit.lar.base, y cuando ejecuto el build fallá porque uno de los test no pasa. Entiendo que debe ser algo relacionado al idioma del SO/JVM (Locale), pero no logro determinar como corregirlo:
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.37 s <<< FAILURE! - in ar.com.comit.lar.base.util.FileTemplateBuilderTest
[ERROR] ar.com.comit.lar.base.util.FileTemplateBuilderTest.createFileTemplate Time elapsed: 0.273 s <<< FAILURE!
java.lang.AssertionError:
Expecting:
<"<invoice>
<name>Mohamed Macejkovic</name>
<id>123-73-4373</id>
<lines>
<line>
<product name="iNWkS" price="8,079"/>
</line>
</lines>
</invoice>">
to contain:
<"<product name="iNWkS" price="8.079"/>">
at ar.com.comit.lar.base.util.FileTemplateBuilderTest.createFileTemplate(FileTemplateBuilderTest.java:57)
Por otro lado, revisando la estructura del plugin generado por scanffold, hay algo que no termino de entender para que sirve: el módulo (se llama así?) ar.com.comit.lar.base.targetplatform.
Pregunto esto porque estuve revisando/"estudiando" casi todos los videos del canal "evenos Consulting GmbH" (que por cierto me resultaron muy útiles para comenzar a entender como funciona iD) vi que crean directamente los plugins desde eclipse y al momento de probarlos directamente los activan en la configuración de ejecución del iDempiere y listo. Entiendo que esto es más para un propósito didactico y no describe el proceso de despliegue de los plugins en un entorno real, pero me pareció importante mencionarlo para seguir entendiendo como es la dinámica de desarrollo en el este nuevo entorno.
Reply all
Reply to author
Forward
0 new messages