[Building Sakai] Assemblies

[Adrian Fish]

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/7493712a/attachment.html