[
http://jira.codehaus.org/browse/MNG-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wendy Smoak closed MNG-3447.
----------------------------
Assignee: Wendy Smoak
Resolution: Incomplete
Please ask questions on the users list instead. You can find subscription info
here: http://maven.apache.org/mail-lists.html
> Enterprise Repository Architecture and Release Process
> ------------------------------------------------------
>
> Key: MNG-3447
> URL: http://jira.codehaus.org/browse/MNG-3447
> Project: Maven 2
> Issue Type: Wish
> Components: Design, Patterns & Best Practices
> Reporter: sachin kamdar
> Assignee: Wendy Smoak
> Priority: Minor
>
> We implemented Maven last year in our Organization, overall we are satisfied
> with the tool however, as we migrate more and more applications to Maven we
> are facing some daunting challenges. We have roughly 500 maven projects for
> 150 odd applications (ears), using the concept of Super POMS and Dependency
> Management to create a layer of abstraction for commonly used artifacts,
> plugins and properties
>
> However, despite of this abstraction we still have fairly deep dependency
> graph. And since we have component base Application Architecture the impact
> of a change in common, low level component which is not managed from Super
> Pom is huge. A change in the low level pom means we have to change entire pom
> hierarchies. In some cases it means changing upto 400 pom files. This issue
> has now become so contentious that we have created a Project to re-structure
> and re-architect Maven.
>
> As far as our Release Cycle goes, we release in test environment from which
> we go through the bug fixing cycle, once all the bugs are fixed then the
> artifacts are pushed into pre-prod and prod. Now because the artifact is
> released into Test envt, any code change for bug fixes will force a pom
> version change. This will trigger a change in the entire project hierarchy
> from core->ejb->war->ear. As a result our release cycles have become really
> slow. We are looking at options to reduce a) the impact of change in the low
> level artifact and b) ability to release quickly.
>
> We looked at version ranges as an options but it would only partly solved the
> problem, as we still get pinned versions into manifest files. Other
> alternative was to release snapshots into Test Environment. Only pitfall with
> this option is that once the bug fixing cycle is over we'll have to release
> and build again. This, at present is against our company policy but
> personally I don't see any fuss with it
>
> I was wondering if anyone has any recommendations for,
>
> 1. What is the recommended Maven Repository Architecture for Organizations
> with Application Architecture such as ours
> 2. Is there a 'best practice' for Releasing Maven Enterprise projects. (from
> dev->test->pre->prod->prod)
> 3. Is there a Dependency Graph type of tool (not like site - dependencies
> report) which can display 'what depends on me' for each and every artifact in
> the hierarchy?
>
> We use WebSphere on Linux and most of our projects have
> ear-->wars-->ejbs-->cores type of structure. We also have whole heap of
> business services deployed as ear-->ejb-->core, which gets used by other
> application.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
