jboss-user
[Arriba] [Todas las Listas]

Re: [jboss-Usuario] [JBoss Herramientas] - Soportando versiones en grand

To: User development <jboss-user@xxxxxxxxxxxxxxx>
Subject: Re: [jboss-Usuario] [JBoss Herramientas] - Soportando versiones en grande multi-módulo osgi proyectos
From: Ian Bull <do-not-reply@xxxxxxxxx>
Date: Sat, 17 Sep 2011 22:54:33 -0400
Auto-submitted: yes
Delivery-date: Sat, 17 Sep 2011 22:55:54 -0400
Envelope-to: traductor@xxxxxxxxxxx
List-archive: <http://lists.jboss.org/pipermail/jboss-user>
List-help: <mailto:jboss-user-request@lists.jboss.org?subject=help>
List-id: The JBoss User main mailing list <jboss-user.lists.jboss.org>
List-post: <mailto:jboss-user@lists.jboss.org>
List-subscribe: <https://lists.jboss.org/mailman/listinfo/jboss-user>, <mailto:jboss-user-request@lists.jboss.org?subject=subscribe>
List-unsubscribe: <https://lists.jboss.org/mailman/listinfo/jboss-user>, <mailto:jboss-user-request@lists.jboss.org?subject=unsubscribe>
Reply-to: The JBoss User main mailing list <jboss-user@xxxxxxxxxxxxxxx>
Sender: jboss-user-bounces@xxxxxxxxxxxxxxx
Ian *Bull [*http://comunidad.*jboss.*org/Personas/*irbull] comentado en

"Soportar versiones en grande *multi-módulo *osgi proyectos"

para ver todos los  comentarios en este *blog correo, visita: *http://comunidad.*jboss.*org/Herramientas/de comunidad/*blog/2011/09/17/soportando-con-versiones-dentro-grande-*multi-módulo-*osgi-comentario#de proyectos-7626

--------------------------------------------------
dejaré el *OSGi batalla de puristas el *OSGi partes, pero de un *p2 perspectiva veo algunas cosas que realmente te podrían conseguir en problema. En particular, es todo relacionado a la versión 1.2.3.GA.  (O incluso peor 1.0.0).  *p2 usos y Versión/de ID como único *identifier.  Tan, si tienes un *bundle llamado *Foo versión 1.2.3.el GA y tú realizan que te *messed arriba de la complexión, así que construiste otra vez. Ahora tienes dos conjuntos diferentes de *bytes con el mismo ID de Unique (*Foo/1.2.3.GA).

Si *p2 ha *cached el original un *somewhere  (o alguien lo tiene instalado), entonces es *anybodies suposición *wich la versión conseguirá *fetched.  Esto es por qué nadie tiene que nunca reutilización la misma versión para el mismo *bundle.

*PDE/La Complexión toma 1.0.0.*qualifier Y lo reemplaza con un *timestamp, tan al menos parte de los cambios de versión.

Otro (relacionado) problema.  Si *nada* cambia en un *bundle entonces la versión no tendría que cambiar. Dejado decir *JBoss versión 1.2.3 es liberado.  Mañana liberas 1.2.4 y sólo 1 línea de código en un *bundle ha cambiado.  Si todo vuestro *bundles conseguir su *versoin chocado, entonces los usuarios descargarán todo 628 artefactos, en vez del artefacto solo que cambió.  

*BTW, el *Eclipse el proyecto tiene sobre 400 *bundles y dirigen sus versiones sin chocar cada *bundle para cada complexión.  hay *techniques para hacer esto con éxito incluyendo archivos de mapa, Herramientas de API y el *Jar *Comparator.

Aclama,
Ian
--------------------------------------------------

Ian Bull [http://community.jboss.org/people/irbull] commented on

"Coping with versions in large multi-module osgi projects"

To view all comments on this blog post, visit: http://community.jboss.org/community/tools/blog/2011/09/17/coping-with-versions-in-large-multi-module-osgi-projects#comment-7626

--------------------------------------------------
I'll let the OSGi purists battle the OSGi parts, but from a p2 perspective I see some things that could really get you in trouble. In particular, it's all related to the version 1.2.3.GA.  (or even worse 1.0.0).  p2 uses and ID/Version as a unique identifier.  So, if you have a bundle called Foo version 1.2.3.GA and you realize that you messed up the build, so you built again. Now you have two different sets of bytes with the same Unique ID (Foo/1.2.3.GA).

If p2 has cached the original one somewhere  (or someone has it installed), then it's anybodies guess wich version will get fetched.  This is why nobody should ever reuse the same version for the same bundle.

PDE/Build takes 1.0.0.qualifier and replaces it with a timestamp, so at least part of the version changes.

Another (related) problem.  If *nothing* changes in a bundle then the version should not change. Let's say JBoss version 1.2.3 is released.  Tomorrow you release 1.2.4 and only 1 line of code in one bundle has changed.  If all your bundles get their versoin bumped, then users will download all 628 artifacts, instead of the single artifact that changed.  

BTW, the Eclipse project has over 400 bundles and they manage their versions without bumping each bundle for each build.  There are techniques for doing this successfully including map files, API Tools and the Jar Comparator.

Cheers,
Ian
--------------------------------------------------

_______________________________________________
*jboss-Usuario *mailing lista
*jboss-user@xxxxxxxxxxxxxxx
*https://listas.*jboss.*org/*mailman/*listinfo/*jboss-Usuario
_______________________________________________
jboss-user mailing list
jboss-user@xxxxxxxxxxxxxxx
https://lists.jboss.org/mailman/listinfo/jboss-user
<Anterior por Tema] Tema Actual [Siguiente por Tema>