[jboss-dev] split metadata

Carlo de Wolf cdewolf at redhat.com
Fri Aug 28 14:30:36 EDT 2009


We can't have Jira projects for each and every component that has its 
own release cycle. That would make Jira flooded with projects.
Meanwhile vote: http://jira.atlassian.com/browse/JRA-2744 
http://jira.atlassian.com/browse/JRA-3228 and 
http://jira.atlassian.com/browse/JRA-3501 :-)

Carlo

Alexey Loubyansky wrote:
> 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
>>>       
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>   




More information about the jboss-development mailing list