Bug#881297: Summary: The state of the existing karaf debian package

[Steinar Bang]

Update to the state of the karaf-debian package:
 https://github.com/steinarb/karaf-debian

The following fixes/improvements have been made:
 1. I've run lintian with the following argument and fixed all of the
complaints:
 lintian -vIiE --pedantic --color=auto karaf*.changes 
karaf_4.1.4-10~9.30_all.deb

 2. I've corrected the ownership of /etc/karaf:
- The ownership has been changed from karaf.karaf to root.karaf
- The mode has been set to 2770 on /etc/karaf/ itself (karaf,
  running as user karaf, must be allowed to create new .cfg files in
  this directory)
- Set ownership root.karaf and mode 2750 on all files in /etc/karaf/
  except for the .cfg files and config.properties
- Set ownership karaf.karaf and mode 2770 on all of the .cfg files
  and config.properties, because karaf needs to be able to write to
  them

 3. Moved KARAF_HOME to /var/lib/karaf and let /usr/share/karaf/ have
ownership root.root.
$KARAF_HOME/bin, $KARAF_HOME/lib and $KARAF_HOME/system are all
symlinks to /usr/share/karaf/

 4. Added SYSV init.d files
Note: these are not extensively tested, because the only way I had
to test them was to build .deb packages with the systemd stuff
removed and try to install them and see that the daemon started, and
that was a lot of work

 5. Moved karaf.log from $KARAF_DATA/log/ to /var/log/karaf/

 6. Bumped the upstream karaf version from 4.1.4 to 4.1.5

Bug#881297: Summary: The state of the existing karaf debian package

[Steinar Bang]

>>>>> Steinar Bang :

> I believe the following steps are needed to make this an official
> package:
>  1. Replace the remaining non-karaf boot jars with debian packages,
> these packages are:
> a. apache felix framework 5.6.10
>- Already a debian package, but currently in version 4.6.12 in
>  stretch, testing and unstable [3]

I've filed a bug to have this updated:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890143

> b. apache felix metatype 1.1.6 [4]

I've filed an RFP for this package:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890144

> c. apache felix configadmin 1.8.16 [5]

I've filed an RFP for this package:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890145

> d. apache felix file install 3.6.4 [6]

I've filed an RFP for this package:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890146

> e. OPS4J PAX URL Aether 2.5.3 [7]

I've filed an RFP for the parentt projec for this package:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890181

> f. OPS4J PAX Logging API 1.10.1 [8]
> g. OPS4J PAX Logging Log4J2 1.10.1 [9]

I've filed an RFP for the parent project for these two packages:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890182

Bug#890182: RFP: libpax-logging -- OSGi logging support

[Steinar Bang]

Package: wnpp
Severity: wishlist

* Package name: libpax-logging
  Version : 1.10.1
  Upstream Author : Alin Dreghiciu 
* URL : https://github.com/ops4j/org.ops4j.pax.logging
* License : Apache v. 2
  Programming Lang: Java
  Description : OSGi logging support

The logging support in the standard Log Service of the OSGi specification is
minimalistic and not entirely suitable for enterprise applications. This
project tries to address this by extending the standard interface with
additional interfaces and using a strong logging backend, the Apache Log4J. Pax
Logging defines its own API, but more importantly it supports the Log4J and
Jakarta Commons Logging APIs as well, making it easy to create bundles that use
these common APIs, either directly in new code or indirectly from inside 3rd
party libraries.

This library is a requirement for having a debian package of apache karaf.  See
this URL for details:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881297#30

Bug#890181: RFP: libpax-url -- URL stream handlers for OSGi

[Steinar Bang]

Package: wnpp
Severity: wishlist

* Package name: libpax-url
  Version : 2.5.3
  Upstream Author : Alin Dreghiciu 
* URL : https://github.com/ops4j/org.ops4j.pax.url
* License : Apache v.2
  Programming Lang: Java
  Description : URL stream handlers for OSGi


OPS4J Pax URL is a set of URL handlers mainly targeting OSGi URL Handler
Service but which can be used in a standard Java environment.

This library is a requirement for a debian package for apache karaf.  See this
URL for details:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881297#30

Bug#890145: RFP: libfelix-configadmin -- An implementation of the OSGi Componendium Configuration Admin Service

[Steinar Bang]

Package: wnpp
Severity: wishlist

* Package name: libfelix-configadmin
  Version : 1.8.16
  Upstream Author : d...@felix.apache.org
