CrEv a écrit 4577 commentaires

sauf que tu veux pouvoir avoir une interface qui se comporte correctement sur la plateforme, ou qui a des effets sympa.

Ha ben de rien.
Pour arrêter jetty, moi c'est CTRL+C ;-)

Ha tiens, pas testé avec java 7.

En fait il n'y a pas tant de dépendances que ça surtout. Je vais rajouter progressivement les autres outils closure, mais ça reste mesuré.

Bon alors, au final, facile ou non de faire du web sympa en java ?

j'oubliais, si tu veux, passes moi ta modif pour le build de soy, je la rajouterai.

Il m'arrive parfois pour ne pas rester enfermé chez moi de le prendre et de me mettre à la terrasse d'un café, de me prendre une bière ou deux tout en étant sur le portable

Et sinon, parfois il t'arrives de faire quelque chose sans être sur ton ordi ? ;-)
(oué bon, vendredi, toussa, saytai trop facile)

Ha oué, c'est sur que s'ils utilisaient un DCVS performant ça irait beaucoup plus vite. Genre, bazaar.
Heu…
ha ben non, finalement ça ne changerait rien. Bazaar, le DCVS aussi performant que SVN !

(c'est pas svn ou pas qui va attirer du monde, mais forcément essayer de faire un DE en jouant avec de l'objective C et du smalltalk, en plus de gnustep, ça attire pas grand monde…)

As-tu réussi ?

Si besoin, j'ai créé un miroir ici : https://github.com/CrEv/Taist
Pour builder, il y a besoin de builder avant Closure templates (soy) que tu pourra trouver ici : https://github.com/CrEv/closure-templates Il s'agit d'un fork du projet de Google avec juste une update de la version de Guava, histoire d'être compatible avec mon code.
Une fois buildé closure, pose le jar dans lib/ et tu peux faire un gradle run pour voir ce que ça donne, http://localhost:8080/hello/world te servira une page fournie par un template soy.

qui bouge dans tous les sens

Je te rejoins complètement, le mien ne bouge pas et c'est tant mieux.

application continue à tourner même quand on la ferme, c'est vraiment un truc qui je trouve insupportable sous mac

Au début je pensais pareil. Mais en fait c'est surtout que ce n'est pas la même "métaphore" application, documents, etc que sur les autres systèmes. Et ça change pas mal de choses. Après c'est sur qu'on est pas habitué en général à ce comportement.

avant-window-navigator et cairo-dock, c'est deux gros tas de bugs

Ha, je me disais bien…
Le mieux que j'avais testé c'est gnome-do, mais c'était toujours plutôt limité malheureusement. Faudrait que je repasse un peu sous KDE pour voir ce que ça donne désormais.

Evidemment… mais je parlais surtout des concepts. Puisque si on regarde vite fait les captures, on a en fait un dérivé de nextstep avec menu global horizontal (comme mac et non plus comme gnustep), un dock plus proche de celui de mac que de gnustep également. Après c'est sur que l'un des problème reste le style de l'ensemble, mais ce n'est pas tout.

