subject:"Re\: \[dom4j\-dev\] dom4j extensions"

Re: [dom4j-dev] dom4j extensions

2008-11-06 Thread Mike Skells

Surely if there are 10 definitions for a given prefix and 10 prefix definitions 
for a given namespace and they are all different then that woul be a problem 
wouldnt it.

Not really. For an xpath you could use each of them. The point for me is to 
have the chance to have all namespaces with prefixes that could be needed by an 
xpath for the given document (or branch). And in most cases you have only the 
ones from your document and this will be better as for example use all 
namespaces from the namespace cache wich means the namespaces from all 
documents that where created since the vm start (and this will result in many 
problems with doubled prefixes).

>From a functional perspective you may be right, but does the XPATh operation 
>run against the namespace or the prefix. I though that the prefix was what was 
>required in XPAth 2. I know thatthe declaration was against the prefix, but 
>the operatio run against the namespace. I amy be mistaken it is a while since 
>I looked at it.


assuming that you can cope with overlaps, are you proposing to try each 
combination and see think ones work. That could be a lot of options

x:n1/x:n2/x:n3/x:n4 would take 1 options if x has 10 mapping would it not.

Regards
Mike Skells
Chief Solutions Architect
ValidSoft Ltd
F: +44 (0) 20 7033 1965
M: +44 (0) 7740 520 717
[EMAIL PROTECTED]
www.validsoft.com
ValidSoft Ltd is a Private Limited Company.
Registered Address:Castle Buildings, Tara Street, Tullamore, Co. Offaly, 
Ireland.
Registration Number: 377068 Registered in Dublin.
The information in this e-mail is confidential and may be legally privileged. 
It is intended solely for the addressee(s).  Access to this e-mail by anyone 
else is unauthorised. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in reliance on 
it, is prohibited and may be unlawful. When addressed to our clients any 
opinions or advice contained in this e-mail are subject to the terms and 
conditions expressed in the governing ValidSoft client terms and conditions.

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
dom4j-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dom4j-dev

Re: [dom4j-dev] dom4j extensions

2008-11-06 Thread Marc Pellmann

Hi Mike!

> So how does this cope with structural chnages. An Element and all of
> the children may be added in a single rearrangement, an element may
> not have a document when it is being built., and the document may be
> chnaged after the element is added, or many other different ways to
> disturb the structure.

I agree that this could happen if branches would be build without
documents or branches from other documents would be added. But I think
there are different scopes of use. And if you want to use full
namespaces support for XPathes you need to build your document in order.
In addition you always have the chance to add namespaces by yourself to
the context if you do some special operations.

If we want to support all cases of structure changes and removes it will
be really costly. I think this would be overdone.

> Surely if there are 10 definitions for a given prefix and 10 prefix
> definitions for a given namespace and they are all different then that
> woul be a problem wouldnt it.

Not really. For an xpath you could use each of them. The point for me is
to have the chance to have all namespaces with prefixes that could be
needed by an xpath for the given document (or branch). And in most cases
you have only the ones from your document and this will be better as for
example use all namespaces from the namespace cache wich means the
namespaces from all documents that where created since the vm start (and
this will result in many problems with doubled prefixes).

-- 
Viele Grüße / best regards

Marc Pellmann (Software Architect)

inubit - integrating your business and IT
inubit AG
Schöneberger Ufer 89-91
D-10785 Berlin
Fon: +49.30. 72 61 12-132
Fax: +49.30. 72 61 12-100
Freecall: 0800-go inubit
Web: www.inubit.com

Vorstand: Dr. Torsten Schmale
Vorsitzender des Aufsichtsrates: Dr. Wolf-Dieter Klemt
Registergericht: AG Charlottenburg
Registernummer: HRB 80154
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
dom4j-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dom4j-dev

Re: [dom4j-dev] dom4j extensions

2008-11-06 Thread Mike Skells

Hi Marc,

