Java Sortie de JOFFAD 2.0 !

Posté par Stéphane Traumat (page perso) le 10/06/04 à 08:16. Modéré par Florent Zara.

juin

2004

Nous sommes heureux d'annoncer la sortie de JOFFAD 2.0

Sous licence LGPL, JOFFAD (Java Open Framework For Application Development) est un modèle de projet J2EE sous JOnAS qui intègre :
- Une arborescence de répertoire simple, réutilisable et documentée.
- Des scripts Ant fonctionnels qui vous permettent de réaliser les tâches basiques d'un projet J2EE (compilation, déploiement, ... ).
- Des outils libres régulièrement utilisés comme XDoclet, JUnitEE ou Struts.

JOFFAD (1 clic)

Le but de JOFFAD est simple :
- Un développeur démarrant un projet ne devra pas perdre de temps à créer une structure de répertoire, des scripts ant ou à installer les outils libres les plus utilisés.
- Un développeur rejoignant un projet ne devra pas perdre de temps à trouver les sources, compiler, packager, déployer...
- Plus globalement, les développeurs utilisant JOFFAD auront un modèle commun de développement.

Bref, JOFFAD est un projet J2EE vide qui servira de base commune à l'ensemble de vos projets.

En téléchargeant JOFFAD 2.0, vous aurez un exemple de projet basique avec :
- un EJB de session offrant une fonction sum().
- un test unitaire de cette fonction.
- une application en ligne de commande permettant de faire la somme de deux nombres.
- une application Struts permettant de faire la somme de deux nombres.
Pour faire fonctionner cette application, il vous suffira de taper la commande suivante : ant all deploy.all et de lancer JOnAS !
Vous pouvez partir de ce projet simple pour comprendre avec J2EE et ensuite utiliser l'IDE Eclipe (par exemple) pour construire un plus gros projet.

PS :
- Nous prévoyons d'intégrer JBoss d'ici la fin de l'été si certains veulent nous aider.
- Je suis en ce moment en train d'écrire un tutoriel complet, sa mise à disposition sera annoncé sur la ml joffad-announce@lists.sourceforge.net.
- Nous faisons des séminaires gratuits de présentation de J2EE et des logiciels libres, n'hésitez pas à nous contacter à ce sujet !

# Tutorial ?

Posté par VACHOR (page perso) le 10/06/04 à 09:51. Évalué à 0.

Manque un bon tutorial pour ce truc.

Répondre
- [^] # Re: Tutorial ?
  
  Posté par Stéphane Traumat (page perso) le 10/06/04 à 09:55. Évalué à 4.
  
  Je suis en train de l'écrire mais ca prend du temps :)
  
  Répondre
  - [^] # Re: Tutorial ?
    
    Posté par VACHOR (page perso) le 10/06/04 à 17:18. Évalué à -1.
    
    Il est vrai que faire les choses bien prend beaucoup plus de temps qu'on se l'imagine !
    Cela paiera surement en audience sur le projet...
    
    Répondre
    - [^] # Re: Tutorial ?
      
      Posté par Stéphane Traumat (page perso) le 10/06/04 à 17:45. Évalué à 2.
      
      Oui, je pense que le tutorial est fondamental si on veut du monde sur notre projet.. Mais on est déja content :)
      
      Mes deux tutoriaux précédents sur J2EE et les EJB ont bien marchés :)
      
      Répondre
# Par rapport à Ejosa ?

Posté par Etienne Juliot (page perso) le 10/06/04 à 10:59. Évalué à 2.

J'étais justement en train de voir pour me faire un tel projet.
Ce projet tombe donc à pic !

J'aimerai par contre savoir ce que vaut Joffad par rapport à Ejosa ?

