Czy mogę użyć Spring roo w istniejącym projekcie, który nie używa Mavena?

Question

Spring Roo może być używany w istniejących projektach, które są follow standard maven layout. Do tej pory wydaje się to oznaczać, że projekty, które nie używają maven, mają pecha.

Zastanawiam się, jakie (jeśli w ogóle) są opcje dla takich istniejących projektów.

Ponownie ułóż układ projektu zgodnie z układem Maven? Wydaje się, że jest to bardzo trudna ścieżka dla projektów z wieloletnią historią w CVS ze względu na fakt, że method for moving around directories w CVS jest wyjątkowo inwazyjny.

Czy istnieją inne opcje, takie jak modyfikowanie konfiguracji Maven do pracy z niestandardowymi układami? Co pamiętam z mojej wcześniejszej lektury na ten temat, podejście Mavena CoC nie faworyzuje takich nietypowych układów.

Edycja: Odpowiedź

Richa poniżej pokazuje, że nadrzędnym domyślne w super-pom jest trywialne. Pozostaje nam pytanie, czy Spring Roo będzie dobrze grać z takimi modyfikacjami. Jest to wątpliwe, biorąc pod uwagę fakt, że Spring Roo nie wykorzystuje samego Mavena.

Edit:

Richa zaktualizowane odpowiedź wskazuje, że domyślnie ROO użyje zakodowanego ścieżki i nie odbierze modyfikacje w pom.xml więc odpowiedzieć jak dotąd wydaje się, że nie jest możliwe od razu po wyjęciu z pudełka, ale można to zrobić za pomocą niestandardowego kodowania (lub poproszenia zespołu ROO o wsparcie)

Answer 1

Nie ma powodu, dla którego my (zespół Roo) nie można zmusić MavenPathResolver do użycia niestandardowych ścieżek, a jednym z celowych powodów, dla których stworzyłem abstrakcję PathResolver, było wsparcie dostosowania wspólnych lokalizacji ścieżek nie tylko do Maven, ale nie do domyślnych lokalizacje, ale także inne systemy kompilujące, takie jak Ant + Ivy. wszystkie podstawowe dodatki do Roo zostały napisane do użycia z PathResolver, więc nie powinno to być dużym wysiłkiem, aby to wspierać. Jeśli nadal potrzebujesz tej pomocy, dodaj prośbę o ulepszenie do Roo Jira instance.

Answer 2

Możesz zmodyfikować Mavena, aby użyć innego zestawu konwencji. Standardowy zestaw odziedziczono po Maven super POM i można go zastąpić przedefiniowaniem odpowiedniej właściwości.

Na przykład, aby zmienić katalog źródłowy z src/main/java na src, katalog testowy na test-src i katalog zasobów z src/main/resources na zasoby, które można ustawić w POM:

<build> 
    <sourceDirectory>src</sourceDirectory> 
    <testSourceDirectory>test-src</testSourceDirectory> 
    <resources> 
    <resource> 
     <directory>resources</directory> 
    </resource> 
    </resources> 
</build> 

Należy pamiętać, że kilka wtyczek nie może korzystać ze standardowych właściwości, aby uzyskać dostęp do lokalizacji (np hardcoding docelowych/klas zamiast używać $ {project.build.outputDirectory}, więc może masz dziwny problem.

---

Aktualizacja: Wygląda jak curl Roo ntly ma te properties hardcoded. Możesz zastąpić MavenPathResolver lub dodać dodatkowy resolver, aby użyć niestandardowych właściwości.

Jeśli jest to dla Ciebie prawdziwy problem, możesz raise a request zmodyfikować MavenPathResolver tak, aby zezwalał na niestandardowe lokalizacje.

Answer 3

Od wersji 1.2 nie jest zaimplementowany.