[Building Sakai] Dependencies, Indie Projects and Contrib

Matthew Jones jonespm at umich.edu
Fri Jun 25 17:20:45 PDT 2010 

Thanks for the response Steve,

I think the ultimate "good thing" would be to make it easy for every project
to be at indie release and do binary releases as you mentioned. This is on
the 2.8 road map. However, there is still a few things holding this up.

1) Because version api's and impl's (especially kernel) are the same we'd
really have to do indie binary release's for every release for highest
confidence. (2.6.0,2.6.1,2.6.2,2.7.0 . . .) This is as I'd mentioned here.
[1] This is a relatively easy problem to fix but it would touch a lot of
code.

2) Most people either can't release indie projects or don't know how. Are
they released from builds.sakaiproject.org? I don't see anything in
confluence about how to actually deploy this. I am not entirely clear how to
do it and think *I* have the permission to do it (but don't do it very often
yet). :)

3) If you're actually building from source, from 2.x or using something that
isn't yet indie, you're out of luck.

I know profile activation is kind of flaky as it seemed the only good ways
to do it were by setting the activeByDefault (and not bother the builder) or
by the having a special file set with <exist> (this worked good in 2.5->2.6)
'unless' another profile is activated somehow by some other trigger. [2] It
ended up being better than doing an <exists> <missing> to just do all
<exists>. I guess it would be *nice* to be able to trigger profiles from
profiles, a few others have also thought so. (MNG-3309) [3] I guess you
can't use too many profiles per tool though, but I don't *think* anyone else
really is using these for anything other than dependency protection between
versions, and in that case there would just be a little duplication.

I typically use all explicit profiles when I do builds (ctools has like 20
profiles in the last build), but it's I know it's possible someone might not
use any and they shouldn't be expected to.

*TL;DR:* Mostly what I'm suggesting (asking for) is that we agree on common
profile id's from here on out that everyone can (and hopefully will use if
they want backward compatibilty) and either acitveByDefault or use an
<exists> tag and some special file in the build (in master? like sakai-2.6).
Lost too much time messing with this, since we're a few months behind the
curve, yet still want the 'latest and greatest'. :)

I don't want to have to activate -P sakai-2.6, sakai2.6, K1, SAKAI, 2.6,
PROFILE2-6. :)

FYI: I'd found that iclicker is also using profiles (Thanks!), but I've
already got the issue i described. :/
*iclicker*
<id>sakai-2.6</id>
*gradebook2 *
<id>sakai2.6</id>

Thanks!

[1]
http://collab.sakaiproject.org/pipermail/sakai-dev/2010-March/006544.html
[2]
http://maven.apache.org/guides/introduction/introduction-to-profiles.html
[3] http://jira.codehaus.org/browse/MNG-3309

On Fri, Jun 25, 2010 at 6:31 PM, Steve Swinsburg
<steve.swinsburg at gmail.com>wrote:

> 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/20100625/37f434eb/attachment.html

More information about the sakai-dev mailing list