whats the problem if we move all the util into the "core" project?

afaik we had to do the same with rdf2go

It was Herko ter Horst who said at the right time 17.02.2009 11:10 the following words:
Hi Leo,

well, the problem is that we are currently mixing two issues, which is 
* mavenization
* releasing aperture 2.0

No, we're not (at least I'm not). We're discussing if any changes we 
need to make to Mavenize Aperture warrant a different version number. 
I'm not saying this should be Aperture 2.0. I'm currently calling it 
1.3.0. It could be 1.2.1, 1.5, 2.0, I don't know.

I'm definitely NOT proposing that we change the architecture of Aperture 
at this time. I'm just moving a couple minor (IMO) things around to 
avoid unnecessary dependencies between modules. However, we are 
significantly changing the way Aperture is organized and built. This 
alone *could* be a change big enough to warrant the 2.0 label, even if 
we don't change anything else.

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 products
that depend on aperture (dynaq, ...).

I think a couple of minor incompatibilities with the existing API are no 
big deal if we document them properly.

One thing after another!
fix mavenization, but do not put architecture changes in.
separate concerns.

Moving a method or a class is not an architectural change. Mavenization 
requires that we think about dependencies between modules. If breaking a 
dependency between two modules can be done by moving one or two methods 
to a different class, or moving one or two classes to a different 
module, that's just part of the process, in my opinion.

for this reason I am strongly against moving classes around.

I don't see the harm in moving a few things. It's not like I'm 
completely changing the way Aperture works.

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.

That's not the reason. The reason is to keep a clean dependency tree and 
avoid dependency cycles. aperture-util contains utilities for "us" as 
Aperture programmers (the utilities everyone already has in some form or 
shape, like StringUtil, IOUtil, etc.). aperture-rdf-util contains 
utilities for Aperture itself AND for Aperture *users* that need to deal 
with the RDF2Go models in Aperture.

aperture-util and aperture-rdf-util are part of this discussion just 
because I Mavenized them first. I'm not trying to optimize anything 
specifically (although if I could replace 1000 LOC with a 
well-established existing library, I'd say it's worth it, but never mind 
that, that's not the goal of this discussion). As Antoni has already 
seen, there are dependencies/difficulties like this all over the code. 
We just need to fix those in the best possible way.


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:  leo.sauermann@dfki.de

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