You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Carlos Sanchez <ca...@apache.org> on 2007/03/28 20:04:45 UTC
Adding hierarchies to the Maven build
Have you guys thought about making the build more hierarchical, adding
more parent poms and grouping the projects to share configuration
for instance, instead of
ipojo
ipojo.arch
ipojo.metadata
ipojo.plugin
ipojo/pom.xml (modules: ipojo, arch, metadata, plugin, version= 0.7.0 )
ipojo/ipojo (usually core or some other name)
ipojo/arch
ipojo/metadata
ipojo/plugin
all the ipojo subprojects would extend ipojo/pom.xml that in turn
extends the parent felix pom, you could share some info in
ipojo/pom.xml
that way you reduce the modules in felix parent to ipojo, plugins,mosgi,...
and you wouldn't need different profiles, just go into one of the
folders and mvn install, eg. go to plugins to build all plugins
from my experience i think it would make more sense and ends being
easier to mantain
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
Re: Adding hierarchies to the Maven build
Posted by Felix Meschberger <fm...@gmail.com>.
Hi all,
Forgive me if I am wrong, but the discussion of whether to structure
the projects as sub-projects with other sub-projects has probably
nothing to do with Eclipse - as long as a parent project is a pom
project and does not contain its own Java source.
Whether and how to support PDE for bundle development is IMHO a
completely different discussion worth to be held.
This is simply about structuring the projects to get a better overview
and probably build control.
As such, I am in favor of hierarchical structuring.
The question to me is rather, what exactly is structured into lower
levels. IPOJO and mosgi are obvious candidates for sub-structuring.
But how about others ? Is it more like "implementations of OSGi
specified services are not structured ?" But then how about the
eventadmin projects, which IMHO warant substructuring, too. Of is the
substructuring more like help work around the maven issue regarding
the package extensions ?
So I propose the following :
> Create sub projects of IPOJO, mosgi, eventadmin, upnp and shell projects
> Create a subproject for straight OSGi-componendium implementations
like scr, http.jetty, log
> Create sort of an extension (or contrib or xxx) sub project for
projects not directly related to OSGi specifications like mishell,
jmood, dependencymanager, jmxintrospector, servicebinder.
> Leave the rest (osgi libraries, framework, main, bundlerepository,
..) at the "top".
> Leave the tools as is (for the moment)
Re tools: Maybe it would be worth a separate discussion on how to
proceed on the different maven plugins in tools/maven2 and maybe
include the IPOJO plugin in this discussion.
Regards
Felix
Re: Adding hierarchies to the Maven build
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Niclas Hedhman wrote:
> On Tuesday 03 April 2007 17:48, Richard S. Hall wrote:
>
>> Well, I don't look at this as a "should we support PDE or not" type of
>> argument.
>>
>
> Ok, let's extend the list;
>
> 1. Eclipse PDE is not happy with jars embedded in bundles. Is there a
> requirement on bundles produced by the Felix community that these bundles do
> not contain any embedded jars?
>
> 2. Eclipse PDE is incapable of handling the case when you call methods in a
> superclass that is in a non-exported package, but the subclass(es) are in an
> exported package. PDE complains about access restrictions where there are
> none.
>
> So, I still think there is a "general question" for this community to answer;
> Is Eclipse PDE support a primary objective of this community?
>
Clearly it is not a primary objective, but if minor compromises can be
made to make it more possible, then that is fine. However, I don't think
our repository structure should be held hostage to it.
It doesn't really sound like the above issues are related to repository
structure, so I am still content to go ahead with making the repository
more hierarchical.
-> richard
> I think this is important, since following the OSGi spec is not enough to be
> PDE compatible, due to PDE bugs.
>
>
> Cheers
>
Re: Adding hierarchies to the Maven build
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 03 April 2007 17:48, Richard S. Hall wrote:
> Well, I don't look at this as a "should we support PDE or not" type of
> argument.
Ok, let's extend the list;
1. Eclipse PDE is not happy with jars embedded in bundles. Is there a
requirement on bundles produced by the Felix community that these bundles do
not contain any embedded jars?
2. Eclipse PDE is incapable of handling the case when you call methods in a
superclass that is in a non-exported package, but the subclass(es) are in an
exported package. PDE complains about access restrictions where there are
none.
So, I still think there is a "general question" for this community to answer;
Is Eclipse PDE support a primary objective of this community?
I think this is important, since following the OSGi spec is not enough to be
PDE compatible, due to PDE bugs.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
Re: Adding hierarchies to the Maven build
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On Apr 3, 2007, at 5:48 AM, Richard S. Hall wrote:
> Niclas Hedhman wrote:
>> On Monday 02 April 2007 19:14, Richard S. Hall wrote:
>>
>>> The end result would be that doing "ls trunk" would show you a
>>> list of
>>> our sub-projects. Going into a sub-project directory would show
>>> you all
>>> of the modules associated with that sub-project. That's it.
>>>
>>
>> Me like indeed. Who needs Felix to have Eclipse support anyway,
>> other than "that McAffer guy" ;o)
>>
>> Seriously, I think we need a decision whether we are a pure OSGi
>> group or want to explicitly support work-arounds of Eclipse PDE
>> bugs and special behaviour.
>>
>> IMHO, I don't care about Eclipse support, and will not accommodate
>> work arounds in my own projects, just because PDE has no support
>> or behaving incorrectly to bundles that are otherwise correct.
>>
>> IF Eclipse PDE support is required by/from Felix community, then
>> the above structure needs to be scrutinized by those who
>> understand that issue. Everyone like me, should just bow to the
>> conclusion.
>>
>
> Well, I don't look at this as a "should we support PDE or not" type
> of argument. I just know that our current approach kind sucks and
> could be improved. Since we use maven it sounds like it could make
> better use of maven too, so that is another argument.
>
> However, I agree with you that if this will seriously cause
> problems for people using this stuff in Eclipse, then they should
> voice their concerns and potentially tweaks to make it work better,
> but certainly Eclipse should not be the only reason so keep a
> repository structure we do not like.
That should have said, "...should not be the only reason to keep..."
-> richard
Re: Adding hierarchies to the Maven build
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Niclas Hedhman wrote:
> On Monday 02 April 2007 19:14, Richard S. Hall wrote:
>
>> The end result would be that doing "ls trunk" would show you a list of
>> our sub-projects. Going into a sub-project directory would show you all
>> of the modules associated with that sub-project. That's it.
>>
>
> Me like indeed. Who needs Felix to have Eclipse support anyway, other
> than "that McAffer guy" ;o)
>
> Seriously, I think we need a decision whether we are a pure OSGi group or want
> to explicitly support work-arounds of Eclipse PDE bugs and special behaviour.
>
> IMHO, I don't care about Eclipse support, and will not accommodate work
> arounds in my own projects, just because PDE has no support or behaving
> incorrectly to bundles that are otherwise correct.
>
> IF Eclipse PDE support is required by/from Felix community, then the above
> structure needs to be scrutinized by those who understand that issue.
> Everyone like me, should just bow to the conclusion.
>
Well, I don't look at this as a "should we support PDE or not" type of
argument. I just know that our current approach kind sucks and could be
improved. Since we use maven it sounds like it could make better use of
maven too, so that is another argument.
However, I agree with you that if this will seriously cause problems for
people using this stuff in Eclipse, then they should voice their
concerns and potentially tweaks to make it work better, but certainly
Eclipse should not be the only reason so keep a repository structure we
do not like.
-> richard
Re: Adding hierarchies to the Maven build
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 02 April 2007 19:14, Richard S. Hall wrote:
> The end result would be that doing "ls trunk" would show you a list of
> our sub-projects. Going into a sub-project directory would show you all
> of the modules associated with that sub-project. That's it.
Me like indeed. Who needs Felix to have Eclipse support anyway, other
than "that McAffer guy" ;o)
Seriously, I think we need a decision whether we are a pure OSGi group or want
to explicitly support work-arounds of Eclipse PDE bugs and special behaviour.
IMHO, I don't care about Eclipse support, and will not accommodate work
arounds in my own projects, just because PDE has no support or behaving
incorrectly to bundles that are otherwise correct.
IF Eclipse PDE support is required by/from Felix community, then the above
structure needs to be scrutinized by those who understand that issue.
Everyone like me, should just bow to the conclusion.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
Re: Adding hierarchies to the Maven build
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Stefano Lenzi wrote:
> I like the idea too ^_^, but I think it should be documented
> somewhere... maybe we can update the readme.txt file that is quit old
> nowdays...
The current documentation is at:
http://cwiki.apache.org/confluence/display/FELIX/SVN+repository+structure
This would need to be updated.
> Finally, if I understood well the future SVN repository will look
> somehow like that:
> trunk
> |
> |-> utility
> |--> ipojo
> |-> core-bundle
> |-> compendium-bundle
> |
> |----------> upnp
> |-> basedriver
> |---> examples
> Am I right?
No.
The trunk should contain our sub-projects, not some attempt at a grand
organization of them.
So, it would be something like this:
trunk/
bundlerepository/
ipojo/
arch/
core/
metadata/
plugin/
upnp/
basedriver/
doc/
extra/
sample/
binarylight/
clock/
tv/
tester/
...
The end result would be that doing "ls trunk" would show you a list of
our sub-projects. Going into a sub-project directory would show you all
of the modules associated with that sub-project. That's it.
-> richard
Re: Adding hierarchies to the Maven build
Posted by Stefano Lenzi <ki...@interfree.it>.
Richard S. Hall wrote:
> Carlos Sanchez wrote:
>> Have you guys thought about making the build more hierarchical, adding
>> more parent poms and grouping the projects to share configuration
>
> This is basically what I was trying to describe in my other message
> where I talk about our waffling between flat versus hierarchical. Since
> flat hasn't seemed to work out too well, I am willing to give a more
> hierarchical approach a try.
>
> However, I still feel that trunk/ should contain sub-projects. Some
> sub-projects may contain multiple parts, e.g., iPOJO, MOSGi, UPnP, etc.
> So those can be grouped, but I do not think we should try to define some
> ontological grouping hierarchical, like tools, plugins, etc. This gets
> too confusing, e.g., iPOJO has a plugin, which could go into plugins or
> tools, but it is really part of the iPOJO sub-project.
>
> Thus, my suggestion would be trunk/ being the flat set of sub-projects,
> where each sub-project can be comprised of one ore more modules to allow
> for additional grouping.
>
> The question is whether or not we should try to formally decide this
> (i.e., a vote) or just do it.
>
> -> richard
>
>>
>> for instance, instead of
>>
>> ipojo
>> ipojo.arch
>> ipojo.metadata
>> ipojo.plugin
>>
>>
>> ipojo/pom.xml (modules: ipojo, arch, metadata, plugin, version= 0.7.0 )
>> ipojo/ipojo (usually core or some other name)
>> ipojo/arch
>> ipojo/metadata
>> ipojo/plugin
>>
>> all the ipojo subprojects would extend ipojo/pom.xml that in turn
>> extends the parent felix pom, you could share some info in
>> ipojo/pom.xml
>>
>> that way you reduce the modules in felix parent to ipojo,
>> plugins,mosgi,...
>>
>> and you wouldn't need different profiles, just go into one of the
>> folders and mvn install, eg. go to plugins to build all plugins
>>
>> from my experience i think it would make more sense and ends being
>> easier to mantain
>>
>
>
I like the idea too ^_^, but I think it should be documented
somewhere... maybe we can update the readme.txt file that is quit old
nowdays...
Finally, if I understood well the future SVN repository will look
somehow like that:
trunk
|
|-> utility
|--> ipojo
|-> core-bundle
|-> compendium-bundle
|
|----------> upnp
|-> basedriver
|---> examples
Am I right?
Ciao,
Stefano "Kismet" Lenzi
Re: Adding hierarchies to the Maven build
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Niclas Hedhman wrote:
> On Thursday 29 March 2007 20:08, Richard S. Hall wrote:
>
>
>> The question is whether or not we should try to formally decide this
>> (i.e., a vote) or just do it.
>>
>
> TheApacheWay; You have now presented a suggestion to change. If noone objects
> within 72 hours, it is considered "consensus" and you (or someone else) just
> do it. If people object, some discussions, and hopefully people who has a say
> are in agreement, otherwise a vote...
>
> FWIW; a positive 'go ahead' from me...
>
Thanks for the information...
-> richard
Re: Adding hierarchies to the Maven build
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 29 March 2007 20:08, Richard S. Hall wrote:
> The question is whether or not we should try to formally decide this
> (i.e., a vote) or just do it.
TheApacheWay; You have now presented a suggestion to change. If noone objects
within 72 hours, it is considered "consensus" and you (or someone else) just
do it. If people object, some discussions, and hopefully people who has a say
are in agreement, otherwise a vote...
FWIW; a positive 'go ahead' from me...
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
Re: Adding hierarchies to the Maven build
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Carlos Sanchez wrote:
> Have you guys thought about making the build more hierarchical, adding
> more parent poms and grouping the projects to share configuration
This is basically what I was trying to describe in my other message
where I talk about our waffling between flat versus hierarchical. Since
flat hasn't seemed to work out too well, I am willing to give a more
hierarchical approach a try.
However, I still feel that trunk/ should contain sub-projects. Some
sub-projects may contain multiple parts, e.g., iPOJO, MOSGi, UPnP, etc.
So those can be grouped, but I do not think we should try to define some
ontological grouping hierarchical, like tools, plugins, etc. This gets
too confusing, e.g., iPOJO has a plugin, which could go into plugins or
tools, but it is really part of the iPOJO sub-project.
Thus, my suggestion would be trunk/ being the flat set of sub-projects,
where each sub-project can be comprised of one ore more modules to allow
for additional grouping.
The question is whether or not we should try to formally decide this
(i.e., a vote) or just do it.
-> richard
>
> for instance, instead of
>
> ipojo
> ipojo.arch
> ipojo.metadata
> ipojo.plugin
>
>
> ipojo/pom.xml (modules: ipojo, arch, metadata, plugin, version= 0.7.0 )
> ipojo/ipojo (usually core or some other name)
> ipojo/arch
> ipojo/metadata
> ipojo/plugin
>
> all the ipojo subprojects would extend ipojo/pom.xml that in turn
> extends the parent felix pom, you could share some info in
> ipojo/pom.xml
>
> that way you reduce the modules in felix parent to ipojo,
> plugins,mosgi,...
>
> and you wouldn't need different profiles, just go into one of the
> folders and mvn install, eg. go to plugins to build all plugins
>
> from my experience i think it would make more sense and ends being
> easier to mantain
>
Re: Adding hierarchies to the Maven build
Posted by Stuart McCulloch <st...@jayway.net>.
Also, I'd recommend using <pluginManagement>...</pluginManagement>
to define plugin configuration in parent poms, with the actual list of build
plugins appearing in the child pom (without needing version, config, etc.)
For example, in the parent I can setup the bundle plugin to use a bnd file:
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>0.9.0-incubator-SNAPSHOT</version>
<extensions>true</extensions>
<configuration>
<instructions>
<!-- assumes bnd file is copied from resources to build
directory -->
<_include>${project.build.outputDirectory}/instructions.bnd</_include>
</instructions>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
and then in any child poms that need bundling, I just need to specify:
<build>
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
</plugin>
<!-- ... other plugins ... -->
</plugins>
</build>
This seems to inherit much better, at least in my experience.
On 29/03/07, Carlos Sanchez <ca...@apache.org> wrote:
> Have you guys thought about making the build more hierarchical, adding
> more parent poms and grouping the projects to share configuration
>
> for instance, instead of
>
> ipojo
> ipojo.arch
> ipojo.metadata
> ipojo.plugin
>
>
> ipojo/pom.xml (modules: ipojo, arch, metadata, plugin, version= 0.7.0 )
> ipojo/ipojo (usually core or some other name)
> ipojo/arch
> ipojo/metadata
> ipojo/plugin
>
> all the ipojo subprojects would extend ipojo/pom.xml that in turn
> extends the parent felix pom, you could share some info in
> ipojo/pom.xml
>
> that way you reduce the modules in felix parent to ipojo, plugins,mosgi,...
>
> and you wouldn't need different profiles, just go into one of the
> folders and mvn install, eg. go to plugins to build all plugins
>
> from my experience i think it would make more sense and ends being
> easier to mantain
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
> -- The Princess Bride
>
--
Cheers, Stuart