Etiqueta: eclipse

EclipseGavab 2.0

13 comentarios

EclipseGavab es una distribución de Eclipse que desarrollamos en Sidelab y venimos usando desde hace más de 5 años en la Universidad Rey Juan Carlos como el IDE de referencia en asignaturas de paradigmas y programación. El principal valor de EclipseGavab es que integra soporte para diferentes de lenguajes de programación permitiendo que los alumnos se familiaricen con un único entorno y se puedan centrar en el lenguaje concreto. En aquellos casos en que ha sido posible, incluye también los correspondientes compiladores/intérpretes/máquinas virtuales de dichos lenguajes.

Lenguajes soportados:

  • Java
  • C/C++ (en Windows incluye compilador basado en cygwin)
  • Pascal y ObjectPascal (en Windows incluye el compilador FreePascal)
  • PascalFC (incluye compilador e intérprete en Windows y Linux)
  • Ruby (en Windows incluye intérprete Ruby)
  • Haskell (en Windows incluye ghc)

Puedes descargar EclipseGavab de los siguientes enlaces:

  • EclipseGavab 2.0 Windows Installer (300Mb). Windows XP and Windows Vista installer. Requires 660 Mb.
  • EclipseGavab 2.0 tar.gz for Linux. A tar.gz Linux distribution. It requires the installation of the following tools: Java SE 6 for executing EclipseGavab and Java programming; gcc for C/C++ programming; FreePascal for Pascal programming; ghc for Haskell programming; and Ruby for Ruby programming.

En Ubuntu, los paquetes necesarios son: build-essential, fp-compiler, fp-units-base, fp-units-rtl, ghc6, ruby, sun-java6-jre, y se pueden instalar con el siguiente comando:

sudo apt-get install build-essential fp-compiler fp-units-base fp-units-rtl ghc6 ruby sun-java6-jre

[Editado el 7/2/2014]

En Ubuntu 64 bits es necesario usar una versión Java de 32 bits. En Windows esto no es necesario porque EclipseGavab lleva una versión de java de 32 bits embebida. Se puede descargar el jdk 7 de 32 bits de esta url, pulsando en «Java Download» y seleccionando después la versión «linux x86» de extensión tar.gz.

Una vez descargado Java, se descomprime (tar -xvzf jdk-7-xx.tar.gz) en el home del usuario y se edita el fichero eclipse.ini para que utilice esta versión de Java. Supongamos que la ruta es «/home/user/jdk-7-u51», el fichero eclipse.ini debe incluir las siguientes líneas inmediatamente antes de la opción «-vmargs»:

-vm
/home/user/jdk-7-u51/bin/java

Enjoy programming!

Resolución de dependencias en plugins de Eclipse con Maven

Deja un comentario

En la lista de distribución de tycho, he visto una interesante discusión sobre cómo tener una dependencia a un jar en un plugin que se resuelva a través de Maven. Parece que no es problema hacer esto cuando se construye el artefacto, pero en desarrollo tiene que estar el jar forzosamente en el workspace o habrá problemas de compilación.

En Sidelab estamos comenzando a migrar algunos proyectos a Maven (puedes ver cómo lo hemos hecho en los proyectos Pascaline y Optsicom RES), y necesitamos tener un ojo puesto en este tipo de cuestiones. Concretamente utilizamos el plugin m2eclipse para Eclipse y tycho para construir artefactos PDE (plugins, features, repositorios p2).

En Pascaline, por ejemplo, tenemos un jar en uno de los plugins que me gustaría que se resolviese dinámicamente cuando haces un checkout del repositorio. Sé que puedo hacer esto cuando hago un build con Maven, porque hay formas de generar artefactos en previamente a la construcción para que sean utilizados en la compilación (como se comenta  en el mismo hilo), pero lo realmente interesante sería hacer un checkout del repositorio y que el plugin m2eclipse resolviera las dependencias materializando el jar desde el repositorio Nexus que tenemos instalado en SidelabCode. Actualmente, el jar, situado en una carpeta lib del plugin, está alojado también en el repositorio, por comodidad. Esta situación es desaconsejable y hace tedioso pasar de una versión a otra del mismo, porque hay que quitar un jar y sustituirlo por otro, pero sobre todo, no queda claro en ningún sitio qué versión del jar se está utilizando. Por supuesto el jar puede incluir en el nombre la versión, pero preferiría que el plugin declarara qué versión del jar necesita y esa versión fuera incorporada en el proyecto dinámicamente.