* URL : http://felix.apache.org/documentation/subprojects/apache-
felix-config-admin.html
* License : Apache v.2
  Programming Lang: Java
  Description : An implementation of the OSGi Componendium Configuration
Admin Service

The OSGi Componendium Configuration Admin Service specifies a service, which
allows for easy management of configuration data for configurable components.
Basicaly configuration is a list of name-value pairs. Configuration is managed
by management applications by asking the Configuration Admin Service for such
configuration. After updating the configuration, it is sent back to the
Configuration Admin Service. The Configuration Admin Service is like a central
hub, which cares for persisting this configuration and also for distributing
the configuration to interested parties. One class of such parties are the
components to be configured. These are registered as ManagedService services.
There is also a notion of ManagedServiceFactory, which allows for multiple
configurations of the same kind to be applied.

This Java library is a requirement for a debian package for apache karaf. See
this URL for details:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881297#30

Bug#890146: RFP: libfelix-fileinstall -- File Install is a directory based OSGi management agent.

[Steinar Bang]

Package: wnpp
Severity: wishlist

* Package name: libfelix-fileinstall
  Version : 3.6.4
  Upstream Author : d...@felix.apache.org
* URL : http://felix.apache.org/documentation/subprojects/apache-
felix-file-install.html
* License : Apache v.2
  Programming Lang: Java
  Description : File Install is a directory based OSGi management agent.

File Install is a directory based OSGi management agent. It uses a directory in
the file system to install and start a bundle when it is first placed there. It
updates the bundle when you update the bundle file in the directory and, when
the file is deleted, it will stop and uninstall the bundle.

This java library is a requirement for creating a debian package of apache
karaf.  See this URL for details:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881297#30

Bug#890144: RFP: libfelix-metatype -- An implementation of the OSGi metatype specification

[Steinar Bang]

Package: wnpp
Severity: wishlist

* Package name: libfelix-metatype
  Version : 1.1.6
  Upstream Author : d...@felix.apache.org
* URL : http://felix.apache.org/documentation/subprojects/apache-
felix-metatype-service.html
* License : Apache v.2
  Programming Lang: Java
  Description : An implementation of the OSGi metatype specification.

The OSGi Metatype specification provides a unified way to describe metadata
about services and a Java interface to retrieve and manipulate such
information. This information can optionally be localized, thus allowing the
developer to provide human-readable metadata descriptions in multiple
languages. The specification defines a rich dynamic typing system to describe
service attributes in a precise way, which makes it possible to dynamically
create user interfaces to configure services.

This package is a requirement for having an apache karaf debian package.  See
this URL for more information:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881297#30

Bug#881297: Summary: The state of the existing karaf debian package

[Steinar Bang]

My own karaf debian package[1] is now in a state where it does what I
need for my own use.  I'm serving the package from my own unofficial APT
repository (which I will discontinue if this RFP results in an official
karaf package).

I don't plan to do any more work on this packaging, except what is
needed to make new stable karaf releases run (ie. I will roll a new
version of the package when karaf 4.1.5 is out).

I'm leaving some notes on the current state of the packaging here
(ie. in the mailing list archives) in case someone wants to use this
package as a starter for an official package.  I will send a message to
the RFP with the same information.

The current state of the karaf debian package, is:
 1. The package is created using native debian packaging tools

 2. The package is built from the source tarball of karaf releases

 3. The source is built with maven and openjdk-8

 4. lintian no longer gives any warnings on the package (I have only run
lintian with "lintian karaf_xxx.deb", I haven't tried with any
arguments)

 5. The package creates a system user named karaf, with group karaf, and
home directory /var/lib/karaf

 6. A karaf service is added to systemd, running as user karaf and
logging to /var/log/syslog and using the following directories:
 KARAF_ETC = /etc/karaf/
 KARAF_HOME = /usr/share/karaf/
 KARAF_DATA = /var/lib/karaf/data/
all directories are owned by user karaf, group karaf

 7. The karaf package works with "apt-get dist-upgrade", config changes
in KARAF_ETC gets the usual APT dialog on modified config change
(ie. "user the package maintainer's version or the modified file
from the old version?), the karaf cache is flushed during an
upgrade, which means that all installed features are lost and must
be reinstalled, contents in KARAF_ETC not installed by the karaf
package is untouched

 8. Those karaf boot requirements that could be satisfied by current
debian stable (debian 9, stretch) uses debian dependencies:
 - Java 8 RE
 - OSGi core 6
 - libjna-java (not strictly needed, but part of the boot directory)
 - libjansi-java
   - This one can be used as a pattern for how to setup
 startup.properties dependencies, the changes are[2]
 a. Add a debian dependency to the control file
 b. Replace the jansi version number with "debian" in
