<!-- take these 2 svn:externals properties as an example -->
$ svn propget svn:externals calc
third-party/sounds http://sounds.red-bean.com/repos
third-party/skins/toolkit -r21 http://svn.red-bean.com/repos/skin-maker
<!-- you can setup different repository links in settings.xml something like:
-->
<repositories>
<repository>
<id>sounds</id>
<name>Repository for sounds</name>
<url>http://sounds.red-bean.com/repos</url>
<layout>default</layout>
<snapshotPolicy>always</snapshotPolicy>
</repository>
<repository>
<id>toolkit</id>
<name>Repository for sounds-toolkit revision 21</name>
<url>http://sounds.red-bean.com/repos/skin-marker</url>
<layout>default</layout>
<snapshotPolicy>always</snapshotPolicy>
</repository>
</repositories>
<!-- later on in pom.xml you can set profiles which will use the correct
repository based on
artifactId -->
<profiles>
<profile>
<id>sounds</id>
<activation>
<activeByDefault>false</activeByDefault>
<property>
<name>${pom.artifactId}</name>
<value>sounds</value>
</property>
</activation>
<build>...</build>
<modules>...</modules>
<repositories>sounds</repositories>
<pluginRepositories>...</pluginRepositories>
<dependencies>...</dependencies>
<reporting>...</reporting>
<dependencyManagement>...</dependencyManagement>
<distributionManagement>...</distributionManagement>
</profile>
<profile>
<id>toolkit</id>
<activation>
<activeByDefault>false</activeByDefault>
<property>
<name>${pom.artifactId}</name>
<value>toolkit</value>
</property>
</activation>
<build>...</build>
<modules>...</modules>
<repositories>toolkit</repositories>
<pluginRepositories>...</pluginRepositories>
<dependencies>...</dependencies>
<reporting>...</reporting>
<dependencyManagement>...</dependencyManagement>
<distributionManagement>...</distributionManagement>
</profile>
</profiles>
the point is you dont want to have to avert any special repository commands to
accomodate different versioned
artifacts located in different repositories
makes sense?
Martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
> Date: Tue, 19 Apr 2011 20:56:28 +0200
> Subject: Re: Maven and Subversion.
> From: [email protected]
> To: [email protected]
>
> On Tue, Apr 19, 2011 at 20:38, <[email protected]> wrote:
> > I am wondering if anyone has a good solution to the following issue.
> >
> > I have a multi module maven configuration ( a pom that runs multiple poms
> > underneath it.). I made it a multi module project because the sub projects
> > are very similar and it is convenient to run them all from one pom.
> > However, I need each of these sub projects to be versioned independently.
> > In subversion, you need to make trunk, tags, and branches folders for each
> > project to do this. This breaks the multi module directory structure for
> > Maven as it requires the pom to be in the top level folder for each of the
> > sub projects.
> >
> > Does anyone have a solution as to the best way to make this work, or am I
> > stuck with not using the multi module project in Maven?
> >
> > Thanks,
> >
> > Todd
>
> In our repository we have the policy that only modules that are always
> released together can live in the same trunk. As a result we don't
> have many multi-module builds. This isn't all rainbows and unicorns,
> as this means more individual trunks to tag, more versions to keep
> track of, more things to build and deploy etc.
>
> For such cases, we've used svn:externals to pull together a few large
> (50 modules) multi-module builds. So far, this has worked out OK. You
> can't sensibly maven release:perform from the root of such a project.
> When it's time to release you still have to do each sub-module
> separately. During development, however, it's a convenient way to
> check everything out and build everything together.
>
>
> Super simplified example:
>
> /repo/project-a/trunk (development, 1.1-SNAPSHOT)
> /repo/project-a/branches/1.0.x (a 1.0.x-SNAPSHOT release branch)
> /repo/project-a/tags/1.0.0
> /repo/project-b/trunk (development, 1.2-SNAPSHOT)
> /repo/project-b/branches/1.1.x (a 1.1.x-SNAPSHOT release branch)
> /repo/project-b/tags/1.1.0
>
> /repo/combined-release/trunk
> contains a pom.xml naming the submodules and defines svn:externals for
> /repo/project-a/trunk
> /repo/project-b/trunk
>
> /repo/combined-release/branches/1.0.x
> contains a pom.xml naming the submodules and defines svn:externals for
> /repo/project-a/branches/1.0.x
> /repo/project-b/branches/1.1.x
>
> /repo/combined-release/tags/1.0.0
> contains a pom.xml naming the submodules and defines svn:externals for
> /repo/project-a/tags/1.0.0
> /repo/project-b/tags/1.1.0
>
> Making something like the above release tag means editing the
> svn:externals to point at the correct project tags. There's no way (I
> know of) of getting maven to do this, as it's pretty SVN specific.
>
> // ben
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