Creo que esto lo puede hacer Maven automáticamente, siempre que las dependencias se declaren en el POM. Pero en este caso la dependencia se especifica en el fichero build.properties del plugin, que es manejado por tycho. Este el problema principal del enfoque Manifest first frente al enfoque POM first. En el enfoque Manifest first la construcción está dirigida por tycho y es leída de los descriptores del plugin (Manifest, build.properties y plugin.xml). En el enfoque POM first, la configuración es leída del POM. De momento, por tanto, no existe una solución satisfactoria. Me pregunto si tycho podría proporcionar un goal que hiciera exactamente esto y que pudiera ejecutarse tras un checkout para materializar los jars/plugins/etc que conforman las dependencias del código descargado. ¿Alguna idea al respecto?

[UPDATE] En este ejemplo parecen hacer justamente eso: descargar un jar en una carpeta. Por lo visto esta acción hay que engancharla al lifecycle-mapping de m2e.

Modularización tipo OSGi en aplicaciones Flash

Deja un comentario

La Fundación Eclipse recibió hace seis meses una petición para un nuevo proyecto, bajo el paraguas del proyecto Eclipse Runtime, que pretende llevar las ventajas de OSGi y el enfoque de puntos de extensión de Eclipse a las aplicaciones desarrolladas para la plataforma Flash. En la propuesta no dicen que vayan a implementar OSGi, simplemente «va a estar inspirado en OSGi».

Los objetivos son bastante ambiciosos y entre otras cosas pretenden desarrollar una plataforma para la construcción de aplicaciones ricas (RCP), así como herramientas de soporte para facilitar el trabajo de los desarrolladores que utilicen estas características. El proyecto contará con la donación del código inicial de Potomac por parte de la empresa ElementRiver.

Como no tenía noticia de que Eclipse se estuviera posicionando también como IDE para Flash, no me he podido resistir a echarle un vistazo a la propuesta, y he observado un par de detalles que me hacen pensar si llegará a ser aceptada. En primer lugar no veo mentores para el proyecto. En la sección correspondiente simplemente se indica TBD (to be defined). Los proyectos Eclipse deben ser «sponsorizados» por dos miembros del Architecture Council. El hecho de que no hayan sido definidos todavía podría indicar que hay poco interés por parte de la Fundación Eclipse en el proyecto.

En segundo lugar, especifican claramente que aunque el desarrollo se llevaría a cabo en el seno de la Fundación Eclipse y el código estaría alojado en los servidores de Eclipse, el contexto natural de utilización del framework sería Adoble Flash Builder IDE, el entorno de desarrollo para aplicaciones Flash de Adobe (sección Adobe Committment). Como no parece razonable que un proyecto desarrollado dentro de la propia Fundación Eclipse no pueda ser utilizado sin una herramienta comercial como es el IDE para Flash de Adobe, la empresa propone como solución salomónica proporcionar una licencia del IDE de Adobe para los committers del proyecto.

Yo lo veo cogido por los pelos…

Google propone dos proyectos a la plataforma Eclipse

Deja un comentario

Google va a donar dos proyectos a la fundación Eclipse. El primero de ellos es WindowBuilder, una herramienta de diseño de interfaces de usuario que soporta SWT y Swing, al estilo del proyecto Visual Editor (VE) que se había quedado algo atrás. El segundo es CodePro Profiler, un profiler de aplicaciones Java.  Ambos proyectos pasaron a manos de Google cuando ésta adquirió Instantiations.