Alors, c'est pas hyper simple à décrire. En gros, premier point capital mais probablement subjectif, je n'ai jamais retrouvé, dans aucun dock linux, le côté agréable du dock de mac (bon en même temps j'ai testé ni unity ni gnome shell donc il y a peut-être du mieux maintenant).
Ensuite, il y a le fait que les programmes, fenêtres et documents ne fonctionne pas de la même manière sur mac que sur linux. Lorsque je ferme toutes les fenêtres de mon firefox, firefox n'est pas fermé. Et donc il reste dans mon doc, indiquant qu'il tourne. Sous linux, ben il est fermé, je n'ai plus qu'à le réouvrir.
En fait le dock n'est qu'une part du problème, mais ce que j'apprécie c'est le modèle application / document qui existe sous mac, le menu "global" et le dock. Le tout ensemble, tout est fait pour que ça fonctionne ensemble. Ca ressemble moins à une juxtaposition de plusieurs éléments.
Souvent sous linux, les docks ressemblent à des hacks qui simplement affichent une liste de fenêtre et regroupent les semblables sous une même icone. D'ailleurs, parfois, l'icône qui sert de lanceur change lorsqu'une fenêtre est là ou même c'est une nouvelle entrée dans le dock. En gros, il n'y a pas cette notion d'application, d'application lancée et de fenêtre.
Dur dur à expliquer, c'est beaucoup des "sensations", mais je trouve le dock de mac beaucoup plus agréable que les autres docks. Le pire étant par exemple les docks qui font des flammes, avec des stacks qui fonctionnent à moitié, c'est assez inutilisable.

Oui, pardon pour l'oubli.

Histoire de compléter, tiré de la news de la 0.4 :

Étoilé se veut être un environnement utilisateur libre et innovant basé sur GNUstep construit à partir de légers et très modulaires composants.
Il a été conçu en gardant à l'esprit une orientation projet et documents, dans le but de permettre aux utilisateurs de créer leur propre workflow en refondant ou combinant les Services (applications) et composants proposés.

La grande flexibilité et modularité aussi bien de l'interface utilisateur que du code doit permettre à Étoilé d'être utilisable d'un environnement mobile jusqu'à la station de travail.

Il faut comparer ce qui est comparable

Justement, là tu tentes de comparer du C et du C++ à Java. C'est quand même loin d'être sur le même plan.
Et d'ailleurs la lib standard de C++… oué, franchement ça fait bien rire, il n'y en a pas vraiment. Ok certains voient la STL (c'est plus ou moins officiel je crois) mais je préfère, de très loin, Qt par exemple.

Oui voilà. On voit arriver dans Java 7 ce qui manque depuis longtemps, par exemple Objects.equals :

• guava : http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/base/Objects.html#equal(java.lang.Object, java.lang.Object)
• jdk 7 : http://docs.oracle.com/javase/7/docs/api/java/util/Objects.html#equals(java.lang.Object, java.lang.Object)

Mais il serait temps que tous les autres helpers arrivent dans le JDK.
Bon évidemment, ni besoin ni intéressant de tout rentrer, mais il y a déjà beaucoup de choses à faire.

(et tout comme gradle, si tu n'as jamais utilisé Guava je te le conseil. C'est propre, sympa, les fonctionnalités objects, cache ou collections sont bien sympa, surtout si tu n'es pas en jdk 7)

Désolé, le thread était sur le sujet "la lib standard de java say que de la daube" et je suis resté dans le sujet.
Et donc ton commentaire va parfaitement dans ce sens car pour tester si ta chaîne est vide tu ajoutes des libs apache commons alors que ce devrait faire partie de l'objet String (même si c'est du static).

Oué enfin ça c'est une fausse bonne raison.
Car rien n'aurait empêché de faire un String.isEmpty (donc en static). Mais non…
D'ailleurs tu viens de montrer pourquoi tout le monde va finalement vers commons de apache, parce que la lib standard de java est chiante.

Heu oui, la lib de base de java Si on veut faire quelque chose de correct en java, en général il y a deux choix qui s'offrent :

• utiliser les libs apache (par exemple comons-io)
• utiliser guava

Il y a sûrement d'autres alternatives, mais c'est parmi les plus courantes.

Ce que je reproche à java ? Ben sa lib standard est tellement bas niveau qu'elle n'intéresse personne en général.

Les libs de java sont nombreuses et variées

Attention, je parle de la lib standard java, pas des libs qui existent

Mais pour des exemples : combien de temps a-t-il fallu attendre pour avoir un String.empty (ou isEmpty, sais plus) ?
Comment on fait, agréablement, du split, du join, etc avec les libs de base ? Ha oui, c'est vrai, la solution du join c'est de faire un stringbuffer et donc de tout faire à la main.

Pourquoi les libs (autre) fournissent-t-elles toujours les mêmes objets, méthodes ? Simplement car rien de sérieux, avant java7, n'était vraiment fait pour avoir une lib standard correcte.
Il suffit de prendre http://code.google.com/p/guava-libraries/wiki/StringsExplained et http://code.google.com/p/guava-libraries/wiki/IOExplained par exemple.

Une petit correction de vos propos: Gradle s'appuie a fond sur Ivy pour gérer les dépendances (plus puissant semblerait-il), pas du tout sur Maven.

Ce que je voulais dire c'est que Gradle peut utiliser les dépendances de maven. Donc l'argument "on a maven pour les dépendances" ne tiens pas face à Gradle qui peut utiliser (lire, récupérer, etc) les dépendances de maven, ivy, statiques, etc.
Après, je ne savais pas s'il utilise ivy ou maven en interne, je ne connais pas ivy en fait.

Ha oui, je pense que le clone anonyme n'est simplement pas dispo…
Le dépôt indiqué est ouvert en read only, mais je pense qu'il te faut un compte sur baregit pour pouvoir faire le clone : http://www.baregit.com/account/register/alpha

Si tu peux, crée un compte, test, et dit moi si ça fonctionne.

Tu es dur avec maven

Oui, mais c'est juste ce qui ressort de mon expérience (mais je ne viens pas du java, ceci explique sûrement cela)

gestion des dépendances

Oui et non. Oui car la dépendance de maven est utilisée dans gradle par exemple. Non car gradle l'étend suffisamment pour ce que soit plus intéressant de se passer de maven.

cycle de vie du build

Celui de maven est une plaie. Impossible de faire facilement ce qu'on veut. Associé au côté purement déclaratif il est très complexe de faire ce qu'on souhaite.

Un exemple bidon : une webapp, à builder sous forme de war. Du code java et des fichiers js. Avant le packaging, compilation des fichiers js, minification, suppression des fichiers sources initiaux. En plus, modification dans certains fichiers de web-inf suivant un profile. Faire ça en maven c'est horrible voir impossible. On est alors résumé à, au mieux, utiliser ant (ce qui est absolument contraire au principe du déclaratif) ou faire un plugin maven (c'est pas bien compliqué, mais loin d'être quelque chose de logique, surtout si on doit en faire un par webapp)

Concernant JSF. JSF en soit n'est pas une trop mauvaise techno. Mais c'est, à mon avis, une mauvaise approche. Pour ma part, les interfaces c'est devenu du templating puissant, facilement (très) internationalisable, qui s'exécute aussi bien côté client que serveur. Avec ça aussi facile de faire de l'ajax, que du pas ajax, qu'un mélange des deux (par exemple en utilisant history). Et fini les composants js, une interface c'est du html, du css, du js simple. Fini la majorité des composants tout fait qui ne conviennent jamais. Le template sort d'ailleurs n'importe quelle donnée (je me sert parfois des templates pour me pondre de l'xml ou du json, bien bien plus agréable que d'utiliser des documents xml par exemple). L'interface au final c'est avant tout du html pur. (bon, ça ne veut pas dire qu'on utilise jamais autre chose hein, jamais de lib). Mais la lib elle est vraiment gérée côté client, pas côté serveur.
Je sais pas si c'est vraiment clair, mais en gros j'en suis totalement revenu du jsf, vaadin, etc. Même play ça ne me tente plus vraiment, je préfère vraiment ma soluce, un peu maison, beaucoup plus assemblage de composant. Je trouve ça plus pratique.

Ha ben non, pas des webservices quand même ! ;-)
Heureusement qu'il y a de quoi générer les wsdl (ou à partir) sans quoi ce serait vraiment horrible…

