directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Knecht <fel...@apache.org>
Subject Re: General Information in pom.xml
Date Sun, 30 Dec 2007 11:38:07 GMT
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
>>
>>   
> 
> 


Mime
View raw message