RE: [site&multiproject plugins] - reorganization of goals use to generate sites
> -Original Message- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 03, 2004 8:11 AM > To: 'Maven Developers List' > Subject: RE: [site&multiproject plugins] - reorganization of goals use > to generate sites > > > > > > -Original Message- > > From: Maczka Michal [mailto:[EMAIL PROTECTED] > > Sent: mardi 2 novembre 2004 16:02 > > To: 'Maven Developers List' > > Subject: RE: [site&multiproject plugins] - reorganization > of goals use to > > generate sites > > [...] > Yes, that's right, I'm not using reactor inside reactor. I > have one level > only. But why don't you ensure that you have only one level > nested? That's > what we do on our big project at work. > Becouse each level introduces in my case (and I think it is often a case) natural way of grouping projects. I very often use a "plugin" design patterns - it means that I have certain "solutions" which can have some additonal functionaliy added dynamically. So I use such layout: solutionA pluginA pluginB solutionB pluginA pluginB When I generate the whole site I want to have on the first level an overview of available "solutions" and only to have a possibility of seeing "addendums" to each of solutions from the website of particular "solution". Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [site&multiproject plugins] - reorganization of goals use to generate sites
> -Original Message- > From: Maczka Michal [mailto:[EMAIL PROTECTED] > Sent: mardi 2 novembre 2004 16:02 > To: 'Maven Developers List' > Subject: RE: [site&multiproject plugins] - reorganization of goals use to > generate sites [snip] > I also want to call something like "site" goal for each of the subprojects > but only one level down from top level project. > Then in same cases this goal should attain "site:generate" goal (if > project > is a leaf) > and only in few cases I want to recursivly attain "multiproject:site" > which > will aggreagte results from child project of subproject. > Probaly you are not using reactor inside reactor ... you have just one > instance of the reactor which process all the projects, right? Yes, that's right, I'm not using reactor inside reactor. I have one level only. But why don't you ensure that you have only one level nested? That's what we do on our big project at work. -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [site&multiproject plugins] - reorganization of goals use to generate sites
> -Original Message- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > [..] > > For the site, I still don't understand what you're problem > is. I just have: > > > > And it works fine. The "site" goal is called on each > subproject which is > what I want. > I also want to call something like "site" goal for each of the subprojects but only one level down from top level project. Then in same cases this goal should attain "site:generate" goal (if project is a leaf) and only in few cases I want to recursivly attain "multiproject:site" which will aggreagte results from child project of subproject. Probaly you are not using reactor inside reactor ... you have just one instance of the reactor which process all the projects, right? michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [site&multiproject plugins] - reorganization of goals use to generate sites
Hello Michal, [snip] > What I could do in my case > (except changing 3 lines of code in 2 plugins - which already worked > for me > :)) > is to add a goal definiton to each project which will control what > shall > happen at that level. > But in my case this is something which I wnat to avoid as I have quite > a lot > of project and only few of them need to start another > instance os reactor. That's what I do in Cargo. I have 2 custom goals (goal interfaces): cargo:dist cargo:clover For the site, I still don't understand what you're problem is. I just have: And it works fine. The "site" goal is called on each subproject which is what I want. Thanks -vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [site&multiproject plugins] - reorganization of goals use to generate sites
> -Original Message- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > [snip] > > Is your problem only with the namespace name clashing with > your toplevel > project "site" goal? No. I don't have problem with top level project - I have problems in the bottom levels of recursion. At the top level I always want to run multiproject:site. >I am doing the same thing in Cargo and I > don't have > issue. However, I've named my goal "cargo:site" in order to > prevent name > clashing. I may look how you do this in cargo. What I could do in my case (except changing 3 lines of code in 2 plugins - which already worked for me :)) is to add a goal definiton to each project which will control what shall happen at that level. But in my case this is something which I wnat to avoid as I have quite a lot of project and only few of them need to start another instance os reactor. Micha;l - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE:[site&multiproject plugins] - reorganization of goals use to generate sites
Hi Michal, [snip] > I would like change both multiproject and site plugin to make it > possible > > - In site plugin: > > I would like to attain "site:generate" goal from "site" goal - not > other way around > > - in multiproject plugin at the end of the code of the goal > > > > > > I would like to attain site:generate goal - not "site" goal. > [snip] Is your problem only with the namespace name clashing with your toplevel project "site" goal? I am doing the same thing in Cargo and I don't have issue. However, I've named my goal "cargo:site" in order to prevent name clashing. Anyway I do agree that following the established standard, the "site" goal should call the "site:generate" goal and not the other around. I'm +1 for this as I don't think it'll break anything (apart from edge cases when end users were relying on side effects...). Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
