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-mechanism.html#Importing_Dependencies
>>>>
>>>> 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
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
