lp:~lool/snapcraft/integration

Branch merges

Propose for merging

No branches dependent on this one.

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

107. By Loïc Minier on 2015-07-24

Merge lp:~lool/snapcraft/mvn-plugin.

106. By Loïc Minier on 2015-07-24

Merge lp:~lool/snapcraft/no-separate-toplevel-dir.

105. By Michael Terry on 2015-07-22

This branch adds a copy plugin. It will copy artifacts into the snap dir. It makes the python3 example a fully working sha3sum that fetches the sha3 lib from github.

104. By Michael Terry on 2015-07-22

Add support for "source-type: tar", rename tgz-content to tar-content, and automatically strip single toplevel directories from unpacked tarballs.

103. By Michael Terry on 2015-07-22

Add source-type, source-branch, and source-tag to the standard source options for plugins.

102. By Michael Terry on 2015-07-22

This branch makes plugin code even simpler, by setting the groundwork for automatic handling of source options in the future.

We introduce a standard handle_source_options() method which will look at a standard set of 'source*' options and use them to grab project code. As we grow source options (see other branches), this method will gracefully handle it without any changes to the plugins.

In addition to the expected changes, I threw in some tiny cleanups I found along the way:

- in autotools_project.py, dropped the 'snap_files' method automatically excluding 'include' -- we haven't determined a sensible default exclusion like that yet

- in python3-project.yaml file, drop unused configflags option

- in plugin.py, dropped support for options_override. We don't use it anymore, I suspect it was originally a sort of option mock. But we seemed to evolve past the need for it.

101. By Michael Terry on 2015-07-22

Only wrap the binaries that are mentioned in meta/package.yaml.

This is less intrusive (not wrapping EVERYTHING we find), sufficient (as long as the entry points get the env, it should carry through), and more robust (executables NOT in bin/ or usr/bin/ can be found).

I also renamed snap/meta: to snappy-metadata: per the email I sent about yaml changes. That change hasn't been approved yet, but neither was the old way either.

I've also moved the actual metadata-copying and binary-wrapping to the snap() command. assemble() now just does 'snappy build'. This felt better, to let the user futz with final to-be-shipped bits if they want to before running snappy build.

100. By Michael Terry on 2015-07-22

Use a temporary cwd during the tests.
Added python3-fixtures as a build dependency.

99. By Michael Terry on 2015-07-22

Add a jdk plugin and an ant-project plugin that requires the jdk.

I use whichever version of openjdk is the default for the platform we're currently on (in keeping with our general choice of "snapcraft is running on the target platform").

I assume that ant will install jar files to target/ (seems to be a common convention, but isn't 100% followed, I don't think?). We can grow support for pointing out the install directory via a flag once we know more.

This isn't a very fancy plugin yet. It doesn't handle any dependencies specified by the ant build config. But it's a start. by mterry approved by mvo

98. By Michael Vogt on 2015-07-22

Look for a local plugin if and only if the plugin name starts with 'x-'.

This was a Mark-requested feature at the IoM, and I think it's fine. It didn't get coded that way at first, because I forgot about it. :-/

This means that parts-from-the-sky or that were copy-and-pasted won't accidentally pick up your weird local plugin. It also means that the user is very explicitly opting into a local plugin (and thus we don't need the warning output about using a local plugin). by mterry approved by mvo