搜尋

搜尋結果

尋。的健身中心-路氹城篇 (2)
專題報導
LifeMag Editor・2016-03-03

澳門哪裡有做gym的地方?我們繼續向大家介紹其他位於路氹區的健身中心,是金沙城中心的假日酒店和康萊德酒店,而這次介紹的兩家健身會籍更是可以共用的!即是說一個會籍就可以共用兩家設施。 假日酒店健身中心 於澳門金沙城中心假日酒店健身中心,面積為620平方米,中心備有一系列最先進的健身器材,包括TechnoGym頂尖級的體重鍛煉器械設備、心肺功能與力量訓練器材,可進行舉重及心肺功能鍛煉。此外,亦有瑜伽、普拉提及亁桑拿浴室設施,大可選擇不同方式來伸展舒緩身心。 康萊德健身中心 澳門金沙城中心康萊德酒店的健身中心,擁有頂尖健身器材,並且提供不同類型的健身課程以供選擇,例如瑜珈拉提、ARKE年輕功能訓練、新陳代謝訓練、腹部訓練、森巴舞、跑步者訓練等,每月都有課程時間表,能更好安排時間參與。 只要加入康萊德休閒會籍,便可同時使用上述兩間酒店的健身中心、游泳池、以及參加健身課程、使用桑拿房、蒸氣房、按摩池,並可享水療及餐飲優惠、免費泊車4小時。收費方面,單人會籍1個月為MOP1,800,6個月為MOP8,800,12個月為MOP16,000,另加5%政府稅。 開放時間:早上 6時 – 晚上 10時 設備便利價格 下集我們將繼續介紹更多健身中心,敬請密切留意~ !!

陳康妮:教育家的人生減法哲學
文化創意
陳康妮・2023-07-26

人生減法哲學是一種主張通過減少不必要的東西,來提升生活品質和幸福感的哲學思想。它與中國傳統哲學有一定的共通之處,也與現代的簡約主義、極簡主義等生活方式有關聯。作為一位澳門教育家,我認為人生減法哲學對於當今社會的教育和個人成長有重要的啟示。 首先,人生減法哲學可以幫助我們擺脫物質的負擔和精神的焦慮。在這個消費主義和資訊爆炸的時代,我們往往被各種商品和信息所吸引,而忽略了自己真正需要和喜歡的東西。我們可能會為了追求更多的財富和名譽,而犧牲了自己的健康和家庭。我們可能會為了滿足他人的期待和評價,而失去了自己的本性和理想。這些都會讓我們感到壓力和不滿,甚至導致心理和身體的問題。因此,我們需要學會做減法,放棄那些無關緊要或有害的東西,只保留那些對我們有價值或意義的東西。這樣,我們就可以減少無謂的開支和浪費,節約時間和精力,提高效率和質量,享受簡單而充實的生活。 其次,人生減法哲學可以幫助我們培養清晰的思維和正確的價值觀。在這個複雜而多變的世界,我們面臨著各種困難和挑戰,需要不斷地學習和創新。然而,如果我們沒有一個清楚的目標和方向,就容易迷失自己或走入歧途。如果我們沒有一個合理的判斷和選擇,就容易被誤導或利用。因此,我們需要學會做減法,去除那些干擾或阻礙我們思考和行動的因素,只保留那些有助於我們解決問題或實現目標的因素。這樣,我們就可以增強自己的邏輯能力和批判能力,形成自己的見解和主張,堅持自己的信念和原則,實現自己的夢想和願景。 人生減法哲學可以幫助我們建立良好的人際關係和社會責任。在這個多元而開放的社會,我們需要與不同的人相處和合作,需要關心和尊重他人的感受和需求。然而,如果我們過於自私或固執,就容易與他人產生衝突或隔閡。如果我們過於敏感或挑剔,就容易對他人產生不信任或厭惡。因此,我們需要學會做減法,減少那些不利於人際溝通或社會和諧的態度和行為,只保留那些有利於人際理解或社會進步的態度和行為。這樣,我們就可以改善自己的人格和品德,增進自己的友誼和愛情,貢獻自己的才能和智慧,為社會的發展和幸福做出貢獻。 人生減法哲學是一種實用而深刻的哲學思想,它可以幫助我們在物質、精神、思想、價值、人際、社會等方面實現自我提升和自我超越。作為一位澳門教育家,我希望通過我的教學和寫作,向更多的人傳播這種哲學思想,讓他們也能從中受益,並將其運用到自己的生活和工作中。我相信,如果每個人都能學會做減法,那麼我們的社會就會更加美好和和諧。 陳康妮Miss Connie Chan專注於教育(人工智能/家庭教育/生涯規劃/創新創業/幼兒教育)英國倫敦大學心理學學士澳洲墨爾本大學教育管理學碩士大學講師澳門資深教育學者澳門教育專欄作家澳門教育學作家:澳門教育創新澳門兒童文學作家澳門斷捨離學會主席

