debian packaging related tasks - sandboxable?

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-unsubscribeant.apache.org
For additional commands, e-mail: dev-helpant.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-unsubscribeant.apache.org
For additional commands, e-mail: dev-helpant.apache.org

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-unsubscribeant.apache.org
> For additional commands, e-mail: dev-helpant.apache.org
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeant.apache.org
For additional commands, e-mail: dev-helpant.apache.org

On Fri, 11 May 2007, Kevin Jackson <foamdinogmail.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-unsubscribeant.apache.org
For additional commands, e-mail: dev-helpant.apache.org

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
$, or 
if that were not set to a compiled-in default location (or
loaded from 
an ant.conf file) like "$/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 $, 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 <brucecallenish.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-unsubscribeant.apache.org
> For additional commands, e-mail: dev-helpant.apache.org
>
>   

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeant.apache.org
For additional commands, e-mail: dev-helpant.apache.org

 

> -----Original Message-----
> From: Bruce Atherton [mailto:brucecallenish.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/ut
il/depot
[2] http://open
jdk.java.net/projects/modules/