Scanning the document in this case is not an option, and as namespaces may be 
removed, and content shared within the document, maintaining a map of usage is 
not trivial in code, CPU or memory.

I do not want to scan the document to build the list of namespaces. The 
add(Namespace) method of AbstractElement could add each new namespace to the 
specific new XPathNamespaces object which is declared at the document (in my 
addition).
So how does this cope with structural chnages. An Element and all of the 
children may be added in a single rearrangement, an element may not have a 
document when it is being built., and the document may be chnaged after the 
element is added, or many other different ways to disturb the structure.

What is needed is a NamespaceContext (but at best not only for jaxen, but that 
is an other point) which holds all namespaces that are declared in the 
document. And what is needed is code to collect this namespaces in creation of 
the document.

Agreed the curren one is tied to Jaxen, and a pluuggable XPath would be a huge 
improvement
The Problem with only add namespaces to the document with add(Namespaces) is in 
adding of branches. To solve this there might be
1) a more complex strategy to hold namespace declarations for each branch
As I am sure youwould agree this would be costly

2) retrieval of all namespaces from the branch while adding

As I am sure youwould agree this would also be costly
3) add all namespaces of the document of the branch (if it comes from an other 
document), because more namespaces than needed should not be a problem

For me point 3 would be enough.

Surely if there are 10 definitions for a given prefix and 10 prefix definitions 
for a given namespace and they are all different then that woul be a problem 
wouldnt it. Dont you have to determine the appropriate namespace mapping and 
the point of evaluation. How do you determine to correct mapping in context

see AbstractElement.getNamespaceForPrefix, and 
DefaultElement.getNamespaceForPrefix

I do not see how this could help?
I was just pointing you to the code that trewalks currently

Regards
Mike Skells
Chief Solutions Architect
ValidSoft Ltd
F: +44 (0) 20 7033 1965
M: +44 (0) 7740 520 717
[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>
<http://www.validsoft.com/>www.validsoft.com<http://www.validsoft.com/>
ValidSoft Ltd is a Private Limited Company.
Registered Address:Castle Buildings, Tara Street, Tullamore, Co. Offaly, 
Ireland.
Registration Number: 377068 Registered in Dublin.
The information in this e-mail is confidential and may be legally privileged. 
It is intended solely for the addressee(s).  Access to this e-mail by anyone 
else is unauthorised. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in reliance on 
it, is prohibited and may be unlawful. When addressed to our clients any 
opinions or advice contained in this e-mail are subject to the terms and 
conditions expressed in the governing ValidSoft client terms and conditions.




From: Marc Pellmann [mailto:[EMAIL PROTECTED]
Sent: 06 November 2008 09:51
To: Mike Skells
Cc: [EMAIL PROTECTED]; [email protected]
Subject: Re: [dom4j-dev] dom4j extensions

Hi Mike!

Scanning the document in this case is not an option, and as namespaces may be 
removed, and content shared within the document, maintaining a map of usage is 
not trivial in code, CPU or memory.

I do not want to scan the document to build the list of namespaces. The 
add(Namespace) method of AbstractElement could add each new namespace to the 
specific new XPathNamespaces object which is declared at the document (in my 
addition).

I would suggest that any code that determines namespace could use a namespace 
resolution strategy that is appropriate for its needs, and this should be able 
to be defaulted without code.
This is what the DefaultNamespaceContext does, albeit without strategy options, 
but any progreammer can withthe 1.6.1 implementation provide a different 
namespace context, appropriate for their needs, and what you are proposing is 
such an alternative I believe

What is needed is a NamespaceContext (but at best not only for jaxen, but that 
is an other point) which holds all namespaces that are declared in the 
document. And what is needed is code to collect this namespaces in creation of 
the document.

The Problem with only add namespaces to the document with add(Namespaces) is in 
adding of branches. To solve this there might be
1) a more complex strategy to hold namespace declarations for each branch
2) retrieval of all namespaces from the branch while adding
3) add all namespaces of the document of the branch (if it comes from an other 
document), because more namespaces than needed should not be a problem