陳康妮:發展有效自主學習課堂勢在必行
文化創意
陳康妮・2022-06-06

【作者簡介】陳康妮 Miss Connie 澳門科技大學講師 澳州墨爾本大學主修教育管理學 澳門教育管理學專家澳門國際培訓師澳門作家(教育/兒童文學)澳門教育專欄作家全球職涯發展師 從事教育管理培訓工作26年 隨著社會的發展,課程改革不斷深入,教學理念發生了明顯的變化,教學模式變得系統化、科學化,增加了趣味性、互動性。以往的應試教育模式正在不斷被淘汰,這樣的課堂會比較枯燥,學生總是被動地接受教育,缺乏積極主動學習的動力,這樣也會大大地影響到學習效果,學習效率會比較低,所以在澳門開展有效自主學習課堂勢在必行,具體如何操作也需要我們深思熟慮。 首先可以確定的就是在澳門開展有效自主學習課堂一定不能脫離實際,要理論與實踐相結合,不能脫離現實。要以最新的課程理念要求為教學根本,立足於教學的實際情況,結合學生的實際情況因材施教。開展有效自主學習課堂,包含著很多方面的內容,既要有學習效率,也要讓學生們發揮自主性,讓學生們朝著學習這一目標去進行。就課堂的實際操作來看,教師在一堂課開始之前最好提前佈置任務,讓學生們去預習課程,因為一堂課的時間有限,同時班機內的學生人數多,不可能將每一個人都照顧到位,有的學生可能理解能力稍差一些,會出現課堂跟不上老師節奏的情況,做好預習能夠比較好地避免這一個情況,而且可以調動學生的自主學習能力。 學生在預習的時候,運用的是自己的思維,全是憑藉個人的意志去理解知識點,預習不僅能讓學生們提前熟悉課堂教學的內容,還能讓學生們在課堂上對比自己的思路和老師的思路,可以即時發現自己存在的不足,同時因為自己也做過了題目,學生也會好奇自己的理解是否正確,這樣在課堂上的時候會更加積極,學習效率也會更高。 這是在課堂之前教師應該做的工作,在教學過程中,教師不能一味地自己講解,而不讓學生之間進行討論,所以在課堂開始的時候,老師可以向大家解釋本堂課的教學目標,爲大家後麵的學習定一個方向,接着教師可以講述一下這堂課的中心內容,讓學生對於知識點有一個基本把握和了解,接着給出幾個可以發散思維的問題,給出學生進行自主討論的時間,讓學生們在自主討論中去探究知識點更深層的含義,幫助學生們進行自我歸納與總結。 教師需要注意的是,一堂課的教學重點不能有太多,要吃透教材,把握住最爲關鍵的幾個點,這樣才能更有針對性,才能幫助學生們吃透知識點,而不是淺嚐輒止。課堂最後老師也可以佈置一些課下的任務,讓學生們回去進行思考。 總而言之,在澳門發展有效自主學習課堂是一條必須要走、需要不斷探索的路,創新教育教學模式,激發學生的自主學習能力,有利於為社會培養高素質人才,也有利於學生未來的個人發展,我們要結合實際情況,不斷探究,不斷精進。

「時尚匯」購物中心完美揉合奢華時尚與精緻美 麗思酒廊獨家呈獻「KWANPEN 80週年慶典下午茶」
生活在我城
LifeMag Editor・2017-12-17

