well, the problem is that we are currently mixing two issues, which is
* releasing aperture 2.0
Bear in mind that all we do currently should also help
the SMILA people to include aperture, especially help them
in their IP due diligence.
If we are now beginning talking about aperture 2.0, it will take
many months and it will break compability with NEPOMUK and other
that depend on aperture (dynaq, ...).
One thing after another!
fix mavenization, but do not put architecture changes in.
for this reason I am strongly against moving classes around.
Especially if the reason is a possible future replacement for a utility
class with apache utility
classes (or aduna utility classes).
we are talking about ~1000 LOC, the effort to replace them with apache
is clearly not worth it.
utility classes are just that: making life easier.
no need to optimize here.
It was Herko ter Horst who said at the right time 17.02.2009 10:14 the
Antoni Mylka wrote:
And one more thing. I noticed that two methods have been removed from
the UriUtil class in the util package. It may have been done to remove
any dependencies from the util package. It's an aperture-util package.
Almost every Aperture class depends on rdf2go in some way.
Do you see the need to have an rdf2go-free util module? Is there any
use for it outside Aperture? If you think there is, then maybe your
original idea with a separate rdf-util module wasn't too bad, but then
the package name should stay the same, and the UriUtil class should go
For the time being, I reintroduced those two methods to UriUtil and
added a dependency on rdf2go to the aperture-util module.
I've indeed removed (actually moved: the methods are in ModelUtil now)
those methods to get a dependency-free util package (for reasons
outlined in my earlier mail).
Most of UriUtil deals with generic URI issues. The methods that have
been moved dealt with URIs in the context of an RDF2Go model, hence the
move to ModelUtil.
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
Aperture-devel mailing list
DI Leo Sauermann http://www.dfki.de/~sauermann
Deutsches Forschungszentrum fuer
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080 Fon: +49 631 20575-116
D-67663 Kaiserslautern Fax: +49 631 20575-102
Germany Mail: firstname.lastname@example.org
Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313