Reprise du message précédent :
yet another jvm language

Yet Another Java Like/Language, ça m'a d'ailleurs fait penser au XKCD d'aujourd'hui

C'est pas nécéssairement une mauvaise chose; contrairement au xkcd d'ajd, je pense pas qu'ils pensent en termes de "nouveau standard". Au pire, Scala piquera les bonnes idées et en deviendra meilleur. Pour ce qui est du support dans IDEA, c'est pê un bon point, mais en même temps, si Jetbrains à ouvert son api de plugin, c'est pas juste pour faire un cadeau, mais pour déléguer une partie du boulot...

Scala a déjà la majorité de ces trucs, ça va pas le rendre moins complexe à approcher. L'inconvénient de scala c'est qu'il fait un pont entre les langages fonctionnels fortement typés (MLs, Haskell) et les langages OO enterprisey (Java, C#), et ça en fait un truc un micropoil complexe (et avec un compilo lent), et les implicits rendent le code plus complexe à lire.
 
Là, le langage reste globalement dans la niche de java, et intègre nativement des patterns importants (genre délégation), mais tu peux quand même t'y retrouver quand tu viens de java sans être polyglotte je pense.

Non bien sûr, mais l'idée générale était assez proche pour me faire marrer (les journées sont longues).

Oué, l'inverse aurait pas été faux non plus. Idée naïve dans un monde de bisounours : le truc Kotlin va a peu de chose près voir le jour en même temps que le JVM-based-Scala-like language de Red Hat. Si Scala est si valable pour se trouver des concurrents directs, ça aurait pas été plus bénéfique de se positionner tous derrière (parce que finalement, à la lecture des comparos, il lui manque pas tant de truc que ça) ? J'avais prévenue, c'est très naïf, mais je pense que ça facilite pas l’émergence d'un langage avec assez de poids pour s'imposer chez un grand compte conservateur par exemple.

Voir plus haut, du même coup, j'aurais préféré que Jetbrains se range du côté de Scala pour que quelques corps viennent booster l’intégration.
 

c'est vraiment de la merde weblogic
pourquoi on peut pas exporter/importer ces putains de configs JMS ?  

nous allons tester une install weblogic vs glassfish pour évaluer une possible tentative de migration future...  
une petite liste de vos griefs les plus marquants siouplé ?
 

même via leur script d'admin ?

objectivement l'interface d'admin écrit dans un fichier XML pour les queues
je migre la version du serveur
je sais pas si le fichier est compatible
j'ai pas accès au fichier sur l'autre serveur donc ça sera au mieux la faite du copier coller.
il faut probablement stopper le serveur si on veut modifier le fichier à la main, et si on le fait pas il y a de grandes chances qu'il écrase tout
Je préfère éviter de toucher ces fichiers à la main, car c'est pas des fichiers prévus pour être modifiés manuellement comme peuvent l'être ceux de tomcat par exemple

donc ouais on a une interface graphique, c'est sympa, mais comme d'hab chez oracle ou ibm, on a l'impression d'être prisonnier de l'interface graphique et de rien pouvoir faire sans

après je pense pas que ça justifie de pas utiliser weblogic, ca m'a juste fait chier de faire 43 create new, next, finish ...

qqun connait groovy ?

Je viens de récupérer un projet maven dans éclipse avec une classe groovy, mais la classe groovy n'ai manifestement pas compilée en .class.
J'ai installé le plugin groovy pour éclipse, mais ça groove pas encore  

je me serais attendu à voir une définition d'un plugin groovy dans le pom.xml, mais il y a qued

et ? Elle est "appelée" ou/comment cette classe ? T'es sur qu'y'a besoin qu'elle soit compilée dans le (jar) ?

une classe du même package y fait appel et ne la trouve pas (du moins au niveau du compilateur éclipse)

