【发布时间】：2014-08-05 10:08:56
【问题描述】：
让我改写一下，以便更直接地提出问题的尖锐结尾：Neo4j 曾经与 Roo 合作过（可能并不完美，但至少在一本书中发表的一些简单示例显然确实有效）。 为什么我不能下载作者使用的 Roo 版本并复制作者的结果？
当然，一个肤浅的答案是，不属于 Roo 发行版的软件依赖项发生了变化。
一个更深层次的问题是，为什么会发生这种情况？也就是说，为什么我不能下载向 Roo 提供这些依赖项的软件版本，这些版本在作者撰写本文时是最新的，并且期望能够复制他的结果？
此时我有点卡住了，我不明白为什么会这样。我似乎没有任何方法能够确定这些版本可能是什么。看起来这应该是 Roo 配置管理的关键部分。但是，仔细想想，我不记得这种记录保存是典型实践的一部分，除非涉及 RPM 包管理器。现在，也许我对这一点的看法是完全错误的。但是，如果不是，那么此时进行开源开发的通常方式是否需要升级？或者也许我完全错了，你可以让 Roo 的时钟倒转，可以这么说。如果是这种情况，请有人告诉我如何将其转回，以便 Neo4j 像以前一样工作（无论好坏，我并不真正关心。我只是想复制结果。）
这是表达和解决问题的更好方式吗？ 我正在努力支持迄今为止写的关于 Roo 的几本书中的一本。坦率地说，我希望看到这本书的作者或出版商介入并帮助我或反驳我，因为这本书仍在销售中。 如果正在进行的示例像我认为的那样严重损坏，那么在我看来继续销售这本书是错误的，或者至少在没有明确警告读者的情况下销售它。 O'Reilly 出版了有问题的书，我对他们的商业道德有很高的主观意见——这个意见足够高，以至于我怀疑我是否把所有事情都弄错了。
一般来说，当你错了时，你可以依靠 100 个人来告诉你（再加上另外 10-20 个人来告诉你在你做对正确的点上你错了，另外还有 5 个-10 抓住了一些基本不相关的观点并与你相矛盾，显然你只是从中获得乐趣，而没有以任何方式推动讨论——他们似乎无法理解的合作概念，更不用说遵循了）。但我和其他问过同样问题的人，除了蟋蟀什么也没听到。唧唧喳喳？？？
mv（抱歉：我无法立即找到用于标记成员 ID 的标记语法）询问 Roo 对 Neo4j 的支持的未来状态，该状态似乎已经失败。一个相关的问题让我很困惑——也让我很沮丧。在 Roo 1.1.4 下支持 Neo4j，但是当我尝试在 1.1.4 是当前版本时显然可以工作的代码（来自 Josh Long 的书 Roo 入门），代码失败的方式与它在下失败的方式完全相同1.2.5（以及即将发布的 1.2.6）。换句话说，可以说，对 Neo4j 的支持似乎被追溯删除了。
我的问题是对该观察的概括：在什么技术情况下（我不希望考虑可能的法律原因）追溯是好的（即合理的、实用的、必要的。等等）改变软件产品已发布版本的行为？”
目前，我发现这个决定对 Roo 来说很不方便，所以我认为我可能会忽略做出这个决定的充分理由。但是请注意，我的问题与 Roo 无关。一方面，我不喜欢讨论参与者努力让 Roo 团队看起来很糟糕的讨论。另一方面，我对一般情况感兴趣，而不仅仅是 Roo 的特殊情况。实际上，目前在我看来，行为中不存在追溯性不一致是稳健系统的必要条件。我的意思是，例如，不一致是从什么时候开始的？是在相关版本的规定生存期期间还是之后。可能我戴着我的小鸡帽子，但现在在我看来，追溯性不一致似乎到处都写着“Humpty Dumpty”。
话虽如此，我想我是在偷偷问第二个问题，但 如果有人告诉我我的前提是尊重 Roo 是不准确的，我将非常感激；也就是说，Neo4j 可以在某种适当的旧版本 Roo 下使用。在这种情况下，我也非常想知道 如何得以实现。 Roo 不需要任何设置配置，因此似乎没有机会进行配置调整。实际上，唯一声明的要求是 Linux、OS X 或 Windows 下的 JDK 和 Maven。但是，addon 命令显然会查询某种数据库。也许这是一个未说明的依赖关系，导致追溯不一致的 Roo 行为。
偷偷回答了第二个问题，我发现很难抗拒回答第三个问题的诱惑。如果我屈服了，问题将是：在 Roo 的特殊情况下，旧版本的行为是否有可能（假设版本代码没有被偷偷改变）已经改变？ 在我看来，答案必须在于 Roo 的依赖项。但是，假设没有任何依赖项追溯改变了它的行为，Roo 可以在不实际修改已发布代码的情况下这样做吗？在我看来，它不能，在这种情况下，我会非常渴望知道哪个依赖项（假设只有一个）追溯地改变了它的行为，以及为什么。但。我想我可能还没有找到资源来掌握提出这个问题的强烈诱惑。 :-)
【问题讨论】：
标签： java maven neo4j spring-roo dependency-management