Dear all

For the m2 studio pom.xml I'm trying to figure out, what comes into the proj
ect 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 project
s 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

[ Post a follow-up to this message ]

Felix Knecht wrote:
> Dear all
>
Hi Felix,
> For the m2 studio pom.xml I'm trying to figure out, what comes into the pr
oject 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.
> 
> pom. ATM it's hard to find a pattern if a specific tag is added to a pom o
f 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

[ Post a follow-up to this message ]

Emmanuel Lecharny schrieb:
> Felix Knecht wrote: 
> Hi Felix, 
> 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 effectiv
e 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/a.../4/apache-4.pom). You can ove
rwrite the <licenses /> tag if you want to
specify anything else as license --> Without having and licenses tag in a mo
dule 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 subproj
ects exists neither a separate mailinglist
nor (I think so) separate comit rights nor separate pmc. Thus I'd treat it a
s 1 project with subproject and therefore
all this tags would go into the projects (directory.apache.org) root pom whi
ch 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-p
lugin, but about the mavenization of the
subproject studio and about the structure and content of the poms all over t
he directory project.


Following the way apache did for the main root pom a directory project pom.x
ml 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/a.../>
/project/8/

No need to have 'project' twice in the url - it just enlarges the url and ob
fuscates 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 c
ould 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.
 
> 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 h
ierarchical structure of the directory
project itself (at least about the subproject 'directory-project' which in f
act 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 strat
egy
OTH (if refactoring the structure of the studio project) we should also thin
k about the way to go for the maven builds -
doing our own maven-plugins or hope that there will be once something offici
al that we can use - because the
pde-maven-plugin presumes a completely different structure: http://mojo.codehaus.o
rg/pd...ugin/usage.html

IIUC the eclipse-plugins are a king of OSGi bundles. So it might also be wor
th to have a look on the upcomming plugin to
bundle such things. It's in apaches felix projct: http://felix.apache.org/site/mav


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

[ Post a follow-up to this message ]