[Building Sakai] Dependencies, Indie Projects and Contrib

[Matthew Jones]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100625/92cdd79b/attachment.html