Re: Maven and Subversion.

2011-04-20 Thread Marc Rohlfs
I was just thinking a bit about this. You're facing different problems 
You won't be able all at once:


1. You could create the releases of the sub modules independently (first 
You'd have to create a release of the parent, using 'mvn release:prepare 
release:perform -N'). Problem: the dependencies in the other sub modules 
wouldn't be updated to the new SNAPSHOT version of the released module.


2. You could release all modules together. Problems: You can only have 
tags for the whole multi project, but You can't have separate tags for 
each sub module (I think, but I can't verify this right now). 
Furthermore You'd always have to release all the sub modules together, 
but I'd assume that You'd rather like to release just one (or some) of 
the sub modules at the same time.


BTW: You'd face the same (or similar) problems with other SCMs, too.


What about requesting a new feature/parameter for the 
maven-release-plugin, e.g. 'releaseModule'. It could be configured the 
same way like the command line option '--projects'. If the parameter is 
not set, the plugin would create the release as it already does right 
now, and otherwise it would only tag and release the specified module(s).


What do You (list members) think about this approach?


Kind regards, Marc

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



Re: Maven and Subversion.

2011-04-20 Thread Wendy Smoak
On Wed, Apr 20, 2011 at 6:59 AM, Marc Rohlfs pomar...@googlemail.com wrote:
 I was just thinking a bit about this. You're facing different problems You
 won't be able all at once:

 1. You could create the releases of the sub modules independently (first
 You'd have to create a release of the parent, using 'mvn release:prepare
 release:perform -N').

Not necessarily.  If that parent (in the directory with the svn
externals) is only there as an aggregator for convenience, it never
needs to be released.

The projects themselves could have some other parent, like a corporate
level parent pom that controls versions, etc.

A project can only declare one parent but it's not 1:1.

-- 
Wendy

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



Re: Maven and Subversion.

2011-04-20 Thread Stephen Connolly
I've never set up a test project to see exactly what it does, but I
thought 
http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#commitByProject
might do something nice... or not!

On 20 April 2011 11:59, Marc Rohlfs pomar...@googlemail.com wrote:
 I was just thinking a bit about this. You're facing different problems You
 won't be able all at once:

 1. You could create the releases of the sub modules independently (first
 You'd have to create a release of the parent, using 'mvn release:prepare
 release:perform -N'). Problem: the dependencies in the other sub modules
 wouldn't be updated to the new SNAPSHOT version of the released module.

 2. You could release all modules together. Problems: You can only have tags
 for the whole multi project, but You can't have separate tags for each sub
 module (I think, but I can't verify this right now). Furthermore You'd
 always have to release all the sub modules together, but I'd assume that
 You'd rather like to release just one (or some) of the sub modules at the
 same time.

 BTW: You'd face the same (or similar) problems with other SCMs, too.


 What about requesting a new feature/parameter for the maven-release-plugin,
 e.g. 'releaseModule'. It could be configured the same way like the command
 line option '--projects'. If the parameter is not set, the plugin would
 create the release as it already does right now, and otherwise it would only
 tag and release the specified module(s).

 What do You (list members) think about this approach?


 Kind regards, Marc

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



Re: Maven and Subversion.

2011-04-20 Thread Marc Rohlfs
Didn't notice that parameter before. Sounds interesting - if it would 
really create a separate release tag for every module. But it wouldn't 
solve the problem of releasing just one (or some) of the modules in the 
reactor.



On 20/04/11 14:01, Stephen Connolly wrote:

I've never set up a test project to see exactly what it does, but I
thoughthttp://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#commitByProject
might do something nice... or not!


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



Re: Maven and Subversion.

2011-04-20 Thread Marc Rohlfs



On 20/04/11 13:55, Wendy Smoak wrote:

On Wed, Apr 20, 2011 at 6:59 AM, Marc Rohlfspomar...@googlemail.com  wrote:

I was just thinking a bit about this. You're facing different problems You
won't be able all at once:

1. You could create the releases of the sub modules independently (first
You'd have to create a release of the parent, using 'mvn release:prepare
release:perform -N').


Not necessarily.  If that parent (in the directory with the svn
externals) is only there as an aggregator for convenience, it never
needs to be released.


I didn't involve the svn:externals idea into my thoughts, because it 
would only work if the modules don't inherit from the parent. In most 
multi-module projects (I've seen), modules do inherit parent 
configurations. I You want to release a sub module, the release plugin 
requests the parent to be released first - which might be achieved using 
'mvn release:prepare release:perform -N'.





The projects themselves could have some other parent, like a corporate
level parent pom that controls versions, etc.

A project can only declare oneparent  but it's not 1:1.



You're right, but Maven discourages this:

[WARNING]
[WARNING] Some problems were encountered while building the effective 
model for test:my-sub-module:jar:1.0-SNAPSHOT
[WARNING] 'parent.relativePath' points at test:my-parent instead of 
test:another-parent, please verify your project structure @ line 11, 
column 11

[WARNING]
[WARNING] It is highly recommended to fix these problems because they 
threaten the stability of your build.

[WARNING]
[WARNING] For this reason, future Maven versions might no longer support 
building such malformed projects.

[WARNING]

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



Re: Maven and Subversion.

2011-04-20 Thread Marc Rohlfs

On 20/04/11 14:41, Marc Rohlfs wrote:

On 20/04/11 13:55, Wendy Smoak wrote:

On Wed, Apr 20, 2011 at 6:59 AM, Marc Rohlfspomar...@googlemail.com
wrote:

I was just thinking a bit about this. You're facing different
problems You
won't be able all at once:

1. You could create the releases of the sub modules independently (first
You'd have to create a release of the parent, using 'mvn release:prepare
release:perform -N').


Not necessarily. If that parent (in the directory with the svn
externals) is only there as an aggregator for convenience, it never
needs to be released.


I didn't involve the svn:externals idea into my thoughts, because it
would only work if the modules don't inherit from the parent. In most
multi-module projects (I've seen), modules do inherit parent
configurations. I You want to release a sub module, the release plugin
requests the parent to be released first - which might be achieved using
'mvn release:prepare release:perform -N'.




The projects themselves could have some other parent, like a corporate
level parent pom that controls versions, etc.

A project can only declare oneparent but it's not 1:1.



You're right, but Maven discourages this:

[WARNING]
[WARNING] Some problems were encountered while building the effective
model for test:my-sub-module:jar:1.0-SNAPSHOT
[WARNING] 'parent.relativePath' points at test:my-parent instead of
test:another-parent, please verify your project structure @ line 11,
column 11
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]


P.S.: Maybe the maven-invoker-plugin could solve this in another way ...

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



RE: Maven and Subversion.

2011-04-20 Thread tpatch
I am still working through the discussion - just wanted to say thanks for the 
feedback.

Todd

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



Re: Maven and Subversion.

2011-04-19 Thread Wendy Smoak
On Tue, Apr 19, 2011 at 2:38 PM,  tpa...@loftware.com wrote:

 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?

If the grouping is *solely* for convenience and you are never going to
release from that top level pom, then you can use svn externals to
pull it all together.

You'll have a directory that contains the top level pom, and has the
svn:externals properties set.  When you check out the directory,
you'll get all the subdirectories.

Several open source projects I've worked on have used this, there
might be a trunks or all directory that pulls in all the
interesting bits.

For CI or when you're ready to release, go back to the 'real' trunk
and do it from there.

-- 
Wendy

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



Re: Maven and Subversion.

2011-04-19 Thread B Smith-Mannschott
On Tue, Apr 19, 2011 at 20:38,  tpa...@loftware.com 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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



RE: Maven and Subversion.

2011-04-19 Thread Martin Gainty

!-- 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
  idsounds/id
  nameRepository for sounds/name
  urlhttp://sounds.red-bean.com/repos/url
  layoutdefault/layout
  snapshotPolicyalways/snapshotPolicy
/repository
repository

  idtoolkit/id

  nameRepository for sounds-toolkit revision 21/name

  urlhttp://sounds.red-bean.com/repos/skin-marker/url

  layoutdefault/layout

  snapshotPolicyalways/snapshotPolicy

/repository
  /repositories
!-- later on in pom.xml you can set profiles which will use the correct 
repository based on
   artifactId --
  profiles
profile
 idsounds/id
 activation
activeByDefaultfalse/activeByDefault
property
  name${pom.artifactId}/name
  valuesounds/value
/property
  /activation
  build.../build
  modules.../modules
  repositoriessounds/repositories
  pluginRepositories.../pluginRepositories
  dependencies.../dependencies
  reporting.../reporting
  dependencyManagement.../dependencyManagement
  distributionManagement.../distributionManagement
/profile

profile
  idtoolkit/id
 activation
activeByDefaultfalse/activeByDefault
property
  name${pom.artifactId}/name
  valuetoolkit/value
/property
  /activation
  build.../build
  modules.../modules
  repositoriestoolkit/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: bsmith.o...@gmail.com
 To: users@maven.apache.org
 
 On Tue, Apr 19, 2011 at 20:38,  tpa...@loftware.com 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

Re: Maven 1 subversion repository

2005-08-22 Thread Jon Strayer
Never mind. I got ot.

On 8/22/05, Jon Strayer [EMAIL PROTECTED] wrote:
 
 What's the path/url to the subversion repository for Maven plugins?



Re: Maven with Subversion

2005-02-21 Thread Brett Porter
On Mon, 21 Feb 2005 16:47:02 +, Bahaa Nasrallah
[EMAIL PROTECTED] wrote:
 Hi,
 I need some information about working with Subversion as SCM with Maven.
 I see that the majority of the plug-ins works with CVS like
 file-activity,developer activity and SCM plugin.

These all work with SVN - see
http://maven.apache.org/reference/plugins/changelog/

 Is Maven supporting enough working with Subversion? if yes how may i
 perform SCM tasks while the SCM plugin supports only CVS ?(actually
 this particular plugin supported once Subversion but not anymore after
 9th of Feb! )

It does, but is in beta:
http://www.apache.org/~brett/maven-stage-site/reference/plugins/scm/

 
 Thanks in advance!
 Bahaa
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED] 
 For additional commands, e-mail: [EMAIL PROTECTED] 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Maven with Subversion - Changelog problem.

2005-01-04 Thread Roy, Anthony
 I assume you are on windows? This is a problem that will be 
 rectified in the next release of the changelog plugin (this 
 weekend - you can use the source from subversion now).

Works like a charm now - thanks

-- 
Anthony Roy.


**

Experience the British Library online at www.bl.uk 

Help the British Library conserve the world's knowledge. Adopt a Book.
www.bl.uk/adoptabook 

*

The information contained in this e-mail is confidential and may be legally
privileged. It is intended for the addressee(s) only. If you are not the
intended recipient, please delete this e-mail and notify the
[EMAIL PROTECTED] : The contents of this e-mail must not be disclosed or
copied without the sender's consent. 

The statements and opinions expressed in this message are those of the
author and do not necessarily reflect those of the British Library. The
British Library does not take any responsibility for the views of the
author. 

* 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Maven with Subversion - Changelog problem.

2004-12-30 Thread Brett Porter
I assume you are on windows? This is a problem that will be rectified
in the next release of the changelog plugin (this weekend - you can
use the source from subversion now).

For authentication - you either need to setup an anonymous connection
and use auth for developerConnection, or preauthenticate by running
another svn command (as svn caches the auth).

Cheers,
Brett

On Thu, 30 Dec 2004 10:40:18 -, Roy, Anthony [EMAIL PROTECTED] wrote:
 Hi all,
 
 We are trying to get set up with Subversion as our scm, but I am having
 trouble getting it to write the changelog correctly. I have the following as
 my repository setup:
 
 repository
 connectionscm|svn|http://host:1234/svn/project/connection
 urlhttp://host:1234/projects/project/browser/url
 /repository
 
 I also have the line,
 maven.changelog.factory=org.apache.maven.svnlib.SvnChangeLogFactory, set
 in my project.properties file.
 
 This is fine as far as the Source Repository goes - the URL is picked up
 fine. No I am presuming that the only thing that the Changelog plugin
 requires is the 'maven.changelog.factory' property set, since I get the
 following outpu from maven when I run site:generate.
 
 [echo] Generating the Change Log...
 maven-changelog-plugin:report:
 [echo] Generating the changelog report
 SCM Working Directory: c:\svn\common\trunk
 SCM Command Line[0]: svn
 SCM Command Line[1]: log
 SCM Command Line[2]: -v
 SCM Command Line[3]: -r{2004-12-31}:{2004-11-30}
 ChangeLog found: 0 entries
 
 I presume that the SvnChangeLogFactory simply runs the command svn log -v
 -r{...}{...} in the current directory and has nothing to do with the
 connection tag. Note the problem: ChangeLog found: 0 entries; running
 the same command from the command line in the c:\svn\common\trunk directory
 results in the long list of changes I had expected.
 
 Any ideas on what the problem may be?
 
 A related problem is Subversion authentication. How can I set up Maven to
 run the ChangeLog tests (and, when I get around to trying it, the SCM goals)
 if I have an authenticating SVN server (currently whilst testing, there is
 no authentication required).
 
 Thanks,
 
 --
 Anthony Roy.
 
 **
 
 Experience the British Library online at www.bl.uk
 
 Help the British Library conserve the world's knowledge. Adopt a Book.
 www.bl.uk/adoptabook
 
 *
 
 The information contained in this e-mail is confidential and may be legally
 privileged. It is intended for the addressee(s) only. If you are not the
 intended recipient, please delete this e-mail and notify the
 [EMAIL PROTECTED] : The contents of this e-mail must not be disclosed or
 copied without the sender's consent.
 
 The statements and opinions expressed in this message are those of the
 author and do not necessarily reflect those of the British Library. The
 British Library does not take any responsibility for the views of the
 author.
 
 *
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Maven with Subversion - Changelog problem.

2004-12-30 Thread Roy, Anthony
 I assume you are on windows? This is a problem that will be 
 rectified in the next release of the changelog plugin (this 
 weekend - you can use the source from subversion now).

Great - look forward to it!
 
 For authentication - you either need to setup an anonymous 
 connection and use auth for developerConnection, or 
 preauthenticate by running another svn command (as svn caches 
 the auth).

OK - thanks.

-- 
Anthony Roy.

t: 01937 54 (6003)
e: [EMAIL PROTECTED]

The British Library
Boston Spa
Wetherby
West Yorkshire
LS23 7BQ



**

Experience the British Library online at www.bl.uk 

Help the British Library conserve the world's knowledge. Adopt a Book.
www.bl.uk/adoptabook 

*

The information contained in this e-mail is confidential and may be legally
privileged. It is intended for the addressee(s) only. If you are not the
intended recipient, please delete this e-mail and notify the
[EMAIL PROTECTED] : The contents of this e-mail must not be disclosed or
copied without the sender's consent. 

The statements and opinions expressed in this message are those of the
author and do not necessarily reflect those of the British Library. The
British Library does not take any responsibility for the views of the
author. 

* 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]