Hello guys,
On Dec 12, 2009, at 18:57 , Brian Topping wrote:
> As I sometimes do, I suspect that this may have been a case of good
> intentions that were never needed. In this case it may have worked to our
> advantage that the util project was never fully realized.
It's a concept that was put in place to keep modularity minimize dependencies.
>> oh, yeah sorry brian, just saw what you are referring to in detail:
>> The util stuff to be included even if its not used. Yeah, that was a bit
>> strange. And do not fully understand.
See below...
>>>> As I get into the tree, I notice that the util project contents (all two
>>>> files) are duplicated into every jar.
They should only be included if they are used, and looking at the original
build.xml that seems to be the case (check the project-bundle macros in that
file).
>>>> I can assume there's a good reason
>>>> that might have been desirable, but there's some havoc with Maven to do so.
There is a reason why the classes in the util package are embedded.
First of all, having a utility library that is shared by many bundles
introduces a lot of extra dependencies.
Furthermore, most of the time, you only use one or two classes or even methods
out of such utility classes. So the original idea is to have a set of
utilities, that only get included when needed, and my future vision was that by
using for example an obfuscator, we could even strip the inclusion to just
those parts that were really being used.
>>>> As I look through the dependencies on these two files, there are really
>>>> only calls to o.a.a.util.Codec from the ace-log project and calls to
>>>> o.a.a.util.VersionRange from the ace-client-repository-helper-bundle
>>>> project.
Exactly, with the idea that we wanted to strip out stuff we did not use using
an obfuscator (because they can do a code analysis and determine what's used
and what's not).
>>>> Any reasons I'm not fully understanding to not move these to those
>>>> respective projects and doing away with the util project until we have a
>>>> stronger need for something like it in the future?
See above, in the future I would like to include such an obfuscator to strip
out unused code. This also goes for example for other types of dependencies
that are only needed at compile time. An example of that:
Let's say we have a:
package foo;
public class Constants {
public static int MY_CONST = 1;
}
and we have several bundles that "use" this constant, so they might include it
in some class/method, like:
package bar;
[...]
public boolean isTrue(int val) {
return (Constants.MY_CONST == val);
}
Now this is something that javac will optimize, so we will never see an import
of package foo in class bar if it only uses this constant. So only compile time
do we need package foo (if that's all we use out of it). Bnd is smart enough
not to import foo in bar, and the old build put foo on the compiler classpath
so it could be accessed.
I hope this helps a bit in figuring out how to translate this to Maven.
>>>> p.s. Sorry if this detail granularity is too small... just don't want to
>>>> make any stupid assumptions as I get started.
These are perfectly valid questions, feel free to fire many more ;)
Greetings, Marcel