La forma de donar el código es un poco esotérica, dado que deben seguir la norma de cualquier otro proyecto, el denominado Eclipse Development Process: han hecho dos propuestas de proyectos a la Fundación Eclipse (ambas bajo el paraguas del Eclipse Tools Project): WindowBuilder y Runtime Analysis Tools. Estas dos propuestas tienen que ser aprobadas y después el código tiene que pasar el estricto IP process. Este es el proceso por el cual la Fundación Eclipse acepta contenido, lo redistribuye y en general gestiona todo lo referente a la propiedad intelectual de la Fundación.

Lo interesante es que han dicho que van a tratar de alcanzar el Release Train de Indigo, la siguiente versión de Eclipse (de la que ya hablamos aquí) que verá la luz en Junio de 2011. Un Release Train en Eclipse es una «macro» release, dado que múltiples proyectos acuerdan sacar conjuntamente una nueva versión en la fecha señalada. En el caso de Eclipse esto se hace cada año en junio. Si tenemos en cuenta que el proyecto debe aprobarse todavía, después entra en fase de incubación y finalmente pasa a la fase de madurez, no sé si realmente les va a dar tiempo.

Lo que está claro es que, salvo que sorprendentemente decidieran algo en otro sentido, el código será aceptado por la Fundación con licencia EPL. Es una buena noticia saber que Eclipse contará en breve con un profiler integrado (algunos usamos VisualVM, que tiene muy buena integración con Eclipse) y con una herramienta de diseño de interfaces que, además, promete integrar también GWT.

La noticia original la vimos de la mano de Mike Milinkovich: Christmas Comes Early for Java Developers. Otros miembros de la Fundación también lo han comentado. Y algunos no han querido que nos olvidemos de aquellos que donan año tras año miles de líneas de código a Eclipse a través de sus committers:

@: News:Google donates $5m worth code to Eclipse. Not-In-News:IBM donating >$5m worth code *every* year via its committers

Kudos to IBM and every Eclipse committer out there!

Optsicom RES – Oferta de PFC en sidelab

Deja un comentario

En sidelab estamos ofertando un Proyecto de Fin de Carrera o un Trabajo de Fin de Máster.

El objetivo del proyecto es distribuir la ejecución de varios algoritmos sobre un conjunto de máquinas que forman un cluster. Para ello, se utilizará el framework GridGain. Además, debido a las facilidades que aporta este framework de desarrollo de aplicaciones, incluso la distribución de la ejecución se podría hacer en la nube en servicios como Amazon.

Este proyecto se enmarca en el contexto del grupo de investigación Optsicom. Los miembros de Optsicom diseñan e implementan algoritmos y realizan numerosos experimentos (ejecuciones de esos algoritmos con diferentes datos) para comprobar la robustez y calidad de los mismos. Estos experimentos pueden llegar a tardar días en completarse.

Los experimentos consisten en ejecutar uno o varios algoritmos sobre un número más o menos grande de datos de ejemplo (a los que llamamos instancias). Hay que ejecutar cada algoritmo sobre cada instancia. Si tenemos 3 algoritmos y 100 instancias, hay que ejecutar un total de 300 experimentos. Esto presenta una buena oportunidad para paralelizar la ejecución de los experimentos cuando hay disponibles varias máquinas.

GridGain ofrece la posibilidad de configurar un conjunto de máquinas para que se puedan utilizar de manera transparente para ejecutar tareas. En nuestro caso las tareas son experimentos. El objetivo del proyecto consiste, pues, en proporcionar una configuración de experimentos que permita utilizar GridGain para paralelizar la experimentación.

El grupo Optsicom está desarrollando Optsicom Optimization Suite, una plataforma para la investigación en optimización. Esta suite dispone de la herramienta Optsicom Remote Experiment System (Optsicom RES). Esta herramienta está formada por un plugin de Eclipse y un servicio que se instala en una máquina remota y permite la ejecución remota de cualquier programa Java desde el propio entorno Eclipse. El presente proyecto se concibe como una ampliación de la herramienta Optsicom RES, para permitir la ejecución de los algoritmos desarrollados en varias máquinas.

