ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <marcel.offerm...@luminis.nl>
Subject Re: Mavenization of o.a.a.util package
Date Sat, 12 Dec 2009 20:40:04 GMT
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


Mime
View raw message