澳門最具時尚風格的購物熱點「時尚匯」購物中心,於12月特別聯同澳門麗思卡爾頓酒店的麗思酒廊隆重呈獻「KWANPEN 80週年慶典下午茶」,慶祝奢華皮革品牌KWANPEN傳承亞洲傳統,以卓越工藝創造出一系列雋永不凡的鱷魚皮革手提袋。由即日起至2018年1月31日,麗思酒廊獨家推出精緻的主題下午茶,配以一系列精選茗茶,帶來時尚優雅的午後時光。下午茶套餐價格為澳門幣488元*(供兩位用),賓客另可選擇澳門幣688元*之下午茶套餐,享用兩杯Perrier-Jouët香檳。套餐提供多款精美甜點,包括銀朱古力蒙布朗、紅莓朱古力樹幹蛋糕、開心果泡芙、藍莓薰衣草撻,以及精選鬆餅;咸點方面,則有牛油果慕絲配鮮蝦沙律、黃甜椒銀杏伴三文魚籽、帝皇蟹腳沙律伴蕃茄碎、煙熏鰻魚餅,以及火雞樹幹蛋糕。KWANPEN經典的 Raffles系列色彩鮮豔,使用鱷魚皮革腹部中央剪裁,以及獨有配件設計。而「KWANPEN 80週年慶典下午茶」則以Raffles系列作為靈感,將美食與品牌的超卓工藝完美融合。賓客在細意品嘗下午茶美點之餘,更可於「時尚匯」購物中心的KWANPEN專門店親身探索全人手製作的Raffles系列。一貫KWANPEN皮革工藝傳統,工匠都為Raffles系列的每個手袋一絲不苟地挑選合適大小的皮革、圖案和紋理。「澳門銀河」零售助理高級副總裁黃興齡表示:「『時尚匯』購物中心薈萃國際知名時尚品牌,提供優質的服務及餐飲選擇,讓賓客感受精彩獨特的休閒體驗。KWANPEN 創立80週年,意義非凡,為此我們十分雀躍能透過麗思酒廊特別設計的主題下午茶,展現KWANPEN的家族傳承及亞洲頂尖皮革工藝。」來自新加坡的KWANPEN創立於1938年,每件產品的設計均精緻奢華,工藝超凡,至今已發展成為市場領先的鱷魚皮革和奢華配件品牌。為慶祝品牌成立80週年,賓客可親臨位於「時尚匯」購物中心的KWANPEN專門店,探索別出心裁的 Raffles 系列,同時可於麗思酒廊細味主題下午茶,盡享時尚與美食共冶一爐的精彩時光。*上述價格須加10%服務費及5%政府稅

Spring Data Jpa 自動化的選擇 - Code First
科技新知
MacauYeah・2025-01-22

Code First vs Database First 在早期SQL資料庫盛行的年代,在設計要使用資料庫儲存資料時,很經常遇到一個策略選擇的問題*Code First* vs *Database First* 這兩個策略的差異可能越來越講不清,筆者也找了一些現時網路上的講法。 Code First: 先從寫程式的角度出發,設計數據模型,再使用工具把你程式碼中的數據模型類(Class),生成一個對應用SQL資料庫的表(Table),自動編做好對應的數據結構(Schema)。這樣你在設計時,以程式設計為主導,方便熟悉程式的人使用。這常見於第一手開發設計,因為資料都是第一次收集和儲存,考慮收集程式的運作最為實際。 Database First: 先從SQL資料庫的儲存、取用資料的方式出發,先用SQL成生Table及Schema,再轉變成為程式碼中的數據模型。這樣的資料庫在日後作分析用途時,比較簡單易懂,方便使用熟悉SQL的人去使用。這也常見於二次開發程式,因為這樣可以確保不會錯誤地破壞原有資料庫。 那麼筆者為何講這兩個差異越來越講不清?那是因為現在的資料庫不能單純地只考慮初次或二次開發問題,而是需要考慮多個系統協調運行的問題。 多系統共享協定 - Database First 因為隨著資料系統發展,有些資料會作為數據源出現或用作共享媒界,如果一定要對設計策略作分類,在多系統協調運作下,這些應該叫使Database First。不論它們是SQL還是NoSQL資料庫,我們的程式碼都要為這個預先定義好的數據結構作出妥協。不論使用工具,還是人為分析,都要把共享的數據結構轉換成自己程式中的數據模型。 即使不是多系統協調運作,有時候因為要移植系統,但同時又要令兩個系統版本相容。新系統也是被逼使用Database First的方式設計。 自動化考量 - Code First 前述我們講到,很多時候我們也是從Database First的方式思考。不過筆者就這個Database First,也弄到滿身傷痕。 首先,拋開工具轉換的誤差,我們人為的把共享數據轉化為數據模型,共享數據有時會有一些先天的缺陷,例如: 資料沒有設計Primay Key (主鍵,唯一鍵)、日期時間的定義不明確等。面對一些意義不明的數據來源,要整合確實很要命。而且二次開發中,不可能100%重用原有的資料庫結構,很多時都會加入新的欄位或更多表格去計數。一旦加入新欄位,在團隊多人開發中,那麼使用唯一的共享開發環境,就變很易有程式碼上的衝突。 若需要多人開發,各人有一個Code First的開發用資料庫,是很必要的。這也可以在系統正式升級前,對比開發中資料庫及舊資料庫的結構,觀看它們之間的差異,評估升級的風險。 也許Code First並不是重點,重點是可以隨時建立一個測試用的資料庫,這才方便合作開發。自動化的地方,不單只限於數據結構,範例資料也該是如此。如果有維繫一個初始範例資料,可以在有需要時自動生成,對於多變的環境一定有很幫助。 現時,筆者基本上都會人為檢視資料庫,人工對照編寫程式中的資料結構(即是人工的Database First),並確保那時程式再次經自動化生成的測試用資料庫,並沒有失真(即是Code First)。至於範例資料,初期筆者也只使用SQL生成,但後期因為資料結構開始複雜,筆者也暫暫使用程式碼生成,雖然工作量會多了,但對於資料庫升級、品牌更換,這是很有效的手段,程式碼升級測試也更順暢,絕比SQL生成更易維護。 Ref - Code First vs Database First https://builtin.com/articles/code-first-vs-database-first-approach