Bon, sinon, maven a des choses sympa, typiquement les archetypes. Je sais pas si un équivalent existe en gradle, au pire rien n'empêche, je pense, de créer un archetype pour faire un projet gradle. Enfin faut voir. Mais dans tous les cas c'est bien ça.

la simplicité et/ou l'intégration avec les IDE

C'est là où gradle est bien je trouve, lorsque je modifie mon fichier gradle, au mieux un coup de gradle eclipse et c'est ok. C'est sur que ce serait mieux si c'était intégré, mais j'ai même pas cherché.

la possibilité de virer maven, ant et des scripts par un seul outil

C'est bien, en partie, dans cet objectif que je pense l'utiliser

Oué enfin la solution maven ça n'a rien à voir. Là tu donnes une dépendance.

je ne sais pas ce que c'est les sentiers battus

Ce que je voulais dire par là c'est sortir de la manière "classique" qui vient à l'esprit de beaucoup de monde qui fait du java. Aujourd'hui, en gros, les anciens projets sont gérés en ant, certains nouveaux en maven. Maven est parfois présenté comme le messie mais c'est juste une grosse bouse en réalité et l'intégration dans eclipse des dernières versions est minable (et bourrée de régressions d'ailleurs).
Mais c'est comme faire du web avec java. En général les gens pensent soit JEE, JSF, etc mais c'est lourd (inutilement), chiant (très), fun (pas du tout) ou Play! (perso j'aime pas mais c'est juste perso), Grails (moins).
Alors qu'en choisissant trois libs tu arrive à quelque chose de réellement sympa pour du java. Mais il faut sortir de la vision classique du java, aller explorer des libs qui proviennent d'autres univers, d'inspiration autre que java.

