well, the problem is that we are currently mixing two issues, which
* 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
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
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
-OSBC tackles the biggest issue in open source: Open Sourcing the
-Strategies to boost innovation and cut costs with open source
-Receive a $600 discount off the registration fee with the source
Aperture-devel mailing list