General Information in pom.xml

[Felix Knecht <fe...@otego.com>]

Dear all

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 />

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) ?

Thanks
Felix

Re: General Information in pom.xml

[Felix Knecht <fe...@apache.org>]

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
>>
>>   
> 
> 

Re: General Information in pom.xml

[Emmanuel Lecharny <el...@gmail.com>]

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. 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.

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).
> 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 ! 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.

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
>
>   


-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org