Yes, this could be a solution. But I was wondering if there will be syncing
problems when Maven is trying to overwrite read-only VCSed dependencies. 


Marilyn Sander -X (marilysa - Digital-X, Inc. at Cisco) wrote:
> 
> It ought to be simple.  You want to have a Maven central repository, and
> have it under version
> control, presumably because your IT department will take responsibility
> for backups of the VCS system, while it will not be responsible for just
> any old file system.
> 
> So, make the central repository referenced in your pom files be just a
> workspace of the VCS.  Every VCS system lets the user create a workspace
> or sandbox or view (it goes by different names).  Have the workspace be
> your Maven central repository, and have everything in that workspace be
> checked in to your VCS.  Adding an artifact to the central repository
> would be a matter of deploying it to the workspace first, followed by
> adding it to the VCS from the workspace. 
> 
> --Marilyn
> 
> -----Original Message-----
> From: scabbage [mailto:[email protected]] 
> Sent: Monday, June 01, 2009 3:12 PM
> To: [email protected]
> Subject: Re: Version Control Maven Dependencies
> 
> 
> 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-tp23823014p2
>>> 3823014.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-tp23823014p2382
> 3333.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-tp23823014p23823800.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]

Reply via email to