$KARAF_ETC/startup.properties
 c. Remove jansi from the $KARAF_HOME/system maven repository
 d. Symlink the "debian" version from debian's maven repository
into the $KARAF_HOME/system repository
 
 9. The jar files that make up karaf are structured as a maven
repository under $KARAF_HOME/system

10. The initial boot is done from the jar files found in
$KARAF_HOME/lib/boot/ (I have replaced non-karaf dependencies here
with symlinks to the jar files of debian packages)

11. The jar files needed to boot to a state where karaf can start
downloading dependencies from maven central (or other maven
repositories), are listed in $KARAF_ETC/startup.properties

12. The $KARAF_HOME/system maven repository has been cleaned for files
not built by source that aren't needed for karaf boot.  The
non-karaf jar files currently in there are needed for boot, and
cannot be satisfied by existing debian java packages


I believe the following steps are needed to make this an official
package:
 1. Replace the remaining non-karaf boot jars with debian packages,
these packages are:
a. apache felix framework 5.6.10
   - Already a debian package, but currently in version 4.6.12 in
 stretch, testing and unstable [3]
b. apache felix metatype 1.1.6 [4]
c. apache felix configadmin 1.8.16 [5]
d. apache felix file install 3.6.4 [6]
e. OPS4J PAX URL Aether 2.5.3 [7]
f. OPS4J PAX Logging API 1.10.1 [8]
g. OPS4J PAX Logging Log4J2 1.10.1 [9]
 2. Restructure karaf into two packages, karaf and libkaraf-java, with
libkaraf-java containing the jar files structured like debian java
packages (ie. in /usr/share/maven-repo both with their actual
version and with the "debian" version).
IMO I'm not sure if this is worth the effort, because the karaf jar
files aren't really meaningful outside of karaf, or in a version
independent manner


Thanks in advance to anyone who will create an official debian package,
whether it is based on my package or not! :-)


- Steinar


References:
 [1] 
 [2] 

 [3] 
 [4] 

 [5] 

 [6] 

 [7] 

Bug#881297: An apache karaf debian package made with native debian packaging tools

[Steinar Bang]

I have written a new debian package that
 1. Uses native debian tools to create the package, instead of fpm
 2. Builds from an apache karaf source tarbal instead of from an apache
karaf binary tarball (like the fpm package mentioned earlier in this
issue does)

The new apache karaf debian package is here:
 https://github.com/steinarb/karaf-debian

Other improvements to the fpm package
 1. Simpler maintscripts written from scratch (I inherited the scripts
in the fpm package, from the package I forked on github, and just
modified them as needed)
 2. The new package works with "apt-get dist-upgrade", the fpm package
didn't (the fix was that I needed to remove the old karaf's OSGi
bundle cache during the upgrade)

I followed the plan outlined below and stopped at step 5 (where the
package became usable to me, as a replacement for the fpm package).



Here's the plan I worked after:
 1. Download the sources and build them with maven
 2. Create the directories that will receive the built karaf stuff:
 mkdir -p /etc/karaf
 mkdir -p /usr/share/karaf
 mkdir -p /var/lib/karaf
 3. Move the built stuff in unpacked-src/assemblies/apache-karaf/target/assembly
