[Building Sakai] Sakai 2.6 Contrib Tool Migration

[Matthew Jones]

Aaron's comment is accurate. Current versions of Maven have a number of
issues that someone *might* fix for future versions of maven. I think I
remember actually seeing a nice one that was fixed. Some of these might
improve these methods of building
Some of the more annoying ones with working on this:
- Property expansion doesn't work in the profile section:
http://jira.codehaus.org/browse/MNG-1775
<http://jira.codehaus.org/browse/MNG-1775>- Being able to have profiles
activate/deactivate other profiles: http://jira.codehaus.org/browse/MNG-2557

There were probably a few others. In any case, the limitation of not being
able to build in project subdirectories is based on using relative paths for
the "missing/exists" activation. A workaround would be to create symlinks in
the directory (something I believe Dr. Chuck tried somewhere). A nice
workaround would be to have it see if
"/.m2/repository/org/sakaiproject/kernel" exists or not and build K1 if it
found this. I tried it but maven couldn't resolve "~" to be the users home
directory and couldn't resolve any variables in the property activation as
mentioned by the jira. :/

The only solution was the one you can up with, explicit profile activation
on the command line. I had to rewrite the default missing/exists to just be
a 'exists' in both cases because there were some instances where both
profiles were still getting activated that I had. Then I added an
activeByDefault on the build that I always wanted to build (made it a little
easier).

As far as the full, Generally in a umich build, I build based on a bunch of
profiles and have noticed a few other tools that use "full" to need to
build. The default pom.xml of the site tool in the distribution has 2
profiles "framework" and "full". If you don't build "full" you don't get a
few features like the Page Order Helper. This was a weird bug for us. I
would just get used to building with "mvn install -P K1,full". If you
specify one profile on the command line (as you've found) it deactivates all
of the previously activated profiles.

The only way we'd be able to possibly get around that is to activate based
on a property mvn -DbuildK1 (which could activate the full and K1 profiles).
Though I'd just make an alias for to activate each profile unless the
community wants to decide on something better.

I use profiles for a lot of different things. A full umich build line is
something like

"mvn install
-P mini26,ctools26,extras,contribextras,taggable,ocw2,autojoin,tbook,evaluation,etudes2,mycourses,osp,gradtools,basiclti,full,simplerlti,mailsender,K1"

It allows you to do some pretty neat customized builds. This is, of course,
fired off via shell script. I would really like for one profile to be able
to either set properties or activate other profiles though. I'm sure it will
either happen eventually. Or if it gets too complex we'll be building with
something other than maven (or a wrapper around the build process).

-Matthew

On Tue, Sep 15, 2009 at 5:13 PM, D. Stuart Freeman <
stuart.freeman at et.gatech.edu> wrote:

> I'm trying to make blogwow build against 2.6 or 2.5 with minimal manual
> pom editing necessary.  I've done the "automatic method" at
>
> http://confluence.sakaiproject.org/display/DOC/Sakai+2.6+Contrib+Tool+Migration+Tips
> and with a little modification got it working if I build from within the
> project directory.  However, if I try to build from a containing
> directory with blogwow defined as a module it doesn't pick up the
> profile.  This appears to be due to maven treating the file path in the
> profile activation as relative to where the mvn command is run rather
> than the location of the pom.
>
> That led me to switch the activation to use the sakai.kernel.version
> property, if it exists we activate the K1 profile, if not we use the
> pre-K1.  This seems to be working for pre-K1, but I need to do further
> testing to see that it works for K1.
>
> It brings up another problem though.  Blogwow has existing profiles,
> there's "full" that builds everything and is active by default, as well
> as others like "ddl" and "tool" that just build those modules.  When the
> pre-K1 profile gets activated the default full profile is deactivated,
> but that's not what I want.  I can't just add the modules to the new
> profiles as that would break the ability to build a subset of the
> modules (I'm not sure how important that is to people).
>
> Does anyone have any suggestions?
>
> --
> D. Stuart Freeman
> Georgia Institute of Technology
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAkqwA2kACgkQ74jXllI0CXQTRQCgoRyMgao0xPJOI7ipOl2vXuYi
> b34AoLSCtiw/qalT+xSPx+yXnqZGXtKR
> =HgFP
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> 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/20090916/3a47c9b8/attachment.html