為程所困-是什麼讓你不想寫自動化測試?
科技新知
MacauYeah・2025-01-08

測試場 VS 自動化測試 筆者一直地更新自己過去所編寫的程式,很恐怖的是,那時的自己很少思考過怎樣寫測試Test Case。致使每次做更新時,都膽戰心驚,要手動建立測試場,人肉去測試每個可能有受影響的地方。在那些年的時候,有能力自己搭建測試場,已經是萬幸。但當面對一些要長期維護的程式,測試場的人肉測試並不是一個有效的方法,一來費時間,二來人腦記憶並不可靠。單靠自己去想想那些地方受影響,再測試,某程度是在挑戰人腦的記憶上限。如果是團隊合作,就更麻煩,你以為修改不會影響到其他人,結果卻是翻天覆地。 所以為求長治久安,編寫自動化測試,是有必要的。這些自動化測試,都算是回歸測試,每次程式有任何地方改動,都確保所有自動化測試被通過。理想始終是理想,但實際操作又會遇到怎麼的問題? 以筆者剛更新的程式為例,難以測試主要是當初沒有想過要測試這件事,所以程式結構通常是【連續順序】地執行。想分段測試?除非先重構。 Function中太多自己創建的Object 回顧自己的程式,初期編寫時,總會我手寫我心,每想要創建任何資源,在java中就會使用 new 字眼,或是自行呼叫某些 builder 類來取得資源,這是其中一個令自己無法寫測試的原因。 我們要想想,這些資源,是不是自己Function中所關心的核心。如果這個資源是被直接回傳的,我們要保留,如果它是HttpClient,只是要來獲取其他資源的媒介,我們或許可以利用依賴注入來取得它,即是把 HttpClient 改為經呼叫方傳入。注入的好處時,我們可以在Test中,修改那些資源的行為和結果。更進一步的是,把那些資源改為 interface 的方式存取,那麼在 Test 中就能更任意地控制該資源的行為。 首次重構某些資源成為依賴注入,大部份都會影響呼叫方,很多地方都要重寫。不論使用constructor injection, setter injection, annotation injection 等,上傳呼叫方,或多或少都會要加減改變參數。極致地,我們把構建都交給Program 框架去做,例如Spring Boot中,各種資源,都交給框架去自動配致。當然,這種做法的學習成本高,除錯成本也高。 【注入】其實是想在控作那些資源,在測試中運行得到固定的行為。使用前述的HttpClient例子,當我們業務邏輯是先訪問外部Web API,再根據結果做處理,那麼我們測試時,就會想模擬Web Api的結果。如果要做到自動化測試,最強硬的手段,就修改自己的HttpClient,模疑給出固定結果。 想要做到這種,在傳統的Java中,我們需要透過進一步抽離Interface去做。但這樣做很累,所以筆者通常會用如Mockito的程式庫,去修改HttpClient的行為。有興趣直接看程式碼的讀者,可以去看 github 。 當然,上述的 HttpClient 例子,使用測試場也有可做測試,自己再去模擬那些Web Api的回傳,有些情況下,這樣會更真實,但大家就必需好好定義測試場的行為。因為測試場可能與團隊的其他成員所共用,有機會其他人可能想要更多互動的測試方式,而非固定的結果。但並上非固定結果的測試場,自動化要測試的可控度就減少。

