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