Si estás interesado en la temática del proyecto, antes de ponerte en contacto con nosotros debes tener en cuenta las siguientes cuestiones:

  • Por su dificultad y su envergadura, el proyecto sólo se oferta para alumnos de la Ingeniería en Informática o a los alumnos que hayan cursado el Máster de Sistemas Telemáticos e Informáticos.
  • Es imprescindible tener un conocimiento medio-alto de la tecnología Java.
  • Hay que tener la suficiente disponibilidad como para dedicar varias horas diarias al proyecto. No es un proyecto que se pueda dejar para los fines de semana.
  • El objetivo del presente proyecto es realizar una aplicación funcional y de calidad, no sólo un prototipo o prueba de concepto. Por este motivo, hay que seguir rigurosamente las buenas prácticas en ingeniería del software: uso de sistemas de control de versiones, programación de test, integración continua, etc.

Si estás interesado en el proyecto, manda tu currículum y tu expediente académico a micael.gallego[at]urjc.es o francisco.gortazar[at]urjc.es.

Novedades en el proyecto Mylyn de Eclipse

1 comentario

El proyecto Mylyn de Eclipse, que viene instalado por defecto desde hace algunas versiones, convierte la interfaz de este IDE en una interfaz orientada a la tarea, integrándose con los sistemas de gestión de código (SCM) como Subversion o git y con los sistemas de control de bugs/tickets (como Bugzilla o Trac). Nosotros lo utilizamos habitualmente mediante una extensión que permite trabajar con Redmine.

Este proyecto es noticia, y merece una entrada en el blog, por dos razones. La primera es que ha sido promocionado como Top-level project dentro de Eclipse. Anteriormente, formaba parte del proyecto Tools. Lo más interesante de todo esto es que Mylyn (antes Mylar) fue el resultado de la tesis de Mik Kersten.

La segunda razón, viene de la mano de un proyecto de Google Summer of Code. Acaban de liberar una versión preliminar del conector Hudson para Mylyn. Por lo visto, Mylyn dispone de una API que permite conectar Mylyn a diferentes sistemas de integración continua simplemente desarrollando un conector para ellos.

Vista del Hudson de sidelab con el conector para Hudson de Mylyn

Ahora que Mylyn es un proyecto de primer nivel dentro de la estructura de Eclipse, tienen un montón de ideas para desarrollar y seguir innovando en el IDE. Y nosotros en Sidelab vamos a estar muy pendientes de esto…

Un ejemplo de ingeniería

Deja un comentario

En un mundo donde lo habitual son los proyectos fuera de plazo, por séptimo año consecutivo, la Fundación Eclipse libera, en la fecha fijada, sin retrasarse un solo día, Eclipse Helios.

Sin duda esto es algo a lo que ya estamos acostumbrados, pero no me gustaría dejar de apuntar que es una auténtica obra de ingeniería. Hay que tener en cuenta que no se libera un único producto: 38 proyectos se comprometieron a liberar sus versiones este 23 de junio, en lo que se denomina Eclipse Release Train, que es, efectivamente, un auténtico tren de productos diferentes. Que 38 proyectos distintos lleguen a esta cita anual, sin retrasos, es todo un logro.

Basta echar un vistazo a la página de descargas para darse cuenta de lo que esto significa.

¡Enhorabuena a los desarrolladores de Eclipse!

Enjoy developing.

Es hora de contribuir a Eclipse

Deja un comentario

Google Summer of Code, un año más, pone en contacto mentores y estudiantes para contribuir a proyectos libres. Eclipse no podía quedarse fuera. En esta página puedes proponer tus ideas o demostrar tu interés, como mentor o estudiante, en algunas de las ideas que ya están publicadas. Lo único que necesitas es una cuenta en el Bugzilla de Eclipse que puedes crear registrándote. Por supuesto, tienes que darte de alta en la página de Google Summer of Code para participar (menores hasta el 12 de marzo, estudiantes del 29 de marzo al 9 de abril).

Hay algunas realmente interesantes, como la integración de Egit con Mylyn (al estilo de Subversive), un conector de Buzz para ECF, o el desarrollo de DSLs ejecutables en la máquina virtual de Java.

Si eres estudiante y te interesa Eclipse, puedes contribuir a este entorno de desarrollo y participar a la vez en el Google Summer of Code.