Docker 來源掃瞄 - Docker Image Scan
科技新知
MacauYeah・2024-12-19

當網安要求越來越高時,我們也要留心 docker image 的來源是不是有漏洞問題。 docker hub 本身就已經有一些安全掃瞄報告,以 nginx 的 1.27.3 版本為例, docker hub nginx 1.27.3 , docker hub 已經列出相當多的CVE漏洞。 不過對於不公開的 docker image ,安全描瞄可是要收費的。作為小團隊,可能想先尋求一些簡單的免費方案。如果你想同樣的需求,可能Trivy會幫到你。 Trivy Trivy 是一個用於描瞄軟件版本依賴或設定檔是否引用到一些有漏洞問題的軟件,它也能檢測 docker image 是否有漏洞或錯誤設定的問題。而且更好的是, Trivy 本身亦有 Docker Image 版本,我們就不用煩惱怎樣弄一個 Trivy 的執行環境,只要可以運行 docker ,有網路就可以了。但使用 Docker Image 版的 Trivy 有一個額外要求,就是它要有主機上的 docker.sock 權限。 描瞄的指令如下,其中 docker.sock 就是為了讓 containers 內部的程式可以存取主機的 docker daemon , .cache 則是為了方便暫在下載資源。 上面故意用 nginx 的兩個同版本號不同平台的 docker image,其實就是為了引出一些潛在問題。nginx 預設是使用的debain OS的,在筆者寫文章的當下,已經更新到最近的 image ,但始終有一大部份可能的漏洞。反觀 alpine OS 版本,就找不到這麼多問題。 這是因為 alpine 預設安裝的依賴較少,所以找到的漏洞也少。正所謂,做多錯多,唔做唔錯(大誤)。這其實有好有不好,因為在發生問題時,在 alpine 下可能連基本的除錯工具都沒有。除非大家有完整測試,或者對 alpine 有相當的認識,你才會選擇一個非官方預設的版本。但就以事論事,引用較少的依賴,長久之下的確是不會有那麼多隱患。大家如果有條件,也可以試試 alpine 或其他版本。 前一節我們可以看到,Trivy需要經過 socket 的方式才能存取主機上的 container daemon 操作權。但 podman 作為一個不主張 daemon (daemon less),亦主張不需要 root (rootless),那麼它該怎樣執行? 其實podman也有user層面上的 socket,而且 trivy 也有對應的方式去轉用第三方 socket (有點像使用遠端主機 socket,但官方並未宣佈正式支援遠端的方式。) 具體使用方式,筆者亦已在 steam deck 上測試,使用方式如下。不過因為 steam deck 預設沒有 root,筆者就省略 cache 指令,免得之後要有權限問題要手動清理。 Ref Podman socket activation Trivy: Support for rootless podman

Spring Data 關聯型態 01
科技新知
MacauYeah・2024-07-16

