Hey David, as you found out you have to define groupId, artifactId of your parent in the pom. I don't believe it is a lot of maintenance though as on many projects I've worked on groupdId and artifactId don't change much.
You also have to specify the version. This can seems like a lot of pain to maintain especially when releasing. But the maven-release-plugin makes it as easy as it gets: http://maven.apache.org/plugins/maven-release-plugin/ You don't need to define the path to the parent pom. Maven will look up in .. by default. Or will get it from the repository if it can't find it there. SaM On Tue, Mar 4, 2008 at 10:04 PM, David Delbecq <[EMAIL PROTECTED]> wrote: > I'll try to find out solution, i began with one of our simplest project, > it's made of several subprojects (using multproject maven 1 goal), but > they have no custom maven.xml (should be the easiest to convert). But i > don't get how to get the equivalent of > > <extend>../project.xml</extend> > > I tried > <parent><relativePath>../pom.xml</relativePath></parent> > > But with i try a mvn jar, it complains the groupId of the parent tag is > not defined. That a problem because i need the groupId and the version > to be inherited from the parent. How should i do it? > The online doc is of no help. It says > > > Alternatively, if we want the groupId and / or the version of your > > modules to be the same as their parents, you can remove the groupId > > and / or the version identity of your module in its POM. > > > > <project> > > <parent> > > <groupId>com.mycompany.app</groupId> > > <artifactId>my-app</artifactId> > > <version>1</version> > > </parent> > > <modelVersion>4.0.0</modelVersion> > > <artifactId>my-module</artifactId> > > </project> > > > As you see in xml fragment given, they did *not* remove the groupId and > versionId? Is it possible to inherit groupId and versionId or will i > have to manually maintain all those ids in each release? > > Sorry to bother you with basic question :) > > > En l'instant précis du 04/03/08 11:32, Samuel Le Berrigaud s'exprimait > en ces termes: > > Hi again, > > > > I personally don't know any plugin that would take your maven.xml and > insert > > it into the maven 2 lifecycle. There is no notion of lifecycle in > maven1, > > just goals. I guess implementing such plugin could be possible but > > definitely not trivial. > > > > Indeed the xslt plugin doesn't give much details about its support. You > > would probably need to get some work done on the existing one or write > your > > own. I don't see that being a huge amount of work. But it would still be > > some work… > > > > Regarding the project on which you depend, your best bet is still to > have it > > as a dependency for your project. Even if it is not maven2, you could > > probably get this other project team to deploy it to an internal maven2 > > repository or do it your self manually when they release it. Some other > > plugins will allow you to filter the files as you extract them. And as > Simon > > said you still have the maven-antrun-plugin: > > http://maven.apache.org/plugins/maven-antrun-plugin/ > > > > I am sorry I cannot be more helpful here, > > maybe someone else has another experience with migrating maven.xmlscripts? > > > > SaM > > > > PS: I don't know what happened to the page you reference in your first > mail > > (http://maven.apache.org/guides/mini/guide-m1-m2.html). Maybe a maven > > developer could help here? > > > > On Tue, Mar 4, 2008 at 9:11 PM, David Delbecq <[EMAIL PROTECTED]> wrote: > > > > > >> Hello, > >> > >> i was hopping there was some way to take my pack of maven.xml preGoal > >> rule and just relocate them somewhere where maven2 would use them. You > >> suggestion will not work. For our XSLT transform, we need to pass > >> parameters to the xslt transform engine (for that we use saxon > >> transformer with some specific transformation parameters), i don't see > >> such equivalent in what you pointed me to nor is there information > about > >> version of xslt supported (1,2? we need 2). > >> > >> For the dependency plugin we have to investigate, but if that mean we > >> need to upgrade included project to maven 2 also, that's a no go. That > >> project i have no write access to and we don't plan maven 2 for it, we > >> just currently, in our build process, download it along our main > >> project, and retrieve some files from it (files we patch on the fly > >> using <ant:replace /> rules btw). We don't even build it, we only need > >> it's webapp (jsp/pictures/html/config) files integrated in our app. > >> > >> > >> So, if we could keep our current build process rules (maven.xml), and > >> just somehow move them in a plugin that would be lot's easier. Some of > >> the jelly rules took time to implement, we don't have the time to > >> recreate all them. Isn't it possible to take the maven.xml and put it > in > >> a project.jelly or it's maven2 equivalent? > >> > >> I need some direction on how to easily convert from maven1 to maven2, > >> related to maven.xml, but all link related to that in maven site seem > >> dead (see my first mail) > >> > >> > >> En l'instant précis du 04/03/08 10:57, Samuel Le Berrigaud s'exprimait > >> en ces termes: > >> > >>> Hi David, > >>> > >>> You don't to implement your whole maven.xml into one maven2 plugin. > >>> > >> Instead > >> > >>> you should decompose what you do in your maven.xml and find out the > >>> > >> existing > >> > >>> maven 2 plugins that would enable those different tasks. > >>> > >>> For example, if I take your two examples below: > >>> - copying resources of another project: > >>> I would make that project a dependency of your web application and > that > >>> would be sufficient to add those on your classpath. > >>> If you need them outside the classpath, I would probably use the maven > >>> dependency plugin: > >>> > >> http://maven.apache.org/plugins/maven-dependency-plugin/ > >> > >>> using the unpack goal, it will unpack the jar wherever you need to. I > >>> > >> would > >> > >>> attach that to the "process-resources" phase of you war module. > >>> > >>> - xslt transformation > >>> that should be fairly easy using the XSLT plugin: > >>> http://mojo.codehaus.org/xslt-maven-plugin/ > >>> attaching it to the same "process-resources" phase. > >>> > >>> Hope this all make sense. I strongly advise researching existing > plugins > >>> before writing your own. All the configuration will go in your > pom.xmlso as > >>> with the maven.xml you can update those rules easily. > >>> > >>> SaM > >>> > >>> On Tue, Mar 4, 2008 at 8:39 PM, David Delbecq <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>> > >>>> Hello, > >>>> > >>>> we have a few project here using maven 1. They become difficult to > >>>> maintain when it come to using new plugins that are not available for > >>>> maven 1. So we thought it might be time to switch to maven 2. > Question > >>>> is, considering about all projects are using preGoal/postGoal and > >>>> personalized rules in maven.xml, what should i do with them? I read > >>>> there is no equivalent of maven.xml, i need to use a plugin. Can I > sort > >>>> of embbed that plugin with the project that use it, or do i need to > >>>> create a separate plugin project for each of our maven.xml, compile > and > >>>> deploy those plugin change everytime before compiling the main > project > >>>> (with maven 1, changes to maven.xml were immediate)? Also if someone > >>>> > >> can > >> > >>>> point me to documentation about converting that maven.xml to a > plugin, > >>>> it'll be great. Documentation here > >>>> http://maven.apache.org/guides/mini/guide-m1-m2.html , section "what > to > >>>> do with maven.xml" point to error page (the pages seems to have been > >>>> removed from maven site :( ) > >>>> > >>>> example of such task of maven.xml here is, we have a project X that > is > >>>> > >> a > >> > >>>> webapp. In a subdirectory of that webapp we need to copy all > ressources > >>>> of another project Y, and we need to merge the struts and web.xml > >>>> configs (we use a xslt processor for that). Am not sure how easy that > >>>> can be transfered to a plugin... > >>>> > >>>> -- > >>>> David Delbecq > >>>> Institut Royal Météorologique > >>>> Ext:557 > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >> -- > >> David Delbecq > >> Institut Royal Météorologique > >> Ext:557 > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > > > > > > -- > David Delbecq > Institut Royal Météorologique > Ext:557 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Samuel Le Berrigaud
