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 07:53:34 GMT

On May 12, 2009, at 7:02 PM, Ralph Goers wrote:

>
> On May 12, 2009, at 6:20 PM, David Jencks wrote:
>
>>
>> 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.
>
> No. The root represents the library. The release is of the library,  
> not the individual subprojects. I just don't want new versions  
> created for subprojects that didn't change.
>>
>>
>> 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.
>
> Actually, I do want them tagged. The "bill of materials" represents  
> a release of the whole library. It is just that some of the  
> artifacts in the library didn't change. But they should all be part  
> of the release tag.
>>
>>
>> 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.
>
> No. See above.
>>
>>
>> My impression is that what you are fighting is the scm system, not  
>> maven.
>
> No. The SCM isn't a problem. However, mvn deploy will try to deploy  
> artifacts that haven't changed since the last release. That is bad.  
> Nexus should be able to silently ignore those or the deployer should  
> somehow be able to detect that the artifact shouldn't be deployed.

I'm even more mystified and understand how you want to use scm even  
less.  One of the basic principles I have for scm is that stuff  
shouldn't be duplicated, in the sense that if some artifact is  
released at version 1.2.3.4 say, the scm location for that release can  
be found in only one, unique, place in the scm tree, such as an svn tag.

Now if I understand what you are proposing, its to have
+root(1.2-SNAPSHOT)
   +A(1.1-SNAPSHOT)
   +B(1.3-SNAPSHOT)

Only B has changed since the last release, which was of root (1.1),  
A(1.1) and B(1.2); these are the version in the release tag.

So you tag this after arranging the new release versions.  You new tag  
has root(1.2), A(1.1) and B(1.3), and trunk has root(1.3-SNAPSHOT),  
A(1.1-SNAPSHOT) and B(1.4-SNAPSHOT)

The problem I have with this is that A(1.1) is present in two  
different tags, violating the uniqueness principle I hold to.

Have I yet again misunderstood the actions you want to take during  
release or do you think the uniqueness principle is not worth  
following?  If I've misunderstood again, could you provide a more  
concrete example with versions and contents of tags to help me  
understand?

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