筆者身邊的朋友,首次接觸 ORM 的關聯型態時都會覺得很難,筆者自己也是。但在好好地理順它的設計時,就會覺得其實很簡單。 因為篇輻很長,我們先以Code First的角度,先體驗一下ORM程式讀取的便捷性,以及解決一個常見的序列化問題。 雙向存取 例如一個Parent,有好幾個Child @Entity public class Parent { // ... Parent Primay Key @OneToMany(mappedBy="parent") List children = new ArrayList(); // TODO add remove } @Entity public class Child { // ... Child Primay Key @ManyToOne Parent parent; } 上述的寫法很簡潔,ORM會為你自動加入join column,處理關聯的載入。在讀取Parent時,它的所有Children就可以直接在Java層面讀取,在讀取Child時,它的Parent也隨時取得。也就是,開發人員只要經SQL準備其中一方的資料,另一方並不需要手動準備,它就可以自動按需載入。 RESTFul API 坑-雙向存取 Spring Data在Java層面的雙向存取,已經做到很方便。但經常坑到我們的是Spring Data與RESTFul API的混合應用。當我們嘗試經API回傳我們的Parent Json時,API會很聰明地把關聯的Children也變成Json回傳。但他也會把child中的parent不斷重複變成json,變成無限輪迴。 坊間有兩種不同的解決方案,可以防止無限輪迴。 讓Json可以認得已經序列化的元素。@JsonIdentityInfo 讓Json只可以單向序列化(serialization)。@JsonManagedReference, @JsonBackReference, @JsonIgnore 筆者兩個方向都試過,但首個方法並不通用,至少它不能算是一般常見的無腦Json結構。它需要伺服器、客戶端都懂這如何經IdentityInfo認得重複出現的元素。 而單向序列化,是筆者現時的通用解。在設計RESTFul READ API時,筆者就會決定到底是Parent自動回傳Child,還是Child自動回傳Parent。決策的考慮因素,主要在於是否可以簡化Client的API調用次數。通常從Parent出發,自動回傳Child,可以節省API調用。但如果是選項性的結果(List of Value),就倒過來。有時候,遇著API需要雙向設計,就只好自己設計DTO資料傳輸對象 (Data transfer object, DTO)。 例如Parent API,就原封不動回傳原本的元素 @Entity public class Parent{ // ... Parent Primay Key @OneToMany(mappedBy="parent") List children = new ArrayList(); } @Entity public class Child { // ... Child Primay Key @ManyToOne @JsonIgnore Parent parent; } Child API,就反過來引用。 public class ParentDTO { // ... Parent Other fields except children } public class ChildDTO { ParentDTO parent; // ... Child Other fields } 這種DTO,看起來很麻煩。但其實Spring有提供一個簡便的複制DTO功能,它可以把自動複制兩個class中有同一名稱、同一型別的欄位到另一個class上,不需要逐個欄位明文寫出來。 BeanUtils.copy(child, childDTO); BeanUtils.copy(parent, parentDTO); childDTO.setParent(parentDTO) // 因為child、childDTO中的parent欄位型別不同,BeanUtils.copy會自動忽略,其他欄位就會自動複制。 註: 其實古早的網頁系統設計,DTO的概念一直存取。只是現在RESTFul API的流行,很多框架已經提向便捷的Json轉換。若然平時只需Json單向存取,筆者還是省略DTO的建立。

Spring Boot - Maven Cheat sheet
科技新知
MacauYeah・2024-01-12

基礎 刪除所有結果,全部重新編譯 mvn clean compile 跑起用Spring boot寫的main class,運行Spring boot context。 mvn spring-boot:run # or mvn clean compile spring-boot:run 執行測試用例,預設只會測試test資料夾下以某些命名規則的class(例如class名以Tests或Test結尾的class,其他命名規則筆者未有能力一一驗證) mvn test # or mvn clean compile test 多Profile、多組件、多測試 使用-P指定編譯時的選用pom.xml中的project.profiles.profile參數。也可以用此來傳遞到spring profile,使得編譯後的spring war預設選擇特定profile。 mvn clean compile -PmvnProfile # or mvn clean compile spring-boot:run -PmvnProfile 使用-pl限定mvn指令只對某個子組件生效,但有時候子組件之間也有引用關係,所以需要再額外加上-am參數(--also-make) mvn clean compile spring-boot:run -pl SUBMODULE_NAME -am 使用-Dtest=限定只執行某個class的測試用例,或單個測試函數。(可以無視class名的命名規則) mvn test -Dtest=TEST_CLASS_NAME # or mvn test -Dtest=TEST_CLASS_NAME#TES_METHOD_NAME 若屬於多組件情況下,其他子模組找不到同樣名稱的測試,會測試失敗。需要再加上-Dsurefire.failIfNoSpecifiedTests=false mvn test -pl SUBMODULE_NAME -am -Dtest=TEST_CLASS_NAME -Dsurefire.failIfNoSpecifiedTests=false # or mvn test -pl SUBMODULE_NAME -am -Dtest=TEST_CLASS_NAME#TES_METHOD_NAME -Dsurefire.failIfNoSpecifiedTests=false 打包 在本機電腦中,把java變成jar或者war。通常用於自行發佈的環境中。 mvn package 有時特定Profile沒法成功執行測試用例,或者你認為有些測試問題不影響使用,需要跳過package中的test。 mvn package -Dmaven.test.skip=true # won't compile test folder mvn package -DskipTests=true # compile, but won't run 例外情況 強行把一個第三方jar,種到本機電腦中的.m2/repository # copy from https://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html mvn install:install-file -Dfile= -DgroupId= -DartifactId= -Dversio