The reason why I mentioned VCS is because it is the only company supported IT service we have. To ensure absolute uptime for your build system, this is the only way to go. Of course we could setup ftp/http to store dependencies. But that gives rise to the same problem for maintenance.
nhajratw wrote: > > If your org is set on not using a repo manager, then I'm not sure that > a VCS is the way to go anyway. > > Since maven doesn't overwrite it's artifacts with a new revision, but > rather keeps distinct copies of each deployed artifact (excepting > SNAPSHOTS) -- I think a simple filesystem layout corresponds better to > a maven repo. If you do that, you can simply configure the deploy > plugin to deploy to an FTP site, and then slap an HTTP server on it > for retrieving the artifacts. The problem with this is that you'll > have to manually deploy all artifacts you want to use from public repos. > > If you want more automation, it's probably going to be a lot of extra > work. I'm not really sure how/why you would involve a VCS into it > though. > > Hopefully someone within your organization *has* signed up to maintain > the custom repository system (scripts, maven plugins, code, etc) that > you end up with. ;-) > > > On Jun 1, 2009, at 6:11 PM, scabbage wrote: > >> >> We have done that already. The internal repo is up and running like >> a charm. >> The reason why I asked for VCS support is that nobody wants to >> maintain this >> repo (although it probably does not require any maintenance). The IT >> service >> of my org does not either. We need a backup plan. >> >> >> >> nhajratw wrote: >>> >>> I'd strongly suggest revisiting the internal proxy. In the time it >>> takes you to come up with a solution to store your artifacts in a >>> VCS, >>> you could have set up Nexus and left early for the day :-) >>> >>> It's really simple, and once up, requires very little maintenance >>> effort. >>> >>> http://nexus.sonatype.org/ >>> >>> >>> >>> On Jun 1, 2009, at 5:52 PM, scabbage wrote: >>> >>>> >>>> I need some suggestions for Enterprise build process using Maven. >>>> >>>> We are currently developing a Java project using Maven. We version >>>> controll >>>> our project source. Our Continuous integration system syncs the >>>> source and >>>> uses maven assembly to build a jar with dependencies. This work flow >>>> works >>>> fine. >>>> >>>> Now my manager is uncomfortable with the fact that we don't VC the >>>> dependency jars. He is afraid that the entire build workflow will be >>>> disrupted if the public repo is down. Of course we could setup an >>>> internal >>>> repo as an dependency proxy. But my manager is reluctant to do so >>>> because we >>>> have limited engineer resources for the repo admin. >>>> >>>> The best solution is to use the company-backed VCS for the >>>> dependencies. But >>>> I haven't found a good way to incorporate both our VCS and Maven. >>>> Can anyone >>>> give me some suggestions on this? >>>> >>>> Thanks. >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/Version-Control-Maven-Dependencies-tp23823014p23823014.html >>>> Sent from the Maven - Users mailing list archive at Nabble.com. >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Version-Control-Maven-Dependencies-tp23823014p23823333.html >> Sent from the Maven - Users mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > -- View this message in context: http://www.nabble.com/Version-Control-Maven-Dependencies-tp23823014p23823614.html Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
