You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Bennett, Timothy (JIS - Applications)" <Ti...@jis.nashville.org> on 2005/08/25 04:42:25 UTC
kxml.jar
Starting to *think* about mavenizing the felix build. Notice that the framework only has one third-party jar dependency -- kxml.jar.
What version is this? Looks like maybe something from the 1.x series, perhaps 1.2.1? Is there a reason for not using the 2.x series versions?
If we need to continue to use 1.x, do you think the Enhydra folks will contribute a build of kxml to ibiblio, named to kxml-1.2.1.jar?
Re: Adding bundles
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 26 August 2005 05:59, Daniel Fagerstrom wrote:
> It is not that easy for a new user to evaluate which of all
> these blocks that they can rely on. And categorizing and removing blocks
> leads to community friction.
>
> So IMO we should only add a bundle after that we have made sure it has
> real long term community support.
Yes. We should learn from experiences elsewhere in Apache, such as Cocoon and
the commons projects.
But sometimes I am 'confused' that small useful code pieces "that just works"
are often discarded as "not maintained" and "should not be used", which IMHO
instead leads to "re-inventing the wheels" more often than necessary.
The more modular and scaled down a codebase is, the less important it is that
there is a healthy community doing active development on it on a daily basis.
Small codebases have less bugs, and if any users can find a bug quickly, and
if there is a good feedback channel in place, it would not be a problem,
IMVHO.
Now, that said, I would also like to take this opportunity to suggest that we
could instead have "tools" and "infrastructure" to "publish" bundles that are
available from a development point of view from elsewhere. I don't know the
principles behind the Oscar Bundle Repository, but we could work on that
principle and perhaps look into;
* Central discovery of N x OBRs, and/or
* RDF to publish and search for bundles across distributed sets of OBRs
* Meta information to classify bundles along various axis.
and so on...
Bottom line of that; Allow one-man shows "elsewhere", and Felix community
helps such efforts to reach a larger audience. For the users, it means go to
Felix and from there they can search for any bundles, in any market segment,
and over time I think such system of repositories would be an enormous help
compared to the current Google searches.
Cheers
Niclas
Re: Adding bundles
Posted by Enrique Rodriguez <en...@gmail.com>.
Daniel Fagerstrom wrote:
...
> But before we start to add bundles to Felix I think we need to discuss
> what policy we should have for adding bundles. Here are my opinions:
>
> * As it is part of our charter to "implement, document, maintain, and
> support standard OSGi R4 services", we should in most cases accept code
> contributions for standard services as initial code base (as long as the
> legal issues are solved of course). For some services there might be
> several different approaches for the services, in such cases we need of
> course more discussion.
Sounds great. There are a number of smaller OBR repos with a lot to
offer and I hope we hear from more people like Didier who are willing to
raise the visibility of their work.
> * Committers can add whatever bundle they want to their sandbox.
This is very cool. Without accountability, the sandbox rapidly becomes
a litterbox.
> * Now we come to the complicated part: non standard bundles. One of the
> cool things with our project is that we have the goal to "provide a
> focal point for the open-source OSGi community to develop next
> generation enhancements to the core framework and act as a conduit for
> the open-source community to the OSGi Alliance". Fullfilling that
> requires IMO some focus, we should not let our project become a dumping
> ground for various half baked ideas and one man shows.
I'd like to provide some commentary, namely what we were thinking when
writing the proposal regarding #3 ("common needs not fully specified")
vs. #4 ("next generation enhancements"). Of course, I look forward to
Felix taking on a life of its own so this may largely be personal opinion.
As you note, #4 results in non-standard bundles. Really, with #4, "next
generation enhancements," we were thinking about how the Service Binder
went on to become Declarative Services. In other words, "next
generation" meant modularity and classloading ... deeper stuff.
But, I'd like to draw some attention to #3 as I believe that is where
some of the most useful bundles will come from. By "interfaces, APIs,
and other common needs not fully specified" we had in mind:
1) "store interfaces" - services such as UserAdmin, ConfigAdmin, and
PrefsAdmin did not define store interfaces. With store interfaces
defined, we could provide bundles for directory (JNDI), JDBC, or object
store (db4o, Prevayler) backends. Existing implementations either
provide no persistence or a simple file store. I believe the lack of
store options is holding back their wider usage.
2) "aspects of the runtime container's packaging" - really this means
daemons and installers (GUI, RPM) for Windows and Linux. We should be
able to provide these as features for Felix users at Apache and
elsewhere to re-use for their projects.
3) "bundle repositories" - OBR and related ideas, such as standardizing
repo formats with Maven and maybe even Eclipse update sites.
OK, I hope that helped. Looking back at the proposal I wouldn't be
surprised if it wasn't clear. Opps.
> IMO a non standard bundle should only be accepted if it is a community
> effort, i.e. if a couple of community members takes part in discussions,
> design and implementation. We should also have vote about accepting the
> bundle.
Makes sense.
> The above might sound somewhat harsh but we have some rather bad
> experience from the Cocoon project on letting people add modules
> (blocks) whenever they feel like. After a number of years we have the
> following situation: http://svn.apache.org/repos/asf/cocoon/blocks/.
> Around 50 blocks of which only a handfull are actively maintained by the
> community. It is not that easy for a new user to evaluate which of all
> these blocks that they can rely on. And categorizing and removing blocks
> leads to community friction.
>
> So IMO we should only add a bundle after that we have made sure it has
> real long term community support.
>
> What do you think?
>
> /Daniel
>
Adding bundles
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Was: Re: kxml.jar
Didier Donsez wrote:
> Daniel Fagerstrom a écrit :
>> Didier Donsez wrote:
<snip/>
>>> http://www-adele.imag.fr/~donsez/dev/osgi/metadataparser/readme.html
>>> and for the demo
>>> http://www-adele.imag.fr/~donsez/dev/osgi/metadataparsertest/readme.html
>>>
>>> This bundle could join the Felix code base.
>> How is it related to the metatype service?
>>
> No relationship.
> But I used the MetadataParser to quickly implement a simple Metatype
> service.
> The MetadataParser parses the XML document associated to the service.
> http://www-adele.imag.fr/~donsez/dev/osgi/metatype/readme.html
If your Metatype service is part of the offering ;) I think it would
make a good addition to Felix.
--- o0o ---
But before we start to add bundles to Felix I think we need to discuss
what policy we should have for adding bundles. Here are my opinions:
* As it is part of our charter to "implement, document, maintain, and
support standard OSGi R4 services", we should in most cases accept code
contributions for standard services as initial code base (as long as the
legal issues are solved of course). For some services there might be
several different approaches for the services, in such cases we need of
course more discussion.
* Committers can add whatever bundle they want to their sandbox.
* Now we come to the complicated part: non standard bundles. One of the
cool things with our project is that we have the goal to "provide a
focal point for the open-source OSGi community to develop next
generation enhancements to the core framework and act as a conduit for
the open-source community to the OSGi Alliance". Fullfilling that
requires IMO some focus, we should not let our project become a dumping
ground for various half baked ideas and one man shows.
IMO a non standard bundle should only be accepted if it is a community
effort, i.e. if a couple of community members takes part in discussions,
design and implementation. We should also have vote about accepting the
bundle.
The above might sound somewhat harsh but we have some rather bad
experience from the Cocoon project on letting people add modules
(blocks) whenever they feel like. After a number of years we have the
following situation: http://svn.apache.org/repos/asf/cocoon/blocks/.
Around 50 blocks of which only a handfull are actively maintained by the
community. It is not that easy for a new user to evaluate which of all
these blocks that they can rely on. And categorizing and removing blocks
leads to community friction.
So IMO we should only add a bundle after that we have made sure it has
real long term community support.
What do you think?
/Daniel
Re: kxml.jar
Posted by Didier Donsez <di...@imag.fr>.
Daniel Fagerstrom a écrit :
> Didier Donsez wrote:
>
>> Bennett, Timothy (JIS - Applications) a écrit :
>>
>>> Starting to *think* about mavenizing the felix build. Notice that
>>> the framework only has one third-party jar dependency -- kxml.jar.
>>>
>>> What version is this? Looks like maybe something from the 1.x
>>> series, perhaps 1.2.1? Is there a reason for not using the 2.x
>>> series versions?
>>
>>
> It seem like 2.x not is back compatible with 1.x. As 1.x is deprecated
> (http://kxml.sourceforge.net/about.shtml) we should probably try to
> move away from it. I have not read the framework code so I don't know
> how kxml is used. Anyway, kxml is AFACS a pull parser, if there are
> resons for continue using pull parsers, using a StAX parser is
> probably the safest bet. kxml 2.x is based on xmlpull.
>
I have no opinion on that
>>> If we need to continue to use 1.x, do you think the Enhydra folks
>>> will contribute a build of kxml to ibiblio, named to kxml-1.2.1.jar?
>>
>>
>> The kxml.jar is embedded in the ServiceBinder and in the
>> BundleRepositoryService (OBR).
>> The kxml.jar could be substituted by a standard JAXP SAX Parser.
>> This is the case in the latest version of MetadataParser bundle. The
>> previous version was integrated by Rick in the
>> BundleRepositoryService sources.
>>
>> http://www-adele.imag.fr/~donsez/dev/osgi/metadataparser/readme.html
>> and for the demo
>> http://www-adele.imag.fr/~donsez/dev/osgi/metadataparsertest/readme.html
>>
>> This bundle could join the Felix code base.
>
>
> How is it related to the metatype service?
>
No relationship.
But I used the MetadataParser to quickly implement a simple Metatype
service.
The MetadataParser parses the XML document associated to the service.
http://www-adele.imag.fr/~donsez/dev/osgi/metatype/readme.html
> /Daniel
>
--
---------------------------------------------------------
Didier DONSEZ
Laboratoire LSR, Institut Imag, Universite Joseph Fourier
Bat. C, 220 rue de la Chimie, Domaine Universitaire
BP 53, 38041 Grenoble Cedex 9, France
GPS : lat 45°11'38.3"N, lon 05°46'14.7"E, alt 223m
Tel : +33 4 76 63 55 49 Fax : +33 4 76 63 55 50
mailto:Didier.Donsez@imag.fr
URL: http://www-adele.imag.fr/~donsez
---------------------------------------------------------
Re: kxml.jar
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Didier Donsez wrote:
> Bennett, Timothy (JIS - Applications) a écrit :
>
>> Starting to *think* about mavenizing the felix build. Notice that
>> the framework only has one third-party jar dependency -- kxml.jar.
>>
>> What version is this? Looks like maybe something from the 1.x
>> series, perhaps 1.2.1? Is there a reason for not using the 2.x
>> series versions?
>
It seem like 2.x not is back compatible with 1.x. As 1.x is deprecated
(http://kxml.sourceforge.net/about.shtml) we should probably try to move
away from it. I have not read the framework code so I don't know how
kxml is used. Anyway, kxml is AFACS a pull parser, if there are resons
for continue using pull parsers, using a StAX parser is probably the
safest bet. kxml 2.x is based on xmlpull.
>> If we need to continue to use 1.x, do you think the Enhydra folks
>> will contribute a build of kxml to ibiblio, named to kxml-1.2.1.jar?
>
> The kxml.jar is embedded in the ServiceBinder and in the
> BundleRepositoryService (OBR).
> The kxml.jar could be substituted by a standard JAXP SAX Parser.
> This is the case in the latest version of MetadataParser bundle. The
> previous version was integrated by Rick in the BundleRepositoryService
> sources.
>
> http://www-adele.imag.fr/~donsez/dev/osgi/metadataparser/readme.html
> and for the demo
> http://www-adele.imag.fr/~donsez/dev/osgi/metadataparsertest/readme.html
>
> This bundle could join the Felix code base.
How is it related to the metatype service?
/Daniel
Re: kxml.jar
Posted by Didier Donsez <di...@imag.fr>.
Bennett, Timothy (JIS - Applications) a écrit :
>Starting to *think* about mavenizing the felix build. Notice that the framework only has one third-party jar dependency -- kxml.jar.
>
>What version is this? Looks like maybe something from the 1.x series, perhaps 1.2.1? Is there a reason for not using the 2.x series versions?
>
>If we need to continue to use 1.x, do you think the Enhydra folks will contribute a build of kxml to ibiblio, named to kxml-1.2.1.jar?
>
>
>
The kxml.jar is embedded in the ServiceBinder and in the
BundleRepositoryService (OBR).
The kxml.jar could be substituted by a standard JAXP SAX Parser.
This is the case in the latest version of MetadataParser bundle. The
previous version was integrated by Rick in the BundleRepositoryService
sources.
http://www-adele.imag.fr/~donsez/dev/osgi/metadataparser/readme.html
and for the demo
http://www-adele.imag.fr/~donsez/dev/osgi/metadataparsertest/readme.html
This bundle could join the Felix code base.
Didier
PS : the MetadataParser bundle do not use the XML Parser Service defined
in the OSGI R3 spec (I can't remember the chapter number, Peter ?)
Remark: the impact is very light
// 2) create a metadata handler
// * KXmlMetadataHandler for kXML parser (light XML parser)
// * XmlMetadataHandler for SAX compliant parser (JAXP, Xerces, ...)
KXmlMetadataHandler handler=new KXmlMetadataHandler();
// SaxMetadataHandler handler=new SaxMetadataHandler();
--
---------------------------------------------------------
Didier DONSEZ
Laboratoire LSR, Institut Imag, Universite Joseph Fourier
Bat. C, 220 rue de la Chimie, Domaine Universitaire
BP 53, 38041 Grenoble Cedex 9, France
GPS : lat 45°11'38.3"N, lon 05°46'14.7"E, alt 223m
Tel : +33 4 76 63 55 49 Fax : +33 4 76 63 55 50
mailto:Didier.Donsez@imag.fr
URL: http://www-adele.imag.fr/~donsez
---------------------------------------------------------
Re: kxml.jar
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 25 August 2005 10:42, Bennett, Timothy (JIS - Applications) wrote:
> What version is this? Looks like maybe something from the 1.x series,
> perhaps 1.2.1? Is there a reason for not using the 2.x series versions?
>
> If we need to continue to use 1.x, do you think the Enhydra folks will
> contribute a build of kxml to ibiblio, named to kxml-1.2.1.jar?
I used to be on that mailing list for >1year and I think the total traffic was
~8 messages, half of that from me. Perhaps kxml has been resurrected since
then, but it was considered a "completed" project.
Cheers
Niclas
Re: kxml.jar
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On 8/24/2005 7:42 PM, Bennett, Timothy (JIS - Applications) wrote:
>Starting to *think* about mavenizing the felix build.
>
>
Maven 2 is going be released real soon. Are you going to use that?
Regards,
Alan
Re: kxml.jar
Posted by Jeff McAffer <Je...@ca.ibm.com>.
For JRE requirements specification you might be interested in looking at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=98798
Jeff
Niclas Hedhman <ni...@hedhman.org>
08/26/2005 04:44 AM
Please respond to
oscar-dev
To
oscar-dev@incubator.apache.org
cc
Subject
Re: kxml.jar
On Friday 26 August 2005 06:19, Richard S. Hall wrote:
> If someone is willing to discuss this with me and do some simple XML
> coding, then we can either move toward kxml 2.x or to something else
> altogether if they know a better way.
I have used Aelfred in the past for light-weight (relative) namespace
capable
parsing, but I think it requires JDK1.2.
Question is what is the JDK requirement for OBR??
In fact, how are we dealing with the JDK versioning issue across each of
the
bundles???
Cheers
Niclas
Re: kxml.jar
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 26 August 2005 06:19, Richard S. Hall wrote:
> If someone is willing to discuss this with me and do some simple XML
> coding, then we can either move toward kxml 2.x or to something else
> altogether if they know a better way.
I have used Aelfred in the past for light-weight (relative) namespace capable
parsing, but I think it requires JDK1.2.
Question is what is the JDK requirement for OBR??
In fact, how are we dealing with the JDK versioning issue across each of the
bundles???
Cheers
Niclas
Re: mavenization
Posted by Brett Porter <br...@gmail.com>.
Thanks. I know what you are talking about now.
I should probably clarify this then having spoken to him:
- this was mostly a gut feeling as it wasn't comprehensive
- it was only across the ASF and for all projects (not just Java)
Cheers,
Brett
On 8/27/05, Noel J. Bergman <no...@devtech.com> wrote:
> > Do you have a reference for this? Interesting.
>
> Ask Hen. He's the one who did the looking.
>
> --- Noel
>
>
RE: mavenization
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Do you have a reference for this? Interesting.
Ask Hen. He's the one who did the looking.
--- Noel
Re: mavenization
Posted by Brett Porter <br...@gmail.com>.
Hi Noel,
Do you have a reference for this? Interesting.
Anyway, I agree with the above point. It doesn't need to be an
either/or. Maven will generate a pretty decent ant build file for
compiling/testing/packaging and it isn't too onerous to use it for the
less frequent tasks. Of course, anyone that wants to use Ant is
welcome to maintain the build file too - there's no reason both can't
be there.
- Brett
On 8/27/05, Noel J. Bergman <no...@devtech.com> wrote:
> Martijn Dashorst wrote:
>
> > distribution is maven agnostic, though: we give the source,
> > the dependencies in a lib folder and a working ant build.xml
> > for people to use in the distribution
>
> Good to hear. Not everyone wants to use Maven. Someone recently did a
> check and found that less than 15% of the Java projects use it. The rest
> (85%+) all use Ant.
>
> --- Noel
>
>
Re: kxml.jar
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Martijn Dashorst wrote:
> If more people are -1 on M2 before it is final, I'd suggest using
> M1.0.2 (M1.1 is also still beta).
I don't see the point of switching to M1, only to switch to M2 later. I
have an Ant build file that works fine for the framework, so it seems
okay to keep that until M2 is closer to being ready. (Keep in mind that
I am only talking about the framework, not the build process for
everything else.) Things seem to be pretty fluid right now, so I would
rather let things settle down.
> Our distribution is maven agnostic, though: we give the source, the
> dependencies in a lib folder and a working ant build.xml for people to
> use in the distribution, and we also supply the maven files. This way
> we cater both worlds in the best possible way we can.
This is exactly what I was thinking we would do for framework releases.
Sounds great.
-> richard
Re: mavenization
Posted by "Noel J. Bergman" <no...@devtech.com>.
Martijn Dashorst wrote:
> distribution is maven agnostic, though: we give the source,
> the dependencies in a lib folder and a working ant build.xml
> for people to use in the distribution
Good to hear. Not everyone wants to use Maven. Someone recently did a
check and found that less than 15% of the Java projects use it. The rest
(85%+) all use Ant.
--- Noel
Re: kxml.jar
Posted by Martijn Dashorst <ma...@dashorst.dds.nl>.
Noel J. Bergman wrote:
>>I am not against using Maven, but I figured we would
>>wait for an official Maven 2 release.
>>
>>
>In lieu of Ant, or as an alternative for those who want to use Maven?
>
>
Development of the maven-osgi plugin, or maven-felix plugin can just
continue. And from what I've heard is that the maven team suggests that
the M2 current release is pretty solid and can be used by other projects.
I haven't found the time yet to tranform the Wicket project to m2, but
I'm anxious to get it going.
If more people are -1 on M2 before it is final, I'd suggest using M1.0.2
(M1.1 is also still beta).
On the ant vs maven topic: the Wicket team uses maven for the internal
builds, and when someone gets the source from CVS, that is all we
support. Our distribution is maven agnostic, though: we give the source,
the dependencies in a lib folder and a working ant build.xml for people
to use in the distribution, and we also supply the maven files. This way
we cater both worlds in the best possible way we can. Our CVS isn't
'poluted' with jar files, and our users have a full distribution,
keeping the Hani's of this world happy :-)
Martijn
RE: kxml.jar
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I am not against using Maven, but I figured we would
> wait for an official Maven 2 release.
In lieu of Ant, or as an alternative for those who want to use Maven?
--- Noel
Re: kxml.jar
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Bennett, Timothy (JIS - Applications) wrote:
>Starting to *think* about mavenizing the felix build. Notice that the framework only has one third-party jar dependency -- kxml.jar.
>
>
I am not against using Maven, but I figured we would wait for an
official Maven 2 release.
>What version is this? Looks like maybe something from the 1.x series, perhaps 1.2.1? Is there a reason for not using the 2.x series versions?
>
>If we need to continue to use 1.x, do you think the Enhydra folks will contribute a build of kxml to ibiblio, named to kxml-1.2.1.jar?
>
kxml.jar is not used by the framework at all. It is used by the OBR
bundle repository bundle. In truth, I would like someone to show me the
better way to do what I am doing there. All I really want is a
lightweight way to parse the repository XML file and get the data into
Java object collection of some sort.
If someone is willing to discuss this with me and do some simple XML
coding, then we can either move toward kxml 2.x or to something else
altogether if they know a better way.
-> richard