[Building Sakai] Sakai 2.6 Contrib Tool Migration

Wed Sep 16 07:37:17 PDT 2009

This suggestion was a comment added in 02/2009 to
http://jira.codehaus.org/browse/MNG-1753 (support improved property
based profile activation)

"Please supply profile activation based on properties set within the
pom.xml, or its parents, via project.properties. Currently, only
properties passed on the CLI are able to activate profiles."

They are looking for ideas for future versions of maven. This would be
fantastic if it worked. Vote and add your support! :) (I have)

Yea, it's kind of a bummer that it deactivates that profile. They'd
need to have an alwaysActiveByDefault or something.

-Matthew

On Wed, Sep 16, 2009 at 9:28 AM, D. Stuart Freeman
<stuart.freeman at et.gatech.edu> wrote:
>
> I'm hoping not to have to specify the property on the command line, but
> rather base the profile activation on the existence of a property that is
> inherited from the parent pom and exists in the K1 parent but not the
> pre-K1 parent.  Unfortunately, that seems to deactivate the active by
> default profiles as well though.
>
> On Wed, Sep 16, 2009 at 09:11:23AM -0400, Matthew Jones wrote:
> >    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:�[1]http://jira.codehaus.org/browse/MNG-1775
> >    - Being able to have profiles activate/deactivate other
> >    profiles:�[2]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
> >    <[3]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
> >      [4]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
> >      [5]sakai-dev at collab.sakaiproject.org
> >      [6]http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> >
> >      TO UNSUBSCRIBE: send email to
> >      [7]sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> >      "unsubscribe"
> >
> > References
> >
> >    Visible links
> >    1. http://jira.codehaus.org/browse/MNG-1775
> >    2. http://jira.codehaus.org/browse/MNG-2557
> >    3. mailto:stuart.freeman at et.gatech.edu
> >    4. http://confluence.sakaiproject.org/display/DOC/Sakai+2.6+Contrib+Tool+Migration+Tips
> >    5. mailto:sakai-dev at collab.sakaiproject.org
> >    6. http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> >    7. mailto:sakai-dev-unsubscribe at collab.sakaiproject.org
>
> --
> D. Stuart Freeman
> Georgia Institute of Technology
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAkqw5/AACgkQ74jXllI0CXSM5gCg29tJ48Wj9yUMZKnl7f8reYTy
> kRoAn0zLI5ywyT+JEQmqP6ViE/doFEIw
> =NF0K
> -----END PGP SIGNATURE-----
>