On 18/04/11 7:32 PM, Andrus Adamchik wrote:
The original idea of having "private" (aka "unpublished") modules that are aggregated into bigger public modules was about consistent picture that we wanted to present to the end users.
I am a little confused by the structure you are presenting. There appear to be several separate issues: 1. minimising the number of pom files visible to users. The current structure tries to achieve this, at the expense of the POLA (Principle Of Least Astonishment) to users familiar with the standard maven ways. The benefit of fewer poms is fairly insignificant. 2. the way the source code is structured and arranged (unpublished modules, etc). I see nothing really wrong with the way it is now.[1] Source code structure should be for Cayenne developers to understand, not end users to worry about. Yes, this produces poms that are visible to the end users, but few will ever care. 3. aggregation of the same code in different ways for client/server/jdk9/etc and how aggregation is achieved. Currently this is by using special aggregation poms. Another approach would be to use the main parent pom, along with profiles to build different output [2]. I don't have an opinion either way, and I'm not sure what is wrong with the current approach, but aggregating using profiles to include different modules seems more 'maven'. It seems to me that exposing cayenne-common.jar to the world is exposing the internal code structure to users. Why is this needed? Am I missing the point of this restructure? Ari [1] But if it were to change, then the source tree could match the output artifacts more closely: trunk - client - server - modeler - lifecycle - frameworks - di - core etc. This makes building artifacts and aggregating them more obvious. [2] http://stackoverflow.com/questions/4230553/maven-aggregate-pom-with-goal -- --------------------------> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
