[cle-release-team] An interesting (bug?) : release problem

David Horowitz david.horwitz at uct.ac.za
Wed Jul 4 08:28:46 PDT 2012


Some things to consider

1 if there is 1 high level Pom it should be simple, it should not define every API in shared the way master Does. Otherwise all we are doing is breaking the work to clean up our dependency tree by declaring a dependency by everything on everything.

There fore it should really just be framework dependencies, build profiles and licenses etc

The scope of a maven property is the Pom it's declared in, really we should not be using properties in master anywhere else

D

Sent from my iPad

On 04 Jul 2012, at 1:04 PM, Aaron Zeckoski <aaronz at vt.edu> wrote:

>> I suppose this wasn't done because I believe there was some idea that
>> kernels might release faster than the regular cycle of Sakai and master
>> would get out of sync. And what version would you release master as? This
> 
> Other way around. The idea was that kernel would not be changed as
> often as the rest of Sakai and it would be released less.
> 
> -AZ
> 
> 
> On Wed, Jul 4, 2012 at 1:24 AM, Matthew Jones <matthew at longsight.com> wrote:
>> I agree, it kind of feels like at this point that master should be the
>> parent for kernel, all of those dependencies defined in kernel that were
>> imported in SAK-18921 moved into master, rather than the other way around.
>> 
>> All master does is define properties and dependencyManagement. I believe if
>> that was worked around so that we just made kernel a "regular indie" and it
>> was
>> 
>> oss-parent<-master<-all indies (including kernel)
>> oss-parent<-master<-base<-all regular stuff
>> 
>> I was kind of hoping at one time for some type of "indie-base" that maven
>> could use to help figure out the release order so it didn't have to be
>> manually defined. I'm not sure if this was possible or not.
>> 
>> Perhaps this is the missing piece at the top?
>> 
>> I suppose this wasn't done because I believe there was some idea that
>> kernels might release faster than the regular cycle of Sakai and master
>> would get out of sync. And what version would you release master as? This
>> hasn't happened and 2.9 Sakai has always matched with 1.3.kernel.
>> Potentially a new master for each indie release of anything, but they've
>> been locked together since I've been doing it.
>> 
>> Would we ever have a 2 *released* Sakai 2.9's, one with a 1.3 kernel and one
>> with a 1.4 kernel? That really doesn't feel likely at all anymore. I think
>> even if we did we'd still have the confusion in the present state.
>> 
>> -Matthew
>> 
>> 
>> On Tue, Jul 3, 2012 at 7:41 PM, Steve Swinsburg <steve.swinsburg at gmail.com>
>> wrote:
>>> 
>>> It seems odd that the kernel needs to be built before the master. Master
>>> should be the top level parent for everything.
>>> 
>>> In https://jira.sakaiproject.org/browse/SAK-18921 the rationale was that
>>> these artifacts were deployed by the kernel so they need to be kept in sync
>>> with both projects, therefore use the import dependency. I would suggest
>>> these be moved out so instead of being deployed by the kernel they are
>>> deployed by another pom, kernel-deploy would be a good spot.
>>> 
>>> cheers,
>>> Steve
>>> 
>>> 
>>> On 04/07/2012, at 5:38 AM, Matthew Jones wrote:
>>> 
>>> So the Sakai release/build process is pretty bad. If you build it with a
>>> populated repository you get unpredictable results. If you build it with an
>>> empty repository it breaks. I'm not sure if this is a bug in maven or a bug
>>> in Sakai at the moment.
>>> 
>>> The problem with this really is this:
>>> https://jira.sakaiproject.org/browse/SAK-18921
>>> 
>>> Master has an import dependency on kernel so it requires kernel to be
>>> built before it can work. So I decided to try to change the master parent to
>>> kernel instead of sonatype so it would always build kernel first correctly
>>> as part of the reactor order (it still needs to build from base)
>>> https://jira.sakaiproject.org/browse/SAK-22353
>>> 
>>> So when you run "mvn clean install" on the base pom, it should see it has
>>> a parent of master->has a parent of kernel and know it needs to build
>>> everything.
>>> 
>>> It all seemed okay *except* when the build gets to the first tool that has
>>> a kernel dependency, it wants the wrong kernel version!
>>> 
>>> http://nightly2.sakaiproject.org/logs/sakai-rel/build-2012-07-03-01:00:02.log.txt
>>> 
>>> 1) org.sakaiproject.kernel:sakai-component-manager:jar:1.2-SNAPSHOT
>>> 
>>> This is defined in kernel pom's dependencyManagement with the
>>> "${project.version}" variable. And 1.2-SNAPSHOT is the version of common
>>> 
>>> <dependency>
>>> <groupId>org.sakaiproject.kernel</groupId>
>>> <artifactId>sakai-component-manager</artifactId>
>>> <version>${project.version}</version>
>>> <scope>provided</scope>
>>> </dependency>
>>> <dependency>
>>> <groupId>org.sakaiproject.kernel</groupId>
>>> <artifactId>sakai-kernel-api</artifactId>
>>> <version>${project.version}</version>
>>> <scope>provided</scope>
>>> </dependency>
>>> <dependency>
>>> <groupId>org.sakaiproject.kernel.component.api</groupId>
>>> <artifactId>sakai-component-manager</artifactId>
>>> <version>${project.version}</version>
>>> <scope>provided</scope>
>>> </dependency>
>>> </dependencies>
>>> 
>>> Somehow the version of the end child (common) is going all the way up to
>>> chain to the parent, and it's using that rather than the 1.3-SNAPSHOT
>>> defined in that pom. If I change this ${project.version} to be
>>> "1.3-SNAPSHOT" (or as a property with a value of 1.3-SNAPSHOT) in these 3
>>> places, the build works. If I revert SAK-18921 and put the parent of master
>>> back to sonatype it works too. (It's able to figure out kernel needs to be
>>> built first as it's a dependency for other projects, it just can't figure it
>>> out as an import dependency).
>>> 
>>> Maven 3 is even worse, because it fails completely without the
>>> relativePaths that were added in
>>> https://jira.sakaiproject.org/browse/SAK-22321 .
>>> 
>>> So I don't know what's up with this ${project.version}. Maybe it's bugged
>>> for multi module projects? I see a lot of random jiras. Same behavior in
>>> Maven 3.0.4 and 2.2.1.
>>> 
>>> I'm thinking of just moving the
>>> 
>>>        <sakai.kernel.version>1.3.0-SNAPSHOT</sakai.kernel.version>
>>> 
>>> property into kernel, and using that? I don't know . . .
>>> _______________________________________________
>>> cle-release-team mailing list
>>> cle-release-team at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>>> 
>>> 
>> 
>> 
>> _______________________________________________
>> cle-release-team mailing list
>> cle-release-team at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>> 
> 
> 
> 
> -- 
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
> 



More information about the cle-release-team mailing list