debian packaging related tasks - sandboxable?

[Kevin Jackson <fo...@gmail.com>]

Hi all,

I have been working on some tasks related to debian packaging.

So far I have :
- dpkg (creates a debian package from a directory)
- control (creates a dpkg control file)

and I'm working on :
- install, takes a .deb package and installs it
- more robust error checking etc for the current tasks

I want to flesh this out as a real antlib for those of us who are
debian users, and also so that we can offer an official .deb build of
Ant (hopefully for 1.7.1 time).

Right now the requirements are that you have a debian based
distribution installed, although a .deb seems to be similar to a jar
(it's just an archive with metadata), so I'd like to transition to a
pure Java version if possible at a later date.

Would this be suitable for the svn sandbox? Are there any objections
to my committing my progress so far?  I only ask as I am in the middle
of updating to feisty fawn, and I'd like to version control my code in
case the worst should happen.

Thanks,
Kev

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: debian packaging related tasks - sandboxable?

[Steve Loughran <st...@apache.org>]

Kevin Jackson wrote:
> Hi all,
> 
> I have been working on some tasks related to debian packaging.
> 
> So far I have :
> - dpkg (creates a debian package from a directory)
> - control (creates a dpkg control file)
> 
> and I'm working on :
> - install, takes a .deb package and installs it
> - more robust error checking etc for the current tasks
> 
> I want to flesh this out as a real antlib for those of us who are
> debian users, and also so that we can offer an official .deb build of
> Ant (hopefully for 1.7.1 time).
> 
> Right now the requirements are that you have a debian based
> distribution installed, although a .deb seems to be similar to a jar
> (it's just an archive with metadata), so I'd like to transition to a
> pure Java version if possible at a later date.
> 
> Would this be suitable for the svn sandbox? Are there any objections
> to my committing my progress so far?  I only ask as I am in the middle
> of updating to feisty fawn, and I'd like to version control my code in
> case the worst should happen.

It could go in as a sandbox antlib, with the long term goal to make it a 
real one. If we could create .deb files without running on a debian 
distro, that would be very cool.

Have you got involved with the jpackage people? I was on their mail list 
for a couple of months last year, but unsubscribed due to irreconcilable 
differences.

-steve

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

RE: debian packaging related tasks - sandboxable?

[Stephen McConnell <mc...@dpml.net>]

 

> -----Original Message-----
> From: Bruce Atherton [mailto:bruce@callenish.com] 
> What do people think about Ant supporting a way to install 
> and remove antlibs from the command line into a standard 
> antlib directory that is automatically added to the classpath 
> on startup? That would support the creation of separate 
> debian packages for individual antlibs. Installed antlibs 
> could be made automatically available to any build file.

This would change the classpath content used across any Ant build and would
ultimately lead to conflicting classes.  

A better approach is to load required facilities into classloaders as close
as possible to the source of the requirement.  In the case of a task the
classloader should be established relative to the task definition.  In the
case of a project the classloader should be established relative to a
project definition.  The only time you should be dropping down to ant wide
extension is when you need to work around the absence of support for the
above capabilities.

I take care of more than a hundred project with lots of interdependencies.
I don't use the ant command (except on a very small number of bootstrapping
projects).  Instead I use a build system [1] that handles automatic
resolution of build sequencing, automatic creation of project classloaders,
and automatic deployment of task-relative classloaders.  This ensures
minimal classpath pollution backed by all of the benefits of
repository-based resource loading.

But the real kicker for debian packages would be related to a custom
repository that links a dabian package with a classloaders and for that you
should be tracking the JSR 277 [2]work.

Cheers, Steve.

[1] http://www.dpml.net/util/depot
[2] http://openjdk.java.net/projects/modules/

Re: debian packaging related tasks - sandboxable?

[Bruce Atherton <br...@callenish.com>]

I agree you'd need a way to turn it off, but I disagree that just adding 
to the LOCALCLASSPATH solves the problem. Or at least, we could do a 
better job in my opinion.

What I was thinking of is something like this: running "ant -install 
new-antlib.jar" could automatically copy the file to ${ANTLIB_HOME}, or 
if that were not set to a compiled-in default location (or loaded from 
an ant.conf file) like "${ANT_HOME}/antlib". That way different 
distributions could define the default location they preferred, but a 
user could still change it either temporarily or permanently.

The advantage to this is that control of the antlibs would be given to 
ant, which knows the most about them. Antlib-specific behaviour like 
validating the antlib, or providing a versioning mechanism, or some 
other feature we think of later would be much easier to do this way, it 
seems to me.

The downside is that the control is pretty coarse-grained: either you 
accept all the antlibs installed in ${ANTLIB_HOME}, or none of them. 
There is also the potential for all of the issues that installed 
extensions have had.

Stefan Bodewig wrote:
> On Fri, 11 May 2007, Bruce Atherton <br...@callenish.com> wrote:
>
>   
>> What do people think about Ant supporting a way to install and
>> remove antlibs from the command line into a standard antlib
>> directory that is automatically added to the classpath on startup?
>> That would support the creation of separate debian packages for
>> individual antlibs. Installed antlibs could be made automatically
>> available to any build file.
>>     
>
> This would be a system wide installation, so as a user you'd need a
> way to turn it off.  There may be situations where your system
> administrator has installed something into that directory that you
> don't want to have on your CLASSPATH (version conflicts ...).
>
> We already have a lot of support for RPM builds in our starter script.
> We could simply hook in Debian systems using the same mechanisms
> without changing anything.  Just provide a /etc/ant.conf which adds
> the directory (or the jars contained in it) you talk about to
> LOCALCLASSPATH and you are done.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>   

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: debian packaging related tasks - sandboxable?

[Stefan Bodewig <bo...@apache.org>]

On Fri, 11 May 2007, Bruce Atherton <br...@callenish.com> wrote:

> What do people think about Ant supporting a way to install and
> remove antlibs from the command line into a standard antlib
> directory that is automatically added to the classpath on startup?
> That would support the creation of separate debian packages for
> individual antlibs. Installed antlibs could be made automatically
> available to any build file.

This would be a system wide installation, so as a user you'd need a
way to turn it off.  There may be situations where your system
administrator has installed something into that directory that you
don't want to have on your CLASSPATH (version conflicts ...).

We already have a lot of support for RPM builds in our starter script.
We could simply hook in Debian systems using the same mechanisms
without changing anything.  Just provide a /etc/ant.conf which adds
the directory (or the jars contained in it) you talk about to
LOCALCLASSPATH and you are done.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: debian packaging related tasks - sandboxable?

[Bruce Atherton <br...@callenish.com>]

I think your plan is a great one.  I'm having a related but different 
thought about debian support.

What do people think about Ant supporting a way to install and remove 
antlibs from the command line into a standard antlib directory that is 
automatically added to the classpath on startup? That would support the 
creation of separate debian packages for individual antlibs. Installed 
antlibs could be made automatically available to any build file.

An alternative of doing this for debian is to define a specific location 
for separately-packaged antlibs to reside (such as 
/usr/share/ant/antlib) and to have that location added as a '-lib' 
parameter to the script installed to invoke ant, but I find that 
solution much more brittle. It doesn't survive a user-installed upgrade 
of ant into /usr/local, for example.

Kevin Jackson wrote:
> Hi all,
>
> I have been working on some tasks related to debian packaging.
>
> So far I have :
> - dpkg (creates a debian package from a directory)
> - control (creates a dpkg control file)
>
> and I'm working on :
> - install, takes a .deb package and installs it
> - more robust error checking etc for the current tasks
>
> I want to flesh this out as a real antlib for those of us who are
> debian users, and also so that we can offer an official .deb build of
> Ant (hopefully for 1.7.1 time).
>
> Right now the requirements are that you have a debian based
> distribution installed, although a .deb seems to be similar to a jar
> (it's just an archive with metadata), so I'd like to transition to a
> pure Java version if possible at a later date.
>
> Would this be suitable for the svn sandbox? Are there any objections
> to my committing my progress so far?  I only ask as I am in the middle
> of updating to feisty fawn, and I'd like to version control my code in
> case the worst should happen.
>
> Thanks,
> Kev
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: debian packaging related tasks - sandboxable?

[Kevin Jackson <fo...@gmail.com>]

> Kevin Jackson wrote:
> > urgh, never ask a
> > design student to write Java, it's a horrible sight :(
>
> probably like getting a java coder to do a web site, no?

Indeed, imagine the code equivalent of 'programmer art' - not a pretty sight!

Kev

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: debian packaging related tasks - sandboxable?

[Steve Loughran <st...@apache.org>]

Kevin Jackson wrote:
> urgh, never ask a
> design student to write Java, it's a horrible sight :(

probably like getting a java coder to do a web site, no?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: debian packaging related tasks - sandboxable?

[Kevin Jackson <fo...@gmail.com>]

Hi

> Go ahead.  The sandbox is there for committers to play.
>
> Stefan

I will try to tidy up the code and commit something later today - got
to mark my students sax/dom assignments first - urgh, never ask a
design student to write Java, it's a horrible sight :(

Kev

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: debian packaging related tasks - sandboxable?

[Stefan Bodewig <bo...@apache.org>]

On Fri, 11 May 2007, Kevin Jackson <fo...@gmail.com> wrote:

> Would this be suitable for the svn sandbox?

Absolutely yes.

> Are there any objections to my committing my progress so far?

Go ahead.  The sandbox is there for committers to play.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org