我們的應用程序之一有耳朵spring-mock.jar。我是CM，我不是開發人員，但它似乎並不像你想要的生產應用程序中的模擬服務。我認爲spring-mock.jar允許你在測試時模仿某些服務。彈簧模擬生產代碼
我看到spring-mock.jar中的任何類都沒有代碼依賴性，但始終存在可能的運行時依賴關係，它們不是編譯時依賴關係。
該組織收集了大約160個jar文件，並在編譯時將它們全部轉儲到classpath中。當他們下載耳朵和耳朵時，他們並沒有做得更好。我的工作是清理這個爛攤子。我找到了重複的jar文件（即同一個jar文件的不同版本），在其他jar文件中找到了很多重複的類，甚至在ear和sar文件中都有junit.jar。
那麼，spring-mock.jar是否有類似的問題？
好的，如果您有權訪問Ant構建文件，我假設您還可以瀏覽源代碼。
在這種情況下，最簡單的事情將是運行的org.springframework.mock.*和org.springframework.test.*使用這些文本文件的一些自動搜索（這些都是我在jar文件中找到的包）。
這樣你可以找到有多少個地方使用spring-mock.jar的內容。如果它們全都位於test目錄中，（不同的是，依賴關係只在單元測試中），那麼你就安全起來了。如果不是，你寧願不從類路徑中移除這個依賴。
我做到了，並使用了Tattletale。在任何生產代碼甚至測試代碼中都不依賴於spring-mock.jar。如果spring-mock.jar處於依賴關係中，我也可以編譯。正如我所說，它可能是一個運行時依賴。我會給開發一個機會來回答一個場景，爲什麼mock會在開發環境之外使用，即使它在開發環境中使用，爲什麼它應該包含在將用於生產的耳朵中。我想要一個不涉及「我」，「不」和「知道」這三個詞的答案。 –
如果您擔心可能會在運行時注入某些依賴項，那麼它們也必須在某處（例如Spring XML文件）進行定義，因此掃描這些文件也可能會有所幫助。我不知道這是否會讓你百分之百地回答這個問題是不是以其他瘋狂的方式注入的，但它可能會讓你變得相當接近這個100％。 – Jagger
你絕對不應該在你的集成環境中嘲笑，那麼爲什麼不試試在集成環境中刪除這個'spring-mock.jar'並且看看事後會發生什麼。這樣你就不會直接在生產系統上這樣做。 – Jagger
還沒有那麼遠。我正在清理過程中。 _current_系統使用''和9個文件的Ant構建文件。大多數目標受到大約十倍的打擊，許多被稱爲14倍。 （而且，他們想知道爲什麼需要這麼長時間）。我已經將構建文件合併到一個'build.xml'中，刪除了使用'depends'參數的''，並添加了Ivy。儘管常春藤下載罐子，但構建需要1/5的時間。但是，我必須通過複製當前輸出來證明這一過程。現在，我已經做到了，我正在記錄開發人員必須清理的問題。 –
感謝您的評論。我會給你信貸，但你只是發表評論。我只是爲開發人員編制一系列問題列表，以查看__。順便說一句，在集成中存在一個簡單的刪除和測試問題。那個罐子可能不是一直需要的。可能有一個流程每個月只運行一次，或者每年運行一次，需要那個jar。刪除它，並且一切運行良好，直到該過程被執行。這就是爲什麼在生產中去除垃圾非常困難：沒有人確切知道需要什麼。 –