Java-buildpack: jrebel 6.4.2a evita la compilación sin conexión

Creado en 7 abr. 2016  ·  10Comentarios  ·  Fuente: cloudfoundry/java-buildpack

Hola,

Jrebel 6.4.2a se lanzó hace unos días y el buildpack no está contento con "2a":
$ bundle exec rake package OFFLINE = true
rastrillo abortado!
Versión micro no válida '2a'

Cambiar config / jrebel_agent.yml a 6.4.2 no soluciona el problema. Logré construir el paquete de compilación sin conexión eliminando la última línea de build / staging / resources / cache / https% 3A% 2F% 2Fdl.zeroturnaround.com% 2Fjrebel% 2Findex.yml.cached

Comentario más útil

El equipo de cambio de cero tiene un archivo de índice no válido. Ambos me pondré en contacto con ellos para mejorarlo y agregaré una solución al paquete de compilación que advertirá e ignorará los valores ilegales.

Todos 10 comentarios

También estoy enfrentando el mismo problema desde ayer para el paquete de compilación Liberty. ¿Puede confirmar que eliminar la línea 6.4.2a de yml en caché no es un problema?

El equipo de cambio de cero tiene un archivo de índice no válido. Ambos me pondré en contacto con ellos para mejorarlo y agregaré una solución al paquete de compilación que advertirá e ignorará los valores ilegales.

¿Por qué no cambiar /lib/java_buildpack/util/tokenized_version.rb valid_major_minor_or_micro para usar \ w en lugar de \ d para las personas que quieren usar esa nueva versión de jrebel?

154 def valido_mayor_minor_o_micro (mayor_minor_o_micro)
155 mayor_menor_o_micro = ~ / ^ [\ w] * $ / || major_minor_or_micro = ~ / ^ + $ /
156 final

El número de versión se especifica y documenta aquí . Los cambios a eso serían un cambio rotundo. Depende de los repositorios cumplir con la especificación en lugar de que la especificación cambie para cumplir con los repositorios.

tiene sentido. Gracias.

¿Alguna actualización sobre esto?

No he recibido una respuesta de JRebel sobre la reparación de su repositorio, pero la compilación en master ahora es más tolerante con el problema.

Lo siento, esto sucedió. No conocíamos las restricciones sobre el formato de la versión. Actualizaremos el repositorio lo antes posible y también te lo haré saber aquí.

@nebhale No pude encontrar tu correo electrónico. Para referencia futura, para que podamos evitar los agujeros negros de la comunicación, ¿cómo trató de comunicarse?

@mirkoadari Le envié un correo electrónico a Mark Taber que, sin duda, era una http://cloudfoundry.slack.com y encontrarme en # java-buildpack. Si quieres correo electrónico, es bhale @.

Actualizamos el repositorio. Si hay algún problema en el futuro, envíe un correo electrónico a [email protected]. Esa es la forma más rápida de llegar a una resolución. Perdón por las molestias a todos.

¿Fue útil esta página
0 / 5 - 0 calificaciones