Michal Maczka wrote:
Brill Pappin wrote:
Using a localized remote repo is *not* an option for us here. I'm fighting other parts of the team to use maven as it is, and having a dependency on a remote machine that is a point-of-failure is not an option.
Other problems include security when a project must be built off-site by a developer working from home, or a contractor... no access; the repository must not be exposed (we did for a while, and promptly got hacked).
You mean the situation when devloper is not able to connect to your servers from home?
How can he/she use things like CVS then? And then how sources of the project will appear on his disk?
You can use the same channel for transfering required artifacts into your local repository.
Yes, that is a good example, and we have more levels of security here than simply ssh, including rotating tokens which Maven *can't* know about.
Also "automatic" is a dirty word around here and no "automatic" cvs access is permitted in any build or deployment script.
The only option that will be satisfactory to the dinosaurs here is that any library not in the public repository goes with the project.... and no, I don't like it but thats what I have to work with :)
This already is supported. If you really have to you can just put your jars to CVS and make a checkout from there.
Then you have to define remote repository which is
using file:// protocol. You can even checkout such liblaries directly into your local repository. In other case maven
willl just copy them to local repository.
That might be a possible solution, although the goal was to be able to bundle up a snapshot, send it out to a contractor and get it back all without anyone having to change the build script or have access to our private codebase.
- Brill Pappin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