On m'a dit dans l'oreillette que le build Ant parvenait lui à compiler. (quand j'ai lancé le ant ça à cependant foiré pour une raison Z)
J'ai vu sur le net des bricoles avec le plugin antrun permettant de "faire ce que ça doit faire".
Je me serais attendu cependant à ce qu'après avoir installé le plugin groovy pour éclipse, éclipse n'indique pas d'erreur de compilation.
Et aussi à trouver une solution qui nécéssite pas de revenir 50 ans en arrière en utilisant ant.
( cependant j'avoue avoir déjà recouru à antrun pour faire du scp )

le plus fun étant de récupérer un projet (d'un source control ?) n'étant pas auto-suffisant ou du moins accompagné d'une doc d'install/update/...
 

Ouais, ya bien le plugin gmaven, mais j'hésite a le recommander. Regarde qd même si ya eu une release, ou mieux, de la doc, depuis 6 mois, ça peut valoir le coup. Also, src/main/groovy

je viens d'éssayer avec gmaven, et j'ai toujours une erreur concernant la classe groovy

en fait il faut bien que eclipse compile la classe à un moment donné non ?
Je pensais que le plugin eclipse permettrait de transformer automatiquement les fichiers .groovy en .class (ou qqchose de similaire je sais pas bien comment le compilateur eclipse interragit avec l'éditeur)

edit: en créant un projet groovy de test, ma classe de test groovy est bien compilée

visiblement maven eclipse ne créé pas ce qu'il faut d'emblée (ce qui me parait normal vu qu'il y a rien de spécifié), mais je ne sais pas encore comment faire en sorte qu'un simple mvn eclipse mette tout bien déker

ça m'insuporte ce nom de groovy pour un truc java
c'est un sacrilège envers le funk

bon bah clairement eclipse+groovy+maven=grosse merde

tel Starsky et Hutch je gagne toujours à la fin

ce qui l'a fait c'est d'ajouter une directive dans le pom pour donner la nature groovy, et d'inclure les .groovy au buildpath

pour la partie compiler je l'ai enlevée car j'ai des blems de dépendances
eclipse se charge de compiler grace au plugin eclipse groovy, mais maven seul aurait besoin de ça pour compiler hors d'éclipse

 
tu fais comme ton predecesseur, tu fixes ton build dans eclipse mais pas maven, du coup le prochain qui recupere ton projet aura le meme probleme

il me semble que tu fais comme ton prédécesseur qui répond à un de mes messages sans en avoir capté le tiers ...
à ceci près que ton prédécesseur c'était toi même il y a plusieurs mois

 
putain ca casse  

je dirais que la meilleur solution pour régler le problème aurait été de virer groovy

bah clairement par rapport au projet ca n'a qu'un intérêt limité
Le type l'a intégré pour se faire plaize.
Il y a que 2 classes avec une méthode de 20 lignes qui ont été codées en groovy sur plusieurs centaines de classe java.

J'ai rien contre le fait de se faire plaiz, mais pour un projet d'entreprise c'est bien le genre de trucs qu'il faut sérieusement documenter, et nottament fournir une solution clef en main pour l'IDE qui est utilisé à 99% dans la boite, parceque évidement il utilisait pas éclipse mais intelij.
Il est plus là donc il a rien à assumer.
On en est juste réduit à lui jeter des petits cailloux par la pensée

edit: je viens de remater de plus près, il utilise Groovy uniquement pour utiliser la classe groovy.xml.MarkupBuilder  

on se sort les doigts du cul (en attendant que groovy-eclipse-compiler ait une dependence correcte sur g-e-batch):

un projet qui dépend d'un IDE pour builder  

 
toi et souk vous avez le dons de faire des réponses irritantes au possible
 
parceque vous savez pas lire
 
déjà le projet était buildable par ant
mais ça me fait chier d'utiliser ant en parallèle de maven, c'est moche
et ensuite le soucis est pas de builder ou pas avec éclipse, le soucis est de pas avoir d'erreur de compilation au niveau de l'IDE

hey, grand, ils ont raison, en même temps, hein.
T'as essayé la solution-qui-marche que je t'ai donnée plus haut, au lieu de râler ?

not yet, demain

ouais ils ont surement raison d'enfoncer des ouvertures sans portes

Non, il ne faut pas documenter, il faut virer. Je trouve cela totalement inacceptable. Le Groovy n'a j'imagine strictement rien de nécessaire. Les dépendances doivent se justifier, étant donné que ça rajoute de la maintenance et des difficultés de déploiement, ça n'est pas anodin. Rien de pire que les flemmards qui vont chercher une lib toute faite dans google pour UNE classe qu'ils auraient pu écrire en 10 minutes. Et même si ça n'est que pour le système de build, pour son petit plaisir perso, il fait chier tout le monde. Au pire du pire, tu décompiles et récupères la ou les classes qui vont bien, mais s'il n'y a que 20 lignes, autant les réécrire en Java.

C'est discutable. Parce que ta class, elle sera peut être fait en 10min, mais elle sera aussi peut être buggué jusqu'à la moelle.
Après, si c'est tirer tout Spring par exemple juste pour avoir une méthode du type String.isEmpty...
 
Tu peux aussi retourner la situation en disant : rien de pire que les mecs qui réinventes la roue...

 
Merci ça marche bien au niveau de la compil qui se fait donc entièrement avec maven
par contre les .java sont inclus dans le target

il aurait aussi pu créer une lib qui ne sert qu'a wrapper l'appel
cette lib aurait son propre projet (si on veut rebuilder), et le jar obtenu pourrait être versionnée avec son .pom etcetera pour l'insérer dans maven, et on jette la clef

c'est parrait abérant de ne pas annuler la sortie de java 7 non ?

hhmm... trop de tergiversations sur le contenu de 7, trop d'hésitations, une grosse volonté de sortir une nouvelle version (nouvelle version = nouveaux packages, nouvelles opportunités pour vendre de la consultance, de la formation, ...)

trop salivant d'un point de vue commercial pour se permettre de repousser la sortie...

edit> et maintenant, c'est Oracle: tout est "produit", avec une roadmap commerciale bien nette... alors une considération technique comme un bug qui pourrait attendre u2...

amha.

ouais, j'ai eux un topo sur Java 7 hier, et pareil, il y a des choses non implémentés qui le seront plus tard, car ils voulaient sortir une version. La phrase qui résume bien le problème :  
 
Il y a des DLCs pour les jeux vidéos, il y a maintenant des DLCs pour Java...

 
en fait non, ça va pas être possible, car il faudrait une dépendance sur des objets métiers

J'ai dû googler un peu pour "DLC"
 
Ca sera devenu naturel avec jigsaw...

Si elle prend 10 mn à écrire, c'est que par définition, la tâche est relativement simple.

toutafé puisque Masklinn remonte cette citation:

donc, 10min à écrire c'est 90min de debug après

Non, il a tord (d'en faire une généralité débile en tous cas)