directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: General Information in pom.xml
Date Sun, 30 Dec 2007 10:20:31 GMT
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



Mime
View raw message