Le problème de certaines remarques c'est que si tu attends que tout le monde passe à autre chose, faut pas s'étonner que ce ne soit pas le cas.

gradle eclipse pour avoir ton projet eclipse à jour. Ca revient à la même chose que la dernière version de m2e qui est pas foutu de mettre à jour le projet lorsqu'on modifie le pom. Maven était pas si mal que ça dans eclipse, mais la dernière version est pitoyable !

Quels plugins t'intéressent réellement ? Parce qu'il y a beaucoup de choses qui nécessitent un plugin en maven et qui sont déjà là en gradle.
Franchement, prend 1h pour lire le début de la doc de gradle, ça ne peut que te faire oublier maven.

Pour le dernier point j'en sais rien, pas utilisé ni cherché.

Allez, c'est vraiment parce que je suis de bonne humeur aujourd'hui…

http://www.baregit.com/crev/taist

Récupérer le projet par git
gradle run

http://localhost:8080/index.html http://localhost:8080/hello http://localhost:8080/hello/world

C'est pas hyper joli, mais c'est un projet existant auquel j'ai enlevé pas mal de trucs (notamment tout ce qui est closure) ce qui explique par exemple le module d'injecteur vide.

Voilou, après il "suffit" d'aller lire les docs de Google Guice et jersey en gros.

Ce qu'il manque pour ce soit bien dans cet exemple : un filtre gzip. Mais en général j'ai un frontal qui le fait (apache)

Non, pas sous la main. J'ai des bribes mais qui contiennent des choses en plus, notamment l'utilisation de Google Closure tools (stylesheet, compiler et surtout, templates - une merveille).

Par contre, pour aller un peu plus loin, voici comment déclarer des filtres, ressources REST et servlets. Cette classe correspond au MyServletConfig de l'exemple précédent.

