Discussion :

[grunt2000]

Bonjour,

J'essaie de récupérer le projet collaboratif Geotools par Git.
Mais parce que je suis néophyte avec Git, je suis surpris de ce qui se passe, et ce qui arrive n'est pas ce à quoi je m'attends.

Geotools a deux versions en activité, d'après son site: une 9-SNAPSHOT en développement à longue échéance et une 8.5 en release.

Lorsque je fais un clone, je reçois la 9-SNAPSHOT qui compile et se teste par un mvn clean install qui fonctionne. Mais ce n'est pas celle-là que je veux exploiter.
Conformément à leurs procédures Git, j'essaie d'évoluer vers les branches 8.x

J'ai relié autant de branches chez moi que j'ai pu aux leurs.
Et aujourd'hui, un git branch -a me donne ceci:

8.x
master
* rel_8.x
remotes/origin/2.7.x
remotes/origin/8.x
remotes/origin/HEAD -> origin/master
remotes/origin/featurecollection_cleanup
remotes/origin/featurecollection_cleanup_origional
remotes/origin/master
remotes/origin/rel_8.x

Mais:
Quand je compile la branche 8.x reçue, je compile une 8-SNAPSHOT qui échoue sur un test unitaire.

Quand je compile la branche rel_8x, je reçois une 8.1 qui échoue sur un autre test unitaire. Peut être n'a t-elle jamais pu être livrée.

Je devrais trouver une version 8.5 quelque-part, puisque c'est la dernière releasée, non ?
Et sans doute aussi une 8.6 ou plus probablement une 8.6-SNAPSHOT quelque-part en cours de développement pour prendre en charge des corrections ou des évolutions.

Les commandes Git que j'exécute ne me montrent pourtant rien.
Je m'y prends mal. Bien sûr, je pourrais les interroger sur leur forum des développeurs, mais j'ai l'impression que je fais juste face à un problème de compréhension personnel d'emploi de Git.

Sur leur git:
https://github.com/geotools/geotools/
qu'est-ce que j'aurais du trouver d'autre que ce que j'ai vu, si je m'y étais bien pris ?

En vous remerciant,

Grunt.

[Philippe Bastiani]

Bonjour Grunt,

Si j'ai bien compris, tu veux partir de la version 8.5 !
En clonant, ton repo, tu as aussi récupéré tous les tags qui ont été positionné:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

git tag

te donne la liste des tags.

Ensuite, tu vas vas ouvrir une nouvelle branch à partir du tag 8.5

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

git checkout 8.5 -b NewBranch

Pour avoir ta branche sur ton dépot github tu feras

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

git push origin NewBranch

puis un pullrequest pour soumettre ta modif au projet !

P.I.: lorsque tu clones geotools tu le fait depuis ton dépot geotools de GitHub et non pas depuis celui du groupe Geotools... Si ton dépot Github n'est pas à jour, tu ne recevras pas les dernières modifs du projet... C.f. le post que l'on a eu en septembre sur le sujet...

Voilà
a+

[grunt2000]

Je n'y avais pas pensé ! Merci !

Par contre, ça continue à m'embêter...
Ça compile jusqu'à un certain stade où ça finit par un:

Results :

Tests in error:
testUserLayerWithInlineFeatures(org.geotools.styling.UserLayerTest)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
-------------------------------------------------------------------------------
Test set: org.geotools.styling.UserLayerTest
-------------------------------------------------------------------------------
Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.013 sec <<< FAILURE!
testUserLayerWithInlineFeatures(org.geotools.styling.UserLayerTest)  Time elapsed: 0.011 sec  <<< ERROR!
java.lang.NullPointerException
	at org.geotools.styling.DefaultResourceLocator.makeRelativeURL(DefaultResourceLocator.java:82)
	at org.geotools.styling.DefaultResourceLocator.locateResource(DefaultResourceLocator.java:53)
	at org.geotools.styling.SLDParser.parseExternalGraphic(SLDParser.java:1683)
	at org.geotools.styling.SLDParser.parseGraphic(SLDParser.java:1563)
	at org.geotools.styling.SLDParser.parsePointSymbolizer(SLDParser.java:1524)
	at org.geotools.styling.SLDParser.parseRule(SLDParser.java:905)
	at org.geotools.styling.SLDParser.parseFeatureTypeStyle(SLDParser.java:811)
	at org.geotools.styling.SLDParser.parseStyle(SLDParser.java:767)
	at org.geotools.styling.SLDParser.parseUserLayer(SLDParser.java:480)
	at org.geotools.styling.SLDParser.parseDescriptor(SLDParser.java:441)
	at org.geotools.styling.SLDParser.parseSLD(SLDParser.java:400)
	at org.geotools.styling.UserLayerTest.testUserLayerWithInlineFeatures(UserLayerTest.java:175)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at junit.framework.TestCase.runTest(TestCase.java:168)
	at junit.framework.TestCase.runBare(TestCase.java:134)
	at junit.framework.TestResult$1.protect(TestResult.java:110)
	at junit.framework.TestResult.runProtected(TestResult.java:128)
	at junit.framework.TestResult.run(TestResult.java:113)
	at junit.framework.TestCase.run(TestCase.java:124)
	at junit.framework.TestSuite.runTest(TestSuite.java:232)
	at junit.framework.TestSuite.run(TestSuite.java:227)
	at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
	at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
	at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
	at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)

