Yes. The maven metadata .xml files
They contain information about what the RELEASE version is and so on. If you don't update these files correctly, strange things will happen when maven is pulling the files down from the remote repository. Similar will happen if you try to copy a file into your local repository directly. Never put files into the local or remote repository directly, only ever use install:install-file or deploy:deploy-file as these maintain the metatdata files for you. (At least that is what I was told) On Jan 24, 2008 2:52 PM, Ken Liu <[EMAIL PROTECTED]> wrote: > Hi Stephen - > > I don't understand what you are saying. Can you explain in more detail? > > My shared repository is no different than a local workstation repository > (just a bunch of files in a directory tree). If I ftp the artifact and the > POM to the server and run install:file, won't the artifact resolve > properly? Is there something I am missing? > > Ken > > On 1/23/08, Stephen Connolly <[EMAIL PROTECTED]> wrote: > > > > you should never just FTP or copy the file. deploy:deploy-file will > > update the metadata. things will go very bad if you don't update the > > metadata > > > > Sent from my iPod > > > > On 23 Jan 2008, at 21:43, "Ken Liu" <[EMAIL PROTECTED]> wrote: > > > > > > > > Thanks, I'm going with #1. The source svn repo seems to have gone away > > (actually I probably can dig around in their svn history to find it, but > > don't have the time/motivation). > > > > Can I use deploy:deploy-file the same ways as install:install-file? I > > usually just ftp the files to the shared maven repo and then telnet in to > > run install. I briefly looked at the deploy plugin docs, but it looked > > really complicated. > > > > Ken > > > > > > On 1/22/08, Stephen Connolly < <[EMAIL PROTECTED]>[EMAIL PROTECTED]> > > wrote: > > > > > > Well if you are just repackaging the -SNAPSHOT jar, then you don't > > > need to build from source... > > > > > > I'd look at deploy:deploy-file rather than install:install-file as > > > otherwise how will the other developers on your team get the artifact (of > > > course you'd need to have your own repo to deploy to in such a case). > > > > > > Building from source (if it's a maven project) might actually be > > > easier: > > > > > > 1. pull the source from SCM > > > 2. Import the source to your SCM > > > 3. update the <scm> tag in the pom.xml > > > 4. release:prepare release:perform > > > > > > presto-chango, you're done > > > > > > On Jan 22, 2008 8:59 PM, Ken Liu < <[EMAIL PROTECTED]>[EMAIL PROTECTED]> > > > wrote: > > > > > > > Hi Stephen - > > > > > > > > Thanks for your reply. Those euro-cents are worth a a lot more than > > > > my $.02. > > > > > > > > I'm leaning toward option #1. > > > > > > > > To clarify, I wasn't planning on rebuilding the jar from the source, > > > > just taking the SNAPSHOT jar from the public repo. In fact, I don't > > > > intend > > > > to ever have to do this again because the particular plugin is no longer > > > > under development (there was never an official, non SNAPSHOT release). > > > > But > > > > point taken, if we were using a different SNAPSHOT plugin, then we might > > > > want to version a newer SNAPSHOT. I plan on using the version " > > > > 2.0-mycompany-1". > > > > > > > > Are the steps that I described sufficient for changing the version > > > > number in the jar, or is it really necessary to build from the source? > > > > I > > > > would rather not spend time/effort rebuilding something from the source > > > > when > > > > the artifact is already being used. > > > > > > > > Ken > > > > > > > > On 1/22/08, Stephen Connolly < <[EMAIL PROTECTED]>[EMAIL PROTECTED]> > > > > wrote: > > > > > > > > > > There are two ways: > > > > > > > > > > 1. Give it a new version number (e.g. 2.0-yourcompany-1) because > > > > > you may > > > > > want to re-build it if/WHEN you find issues with your build, and > > > > > if you > > > > > don't attach a build/version to the version number you'll be in > > > > > trouble. > > > > > Also you should prefix the build/version with yourcompany so > > > > > people know > > > > > it's you as what did it. > > > > > > > > > > 2. Alternatively, change the groupId to > > > > > com.yourcompany.yourproduct... now > > > > > you can have any version number you like. For that kind of change > > > > > I would > > > > > strongly recommend importing the source code into your SCM, as in > > > > > reality > > > > > this is a "fork" > > > > > > > > > > For both 1 & 2 I would ensure that you have a snapshot of the > > > > > source code in > > > > > SCM, but with option 2, you really will need that snapshot. Also > > > > > #2 is > > > > > probably better suited to when you need to patch the source > > > > > heavily in order > > > > > to get it to build, whereas #1 is for when they just have not > > > > > pushed a > > > > > release as recently as you'd like. > > > > > > > > > > Just my €0.02 > > > > > > > > > > On Jan 22, 2008 7:54 PM, Ken Liu < <[EMAIL PROTECTED]> > > > > > [EMAIL PROTECTED] > wrote: > > > > > > > > > > > Hi all - > > > > > > > > > > > > I am getting close to releasing a project and am trying to nail > > > > > down all > > > > > > the > > > > > > SNAPSHOT dependencies. I have one plugin (jboss-sar), which was > > > > > never > > > > > > released, and only has a 2.0-SNAPSHOT version available. I want > > > > > to take > > > > > > this jar and assign a release number to it to be installed in > > > > > our internal > > > > > > maven repo. > > > > > > > > > > > > Is there an "official" way to do this? I have been manually > > > > > doing the > > > > > > following: > > > > > > 1) in the jar, editing plugin.xml and replacing the version " > > > > > 2.0-SNAPSHOT " > > > > > > with "2.0-MINE" > > > > > > 2) in the jar, editing pom.properties and changing the property > > > > > " > > > > > > 2.0-SNAPSHOT" with "2.0-MINE" > > > > > > 3) in the jar, editing pom.xml and replacing the version " > > > > > 2.0-SNAPSHOT" > > > > > > with > > > > > > "2.0-MINE" > > > > > > 4) renaming the jar from " > > > > > jboss-sar-maven-plugin-2.0-SNAPSHOT.jar" to " > > > > > > jboss-sar-maven-plugin-2.0-MINE.jar" > > > > > > 5) using "mvn install:install-file" to add the jar to my > > > > > internal > > > > > > repository > > > > > > > > > > > > Is this sufficient? Did I miss any steps? Is there an easier > > > > > way to do > > > > > > this? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
