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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
  
    

_______________________________________________
jboss-development mailing list
jboss-development@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development