Message-ID: <827961950.11027.1406566063748.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_11026_1607691272.1406566063747" ------=_Part_11026_1607691272.1406566063747 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This guide will walk you through=20
See http= ://www.nabble.com/forum/ViewPost.jtp?post=3D7884079&framed=3Dy&skin= =3D177, a single artifact can not be available on multiple repositories= .=20
The workaround is to install mvnproxy and include in the configuration a=
ll internal repositories.
This way mvnproxy will aggregate all the co= nfigured repositories regardless of what actual repository was requested. T= hat is, even though an artifact from central was requested, mvnproxy will r= eturn any matching files found for all the repositories that are configured= within mvnproxy.
The previous workaround was to suffix "-i" to the artifactId, = which is a broken workaround as this makes a duplicate copy of the artifact= with a different name and will cause two potentially incompatible librarie= s to be on the classpath. If you see any references to this workaround in t= his document please make corrections.=20
Previous versions of this document recommended a naming convention like = -INTERNAL-r<svn rev>-p<Patch Num>-p<Patch Num>... The pro= blem is that this causes very long file names on windows and then when you = run maven the java will fail with a general protection fault. Please ensure= you dont use long version values.=20
Maven uses Subversion as it's source control repository. The = base subversion repository is located at http://svn.apache.= org/repos/asf/maven. Within this structure there are a number of differ= ent directories of useful files:=20
Using your favourite subversion tool, check out the plugin you want (e.g= . http://svn.apache.org= /repos/asf/maven/plugins/trunk/maven-assembly-plugin)=20
Maven developers try to ensure that the trunk always builds and to build=
your own copy use
However because the plugin may be using snapshot versions of other plugi=
ns, you will need to ensure you have setup your environment correctly to ob=
tain any dependencies from the snapshot repositories. See the Maven Development Procedures for m=
ore details on how to configure your environment. You may also want to read=
Guide to Testi=
ng Development Versions of Plugin and
Guide to Plugin Snapshot Repositories= a> (this guide contains the codehaus snapshot repository setup)
Here are the profiles in use from following the advice above:=20 =20
Find the project for the maven plugin at h= ttp://jira.codehaus.org/secure/BrowseProjects.jspa.=20
Before you create a new JIRA issue you should confirm that there is no e=
xisting issue already available.
If one already exists, check what ot= her people have suggested for a suitable solution. If there is a patch alre= ady, try using that before making your own modifications.
The first step should be to create a unit test.=20
After the unit test has been created modify the code to pass the unit te= st.=20
Once the unit test is passing you can then build the plugin and attempt =
to use it locally via
mvn install. You should check that the p=
lugin works as expected in your project.
In the root directory of the plugin you have been modifying use
n diff > ../JIRA COMPONENT-JIRA ID-patch.txt e.=
svn diff > ../MASSEMBLY-118-patch.txt.
Find the JIRA issue you previously created and click the
le link on the left side under the
Operations links. In=
the comment text area provide a brief description of the patch contents an=
d anything of interest that should be pointed out.
In the root directoy of the plugin run
patch -p0 < PATCH FI=
patch -p0 < ../MASSEMBLY-118-patch.txt.=
-p0 says to patch that there are no leading paths that ne=
ed to be stripped from the patch file. In general you won't need to modify =
this, but if you do look at the
patch file for lines like
x: FILE and work out how many path elements should be strip=
ped and use that number as the option to
If you have an internal repository that is used by your company then you= will want to deploy your patched versions to this repository until your pa= tches have been applied to the plugin. If you don't have an internal reposi= tory you should consider setting one up, see Using Maven in a corporate environm= ent for more details.=20
Before you start, ensure that your pom file does not depend upon any
version you will need to checkout the trunk for that artifact, build it an=
d then follow the steps below to promote it to an internal release, otherwi=
se you won't have any control over the build process.
Make the following changes to the
pom.xml file after making=
a backup copy.
-INTERNAL-r<svn version>inste= ad of
-SNAPSHOT. See Better Builds with M= aven (June 2006) page 61 for an explanation of how version numbers are = compared. e.g. if the version is
2.2-SNAPSHOTand the subversi= on repository when you checked out the plugin was at r485327 then set it to=
2.2-INTERNAL-r485327. Note: When the plugin is officially rel= eased as
2.2the released version will be considered newer tha= n your patched version and supercede it. You will need to check if your pat= ches have been applied in the release and if not then follow these instruct= ions again. By including the patch numbers in the version id it will help y= ou identify immediately what needs to get checked.
repo= sitoriessection and contain an enabled
SNAPSHOT dependencies need to be internally released by=
following the above instructions. The dependency version is then changed f=
-INTERNAL. This can be quite a l=
ong process of chasing the dragon's tail.
You will need to also chase parent definitions that are a
version. Since you only need the pom definition use
mvn -N to avoid recursing into the module directories (which you don't care a=
bout and don't need to checkout). Parent poms are located one directory abo=
ve the current pom, unless there is a
Each dependency and parent pom that is promoted to
needs to be deployed to your internal repository via
mvn deploy, you must do this depth first so that the pom you are deploying has no <=
Once all dependencies and parents have been deployed you can now deploy =
your changes to the plugin to your internal repository via