[jboss-dev] split metadata

Max Rydahl Andersen max.andersen at redhat.com
Fri Aug 28 16:21:02 EDT 2009


or upgrade to Jira 4 and get Project Category search - making it 
possible to actually manage multi-versions project as "one"

http://jira.atlassian.com/browse/JRA-3464

/max

Carlo de Wolf wrote:
> 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
>>
>>      
>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-development/attachments/20090828/48b77ba5/attachment.html 


More information about the jboss-development mailing list