For me point 3 would be enough.

see AbstractElement.getNamespaceForPrefix, and 
DefaultElement.getNamespaceForPr

Re: [dom4j-dev] dom4j extensions

2008-11-06 Thread Marc Pellmann

Hi Mike!

> Scanning the document in this case is not an option, and as namespaces
> may be removed, and content shared within the document, maintaining a
> map of usage is not trivial in code, CPU or memory.

I do not want to scan the document to build the list of namespaces. The
add(Namespace) method of AbstractElement could add each new namespace to
the specific new XPathNamespaces object which is declared at the
document (in my addition).

> I would suggest that any code that determines namespace could use a
> namespace resolution strategy that is appropriate for its needs, and
> this should be able to be defaulted without code.
> This is what the DefaultNamespaceContext does, albeit without strategy
> options, but any progreammer can withthe 1.6.1 implementation provide
> a different namespace context, appropriate for their needs, and what
> you are proposing is such an alternative I believe

What is needed is a NamespaceContext (but at best not only for jaxen,
but that is an other point) which holds all namespaces that are declared
in the document. And what is needed is code to collect this namespaces
in creation of the document.

The Problem with only add namespaces to the document with
add(Namespaces) is in adding of branches. To solve this there might be
1) a more complex strategy to hold namespace declarations for each branch
2) retrieval of all namespaces from the branch while adding
3) add all namespaces of the document of the branch (if it comes from an
other document), because more namespaces than needed should not be a
problem

For me point 3 would be enough.

> see AbstractElement.getNamespaceForPrefix, and
> DefaultElement.getNamespaceForPrefix

I do not see how this could help?


-- 
Viele Grüße / best regards

Marc Pellmann (Software Architect)

inubit - integrating your business and IT
inubit AG
Schöneberger Ufer 89-91
D-10785 Berlin
Fon: +49.30. 72 61 12-132
Fax: +49.30. 72 61 12-100
Freecall: 0800-go inubit
Web: www.inubit.com

Vorstand: Dr. Torsten Schmale
Vorsitzender des Aufsichtsrates: Dr. Wolf-Dieter Klemt
Registergericht: AG Charlottenburg
Registernummer: HRB 80154
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
dom4j-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dom4j-dev

Re: [dom4j-dev] dom4j extensions

2008-11-06 Thread Mike Skells

Hi Mark,
I agree that the implementation does not cope with all of the complexities of 
possible naming patterns that may be employed, but I would be interested to 
understand how you expect to maintain the list of namespaces.

I regularly handle files of 10M to 100Mb, and modify these documents based on 
XPath based rules.

Scanning the document in this case is not an option, and as namespaces may be 
removed, and content shared within the document, maintaining a map of usage is 
not trivial in code, CPU or memory.

I would suggest that any code that determines namespace could use a namespace 
resolution strategy that is appropriate for its needs, and this should be able 
to be defaulted without code.
This is what the DefaultNamespaceContext does, albeit without strategy options, 
but any progreammer can withthe 1.6.1 implementation provide a different 
namespace context, appropriate for their needs, and what you are proposing is 
such an alternative I believe


The code for retrieval  is in 1.6.1
see AbstractElement.getNamespaceForPrefix, and 
DefaultElement.getNamespaceForPrefix

Also NamespaceStack.

The mechanism for retrieveal is I believe linked in with the Jaxen namespace 
resolution techniques, as can be seen by an inspection of 
DefaultNamespaceContext.

