This might be easier in the short run, but consider what happens when you do a release - your repo definitions are forever stuck in the released POM and so would force you to keep running your internal repo at that specific address forever (or force users to specify some mirror settings if the location changes). This could be mitigated by infrastructure, DNS mappings etc but the recommended practice is to keep all repo definitions in your settings, together with any mirror settings you may have so you are completely free to change your infrastructure without affecting released artifacts.
On Fri, Jun 6, 2008 at 7:40 AM, Rick <[EMAIL PROTECTED]> wrote: > I'm still a bit confused though... can't I define my repository in a > parent.pom ? Why isn't this the preferred approach? Would seem to make sense > to me - users check out a parent project from cvs. Run mvn install, put the > parent pom in their repo. All new projects use this parent pom definition > where the company's internal repo is definied. > > Wouldn't this be easier? > > > On Thu, Jun 5, 2008 at 11:43 PM, Wayne Fay <[EMAIL PROTECTED]> wrote: > >> The easiest would be to simply rename settings.xml to settings.x when >> you get home. This assumes that you don't have any special settings >> for your projects. But this would disable the artifactory repo. Or if >> you're on an operating system with symbolic links, you could adjust >> the link to settings.xml when you change locations. >> >> Another approach would involve creating copies of mvn.bat and >> settings.xml and calling mvn-copy when you're home. You would also set >> mvn-copy.bat up to append -s /path/to/settings-copy.xml to all calls >> to mvn. >> >> Wayne >> >> On Thu, Jun 5, 2008 at 10:06 PM, Rick <[EMAIL PROTECTED]> wrote: >> > I'm totally confused and could use some help... >> > >> > I have an internal company repo setup fine. Currently, following the >> > artifcatory docs, I defined this repo in my mavenhome/conf/settings.xml >> file >> > such as: >> > >> > <profile> >> > <id>acme-company</id> >> > <repositories> >> > <repository> >> > <id>central</id> >> > <url>http://urlip:8081/artifactory/repo</url> >> > <snapshots> >> > <enabled>false</enabled> >> > </snapshots> >> > </repository> >> > .... >> > >> > I can then set this profile to be active in the settings.xml file as well >> > and all works fine. >> > >> > The problem is when I'm at home using this laptop I don't want to use >> this >> > profile! I just want plain jane vanilla iblio repo. >> > >> > I'm confused how to set up things to get what I want - projects using our >> > company parent pom using the repositories as defined above, and any other >> > projects to not use the profile as above. >> > >> > What I was 'thinking' I could so is just set up the repository definition >> in >> > my parent proejct pom.. but that didn't seem to work at all. To me this >> > makes the most sense as users wouldn't even have to define anything in >> their >> > settings.xml file. I see no examples of this however and can't seem to >> get >> > ti to work. Assuming I keep this profile definition in my (and >> unfortunately >> > the whole team's local settings.xml file) how do I set up parent company >> > profile to use it? If I keep it "alawys active" then it's always active >> even >> > when I'm not at work which seems to be a pain. >> > >> > Even if this kind of info shouldn't be in a parent pom, and should be in >> the >> > settings.xml file, how do I then easily set things up so that I can do >> "mvn >> > install" when I'm not at work and have it NOT try to connect to the >> > acme-company profile? I'd prefer not to have a pass in a profile argument >> on >> > the command line, but I suppose if I have to, I'll do it. >> > >> > I'm thinking this is a common situation so I must be totally doing >> something >> > wrong, >> > >> > -- >> > Rick >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > Rick > -- - Jan Fredrik Wedén --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
