[xwiki-devs] [VOTE] Move all rendering related components under the same maven parent and separate a little more
Hi xwikiers, I need to commit the 1.0->2.0 converter which contains some classes used only for this purpose. So I would prefer to to add it directly in xwiki-core-rendering module, plus I don't like to have anything about xwiki 1.0 in the core-rendering module. But if we have XWiki 1.0 parser in it's own module, it would be cleaner to have all parsers extracted from the core-rendering module. So I propose to reorg a bit rendering to have: - xwiki-core-rendering - xwiki-core-rendering-api - xwiki-core-rendering-macros - xwiki-core-rendering-macro-toc - ... - xwiki-core-rendering-parsers - xwiki-core-rendering-parser-xwiki10 - xwiki-core-rendering-parser-wikimodel - xwiki-core-rendering-parser-doxia Also having everything under the same maven parent is better in the context of making xwiki rendering framework an independent open source project latter. And better sooner than latter. Here is my +1. -- Thomas Mortagne
+1 Thomas Mortagne wrote:
Hi xwikiers,
I need to commit the 1.0->2.0 converter which contains some classes used only for this purpose. So I would prefer to to add it directly in xwiki-core-rendering module, plus I don't like to have anything about xwiki 1.0 in the core-rendering module. But if we have XWiki 1.0 parser in it's own module, it would be cleaner to have all parsers extracted from the core-rendering module.
So I propose to reorg a bit rendering to have:
- xwiki-core-rendering - xwiki-core-rendering-api - xwiki-core-rendering-macros - xwiki-core-rendering-macro-toc - ... - xwiki-core-rendering-parsers - xwiki-core-rendering-parser-xwiki10 - xwiki-core-rendering-parser-wikimodel - xwiki-core-rendering-parser-doxia
Also having everything under the same maven parent is better in the context of making xwiki rendering framework an independent open source project latter. And better sooner than latter.
Here is my +1.
+1 On Jan 7, 2009, at 5:19 PM, Thomas Mortagne wrote:
Hi xwikiers,
I need to commit the 1.0->2.0 converter which contains some classes used only for this purpose. So I would prefer to to add it directly in xwiki-core-rendering module, plus I don't like to have anything about xwiki 1.0 in the core-rendering module. But if we have XWiki 1.0 parser in it's own module, it would be cleaner to have all parsers extracted from the core-rendering module.
So I propose to reorg a bit rendering to have:
- xwiki-core-rendering - xwiki-core-rendering-api - xwiki-core-rendering-macros - xwiki-core-rendering-macro-toc - ... - xwiki-core-rendering-parsers - xwiki-core-rendering-parser-xwiki10 - xwiki-core-rendering-parser-wikimodel - xwiki-core-rendering-parser-doxia
Also having everything under the same maven parent is better in the context of making xwiki rendering framework an independent open source project latter. And better sooner than latter.
Here is my +1.
-- Thomas Mortagne
Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net
+1 JV. On Wed, Jan 7, 2009 at 5:19 PM, Thomas Mortagne <[email protected]> wrote:
Hi xwikiers,
I need to commit the 1.0->2.0 converter which contains some classes used only for this purpose. So I would prefer to to add it directly in xwiki-core-rendering module, plus I don't like to have anything about xwiki 1.0 in the core-rendering module. But if we have XWiki 1.0 parser in it's own module, it would be cleaner to have all parsers extracted from the core-rendering module.
So I propose to reorg a bit rendering to have:
- xwiki-core-rendering - xwiki-core-rendering-api - xwiki-core-rendering-macros - xwiki-core-rendering-macro-toc - ... - xwiki-core-rendering-parsers - xwiki-core-rendering-parser-xwiki10 - xwiki-core-rendering-parser-wikimodel - xwiki-core-rendering-parser-doxia
Also having everything under the same maven parent is better in the context of making xwiki rendering framework an independent open source project latter. And better sooner than latter.
Here is my +1.
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 Thomas Mortagne wrote:
Hi xwikiers,
I need to commit the 1.0->2.0 converter which contains some classes used only for this purpose. So I would prefer to to add it directly in xwiki-core-rendering module, plus I don't like to have anything about xwiki 1.0 in the core-rendering module. But if we have XWiki 1.0 parser in it's own module, it would be cleaner to have all parsers extracted from the core-rendering module.
So I propose to reorg a bit rendering to have:
- xwiki-core-rendering - xwiki-core-rendering-api - xwiki-core-rendering-macros - xwiki-core-rendering-macro-toc - ... - xwiki-core-rendering-parsers - xwiki-core-rendering-parser-xwiki10 - xwiki-core-rendering-parser-wikimodel - xwiki-core-rendering-parser-doxia
Also having everything under the same maven parent is better in the context of making xwiki rendering framework an independent open source project latter. And better sooner than latter.
Here is my +1.
Also WDYT of creating a xwiki-core-rendering-all maven project which would be used as entry point to depends on all rendering components. This way we could remove all the things which are listed in old xwik-core project and just depends on xwiki-core-rendering-all ? On Wed, Jan 7, 2009 at 5:19 PM, Thomas Mortagne <[email protected]> wrote:
Hi xwikiers,
I need to commit the 1.0->2.0 converter which contains some classes used only for this purpose. So I would prefer to to add it directly in xwiki-core-rendering module, plus I don't like to have anything about xwiki 1.0 in the core-rendering module. But if we have XWiki 1.0 parser in it's own module, it would be cleaner to have all parsers extracted from the core-rendering module.
So I propose to reorg a bit rendering to have:
- xwiki-core-rendering - xwiki-core-rendering-api - xwiki-core-rendering-macros - xwiki-core-rendering-macro-toc - ... - xwiki-core-rendering-parsers - xwiki-core-rendering-parser-xwiki10 - xwiki-core-rendering-parser-wikimodel - xwiki-core-rendering-parser-doxia
Also having everything under the same maven parent is better in the context of making xwiki rendering framework an independent open source project latter. And better sooner than latter.
Here is my +1.
-- Thomas Mortagne
-- Thomas Mortagne
On Thu, Jan 8, 2009 at 11:27 AM, Thomas Mortagne <[email protected]> wrote:
Also WDYT of creating a xwiki-core-rendering-all maven project which would be used as entry point to depends on all rendering components. This way we could remove all the things which are listed in old xwik-core project and just depends on xwiki-core-rendering-all ?
Even i'm not sure what is the clean way to do it with maven.
On Wed, Jan 7, 2009 at 5:19 PM, Thomas Mortagne <[email protected]> wrote:
Hi xwikiers,
I need to commit the 1.0->2.0 converter which contains some classes used only for this purpose. So I would prefer to to add it directly in xwiki-core-rendering module, plus I don't like to have anything about xwiki 1.0 in the core-rendering module. But if we have XWiki 1.0 parser in it's own module, it would be cleaner to have all parsers extracted from the core-rendering module.
So I propose to reorg a bit rendering to have:
- xwiki-core-rendering - xwiki-core-rendering-api - xwiki-core-rendering-macros - xwiki-core-rendering-macro-toc - ... - xwiki-core-rendering-parsers - xwiki-core-rendering-parser-xwiki10 - xwiki-core-rendering-parser-wikimodel - xwiki-core-rendering-parser-doxia
Also having everything under the same maven parent is better in the context of making xwiki rendering framework an independent open source project latter. And better sooner than latter.
Here is my +1.
-- Thomas Mortagne
-- Thomas Mortagne
-- Thomas Mortagne
On Jan 8, 2009, at 12:39 PM, Thomas Mortagne wrote:
On Thu, Jan 8, 2009 at 11:27 AM, Thomas Mortagne <[email protected]> wrote:
Also WDYT of creating a xwiki-core-rendering-all maven project which would be used as entry point to depends on all rendering components. This way we could remove all the things which are listed in old xwik-core project and just depends on xwiki-core-rendering-all ?
Even i'm not sure what is the clean way to do it with maven.
That's basically the same question Asiri asked yesterday but at the level of platform/core. IMO there must be a good reason to have separate modules. If not we must have a single module. If we do it means the modules are not all compulsory and can be used independently. This means that it's the pom that uses them that need to declare a dep on them for its needs. One thing that might help is to follow the BOM pattern defined here (<scope>import</scope>): http://maven.apache.org/guides/introduction/introduction-to-dependency-mecha... I just discovered this notion of import scope and haven't used it before. However it seems we'll still need to declare the deps, it's only the versions that can be shared. If we go the rendering-all solution then I'd like that this module be a ubjerjar module, i.e. it generates a single jar for all the modules it aggregates (using the assembly plugin) and so that dependent projects have only 1 dependency which is that uberjar. WDYT?
On Wed, Jan 7, 2009 at 5:19 PM, Thomas Mortagne <[email protected]> wrote:
Hi xwikiers,
I need to commit the 1.0->2.0 converter which contains some classes used only for this purpose. So I would prefer to to add it directly in xwiki-core-rendering module, plus I don't like to have anything about xwiki 1.0 in the core-rendering module. But if we have XWiki 1.0 parser in it's own module, it would be cleaner to have all parsers extracted from the core-rendering module.
So I propose to reorg a bit rendering to have:
- xwiki-core-rendering - xwiki-core-rendering-api - xwiki-core-rendering-macros - xwiki-core-rendering-macro-toc - ... - xwiki-core-rendering-parsers - xwiki-core-rendering-parser-xwiki10 - xwiki-core-rendering-parser-wikimodel - xwiki-core-rendering-parser-doxia
Also having everything under the same maven parent is better in the context of making xwiki rendering framework an independent open source project latter. And better sooner than latter.
Here is my +1.
Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net
On Thu, Jan 8, 2009 at 1:16 PM, Vincent Massol <[email protected]> wrote:
On Jan 8, 2009, at 12:39 PM, Thomas Mortagne wrote:
On Thu, Jan 8, 2009 at 11:27 AM, Thomas Mortagne <[email protected]> wrote:
Also WDYT of creating a xwiki-core-rendering-all maven project which would be used as entry point to depends on all rendering components. This way we could remove all the things which are listed in old xwik-core project and just depends on xwiki-core-rendering-all ?
Even i'm not sure what is the clean way to do it with maven.
That's basically the same question Asiri asked yesterday but at the level of platform/core.
IMO there must be a good reason to have separate modules. If not we must have a single module. If we do it means the modules are not all compulsory and can be used independently. This means that it's the pom that uses them that need to declare a dep on them for its needs.
One thing that might help is to follow the BOM pattern defined here (<scope>import</scope>): http://maven.apache.org/guides/introduction/introduction-to-dependency-mecha...
I just discovered this notion of import scope and haven't used it before. However it seems we'll still need to declare the deps, it's only the versions that can be shared.
If we go the rendering-all solution then I'd like that this module be a ubjerjar module, i.e. it generates a single jar for all the modules it aggregates (using the assembly plugin) and so that dependent projects have only 1 dependency which is that uberjar.
WDYT?
Yes but for this we need to merge all the component.xml files correctly but I guess it's doable.
On Wed, Jan 7, 2009 at 5:19 PM, Thomas Mortagne <[email protected]> wrote:
Hi xwikiers,
I need to commit the 1.0->2.0 converter which contains some classes used only for this purpose. So I would prefer to to add it directly in xwiki-core-rendering module, plus I don't like to have anything about xwiki 1.0 in the core-rendering module. But if we have XWiki 1.0 parser in it's own module, it would be cleaner to have all parsers extracted from the core-rendering module.
So I propose to reorg a bit rendering to have:
- xwiki-core-rendering - xwiki-core-rendering-api - xwiki-core-rendering-macros - xwiki-core-rendering-macro-toc - ... - xwiki-core-rendering-parsers - xwiki-core-rendering-parser-xwiki10 - xwiki-core-rendering-parser-wikimodel - xwiki-core-rendering-parser-doxia
Also having everything under the same maven parent is better in the context of making xwiki rendering framework an independent open source project latter. And better sooner than latter.
Here is my +1.
Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Jan 8, 2009, at 3:22 PM, Thomas Mortagne wrote:
On Thu, Jan 8, 2009 at 1:16 PM, Vincent Massol <[email protected]> wrote:
On Jan 8, 2009, at 12:39 PM, Thomas Mortagne wrote:
On Thu, Jan 8, 2009 at 11:27 AM, Thomas Mortagne <[email protected]> wrote:
Also WDYT of creating a xwiki-core-rendering-all maven project which would be used as entry point to depends on all rendering components. This way we could remove all the things which are listed in old xwik-core project and just depends on xwiki-core-rendering-all ?
Even i'm not sure what is the clean way to do it with maven.
That's basically the same question Asiri asked yesterday but at the level of platform/core.
IMO there must be a good reason to have separate modules. If not we must have a single module. If we do it means the modules are not all compulsory and can be used independently. This means that it's the pom that uses them that need to declare a dep on them for its needs.
One thing that might help is to follow the BOM pattern defined here (<scope>import</scope>): http://maven.apache.org/guides/introduction/introduction-to-dependency-mecha...
I just discovered this notion of import scope and haven't used it before. However it seems we'll still need to declare the deps, it's only the versions that can be shared.
If we go the rendering-all solution then I'd like that this module be a ubjerjar module, i.e. it generates a single jar for all the modules it aggregates (using the assembly plugin) and so that dependent projects have only 1 dependency which is that uberjar.
WDYT?
Yes but for this we need to merge all the component.xml files correctly but I guess it's doable.
Just asked and the assembly plugin and the shade plugin support merging of components.xml. -Vincent
On Wed, Jan 7, 2009 at 5:19 PM, Thomas Mortagne <[email protected]> wrote:
Hi xwikiers,
I need to commit the 1.0->2.0 converter which contains some classes used only for this purpose. So I would prefer to to add it directly in xwiki-core-rendering module, plus I don't like to have anything about xwiki 1.0 in the core-rendering module. But if we have XWiki 1.0 parser in it's own module, it would be cleaner to have all parsers extracted from the core-rendering module.
So I propose to reorg a bit rendering to have:
- xwiki-core-rendering - xwiki-core-rendering-api - xwiki-core-rendering-macros - xwiki-core-rendering-macro-toc - ... - xwiki-core-rendering-parsers - xwiki-core-rendering-parser-xwiki10 - xwiki-core-rendering-parser-wikimodel - xwiki-core-rendering-parser-doxia
Also having everything under the same maven parent is better in the context of making xwiki rendering framework an independent open source project latter. And better sooner than latter.
Here is my +1.
On Jan 8, 2009, at 3:37 PM, Vincent Massol wrote:
On Jan 8, 2009, at 3:22 PM, Thomas Mortagne wrote:
On Thu, Jan 8, 2009 at 1:16 PM, Vincent Massol <[email protected]> wrote:
On Jan 8, 2009, at 12:39 PM, Thomas Mortagne wrote:
On Thu, Jan 8, 2009 at 11:27 AM, Thomas Mortagne <[email protected]> wrote:
Also WDYT of creating a xwiki-core-rendering-all maven project which would be used as entry point to depends on all rendering components. This way we could remove all the things which are listed in old xwik-core project and just depends on xwiki-core-rendering-all ?
Even i'm not sure what is the clean way to do it with maven.
That's basically the same question Asiri asked yesterday but at the level of platform/core.
IMO there must be a good reason to have separate modules. If not we must have a single module. If we do it means the modules are not all compulsory and can be used independently. This means that it's the pom that uses them that need to declare a dep on them for its needs.
One thing that might help is to follow the BOM pattern defined here (<scope>import</scope>): http://maven.apache.org/guides/introduction/introduction-to-dependency-mecha...
I just discovered this notion of import scope and haven't used it before. However it seems we'll still need to declare the deps, it's only the versions that can be shared.
If we go the rendering-all solution then I'd like that this module be a ubjerjar module, i.e. it generates a single jar for all the modules it aggregates (using the assembly plugin) and so that dependent projects have only 1 dependency which is that uberjar.
WDYT?
Yes but for this we need to merge all the component.xml files correctly but I guess it's doable.
Just asked and the assembly plugin and the shade plugin support merging of components.xml.
See http://svn.sonatype.org/nexus/trunk/nexus-indexer/pom.xml and search for "shade". -Vincent
On Wed, Jan 7, 2009 at 5:19 PM, Thomas Mortagne <[email protected]> wrote:
Hi xwikiers,
I need to commit the 1.0->2.0 converter which contains some classes used only for this purpose. So I would prefer to to add it directly in xwiki-core-rendering module, plus I don't like to have anything about xwiki 1.0 in the core-rendering module. But if we have XWiki 1.0 parser in it's own module, it would be cleaner to have all parsers extracted from the core-rendering module.
So I propose to reorg a bit rendering to have:
- xwiki-core-rendering - xwiki-core-rendering-api - xwiki-core-rendering-macros - xwiki-core-rendering-macro-toc - ... - xwiki-core-rendering-parsers - xwiki-core-rendering-parser-xwiki10 - xwiki-core-rendering-parser-wikimodel - xwiki-core-rendering-parser-doxia
Also having everything under the same maven parent is better in the context of making xwiki rendering framework an independent open source project latter. And better sooner than latter.
Here is my +1.
Another issue: extract parsers means we have to find a place where to put all the multiparsers unit tests on syntaxes, etc. I propose 1) * xwiki-core-rendering * xwiki-core-rendering-parsers * xwiki-core-rendering-parsers-tests or 2) * xwiki-core-rendering * xwiki-core-rendering-tests if we consider we will also extract renderers from rendering-api in the future +1 for 2) WDYT ? On Thu, Jan 8, 2009 at 3:38 PM, Vincent Massol <[email protected]> wrote:
On Jan 8, 2009, at 3:37 PM, Vincent Massol wrote:
On Jan 8, 2009, at 3:22 PM, Thomas Mortagne wrote:
On Thu, Jan 8, 2009 at 1:16 PM, Vincent Massol <[email protected]> wrote:
On Jan 8, 2009, at 12:39 PM, Thomas Mortagne wrote:
On Thu, Jan 8, 2009 at 11:27 AM, Thomas Mortagne <[email protected]> wrote:
Also WDYT of creating a xwiki-core-rendering-all maven project which would be used as entry point to depends on all rendering components. This way we could remove all the things which are listed in old xwik-core project and just depends on xwiki-core-rendering-all ?
Even i'm not sure what is the clean way to do it with maven.
That's basically the same question Asiri asked yesterday but at the level of platform/core.
IMO there must be a good reason to have separate modules. If not we must have a single module. If we do it means the modules are not all compulsory and can be used independently. This means that it's the pom that uses them that need to declare a dep on them for its needs.
One thing that might help is to follow the BOM pattern defined here (<scope>import</scope>): http://maven.apache.org/guides/introduction/introduction-to-dependency-mecha...
I just discovered this notion of import scope and haven't used it before. However it seems we'll still need to declare the deps, it's only the versions that can be shared.
If we go the rendering-all solution then I'd like that this module be a ubjerjar module, i.e. it generates a single jar for all the modules it aggregates (using the assembly plugin) and so that dependent projects have only 1 dependency which is that uberjar.
WDYT?
Yes but for this we need to merge all the component.xml files correctly but I guess it's doable.
Just asked and the assembly plugin and the shade plugin support merging of components.xml.
See http://svn.sonatype.org/nexus/trunk/nexus-indexer/pom.xml and search for "shade".
-Vincent
On Wed, Jan 7, 2009 at 5:19 PM, Thomas Mortagne <[email protected]> wrote: > Hi xwikiers, > > I need to commit the 1.0->2.0 converter which contains some > classes > used only for this purpose. So I would prefer to to add it > directly in > xwiki-core-rendering module, plus I don't like to have anything > about > xwiki 1.0 in the core-rendering module. > But if we have XWiki 1.0 parser in it's own module, it would be > cleaner to have all parsers extracted from the core-rendering > module. > > So I propose to reorg a bit rendering to have: > > - xwiki-core-rendering > - xwiki-core-rendering-api > - xwiki-core-rendering-macros > - xwiki-core-rendering-macro-toc > - ... > - xwiki-core-rendering-parsers > - xwiki-core-rendering-parser-xwiki10 > - xwiki-core-rendering-parser-wikimodel > - xwiki-core-rendering-parser-doxia > > Also having everything under the same maven parent is better in > the > context of making xwiki rendering framework an independent open > source > project latter. And better sooner than latter. > > Here is my +1.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Jan 8, 2009, at 4:45 PM, Thomas Mortagne wrote:
Another issue: extract parsers means we have to find a place where to put all the multiparsers unit tests on syntaxes, etc.
I propose
1) * xwiki-core-rendering * xwiki-core-rendering-parsers * xwiki-core-rendering-parsers-tests
or
2) * xwiki-core-rendering * xwiki-core-rendering-tests
if we consider we will also extract renderers from rendering-api in the future
+1 for 2)
+1 for 2) Thanks -Vincent
WDYT ?
On Thu, Jan 8, 2009 at 3:38 PM, Vincent Massol <[email protected]> wrote:
On Jan 8, 2009, at 3:37 PM, Vincent Massol wrote:
On Jan 8, 2009, at 3:22 PM, Thomas Mortagne wrote:
On Thu, Jan 8, 2009 at 1:16 PM, Vincent Massol <[email protected]> wrote:
On Jan 8, 2009, at 12:39 PM, Thomas Mortagne wrote:
On Thu, Jan 8, 2009 at 11:27 AM, Thomas Mortagne <[email protected]> wrote: > Also WDYT of creating a xwiki-core-rendering-all maven project > which > would be used as entry point to depends on all rendering > components. > This way we could remove all the things which are listed in old > xwik-core project and just depends on xwiki-core-rendering-all ?
Even i'm not sure what is the clean way to do it with maven.
That's basically the same question Asiri asked yesterday but at the level of platform/core.
IMO there must be a good reason to have separate modules. If not we must have a single module. If we do it means the modules are not all compulsory and can be used independently. This means that it's the pom that uses them that need to declare a dep on them for its needs.
One thing that might help is to follow the BOM pattern defined here (<scope>import</scope>): http://maven.apache.org/guides/introduction/introduction-to-dependency-mecha...
I just discovered this notion of import scope and haven't used it before. However it seems we'll still need to declare the deps, it's only the versions that can be shared.
If we go the rendering-all solution then I'd like that this module be a ubjerjar module, i.e. it generates a single jar for all the modules it aggregates (using the assembly plugin) and so that dependent projects have only 1 dependency which is that uberjar.
WDYT?
Yes but for this we need to merge all the component.xml files correctly but I guess it's doable.
Just asked and the assembly plugin and the shade plugin support merging of components.xml.
See http://svn.sonatype.org/nexus/trunk/nexus-indexer/pom.xml and search for "shade".
-Vincent
> On Wed, Jan 7, 2009 at 5:19 PM, Thomas Mortagne > <[email protected]> wrote: >> Hi xwikiers, >> >> I need to commit the 1.0->2.0 converter which contains some >> classes >> used only for this purpose. So I would prefer to to add it >> directly in >> xwiki-core-rendering module, plus I don't like to have anything >> about >> xwiki 1.0 in the core-rendering module. >> But if we have XWiki 1.0 parser in it's own module, it would be >> cleaner to have all parsers extracted from the core-rendering >> module. >> >> So I propose to reorg a bit rendering to have: >> >> - xwiki-core-rendering >> - xwiki-core-rendering-api >> - xwiki-core-rendering-macros >> - xwiki-core-rendering-macro-toc >> - ... >> - xwiki-core-rendering-parsers >> - xwiki-core-rendering-parser-xwiki10 >> - xwiki-core-rendering-parser-wikimodel >> - xwiki-core-rendering-parser-doxia >> >> Also having everything under the same maven parent is better in >> the >> context of making xwiki rendering framework an independent open >> source >> project latter. And better sooner than latter. >> >> Here is my +1.
On Thu, Jan 8, 2009 at 3:37 PM, Vincent Massol <[email protected]> wrote:
On Jan 8, 2009, at 3:22 PM, Thomas Mortagne wrote:
On Thu, Jan 8, 2009 at 1:16 PM, Vincent Massol <[email protected]> wrote:
On Jan 8, 2009, at 12:39 PM, Thomas Mortagne wrote:
On Thu, Jan 8, 2009 at 11:27 AM, Thomas Mortagne <[email protected]> wrote:
Also WDYT of creating a xwiki-core-rendering-all maven project which would be used as entry point to depends on all rendering components. This way we could remove all the things which are listed in old xwik-core project and just depends on xwiki-core-rendering-all ?
Even i'm not sure what is the clean way to do it with maven.
That's basically the same question Asiri asked yesterday but at the level of platform/core.
IMO there must be a good reason to have separate modules. If not we must have a single module. If we do it means the modules are not all compulsory and can be used independently. This means that it's the pom that uses them that need to declare a dep on them for its needs.
One thing that might help is to follow the BOM pattern defined here (<scope>import</scope>): http://maven.apache.org/guides/introduction/introduction-to-dependency-mecha...
I just discovered this notion of import scope and haven't used it before. However it seems we'll still need to declare the deps, it's only the versions that can be shared.
If we go the rendering-all solution then I'd like that this module be a ubjerjar module, i.e. it generates a single jar for all the modules it aggregates (using the assembly plugin) and so that dependent projects have only 1 dependency which is that uberjar.
WDYT?
Yes but for this we need to merge all the component.xml files correctly but I guess it's doable.
Just asked and the assembly plugin and the shade plugin support merging of components.xml.
Ok great
-Vincent
On Wed, Jan 7, 2009 at 5:19 PM, Thomas Mortagne <[email protected]> wrote:
Hi xwikiers,
I need to commit the 1.0->2.0 converter which contains some classes used only for this purpose. So I would prefer to to add it directly in xwiki-core-rendering module, plus I don't like to have anything about xwiki 1.0 in the core-rendering module. But if we have XWiki 1.0 parser in it's own module, it would be cleaner to have all parsers extracted from the core-rendering module.
So I propose to reorg a bit rendering to have:
- xwiki-core-rendering - xwiki-core-rendering-api - xwiki-core-rendering-macros - xwiki-core-rendering-macro-toc - ... - xwiki-core-rendering-parsers - xwiki-core-rendering-parser-xwiki10 - xwiki-core-rendering-parser-wikimodel - xwiki-core-rendering-parser-doxia
Also having everything under the same maven parent is better in the context of making xwiki rendering framework an independent open source project latter. And better sooner than latter.
Here is my +1.
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (5)
-
Jean-Vincent Drean -
Jerome Velociter -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol