Gli hook di mercurial sono una cosa interessante per sviluppare un proprio workflow e prevenire un set conosciuto di errori. Ma farne il debug potrebbe essere una tragedia.
Nel caso dell’estensione per bugzilla, che può aggiungere commenti a bug specificati all’interno di messaggi di commit (nella forma “bug 1234, bla bla bla”), dopo aver configurato – credevo – tutto correttamente non funzionava una mazza.
Bene, tenete conto che l’esempio di configurazione che potete leggere sulla pagina wiki dell’estensione, BugzillaExtension – Mercurial, ha un piccolissimo difetto:
host = bugzilla # mysql server where bugzilla database lives
password = ** # user's password
version = 2.16 # version of bugzilla installed
Vedete le parti grassettate? I commenti? Be’. NON SONO COMMENTI. Almeno fino alla versione 2.2.2 di mercurial (su CentOS) vengono inclusi nel valore del parametro. Quindi il parametro version ha valore 2.16 # version of bugzilla installed. Che, a dirla tutta, è un valore un po’ del piffero.
Quindi badate bene a togliere tutti i commenti che non sono su righe a sé stanti dal vostro file di configurazione.
Very simple to use. CTRL+Click on or debug a class you don’t have the source of, and you can see it. Depending on how it has been compiled you can see it seamlessly as it was the real source (this is the case for JDK classes), or in debug you could have some issue tracking down the exact line it’s executing (the debugger chooses a line but you have to look for comments indicating original lines). The stand-alone Java Decompiler JD-GUI
is very good too.
Imagine you have a big project with thousands of classes and methods, and you suspect that the majority of those is not really necessary: this plugin is for you. It can check for hard-coded references in your .java sources and the presence of full-path or simple name matching of classes in text files (you can specify regular expressions for files to check, but I’ve managed to only use file extensions, I’m not really sure of what kind of regular expressions it’s using), for example servlet mappings in web.xml. You can decide to be notified of a zero or a low number of references to whole classes or single methods. If you delete unnecessary classes and method you can then re-check to see if something new pops out. The process can be a bit slow, but that’s because it’s thorough.
This is an old plugin that I used some time ago (I don’t know if it’s still working). It warns you of unresolved dependencies in the classpath, which is useful if the unresolved dependencies are in some jar in your project. You can get a ton of false positives, as many jars can have unresolved dependencies for parts you don’t use (and so you haven’t provided the dependencies of), but if you know where to look it may be of great help.
A plugin for using Mercurial
as (D)VCS. It’s in active development, and it has much increased it’s usability in the last year. It’s almost perfect for everyday use (commit, pull, push, merge, switch to, add branch, show history, compare), even though for particular uses or external mercurial plugins you could often need the good old command line or TortoiseHG. Switching between very different branches or revisions can be very slow (TortoiseHG is probably much faster).