[jboss-dev] split metadata

[Alexey Loubyansky]

Replied to the wrong thread. I meant to say the AS trunk is now using 
the new split metadata.

I guess we need new Jira projects for each metadata project.

Alexey Loubyansky wrote:
> Ok, committed. The metadata versions are now at 2.0.0.Alpha.
> 
> I've changed the maven artifactId of the projects to 
> jboss-metadata-project_name to follow other projects.
> 
> I haven't split common further for now. But I am also not against it.
> 
> Jesper Pedersen wrote:
>> Hi Alexey.
>>
>> On Wednesday 17 June 2009 09:35:03 Alexey Loubyansky wrote:
>>> I have committed the split metadata now. The details are below. I'd like
>>> to get feedback from the projects that use it.
>>>
>>
>> Excellent :)
>>
>>> New metadata structure
>>> ----------------------
>>>
>>> Metadata project (version 1.0.X) has been split into several: common
>>> project + one project per specific technology. The initial version for
>>> all the new projects is 2.0.0-SNAPSHOT. The current list of the projects
>>> is: - common
>>> - EJB
>>> - WEB
>>> - RAR
>>> - EAR
>>> - client
>>>
>>> The common one contains stuff which is used by other projects, plus
>>> common Java EE metadata, common JBoss metadata and WS metadata. These
>>> could further be extracted to their own projects if needed.
>>> All technology-specific projects declare dependency on the common 
>>> project.
>>>
>>
>> Perhaps the common module can be split even more.
>>
>> I see some classes that are marked as @Deprecated - since this is a 
>> 2.0 version these could be moved to a "legacy" module.
>>
>> Also I think that the common module only should contain the classes 
>> actually needed by the sub-projects - and thereby provide a common core.
>>
>> I'm thinking about the org.jboss.metadata.javaee.spec and classes in 
>> the top-level org.jboss.metadata package - could be moved to a 
>> javaee-spec module. And there are other examples.
>>
>> The Tattletale report for the RAR module shows that
>>  org/jboss/metadata/annotation/**
>>  org/jboss/metadata/javaee/support/*
>>
>> are needed - so those are candidates to stay in the common module IMHO.
>>
>> Best regards,
>>  Jesper
>