to the appropriate places the final structure
a. mv unpacked-src/assemblies/apache-karaf/target/assembly/bin to 
/usr/share/karaf
b. mv unpacked-src/assemblies/apache-karaf/target/assembly/data to 
/var/lib/karaf
c. mv unpacked-src/assemblies/apache-karaf/target/assembly/deploy to 
/var/lib/karaf
d. mv unpacked-src/assemblies/apache-karaf/target/assembly/etc/* to 
/etc/karaf
e. mv unpacked-src/assemblies/apache-karaf/target/assembly/lib to 
/usr/share/karaf
f. mv unpacked-src/assemblies/apache-karaf/target/assembly/system to 
/usr/share/karaf
 4. Create a systemd config that sets up the appropriate environment variables 
before 
starting the karaf daemon
  KARAF_BASE=/usr/share/karaf
  KARAF_ETC=/etc/karaf
  KARAF_DATA=/var/lib/karaf/data
 5. Create postinst and postrm scripts that creates/removes a karaf user
(and group) and sets up and removes the systemd daemon
 6. Replace all of the non org.apache.karaf.*.jar needed for boot with
deb dependencies
 7. Move the org.apache.karaf.*.jar part of /usr/share/karaf/system to
/usr/share/maven-repository and use this as the system repo in karaf

Bug#881297: Notes on how karaf starts and what dependencies are needed

[Steinar Bang]

 1. Karaf boots from a small kernel and the rest are pulled in, and
started, using maven.  Maven initially looks to a maven repository
in the karaf distro (the "system" repository), if it doesn't find
what it looks for there, it moves on to maven central and a couple
of other maven repositories (the list of repositores can be modified
at runtime, using commands in the karaf console)

 2. Karaf is started by the karaf script
 
https://github.com/apache/karaf/blob/master/assemblies/features/base/src/main/filtered-resources/resources/bin/karaf

 3. The script uses environment variables that could be set from the
outside (e.g. in a systemd control file or a sysv init script) to
make karaf use other directories:
 KARAF_ETC
 KARAF_DATA
 KARAF_HOME
there used to be a point in setting the KARAF_LOG directory as well
(in my own debian package I had it set to /var/log/karaf in the
4.0.x series of karaf), but logging is now handled by the pax
logging JUL (which I guess is "java.util.logging") handler, and in
debian with openjdk ends up in /var/log/syslog and KARAF_LOG is no
longer used in the karaf script
Suggested values for the environment variables:
 KARAF_HOME=/usr/share/karaf (or maybe /usr/share/java/karaf ?)
  - This is where the scripts should end up
  - The lib subdirectory is where the OSGi runtime finds its jar
files
  - The lib/boot directory is where the OSGi runtime boots from
- Could the jar files here be symlinks to jars installed by
  other debian packages?
  - This is also where the deploy directory is expected to be (the
directory where bundles can be dropped to be installed as
plugins) 
 KARAF_ETC=/etc/karaf
  - This is where the config files are
  - A problem: This directory will be written to and some files
modified on each karaf start/stop. Their md5 sum will not change
unless the config is changed, but their date will be changed
 KARAF_DATA=/var/lib/karaf
  - Will contain the persistent osgi runtime information (cached
bundles and their states)
  - Removing the contents of this directory will return karaf to its
pristine state (so "apt-get purge" should delete it)
  - Will contain the karaf tmp directory

 4. The script boots from a small CLASSPATH consisting of the contents
of the $KARAF_HOME/lib/boot directory
  
https://github.com/apache/karaf/blob/master/assemblies/features/base/src/main/filtered-resources/resources/bin/karaf#L73
The contents of the lib/boot directory of karaf 4.1.4, is:
  -rw-r--r-- 1 sb sb 1440500 Dec 15 20:14 jna-4.5.0.jar
  -rw-r--r-- 1 sb sb 2324986 Dec 15 20:14 jna-platform-4.5.0.jar
  -rw-r--r-- 1 sb sb   31235 Dec 15 20:14 
org.apache.karaf.diagnostic.boot-4.1.4.jar
  -rw-r--r-- 1 sb sb   18181 Dec 15 20:14 
org.apache.karaf.jaas.boot-4.1.4.jar
  -rw-r--r-- 1 sb sb  150582 Dec 15 20:14 org.apache.karaf.main-4.1.4.jar
  -rw-r--r-- 1 sb sb  475256 Dec 15 20:14 org.osgi.core-6.0.0.jar

 5. The script adds a directory containing jar files to the
java.endorsed.dirs system properties
  
https://github.com/apache/karaf/blob/master/assemblies/features/base/src/main/filtered-resources/resources/bin/karaf#L158
  
https://github.com/apache/karaf/blob/master/assemblies/features/base/src/main/filtered-resources/resources/bin/karaf#L297
The contents of the lib/ext/ directory in karaf-4.1.4, is:
-rw-r--r-- 1 sb sb   26366 Dec 15 20:14 javax.annotation-api-1.2.jar
-rw-r--r-- 1 sb sb9598 Dec 15 20:14 
org.apache.karaf.exception-4.1.4.jar
-rw-r--r-- 1 sb sb 2952198 Dec 15 20:14 
org.apache.servicemix.bundles.xalan-2.7.2_3.jar
-rw-r--r-- 1 sb sb  284590 Dec 15 20:14 
org.apache.servicemix.bundles.xalan-serializer-2.7.2_1.jar
-rw-r--r-- 1 sb sb 1400520 Dec 15 20:14 
org.apache.servicemix.bundles.xerces-2.11.0_1.jar
-rw-r--r-- 1 sb sb   65653 Dec 15 20:14 
org.apache.servicemix.specs.activation-api-1.1-2.9.0.jar
-rw-r--r-- 1 sb sb  121045 Dec 15 20:14 
org.apache.servicemix.specs.jaxb-api-2.2-2.9.0.jar
-rw-r--r-- 1 sb sb  261001 Dec 15 20:14 
org.apache.servicemix.specs.jaxp-api-1.4-2.9.0.jar
-rw-r--r-- 1 sb sb   73842 Dec 15 20:14 
org.apache.servicemix.specs.jaxws-api-2.2-2.9.0.jar
-rw-r--r-- 1 sb sb   49355 Dec 15 20:14 
org.apache.servicemix.specs.saaj-api-1.3-2.9.0.jar
-rw-r--r-- 1 sb sb   48782 Dec 15 20:14 
org.apache.servicemix.specs.stax-api-1.2-2.9.0.jar

 6. The script adds a directory to the java.ext.dirs system properties
  
https://github.com/apache/karaf/blob/master/assemblies/features/base/src/main/filtered-resources/resources/bin/karaf#L159
  
https://github.com/apache/karaf/blob/master/assemblies/features/base/src/main/filtered-resources/resources/bin/karaf#L298
The the lib/ext/ directory in karaf-4.1.4, is empty

 7. the $KAR

Bug#881297: An example debian package

[Steinar Bang]

I currently use this self-packaged debian package:
 https://github.com/steinarb/karaf-deb-packaging

This debian package isn't built according to debian java standards so it
isn't immediately useful for a "real" karaf .deb package, but there may
be stuff in the installation scripts that could be borrowed.

I forked my github project from this project
 https://github.com/DemisR/karaf-deb-packaging
and did the following:
 1. Switched from Oracle Java SDK to openjdk
 2. Switched from using the proprietary karaf-wrapper to using the
included init scrips (and later systemd)
 3. Tried using /var/lib/karaf
 4. Updated the karaf version several times


This document describe (in Norwegian, unfortunately), how to build the
.deb package on a debian system and then start karaf (steps 1, 2 and 3),
and then ssh into karaf (step 5), add an extra maven repository (step 6)
and use maven to provision and start a web application (step 7):
 
https://github.com/steinarb/ukelonn#oppsett-av-webappen-på-en-server-med-debian-gnulinux

Bug#881297: Prior discussion about packing apache karaf

[Steinar Bang]

Back in September 2015 there were discussions about packaging karaf, but
it doesn't look like anything happened:
 https://lists.debian.org/debian-java/2015/09/threads.html#00086

Bug#881297: RFP: apache-karaf -- A small OSGi based application server provisioned from maven, and with an integrated SSH server.

[Steinar Bang]

Package: wnpp
Severity: wishlist

* Package name: apache-karaf
  Version : 4.1.3
  Upstream Author : d...@karaf.apache.org
* URL : http://karaf.apache.org/download.html
* License : Apache License v2
  Programming Lang: Java
  Description : A small OSGi based application server provisioned from 
maven, and with an integrated SSH server.

Karaf is a small and fast application server for OSGi based
application.

Karaf is provisioned using maven, so it is possible to start with a
clean karaf installation, log in using SSH to karaf's integrated SSH
server and from its command line, run commands that will pull in an
application and its dependencies.

Karaf is also convenient for development: karaf can be set up to
listen for new builds of SNAPSHOT versions in the local repository.
So this means that all you need to do to make karaf pick up new
versions of the code is run
 mvn install
in the module(s) you want karaf to pick up.

Together with remote debugging from eclipse this makes for easy
development and quick turnaround to try out code changes in the
appserver.

Karaf relies on OPS4J ("the pax stuff", e.g. pax-web, pax-jdbc) to
provide the infrastructure that makes up an application server.

Karaf introduces a concept called "features" that makes it resolve the
runtime dependencies of OSGi applications (runtime dependency
resolution have been the achilles heel of OSGi applications).  Karaf
also has a maven plugin that makes it possible to piggy back the
creation of karaf features when creating OSGi bundles.

Bug#844253: RFP: glsof -- Two graphical frontends to lsof (Filemonitor and Queries)

[Steinar Bang]

Package: wnpp
Severity: wishlist

* Package name: glsof
  Version : 2.4.1
  Upstream Author : Daniele Francesconi 
* URL : http://glsof.sourceforge.net
* License : GPL v3
  Programming Lang: Java
  Description : Two graphical frontends to lsof (Filemonitor and Queries)

Description from home page:

Glsof is two separate utilities (Queries & FileMonitor) to the command
line utility Lsof by Vic Abell.  Both applications are written in
Java.  Another fundamental requirement is the command line Lsof that
has to be installed on your system.  Lsof is supported by most of the
Unix/Linux systems including Mac Os X.

Filemonitor monitors the activity of files, processes and network
connections in ‘real time’ via lsof, returning them in a list.  One of
its main features is the possibility to control a remote system
running it as “client” (included Windows systems) and a separate
“server” on the target system.  More information here.

Queries manages multiple queries for Lsof, returning output in
different tables.  Please note that work on a new version is in
progress at the moment.  More information here.


Comment by issue reporter: The Filemonitor is the important part to package

I needed to look at a long lsof output today, and though "is there a
nice GUI for lsof?", googled and found this, which looks like a nice
and useful tool for a busy system manager or developer.

There was a package request for an earlier version of this program
that was written using C and GTk+ back in 2007, but that issue was
canceled since the program was undergoing a rewrite to Java.

The request to package for the C/GTk+ version of the program, is:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413115

Bug#602781: Is there any progress on packaging flightcrew?

[Steinar Bang]

This ITP is almost two years old now, and there is no package in any of
the archives?

If flightcrew won't be packaged by the current maintainer, perhaps
this bug should be closed?

An RFP from this summer was marked as done, because there already was an
ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678833


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipaez69a@dod.no

Bug#518230: Would be nice to see NBC packaged for debian

[Steinar Bang]

Just took a quick google today to see if anyone have packaged NBC for
debian.  What I found was this one, which I guess is closed.

I would just like to record that there is at least one user for the
package if it's packaged, ie. me. :-)



-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87tyeo34mb@dod.no

Bug#288276: RFP: vex -- a visual XML editor written in Java

[Steinar Bang]

Package: wnpp
Severity: wishlist


* Package name: vex
  Version : 1.1.0
  Upstream Author : Ian Edwards <[EMAIL PROTECTED]>
* URL : http://vex.sourceforge.net/
* License : LGPL
  Description : An XML editor using DTDs and CSS to adapt to XML formats

Vex is an editor for XML documents. The "visual" part comes from the
fact that Vex hides the raw XML tags from the user, providing instead
a wordprocessor-like interface. Because of this, Vex is best suited
for "document-style" XML documents such as XHTML and DocBook rather
than "data-style" XML documents.  It can be both standalone, and a
plugin to the Eclipse IDE.  The debian packaging should support both
modes, as well as making it possible to use it from Java applications.

Bug#272084: RFP: ups -- source level C, C++ and Fortran debugger with an X windows interface

[Steinar Bang]

Package: wnpp
Severity: wishlist


* Package name: ups
  Version : 3.37
  Upstream Author : Ian Edwards <[EMAIL PROTECTED]>
* URL : http://ups.sourceforge.net/
* License : GPL
  Description : source level C, C++ and Fortran debugger with an X windows 
interface

(Include the long description here.)
Ups is a source level C,C++ and Fortran debugger that runs under
X11. Currently supported systems are FreeBSD and GNU/Linux on Intel
x86 and Solaris on SPARC. On these systems it runs native; it is not a
front-end to GNU gdb. An ANSI C interpreter is included; this is built
in to ups to provide conditional debugging and can also be built as a
seperate program.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (990, 'testing'), (90, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.4-1-686
Locale: LANG=C, LC_CTYPE=C

Bug#233298: Corrected URL and version

[Steinar Bang]

  Version : 0.5.1
* URL : http://xml.apache.org/forrest/

Bug#233298: RFP: forrest -- Forrest is an XML standards-oriented project documentation framework based on Apache Cocoon, providing XSLT stylesheets and schemas, images and other resources. Forrest uses these to render the XML source content into a website via command-line, robot, or a dynamic web application.

[Steinar Bang]

Package: wnpp
Severity: wishlist





* Package name: forrest
  Version : x.y.z
  Upstream Author : Name <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : Apache Software License, Version 1.1
  Description : Website creation tool

(Include the long description here.)
Forrest is an XML standards-oriented project documentation framework
based on Apache Cocoon, providing XSLT stylesheets and schemas, images
and other resources. Forrest uses these to render the XML source
content into a website via command-line, robot, or a dynamic web
application.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux doohan 2.4.24-1-686 #1 Tue Jan 6 21:29:44 EST 2004 i686
Locale: LANG=C, LC_CTYPE=C