Reputation: 1
First off, let me give you a background on my git repo and my setup...
For example... https://github.com/gitRepo/sqeTemp
.
Within that repo, I have 5 mavenized projects that are not related to each other.
gitRepo/sqeTemp
> Project 1
> Project 2
> Project 3
> Project 4
> Project 5
within the pom.xml
of Projects 1 (which is the project I'm trying to release, I have the following:
<scm>
<connection>scm:git:[email protected]:gitRepo/sqeTemp.git</connection>
<developerConnection>scm:git:[email protected]:gitRepo/sqeTemp.git</developerConnection>
<url>http://github.com/gitRepo/sqeTemp</url>
</scm>
<distributionManagement>
<repository>
<id>releases</id>
<url>
http://ec2.compute.amazonaws.com:8081/nexus/content/repositories/releases
</url>
</repository>
<snapshotRepository>
<id>snapshots</id>
<url>
http://ec2.compute.amazonaws.com:8081/nexus/content/repositories/snapshots
</url>
</snapshotRepository>
</distributionManagement>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.4.1</version>
<configuration>
<autoVersionSubmodules>false</autoVersionSubmodules>
</configuration>
</plugin>
When I do execute the mvn release:prepare
command, its complaining that I have local modifications to project 2 and project 3 which should be OK since it's not related to project 1 at all.
Now the question is, how do I tell the release plugin and Git to only focus on project 1 and not even bother with looking at project 2 and 3.
I'm new to GIT and have been a longtime user of SVN and never had this problem with SVN.
Upvotes: 0
Views: 187
Reputation: 1536
For a quick workaround, did you try stashing the changes from projekt 2 and 3?
Upvotes: 0
Reputation: 11443
With Subversion, you can check out just a subdirectory of a repository. This is not possible with Git. For a large project, this means that you always have to download the whole repository, even if you only need the current version of some sub-directory. I belive that is why release plugin is complaining about local changes in the other projects. It's a kind of general idea behind git, so the best way to work this around is to move separate projects to separate git repositories or separate git submodules
Upvotes: 1