| Re: [m2e-users] share a m2Eclipse like "Team Project Set" |
Hi, so today I’ve tried the super pom “workaround” Strukture in svn: “Team Project Set” |-- projectA | |--trunk | |--branches | |--tags |-- projectB | |--trunk | |--branches | |--tags If I now add a super pom, I’ve to add it like this: “Team Project Set” |-- projectA | |--trunk | |--branches | |--tags |-- projectB | |--trunk | |--branches | |--tags |--pom.xml And if I checkout as maven project “Team Project Set”, so I will get all branches and tags. @Asaf, did I understand you the right way? Fredy Von: m2e-users-bounces@xxxxxxxxxxx [mailto:m2e-users-bounces@xxxxxxxxxxx] Im Auftrag von Hauschel Fred Robert Hi Asaf, >Thus super pom seems a cheaper and easier solution for your client, than Team Project Set.< Yes, you are right! I will do it this way. > The only trick is to checkout the source code of each project into that food-build directory, right? You can script it hard coded, and than later make it more generic.< That is no problem, the developer have to do one action anyway, so I let him “checkout as maven project” the super pom. I think I will find a place in svn therefore. Thanks Fredy Von: m2e-users-bounces@xxxxxxxxxxx [mailto:m2e-users-bounces@xxxxxxxxxxx] Im Auftrag von Asaf Mesika I think the easiest way to go is: File -> Import -> Maven Project and then choose the pom.xml of the super pom. It automatically marks and loads all modules (<module>) contained in that super pom. Each module will be a subdirectory in the foo-build dir, which hold the super pom.xml. It's way easier and portable than a Team Project Set, which is not guaranteed to be compatible with future version of Eclipse. Thus super pom seems a cheaper and easier solution for your client, than Team Project Set. The only trick is to checkout the source code of each project into that food-build directory, right? You can script it hard coded, and than later make it more generic. On Tue, Feb 8, 2011 at 5:28 PM, Hauschel Fred Robert <FredRobert.Hauschel@xxxxxxxxxxx> wrote: Hi Asaf, > Why do you need a .project file for the referenced projects?< Customer requirement. The customers developers will work with eclipse and will setup the ide as easy as possible. With all artefacts of the department. !!!! And I won’t check in this eclipse stuff !!!!! > M2Eclipse generates it for you from the pom.xml< Yes, if I include the artefacts with “checkout as maven project” or “import as maven project”. But not if I import a eclipse “team project set”. > The idea is to have all your metadata in one file: pom.xml < That’s a good Idea, but I’m not sure if a pom artifact is the solution ?! All projects referenced by that SuperMasterPom shouldn’t have a dependency to the SuperMasterPom, they should have an independend lifecycle. So the SuperMasterPom in my case will be only for convenient checkout. A.k.a. “Team Project Set” for m2Eclipse users ;-)) >Thus any developer can work with any IDE (Eclipse, Netbeans, IDEA).< Yes they can do that anyway! But they won’t ;-) That is my first goal! Fredy Von: m2e-users-bounces@xxxxxxxxxxx [mailto:m2e-users-bounces@xxxxxxxxxxx] Im Auftrag von Asaf Mesika
Why do you need a .project file for the referenced projects? M2Eclipse generates it for you from the pom.xml. The idea is to have all your metadata in one file: pom.xml. Thus any developer can work with any IDE (Eclipse, Netbeans, IDEA). On Tue, Feb 8, 2011 at 4:28 PM, Hauschel Fred Robert <FredRobert.Hauschel@xxxxxxxxxxx> wrote: Hi Asaf, sound very interesting ;-) I understand your "foo-build" solution as a “big” multi module maven pom-artefact, which have all the department maven artefacts as module. This will simplify the checkout in eclipse, but it is a litle kind of workaround. Maybe I will do that! Your maven plugin will help to check out the “referenced” projects, but they are no projects with eclipse nature. You use a pom for handling the “meta-data” which for example in the eclipse project set. I’m not sure if this is The solution, but I’m sure it is the right way. Fredy Von: m2e-users-bounces@xxxxxxxxxxx [mailto:m2e-users-bounces@xxxxxxxxxxx] Im Auftrag von Asaf Mesika Why not have a "foo-build" project which has a pom.xml file of pom packaging,which serves as an aggregator for you project. This project will contain all the projects you need for a specific product. You can use git sub-module to hold the references to each project. I'm in the process of writing a maven plugin which analyzes a pom.xml file, and for a specific groupId artifacts, it retrieves its pom file from Nexus, extracts the repository location and checks it out to the "foo-build" project directory. I think Atlassian Confluence wrote something similar. On Tue, Feb 8, 2011 at 3:52 PM, Igor Fedorenko <igor@xxxxxxxxxxxxxx> wrote: You'll have to write some java code to do that, I can provide pointers Hi all, _______________________________________________
|