为什么运行旧版本不会复制旧行为?

时间:2014-08-05 10:08:56

标签: java maven neo4j spring-roo dependency-management

让我重新措辞,以便更直接地提出问题的尖端:Neo4j曾与Roo一起工作(也许并不完美,但至少在一本书中发表的一些简单例子显然确实有效)。 为什么我不能下载作者使用的Roo版本并复制作者的结果?

当然,一个浅薄的答案是软件依赖关系不属于Roo发行版的一部分已经改变

更深层次的问题是,为什么会发生这种情况?也就是说,为什么我不能将提供这些依赖关系的软件版本下载到作者写作时当前的Roo并期望能够复制他的结果? < / p>

在这一点上,我有点卡住了我无法理解为什么。我似乎没有任何办法能够确定这些版本可能是什么。看起来这应该是Roo配置管理的关键部分。但是,考虑到这一点,我不记得这种记录保持是典型实践的一部分,除非涉及RPM包管理器。现在,也许我对这一点的看法是错误的。但是,如果他们不是不通常的开源开发方式需要在此时进行升级吗?或者也许我完全错了你可以回转Roo的时钟,可以这么说。如果是这样的话,请有人告诉我如何将其转回去,以便Neo4j能像以前那样工作(无论好坏,我都不在乎。我只是想复制的结果。)

这是表达和攻击问题的更好方法吗? 我非常努力地支持迄今为止关于Roo 的几本书中的一本。坦率地说,我希望看到这本书的作者或出版商涉足并帮助我或反驳我,因为这本书仍然被出售。 如果正在进行的示例严重破坏,我认为在我看来继续销售这本书是错误的,或者至少在没有向读者发出明确警告的情况下将其出售。 O&#39; Reilly出版了这本书,我对他们的商业道德有很高的主观意见 - 一个足够高的观点,我想知道我是否弄错了。

一般来说,当你出错时,你可以依靠100个人来告诉你(另外还有10到20个人告诉你,你做了得到的点错了正确和另一个5-10抓住一些基本上无关紧要的点,并且显然与你的乐趣相矛盾,而不以任何方式推动讨论 - 一个合作的概念,他们似乎无法抓住,更不用说追随了)。但我和其他基本上问同样问题的人除了蟋蟀之外什么也听不见。线性调频的线性调频???


mv(对不起:我没有立即找到用于标记成员ID的标记语法)问了一个关于Roo对Neo4j的支持的未来状态的问题,看起来已经失败了。一个相关的问题困惑 - 并让我感到沮丧 - 很大。 Neo4j在Roo 1.1.4下受到支持,但是当我尝试当1.1.4是最新版本时显然有用的代码(来自Josh Long的书 Roo入门)时,代码完全失败了它在1.2.5(和即将发布的版本,1.2.6)下失败的方式。换句话说,似乎可以说,对Neo4j的支持被追溯删除了。

我的问题是对该观察的概括:在什么技术环境下(我不想考虑可能的法律原因)会是好的(即,合理,实用,必要。&amp; c 。)追溯性地改变软件产品发布版本的行为?&#34;

目前,我发现这个决定是因为尊重Roo不方便,所以我想我可能会忽略这个决定的充分理由。但请注意,我的问题并不特别适用于Roo。首先,我不喜欢讨论,参与者努力让Roo团队看起来很糟糕。另一方面,我对一般情况感兴趣,而不仅仅是Roo的特殊情况。实际上,在我看来,行为中不存在追溯性不一致是健全系统的必要条件。我的意思是,例如,在不确定性开始的时间到了什么时候?是在所述释放的可行性持续时间期间还是之后。可能我戴着我的小鸡帽子但是现在我觉得好像追溯不一致有&#34; Humpty Dumpty&#34;写满了它。

话虽这么说,我想我会偷偷回答第二个问题,但我非常感谢被告知我的前提是尊重Roo是不准确的;也就是说,Neo4j 可以以某种方式在Roo的一些适当的旧发布版本下使用。在这种情况下,我也非常好奇地知道如何完成。 Roo不需要任何设置配置,因此似乎没有机会进行配置调整。实际上,唯一声明的要求是Linux,OS X或Windows下的JDK和Maven。但是, addon 命令显然会查询某种类型的数据库。也许这是一个未说明的依赖,负责追溯不一致的Roo行为。

在第二个问题中偷偷摸摸,我发现难以抗拒试探第三个问题。如果我屈服,那么问题就是:在Roo的特定情况下,如果可能(假设发布代码没有被秘密更改),旧版本的行为是否已经改变了? 在我看来,答案必须在于Roo的依赖。但是,假设没有任何依赖项追溯性地改变了它的行为,那么Roo可以在不实际修改已发布的代码的情况下这样做吗?在我看来,它不能,在这种情况下,我非常渴望知道哪个依赖(假设只有一个)已经追溯性地改变了它的行为,以及为什么。但。我想我还可以找到掌握这个问题的强大诱惑的资源。 : - )

1 个答案:

答案 0 :(得分:0)

很长的问题,..

运行旧版本应该复制它的行为,但由于各种情况可能会出现不一致。如果没有更详细的问题描述和堆栈跟踪(如果有的话),很难确定那些。

您声明您认为roo-distribution的软件依赖性可能已经发生了变化,但情况并非如此:maven作为您的依赖管理器,只要存在,就应该处理这个问题。 SNAPSHOT(或者更确切地说,在依赖关系树中)没有pom.xml个依赖关系。

但是现在行为可能有所不同还有其他原因。它可能是您使用的JDK的版本。这些也应该向后兼容,但在维基百科上,我看到spring roo不支持Java 8,例如。

然后有你的操作系统,但我相信如果现在这个问题就会出现某种错误。

最后我会看一下spring roo的第三方插件。不幸的是我对它们并不熟悉,但在我看来,第三方插件是通过一些命令下载的,这些命令并不一定要求此插件的正确&#39;兼容版本。

我希望这个标题问题的答案可以帮到你。你的第二个和第三个问题确实帮助我制定了这个答案,但一般来说,最好在第二个和第三个问题中单独发帖。