D'après ce que j'ai peu voir, Joffad semble beaucoup plus simple. Dans les deux sens du terme : il y a moins de choses à comprendre pour l'utiliser, mais sa couverture d'un cycle de développement complet est plus limité.
Par exemple, Ejosa intègre complétement le MDA (en gros, pilotage du projet par le modèle).
Enfin bon, c'est un avis rapide, car je ne suis qu'au début de mes essais dans les 2 cas.

Je sais pas trop lequel choisir.

Tiens, d'ailleurs, autre question : quand on bosse avec des composants, mieux vaut faire un projet et une arborescence complète par composant, ou tout mettre ensemble (métier et applicatif) et faire la distinction au build ?

Répondre
- [^] # Re: Par rapport à Ejosa ?
  
  Posté par Stéphane Traumat (page perso) le 10/06/04 à 11:09. Évalué à 4.
  
  Bonjour,
  
  Je connais bien le projet Ejosa et son excellent développer Lofi. C'est un très beau projet, il a même été question de merger nos deux projets...
  mais nous ne l'avons pas fait car je préférais garder un projet simple. Ejosa est vraiment très bien mais se mettre dedans prend du temps.. et le but de JOFFAD est justement de ne pas en perdre.
  
  Pour le cycle de dev, il est vrai que nous n'avons pas pris tout en compte, nous partons du principe :
  - dev du domaine des données
  - dev de la logique métier
  - tests unitaires de la logique métier
  - dev des applications clients
  
  l'approche MDA sera peut etre pris en compte dans la prochaine version avec androMDA... mais ca reste à determiner.
  
  Pour ta question, je préfère tout mettre ensemble perso...
  
  Sinon, je le répète, le but de JOFFAD est vraimetn de rester simple et de gagner du temps.
  
  Répondre
  - [^] # MDA ?
    
    Posté par Dian Blue le 10/06/04 à 13:17. Évalué à 2.
    
    Peux tu mieux décrire ce que tu entends par intégration avec MDA (Model Driven Approach je suppose) ?
    Permettre de la transformation de modèle ?
    Un modéle serait une représentation de la strucuture du projet ?
    Un plugin Eclipse serait envisagé ?
    
    Merci par avance.
    
    Répondre
    - [^] # Re: MDA ?
      
      Posté par Stéphane Traumat (page perso) le 10/06/04 à 14:12. Évalué à 2.
      
      Ce que moi j'entends par MDA ( ce n'est peut etre pas juste ) :
      
      - utilisation d'un outil type poseidon ( http://www.gentleware.com/(...) ) pour modéliser.
      
      - puis utilisation de androMDA ( http://www.andromda.org/(...) ) pour générer les composants.
      
      Il y a des plugins eclipse comme omondo qui font ça aussi mais pas vérifier
      
      Répondre
    - [^] # Re: MDA ?
      
      Posté par Etienne Juliot (page perso) le 10/06/04 à 14:42. Évalué à 2.
      
      Bon, je vais faire un peu de pub pour mon ptit site web perso qui explique cette norme de l'OMG :
      http://www.toutmda.fr.st(...)
      
      Répondre
# JOFFAD & Maven

Posté par Hubert (page perso) le 10/06/04 à 11:48. Évalué à 3.

Comment se positionne un tel outil vis-à-vis de Maven ?

Répondre
- [^] # Re: JOFFAD & Maven
  
  Posté par Stéphane Traumat (page perso) le 10/06/04 à 11:50. Évalué à 5.
  
  On se positionne comme "beaucoup plus simple" et je pense qu'on a réussit.
  
  Bien entendu, nous n'avons pas toutes les fonctionnalités de Maven mais il très facile de rajouetr ce qui vous manque et pkoi pas de les intégrer à la prochaine version de JOFFAD
  
  Répondre
  - [^] # Re: JOFFAD & Maven
    
    Posté par Alexandre Touret (page perso) le 10/06/04 à 21:58. Évalué à 0.
    
    C est clair que maven est(/etait?) assez complique. maintenant, vuq ue ts les projes jakarta l utilisent il devient asseez populaire et les best practices publies sur le wiki le rende plus accessible
    
    Répondre
    - [^] # Re: JOFFAD & Maven
      
      Posté par Stéphane Traumat (page perso) le 10/06/04 à 22:40. Évalué à 2.
      
      Peut être oui... mais pour la plupart de nos projets, ca revient à utiliser une usine à gaz avec des millions d'options pour des projets relativement simple.
      
      Donc je préfère utiliser un truc plus simple, plus facile avec moins d'options. Ne serait ce que pour intégrer facilement de nouveaux emplyés/stagiaires/partenaires dans nos équipes.
      
      Répondre
      - [^] # Re: JOFFAD & Maven
        
        Posté par Alexandre Touret (page perso) le 10/06/04 à 23:38. Évalué à 1.
        
        perso sur des projets +/ standards
        struts
        jboss ejb session, cmp
        xdoclet
        junit
        
        je trouve maven assez souple ( apres 1 an de travail dessus :-) ). Il offre une palette d outils tres impressionnants, surtout dans la generation de la doc.
        Mais j admets volontiers qu au debut Jelly et la maniere dont c est foutu est assez deconcertante. En plus la moitie des properties n est pas referencee
        
        Répondre
        
        [^] # Re: JOFFAD & Maven
        
        Posté par Stéphane Traumat (page perso) le 11/06/04 à 09:07. Évalué à 2.
        
        Et bien, JOFFAD comprend le support de struts, ejb, xxdoclet et junit :)
        mais la plateforme est plus simple ;)
        
        Répondre
        
        [^] # Re: JOFFAD & Maven
        
        Posté par Etienne Juliot (page perso) le 11/06/04 à 10:22. Évalué à -1.
        
        Plutot de rester chacun sur vos positions de "c'est mon truc le meilleur", ne serait-il pas possible de les faire cohabiliter ?
        
        Joffad livre des scripts Ant pour la compilation, le déploiement, ... Ne serait-il pas possible de proposer des scripts Maven pour la publication, les dépendances ?
        
        Ainsi, Maven serait le moteur, et Joffad le capeau. Et on garderait un projet simple et rapidement utilisable, avec la puissance de l'outil Apache.
        
        Répondre
        
        [^] # Re: JOFFAD & Maven
        
        Posté par Stéphane Traumat (page perso) le 11/06/04 à 10:56. Évalué à 3.
        
        Le débat n'en est pas du tout à "c'est mon truc le meilleur", il est déja clair que Maven est beaucoup plus complet que nous et permet plus de choses.
        
        On ne peut pas, je pense, faire cohabiter les deux projets pour la simple et bonne raison que nous n'avons pas les mêmes objectifs.
        
        Maven se veut un produit complet, standard, utilisable.
        JOFFAD se veut etre un produit très simple que les gens peuvent prendre et modifier pour coller à leur besoin.
        
        Le but de JOFFAD est de rester simple ce qui n'est pas le cas de MAVEN. N'ayant pas les mêmes buts, on a décidé de continuer de développer JOFFAD.
        
        Répondre
        
        [^] # Re: JOFFAD & Maven
        
        Posté par Etienne Juliot (page perso) le 11/06/04 à 15:40. Évalué à 1.
        
        OK.
        
        En tout cas, je te soutient dans ta démarche car votre projet et son optique (rester simple) sont très intéressant pour tout nouveau projet, ou pour tout simplement de la veille techno.
        
        Bonne continuation.
        
        Répondre
        
        [^] # Re: JOFFAD & Maven
        
        Posté par Stéphane Traumat (page perso) le 11/06/04 à 16:48. Évalué à 2.
        
        Merci :) ca fait du bien d'etre supporté de temps en temps :) merci.
        
        Répondre
        
        [^] # Re: JOFFAD & Maven
        
        Posté par deuch le 12/06/04 à 09:50. Évalué à 0.
        
        OK installation nickel ...
        
        Mais pour le projet calculator j'ai des grosses erreurs quand je fais le ant ejb ...
        
        Voilà en gros ce qu'il me dit :
        
        xdoclet.ejb:
        
        xdoclet.ejb:
        [echo] +---------------------------------------------------------------------+
        [echo] | xdoclet.ejb |
        [echo] +---------------------------------------------------------------------+
        [ejbdoclet] java.io.IOException: Mauvais descripteur de fichier
        [ejbdoclet] at java.io.FileDescriptor.seek(long, int, boolean) (/usr/lib/libgcj.so.5.0.0)
        [ejbdoclet] at java.io.RandomAccessFile.seek(long) (/usr/lib/libgcj.so.5.0.0)[ejbdoclet] at java.util.zip.ZipFile$PartialInputStream.read(byte[], int, int) (/usr/lib/libgcj.so.5.0.0)
        
        puis :
        
        ejbjar:
        [echo] +---------------------------------------------------------------------+
        [echo] | ejbjar |
        [echo] +---------------------------------------------------------------------+
        [ejbjar] building calculator-ejb.jar with 9 files
        
        BUILD FAILED
        java.lang.InternalError
        at java.util.zip.Deflater.deflate(byte[], int, int) (/usr/lib/libgcj.so.5.0.0)
        at java.util.zip.DeflaterOutputStream.deflate() (/usr/lib/libgcj.so.5.0.0)
        at java.util.zip.DeflaterOutputStream.write(byte[], int, int) (/usr/lib/libgcj.so.5.0.0)
        at java.util.zip.ZipOutputStream.write(byte[], int, int) (/usr/lib/libgcj.so.5.0.0)
        
        Idem pour le projet struts ... des que je submit le formulaire j'ai le droit a cette erreur :
        
        cause mère
        
        java.lang.IllegalAccessError: tried to access class org.apache.commons.beanutils.MappedPropertyDescriptor$1 from class org.apache.commons.beanutils.MappedPropertyDescriptor
        at org.apache.commons.beanutils.MappedPropertyDescriptor.getPublicDeclaredMethods(MappedPropertyDescriptor.java:383)
        at org.apache.commons.beanutils.MappedPropertyDescriptor.internalFindMethod(MappedPropertyDescriptor.java:453)
        at org.apache.commons.beanutils.MappedPropertyDescriptor.findMethod(MappedPropertyDescriptor.java:527)
        at org.apache.commons.beanutils.MappedPropertyDescriptor.(MappedPropertyDescriptor.java:149)
        at org.apache.commons.beanutils.PropertyUtils.getPropertyDescriptor(PropertyUtils.java:907)
        at org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:934)
        at org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808)
        at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:978)
        at org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:779)
        at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:246)
        at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1292)
        at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:510)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
        at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:98)
        at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:176)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:172)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
        at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
        at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
        at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
        at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2416)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
        at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
        at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
        at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
        at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
        at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
        at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
        at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
        at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:601)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392)
        at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
        at java.lang.Thread.run(Thread.java:534)
        
        Je precise que tout est installé et les varaibles d'environnement setter ...
        
        Je suis sous Linux (Fedora Core 2 ...)
        
        Merci d'avance pour votre aide ...
        
        Répondre
        
        [^] # Re: JOFFAD & Maven
        
        Posté par Stéphane Traumat (page perso) le 12/06/04 à 15:27. Évalué à 2.
        
        Bonjour,
        
        Vous utilisez quel SDK ? avez vous fait java -version et y avait il des erreurs ?
        
        vous pouvre me mailer à stephane.traumat@scub.net
        
        Répondre
        
        [^] # Re: JOFFAD & Maven
        
        Posté par deuch le 14/06/04 à 11:15. Évalué à 0.
        
        Ok merci !!!
        
        Pouvez vous me dire si vous avez bien recu mon mail ??? :-)
        
        Merci d'avance !!
        
        deuch
        
        Répondre

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.