You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by "Farr, Aaron" <Aa...@am.sony.com> on 2004/06/17 20:35:21 UTC
[magic] proxies and remote repositories
Hello.
I'm just in the process of committing a few changes to the reactor.xml and
build.xml which:
1. allow for a 'user.properties' to be set rather than having users edit
the default build.properties
2. allow for the following properties for setting an HTTP proxy:
project.proxy.host
project.proxy.port
project.proxy.user
project.proxy.password
3. runs a <setproxy> task in the reactor.xml init target which wasn't
being called by the build.xml init target. So I commented out the
reactor init methods and added the setproxy. Someone else may have
a better idea.
Finally, do we have a way to change the remote repositories? In some cases,
individuals will want to point to a local mirror of ibiblio or dpml.
And did we think about using some of depot's tools for repository and
resource management?
J. Aaron Farr
SONY ELECTRONICS
STP SYSTEMS
(724) 696-7653
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [magic] proxies and remote repositories
Posted by Stephen McConnell <mc...@apache.org>.
Farr, Aaron wrote:
> Hello.
>
> I'm just in the process of committing a few changes to the reactor.xml and
> build.xml which:
>
> 1. allow for a 'user.properties' to be set rather than having users edit
> the default build.properties
Handling of user.properties is already in place.
See ContextualTask.
>
> 2. allow for the following properties for setting an HTTP proxy:
> project.proxy.host
> project.proxy.port
> project.proxy.user
> project.proxy.password
>
> 3. runs a <setproxy> task in the reactor.xml init target which wasn't
> being called by the build.xml init target. So I commented out the
> reactor init methods and added the setproxy. Someone else may have
> a better idea.
Yes - the above is needed.
> Finally, do we have a way to change the remote repositories? In some cases,
> individuals will want to point to a local mirror of ibiblio or dpml.
Sure - take a look at the Home class and how it is pulling in
information about available repositories.
> And did we think about using some of depot's tools for repository and
> resource management?
It should be possible to map these in as supplimentary plugins - but
more thinking needed.
Steve.
--
|---------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [magic] proxies and remote repositories
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 18 June 2004 02:35, Farr, Aaron wrote:
> 1. allow for a 'user.properties' to be set rather than having users edit
> the default build.properties
Good idea. IMHO, it should be at 'project', 'magic' and 'system' level, e.g.
runtime/activation/api, central/system and ${user.home} and must have higher
precedence than the common ones.
> 2. allow for the following properties for setting an HTTP proxy:
> 3. runs a <setproxy> task in the reactor.xml init target which wasn't
No comment. I guess a lot of people need it...
> Finally, do we have a way to change the remote repositories? In some
> cases, individuals will want to point to a local mirror of ibiblio or dpml.
For now, it should be an overridable property. Later we should support some
clever algorithm for multiple prioritized sites.
> And did we think about using some of depot's tools for repository and
> resource management?
Are you subscribed to the Depot list?? If so, you should have noticed the
complete lack of activity recently, which yesterday was raised as a major
concern.
To me it seems that we have more experience with repository handling (it ain't
that hard!) than Depot. IIRC, one concern that was raised earlier, in
conjunction of seeing if we could put Depot into Merlin instead of Avalon
Repository, was the lack of classloader management, which is also a concern
in the build system (believe it or not).
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org