[Building Sakai] Maven profiles question

[Jim Eng]

Matthew Jones (Matthew Jones <jonespm at umich.edu>) suggested using activation by properties.  Here is the text of his response:

It looks like gradebook2 already does it and it works. Just add a property line to the activation block for the profiles and build it with -D instead of -P.

It looks like there might be some issues around it, like people wanting to be able to specify an "or" or an "and". Right now it's just whatever matches first, activatebydefault gets the lowest priority.
http://jira.codehaus.org/browse/MNG-3328

(Like in gb2 pom): 
 39 <id>sakai2.7</id> 
 40 <activation> 
 41 <activeByDefault>true</activeByDefault> 
 42 <property><name>sakai2.7</name></property>
 43 </activation>

$mvn -Dsakai2.6 help:active-profiles
Active Profiles for Project 'org.sakaiproject.gradebook2:gradebook2-base:pom:1.3.0-SNAPSHOT': The following profiles are active: 

 - sakai2.6 (source: pom)

$mvn -Dsakai2.7 help:active-profiles
The following profiles are active:

 - sakai2.7 (source: pom)

$mvn help:active-profiles
The following profiles are active:

 - sakai2.7 (source: pom)
On Nov 11, 2010, at 1:49 PM, Jim Eng wrote:

> BTW, in our branch of evaluation, the sakai2.7 profile is activated by default.  If we remove that and leave it without a default activation, evalport builds OK.  
> 
> So a possible solution is that every project with dependencies on indie projects could manage those dependencies across sakai versions with profiles with the understanding that none of them can define a default profile.  It would be better if we didn't need that restriction.
> 
> Jim
> 
> On Nov 11, 2010, at 1:23 PM, Jim Eng wrote:
> 
>> I am working on a contrib project ("evalport") with dependencies in kernel and other sakai projects with independent releases.  We have introduced the use of profiles so we can specify the dependencies correctly for Sakai 2.6, 2.7, etc.  To reduce confusion, we are using the same profile id's that have been used in gradebook2 and a couple other projects.  Our project is dependent on another contrib project ("evaluation") that uses the same profile id's.  
>> 
>> We are running into a problem when we try to build our project ("evalport") separately from the rest of sakai.  If we build all of sakai, including these two contrib projects, everything builds fine, as long as we specify the profile ("sakai2.6" or "sakai2.7").  But suppose we build everything with the "sakai2.6" profile and then make some slight changes in our contrib project ("evalport") and try to build it again with the "sakai2.6" profile.  That's when we have a problem.  The problem is that evaluation is dependent on scheduler.  In sakai 2.6, scheduler is not an indie release.  It is part of the core sakai build.  In sakai 2.7, scheduler is an indie project.  The group-id, artifact-id and version are all different.  The sakai2.6 profile in the evaluation pom's specify the old dependency and the sakai2.7 profile specify the new dependencies.  When we build evalport separately (with the sakai2.6 profile), it fails with error messages indicating that the indie version of sc
>> heduler can't be found and reports the source of the problem in the evaluation project, even though the evaluation jar was build with the 2.6 profile. 
>> 
>> Path to dependency: 
>> 	1) org.sakaiproject.evalport:evalport-api:jar:0.1
>> 	2) org.sakaiproject.evaluation:sakai-evaluation-api:jar:1.2.1
>> 	3) org.sakaiproject.scheduler:scheduler-api:jar:${sakai.scheduler.version}
>> 
>> I'm wondering if anybody has any suggestions about how to fix this.  I haven't found anything in the maven documentation.  Has anybody else seen something like this?  How did you solve it?
>> 
>> Thanks.
>> 
>> Jim
>> 
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>> 
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>> 
>> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20101111/d9d83553/attachment.html