You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Brett Porter (JIRA)" <ji...@codehaus.org> on 2005/09/12 17:11:03 UTC
[jira] Updated: (MNG-139) server definitions should be reusable
[ http://jira.codehaus.org/browse/MNG-139?page=all ]
Brett Porter updated MNG-139:
-----------------------------
Fix Version: (was: 2.0-beta-1)
2.0-beta-2
Remaining Estimate: (was: 4 hours)
Original Estimate: (was: 14400)
scope is beyond what I was intending to implement - might push this back.
One thing I'd like to do is eliminate the <id/> element in the repository definition, and instead store a unique key in the metadata at the root of the repository. That can be looked up once and retained, and used as the key for defining servers in settings.xml, ensuring consistency between environments, while still being portable across changing urls or different hostnames/redirects.
> server definitions should be reusable
> -------------------------------------
>
> Key: MNG-139
> URL: http://jira.codehaus.org/browse/MNG-139
> Project: Maven 2
> Type: Task
> Components: design
> Reporter: Brett Porter
> Assignee: Brett Porter
> Priority: Critical
> Fix For: 2.0-beta-2
>
>
> currently if multiple projects use the same server for deployment, we are relying on inheritence to share the definition, or it must be copied. This applies similarly to the SCM connection and the dist/site management settings.
> It would be a good idea to be able to declare these elements in a deployed artifact.
> It may still be reasonable to do this through inheritence, but there is a chance we'll hit the need for multiple inheritence (because multiple projects inherit things from different sources), so we should enumerate the use cases and verify it.
> eg.
> A B
> / \ / \
> C D E
> Where A and B declare two different things that D uses both of, but which C and E desire only to inherit one of.
> This essentially using composition for some elements instead of inheritence.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org