public class MyServletConfig extends GuiceServletContextListener {
  @Override
  protected Injector getInjector() {
    return Guice.createInjector(new JerseyServletModule() {
      @Override
      protected void configureServlets() {
        filter("/admin/*").through(AuthFilter.class); // web filter pour protéger /admin

        serve("/index.html").with(IndexServlet.class); // un index basique (oui, je ne sert pas mon html en statique mais avec des templates soy, c'est plus rapide et plus efficace, paramétrable, toussa)

        serve("*.html).with(MyServlet.class);

        bind(GsonBodyWriter.class); // permet de sérialiser toute réponse jersey en json

        bind(User.class); // une ressource jax-rs classique
        bind(Right.class); // idem
        serve("/*").with(GuiceContainer.class); // tout ce qui est en /* et qui n'a pas déjà été matché est capté par jax-rs
      }
    });
  }
}

voir http://code.google.com/p/google-guice/wiki/ServletModule par exemple

Si jamais je trouve le temps, je collerai un petit exemple un de ces jours.

une mini-distribution dans ma distribution.

Alors ça c'est ce que font quasiment tous les langages aujourd'hui. cpan, gem, easy_install, pear, etc.
Ils font quasiment tous, par certains côtés, doublons avec le système de package de ta distrib. Idem pour go avec go get…

Gradle te permet ça de manière simple, notamment la dernière ligne qui te charge tous les jars d'un ou plusieurs répertoire.
Donc tu peux faire exactement pareil, tu n'as qu'à mettre un compile fileTree(dir: '/usr/share/java', include: '*.jar') et c'est terminé.
Et hop, pas besoin de gérer des dépendances maven ou autre, tu n'as qu'à poser tes jars comme tu veux.

Maintenant, je pense tout de même que c'est une mauvaise solution.
Pire, je développe en OSGi donc il m'est possible d'avoir n versions d'une même lib exécutées en même temps dans le même projet global. Et là, tu es bien obligé de gérer les dépendances.

Donc au final : tu veux faire un projet un peu important ? Utilise les dépendances, le format de dépendance maven par exemple, au travers de gradle c'est le plus simple.
Tu veux faire un petit projet ou ne pas te prendre la tête ? Copie les jars souhaités dans un répertoire quelconque (comme tu ferais avec n'importe quel langage) et utilise gradle de la manière suivante :

apply plugin: 'java'
apply plugin: 'application'

sourceCompatibility = 1.6
version = '0.1.0'

mainClassName = "main.Main"

dependencies {
  compile fileTree(dir: 'libs', include: '*.jar')
}

C'est quand même pas bien dur, c'est très lisible, il n'y a pas besoin de plus. Rien à faire de spécial, avec ça tu es comme avec la majorité des langages.
Tu met un répertoire src/main/java avec tes sources, src/main/resources pour tes ressources et c'est terminé.
gradle run et tu exécute ton main.

Franchement, c'est hyper simple.
Mais il faut sortir des sentiers classiques de java.

D'ailleurs, j'encourage quiconque utilisant maven à tester rien qu'une fois Gradle. Ca surclasse réellement maven.

J'ai lu un peu de travers, mais quelques points tout de même.

Franchement, si tu ne veux pas te prendre la tête utilise Gradle et non maven (gradle lit les dép maven). C'est beaucoup plus agréable. Maven c'est bien, c'est bien pour certaines parties des dépendances, mais c'est chiant.

Et pour faire du http, soit tu prends un truc comme play (on va dire en gros que c'est comparable à utiliser un symfony ou rails sur le principe) soit tu fais plus léger, moins guidé, mais à la main (c'est la solution que je préfère).

Par exemple, voici un petit fichier gradle qui te met à dispo tout ce qu'il faut :

apply plugin: 'java'
apply plugin: 'application'
apply plugin: 'eclipse'

sourceCompatibility = 1.6
version = '0.1.0'

mainClassName = "main.Main"

repositories {
  mavenCentral()
}

dependencies {
  compile group: 'com.google.inject',            name: 'guice',                version: '3.0'
  compile group: 'com.google.inject.extensions', name: 'guice-assistedinject', version: '3.0'
  compile group: 'com.google.inject.extensions', name: 'guice-servlet',        version: '3.0'
  compile group: 'com.sun.jersey.contribs',      name: 'jersey-guice',         version: '1.9-ea06'
  compile group: 'org.eclipse.jetty',            name: 'jetty-server',         version: '8.0.0.M3'
  compile group: 'org.eclipse.jetty',            name: 'jetty-servlet',        version: '8.0.0.M3'
  compile group: 'com.sun.jersey',               name: 'jersey-server',        version: '1.9-ea03'
  compile group: 'com.sun.jersey',               name: 'jersey-core',          version: '1.9-ea03'
  compile group: 'com.google.code.gson',         name: 'gson',                 version: '2.1'
  compile group: 'com.google.guava',             name: 'guava',                version: '11.0.1'
  compile fileTree(dir: 'libs', include: '*.jar')
}

En gros :

• compile du java
• lance en tant qu'application
• fourni un projet eclipse
• utilise le dépot central de maven
• charge un certain nombre de dépendances, entre autre :
  • Injection de dépendances avec Guice (nikel)
  • Jetty comme serveur web
  • guice, jetty, jersey pour coder simplement une appli web (sans war, sans webapp, juste de l'injection, des servlets et du REST)
  • gson pour faire du json
  • guava parce que c'est bien (cache par exemple)
  • et surtout, chargement des .jar locaux, ne provenant donc pas de maven. Parfait pour mixer dépendances d'un repository et jar buildés à la main (chose que maven ne permet pas comme ça)

Avec une base de ce genre, tu est tranquille pour développer.

Et en gros ton appli se résume à ça :

/**
   * Run the Jetty server with a default Guice handler
   * @throws Exception Exceptions
   */
  public void run() throws Exception {
    server = new Server(port);

    ServletContextHandler sch = getDefaultContextHandler();
    sch.addEventListener(new MyServletConfig());

    server.setHandler(sch);

    server.start();
    server.join();
  }

  /**
   * @return a default servlet context handler using Guice.
   */
  private ServletContextHandler getDefaultContextHandler() {
    ServletContextHandler sch = new ServletContextHandler(ServletContextHandler.SESSIONS);
    sch.setContextPath("/");

    sch.addFilter(GuiceFilter.class, "/*", null);
    sch.addServlet(DefaultServlet.class, "/");

    return sch;
  }

Le problème c'est que c'est loin d'être la manière "classique" de faire en java. Beaucoup de monde est resté enfermé dans une logique JEE totalement monstrueuse, bien bourrine et surtout absolument pas agréable.
Avec un truc du genre du peu enfin coder "facilement" en java sans te prendre trop la tête.

Ha non, je me fais quand même laminé icitte
Mais lui triche pour de vrai ! ;-)

Juste quelques bonnes fibres, un accès sur un backbone correct et hop. Bon ok, j'ai fait depuis mon taff, c'est vrai, mais on devrait raccourcir un peu ce temps dans le futur (il faut bien choisir ses interconnexion mais ça se fait)

D'ailleurs, c'est marrant avec les autres "grands" :

• yahoo : 197ms
• bing : 9 ms
• facebook.com : 165ms
• apple.com : 10ms

Et le meilleur pour la fin (le plus important !) :

• linuxfr.org : 9ms

Je développe sur 160-200 colonnes.

Ha quand même !

En typo, en général, on tente d'avoir des lignes contenant 45 à 75 caractères en gros. Disons que c'est autour de ces valeurs que l'oeil s'y retrouve pas mal (afficher un texte sur un écran wide par exemple est particulièrement désagréable). C'est aussi pour cette raison qu'en général les journaux sont sous forme de colonnes.
Evidemment, si on prend en compte les indentations de code on dépasse rapidement les 80 colonnes, sachant aussi que souvent on lit je pense le code un peu différemment que du texte, notamment grâce à la coloration qui permet de "zapper" quelques termes.
Tout ça pour dire que 80 me parait bien juste, 200 me parait par contre plutôt énorme.

Ensuite, l'avantage de lignes pas trop longues est de pouvoir facilement mettre deux codes l'un à côté de l'autre. Et là les 80 colonnes sont pas mal (ou alors c'est parce que j'ai un écran pourri, qui ne fait que 1440 de largeur :-( )

Oué mais ça voudrait dire s'arrêter de la sorte pour tous les composants ou libs du projet.
C'est un peu comme si on disait que tout était du java finalement, en s'arrêtant au .class