[Building Sakai] Assemblies

[Adrian Fish]

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"
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20131112/1973e703/attachment.html