You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ace.apache.org by Brian Topping <to...@codehaus.org> on 2009/12/12 18:23:55 UTC
Mavenization of o.a.a.util package
Hi guys,
As I get into the tree, I notice that the util project contents (all
two files) are duplicated into every jar. I can assume there's a good
reason that might have been desirable, but there's some havoc with
Maven to do so.
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.
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?
Cheers, Brian
p.s. Sorry if this detail granularity is too small... just don't want
to make any stupid assumptions as I get started.
Re: Mavenization of o.a.a.util package
Posted by Marcel Offermans <ma...@luminis.nl>.
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
Re: Mavenization of o.a.a.util package
Posted by Brian Topping <to...@codehaus.org>.
Never mind, I'm just not acclimated to the sources yet. Thanks for
bearing with me. I'll stick to the tasks in Jira.
:B
On Dec 12, 2009, at 12:57 PM, Brian Topping wrote:
> Ok thanks for the clarification.
>
> 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.
>
> I am more comfortable with the change and am going to go ahead with
> it. We can always put it back if necessary.
>
> On Dec 12, 2009, at 12:42 PM, Toni Menzel wrote:
>
>> 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.
>> For those cases i would not embed the util stuff at all.
>>
>>
>> On Sat, Dec 12, 2009 at 6:35 PM, Toni Menzel <to...@okidokiteam.com>
>> wrote:
>>
>>> Well, this is somewhat related to the old story, to include api into
>>> implementation or not to include and import from its own bundle.
>>> Sure, util is not api, but i can somewhat understand the inclusion
>>> of those
>>> to libs into the respective bundles. Also because they are just
>>> two classes.
>>>
>>> Anyhow, let the community decide. (my vote is 0 here)
>>> Remember: This is not related to the maven convertion. Just what
>>> to embed
>>> in the final bundles. (one line in osgi.bnd)
>>>
>>>
>>> On Sat, Dec 12, 2009 at 6:23 PM, Brian Topping
>>> <to...@codehaus.org>wrote:
>>>
>>>> Hi guys,
>>>>
>>>> As I get into the tree, I notice that the util project contents
>>>> (all two
>>>> files) are duplicated into every jar. I can assume there's a
>>>> good reason
>>>> that might have been desirable, but there's some havoc with Maven
>>>> to do so.
>>>>
>>>> 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.
>>>>
>>>> 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?
>>>>
>>>> Cheers, Brian
>>>>
>>>> p.s. Sorry if this detail granularity is too small... just don't
>>>> want to
>>>> make any stupid assumptions as I get started.
>>>>
>>>
>>>
>>>
>>> --
>>> Toni Menzel
>>> Independent Software Developer
>>> Professional Profile: http://okidokiteam.com
>>> toni@okidokiteam.com
>>> http://www.ops4j.org - New Energy for OSS Communities - Open
>>> Participation Software.
>>>
>>>
>>
>>
>> --
>> Toni Menzel
>> Independent Software Developer
>> Professional Profile: http://okidokiteam.com
>> toni@okidokiteam.com
>> http://www.ops4j.org - New Energy for OSS Communities - Open
>> Participation Software.
>
>
Re: Mavenization of o.a.a.util package
Posted by Brian Topping <to...@codehaus.org>.
Ok thanks for the clarification.
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.
I am more comfortable with the change and am going to go ahead with
it. We can always put it back if necessary.
On Dec 12, 2009, at 12:42 PM, Toni Menzel wrote:
> 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.
> For those cases i would not embed the util stuff at all.
>
>
> On Sat, Dec 12, 2009 at 6:35 PM, Toni Menzel <to...@okidokiteam.com>
> wrote:
>
>> Well, this is somewhat related to the old story, to include api into
>> implementation or not to include and import from its own bundle.
>> Sure, util is not api, but i can somewhat understand the inclusion
>> of those
>> to libs into the respective bundles. Also because they are just two
>> classes.
>>
>> Anyhow, let the community decide. (my vote is 0 here)
>> Remember: This is not related to the maven convertion. Just what to
>> embed
>> in the final bundles. (one line in osgi.bnd)
>>
>>
>> On Sat, Dec 12, 2009 at 6:23 PM, Brian Topping
>> <to...@codehaus.org>wrote:
>>
>>> Hi guys,
>>>
>>> As I get into the tree, I notice that the util project contents
>>> (all two
>>> files) are duplicated into every jar. I can assume there's a good
>>> reason
>>> that might have been desirable, but there's some havoc with Maven
>>> to do so.
>>>
>>> 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.
>>>
>>> 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?
>>>
>>> Cheers, Brian
>>>
>>> p.s. Sorry if this detail granularity is too small... just don't
>>> want to
>>> make any stupid assumptions as I get started.
>>>
>>
>>
>>
>> --
>> Toni Menzel
>> Independent Software Developer
>> Professional Profile: http://okidokiteam.com
>> toni@okidokiteam.com
>> http://www.ops4j.org - New Energy for OSS Communities - Open
>> Participation Software.
>>
>>
>
>
> --
> Toni Menzel
> Independent Software Developer
> Professional Profile: http://okidokiteam.com
> toni@okidokiteam.com
> http://www.ops4j.org - New Energy for OSS Communities - Open
> Participation Software.
Re: Mavenization of o.a.a.util package
Posted by Toni Menzel <to...@okidokiteam.com>.
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.
For those cases i would not embed the util stuff at all.
On Sat, Dec 12, 2009 at 6:35 PM, Toni Menzel <to...@okidokiteam.com> wrote:
> Well, this is somewhat related to the old story, to include api into
> implementation or not to include and import from its own bundle.
> Sure, util is not api, but i can somewhat understand the inclusion of those
> to libs into the respective bundles. Also because they are just two classes.
>
> Anyhow, let the community decide. (my vote is 0 here)
> Remember: This is not related to the maven convertion. Just what to embed
> in the final bundles. (one line in osgi.bnd)
>
>
> On Sat, Dec 12, 2009 at 6:23 PM, Brian Topping <to...@codehaus.org>wrote:
>
>> Hi guys,
>>
>> As I get into the tree, I notice that the util project contents (all two
>> files) are duplicated into every jar. I can assume there's a good reason
>> that might have been desirable, but there's some havoc with Maven to do so.
>>
>> 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.
>>
>> 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?
>>
>> Cheers, Brian
>>
>> p.s. Sorry if this detail granularity is too small... just don't want to
>> make any stupid assumptions as I get started.
>>
>
>
>
> --
> Toni Menzel
> Independent Software Developer
> Professional Profile: http://okidokiteam.com
> toni@okidokiteam.com
> http://www.ops4j.org - New Energy for OSS Communities - Open
> Participation Software.
>
>
--
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
toni@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
Re: Mavenization of o.a.a.util package
Posted by Toni Menzel <to...@okidokiteam.com>.
Well, this is somewhat related to the old story, to include api into
implementation or not to include and import from its own bundle.
Sure, util is not api, but i can somewhat understand the inclusion of those
to libs into the respective bundles. Also because they are just two classes.
Anyhow, let the community decide. (my vote is 0 here)
Remember: This is not related to the maven convertion. Just what to embed in
the final bundles. (one line in osgi.bnd)
On Sat, Dec 12, 2009 at 6:23 PM, Brian Topping <to...@codehaus.org> wrote:
> Hi guys,
>
> As I get into the tree, I notice that the util project contents (all two
> files) are duplicated into every jar. I can assume there's a good reason
> that might have been desirable, but there's some havoc with Maven to do so.
>
> 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.
>
> 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?
>
> Cheers, Brian
>
> p.s. Sorry if this detail granularity is too small... just don't want to
> make any stupid assumptions as I get started.
>
--
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
toni@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.