maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Progress on support for large projects
Date Wed, 13 May 2009 01:20:22 GMT

On May 12, 2009, at 3:43 PM, Ralph Goers wrote:

>
> On May 12, 2009, at 2:43 PM, Brian Fox wrote:
>
>>>
>>>
>>>
>>> As I already said, I talked about release-plugin and my view of  
>>> the world
>>> and it seems NOT to fit together. My POM-tree follows strict logical
>>> aspects that is motivated by the architecture of the project and  
>>> NOT by
>>> the philosophy of some plugin.
>>>
>>
>> I'm trying to understand your structure and motivations behind it,  
>> so if you
>> would care to elaborate, we can be sure to consider these aspects  
>> down the
>> road.
>
> Well, you've seen mine. Imagine Apache commons where you wanted to  
> run a build from the root of commons. Not everything changes with  
> each release so it is silly to deploy new jar versions that haven't  
> changed. So you create a "bill of materials" (bom) pom that has the  
> versions of all the subprojects and anything wanting to use a  
> commons project can just import that and then specify dependencies  
> on the various commons subprojects without specifying a version. But  
> to build this all the subprojects need to have the bom pom as their  
> parent or grandparent. Thus, any time you change the bom pom version  
> every subproject has to change even if nothing changed in it. PITA.
>
> Granted, my "library" isn't as big as commons, put it still  
> currently contains 22 pom.xml files that have to be modified each  
> time the bom pom changes.

I'm fairly mystified how what you and Jorg appear to want could work  
with any of the scm systems I know about, that tag an entire file  
system subtree at once.  Maybe I don't understand what you guys are  
talking about at all..... here's what I think you want:

file system structure showing projects
+root
   +A
   +B
   +C
...
   +D

Probably Jorg has further nesting, but I don't think that actually  
affects the argument.

Projects A, C, E, G,... need to be released right now, whereas  
projects B, D, F... are just fine and don't need releases.

IIUC you guys are supposing a parent pom for all these projects in  
"root" and want to be able to run a release on root and have the  
effect be to release just A, C, E, G and the root pom.

So if you run a release on root the entire tree will get tagged  
including B, D, F etc that you didn't want tagged.

So I think what you want to do is have a quick way to run releases on  
A,C,E,G,... and have each of those tagged individually and not tag the  
whole tree at once.

My impression is that what you are fighting is the scm system, not  
maven.

As far as project setup, what I've done in this situation is have a  
parent pom that isn't "root" but parallel to the projects: all the  
projects use this parent as their parent and obviously dont specify  
its location as "..".  I then construct a pom that builds whatever I'm  
interested in working on in root, but don't check it into svn.  I've  
never had to release more than 2 projects at once in such a setup, so  
just releasing modules individually hasn't been a problem for me.  I  
can see that it would be a problem if I had 10 projects to release at  
once.  I'd think this is additional new functionality for e.g. the  
release plugin rather than something that can be created by modifying  
existing functionality.

I was really confused by this kind of situation until I realized that  
the problems with releasing complicated partial subtrees were caused  
by scm, not maven.  After I arranged the source so tagging would  
correspond to the independent versions I wanted the layout became much  
easier for me to understand.

Does this correspond at all to what you guys are talking about?

thanks
david jencks




>
>
> Ralph
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message