[Building Sakai] Dependencies, Indie Projects and Contrib

[Steve Swinsburg]

Hi Matthew,

Whilst the build profiles technique for pre-K1 and K1 that Nuno and I figured out was pretty neat, I've abandoned it in favour of a Tomcat assembly/binary deploy. 

I believe the issue was that only one build profile can be active at any one time, and if you build the tool in amongst a full Sakai build, then a profile is always active so the profile you specify never gets activated and the build may fail. So now I just recommend using a binary deployment for things like Profile2.

That said, +1 to a standardised build profile id system. Then we could include these standardised profiles in tools and they can be built amongst a full deployment. The ids would need to be changed in the master poms though.

cheers,
Steve


On 26/06/2010, at 1:42 AM, Matthew Jones wrote:

> I'm have a problem, the same as last year, but first, a story (skip to TL;DR if desired) :
> 
> Back when Sakai 2.6 was released 2 years ago (2008), kernel was released as an independent project. This was essentially the first "indie project" and this was generally seen as a "good thing". However the side effect was that every project that depended on anything now in the kernel had to have their build files changed. Fortunately some people (Chuck and Ian) noticed developers would have a hard time figuring out what got renamed to what and wrote an xslt transform! [1]
> 
> A year later (2009), developers were finally bringing up 2.6 and some were having problems because while the trunk was converted, contrib tools weren't, so none of these compiled. As an additional problem, contrib developers still wanted their tools to compile under 2.5. So the options were.
> 1) Provide patches for 2.5 and 2.6 poms
> 2) Maintain 2 branches for each set of poms
> 3) Steve Swinsburg's and Nuno's great idea to use build profiles [2]
> 
> I took this idea and modified the old xslt scripts to use the build profiles and converted a bunch of tools so they could compile both ways and all was good. I wrote on confluence about it and a few people used it. [3] However the community never really seemed to have a best practice on this.
> 
> Flash forward to today (2010) and 2.7 is doing the same thing with edu-services and other indie projects. Some people like Charles Hedrick have complained about 'unnecessary pom changes' [4] and I agree with this especially for contrib. Especially as this time there are no xslt transforms and no build profiles (that I know of) that are suggested for developers. 
> 
> I would really like to suggest this as a best practice for Sakai tools. If you leave in the 'activateByDefault' then it will by default build on whatever the newest, but at least someone can toggle the old profiles and easily build. (Probably better than using the old exists/missing activation) There are ways for developers to work around api changes using these as well. [5] Then the only thing that *might* need a patch is the parent, which is still a problem because of MNG-624 [6], but maybe someday that will be resolved, and this is much easier fixed with a regex or a xslt.
> 
> TL;DR : I want build profiles using a consistent <id> so I can build the same tool in Sakai 2.5, 2.6 and 2.7 without patching or using an old branch or a tool. This worked great for tools in 2.6 that used it but it seemed like only a few people did. If all tools used it, I think it would be easier for everyone.
> 
> FYI: Just noticed gradebook2 is doing exactly this. Thanks gradebook2 developers!
> 
> https://source.sakaiproject.org/contrib/gradebook2/trunk/pom.xml
> 
> Thoughts?
> 
> <!-- Set up special profiles for different sakai versions for CM-API -->
> 
> <profiles>
>     <profile>
>         <id>sakai2.7</id>
>         <activation>
>             <!-- Sakai 2.7 is the default, activate this by default -->
>             <activeByDefault>true</activeByDefault>
>         </activation>
>         <dependencies>
>             <dependency>
>                 <groupId>org.sakaiproject.edu-services.course-management</groupId>
>                 <artifactId>coursemanagement-api</artifactId>
>                 <version>${sakai.edu-services.version}</version>
>             </dependency>
>         </dependencies>
>     </profile>
>     <profile>
>         <id>sakai2.6</id>
>         <dependencies>
>             <dependency>
>                 <groupId>org.sakaiproject</groupId>
>                 <artifactId>sakai-coursemanagement-api</artifactId>
>                 <version>${sakai.version}</version>
>             </dependency>
>         </dependencies>
>     </profile>
> </profiles>
> 
> [1] http://old.nabble.com/Bringing-a-contrib-tool-up-to-K1---SASH-td18747095.html
> [2] http://steve-on-sakai.blogspot.com/2009/03/build-profiles-and-sakai-dependencies.html
> [3] http://confluence.sakaiproject.org/display/DOC/Sakai+2.6+Contrib+Tool+Migration+Tips
> [4] http://collab.sakaiproject.org/pipermail/sakai-dev/2010-April/006746.html
> [5] http://mojo.codehaus.org/build-helper-maven-plugin/
> [6] http://jira.codehaus.org/browse/MNG-624
> _______________________________________________
> 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/20100626/63afabfe/attachment.html