[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#792018: RFS: commandbox/2.0.0 ITP -- CFML REPL, CLI, Package Manager, and Embedded Server



Thanks again for the answers Emmanuel.  Due to the large amount of work that will be involved in packaging every Java dependency, we'll probably table this effort for now and come back to it at a later date.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp 

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org 
Blog: http://www.codersrevolution.com


On Sun, Jul 19, 2015 at 6:37 AM, Emmanuel Bourg <ebourg@apache.org> wrote:
Le 18/07/2015 08:18, Brad Wood a écrit :

> A source package makes sense in theory, but how do I create it? Does it
> contain the uncompiled Java and CFML source for the project?  If the
> source package must contain everything necessary to build my project,
> what restrictions are their on the build tools?  Will I have to rewrite
> to something other than Ant?  The current build is rather large and
> includes generation of API docs, and updating our artifacts repo.

A source package consists in the uncompiled upstream sources plus Debian
specific metadata and a makefile to build the project. Usually this
makefile delegates the work to the upstream build system, so you don't
have to rewrite something from scratch.

See for example the jsch package [1]. It contains the upstream sources
and an additional 'debian' directory. In this directory you'll find the
control file [2] that specifies the name, the description and the
dependencies of the source and binary packages, and the rules makefile
[3] that invokes the upstream Ant build file and assembles the jar files
and documentation produced into the final binary packages. The control
directory contains other files used by the makefile to build the binary
package.

If you clone the jsch package repository you can build the source and
the binary package with the 'debuild' command (you have to install the
devscripts package first).


> Does this mean I'd have to go through this entire process for every 3rd
> party lib and get them as separate packages on the Debian repo?  Can I
> solicit sponsorship for packages I don't have any control over?  How do
> you handle different versions of jars?  For instance, my project may
> need version 2.1 even though 2.3 is the latest, etc.  Does that also
> mean I'd have to create a source package and figure out how to compile
> each of the 3rd party libraries?

You are correct, every dependency must be packaged separately, and you
can package them even if you aren't an upstream developer (and we'll
happily support you in the process). If an already packaged dependency
is incompatible with your project, you can either patch your code to
work with the version available in Debian, or create a duplicate package
with a fixed version for this dependency (this isn't the common case
fortunately).

Emmanuel Bourg

[1] http://anonscm.debian.org/cgit/pkg-java/jsch.git/tree/
[2] http://anonscm.debian.org/cgit/pkg-java/jsch.git/tree/debian/control
[3] http://anonscm.debian.org/cgit/pkg-java/jsch.git/tree/debian/rules



Reply to: