well, the problem is that we are currently mixing two issues, which is
* 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.
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