Emmanuel Lecharny schrieb: > Felix Knecht wrote: >> Dear all >> > Hi Felix, >> For the m2 studio pom.xml I'm trying to figure out, what comes into >> the project pom and what's comming from the parent >> pom like >> >> <developers /> >> <contributors /> >> <licenses /> >> <mailinglists /> >> > I think they all belongs to the parent project.
Yes, but the directory-project/pom.xm doesn't contains e.g. the <developers /> tag. Tags from a parent pom are inherited. A sample for the <licenses /> tag: directory-project/pom.xml has no licenses tag. When you look at the effective pom (mvn help:effective-pom) you'll see, that the licenses tag is there - it's inherited from the parent pom which is the org.apache root pom (see http://repo1.maven.org/maven2/org/apache/apache/4/apache-4.pom). You can overwrite the <licenses /> tag if you want to specify anything else as license --> Without having and licenses tag in a module pom but referencing apaches root pom as parent you'll get the licenses for free :-) About developers/contributors/mailinglists: In fact only 1 project exists: directory.apache.org. For none of the subprojects exists neither a separate mailinglist nor (I think so) separate comit rights nor separate pmc. Thus I'd treat it as 1 project with subproject and therefore all this tags would go into the projects (directory.apache.org) root pom which shall be the parent for all subprojects. I mean, if you have a > specific plugin (the browser, for instance), then it has to store the > developpers and other associated infos to this plugin. > Hmmm, sorry I was not clear enough. I'm not talking about the maven-studio-plugin, but about the mavenization of the subproject studio and about the structure and content of the poms all over the directory project. Following the way apache did for the main root pom a directory project pom.xml should look like <project > <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.apache</groupId> <artifactId>apache</artifactId> <version>4</version> </parent> <groupId>org.apache</groupId> <version>9-SNAPSHOT</version> <artifactId>directory</artifactId> <name>Apache Directory Project</name> ... This pom then can be found @http://repo1.maven.org/maven2/org/apache/directory/8/ instead of the current @http://repo1.maven.org/maven2/org/apache/directory/project/project/8/ No need to have 'project' twice in the url - it just enlarges the url and obfuscates somehow the projects hierarchy structure which could be much clearer when 'project root stuff' is put where it belongs to and not put into a subproject 'project' obfuscating the real hierarchy. So a more hierarchical structure could look like - directory (.apache.org) | +-- pom.xml (1) +-- resources +-- site | +--> apacheds | | | +-- pom.xml (2) +--> daemon | +--> shared | +--> studio (1) This is the main pom.xml for the directory project. - It references the apache pom as parent. - Contains general information for the directory project like <developers /> <contributors /> .... (2) This is the pom.xml for the apacheds subprojects. - It references the directory pom as parent - Contains specific content for the apacheds project - May overwrite inherited content if needed > If you are to create a parent pom to build all the studio's plugin, then > it's a different story : IMHO, it should only contain the mailing lists > references (licenses must be present in all the plugin's poms, as > someone may simply install a few of them). It's inherited from the parent pom if done correctly. >> More may exist. >> >> >From my POV all the tags above are general information valid for all >> projects having directory-project set as parent >> pom. ATM it's hard to find a pattern if a specific tag is added to a >> pom of a subproject or not. >> >> What's the pattern (if one exists) ? >> > I'm not sure that ADS itself is a good pattern to follow ... ? May be > it's a perfect timing to open such a discussion, for sure ! Yes, even when I was missunderstood because of my insufficient comment what I'm thinking about ;-) We already > have talked about Studio project's layout last friday with > Pierre-Arnaud, and we reached a point were we agreed that this should be > discussed on the ML. Looking at my thoughts above I hope I can also rise a discussion about the hierarchical structure of the directory project itself (at least about the subproject 'directory-project' which in fact would be the root project). I don't know the creation of eclipse-plugins good enough to give a well base feedback about the suggested structure below. So just my 2 cents: OOH it looks definitely more structured than it is now and has a clear strategy OTH (if refactoring the structure of the studio project) we should also think about the way to go for the maven builds - doing our own maven-plugins or hope that there will be once something official that we can use - because the pde-maven-plugin presumes a completely different structure: http://mojo.codehaus.org/pde-maven-plugin/usage.html IIUC the eclipse-plugins are a king of OSGi bundles. So it might also be worth to have a look on the upcomming plugin to bundle such things. It's in apaches felix projct: http://felix.apache.org/site/maven-bundle-plugin-bnd.html. > > My personnal opinion is that Studio should have a main pom.xml for _all_ > the plugins, each plugin being seen as a project. We should also have a > 'commons' sub-project. Here is the layout I see : > > - Studio pom.xml (parent pom) > | > +--> plugins > | | > | +--> browser > | | | > | | +--> features > | | +--> plugins > | | +--> help > | +--> schema > | | | > | | +--> features > | | +--> plugins > | | +--> help > | +--> configuration > | | | > | | +--> features > | | +--> plugins > | | +--> help > | +--> Widgets > | | > | +--> File manager > | | | > | | +--> features > | | +--> plugins > | | +--> help > | +--> ... (more common widgets) > | +--> commons > | > +--> (Any component used by all the studio projects, like a > schema parser, etc) > > Another thing is that we would like to be able to build the studio > within ADS itself. ADS currently build 4 sub-projects : > - shared > - daemon > - installers > - apacheds > > we may want to build studio too, as it used shared. The idea is to be > able to see the impact on studio when we modify shared. Of course, this > should be optionnal, otherwise compiling the server will kill us ! > > Last, not least, I insist on the fact we should clearly separate > presentation from treatment into studio plugins, so we can add some unit > tests for treatments (it's almost impossible to unit test presentation, > sadly ...). > > Hope it helps ! >> Thanks >> Felix >> >> > >