Ça me surprend parce que je suis persuadé que la version releasée doit passer ses tests, et pour ça, je pense que je ne suis pas encore sur la bonne.

Ou alors, au vu du code qui se plante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
    URL makeRelativeURL(String uri) {
        try {
            return new URL(sourceUrl, uri);
        } catch (MalformedURLException e) {
            LOGGER.warning("can't parse " + uri + " as relative to"
                    + sourceUrl.toExternalForm());
        }
        return null;
    }

Il me manque un paramétrage qui ne m'est pas livré quand je download leur version...

Je vais peut être être obligé quand même de les contacter sur leur forum développeurs.

[Philippe Bastiani]

Ben, je ne sais pas quoi te dire... je pense effectivement que la version avec tag doit compiler !

Tu peux tjrs comparer avec les versions qui sont ici.

Tu dois avoir ces commits dans ton dépot local (git log).

As-tu attaché ton dépot local à EGit ? toutes ces opérations peuvent se faire depuis Eclipse...

Bon dev
Philippe

[Philippe Bastiani]

Tiens au passage, j'ai parcouru ton doc sur Git pour Geotools... très lié à svn leur vision du workflow git

- ils conseillent de renommer origin par ton login : bof !

- je ne vois pas comment on pourrait pousser directement sur geotools comme ils semblent l'indiquer 'git push geotools master' ! Celà va à l'encontre du process github qui fonctionne en pullrequest... Si tel était le cas: la branche master de geotool serait polluée !!!

- ils n'invitent pas les développeurs à travailler systématiquement sur des branches ! Hors, sur github, tu ne peux faire qu'un seul pullrequest par branche... du coup, tu ne peux pas travailler sur plusieurs fixes avec ce process... surtout, que tes contribution peux-être rejeté !

[grunt2000]

Tu sais, je ne vais pas leur jeter la pierre, car le projet date d'avant Git et ils ont du migrer et moi-même, c'est SVN et CVS que je connais (et des trucs plus atroces encore, comme MKS...).

J'essaie de les déranger un minimum en tâchant de m'en sortir tout seul si possible, mais leur projet m'a poussé à installer Git que je ne connais pas.

Je me dis que eux non plus: ils ont du s'y essayer comme tout le monde, et peut être faire des mauvais choix. Moi, j'observe Git aujourd'hui, mais je me demande si je recommanderai son emploi dans une entreprise où j'aurais la responsabilité du choix du [D]VCS avant deux ou trois ans d'ici. Git n'est pas simple à appréhender.

En fait, si tu lis les tutoriaux à son sujet ceux-ci sont pleins de négations: "ne faites pas ceci", "ne confondez pas ceci avec cela", "Ceci est une mauvaise pratique", "Respectez cela". C'est à dire qu'à mes yeux Git est très stressant: beaucoup de docs et de sujets de discussions n'arrivent pas à dire ce qu'il faut faire: elles énumèrent des avertissements sur la manière dont il ne faut pas l'employer. Particulièrement, les confusions avec SVN. Les fils de discussions de plainte de mauvais emploi sont si fréquents: dur de prendre confiance !

En un mot, le gros problème de Git, pour ceux qui le découvrent, moi, l'équipe de Geotools sans doute, c'est qu'il est difficile de savoir comment s'en servir tellement la doc qui dit comment ne pas s'en servir est profuse.
C'est sans doute un outil génial. Mais très très très mal introduit, très difficilement utilisable parce qu'il ne donne pas confiance. Mais alors: pas du tout !
Un plantage CVS ou SVN, tout administrateur a eu à s'en sortir. Mais Git, déjà les opérations normales ont l'air d'être faites mal par le pequin lambda à lire ce que l'on lit. Alors on se dit qu'au moindre incident système un peu chiant, tout sera foutu par terre ? Git m'est, pour le moment, très inquiétant.

C'est un outil que j'emploie avec très peu de sérénité. Et ça, surtout parce que tout le monde passe son temps à écrire sur les forums que personne ne sait l'employer bien.


EDIT: Ah, c'est pas mal comme Braillou 2013, tiens. Pourquoi je me suis mis brutalement de mauvaise humeur contre Git, moi ?

[Philippe Bastiani]

Franchement, la phase d'apprentissage de git n'est pas plus longue que celle de svn/xxVS !

Par contre: je te le concède, il n'y a pas beaucoup de tutos qui explique correctement son fonctionnement ! Le livre ProGit (en français) est un bon outil d'apprentissage.

Après le passage, svn/xxVS -> git t'oblige à une petite gymnastique mais bon...

Git est, au passage, très utilisé en entreprise, grâce à Github qui la popularisé (il y a 4 ans je misais sur mercurial qui est réellement multi-plateforme mais github est passé par là).

L'administration d'un svn (ou pire avec clearcase) n'est finalement pas plus simple. Perso ayant démarrer avec RCS et étant passé par plusieurs xxVS/svn/clearcase, je le trouve plus simple mais peut-être moins intuitif.

Démarrer git avec github n'est pas non la meilleure façon de l'appréhender car tu dois jongler avec 3 dépots et tu dois te palucher les synchros... mais, si un service comme github prend le pas sur sourceforge, c'est IMHO, en bonne partie grace à la souplesse de git...

Bon courage
Philippe