Regards
Mike Skells
Chief Solutions Architect
ValidSoft Ltd
F: +44 (0) 20 7033 1965
M: +44 (0) 7740 520 717
[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>
<http://www.validsoft.com/>www.validsoft.com<http://www.validsoft.com/>
ValidSoft Ltd is a Private Limited Company.
Registered Address:Castle Buildings, Tara Street, Tullamore, Co. Offaly, 
Ireland.
Registration Number: 377068 Registered in Dublin.
The information in this e-mail is confidential and may be legally privileged. 
It is intended solely for the addressee(s).  Access to this e-mail by anyone 
else is unauthorised. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in reliance on 
it, is prohibited and may be unlawful. When addressed to our clients any 
opinions or advice contained in this e-mail are subject to the terms and 
conditions expressed in the governing ValidSoft client terms and conditions.




From: Marc Pellmann [mailto:[EMAIL PROTECTED]
Sent: 06 November 2008 08:44
To: Mike Skells
Cc: [EMAIL PROTECTED]; [email protected]
Subject: Re: [dom4j-dev] dom4j extensions

Hi!

In older version (1.6 etc) a namespace context was created by walking the 
element hierarchy and picking the namespaces that were defined in the element 
that is the context of the xpath statement

I do not see this in 1.6.1 but I think it would not be enough if it is there. 
The xpath expression could be of any complexity and could try to select nodes 
in all other branches of the document and in deeper of the actual with own 
namespace declarations, too. And this branches have other namespace 
declarations and maybe the prefixes would be the same with other URIs or there 
are default namespaces without prefixes, that need to be changed (added with 
prefix).

There is no method to get all namespaces that are defined in the document. So 
this is what I have added. In many cases it would be enough to add namespaces 
unchanged to the xpath expression. But in the situations above it is needed to 
change prefixes of some namespace definitions that should be added to the 
context and this is done, too. The xpath need to use this new prefixes - there 
is no code in the moment to automatically change some pathes, because this 
might be extreme complex. Again the xpath could be of any complexity.

As an example try come xpathes with this xml:

http://zvon.org/xnumber";<http://zvon.org/xnumber> 
xmlns:lower="http://zvon.org/lowercase";<http://zvon.org/lowercase> ooo="222">
  
http://zvon.org/uppercase";<http://zvon.org/uppercase>>
  
  http://zvon.org/xnumber";<http://zvon.org/xnumber>>

  


  
  http://zvon.org/uppercase";<http://zvon.org/uppercase>>
http://zvon.org/uppercase";<http://zvon.org/uppercase> 
upper:U="A" U="A" lower:U="A">
  
  http://zvon.org/lowercase";<http://zvon.org/lowercase>>
http://zvon.org/uppercase";<http://zvon.org/uppercase> 
xmlns="http://zvon.org/xnumber";<http://zvon.org/xnumber>>
  


  


--
Viele Grüße / best regards

Marc Pellmann (Software Architect)

inubit - integrating your business and IT
inubit AG
Schöneberger Ufer 89-91
D-10785 Berlin
Fon: +49.30. 72 61 12-132
Fax: +49.30. 72 61 12-100
Freecall: 0800-go inubit
Web: www.inubit.com<http://www.inubit.com>

Vorstand: Dr. Torsten Schmale
Vorsitzender des Aufsichtsrates: Dr. Wolf-Dieter Klemt
Registergericht: AG Charlottenburg
Registernummer: HRB 80154
---

Re: [dom4j-dev] dom4j extensions

2008-11-06 Thread Marc Pellmann

Hi!

> In older version (1.6 etc) a namespace context was created by walking
> the element hierarchy and picking the namespaces that were defined in
> the element that is the context of the xpath statement

I do not see this in 1.6.1 but I think it would not be enough if it is
there. The xpath expression could be of any complexity and could try to
select nodes in all other branches of the document and in deeper of the
actual with own namespace declarations, too. And this branches have
other namespace declarations and maybe the prefixes would be the same
with other URIs or there are default namespaces without prefixes, that
need to be changed (added with prefix).

There is no method to get all namespaces that are defined in the
document. So this is what I have added. In many cases it would be enough
to add namespaces unchanged to the xpath expression. But in the
situations above it is needed to change prefixes of some namespace
definitions that should be added to the context and this is done, too.
The xpath need to use this new prefixes - there is no code in the moment
to automatically change some pathes, because this might be extreme
complex. Again the xpath could be of any complexity.

As an example try come xpathes with this xml:

http://zvon.org/xnumber";
xmlns:lower="http://zvon.org/lowercase"; ooo="222">
  
http://zvon.org/uppercase";>
  
  http://zvon.org/xnumber";>

  


  
  http://zvon.org/uppercase";>
http://zvon.org/uppercase"; upper:U="A" U="A"
lower:U="A">
  
  http://zvon.org/lowercase";>
http://zvon.org/uppercase";
xmlns="http://zvon.org/xnumber";>
  


  


-- 
Viele Grüße / best regards

Marc Pellmann (Software Architect)

inubit - integrating your business and IT
inubit AG
Schöneberger Ufer 89-91
D-10785 Berlin
Fon: +49.30. 72 61 12-132
Fax: +49.30. 72 61 12-100
Freecall: 0800-go inubit
Web: www.inubit.com

Vorstand: Dr. Torsten Schmale
Vorsitzender des Aufsichtsrates: Dr. Wolf-Dieter Klemt
Registergericht: AG Charlottenburg
Registernummer: HRB 80154
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
dom4j-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dom4j-dev

Re: [dom4j-dev] dom4j extensions

2008-11-05 Thread Mike Skells

Hi,
In older version (1.6 etc) a namespace context was created by walking the 
element hierarchy and picking the namespaces that were defined in the element 
that is the context of the xpath statement


so if you did X.selectSingleNode("some/path)
then all of the namespaces that were defined in X or any of it parents would be 
passed to jaxen.

I ahave no knowledge ofthe 2 build line

Regards
Mike Skells
Chief Solutions Architect
ValidSoft Ltd
F: +44 (0) 20 7033 1965
M: +44 (0) 7740 520 717
[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>
<http://www.validsoft.com/>www.validsoft.com<http://www.validsoft.com/>
ValidSoft Ltd is a Private Limited Company.
Registered Address:Castle Buildings, Tara Street, Tullamore, Co. Offaly, 
Ireland.
Registration Number: 377068 Registered in Dublin.
The information in this e-mail is confidential and may be legally privileged. 
It is intended solely for the addressee(s).  Access to this e-mail by anyone 
else is unauthorised. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in reliance on 
it, is prohibited and may be unlawful. When addressed to our clients any 
opinions or advice contained in this e-mail are subject to the terms and 
conditions expressed in the governing ValidSoft client terms and conditions.




From: Marc Pellmann [mailto:[EMAIL PROTECTED]
Sent: 05 November 2008 14:59
To: Mike Skells
Cc: [EMAIL PROTECTED]; [email protected]
Subject: Re: [dom4j-dev] dom4j extensions

Hi Mike!

I believe from memory that the existing codebase does (2) already, albeit for 
Jaxen only

I have checked out version 2 from the mercurial now, but I do not see this!? 
Which changes do you mean in detail?

--
Viele Grüße / best regards

Marc Pellmann (Software Architect)

inubit - integrating your business and IT
inubit AG
Schöneberger Ufer 89-91
D-10785 Berlin
Fon: +49.30. 72 61 12-132
Fax: +49.30. 72 61 12-100
Freecall: 0800-go inubit
Web: www.inubit.com<http://www.inubit.com>

Vorstand: Dr. Torsten Schmale
Vorsitzender des Aufsichtsrates: Dr. Wolf-Dieter Klemt
Registergericht: AG Charlottenburg
Registernummer: HRB 80154
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
dom4j-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dom4j-dev

Re: [dom4j-dev] dom4j extensions

2008-11-05 Thread Marc Pellmann

Hi Mike!

> I believe from memory that the existing codebase does (2) already,
> albeit for Jaxen only

I have checked out version 2 from the mercurial now, but I do not see
this!? Which changes do you mean in detail?

-- 
Viele Grüße / best regards

Marc Pellmann (Software Architect)

inubit - integrating your business and IT
inubit AG
Schöneberger Ufer 89-91
D-10785 Berlin
Fon: +49.30. 72 61 12-132
Fax: +49.30. 72 61 12-100
Freecall: 0800-go inubit
Web: www.inubit.com

Vorstand: Dr. Torsten Schmale
Vorsitzender des Aufsichtsrates: Dr. Wolf-Dieter Klemt
Registergericht: AG Charlottenburg
Registernummer: HRB 80154
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
dom4j-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dom4j-dev

Re: [dom4j-dev] dom4j extensions

2008-11-04 Thread Mike Skells

I believe from memory that the existing codebase does (2) already, albeit for 
Jaxen only

Regards
Mike Skells
Chief Solutions Architect
ValidSoft Ltd
F: +44 (0) 20 7033 1965
M: +44 (0) 7740 520 717
[EMAIL PROTECTED]
www.validsoft.com
ValidSoft Ltd is a Private Limited Company.
Registered Address:Castle Buildings, Tara Street, Tullamore, Co. Offaly, 
Ireland.
Registration Number: 377068 Registered in Dublin.
The information in this e-mail is confidential and may be legally privileged. 
It is intended solely for the addressee(s).  Access to this e-mail by anyone 
else is unauthorised. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in reliance on 
it, is prohibited and may be unlawful. When addressed to our clients any 
opinions or advice contained in this e-mail are subject to the terms and 
conditions expressed in the governing ValidSoft client terms and conditions.




From: Marc Pellmann [mailto:[EMAIL PROTECTED]
Sent: 04 November 2008 10:58
To: [EMAIL PROTECTED]; [email protected]
Subject: [dom4j-dev] dom4j extensions

Hello Filip, hello dom4j developers!

I have some problems/aspects with dom4j and want to add some code to the 
project to fix this. The problems are:

1. XPath 2.0
In the Moment there is a fix use of Jaxen in the XPath API. I want to use the 
XPath implementation of Saxon. To do this I have added JAXP methods to the 
XPath interface. Then I have implemented this with JAXP. There are now parallel 
methods for variable and function contexts for JAXP and Jaxen (to not break the 
interface). May be in the future (dom4j 2.0) it will be an good idea to use 
only the JAXP interfaces and write Jaxen implementations for them!?

2. Access to all namespaces used by the document for XPathes
It is needed to add all namespaces from the document to the xpath, to work 
correct with namespaces. This also need the ability to add new prefixes for 
URIs, if there are default namespaces or doubled prefixes. I have added such an 
class and the access to it in document interface (and the AbstractDocument 
implementation). The element implementation (AbstractElement) adds namespaces 
to this object if added to the element. (removing is an aspect, that is not 
addressed)

What is the preferred way for you to add (and update) this code?

--
Viele Grüße / best regards

Marc Pellmann (Software Architect)

inubit - integrating your business and IT
inubit AG
Schöneberger Ufer 89-91
D-10785 Berlin
Fon: +49.30. 72 61 12-132
Fax: +49.30. 72 61 12-100
Freecall: 0800-go inubit
Web: www.inubit.com

Vorstand: Dr. Torsten Schmale
Vorsitzender des Aufsichtsrates: Dr. Wolf-Dieter Klemt
Registergericht: AG Charlottenburg
Registernummer: HRB 80154
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
dom4j-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dom4j-dev

Re: [dom4j-dev] dom4j extensions

Re: [dom4j-dev] dom4j extensions

Re: [dom4j-dev] dom4j extensions

Re: [dom4j-dev] dom4j extensions

Re: [dom4j-dev] dom4j extensions

Re: [dom4j-dev] dom4j extensions

Re: [dom4j-dev] dom4j extensions

Re: [dom4j-dev] dom4j extensions

Re: [dom4j-dev] dom4j extensions

9 matches

Site Navigation

Mail list logo

Footer information