[Building Sakai] Assemblies

Tue Nov 12 09:28:02 PST 2013

Cool stuff, both of you. Maybe a blog/wiki post?

Thanks,
-Noah

On Nov 12, 2013, at 10:47 AM, Matthew Jones wrote:

> As a followup, I've had these functions called 'c' and 'cskip' (that adds the maven skip' for some time that do this same thing. Check out a project, go into it and run "c". Deploy to tmp and tar it up. Just put them into the .bashrc startup script. Probably some silght improvement but did the job. For the full sakai build, you can run -P pack-bin and get a full archive of everything.
> 
> function c () {
> export TOMTMP="/tmp/$(date +%N)"
> mvn -Dmaven.tomcat.home=$TOMTMP clean install sakai:deploy && printf "Deployed to %s\n" $TOMTMP && pushd . && cd $TOMTMP && tar zcvf $TOMTMP.tgz * && popd && printf "Created %s\n" $TOMTMP.tgz;
> }
> 
> function cskip () {
> export TOMTMP=/tmp/$(date +%N)
> mvn -Dmaven.test.skip=true -Dmaven.tomcat.home=$TOMTMP clean install sakai:deploy && printf "Deployed to %s\n" $TOMTMP && pushd . && cd $TOMTMP && tar zcvf $TOMTMP.tgz * && popd && printf "Created %s\n" $TOMTMP.tgz;
> }
> 
> 
> 
> On Tue, Nov 12, 2013 at 10:32 AM, Adrian Fish <adrian.r.fish at gmail.com> wrote:
> I've ended up putting this on my path:
> 
> #!/bin/sh
> 
> tooldir=`pwd`
> toolname=`basename ${tooldir}`
> tomcatdir=${tooldir}/tarball
> tarfile=${tooldir}/${toolname}.tgz
> 
> echo "Making ${tomcatdir} ..."
> mkdir ${tomcatdir}
> 
> mvn -o -Dmaven.tomcat.home=${tomcatdir} sakai:deploy
> 
> echo "Tarring ${tomcatdir} to ${tarfile} ..."
> cd ${tomcatdir}
> tar zcf ${tarfile} *
> 
> Which does the job,
> 
> Cheers,
> Adrian.
> 
> 
> On 12 November 2013 14:49, Adrian Fish <adrian.r.fish at gmail.com> wrote:
> Thanks Noah. That's a good idea, deploying to a temp directory and then zipping it.
> 
> Cheers,
> Adrian.
> 
> 
> On 12 November 2013 13:44, Noah Botimer <botimer at umich.edu> wrote:
> I think it's based on sound goals, but I'm not sure the execution ever delivered. Unless I missed something, it's just an unzip. There is no manifest or anything to clean up after a deployment. Say, for example, an API jar gets a version bump. There would be two versions in shared and no telling which would be loaded by a webapp.
> 
> So, that's the problem. Here's an equivalent pattern without the "assembly":
> 
> cd /sakai-src/awesome-tool
> mkdir awesome-tool-0.0.1
> mvn -Dmaven.tomcat.home=`pwd`/awesome-tool-0.0.1 sakai:deploy
> tar zcf awesome-tool-0.0.1.tar.gz awesome-tool-0.0.1
> cd /awesome-tomcat-install
> tar zxvf /sakai-src/awesome-tool/awesome-tool-0.0.1.tar.gz
> 
> Namely, you could set up a tiny shell script or maven goal to do this, whatever you call it or however you compress it. The sakai:deploy to a dummy dir followed by some zip is the key. It's just important to be aware of the limitations of such a pattern as noted above.
> 
> Something like a WAR/EAR is really a better model, but unless we scope the conversation down, we end up back at the "reloadable component manager" topic that seeded the "K1" effort in 2007 and OSGI experiments... I have no suggested answers here, except maybe sakai:deploy writing a manifest file and a generalized script that can clean up according to said manifest.
> 
> Thanks,
> -Noah
> 
> On Nov 12, 2013, at 7:29 AM, Adrian Fish wrote:
> 
>> Thanks Aaron.
>> 
>> Don't assemblies have some use outside of the full Sakai build scenario, though? I just find them useful for building a zip that can be overlaid onto a production server, and the idea of the tool maintainer maintaining the list of files that goes into that zip, via the assembly, seems sound. So, nothing to do with indies, or full builds, just making it a bit easier to do individual tool upgrades to production machines without needing the source or dev tools to be on that machine.
>> 
>> Cheers,
>> Adrian.
>> 
>> 
>> On 12 November 2013 12:21, Aaron Zeckoski <azeckoski at unicon.net> wrote:
>> I think this was best covered in this email thread (snippet below) but
>> as part of https://jira.sakaiproject.org/browse/SAK-23907 the
>> assemblies were deleted from all core code in trunk and generally
>> speaking, contrib projects should follow this practice (though nothing
>> says they have to, there just won't be any community support for an
>> assembly style build).
>> 
>> -AZ
>> 
>> On Thu, Sep 12, 2013 at 3:45 PM, Aaron Zeckoski <azeckoski at unicon.net> wrote:
>> > This is a "heads up" (warning) for all developers and contrib tool authors.
>> >
>> > With the completion of https://jira.sakaiproject.org/browse/SAK-23907
>> > we will have removed all indies (projects which were versioned
>> > separately from the main Sakai version and downloaded as a binary
>> > instead of built during regular builds) and all indie project versions
>> > (e.g. sakai.jsf.version) from the corporate POM (a.k.a. master). This
>> > change includes the kernel. This has been committed to trunk as of
>> > today and should be working for all core projects.
>> >
>> > Any contrib tools which referenced older versions manually (e.g.
>> > 1.4.0-SNAPSHOT for kernel) or used the project versions will fail to
>> > build against trunk after today. All non-core code should use the
>> > Sakai master pom as parent and should not reference versions directly
>> > but should instead exclude the version for all Sakai dependencies and
>> > all maven dependency management to handle the versioning.
>> >
>> > Look at the projects in the core for examples of the right way to do this.
>> >
>> > Let me know if you have any questions.
>> > -AZ
>> 
>> 
>> On Tue, Nov 12, 2013 at 6:52 AM, Adrian Fish <adrian.r.fish at gmail.com> wrote:
>> > I know there was recently discussion involving removing the assemblies from
>> > tools, since they don't make sense outside the context of independent
>> > builds. Was a decision reached on that?
>> >
>> > Cheers,
>> > Adrian.
>> >
>> > _______________________________________________
>> > 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"
>> 
>> 
>> 
>> --
>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>> 
>> _______________________________________________
>> 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"
> 
> 
> 
> 
> _______________________________________________
> 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/20131112/0d045adb/attachment.html 