[Building Sakai] Sakai 2.6 Contrib Tool Migration
D. Stuart Freeman
stuart.freeman at et.gatech.edu
Wed Sep 16 06:28:16 PDT 2009
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20090916/377ec78a/attachment.bin
More information about the sakai-dev
mailing list