Let me rephrase so as to put the pointy end of the question more directly: Neo4j worked with Roo at one time (maybe not perfectly, but some simple examples published in at least one book apparently did work). Why can't I download the version of Roo that the author used and duplicate the author's results?
A shallow answer, of course, is that software dependencies not part of the Roo distribution have changed.
A deeper question is, Why does this happen? That is, why can't I download the versions of the software providing those dependencies to Roo that were current at the time of the author's writing and expect to be able to duplicate his results?
It's at this point that I'm a little stuck and I can't see why that should be. I don't seem to have any way to be able to identify what those versions might have been. It seems like that ought to be a critical part of Roo's configuration management. But, come to think of it, I don't recall this sort of record-keeping to be part of typical practice except where the RPM package manager is involved. Now, maybe my perceptions as to this point are flat out wrong. But if they're not doesn't the usual way of doing open-source development need to be upgraded at this point? Or maybe I'm so completely wrong that you can turn back Roo's clock, so to speak. If that's the case, will someone please tell me how to turn it back so that Neo4j works as well as it once did (However well or badly that was I don't really care. I just want to replicate results.)
Is that a better way of expressing and attacking the problem? I'm trying very hard to prop up one of the couple of books written to date about Roo. Frankly I'd like to see the book's author(s) or publisher wade in and help me or rebut me, because the book's still being sold. If the ongoing example is as badly broken as I think it seems to me that it would be wrong to continue selling the book or, at least, selling it without a clear warning to the reader. O'Reilly published the book in question and I have a high subjective opinion of their business ethics--a high enough opinion that I wonder if I'm getting everything wrong.
Generally when you're wrong, you can depend on 100 people to tell you so (plus another 10-20 to tell you you're wrong on points that you did get right and another 5-10 that seize on some basically irrelevant point and contradict you apparently ust fof the fun ot it, without in any way moving the discussion forward--a cooperative concept they seem incapable of grasping let alone following). But I, and others who've asked essentially the same question, hear nothing but the crickets. Chirp-chirp???
mv (sorry: I wasn't immediately able to find the markup syntax used to notate the ids of members) asked a question about the future status of Roo's support for Neo4j, which appears to have foundered. A related question puzzles--and frustrates me--mightily. Neo4j was supported under Roo 1.1.4 but when I try code that apparently worked when 1.1.4 was current (from Josh Long's book Getting Started with Roo), the code fails in exactly the way it fails under 1.2.5 (and the upcoming release, 1.2.6). In other words, it appears that support for Neo4j was removed retroactively, so to speak.
My question follows as a generalization of that observation: Under what technical circumstances (I don't wish to consider possible legal reasons) would it be good (i.e., sound, practical, necessary. &c.) to retroactively alter the behavior of a released version of a software product?"
Currently, I'm finding this decision as respects Roo inconvenient and so I think I may overlook good reasons for such a decision. Please note, however, that my question doesn't specifically pertain to Roo. For one thing, I don't relish a discussion in which participants work to make the Roo team look bad. For another, I'm interested in the general case, not merely the particular case of Roo. Actually it seems to me at the moment that the absence of retroactive inconsistencies in behavior is a necessary condition for robust systems. I mean, for example, at exactly what time did the inconsistency begin? Was it during or after the stated duration of viability of the release in question. Probably I'm wearing my Chicken Little hat but right now it seems to me as though retroactive inconsistency has "Humpty Dumpty" written all over it.
That being said, I suppose I'm sneaking in a second question, but I would very much appreciate being told that my premise as respects Roo is inaccurate; that is, Neo4j can somehow be used under some appropriately old released version of Roo. In that case, I would also be immensely curious to know how this might be accomplished. Roo doesn't require any set up configuration so there appears to be no opportunity for a configuration tweak. Actually the only stated requirements are a JDK and Maven under Linux, OS X, or Windows. But, the addon command apparently queries a database of some sort. Perhaps that is an unstated dependency responsible for retroactively inconsistent Roo behavior.
Having snuck in a second question, I'm finding it difficult resisting temptation to go for a third question. If I were to succumb, the question would be this: How, in the particular case of Roo, is it possible (assuming that the release code has not been surreptitiously changed) that the behavior of an old release has been changed? It seems to me that the answer must lie in Roo's dependencies. But, assuming none of the dependencies has retroactively changed its behavior, can Roo do so without actually modifying the released code? It seems to me that it cannot, in which case I'd be exceptionally eager to know which dependency (assuming there is only one) has retroactively changed its behavior, and why. But. I think I may yet find the resources to master even the quite strong temptation to pose that question. :-)
Long question,..
Running an old release should duplicate it's behavior, but there might be inconsistencies due to various circumstances. It will be hard to pinpoint those without some more eleborate description of the problem and a stacktrace (if available).
You state that you believe the software dependencies of the roo-distribution might have changed, but this should not be the case: maven, acting as your dependency manager, should take care of that as long as there are no SNAPSHOT dependendencies in your pom.xml (or rather, in the dependency tree).
But there are other reasons the behavior might be different now. It could well be the version of the JDK you use. These also should be backward compatible but on wikipedia I saw that spring roo doesn't support Java 8, for example.
Then there is your operating system, but I believe it would indicate some sort of bug if that would be the issue now.
Finally I would look at third-party addons of spring roo. Unfortunately I am not familiar with them, but it seems to me that a third party add-on is downloaded with some command that doesn't necessarily ask for the 'correct', compatible version of this addon.
I hope this answer to the title-question helps you. your second and third question did help me in formulating this answer, but generally it would be a good idea to make separate posts for the snuck-in second and third question.