You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2005/11/30 21:53:22 UTC
Repository/package structure
Hello,
It seems that we have a few contributions nearly ready for the
repository. It might be worthwhile if we talk about repository and
package structure, since this issue will come up as soon as everything
is in order for the code contributions.
We sort of had this discussion earlier, but it is not clear to me that
we came away with a final consensus. I think we just said we will defer
until we need to do something...well, now we need to do something. :-)
I propose that the trunk directory contain a directory for each
subproject, where the subproject directory name is the package name of
the root package of the subproject. Taking the framework as an example:
trunk/
org.apache.felix.framework/
Of course, for the framework we will need to move some other things
around since it currently contains some bundles, so we might end up with:
trunk/
org.apache.felix.framework/
org.apache.felix.shell/
org.apache.felix.shell.tui/
org.apache.felix.bundlerepository/
The shell and bundlerepository subprojects include default
implementations that could be moved up to top-level subprojects if
deemed necessary in the future, such as if we eventually have multiple
implementations available of our own services.
For our outstanding contributions (i.e., UPnP, HTTP Service, and
Preferences Service) , I propose the following:
trunk/
org.apache.felix.http.jetty/
org.apache.felix.prefs.jndi/
org.apache.felix.upnp/
The first two allow for other service implementations (e.g., HTTP based
on Tomcat or Prefs based on files). For UPnP, it seems to me that
multiple implementations are less likely, so I didn't propose any
sub-package...UPnP implementation packages could be renamed later if
another implementation comes along.
I assume that we will get a Log Service before long, so that will likely
be something like:
trunk/
org.apache.felix.log.simple/
org.apache.felix.log.postgres/
Summarizing, we end up with the trunk/ directory being a flat list of
subprojects named after their package.
Thoughts?
-> richard
Re: Re[2]: Installers for Felix needed
Posted by Brett Porter <br...@gmail.com>.
On 12/3/05, Peter Kriens <Pe...@aqute.se> wrote:
> So I can rely on you to get me an RPM (guess a Windows installer is
> too much for Apache :-)
>
Not sure what you mean - plenty of ASF projects include windows installers :)
FWIW, if the consensus is to eventually go down the Maven 2 path then
we have recent support for generating RPMs and Windows installers
(NSIS) reusing your existing metadata as much as possible.
Cheers,
Brett
Re[2]: Installers for Felix needed
Posted by Peter Kriens <Pe...@aQute.se>.
So I can rely on you to get me an RPM (guess a Windows installer is
too much for Apache :-)
I also have ProSyst and Eclipse commit themselves to such
installers! I think this might greatly promote the use of OSGi on
desktops.
Thanks! Kind regards,
Peter Kriens
AK> Richard S. Hall wrote:
>> I don't think we can meet all of the requirements yet, but we are
>> getting there.
>>
>> As a way to start, it would be cool if someone who had the knowledge
>> could create an RPM that would install Felix as a Linux service...or
>> at least I think that would be really cool. :-)
>>
>> Anyone know how to do this? Perhaps we should create a JIRA issue for
>> this...
AK> Yeah I can whip together an rpm descriptor file for this easily. I
AK> think more importantly we should get a native daemon to run Felix
AK> though. Take a look at the Jakarta Daemons project. I used this for a
AK> couple of projects and the procrun/jsvc code seems to work well.
AK> Alex
--
Peter Kriens Tel +33870447986
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Installers for Felix needed
Posted by Alex Karasulu <ao...@bellsouth.net>.
Richard S. Hall wrote:
> I don't think we can meet all of the requirements yet, but we are
> getting there.
>
> As a way to start, it would be cool if someone who had the knowledge
> could create an RPM that would install Felix as a Linux service...or
> at least I think that would be really cool. :-)
>
> Anyone know how to do this? Perhaps we should create a JIRA issue for
> this...
Yeah I can whip together an rpm descriptor file for this easily. I
think more importantly we should get a native daemon to run Felix
though. Take a look at the Jakarta Daemons project. I used this for a
couple of projects and the procrun/jsvc code seems to work well.
Alex
Re: Installers for Felix needed
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I don't think we can meet all of the requirements yet, but we are
getting there.
As a way to start, it would be cool if someone who had the knowledge
could create an RPM that would install Felix as a Linux service...or at
least I think that would be really cool. :-)
Anyone know how to do this? Perhaps we should create a JIRA issue for
this...
-> richard
Peter Kriens wrote:
> I am planning to use my OSGi blog (http://www.osgi.org/blog)
> to develop/describe a home gateway from the ground up. I asked the
> different vendors of Frameworks for an easy to install version (OSGi
> for dummies). Richard indicated that he would love to do it ... if he
> had the time and experience. It would be sad if Felix was not part of
> the possible frameworks ...
>
> I need Service Platform as a simple Windows installer, and
> optionally installers for Linux and Mac. It is paramount that the installer is simple
> and easy. The Framework should automatically start when the computer
> is started. The Service Platform should have the following basic services:
>
> Flash screen (Apache Rocks!)
> Http Service (you can advertise on the 404 page)
> Log Service
> Event Admin
> Configuration Admin
> Declarative Services
> Provisioning bundle
>
> The declarative services will be rather difficult, but maybe it is
> possible to use the Declarative Services from Eclipse? I really would
> like to have this included because it means I can make the examples
> simpler.
>
> The framework should be lean and mean. Over time I will add lots of
> services from the different vendors.
>
> Is there someone on this list that is willing to make such an
> installer for Linux and/or Windows for the greater good of Apache
> Felix? :-)
>
> Kind regards,
>
> Peter Kriens
>
>
Re: Installers for Felix needed
Posted by Alex Karasulu <ao...@bellsouth.net>.
Peter Kriens wrote:
> Flash screen (Apache Rocks!)
>
>
Greatly appreciated Peter! I can lend a hand btw with multiple platform
installers as I have recently have had to learn how to use a few.
Alex
Installers for Felix needed
Posted by Peter Kriens <Pe...@aQute.se>.
I am planning to use my OSGi blog (http://www.osgi.org/blog)
to develop/describe a home gateway from the ground up. I asked the
different vendors of Frameworks for an easy to install version (OSGi
for dummies). Richard indicated that he would love to do it ... if he
had the time and experience. It would be sad if Felix was not part of
the possible frameworks ...
I need Service Platform as a simple Windows installer, and
optionally installers for Linux and Mac. It is paramount that the installer is simple
and easy. The Framework should automatically start when the computer
is started. The Service Platform should have the following basic services:
Flash screen (Apache Rocks!)
Http Service (you can advertise on the 404 page)
Log Service
Event Admin
Configuration Admin
Declarative Services
Provisioning bundle
The declarative services will be rather difficult, but maybe it is
possible to use the Declarative Services from Eclipse? I really would
like to have this included because it means I can make the examples
simpler.
The framework should be lean and mean. Over time I will add lots of
services from the different vendors.
Is there someone on this list that is willing to make such an
installer for Linux and/or Windows for the greater good of Apache
Felix? :-)
Kind regards,
Peter Kriens
--
Peter Kriens Tel +33870447986
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Repository/package structure
Posted by Alex Karasulu <ao...@bellsouth.net>.
Richard S. Hall wrote:
> Alan D. Cabrera wrote:
>
>> I think that it's great to have it all packaged up in the manner you
>> described; this can be accomplished with the maven assembly plugin.
>
>
> Yes, I expected that our eventual maven build process would do it.
>
>> I think that it's bad form to support both ant and maven.
>
>
> I don't. But if it is a problem, Felix release could ship only with
> ant support and maven could just be used for Felix developers.
I agree with Richard here. We can have both. Maven can generate ant
build.xml files too btw but there's nothing stopping us from having both
the ant and maven stuff maintained independently and side by side. Lots
of work though.
> To make sure that I am being clear, I am not talking about having two
> build processes for the entire Felix project. I anticipate that the
> Felix project will ultimately only have a maven build process. But the
> release archive of the framework will be self-contained and include an
> Ant build file (and a maven one if it isn't problematic).
Should not be a problem.
Alex
Re: Repository/package structure
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Alan D. Cabrera wrote:
> I think that it's great to have it all packaged up in the manner you
> described; this can be accomplished with the maven assembly plugin.
Yes, I expected that our eventual maven build process would do it.
> I think that it's bad form to support both ant and maven.
I don't. But if it is a problem, Felix release could ship only with ant
support and maven could just be used for Felix developers.
To make sure that I am being clear, I am not talking about having two
build processes for the entire Felix project. I anticipate that the
Felix project will ultimately only have a maven build process. But the
release archive of the framework will be self-contained and include an
Ant build file (and a maven one if it isn't problematic).
In the future, we may be able to drop support for ant, but currently it
is still more widely used than maven.
-> richard
Re: Repository/package structure
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Richard S. Hall wrote, On 12/2/2005 1:22 PM:
> Alan D. Cabrera wrote:
>
>> Richard S. Hall wrote, On 12/2/2005 6:59 AM:
>>
>>> Keep in mind that this is only discussing our internal build
>>> process. We can package and distribute our subprojects with
>>> different build processes. For example, I expect Felix releases to
>>> be backed in a self-contained way with an Ant file.
>>
>>
>> Can you explain this in more detail?
>
>
> I expect that when the time comes to create a Felix release archive
> (which I hope a snapshot will happen soon) that it will be a
> completely self-contained binary plus buildable source release, just
> like previous versions of Oscar were. This means that the Felix
> release will come with binaries as well as a src.jar file that
> contains its source code along with a simple build file for building
> it. It will definitely contain a simple Ant build file, since many
> people do not use Maven. It may also include a Maven build file too.
> The important thing in my book is that it is simple and self-contained
> and does not require remote access to repositories to be built.
I think that it's great to have it all packaged up in the manner you
described; this can be accomplished with the maven assembly plugin. I
think that it's bad form to support both ant and maven.
Regards,
Alan
Re: Repository/package structure
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Alan D. Cabrera wrote:
> Richard S. Hall wrote, On 12/2/2005 6:59 AM:
>> Keep in mind that this is only discussing our internal build process.
>> We can package and distribute our subprojects with different build
>> processes. For example, I expect Felix releases to be backed in a
>> self-contained way with an Ant file.
>
> Can you explain this in more detail?
I expect that when the time comes to create a Felix release archive
(which I hope a snapshot will happen soon) that it will be a completely
self-contained binary plus buildable source release, just like previous
versions of Oscar were. This means that the Felix release will come with
binaries as well as a src.jar file that contains its source code along
with a simple build file for building it. It will definitely contain a
simple Ant build file, since many people do not use Maven. It may also
include a Maven build file too. The important thing in my book is that
it is simple and self-contained and does not require remote access to
repositories to be built.
-> richard
Re: Repository/package structure
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Richard S. Hall wrote, On 12/2/2005 6:59 AM:
> Stefano Lenzi wrote:
>
>> If so
>> were do we store the dependencies package between subproject?
>>
>
>
> If I understand correctly, other subproject JAR files would be stored
> in a Maven repository and would automatically be retrieved when
> building subprojects that depend on them. Someone can correct me if I
> am wrong.
Dependencies are explicitly stated in the pom.xml files that re in each
sub-project. These dependencies are automatically downloaded from the
maven repository during a build.
> Keep in mind that this is only discussing our internal build process.
> We can package and distribute our subprojects with different build
> processes. For example, I expect Felix releases to be backed in a
> self-contained way with an Ant file.
Can you explain this in more detail?
Regards,
Alan
Re: Repository/package structure
Posted by Enrique Rodriguez <en...@gmail.com>.
Stefano Lenzi wrote:
> Enrique Rodriguez wrote:
>
>>In a nutshell, releases go under a releases/ dir
>
> So if I understand well the releases are done for subproject(bundle),
> isn't it?
Yes.
Enrique
Re: Repository/package structure
Posted by Stefano Lenzi <ki...@interfree.it>.
Enrique Rodriguez wrote:
> Richard S. Hall wrote:
>
>> Stefano Lenzi wrote:
>
> ...
>
>>> - Stephane Frenot has pointed out of will be manged bundle version: do
>>> you think to use just a "special log message" or it's better if we use
>>> something like:
>>>
>>> trunk/
>>> org.apache.felix.http.jetty/
>>> org.apache.felix.prefs.jndi/
>>> org.apache.felix.upnp/
>>> trunk/
>>> 1.0.0/
>>> 1.0.1/
>>> 2.0.0/
>>
>>
>> I don't think we would keep different versions in the trunk/
>> directory, would we? My understanding is that the trunk/ directory is
>> the current line of development. We have a tags/ directory for
>> creating releases and a branch/ directory for diverging from the
>> trunk/, correct?
>
>
> Right, no trunk/ under another trunk/ and no versions in there,
> either. We discussed this during an initial repo layout thread,
> summarized here:
>
> http://mail-archives.apache.org/mod_mbox/incubator-oscar-dev/200508.mbox/%3cC9B41A4AFD8DC441B8D62DA7EC801603050DFB@jis06248.jis.org%3e
>
>
> In a nutshell, releases go under a releases/ dir
So if I understand well the releases are done for subproject(bundle),
isn't it?
> and any branching is done to personal sandboxes, eg sandbox/erodriguez.
>
> Enrique
>
>
Re: Repository/package structure
Posted by Enrique Rodriguez <en...@gmail.com>.
Richard S. Hall wrote:
> Stefano Lenzi wrote:
...
>> - Stephane Frenot has pointed out of will be manged bundle version: do
>> you think to use just a "special log message" or it's better if we use
>> something like:
>>
>> trunk/
>> org.apache.felix.http.jetty/
>> org.apache.felix.prefs.jndi/
>> org.apache.felix.upnp/
>> trunk/
>> 1.0.0/
>> 1.0.1/
>> 2.0.0/
>
> I don't think we would keep different versions in the trunk/ directory,
> would we? My understanding is that the trunk/ directory is the current
> line of development. We have a tags/ directory for creating releases and
> a branch/ directory for diverging from the trunk/, correct?
Right, no trunk/ under another trunk/ and no versions in there, either.
We discussed this during an initial repo layout thread, summarized here:
http://mail-archives.apache.org/mod_mbox/incubator-oscar-dev/200508.mbox/%3cC9B41A4AFD8DC441B8D62DA7EC801603050DFB@jis06248.jis.org%3e
In a nutshell, releases go under a releases/ dir and any branching is
done to personal sandboxes, eg sandbox/erodriguez.
Enrique
Re: Repository/package structure
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Stefano Lenzi wrote:
> - Do you want to be able to compile each subproject separately?
Yes, that would be a goal, I think.
> If so
> were do we store the dependencies package between subproject?
>
If I understand correctly, other subproject JAR files would be stored in
a Maven repository and would automatically be retrieved when building
subprojects that depend on them. Someone can correct me if I am wrong.
Keep in mind that this is only discussing our internal build process. We
can package and distribute our subprojects with different build
processes. For example, I expect Felix releases to be backed in a
self-contained way with an Ant file.
> - Stephane Frenot has pointed out of will be manged bundle version: do
> you think to use just a "special log message" or it's better if we use
> something like:
>
> trunk/
> org.apache.felix.http.jetty/
> org.apache.felix.prefs.jndi/
> org.apache.felix.upnp/
> trunk/
> 1.0.0/
> 1.0.1/
> 2.0.0/
>
I don't think we would keep different versions in the trunk/ directory,
would we? My understanding is that the trunk/ directory is the current
line of development. We have a tags/ directory for creating releases and
a branch/ directory for diverging from the trunk/, correct?
> - Also when you speak about subproject do you think just to a bundle or even a suite of bundle? For example we have done UPnP Base Driver bundle but also a Generic Control Point bundle. Do you plan to use different subproject in that case?
>
Personally, I would like the possibility to be one or more JAR files,
just so that we can avoid a million subprojects. However, it is my
understanding that Maven requires one JAR per subproject.
> - I think that some information should be store even on the root of the trunk. Something like the "ant" to build the whole Felix stuff, test unit that test the interaction between several project, dome documentation and maybe other stuff.
>
I think that there will be an integrated build process, we just haven't
gotten there yet. Currently, we just need to get our structure correct,
with everyone using their own build process for the time being. Then we
need to transition to a common build process after that...at least that
seems to make sense to me. :-)
-> richard
Re: Repository/package structure
Posted by Stefano Lenzi <ki...@interfree.it>.
Richard S. Hall wrote:
>
>
> Thoughts?
Ok! But I need to understand something like:
- Do you want to be able to compile each subproject separately? If so
were do we store the dependencies package between subproject?
- Stephane Frenot has pointed out of will be manged bundle version: do
you think to use just a "special log message" or it's better if we use
something like:
trunk/
org.apache.felix.http.jetty/
org.apache.felix.prefs.jndi/
org.apache.felix.upnp/
trunk/
1.0.0/
1.0.1/
2.0.0/
- Also when you speak about subproject do you think just to a bundle or even a suite of bundle? For example we have done UPnP Base Driver bundle but also a Generic Control Point bundle. Do you plan to use different subproject in that case?
- I think that some information should be store even on the root of the trunk. Something like the "ant" to build the whole Felix stuff, test unit that test the interaction between several project, dome documentation and maybe other stuff.
>
> -> richard
>
>
Re: Repository/package structure
Posted by Rinku <ra...@gmail.com>.
Hi,
Here's another thought...
I think project structure followed by Maven2 project is pretty neat with
tests (and resources for tests) segregated from the main project ones.
so, sources under org.apache.felix.framework would look something like:
org.apache.felix.framework
/src
/main
/java
/resources
/test
/java
/resources
The package naming remains same under both src/main/java and src/test/java.
Haven't caught up with all the emails on this thread, so not sure if this
has been proposed already or if there is a reason for not going with it.
Cheers,
Rahul
----- Original Message -----
From: "Richard S. Hall" <he...@ungoverned.org>
To: <fe...@incubator.apache.org>
Sent: Thursday, December 01, 2005 9:53 AM
Subject: Repository/package structure
> Hello,
>
> It seems that we have a few contributions nearly ready for the repository.
> It might be worthwhile if we talk about repository and package structure,
> since this issue will come up as soon as everything is in order for the
> code contributions.
>
> We sort of had this discussion earlier, but it is not clear to me that we
> came away with a final consensus. I think we just said we will defer until
> we need to do something...well, now we need to do something. :-)
>
> I propose that the trunk directory contain a directory for each
> subproject, where the subproject directory name is the package name of the
> root package of the subproject. Taking the framework as an example:
>
> trunk/
> org.apache.felix.framework/
>
> Of course, for the framework we will need to move some other things around
> since it currently contains some bundles, so we might end up with:
>
> trunk/
> org.apache.felix.framework/
> org.apache.felix.shell/
> org.apache.felix.shell.tui/
> org.apache.felix.bundlerepository/
>
> The shell and bundlerepository subprojects include default implementations
> that could be moved up to top-level subprojects if deemed necessary in the
> future, such as if we eventually have multiple implementations available
> of our own services.
>
> For our outstanding contributions (i.e., UPnP, HTTP Service, and
> Preferences Service) , I propose the following:
>
> trunk/
> org.apache.felix.http.jetty/
> org.apache.felix.prefs.jndi/
> org.apache.felix.upnp/
>
> The first two allow for other service implementations (e.g., HTTP based on
> Tomcat or Prefs based on files). For UPnP, it seems to me that multiple
> implementations are less likely, so I didn't propose any
> sub-package...UPnP implementation packages could be renamed later if
> another implementation comes along.
>
> I assume that we will get a Log Service before long, so that will likely
> be something like:
>
> trunk/
> org.apache.felix.log.simple/
> org.apache.felix.log.postgres/
>
> Summarizing, we end up with the trunk/ directory being a flat list of
> subprojects named after their package.
>
> Thoughts?
>
> -> richard
Re: Repository/package structure
Posted by st...@insa-lyon.fr.
Hello all,
I've two comments.
It seems that it is mainly a package oriented structure.
I wonder how bundles and versions are held.
Is </trunk/>org.apache.felix.shell/ a package, a service or the bundle name ?
At the begining it is package, but at the end you speak of services
(http). Do you map 1 to 1 ?
/stephane
On Wed, Nov 30, 2005 at 03:53:22PM -0500, Richard S. Hall wrote:
> Hello,
>
> It seems that we have a few contributions nearly ready for the
> repository. It might be worthwhile if we talk about repository and
> package structure, since this issue will come up as soon as everything
> is in order for the code contributions.
>
> We sort of had this discussion earlier, but it is not clear to me that
> we came away with a final consensus. I think we just said we will defer
> until we need to do something...well, now we need to do something. :-)
>
> I propose that the trunk directory contain a directory for each
> subproject, where the subproject directory name is the package name of
> the root package of the subproject. Taking the framework as an example:
>
> trunk/
> org.apache.felix.framework/
>
> Of course, for the framework we will need to move some other things
> around since it currently contains some bundles, so we might end up with:
>
> trunk/
> org.apache.felix.framework/
> org.apache.felix.shell/
> org.apache.felix.shell.tui/
> org.apache.felix.bundlerepository/
>
> The shell and bundlerepository subprojects include default
> implementations that could be moved up to top-level subprojects if
> deemed necessary in the future, such as if we eventually have multiple
> implementations available of our own services.
>
> For our outstanding contributions (i.e., UPnP, HTTP Service, and
> Preferences Service) , I propose the following:
>
> trunk/
> org.apache.felix.http.jetty/
> org.apache.felix.prefs.jndi/
> org.apache.felix.upnp/
>
> The first two allow for other service implementations (e.g., HTTP based
> on Tomcat or Prefs based on files). For UPnP, it seems to me that
> multiple implementations are less likely, so I didn't propose any
> sub-package...UPnP implementation packages could be renamed later if
> another implementation comes along.
>
> I assume that we will get a Log Service before long, so that will likely
> be something like:
>
> trunk/
> org.apache.felix.log.simple/
> org.apache.felix.log.postgres/
>
> Summarizing, we end up with the trunk/ directory being a flat list of
> subprojects named after their package.
>
> Thoughts?
>
> -> richard
--
Stephane Frenot - Associate professor |
CITI/INRIA Ares - INSA lyon | mailto:stephane.frenot@insa-lyon.fr
Bat. Léonard de Vinci | http://ares.insa-lyon.fr/~sfrenot/
21 av Jean Capelle | ICQ:643346 (et oui !)
69621 Villeurbanne Cedex | +33 472 436 422 / +33 617 671 714
----------------------------------------------------------------------------
Re: Repository/package structure
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Rob Walker wrote:
> I did wonder whether 'http.oscar' could be an alternative - http.jetty
> is completely accurate in the sense we bundle jetty, but I quite liked
> the "tribute" aspect of classing this as the "oscar http
> implementation", to reflect it's heritage. Maybe i'm just being
> needlessly nostalgic there though.
>
> I'd be happy to contribute our Log as log.simple (or maybe log.oscar)
> unless others have better. Also be happy to participate in discussion
> the best marge/blend of various Log services, and other technologies
> like Log4j as we discusssed.
I don't have a strong opinion on this one way or the other. However,
part of me is a little gun shy of trying to maintain legacy ties given
what happened last time I tried. :-o
-> richard
Re: Repository/package structure
Posted by Rob Walker <ro...@ascert.com>.
Richard
Nice job.. I hate devising package naming, always seems to be an
impossible balance of trying to include n-dimensions of
project/service/bundle/implementor names in a reasonable length package
name. These seem to strike the right balance to me.
I did wonder whether 'http.oscar' could be an alternative - http.jetty
is completely accurate in the sense we bundle jetty, but I quite liked
the "tribute" aspect of classing this as the "oscar http
implementation", to reflect it's heritage. Maybe i'm just being
needlessly nostalgic there though.
I'd be happy to contribute our Log as log.simple (or maybe log.oscar)
unless others have better. Also be happy to participate in discussion
the best marge/blend of various Log services, and other technologies
like Log4j as we discusssed.
Regards
-- Rob
Richard S. Hall wrote:
> Hello,
>
> It seems that we have a few contributions nearly ready for the
> repository. It might be worthwhile if we talk about repository and
> package structure, since this issue will come up as soon as everything
> is in order for the code contributions.
>
> We sort of had this discussion earlier, but it is not clear to me that
> we came away with a final consensus. I think we just said we will
> defer until we need to do something...well, now we need to do
> something. :-)
>
> I propose that the trunk directory contain a directory for each
> subproject, where the subproject directory name is the package name of
> the root package of the subproject. Taking the framework as an example:
>
> trunk/
> org.apache.felix.framework/
>
> Of course, for the framework we will need to move some other things
> around since it currently contains some bundles, so we might end up with:
>
> trunk/
> org.apache.felix.framework/
> org.apache.felix.shell/
> org.apache.felix.shell.tui/
> org.apache.felix.bundlerepository/
>
> The shell and bundlerepository subprojects include default
> implementations that could be moved up to top-level subprojects if
> deemed necessary in the future, such as if we eventually have multiple
> implementations available of our own services.
>
> For our outstanding contributions (i.e., UPnP, HTTP Service, and
> Preferences Service) , I propose the following:
>
> trunk/
> org.apache.felix.http.jetty/
> org.apache.felix.prefs.jndi/
> org.apache.felix.upnp/
>
> The first two allow for other service implementations (e.g., HTTP
> based on Tomcat or Prefs based on files). For UPnP, it seems to me
> that multiple implementations are less likely, so I didn't propose any
> sub-package...UPnP implementation packages could be renamed later if
> another implementation comes along.
>
> I assume that we will get a Log Service before long, so that will
> likely be something like:
>
> trunk/
> org.apache.felix.log.simple/
> org.apache.felix.log.postgres/
>
> Summarizing, we end up with the trunk/ directory being a flat list of
> subprojects named after their package.
>
> Thoughts?
>
> -> richard
>
--
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
Re: Repository/package structure
Posted by Enrique Rodriguez <en...@gmail.com>.
Richard S. Hall wrote:
> I am in agreement with Enrique on this one. I would not like to see the
> test cases for each sub-project be a sub-project in the trunk/
> directory, because this will pollute the trunk/ directory by doubling
> its contents. I think each sub-project should put its test cases inside
> of its trunk/sub-project/ directory. The only tests that should
> potentially be in the trunk/ directory are those that span multiple
> sub-projects, I think.
Great, that's what I was thinking. Test bundles make sense for
integration tests, ie tests that require 1..n bundles together in a
container.
Enrique
Re: Repository/package structure
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Well, I believe that for Maven2 we are supposed to have one JAR file per
subproject, although it does seem that this could result in lots of
small subprojects. Maybe someone has more ideas on this subject.
-> richard
Francesco Furfari wrote:
> Yes, the base driver now is splitted in two bundles : badriver and
> basedriver-extra
> more we have a bundle for the Generic Control Point utility
> and some demo bundles to show the basedriver working on the OSGi side
>
> another question is related to the patched CyblerLink libraries that
> Stefano mantain aligned with
> Satoshi versioning.
>
> more recently Nico Goeminne as donated to us a backported (Java
> 1.3.1) version of the Basedriver (and extra and patched cyberlink)
> that we should mantain separately.
>
>
> ff
>
>
> Richard S. Hall ha scritto:
>
>> I am fine with having a separate sub-directory for src and test, but
>> I think in that case it makes sense to keep package names the same,
>> e.g.:
>>
>> trunk/
>> org.apache.felix.upnp/
>> src/
>> org/apache/felix/upnp/basedriver
>> ...
>> test/
>> org/apache/felix/upnp/basedriver
>> ...
>>
>> It seems a benefit of this approach is that you can have package
>> private access.
>>
>> One thing to point out, however, is that I was under some
>> understanding that there was supposed to be one JAR file
>> per-subproject mapping. Does UPnP get packaged into multiple bundles?
>> If so, we will need to create a trunk/ subproject directory for each
>> one.
>>
>> -> richard
>>
>> Francesco Furfari wrote:
>>
>>> No, it should be
>>> trunk/
>>> org.apache.felix.upnp/
>>> src/
>>> org/apache/felix/upnp/
>>> basedriver/*.java
>>> controlPoint/*.java
>>> samples/*.java
>>> otherComponents/*.java
>>>
>>> for the source code,
>>> now for the testcases code we could use
>>> trunk/
>>> org.apache.felix.upnp/
>>> src/
>>> test/
>>>
>>> or
>>>
>>> trunk/
>>> org.apache.felix.upnp/
>>> src/
>>> org/apache/felix/upnp/
>>> basedriver/test/*.java
>>> controlPoint/test/*.java
>>> samples/test/*.java
>>> otherComponents/test/*.java
>>>
>>> does it sound good for you?
>>> what do you prefer? we haven't testcase yet.
>>>
>>> ff
>>>
>>>
>>> Richard S. Hall ha scritto:
>>>
>>>> If I understand everything correctly, under the current proposal
>>>> you would have this:
>>>>
>>>> trunk/
>>>> org.apache.felix.upnp.basedriver/
>>>> src/org/apache/felix/upnp/basedriver/*.java
>>>> src/org/apache/felix/upnp/basedriver/test/*.java
>>>>
>>>> Note that the trunk/ directory contains sub-project directories
>>>> named after the sub-projects package name. We do not have an org/
>>>> directory in the trunk/ directory.
>>>>
>>>> -> richard
>>>>
>>>> Francesco Furfari wrote:
>>>>
>>>>> so in the repository we have
>>>>> trunk/org/apache/felix/upnp/src[org.apache.felix.upnp.basedriver]
>>>>> and
>>>>> trunk/org/apache/felix/upnp/test[org.apache.felix.upnp.basedriverTest]
>>>>>
>>>>> where [org.apache.felix.upnp.*] are the folders for packaging
>>>>>
>>>>> is it right?
>>>>> francesco
>>>>>
>>>>> Richard S. Hall ha scritto:
>>>>>
>>>>>> I am in agreement with Enrique on this one. I would not like to
>>>>>> see the test cases for each sub-project be a sub-project in the
>>>>>> trunk/ directory, because this will pollute the trunk/ directory
>>>>>> by doubling its contents. I think each sub-project should put its
>>>>>> test cases inside of its trunk/sub-project/ directory. The only
>>>>>> tests that should potentially be in the trunk/ directory are
>>>>>> those that span multiple sub-projects, I think.
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>> Enrique Rodriguez wrote:
>>>>>>
>>>>>>> Richard S. Hall wrote:
>>>>>>>
>>>>>>>> Francesco Furfari wrote:
>>>>>>>>
>>>>>>>>> It's ok for me, we have a similar structure.
>>>>>>>>> What for the test cases? do we put all inside the subprojects?
>>>>>>>>> org.apache.felix.upnp.test?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This seems to make more sense to me, as opposed to
>>>>>>>> org.apache.felix.test.upnp...but I can go either way.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I was picturing implementation code and testcases in the same
>>>>>>> subproject, but in separate source folders. During packaging,
>>>>>>> the testcases are not included in the resulting jar/bundle.
>>>>>>>
>>>>>>> Is this what the separate bundle for tests is for or is the test
>>>>>>> subproject specifically for some sort of integration tests, ie
>>>>>>> tests against the public API? Where do per-class unit tests
>>>>>>> go? I would like some help understanding this practice.
>>>>>>>
>>>>>>> Enrique
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
Re: Repository/package structure
Posted by Francesco Furfari <fr...@isti.cnr.it>.
Yes, the base driver now is splitted in two bundles : badriver and
basedriver-extra
more we have a bundle for the Generic Control Point utility
and some demo bundles to show the basedriver working on the OSGi side
another question is related to the patched CyblerLink libraries that
Stefano mantain aligned with
Satoshi versioning.
more recently Nico Goeminne as donated to us a backported (Java 1.3.1)
version of the Basedriver (and extra and patched cyberlink) that we
should mantain separately.
ff
Richard S. Hall ha scritto:
> I am fine with having a separate sub-directory for src and test, but I
> think in that case it makes sense to keep package names the same, e.g.:
>
> trunk/
> org.apache.felix.upnp/
> src/
> org/apache/felix/upnp/basedriver
> ...
> test/
> org/apache/felix/upnp/basedriver
> ...
>
> It seems a benefit of this approach is that you can have package
> private access.
>
> One thing to point out, however, is that I was under some
> understanding that there was supposed to be one JAR file
> per-subproject mapping. Does UPnP get packaged into multiple bundles?
> If so, we will need to create a trunk/ subproject directory for each one.
>
> -> richard
>
> Francesco Furfari wrote:
>
>> No, it should be
>> trunk/
>> org.apache.felix.upnp/
>> src/
>> org/apache/felix/upnp/
>> basedriver/*.java
>> controlPoint/*.java
>> samples/*.java
>> otherComponents/*.java
>>
>> for the source code,
>> now for the testcases code we could use
>> trunk/
>> org.apache.felix.upnp/
>> src/
>> test/
>>
>> or
>>
>> trunk/
>> org.apache.felix.upnp/
>> src/
>> org/apache/felix/upnp/
>> basedriver/test/*.java
>> controlPoint/test/*.java
>> samples/test/*.java
>> otherComponents/test/*.java
>>
>> does it sound good for you?
>> what do you prefer? we haven't testcase yet.
>>
>> ff
>>
>>
>> Richard S. Hall ha scritto:
>>
>>> If I understand everything correctly, under the current proposal you
>>> would have this:
>>>
>>> trunk/
>>> org.apache.felix.upnp.basedriver/
>>> src/org/apache/felix/upnp/basedriver/*.java
>>> src/org/apache/felix/upnp/basedriver/test/*.java
>>>
>>> Note that the trunk/ directory contains sub-project directories
>>> named after the sub-projects package name. We do not have an org/
>>> directory in the trunk/ directory.
>>>
>>> -> richard
>>>
>>> Francesco Furfari wrote:
>>>
>>>> so in the repository we have
>>>> trunk/org/apache/felix/upnp/src[org.apache.felix.upnp.basedriver]
>>>> and
>>>> trunk/org/apache/felix/upnp/test[org.apache.felix.upnp.basedriverTest]
>>>> where [org.apache.felix.upnp.*] are the folders for packaging
>>>>
>>>> is it right?
>>>> francesco
>>>>
>>>> Richard S. Hall ha scritto:
>>>>
>>>>> I am in agreement with Enrique on this one. I would not like to
>>>>> see the test cases for each sub-project be a sub-project in the
>>>>> trunk/ directory, because this will pollute the trunk/ directory
>>>>> by doubling its contents. I think each sub-project should put its
>>>>> test cases inside of its trunk/sub-project/ directory. The only
>>>>> tests that should potentially be in the trunk/ directory are those
>>>>> that span multiple sub-projects, I think.
>>>>>
>>>>> -> richard
>>>>>
>>>>> Enrique Rodriguez wrote:
>>>>>
>>>>>> Richard S. Hall wrote:
>>>>>>
>>>>>>> Francesco Furfari wrote:
>>>>>>>
>>>>>>>> It's ok for me, we have a similar structure.
>>>>>>>> What for the test cases? do we put all inside the subprojects?
>>>>>>>> org.apache.felix.upnp.test?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This seems to make more sense to me, as opposed to
>>>>>>> org.apache.felix.test.upnp...but I can go either way.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I was picturing implementation code and testcases in the same
>>>>>> subproject, but in separate source folders. During packaging,
>>>>>> the testcases are not included in the resulting jar/bundle.
>>>>>>
>>>>>> Is this what the separate bundle for tests is for or is the test
>>>>>> subproject specifically for some sort of integration tests, ie
>>>>>> tests against the public API? Where do per-class unit tests go?
>>>>>> I would like some help understanding this practice.
>>>>>>
>>>>>> Enrique
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
Re: Repository/package structure
Posted by "Richard S. Hall" <he...@ungoverned.org>.
But even for fragments [yuck] to come into play, we need the src and
test code to have the same package name for them to have the possibility
of package private access...that is what I was trying to say with my
comment.
How the test code is packaged is another issue, in which case, fragments
[yuck] would work.
;-)
-> richard
Thomas Watson wrote:
> "Richard S. Hall" <he...@ungoverned.org> wrote on 12/01/2005 02:10:18 PM:
>
>
>> I am fine with having a separate sub-directory for src and test, but I
>> think in that case it makes sense to keep package names the same, e.g.:
>>
>> trunk/
>> org.apache.felix.upnp/
>> src/
>> org/apache/felix/upnp/basedriver
>> ...
>> test/
>> org/apache/felix/upnp/basedriver
>> ...
>>
>> It seems a benefit of this approach is that you can have package private
>>
>
>
>> access.
>>
>> One thing to point out, however, is that I was under some understanding
>> that there was supposed to be one JAR file per-subproject mapping. Does
>> UPnP get packaged into multiple bundles? If so, we will need to create a
>>
>
>
>> trunk/ subproject directory for each one.
>>
>> -> richard
>>
>>
>
> This is a usecase for fragments, right? You do not want to package
> your testcase code in with your normal bundle. Your testcase code is
> contained in a fragment of the bundle you are testing. This will
> give you package level access even though the code is contained in
> another bundle fragment. Some of junit tests in Eclipse use this
> same approach. In Eclipse the tests are stored in a completely
> separate project directory. This is because Eclipse keeps a
> 1-to-1 mapping between projects and bundles.
>
> I know how much Richard loves fragments :-)
>
> Tom.
>
>
Re: Repository/package structure
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Richard S. Hall wrote, On 12/2/2005 6:51 AM:
> Alan D. Cabrera wrote:
>
>> I'm glad you brought this up. Maven 2 is great if you do things the
>> maven 2 way. Things go really bad, if you try to adopt your own
>> strategy. This is a good thing. imho, since maven 2 is kindof a
>> revolt against the millions of ways that ant projects can be setup.
>>
>> Here is what would be a vanilla maven 2 setup:
>>
>> trunk/
>> felix-framework/
>> felix-shell/
>> felix-shell-tui/
>> felix-bundlerepository/
>> felix-http-jetty/
>> felix-prefs-jndi/
>> felix-upnp/
>> felix-log-simple/
>> felix-log-postgres/
>>
>> Each project would have the following structure
>>
>> src/
>> main/
>> java/
>> org/apache/felix/...
>> resources/
>> test/
>> java/
>> org/apache/felix/...
>> resources/
>
>
> Well, I am not totally against this structure, but it does somewhat
> suck for people like me who still regularly use the command line to
> keep making our paths deeper and deeper.
>
>> Anything that's in test, never makes it into the bundle that's produced.
>
>
> However, our tests may be packaged as a [potentially separate] bundle...
You can easily make separate test bundles by adding a <phase> element to
your plugin. The test bundle never gets deployed out into the repositories.
Regards,
Alan
Re: IDE Lockin? (was Re: Repository/package structure)
Posted by Alex Karasulu <ao...@bellsouth.net>.
Ersin Er wrote:
>On 12/3/05, Richard S. Hall <he...@ungoverned.org> wrote:
>
>
>>Sure, but it is still annoying. To me creating a directory structure in
>>advance that covers all basis, like mixed language development, is sort
>>of like pre-optimizing your code...you should avoid doing it. Most of
>>our subprojects will never use a language other than Java, so it is
>>fairly pointless to have that level of structure.
>>
>>
>
>The "java" named directory is there to seperate application code from
>"resources", "filters" and other things more then supplying an
>infrastructure for other language implementations (this is very
>unusual). Here is the m2 standard directory layout doco:
>
>http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>
>I do favor m2 guys' advices to be able to free my mind about future
>project structure flexibility requirements.
>
>
Very good point. They, the maven folks, know their stuff and have
thought this through. Richard this explains why they hava 'java'. It's
not just to differentiate/organize based on language.
I just wish everyone can come to agreement on the project layout
structure and the remote repo structure which is yet another ball of
wax: obr, maven repos, and update sites etc.
Alex
Re: IDE Lockin? (was Re: Repository/package structure)
Posted by Ersin Er <er...@gmail.com>.
On 12/3/05, Richard S. Hall <he...@ungoverned.org> wrote:
> Sure, but it is still annoying. To me creating a directory structure in
> advance that covers all basis, like mixed language development, is sort
> of like pre-optimizing your code...you should avoid doing it. Most of
> our subprojects will never use a language other than Java, so it is
> fairly pointless to have that level of structure.
The "java" named directory is there to seperate application code from
"resources", "filters" and other things more then supplying an
infrastructure for other language implementations (this is very
unusual). Here is the m2 standard directory layout doco:
http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
I do favor m2 guys' advices to be able to free my mind about future
project structure flexibility requirements.
> It seems like it wouldn't be unreasonable for Maven to support some sort
> of graduated level approach, so the structure could be tuned to the
> desire of the develop and the project scope. I like things to start
> simple and grow complex, not just start complex. ;-)
>
> Let me reiterate, however, that I don't think that this is a huge
> obstacle, just an annoyance.
>
> -> richard
>
Cheers,
--
Ersin
Re: IDE Lockin? (was Re: Repository/package structure)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Alex Karasulu wrote:
>>
>> Well, I am not totally against this structure, but it does somewhat
>> suck for people like me who still regularly use the command line to
>> keep making our paths deeper and deeper.
>>
>>
>
> I'm all about the command line too Richard. The pain of these extra
> directories is emeliorated by tab completion, pushd, and popd.
Sure, but it is still annoying. To me creating a directory structure in
advance that covers all basis, like mixed language development, is sort
of like pre-optimizing your code...you should avoid doing it. Most of
our subprojects will never use a language other than Java, so it is
fairly pointless to have that level of structure.
It seems like it wouldn't be unreasonable for Maven to support some sort
of graduated level approach, so the structure could be tuned to the
desire of the develop and the project scope. I like things to start
simple and grow complex, not just start complex. ;-)
Let me reiterate, however, that I don't think that this is a huge
obstacle, just an annoyance.
-> richard
Re[4]: IDE Lockin? (was Re: Repository/package structure)
Posted by Peter Kriens <Pe...@aQute.se>.
I took this offline because the scope of this discussion is not felix
anymore :-)
Kind regards,
Peter Kriens
JM> Peter Kriens <Pe...@aQute.se> wrote on 12/05/2005 02:15:35 AM:
>> JM> and some tooling even has graphical editors and wizards for it. If
JM> you
>> JM> pick some other format then you start duplicating the info in the
JM> manifest
>> JM> and have to start talking about tooling for it etc etc.
>> That is very restrictive implying that you can never generate the
>> import statements. I have been making bundles for 8 years now and the
>> greatest improvement I ever had was when I could leave the imports up
>> to btool. I generate the manifest from a template, so duplication is
>> not an issue.
JM> How does btool manage the import version ranges and export version
JM> numbers? I can see where it would be able to generate the list of
JM> packages needed but not their versions. The btool function is indeed
JM> useful (we are in the process of adding similar function to PDE). The use
JM> of manifests is not a limitation in doing this.
JM> The point here is that developers really do have to manage this
JM> information. To them the underlying representation is not important.
JM> Implicit in what you propose is a duplicate form of metadata that has to
JM> capture the same kind of info that is already in the manifest. Tooling
JM> needs to understand both then because some things it manipulates has
JM> manifests (they are already built) and some don't (they are being built).
JM> This new metadata format has to somehow facilitate all the nuances of the
JM> manifest.mf but the syntax/form will be different. This is painful. Also,
JM> it implies that things like editors have to be duplicated as well.
JM> In the end, I don't see a real benefit here. Information that can be
JM> generated can be generated into a manifest. Information that has to be
JM> entered by users can be entered into that same manifest. The runtime and
JM> the tooling can all use that manifest. One syntax. One file. Simple.
>> I really think (ab)using the manifest as an input instead of the
>> traditional output is a wrong idea because it was just not intended to
>> be an input. For the R4 build I tried to do it but it became too
>> artificial.
JM> Here in lies our disconnect. There is a whole mess of information in the
JM> manifest that has to be crafted/specified by a developer. Things like the
JM> version ranges and export versions, the choice between Import-Package and
JM> Require-Bundle, fragment hosting, .... Setting things up so that you can
JM> spec this in a different file in a different syntax seems
JM> counterproductive.
>> Also, the classpath is a wider issue. I frequently created multiple
>> bundles from a single project. Our test suites use many bundles per
>> test suite sometimes up to 20 per testcase, it would be dramatic if
>> they all had to become their own project (which I think is implied by
>> your manifest model).
JM> This is actually not a manifest issue but a classpath management issue. To
JM> get a highly accurate classpath you have to compile each bundle on its own
JM> (so that you can control visibility correctly). This implies separate
JM> build structures. In the Eclipse case that means separate projects. Don't
JM> know what it means in Maven or any other setup.
JM> Project sets and working sets in Eclipse help you manage collections of
JM> projects but yes, having lots can still be an issue depending on what you
JM> do. Note that this does not particularly impact you if you are not using
JM> Eclipse since you don;t have projects. There is relatively little that is
JM> magic about being a project. You just have to have a .project file and
JM> .classpath file that points to the source folders for the project. You
JM> can inject these into many different repo/source structures and does not
JM> impact your ability to use other tooling (IDEA, javac, ...).
>> And about the graphic editors ... I wish there was a way to disable
>> them :-( They seem to be always in the way and too focused on Eclipse
>> features instead of simple bundles.
JM> I think you should be looking at the latest Eclipse builds. You will find
JM> very few references to Eclipse-specific pieces (other than the use of the
JM> term "plugin" vs. "bundle"). We are actively and aggressively seeking to
JM> make PDE a first-class bundle development environment so for those who
JM> care, please get Eclipse 3.2 M4 (end of next week) and try the tooling.
JM> Let us know what you don't like.
JM> Jeff
--
Peter Kriens Tel +33870447986
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Re[2]: IDE Lockin? (was Re: Repository/package structure)
Posted by Jeff McAffer <Je...@ca.ibm.com>.
Peter Kriens <Pe...@aQute.se> wrote on 12/05/2005 02:15:35 AM:
> JM> and some tooling even has graphical editors and wizards for it. If
you
> JM> pick some other format then you start duplicating the info in the
manifest
> JM> and have to start talking about tooling for it etc etc.
> That is very restrictive implying that you can never generate the
> import statements. I have been making bundles for 8 years now and the
> greatest improvement I ever had was when I could leave the imports up
> to btool. I generate the manifest from a template, so duplication is
> not an issue.
How does btool manage the import version ranges and export version
numbers? I can see where it would be able to generate the list of
packages needed but not their versions. The btool function is indeed
useful (we are in the process of adding similar function to PDE). The use
of manifests is not a limitation in doing this.
The point here is that developers really do have to manage this
information. To them the underlying representation is not important.
Implicit in what you propose is a duplicate form of metadata that has to
capture the same kind of info that is already in the manifest. Tooling
needs to understand both then because some things it manipulates has
manifests (they are already built) and some don't (they are being built).
This new metadata format has to somehow facilitate all the nuances of the
manifest.mf but the syntax/form will be different. This is painful. Also,
it implies that things like editors have to be duplicated as well.
In the end, I don't see a real benefit here. Information that can be
generated can be generated into a manifest. Information that has to be
entered by users can be entered into that same manifest. The runtime and
the tooling can all use that manifest. One syntax. One file. Simple.
> I really think (ab)using the manifest as an input instead of the
> traditional output is a wrong idea because it was just not intended to
> be an input. For the R4 build I tried to do it but it became too
> artificial.
Here in lies our disconnect. There is a whole mess of information in the
manifest that has to be crafted/specified by a developer. Things like the
version ranges and export versions, the choice between Import-Package and
Require-Bundle, fragment hosting, .... Setting things up so that you can
spec this in a different file in a different syntax seems
counterproductive.
> Also, the classpath is a wider issue. I frequently created multiple
> bundles from a single project. Our test suites use many bundles per
> test suite sometimes up to 20 per testcase, it would be dramatic if
> they all had to become their own project (which I think is implied by
> your manifest model).
This is actually not a manifest issue but a classpath management issue. To
get a highly accurate classpath you have to compile each bundle on its own
(so that you can control visibility correctly). This implies separate
build structures. In the Eclipse case that means separate projects. Don't
know what it means in Maven or any other setup.
Project sets and working sets in Eclipse help you manage collections of
projects but yes, having lots can still be an issue depending on what you
do. Note that this does not particularly impact you if you are not using
Eclipse since you don;t have projects. There is relatively little that is
magic about being a project. You just have to have a .project file and
.classpath file that points to the source folders for the project. You
can inject these into many different repo/source structures and does not
impact your ability to use other tooling (IDEA, javac, ...).
> And about the graphic editors ... I wish there was a way to disable
> them :-( They seem to be always in the way and too focused on Eclipse
> features instead of simple bundles.
I think you should be looking at the latest Eclipse builds. You will find
very few references to Eclipse-specific pieces (other than the use of the
term "plugin" vs. "bundle"). We are actively and aggressively seeking to
make PDE a first-class bundle development environment so for those who
care, please get Eclipse 3.2 M4 (end of next week) and try the tooling.
Let us know what you don't like.
Jeff
Re[2]: IDE Lockin? (was Re: Repository/package structure)
Posted by Peter Kriens <Pe...@aQute.se>.
JM> and some tooling even has graphical editors and wizards for it. If you
JM> pick some other format then you start duplicating the info in the manifest
JM> and have to start talking about tooling for it etc etc.
That is very restrictive implying that you can never generate the
import statements. I have been making bundles for 8 years now and the
greatest improvement I ever had was when I could leave the imports up
to btool. I generate the manifest from a template, so duplication is
not an issue.
I really think (ab)using the manifest as an input instead of the
traditional output is a wrong idea because it was just not intended to
be an input. For the R4 build I tried to do it but it became too
artificial.
Also, the classpath is a wider issue. I frequently created multiple
bundles from a single project. Our test suites use many bundles per
test suite sometimes up to 20 per testcase, it would be dramatic if
they all had to become their own project (which I think is implied by
your manifest model).
And about the graphic editors ... I wish there was a way to disable
them :-( They seem to be always in the way and too focused on Eclipse
features instead of simple bundles.
If the .classpath does not support this model, I sure hope Apache will
specify a format that they will support :-(
Kind regards,
Peter Kriens
JM> Peter Kriens <Pe...@aQute.se> wrote on 12/03/2005 06:41:02 AM:
>> One thing that might solve the dichotomy between tool lock in and
>> flexibility to change IDEs is to have standard file format for the
>> dependencies.
JM> Errr, the OSGi bundle manifest is standard and hey its even there already
JM> in bundles. It's relatively simple, there is excellent documentation :-)
JM> and some tooling even has graphical editors and wizards for it. If you
JM> pick some other format then you start duplicating the info in the manifest
JM> and have to start talking about tooling for it etc etc.
>> I am using the Eclipse .classpath file in btool, but I made the parser
>> pluggable so I can support other dependency files as well. If
>> Felix/Apache just selects a standard format for declaring the
>> dependencies, then
>> it should not be that hard for Eclipse to support this format with a
>> plugin.
JM> The Eclipse .classpath file is very brittle for use in this way. Eclipse
JM> PDE just reads the bundle manifest file. It completely generates the
JM> classpath. The .classpath file really isn't used in normal bundle
JM> development with PDE.
JM> Jeff
--
Peter Kriens Tel +33870447986
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: IDE Lockin? (was Re: Repository/package structure)
Posted by Jeff McAffer <Je...@ca.ibm.com>.
Peter Kriens <Pe...@aQute.se> wrote on 12/03/2005 06:41:02 AM:
> One thing that might solve the dichotomy between tool lock in and
> flexibility to change IDEs is to have standard file format for the
> dependencies.
Errr, the OSGi bundle manifest is standard and hey its even there already
in bundles. It's relatively simple, there is excellent documentation :-)
and some tooling even has graphical editors and wizards for it. If you
pick some other format then you start duplicating the info in the manifest
and have to start talking about tooling for it etc etc.
> I am using the Eclipse .classpath file in btool, but I made the parser
> pluggable so I can support other dependency files as well. If
> Felix/Apache just selects a standard format for declaring the
> dependencies, then
> it should not be that hard for Eclipse to support this format with a
> plugin.
The Eclipse .classpath file is very brittle for use in this way. Eclipse
PDE just reads the bundle manifest file. It completely generates the
classpath. The .classpath file really isn't used in normal bundle
development with PDE.
Jeff
Re: IDE Lockin? (was Re: Repository/package structure)
Posted by Peter Kriens <Pe...@aQute.se>.
One thing that might solve the dichotomy between tool lock in and
flexibility to change IDEs is to have standard file format for the
dependencies.
I am using the Eclipse .classpath file in btool, but I made the parser
pluggable so I can support other dependency files as well. If
Felix/Apache just selects a standard format for declaring the dependencies, then
it should not be that hard for Eclipse to support this format with a
plugin.
In the current OSGi build (>700 bundles) you can use any IDE and the
build is done with ant. Eclipse users have an advantage, but it is
absolutely not a requirement to use Eclipse. Emacs and vi are well
supported :-)
Kind regards,
Peter Kriens
AK> Jeff McAffer wrote:
>>and of course, it is not particularly useful to an Eclipse-based
>>developer. The good thing about PDE is that it directly and inherently
>>supports OSGi bundle development with extremely accurate classpath
>>renditions and tooling for maintaining versions etc. It also puts in
>>place a simplified process that means you don't have to think about
>>project structure much. Of course, this clashes directly with Maven's
>>simplified process :-)
>>
>>
AK> Question is: Do we want to have IDE lock in? Won't we alienate
AK> contributors and perspective committers if we force them to use a
AK> particular IDE?
AK> I must admit I'm loving eclipse today. Here's what happened to me over
AK> the years where IDE's are concerned:
AK> Vi/Emacs JDE (pre 2001) ->
JEdit (2002) ->>
Eclipse (2003) ->>
AK> IntelliJ IDEA (2004) ->
AK> Eclipse (Today)
AK> As you can see I change my mind frequently. I'll use what is best for
AK> the task at hand. Now a days Eclipse is really kicking arse all over:
AK> speed, features, support for j2me, j2ee, and of course for OSGi, for web
AK> dev with WTP stuff the list goes on and on. It's looking really good
AK> these days coming from a guy who favors the command line over UI. FYI I
AK> just switched from IDEA which is a fat pig now with 5.0. Eclipse 3.1 is
AK> also faster and has this excellent PDE tool (nice job btw). IDEA
AK> however is just pleaseant to program with. It's far superior to any
AK> other IDE I've used so far. I think it's slicker yet lacks the features
AK> and speed of Eclipse hence my recent switch.
AK> Anyway the point is not which IDE do we use. This is not a question for
AK> us to answer. We cannot alienate users of other IDEs. Like I said
AK> yesterday I was an Intellij IDEA user and still want to reserve the
AK> right to switch IDE's if Eclipse does not meet my needs in the future.
AK> This does not mean I favor any IDE ultimately. I change with the wind.
AK> I would like to retain this freedom and to protect others that want to
AK> develope with any IDE as part of this community.
AK> Jeff, and other Eclipse peeps, please don't take this personally. We're
AK> here to maximize freedom for our community not to constrain them to a
AK> particular IDE. We need a tool that allows us to generate descriptors
AK> for various IDEs. And thus we should try to conform to it's layout what
AK> ever that may be. Plus as another requirement the tool should be a CLI
AK> tool that allows for headless builds. CI is a plus.
>>>src/
>>> main/
>>> java/
>>> org/apache/felix/...
>>> resources/
>>> test/
>>> java/
>>> org/apache/felix/...
>>> resources/
>>>
>>>
>>
>>Well, I am not totally against this structure, but it does somewhat suck
>>for people like me who still regularly use the command line to keep
>>making our paths deeper and deeper.
>>
>>
AK> I'm all about the command line too Richard. The pain of these extra
AK> directories is emeliorated by tab completion, pushd, and popd.
AK> Side note: No offense to anyone but I don't trust IDEs since they dumb
AK> things down. I can't stand it when tools obscure simple tasks to
AK> accomodate challenged users while creating havoc for those that know
AK> what they're doing. I cannot count the number of times some IDE plugin
AK> has screwed up my SVN working directory or messed up an ant/maven
AK> descriptor. Is it getting better and better every day? Yes for sure it
AK> is but we cannot *unfortunately* give up on the more tedious command line.
AK> Alex
--
Peter Kriens Tel +33870447986
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: IDE Lockin? (was Re: Repository/package structure)
Posted by Enrique Rodriguez <en...@gmail.com>.
Jeff McAffer wrote:
> Enrique wins the prize. Have to wait for ApacheCon to see what that is...
>
> I've always wondered: If it is 99 44/100 pure, what is the other 56/100?
> Impure? But impure what?
uncombined alkali, 0.11%
carbonates, 0.28%
mineral matter, 0.17%
Total: 0.56%.
http://www.straightdope.com/classics/a930820.html
Enrique
Re: IDE Lockin? (was Re: Repository/package structure)
Posted by Jeff McAffer <Je...@ca.ibm.com>.
Enrique wins the prize. Have to wait for ApacheCon to see what that is...
I've always wondered: If it is 99 44/100 pure, what is the other 56/100?
Impure? But impure what?
Jeff
p.s., for those not indocrinated with North American culture (or too young
:-) this is from an Ivory soap commercial. Apparently soap that floats
is inherently pure and good. Who knows. Sorry to distract from the
topic at hand.
Enrique Rodriguez <en...@gmail.com>
12/05/2005 04:34 PM
Please respond to
felix-dev
To
felix-dev@incubator.apache.org
cc
Subject
Re: IDE Lockin? (was Re: Repository/package structure)
Jeff McAffer wrote:
...
> resolver AND sophisticated classpath/compiler management. This is a key
> characteristic of PDE. The classpath used at compile time is 99 44/100%
> accurate (see who gets that reference) ...
It floats?
Enrique
Re: IDE Lockin? (was Re: Repository/package structure)
Posted by Enrique Rodriguez <en...@gmail.com>.
Jeff McAffer wrote:
...
> resolver AND sophisticated classpath/compiler management. This is a key
> characteristic of PDE. The classpath used at compile time is 99 44/100%
> accurate (see who gets that reference) ...
It floats?
Enrique
Re: IDE Lockin? (was Re: Repository/package structure)
Posted by Jeff McAffer <Je...@ca.ibm.com>.
"Alan D. Cabrera" <li...@toolazydogs.com> wrote on 12/03/2005 12:56:30 PM:
> I use Idea and there is a maven plugin that generates Idea projects w/
> the proper classpath setup from maven poms. Would it be possible to
> create such a plugin for Eclipse, if one does not exist already?
Yup, I believe there is one. This is goodness for all. The point I am
have been trying to get across however is that this approach is not
sufficient for OSGi bundle development. With this setup (even loading
into Eclipse) you are NOT getting the proper OSGi classpath setup. Maven
dependencies are equivalent to OSGi Require-Bundle. This is new for OSGi
R4 and is not at all the common way of specing dependencies in OSGi
bundles. As I'm sure Richard will tell you, Import-Package is hands down
the standard way of doing things. For this you need a complex dependency
resolver AND sophisticated classpath/compiler management. This is a key
characteristic of PDE. The classpath used at compile time is 99 44/100%
accurate (see who gets that reference) compared to the runtime classpath
on a per bundle basis. Further, bundles can say what JRE they require
(e.g., J2SE 1.4, 1.5, Foundation 1.0, ...). PDE manages this for you and
compiles individual bundles against the specified JREs.
Anyway, it likely sounds like I am trying to sell PDE. I suppose I am in
a way but it is not my main goal and I certainly don't expect Felix to
lock into Eclipse or any other IDE/tooling. I am more trying to point out
some reality so people understand that tooling and developing modularized
Java (i.e., OSGi) requires some different thought processes.
Jeff
Re: IDE Lockin? (was Re: Repository/package structure)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Jeff McAffer wrote, On 12/2/2005 6:53 PM:
>Alex Karasulu <ao...@bellsouth.net> wrote on 12/02/2005 05:03:28 PM:
>
>
>
>>Jeff McAffer wrote:
>>
>>
>>
>>>and of course, it is not particularly useful to an Eclipse-based
>>>developer. The good thing about PDE is that it directly and inherently
>>>
>>>
>
>
>
>>>supports OSGi bundle development with extremely accurate classpath
>>>renditions and tooling for maintaining versions etc. It also puts in
>>>place a simplified process that means you don't have to think about
>>>project structure much. Of course, this clashes directly with Maven's
>>>simplified process :-)
>>>
>>>
>>>
>>>
>>Question is: Do we want to have IDE lock in? Won't we alienate
>>contributors and perspective committers if we force them to use a
>>particular IDE?
>>
>>
>
>No, you don't want to have IDE lock in. To be precise here, the issue is
>tool locking not IDE lockin. Maven is dictating a file structure. Eclipse
>is dictating a file structure. The use of Maven POMs for dependency info
>defeats Eclipse;s classpath management... Other tools one might want to
>use may also be dictating things. I'm not sure which of these is more
>strict but this is the tension.
>
>Honestly, I think that both Maven and Eclipse need to get a bit more
>flexible. Jason and I have been talking about this but nothing has
>actually happened as yet. Given the open source nature of both tools and
>their growing committment to OSGi, I'm feeling that there must be some
>sort of middle ground that can be reached.
>
>
I use Idea and there is a maven plugin that generates Idea projects w/
the proper classpath setup from maven poms. Would it be possible to
create such a plugin for Eclipse, if one does not exist already?
Regards,
Alan
Re: CLI for PDE as build tool? (was: Re: IDE Lockin?)
Posted by Pascal Rapicault <pa...@yahoo.fr>.
Peter,
What you are describing already exists and is called PDE Build. It is
the mechanism used by the SDK team and most (if not all) of the other
eclipse projects to build their bundles.
It takes as input a set of bundles to build (the set is described in a
feature.xml), analyzes their manifest, create an Ant build file for
each of them and also creates a general build file orchestrating the
build.
The build script generator is an Ant task.
PaScaL
Ps: I will post here a detailed example on how to setup a PDE based
build.
On 3-Dec-05, at 1:52 PM, Peter Neubauer wrote:
> The only system right now doing that is the PDE. How about separating
> the PDE
> GUI from the PDE core (not sure if that is already there), add a
> command line
> interface to the core, and be able to run the PDE as a build tool?
> behind the
> scenes you could probably use Ant or whatever for compiling etc etc.
> and make
> the internal dependency model (read up from the manifests) exportable
> to
> interlinked POMs, RDF, Manifests or other formats. I think that would
> give
> everyone a nice start on OSGi centric build systems.
Re: CLI for PDE as build tool? (was: Re: IDE Lockin?)
Posted by Jeff McAffer <Je...@ca.ibm.com>.
Thank you Peter! This is what I have been trying to point out.
Jeff
Peter Neubauer <pe...@neubauer.se> wrote on 12/03/2005 01:52:27 PM:
> Hi Jeff,
>
> On Saturday 03 December 2005 03:53, Jeff McAffer wrote:
> > Eclipse PDE is not just a Java IDE. It does
> > full OSGi classpath modeling, complete compiler integration and
visibility
> > control, target management, multiple concurrent target JRE support,
> > import/export/dependency management, in-place launching, ... I'll be
at
> > ApacheCon and would be more than happy to show anyone who asks.
> I think that classical build systems like Maven, Ant, Ivy etc etc
> have one big
> problem with respect to OSGi - they are artifact-oriented, that is,
their
> unit of concern is the .jar artifacts and their dependencies.
> OSGi OTOH is only concerned with package import, export, dependencies
and
> versioning.
> As long as you don't have a jar containing only one package of the same
> version, therefore these tools will not be able to figure out OSGi
> dependencies beyond basic stuff.
>
> Of course, the OSGi just specifies the runtime aspect of the component,
> leaving test- and compile time dependencies untouched in the
specification
> with room for improvement.
>
> Because of this difference, IMHO there is a need for a non-generic OSGi
> centered build system that deals only with bundles and their
dependencies.
> Such a tool has to run in a OSGi container in order to utilize the
frameworks
> resolution of deps, packages, imports and exports.
It doesn't actually have to run in an OSGi container. In fact, even if it
does it has to use a different list of bundles and packages since you are
likely building things that you are not currently running and don't want
to run the things you are building. The Equinox implementation includes a
distinct state and resolver structure that is intented to be used by
tooling and provisioning mechanisms to reason about configurations of
bundles. This code is embedded in the org.eclipse.osgi JAR but in theory
could be broken out.
> The only system right now doing that is the PDE. How about separating
the PDE
> GUI from the PDE core (not sure if that is already there), add a command
line
> interface to the core, and be able to run the PDE as a build tool?
behind the
> scenes you could probably use Ant or whatever for compiling etc etc.and
make
As Pascal points out, PDE Build is what you want.
> the internal dependency model (read up from the manifests) exportable to
> interlinked POMs, RDF, Manifests or other formats. I think that would
give
> everyone a nice start on OSGi centric build systems.
Yes. We have had some preliminary discussion with the Maven folks in this
direction. We'll see where that goes...
CLI for PDE as build tool? (was: Re: IDE Lockin?)
Posted by Peter Neubauer <pe...@neubauer.se>.
Hi Jeff,
On Saturday 03 December 2005 03:53, Jeff McAffer wrote:
> Eclipse PDE is not just a Java IDE. It does
> full OSGi classpath modeling, complete compiler integration and visibility
> control, target management, multiple concurrent target JRE support,
> import/export/dependency management, in-place launching, ... I'll be at
> ApacheCon and would be more than happy to show anyone who asks.
I think that classical build systems like Maven, Ant, Ivy etc etc have one big
problem with respect to OSGi - they are artifact-oriented, that is, their
unit of concern is the .jar artifacts and their dependencies.
OSGi OTOH is only concerned with package import, export, dependencies and
versioning.
As long as you don't have a jar containing only one package of the same
version, therefore these tools will not be able to figure out OSGi
dependencies beyond basic stuff.
Of course, the OSGi just specifies the runtime aspect of the component,
leaving test- and compile time dependencies untouched in the specification
with room for improvement.
Because of this difference, IMHO there is a need for a non-generic OSGi
centered build system that deals only with bundles and their dependencies.
Such a tool has to run in a OSGi container in order to utilize the frameworks
resolution of deps, packages, imports and exports.
The only system right now doing that is the PDE. How about separating the PDE
GUI from the PDE core (not sure if that is already there), add a command line
interface to the core, and be able to run the PDE as a build tool? behind the
scenes you could probably use Ant or whatever for compiling etc etc. and make
the internal dependency model (read up from the manifests) exportable to
interlinked POMs, RDF, Manifests or other formats. I think that would give
everyone a nice start on OSGi centric build systems.
Just a thought.
/peter
Re: IDE Lockin? (was Re: Repository/package structure)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 03 December 2005 10:53, Jeff McAffer wrote:
> No, you don't want to have IDE lock in. To be precise here, the issue is
> tool locking not IDE lockin. Maven is dictating a file structure. Eclipse
> is dictating a file structure. The use of Maven POMs for dependency info
> defeats Eclipse;s classpath management... Other tools one might want to
> use may also be dictating things. I'm not sure which of these is more
> strict but this is the tension.
For us who may not be fully up-to-date of what is happening in Eclipse, do you
have some pointers on the "PDE tooling" running without the "IDE lock-in" ??
Cheers
Niclas
Re: IDE Lockin? (was Re: Repository/package structure)
Posted by Jeff McAffer <Je...@ca.ibm.com>.
Alex Karasulu <ao...@bellsouth.net> wrote on 12/02/2005 05:03:28 PM:
> Jeff McAffer wrote:
>
> >and of course, it is not particularly useful to an Eclipse-based
> >developer. The good thing about PDE is that it directly and inherently
> >supports OSGi bundle development with extremely accurate classpath
> >renditions and tooling for maintaining versions etc. It also puts in
> >place a simplified process that means you don't have to think about
> >project structure much. Of course, this clashes directly with Maven's
> >simplified process :-)
> >
> >
> Question is: Do we want to have IDE lock in? Won't we alienate
> contributors and perspective committers if we force them to use a
> particular IDE?
No, you don't want to have IDE lock in. To be precise here, the issue is
tool locking not IDE lockin. Maven is dictating a file structure. Eclipse
is dictating a file structure. The use of Maven POMs for dependency info
defeats Eclipse;s classpath management... Other tools one might want to
use may also be dictating things. I'm not sure which of these is more
strict but this is the tension.
Honestly, I think that both Maven and Eclipse need to get a bit more
flexible. Jason and I have been talking about this but nothing has
actually happened as yet. Given the open source nature of both tools and
their growing committment to OSGi, I'm feeling that there must be some
sort of middle ground that can be reached.
> Side note: No offense to anyone but I don't trust IDEs since they dumb
> things down. I can't stand it when tools obscure simple tasks to
> accomodate challenged users while creating havoc for those that know
> what they're doing. I cannot count the number of times some IDE plugin
> has screwed up my SVN working directory or messed up an ant/maven
> descriptor. Is it getting better and better every day? Yes for sure it
> is but we cannot *unfortunately* give up on the more tedious command
line.
The use of IDEs should not force you to give up on tedium. People are
free to use vi and javac to compile things. Note again it is not an IDE
thing, it is a tooling thing. Maven is doing magic even though it is a
command line tool.
One thing we have found is that developing components is hard. Its not
too bad if you are doing small things at the bottom of the stack. As you
go up it gets harder and harder. Tooling becomes more than a crutch for
the challenged. Classpath and dependency management are brutal. Many
people I talk to don't really know what things like Eclipse's PDE
(plugin/bundle development environment) can do for them. <pause for a
brief Eclipse endorsement> Eclipse PDE is not just a Java IDE. It does
full OSGi classpath modeling, complete compiler integration and visibility
control, target management, multiple concurrent target JRE support,
import/export/dependency management, in-place launching, ... I'll be at
ApacheCon and would be more than happy to show anyone who asks. </end of
endorsement> (that was just some rah rah for Richard 'cause its been a
while :-)
Anyway, this sort of thing is important because people will emulate what
you do. So if you use a mess of shortcuts because you can (i.e., because
the world is simpler at the bottom), you are not setting an example that
will be useful for others. As such, they are not going to be as
successful.
Jeff
IDE Lockin? (was Re: Repository/package structure)
Posted by Alex Karasulu <ao...@bellsouth.net>.
Jeff McAffer wrote:
>and of course, it is not particularly useful to an Eclipse-based
>developer. The good thing about PDE is that it directly and inherently
>supports OSGi bundle development with extremely accurate classpath
>renditions and tooling for maintaining versions etc. It also puts in
>place a simplified process that means you don't have to think about
>project structure much. Of course, this clashes directly with Maven's
>simplified process :-)
>
>
Question is: Do we want to have IDE lock in? Won't we alienate
contributors and perspective committers if we force them to use a
particular IDE?
I must admit I'm loving eclipse today. Here's what happened to me over
the years where IDE's are concerned:
Vi/Emacs JDE (pre 2001) ->
JEdit (2002) ->
Eclipse (2003) ->
IntelliJ IDEA (2004) ->
Eclipse (Today)
As you can see I change my mind frequently. I'll use what is best for
the task at hand. Now a days Eclipse is really kicking arse all over:
speed, features, support for j2me, j2ee, and of course for OSGi, for web
dev with WTP stuff the list goes on and on. It's looking really good
these days coming from a guy who favors the command line over UI. FYI I
just switched from IDEA which is a fat pig now with 5.0. Eclipse 3.1 is
also faster and has this excellent PDE tool (nice job btw). IDEA
however is just pleaseant to program with. It's far superior to any
other IDE I've used so far. I think it's slicker yet lacks the features
and speed of Eclipse hence my recent switch.
Anyway the point is not which IDE do we use. This is not a question for
us to answer. We cannot alienate users of other IDEs. Like I said
yesterday I was an Intellij IDEA user and still want to reserve the
right to switch IDE's if Eclipse does not meet my needs in the future.
This does not mean I favor any IDE ultimately. I change with the wind.
I would like to retain this freedom and to protect others that want to
develope with any IDE as part of this community.
Jeff, and other Eclipse peeps, please don't take this personally. We're
here to maximize freedom for our community not to constrain them to a
particular IDE. We need a tool that allows us to generate descriptors
for various IDEs. And thus we should try to conform to it's layout what
ever that may be. Plus as another requirement the tool should be a CLI
tool that allows for headless builds. CI is a plus.
>>src/
>> main/
>> java/
>> org/apache/felix/...
>> resources/
>> test/
>> java/
>> org/apache/felix/...
>> resources/
>>
>>
>
>Well, I am not totally against this structure, but it does somewhat suck
>for people like me who still regularly use the command line to keep
>making our paths deeper and deeper.
>
>
I'm all about the command line too Richard. The pain of these extra
directories is emeliorated by tab completion, pushd, and popd.
Side note: No offense to anyone but I don't trust IDEs since they dumb
things down. I can't stand it when tools obscure simple tasks to
accomodate challenged users while creating havoc for those that know
what they're doing. I cannot count the number of times some IDE plugin
has screwed up my SVN working directory or messed up an ant/maven
descriptor. Is it getting better and better every day? Yes for sure it
is but we cannot *unfortunately* give up on the more tedious command line.
Alex
Re: Repository/package structure
Posted by Jeff McAffer <Je...@ca.ibm.com>.
and of course, it is not particularly useful to an Eclipse-based
developer. The good thing about PDE is that it directly and inherently
supports OSGi bundle development with extremely accurate classpath
renditions and tooling for maintaining versions etc. It also puts in
place a simplified process that means you don't have to think about
project structure much. Of course, this clashes directly with Maven's
simplified process :-)
Jeff
"Richard S. Hall" <he...@ungoverned.org>
12/02/2005 09:51 AM
Please respond to
felix-dev
To
felix-dev@incubator.apache.org
cc
Subject
Re: Repository/package structure
Alan D. Cabrera wrote:
> I'm glad you brought this up. Maven 2 is great if you do things the
> maven 2 way. Things go really bad, if you try to adopt your own
> strategy. This is a good thing. imho, since maven 2 is kindof a
> revolt against the millions of ways that ant projects can be setup.
>
> Here is what would be a vanilla maven 2 setup:
>
> trunk/
> felix-framework/
> felix-shell/
> felix-shell-tui/
> felix-bundlerepository/
> felix-http-jetty/
> felix-prefs-jndi/
> felix-upnp/
> felix-log-simple/
> felix-log-postgres/
>
> Each project would have the following structure
>
> src/
> main/
> java/
> org/apache/felix/...
> resources/
> test/
> java/
> org/apache/felix/...
> resources/
Well, I am not totally against this structure, but it does somewhat suck
for people like me who still regularly use the command line to keep
making our paths deeper and deeper.
> Anything that's in test, never makes it into the bundle that's produced.
However, our tests may be packaged as a [potentially separate] bundle...
-> richard
Re: Repository/package structure
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Alan D. Cabrera wrote:
> I'm glad you brought this up. Maven 2 is great if you do things the
> maven 2 way. Things go really bad, if you try to adopt your own
> strategy. This is a good thing. imho, since maven 2 is kindof a
> revolt against the millions of ways that ant projects can be setup.
>
> Here is what would be a vanilla maven 2 setup:
>
> trunk/
> felix-framework/
> felix-shell/
> felix-shell-tui/
> felix-bundlerepository/
> felix-http-jetty/
> felix-prefs-jndi/
> felix-upnp/
> felix-log-simple/
> felix-log-postgres/
>
> Each project would have the following structure
>
> src/
> main/
> java/
> org/apache/felix/...
> resources/
> test/
> java/
> org/apache/felix/...
> resources/
Well, I am not totally against this structure, but it does somewhat suck
for people like me who still regularly use the command line to keep
making our paths deeper and deeper.
> Anything that's in test, never makes it into the bundle that's produced.
However, our tests may be packaged as a [potentially separate] bundle...
-> richard
Re[2]: Repository/package structure
Posted by Peter Kriens <Pe...@aQute.se>.
One issue I found over time is that I replicate packages in bundles.
My btool makes it trivial to say which pakages from the class path
should be included. The packageinfo file in the package directory
supports this model very well. A central file with versions for
packages in a project is imho VERY error prone ...
Kind regards,
Peter Kriens
ADC> Peter Kriens wrote, On 12/2/2005 5:34 AM:
>>One thing that I found very useful in the OSGi build is to have a file
>>in each package directory that contains its version.
>>
>>
ADC> Using maven 2, you can declare the versions of all your packages in one
ADC> place, the root pom.xml. Check out how Geronimo declares versions in
ADC> its root pom.xml.
ADC> Regards,
ADC> Alan
--
Peter Kriens Tel +33870447986
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Repository/package structure
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Peter Kriens wrote, On 12/2/2005 5:34 AM:
>One thing that I found very useful in the OSGi build is to have a file
>in each package directory that contains its version.
>
>
Using maven 2, you can declare the versions of all your packages in one
place, the root pom.xml. Check out how Geronimo declares versions in
its root pom.xml.
Regards,
Alan
Re[2]: Repository/package structure
Posted by Peter Kriens <Pe...@aQute.se>.
One thing that I found very useful in the OSGi build is to have a file
in each package directory that contains its version. My btool (which
makes the manifest and JAR files) includes this "packageinfo" file
in the JAR files so that I always have a way to find the version of
the package. Trying to maintain package versions centrally is very
error prone imho.
I currently use the following format:
version 1.3.2
However, I could make it compatible with a properties file by adding a
'=' sign.
Just an idea, kind regards,
Peter Kriens
--
Peter Kriens Tel +33870447986
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Repository/package structure
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Alex Karasulu wrote, On 12/1/2005 2:46 PM:
> Enrique Rodriguez wrote:
>
>> Thomas Watson wrote:
>>
>>> This is a usecase for fragments, right? You do not want to package
>>> your testcase code in with your normal bundle. Your testcase code
>>> is contained in a fragment of the bundle you are testing. This will
>>> give you package level access even though the code is contained in
>>> another bundle fragment. Some of junit tests in Eclipse use this
>>> same approach. In Eclipse the tests are stored in a completely
>>> separate project directory. This is because Eclipse keeps a 1-to-1
>>> mapping between projects and bundles.
>>
>>
>> ...
>>
>> I agree I don't want to package my testcase code into my bundle. But
>> I can achieve this with include/excludes in Ant/Maven. What do I
>> gain by adopting a fragment-based strategy? I am new to fragments so
>> I am asking to learn more, not question your statements. I like the
>> mental picture I'm getting, but the only visible benefit I can come
>> up with is the simplification of the source folder hierarchy, eg
>> collapsing the 'src/main/java' and 'src/test/java' of Maven 2 to just
>> 'src/' by virtue of demarcing code by bundle or fragment. In lieu of
>> actually launching into experimental coding with fragments, what
>> other benefits or use cases can you enumerate?
>
>
> With src/ and test/ folders where would resources for the bundle and
> test resources go? I think this drove maven peeps to use src/main and
> src/test base directories underwhich you can have src/main/resources
> and src/test/resources. I worry a bit if we are using maven and yet
> diverging from it's standard layout. I've always gotten burnt by
> doing this.
I'm glad you brought this up. Maven 2 is great if you do things the
maven 2 way. Things go really bad, if you try to adopt your own
strategy. This is a good thing. imho, since maven 2 is kindof a revolt
against the millions of ways that ant projects can be setup.
Here is what would be a vanilla maven 2 setup:
trunk/
felix-framework/
felix-shell/
felix-shell-tui/
felix-bundlerepository/
felix-http-jetty/
felix-prefs-jndi/
felix-upnp/
felix-log-simple/
felix-log-postgres/
Each project would have the following structure
src/
main/
java/
org/apache/felix/...
resources/
test/
java/
org/apache/felix/...
resources/
Anything that's in test, never makes it into the bundle that's produced.
Regards,
Alan
Re: Repository/package structure
Posted by Alex Karasulu <ao...@bellsouth.net>.
Enrique Rodriguez wrote:
> Thomas Watson wrote:
>
>> This is a usecase for fragments, right? You do not want to package
>> your testcase code in with your normal bundle. Your testcase code is
>> contained in a fragment of the bundle you are testing. This will
>> give you package level access even though the code is contained in
>> another bundle fragment. Some of junit tests in Eclipse use this
>> same approach. In Eclipse the tests are stored in a completely
>> separate project directory. This is because Eclipse keeps a 1-to-1
>> mapping between projects and bundles.
>
> ...
>
> I agree I don't want to package my testcase code into my bundle. But
> I can achieve this with include/excludes in Ant/Maven. What do I gain
> by adopting a fragment-based strategy? I am new to fragments so I am
> asking to learn more, not question your statements. I like the mental
> picture I'm getting, but the only visible benefit I can come up with
> is the simplification of the source folder hierarchy, eg collapsing
> the 'src/main/java' and 'src/test/java' of Maven 2 to just 'src/' by
> virtue of demarcing code by bundle or fragment. In lieu of actually
> launching into experimental coding with fragments, what other benefits
> or use cases can you enumerate?
With src/ and test/ folders where would resources for the bundle and
test resources go? I think this drove maven peeps to use src/main and
src/test base directories underwhich you can have src/main/resources and
src/test/resources. I worry a bit if we are using maven and yet
diverging from it's standard layout. I've always gotten burnt by doing
this.
Alex
Re: Repository/package structure
Posted by Enrique Rodriguez <en...@gmail.com>.
Thomas Watson wrote:
> This is a usecase for fragments, right? You do not want to package
> your testcase code in with your normal bundle. Your testcase code is
> contained in a fragment of the bundle you are testing. This will
> give you package level access even though the code is contained in
> another bundle fragment. Some of junit tests in Eclipse use this
> same approach. In Eclipse the tests are stored in a completely
> separate project directory. This is because Eclipse keeps a
> 1-to-1 mapping between projects and bundles.
...
I agree I don't want to package my testcase code into my bundle. But I
can achieve this with include/excludes in Ant/Maven. What do I gain by
adopting a fragment-based strategy? I am new to fragments so I am
asking to learn more, not question your statements. I like the mental
picture I'm getting, but the only visible benefit I can come up with is
the simplification of the source folder hierarchy, eg collapsing the
'src/main/java' and 'src/test/java' of Maven 2 to just 'src/' by virtue
of demarcing code by bundle or fragment. In lieu of actually launching
into experimental coding with fragments, what other benefits or use
cases can you enumerate?
Enrique
Re: Repository/package structure
Posted by Thomas Watson <tj...@us.ibm.com>.
"Richard S. Hall" <he...@ungoverned.org> wrote on 12/01/2005 02:10:18 PM:
> I am fine with having a separate sub-directory for src and test, but I
> think in that case it makes sense to keep package names the same, e.g.:
>
> trunk/
> org.apache.felix.upnp/
> src/
> org/apache/felix/upnp/basedriver
> ...
> test/
> org/apache/felix/upnp/basedriver
> ...
>
> It seems a benefit of this approach is that you can have package private
> access.
>
> One thing to point out, however, is that I was under some understanding
> that there was supposed to be one JAR file per-subproject mapping. Does
> UPnP get packaged into multiple bundles? If so, we will need to create a
> trunk/ subproject directory for each one.
>
> -> richard
>
This is a usecase for fragments, right? You do not want to package
your testcase code in with your normal bundle. Your testcase code is
contained in a fragment of the bundle you are testing. This will
give you package level access even though the code is contained in
another bundle fragment. Some of junit tests in Eclipse use this
same approach. In Eclipse the tests are stored in a completely
separate project directory. This is because Eclipse keeps a
1-to-1 mapping between projects and bundles.
I know how much Richard loves fragments :-)
Tom.
Re: Repository/package structure
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I am fine with having a separate sub-directory for src and test, but I
think in that case it makes sense to keep package names the same, e.g.:
trunk/
org.apache.felix.upnp/
src/
org/apache/felix/upnp/basedriver
...
test/
org/apache/felix/upnp/basedriver
...
It seems a benefit of this approach is that you can have package private
access.
One thing to point out, however, is that I was under some understanding
that there was supposed to be one JAR file per-subproject mapping. Does
UPnP get packaged into multiple bundles? If so, we will need to create a
trunk/ subproject directory for each one.
-> richard
Francesco Furfari wrote:
> No, it should be
> trunk/
> org.apache.felix.upnp/
> src/
> org/apache/felix/upnp/
> basedriver/*.java
> controlPoint/*.java
> samples/*.java
> otherComponents/*.java
>
> for the source code,
> now for the testcases code we could use
> trunk/
> org.apache.felix.upnp/
> src/
> test/
>
> or
>
> trunk/
> org.apache.felix.upnp/
> src/
> org/apache/felix/upnp/
> basedriver/test/*.java
> controlPoint/test/*.java
> samples/test/*.java
> otherComponents/test/*.java
>
> does it sound good for you?
> what do you prefer? we haven't testcase yet.
>
> ff
>
>
> Richard S. Hall ha scritto:
>
>> If I understand everything correctly, under the current proposal you
>> would have this:
>>
>> trunk/
>> org.apache.felix.upnp.basedriver/
>> src/org/apache/felix/upnp/basedriver/*.java
>> src/org/apache/felix/upnp/basedriver/test/*.java
>>
>> Note that the trunk/ directory contains sub-project directories named
>> after the sub-projects package name. We do not have an org/ directory
>> in the trunk/ directory.
>>
>> -> richard
>>
>> Francesco Furfari wrote:
>>
>>> so in the repository we have
>>> trunk/org/apache/felix/upnp/src[org.apache.felix.upnp.basedriver]
>>> and
>>> trunk/org/apache/felix/upnp/test[org.apache.felix.upnp.basedriverTest]
>>> where [org.apache.felix.upnp.*] are the folders for packaging
>>>
>>> is it right?
>>> francesco
>>>
>>> Richard S. Hall ha scritto:
>>>
>>>> I am in agreement with Enrique on this one. I would not like to see
>>>> the test cases for each sub-project be a sub-project in the trunk/
>>>> directory, because this will pollute the trunk/ directory by
>>>> doubling its contents. I think each sub-project should put its test
>>>> cases inside of its trunk/sub-project/ directory. The only tests
>>>> that should potentially be in the trunk/ directory are those that
>>>> span multiple sub-projects, I think.
>>>>
>>>> -> richard
>>>>
>>>> Enrique Rodriguez wrote:
>>>>
>>>>> Richard S. Hall wrote:
>>>>>
>>>>>> Francesco Furfari wrote:
>>>>>>
>>>>>>> It's ok for me, we have a similar structure.
>>>>>>> What for the test cases? do we put all inside the subprojects?
>>>>>>> org.apache.felix.upnp.test?
>>>>>>
>>>>>>
>>>>>>
>>>>>> This seems to make more sense to me, as opposed to
>>>>>> org.apache.felix.test.upnp...but I can go either way.
>>>>>
>>>>>
>>>>>
>>>>> I was picturing implementation code and testcases in the same
>>>>> subproject, but in separate source folders. During packaging, the
>>>>> testcases are not included in the resulting jar/bundle.
>>>>>
>>>>> Is this what the separate bundle for tests is for or is the test
>>>>> subproject specifically for some sort of integration tests, ie
>>>>> tests against the public API? Where do per-class unit tests go?
>>>>> I would like some help understanding this practice.
>>>>>
>>>>> Enrique
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
Re: Repository/package structure
Posted by Enrique Rodriguez <en...@gmail.com>.
Francesco Furfari wrote:
...
> or
>
> trunk/
> org.apache.felix.upnp/
> src/
> org/apache/felix/upnp/
> basedriver/test/*.java
> controlPoint/test/*.java
> samples/test/*.java
> otherComponents/test/*.java
>
> does it sound good for you?
> what do you prefer? we haven't testcase yet.
The problem with 'test' in the package name is that it breaks the
best-practice of using package-scoping to allow per-class unit testing.
Your 1st example works:
trunk/
org.apache.felix.upnp/
src/
org/apache/felix/upnp/
basedriver/MyClass.java
test/
org/apache/felix/upnp/
basedriver/MyClassTest.java
Where MyClass has package-scoped methods that MyClassTest can use for
unit testing.
Enrique
Re: Repository/package structure
Posted by Francesco Furfari <fr...@isti.cnr.it>.
No, it should be
trunk/
org.apache.felix.upnp/
src/
org/apache/felix/upnp/
basedriver/*.java
controlPoint/*.java
samples/*.java
otherComponents/*.java
for the source code,
now for the testcases code we could use
trunk/
org.apache.felix.upnp/
src/
test/
or
trunk/
org.apache.felix.upnp/
src/
org/apache/felix/upnp/
basedriver/test/*.java
controlPoint/test/*.java
samples/test/*.java
otherComponents/test/*.java
does it sound good for you?
what do you prefer? we haven't testcase yet.
ff
Richard S. Hall ha scritto:
> If I understand everything correctly, under the current proposal you
> would have this:
>
> trunk/
> org.apache.felix.upnp.basedriver/
> src/org/apache/felix/upnp/basedriver/*.java
> src/org/apache/felix/upnp/basedriver/test/*.java
>
> Note that the trunk/ directory contains sub-project directories named
> after the sub-projects package name. We do not have an org/ directory
> in the trunk/ directory.
>
> -> richard
>
> Francesco Furfari wrote:
>
>> so in the repository we have
>> trunk/org/apache/felix/upnp/src[org.apache.felix.upnp.basedriver]
>> and
>> trunk/org/apache/felix/upnp/test[org.apache.felix.upnp.basedriverTest]
>> where [org.apache.felix.upnp.*] are the folders for packaging
>>
>> is it right?
>> francesco
>>
>> Richard S. Hall ha scritto:
>>
>>> I am in agreement with Enrique on this one. I would not like to see
>>> the test cases for each sub-project be a sub-project in the trunk/
>>> directory, because this will pollute the trunk/ directory by
>>> doubling its contents. I think each sub-project should put its test
>>> cases inside of its trunk/sub-project/ directory. The only tests
>>> that should potentially be in the trunk/ directory are those that
>>> span multiple sub-projects, I think.
>>>
>>> -> richard
>>>
>>> Enrique Rodriguez wrote:
>>>
>>>> Richard S. Hall wrote:
>>>>
>>>>> Francesco Furfari wrote:
>>>>>
>>>>>> It's ok for me, we have a similar structure.
>>>>>> What for the test cases? do we put all inside the subprojects?
>>>>>> org.apache.felix.upnp.test?
>>>>>
>>>>>
>>>>>
>>>>> This seems to make more sense to me, as opposed to
>>>>> org.apache.felix.test.upnp...but I can go either way.
>>>>
>>>>
>>>>
>>>> I was picturing implementation code and testcases in the same
>>>> subproject, but in separate source folders. During packaging, the
>>>> testcases are not included in the resulting jar/bundle.
>>>>
>>>> Is this what the separate bundle for tests is for or is the test
>>>> subproject specifically for some sort of integration tests, ie
>>>> tests against the public API? Where do per-class unit tests go? I
>>>> would like some help understanding this practice.
>>>>
>>>> Enrique
>>>>
>>>>
>>>
>>
>>
>>
>
Re: Repository/package structure
Posted by Francesco Furfari <fr...@isti.cnr.it>.
Ooops :)
I have read all again, just a moment
ff
Richard S. Hall ha scritto:
> If I understand everything correctly, under the current proposal you
> would have this:
>
> trunk/
> org.apache.felix.upnp.basedriver/
> src/org/apache/felix/upnp/basedriver/*.java
> src/org/apache/felix/upnp/basedriver/test/*.java
>
> Note that the trunk/ directory contains sub-project directories named
> after the sub-projects package name. We do not have an org/ directory
> in the trunk/ directory.
>
> -> richard
>
> Francesco Furfari wrote:
>
>> so in the repository we have
>> trunk/org/apache/felix/upnp/src[org.apache.felix.upnp.basedriver]
>> and
>> trunk/org/apache/felix/upnp/test[org.apache.felix.upnp.basedriverTest]
>> where [org.apache.felix.upnp.*] are the folders for packaging
>>
>> is it right?
>> francesco
>>
>> Richard S. Hall ha scritto:
>>
>>> I am in agreement with Enrique on this one. I would not like to see
>>> the test cases for each sub-project be a sub-project in the trunk/
>>> directory, because this will pollute the trunk/ directory by
>>> doubling its contents. I think each sub-project should put its test
>>> cases inside of its trunk/sub-project/ directory. The only tests
>>> that should potentially be in the trunk/ directory are those that
>>> span multiple sub-projects, I think.
>>>
>>> -> richard
>>>
>>> Enrique Rodriguez wrote:
>>>
>>>> Richard S. Hall wrote:
>>>>
>>>>> Francesco Furfari wrote:
>>>>>
>>>>>> It's ok for me, we have a similar structure.
>>>>>> What for the test cases? do we put all inside the subprojects?
>>>>>> org.apache.felix.upnp.test?
>>>>>
>>>>>
>>>>>
>>>>> This seems to make more sense to me, as opposed to
>>>>> org.apache.felix.test.upnp...but I can go either way.
>>>>
>>>>
>>>>
>>>> I was picturing implementation code and testcases in the same
>>>> subproject, but in separate source folders. During packaging, the
>>>> testcases are not included in the resulting jar/bundle.
>>>>
>>>> Is this what the separate bundle for tests is for or is the test
>>>> subproject specifically for some sort of integration tests, ie
>>>> tests against the public API? Where do per-class unit tests go? I
>>>> would like some help understanding this practice.
>>>>
>>>> Enrique
>>>>
>>>>
>>>
>>
>>
>>
>
Re: Repository/package structure
Posted by Stefano Lenzi <ki...@interfree.it>.
BJ Hargrave wrote:
>Actually I think it should be
>
>
>trunk/
> org.apache.felix.upnp.basedriver/
> src/org/apache/felix/upnp/basedriver/*.java
> test/org/apache/felix/upnp/test/basedriver/*.java
>
>Note that test code is in a test folder. I think it is very good to have a
>clear seperation between the impl and its tests. Just having test in the
>package name is not enough.
>
>
I agree with this way. You can easily identify if the content is for
test or not.
Re: Repository/package structure
Posted by BJ Hargrave <ha...@us.ibm.com>.
Actually I think it should be
trunk/
org.apache.felix.upnp.basedriver/
src/org/apache/felix/upnp/basedriver/*.java
test/org/apache/felix/upnp/test/basedriver/*.java
Note that test code is in a test folder. I think it is very good to have a
clear seperation between the impl and its tests. Just having test in the
package name is not enough.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
Office: +1 407 849 9117 Mobile: +1 386 848 3788
"Richard S. Hall" <he...@ungoverned.org>
2005-12-01 02:26 PM
Please respond to
felix-dev
To
felix-dev@incubator.apache.org
cc
Subject
Re: Repository/package structure
If I understand everything correctly, under the current proposal you
would have this:
trunk/
org.apache.felix.upnp.basedriver/
src/org/apache/felix/upnp/basedriver/*.java
src/org/apache/felix/upnp/basedriver/test/*.java
Note that the trunk/ directory contains sub-project directories named
after the sub-projects package name. We do not have an org/ directory in
the trunk/ directory.
-> richard
Francesco Furfari wrote:
> so in the repository we have
> trunk/org/apache/felix/upnp/src[org.apache.felix.upnp.basedriver]
> and
> trunk/org/apache/felix/upnp/test[org.apache.felix.upnp.basedriverTest]
> where [org.apache.felix.upnp.*] are the folders for packaging
>
> is it right?
> francesco
>
> Richard S. Hall ha scritto:
>
>> I am in agreement with Enrique on this one. I would not like to see
>> the test cases for each sub-project be a sub-project in the trunk/
>> directory, because this will pollute the trunk/ directory by doubling
>> its contents. I think each sub-project should put its test cases
>> inside of its trunk/sub-project/ directory. The only tests that
>> should potentially be in the trunk/ directory are those that span
>> multiple sub-projects, I think.
>>
>> -> richard
>>
>> Enrique Rodriguez wrote:
>>
>>> Richard S. Hall wrote:
>>>
>>>> Francesco Furfari wrote:
>>>>
>>>>> It's ok for me, we have a similar structure.
>>>>> What for the test cases? do we put all inside the subprojects?
>>>>> org.apache.felix.upnp.test?
>>>>
>>>>
>>>> This seems to make more sense to me, as opposed to
>>>> org.apache.felix.test.upnp...but I can go either way.
>>>
>>>
>>> I was picturing implementation code and testcases in the same
>>> subproject, but in separate source folders. During packaging, the
>>> testcases are not included in the resulting jar/bundle.
>>>
>>> Is this what the separate bundle for tests is for or is the test
>>> subproject specifically for some sort of integration tests, ie tests
>>> against the public API? Where do per-class unit tests go? I would
>>> like some help understanding this practice.
>>>
>>> Enrique
>>>
>>>
>>
>
>
>
Re: Repository/package structure
Posted by "Richard S. Hall" <he...@ungoverned.org>.
If I understand everything correctly, under the current proposal you
would have this:
trunk/
org.apache.felix.upnp.basedriver/
src/org/apache/felix/upnp/basedriver/*.java
src/org/apache/felix/upnp/basedriver/test/*.java
Note that the trunk/ directory contains sub-project directories named
after the sub-projects package name. We do not have an org/ directory in
the trunk/ directory.
-> richard
Francesco Furfari wrote:
> so in the repository we have
> trunk/org/apache/felix/upnp/src[org.apache.felix.upnp.basedriver]
> and
> trunk/org/apache/felix/upnp/test[org.apache.felix.upnp.basedriverTest]
> where [org.apache.felix.upnp.*] are the folders for packaging
>
> is it right?
> francesco
>
> Richard S. Hall ha scritto:
>
>> I am in agreement with Enrique on this one. I would not like to see
>> the test cases for each sub-project be a sub-project in the trunk/
>> directory, because this will pollute the trunk/ directory by doubling
>> its contents. I think each sub-project should put its test cases
>> inside of its trunk/sub-project/ directory. The only tests that
>> should potentially be in the trunk/ directory are those that span
>> multiple sub-projects, I think.
>>
>> -> richard
>>
>> Enrique Rodriguez wrote:
>>
>>> Richard S. Hall wrote:
>>>
>>>> Francesco Furfari wrote:
>>>>
>>>>> It's ok for me, we have a similar structure.
>>>>> What for the test cases? do we put all inside the subprojects?
>>>>> org.apache.felix.upnp.test?
>>>>
>>>>
>>>> This seems to make more sense to me, as opposed to
>>>> org.apache.felix.test.upnp...but I can go either way.
>>>
>>>
>>> I was picturing implementation code and testcases in the same
>>> subproject, but in separate source folders. During packaging, the
>>> testcases are not included in the resulting jar/bundle.
>>>
>>> Is this what the separate bundle for tests is for or is the test
>>> subproject specifically for some sort of integration tests, ie tests
>>> against the public API? Where do per-class unit tests go? I would
>>> like some help understanding this practice.
>>>
>>> Enrique
>>>
>>>
>>
>
>
>
Re: Repository/package structure
Posted by Francesco Furfari <fr...@isti.cnr.it>.
so in the repository we have
trunk/org/apache/felix/upnp/src[org.apache.felix.upnp.basedriver]
and
trunk/org/apache/felix/upnp/test[org.apache.felix.upnp.basedriverTest]
where [org.apache.felix.upnp.*] are the folders for packaging
is it right?
francesco
Richard S. Hall ha scritto:
> I am in agreement with Enrique on this one. I would not like to see
> the test cases for each sub-project be a sub-project in the trunk/
> directory, because this will pollute the trunk/ directory by doubling
> its contents. I think each sub-project should put its test cases
> inside of its trunk/sub-project/ directory. The only tests that should
> potentially be in the trunk/ directory are those that span multiple
> sub-projects, I think.
>
> -> richard
>
> Enrique Rodriguez wrote:
>
>> Richard S. Hall wrote:
>>
>>> Francesco Furfari wrote:
>>>
>>>> It's ok for me, we have a similar structure.
>>>> What for the test cases? do we put all inside the subprojects?
>>>> org.apache.felix.upnp.test?
>>>
>>>
>>> This seems to make more sense to me, as opposed to
>>> org.apache.felix.test.upnp...but I can go either way.
>>
>>
>> I was picturing implementation code and testcases in the same
>> subproject, but in separate source folders. During packaging, the
>> testcases are not included in the resulting jar/bundle.
>>
>> Is this what the separate bundle for tests is for or is the test
>> subproject specifically for some sort of integration tests, ie tests
>> against the public API? Where do per-class unit tests go? I would
>> like some help understanding this practice.
>>
>> Enrique
>>
>>
>
Re: Repository/package structure
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I am in agreement with Enrique on this one. I would not like to see the
test cases for each sub-project be a sub-project in the trunk/
directory, because this will pollute the trunk/ directory by doubling
its contents. I think each sub-project should put its test cases inside
of its trunk/sub-project/ directory. The only tests that should
potentially be in the trunk/ directory are those that span multiple
sub-projects, I think.
-> richard
Enrique Rodriguez wrote:
> Richard S. Hall wrote:
>> Francesco Furfari wrote:
>>
>>> It's ok for me, we have a similar structure.
>>> What for the test cases? do we put all inside the subprojects?
>>> org.apache.felix.upnp.test?
>>
>> This seems to make more sense to me, as opposed to
>> org.apache.felix.test.upnp...but I can go either way.
>
> I was picturing implementation code and testcases in the same
> subproject, but in separate source folders. During packaging, the
> testcases are not included in the resulting jar/bundle.
>
> Is this what the separate bundle for tests is for or is the test
> subproject specifically for some sort of integration tests, ie tests
> against the public API? Where do per-class unit tests go? I would
> like some help understanding this practice.
>
> Enrique
>
>
Re: Repository/package structure
Posted by Enrique Rodriguez <en...@gmail.com>.
Richard S. Hall wrote:
> Francesco Furfari wrote:
>
>> It's ok for me, we have a similar structure.
>> What for the test cases? do we put all inside the subprojects?
>> org.apache.felix.upnp.test?
>
> This seems to make more sense to me, as opposed to
> org.apache.felix.test.upnp...but I can go either way.
I was picturing implementation code and testcases in the same
subproject, but in separate source folders. During packaging, the
testcases are not included in the resulting jar/bundle.
Is this what the separate bundle for tests is for or is the test
subproject specifically for some sort of integration tests, ie tests
against the public API? Where do per-class unit tests go? I would like
some help understanding this practice.
Enrique
Re: Repository/package structure
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Francesco Furfari wrote:
> It's ok for me, we have a similar structure.
> What for the test cases? do we put all inside the subprojects?
> org.apache.felix.upnp.test?
This seems to make more sense to me, as opposed to
org.apache.felix.test.upnp...but I can go either way.
-> richard
>
> francesco
>
>
> Richard S. Hall ha scritto:
>
>> Hello,
>>
>> It seems that we have a few contributions nearly ready for the
>> repository. It might be worthwhile if we talk about repository and
>> package structure, since this issue will come up as soon as
>> everything is in order for the code contributions.
>>
>> We sort of had this discussion earlier, but it is not clear to me
>> that we came away with a final consensus. I think we just said we
>> will defer until we need to do something...well, now we need to do
>> something. :-)
>>
>> I propose that the trunk directory contain a directory for each
>> subproject, where the subproject directory name is the package name
>> of the root package of the subproject. Taking the framework as an
>> example:
>>
>> trunk/
>> org.apache.felix.framework/
>>
>> Of course, for the framework we will need to move some other things
>> around since it currently contains some bundles, so we might end up
>> with:
>>
>> trunk/
>> org.apache.felix.framework/
>> org.apache.felix.shell/
>> org.apache.felix.shell.tui/
>> org.apache.felix.bundlerepository/
>>
>> The shell and bundlerepository subprojects include default
>> implementations that could be moved up to top-level subprojects if
>> deemed necessary in the future, such as if we eventually have
>> multiple implementations available of our own services.
>>
>> For our outstanding contributions (i.e., UPnP, HTTP Service, and
>> Preferences Service) , I propose the following:
>>
>> trunk/
>> org.apache.felix.http.jetty/
>> org.apache.felix.prefs.jndi/
>> org.apache.felix.upnp/
>>
>> The first two allow for other service implementations (e.g., HTTP
>> based on Tomcat or Prefs based on files). For UPnP, it seems to me
>> that multiple implementations are less likely, so I didn't propose
>> any sub-package...UPnP implementation packages could be renamed later
>> if another implementation comes along.
>>
>> I assume that we will get a Log Service before long, so that will
>> likely be something like:
>>
>> trunk/
>> org.apache.felix.log.simple/
>> org.apache.felix.log.postgres/
>>
>> Summarizing, we end up with the trunk/ directory being a flat list of
>> subprojects named after their package.
>>
>> Thoughts?
>>
>> -> richard
>>
>
>
>
Re: Repository/package structure
Posted by Francesco Furfari <fr...@isti.cnr.it>.
It's ok for me, we have a similar structure.
What for the test cases? do we put all inside the subprojects?
org.apache.felix.upnp.test?
francesco
Richard S. Hall ha scritto:
> Hello,
>
> It seems that we have a few contributions nearly ready for the
> repository. It might be worthwhile if we talk about repository and
> package structure, since this issue will come up as soon as everything
> is in order for the code contributions.
>
> We sort of had this discussion earlier, but it is not clear to me that
> we came away with a final consensus. I think we just said we will
> defer until we need to do something...well, now we need to do
> something. :-)
>
> I propose that the trunk directory contain a directory for each
> subproject, where the subproject directory name is the package name of
> the root package of the subproject. Taking the framework as an example:
>
> trunk/
> org.apache.felix.framework/
>
> Of course, for the framework we will need to move some other things
> around since it currently contains some bundles, so we might end up with:
>
> trunk/
> org.apache.felix.framework/
> org.apache.felix.shell/
> org.apache.felix.shell.tui/
> org.apache.felix.bundlerepository/
>
> The shell and bundlerepository subprojects include default
> implementations that could be moved up to top-level subprojects if
> deemed necessary in the future, such as if we eventually have multiple
> implementations available of our own services.
>
> For our outstanding contributions (i.e., UPnP, HTTP Service, and
> Preferences Service) , I propose the following:
>
> trunk/
> org.apache.felix.http.jetty/
> org.apache.felix.prefs.jndi/
> org.apache.felix.upnp/
>
> The first two allow for other service implementations (e.g., HTTP
> based on Tomcat or Prefs based on files). For UPnP, it seems to me
> that multiple implementations are less likely, so I didn't propose any
> sub-package...UPnP implementation packages could be renamed later if
> another implementation comes along.
>
> I assume that we will get a Log Service before long, so that will
> likely be something like:
>
> trunk/
> org.apache.felix.log.simple/
> org.apache.felix.log.postgres/
>
> Summarizing, we end up with the trunk/ directory being a flat list of
> subprojects named after their package.
>
> Thoughts?
>
> -> richard
>
Re: Repository/package structure
Posted by Enrique Rodriguez <en...@gmail.com>.
BJ Hargrave wrote:
> I like it. It is very much like eclipse organization and supports using
> eclipse IDE to develop individual projects.
I agree. The layout looks good, Richard.
Enrique
Re: Repository/package structure
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Yes, since the symbolic name is supposed to be globally unique, the most
reasonable choice is to use the full package name.
-> richard
Jeff McAffer wrote:
> just to be really really clear then, the BSN would be "
> org.apache.felix.http.jetty".
>
> Jeff
>
>
>
>
> Rob Walker <ro...@ascert.com>
> 12/01/2005 12:28 PM
> Please respond to
> felix-dev
>
>
> To
> felix-dev@incubator.apache.org
> cc
>
> Subject
> Re: Repository/package structure
>
>
>
>
>
>
> Is there any value in using the last 2 parts as the symbolic names -
> that would give us 'http-jetty' for instance rather than just 'jetty'.
> Struck me the latter could be confusing, at least in this specific case.
>
> -- Rob
>
> Richard S. Hall wrote:
>
>
>> I think it seems reasonable to use it as the symbolic name, since we
>> don't have any other useful candidate to fill that role...it is what I
>> do currently with my own bundles.
>>
>> -> richard
>>
>> Jeff McAffer wrote:
>>
>>
>>> Just to be clear, are the dir names also the bundle symbolic name?
>>> FWIW, that is the eclipse convention and while it is not mandatory
>>> that the names match, this tends to be the most tested and mostly
>>> likely to work seamlessly path. Then people just check out that dir
>>> as a project and life in PDE is sweet.
>>>
>>> Jeff
>>>
>>>
>>>
>
>
>
>
>
Re: Repository/package structure
Posted by Jeff McAffer <Je...@ca.ibm.com>.
just to be really really clear then, the BSN would be "
org.apache.felix.http.jetty".
Jeff
Rob Walker <ro...@ascert.com>
12/01/2005 12:28 PM
Please respond to
felix-dev
To
felix-dev@incubator.apache.org
cc
Subject
Re: Repository/package structure
Is there any value in using the last 2 parts as the symbolic names -
that would give us 'http-jetty' for instance rather than just 'jetty'.
Struck me the latter could be confusing, at least in this specific case.
-- Rob
Richard S. Hall wrote:
> I think it seems reasonable to use it as the symbolic name, since we
> don't have any other useful candidate to fill that role...it is what I
> do currently with my own bundles.
>
> -> richard
>
> Jeff McAffer wrote:
>
>> Just to be clear, are the dir names also the bundle symbolic name?
>> FWIW, that is the eclipse convention and while it is not mandatory
>> that the names match, this tends to be the most tested and mostly
>> likely to work seamlessly path. Then people just check out that dir
>> as a project and life in PDE is sweet.
>>
>> Jeff
>>
>>
Re: Repository/package structure
Posted by Rob Walker <ro...@ascert.com>.
Is there any value in using the last 2 parts as the symbolic names -
that would give us 'http-jetty' for instance rather than just 'jetty'.
Struck me the latter could be confusing, at least in this specific case.
-- Rob
Richard S. Hall wrote:
> I think it seems reasonable to use it as the symbolic name, since we
> don't have any other useful candidate to fill that role...it is what I
> do currently with my own bundles.
>
> -> richard
>
> Jeff McAffer wrote:
>
>> Just to be clear, are the dir names also the bundle symbolic name?
>> FWIW, that is the eclipse convention and while it is not mandatory
>> that the names match, this tends to be the most tested and mostly
>> likely to work seamlessly path. Then people just check out that dir
>> as a project and life in PDE is sweet.
>>
>> Jeff
>>
>>
Re: Repository/package structure
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I think it seems reasonable to use it as the symbolic name, since we
don't have any other useful candidate to fill that role...it is what I
do currently with my own bundles.
-> richard
Jeff McAffer wrote:
> Just to be clear, are the dir names also the bundle symbolic name? FWIW,
> that is the eclipse convention and while it is not mandatory that the
> names match, this tends to be the most tested and mostly likely to work
> seamlessly path. Then people just check out that dir as a project and
> life in PDE is sweet.
>
> Jeff
>
>
>
>
> BJ Hargrave <ha...@us.ibm.com>
> 11/30/2005 08:16 PM
> Please respond to
> felix-dev
>
>
> To
> felix-dev@incubator.apache.org
> cc
>
> Subject
> Re: Repository/package structure
>
>
>
>
>
>
> I like it. It is very much like eclipse organization and supports using
> eclipse IDE to develop individual projects.
>
> You will also need a project to hold the OSGi companion code:
>
> trunk/
> org.osgi/
>
> for example.
>
> How will you segregate test cases?
>
> trunk/
> org.apache.felix.test.framework/ ?
>
> BJ Hargrave
> Senior Technical Staff Member, IBM
> OSGi Fellow and CTO of the OSGi Alliance
> hargrave@us.ibm.com
> Office: +1 407 849 9117 Mobile: +1 386 848 3788
>
>
>
> "Richard S. Hall" <he...@ungoverned.org>
> 2005-11-30 03:53 PM
> Please respond to
> felix-dev
>
>
> To
> felix-dev@incubator.apache.org
> cc
>
> Subject
> Repository/package structure
>
>
>
>
>
>
> Hello,
>
> It seems that we have a few contributions nearly ready for the
> repository. It might be worthwhile if we talk about repository and
> package structure, since this issue will come up as soon as everything
> is in order for the code contributions.
>
> We sort of had this discussion earlier, but it is not clear to me that
> we came away with a final consensus. I think we just said we will defer
> until we need to do something...well, now we need to do something. :-)
>
> I propose that the trunk directory contain a directory for each
> subproject, where the subproject directory name is the package name of
> the root package of the subproject. Taking the framework as an example:
>
> trunk/
> org.apache.felix.framework/
>
> Of course, for the framework we will need to move some other things
> around since it currently contains some bundles, so we might end up with:
>
> trunk/
> org.apache.felix.framework/
> org.apache.felix.shell/
> org.apache.felix.shell.tui/
> org.apache.felix.bundlerepository/
>
> The shell and bundlerepository subprojects include default
> implementations that could be moved up to top-level subprojects if
> deemed necessary in the future, such as if we eventually have multiple
> implementations available of our own services.
>
> For our outstanding contributions (i.e., UPnP, HTTP Service, and
> Preferences Service) , I propose the following:
>
> trunk/
> org.apache.felix.http.jetty/
> org.apache.felix.prefs.jndi/
> org.apache.felix.upnp/
>
> The first two allow for other service implementations (e.g., HTTP based
> on Tomcat or Prefs based on files). For UPnP, it seems to me that
> multiple implementations are less likely, so I didn't propose any
> sub-package...UPnP implementation packages could be renamed later if
> another implementation comes along.
>
> I assume that we will get a Log Service before long, so that will likely
> be something like:
>
> trunk/
> org.apache.felix.log.simple/
> org.apache.felix.log.postgres/
>
> Summarizing, we end up with the trunk/ directory being a flat list of
> subprojects named after their package.
>
> Thoughts?
>
> -> richard
>
>
>
>
>
Re: Repository/package structure
Posted by Enrique Rodriguez <en...@gmail.com>.
Jeff McAffer wrote:
> Just to be clear, are the dir names also the bundle symbolic name? FWIW,
> that is the eclipse convention and while it is not mandatory that the
> names match, this tends to be the most tested and mostly likely to work
> seamlessly path. Then people just check out that dir as a project and
> life in PDE is sweet.
I agree it should be the Bundle-SymbolicName. It also makes sense as
the Maven artifact ID.
Enrique
Re: Repository/package structure
Posted by Jeff McAffer <Je...@ca.ibm.com>.
Just to be clear, are the dir names also the bundle symbolic name? FWIW,
that is the eclipse convention and while it is not mandatory that the
names match, this tends to be the most tested and mostly likely to work
seamlessly path. Then people just check out that dir as a project and
life in PDE is sweet.
Jeff
BJ Hargrave <ha...@us.ibm.com>
11/30/2005 08:16 PM
Please respond to
felix-dev
To
felix-dev@incubator.apache.org
cc
Subject
Re: Repository/package structure
I like it. It is very much like eclipse organization and supports using
eclipse IDE to develop individual projects.
You will also need a project to hold the OSGi companion code:
trunk/
org.osgi/
for example.
How will you segregate test cases?
trunk/
org.apache.felix.test.framework/ ?
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
Office: +1 407 849 9117 Mobile: +1 386 848 3788
"Richard S. Hall" <he...@ungoverned.org>
2005-11-30 03:53 PM
Please respond to
felix-dev
To
felix-dev@incubator.apache.org
cc
Subject
Repository/package structure
Hello,
It seems that we have a few contributions nearly ready for the
repository. It might be worthwhile if we talk about repository and
package structure, since this issue will come up as soon as everything
is in order for the code contributions.
We sort of had this discussion earlier, but it is not clear to me that
we came away with a final consensus. I think we just said we will defer
until we need to do something...well, now we need to do something. :-)
I propose that the trunk directory contain a directory for each
subproject, where the subproject directory name is the package name of
the root package of the subproject. Taking the framework as an example:
trunk/
org.apache.felix.framework/
Of course, for the framework we will need to move some other things
around since it currently contains some bundles, so we might end up with:
trunk/
org.apache.felix.framework/
org.apache.felix.shell/
org.apache.felix.shell.tui/
org.apache.felix.bundlerepository/
The shell and bundlerepository subprojects include default
implementations that could be moved up to top-level subprojects if
deemed necessary in the future, such as if we eventually have multiple
implementations available of our own services.
For our outstanding contributions (i.e., UPnP, HTTP Service, and
Preferences Service) , I propose the following:
trunk/
org.apache.felix.http.jetty/
org.apache.felix.prefs.jndi/
org.apache.felix.upnp/
The first two allow for other service implementations (e.g., HTTP based
on Tomcat or Prefs based on files). For UPnP, it seems to me that
multiple implementations are less likely, so I didn't propose any
sub-package...UPnP implementation packages could be renamed later if
another implementation comes along.
I assume that we will get a Log Service before long, so that will likely
be something like:
trunk/
org.apache.felix.log.simple/
org.apache.felix.log.postgres/
Summarizing, we end up with the trunk/ directory being a flat list of
subprojects named after their package.
Thoughts?
-> richard
Re: Repository/package structure
Posted by BJ Hargrave <ha...@us.ibm.com>.
I like it. It is very much like eclipse organization and supports using
eclipse IDE to develop individual projects.
You will also need a project to hold the OSGi companion code:
trunk/
org.osgi/
for example.
How will you segregate test cases?
trunk/
org.apache.felix.test.framework/ ?
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
Office: +1 407 849 9117 Mobile: +1 386 848 3788
"Richard S. Hall" <he...@ungoverned.org>
2005-11-30 03:53 PM
Please respond to
felix-dev
To
felix-dev@incubator.apache.org
cc
Subject
Repository/package structure
Hello,
It seems that we have a few contributions nearly ready for the
repository. It might be worthwhile if we talk about repository and
package structure, since this issue will come up as soon as everything
is in order for the code contributions.
We sort of had this discussion earlier, but it is not clear to me that
we came away with a final consensus. I think we just said we will defer
until we need to do something...well, now we need to do something. :-)
I propose that the trunk directory contain a directory for each
subproject, where the subproject directory name is the package name of
the root package of the subproject. Taking the framework as an example:
trunk/
org.apache.felix.framework/
Of course, for the framework we will need to move some other things
around since it currently contains some bundles, so we might end up with:
trunk/
org.apache.felix.framework/
org.apache.felix.shell/
org.apache.felix.shell.tui/
org.apache.felix.bundlerepository/
The shell and bundlerepository subprojects include default
implementations that could be moved up to top-level subprojects if
deemed necessary in the future, such as if we eventually have multiple
implementations available of our own services.
For our outstanding contributions (i.e., UPnP, HTTP Service, and
Preferences Service) , I propose the following:
trunk/
org.apache.felix.http.jetty/
org.apache.felix.prefs.jndi/
org.apache.felix.upnp/
The first two allow for other service implementations (e.g., HTTP based
on Tomcat or Prefs based on files). For UPnP, it seems to me that
multiple implementations are less likely, so I didn't propose any
sub-package...UPnP implementation packages could be renamed later if
another implementation comes along.
I assume that we will get a Log Service before long, so that will likely
be something like:
trunk/
org.apache.felix.log.simple/
org.apache.felix.log.postgres/
Summarizing, we end up with the trunk/ directory being a flat list of
subprojects named after their package.
Thoughts?
-> richard