You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Bennett, Timothy (JIS - Applications)" <Ti...@jis.nashville.org> on 2005/08/23 06:55:03 UTC
JIRA Components
Can we create components within JIRA Felix?
Now that we have at least two products in SVN (framework + maven-osgi-plugin), I think we might need to start thinking about organizing JIRA issues according to products.
I'd be happy to help if I had the appropriate JIRA rights...
-- tbennett
Re: JIRA Components
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 24 August 2005 01:36, Upayavira wrote:
> Or we could have a 'line' of products that we call 'feline'. Hmm.
He he... "Felix the Cat", old cartoon...
Cheers
Niclas
Re: JIRA Components
Posted by Upayavira <uv...@odoko.co.uk>.
Niclas Hedhman wrote:
> On Tuesday 23 August 2005 23:47, Richard S. Hall wrote:
>
>>I guess this is a question of to what does the name "Felix" refer?
>>
>>My assumption is that Felix itself refers to the container, i.e., the
>>framewor
>
>
> Felix is first and foremost the "community name". As it will receive
> felix.apache.org when it graduates.
>
> Secondly, but more common to the wider public, is the "Product".
>
> Richard suggests that "Felix == The OSGi container of the Felix project."
> which makes perfect sense to me.
>
> Assuming that the scope of "the Felix community" is beyond the container, and
> also includes bundles for various purposes, those _should not_ be Felix
> specific, hence possibly detached from the Felix name for technical reasons,
> but associated with "the Felix community" for social reasons.
>
>
> Tricky this one.
>
>
> Personally, I think I lean towards Richard's definition of the "Felix Product"
> and have a "FeLib" (just kidding) of bundles under one or more umbrella
> names, with mostly descriptive names.
Or we could have a 'line' of products that we call 'feline'. Hmm.
Upayavira
Re: JIRA Components
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 23 August 2005 23:47, Richard S. Hall wrote:
> I guess this is a question of to what does the name "Felix" refer?
>
> My assumption is that Felix itself refers to the container, i.e., the
> framewor
Felix is first and foremost the "community name". As it will receive
felix.apache.org when it graduates.
Secondly, but more common to the wider public, is the "Product".
Richard suggests that "Felix == The OSGi container of the Felix project."
which makes perfect sense to me.
Assuming that the scope of "the Felix community" is beyond the container, and
also includes bundles for various purposes, those _should not_ be Felix
specific, hence possibly detached from the Felix name for technical reasons,
but associated with "the Felix community" for social reasons.
Tricky this one.
Personally, I think I lean towards Richard's definition of the "Felix Product"
and have a "FeLib" (just kidding) of bundles under one or more umbrella
names, with mostly descriptive names.
Cheers
Niclas
Re: JIRA Components
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Richard S. Hall wrote:
> For example, the core class of the framework is called Felix, thus
> creating an instance of the framework is "new Felix(...)". If the
> framework is not actually called Felix, then this might not make sense.
I should also state that I prefer using the name Felix for the framework
as opposed to the "Felix framework".
In my experience with Oscar, most people associated the name with the
framework, while at the same time associating it with the entire effort
(i.e., including bundles, tools, etc.) without much confusion.
-> richard
Re: JIRA Components
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Alex Karasulu wrote:
> Perhaps we keep the FELIX project for general issues. We should
> create separate projects under the Felix category for the maven
> plugin, eclipse plugin and the core container. All separately
> releaseable bundles can be projects as well within the FELIX category.
It was my understanding that the "Felix" project was for the framework.
I guess this is a question of to what does the name "Felix" refer?
My assumption is that Felix itself refers to the container, i.e., the
framework.
The more general term/phrase of "the Felix Project" refers to everything
else that is related to it.
For example, the core class of the framework is called Felix, thus
creating an instance of the framework is "new Felix(...)". If the
framework is not actually called Felix, then this might not make sense.
-> richard
Re: JIRA Components
Posted by Alex Karasulu <ao...@bellsouth.net>.
Enrique Rodriguez wrote:
> Bennett, Timothy (JIS - Applications) wrote:
>
>> Can we create components within JIRA Felix?
>
>
> The problem with the JIRA "components" is that you can't rev
> components separately using the JIRA version/roadmap features. All
> components have to rev together. By "rev" I mean if you create a 0.1
> release and tie issues to it, all components are part of that 0.1
> release.
>
Good points you make here Enrique. Let's create separate Felix projects
and prefix them with FELIX so that we can version different deliverables
separately. I really like using the road map features so when it comes
to components verses projects in a category I'm a +1 for separate JIRA
projects.
>> Now that we have at least two products in SVN (framework +
>> maven-osgi-plugin), I think we might need to start thinking about
>> organizing JIRA issues according to products.
>
>
> Right now we have the FELIX project in JIRA. We would need new
> projects for the maven-osgi-plugin and the eclipse plugin. No big
> deal; I'd just like to point this out since it recently bit me. We
> have a "Felix" category to help group Felix project related
> subprojects like these together.
Perhaps we keep the FELIX project for general issues. We should create
separate projects under the Felix category for the maven plugin, eclipse
plugin and the core container. All separately releaseable bundles can
be projects as well within the FELIX category.
Alex
Re: JIRA Components
Posted by Enrique Rodriguez <en...@gmail.com>.
Bennett, Timothy (JIS - Applications) wrote:
> Can we create components within JIRA Felix?
The problem with the JIRA "components" is that you can't rev components
separately using the JIRA version/roadmap features. All components have
to rev together. By "rev" I mean if you create a 0.1 release and tie
issues to it, all components are part of that 0.1 release.
> Now that we have at least two products in SVN (framework + maven-osgi-plugin), I think we might need to start thinking about organizing JIRA issues according to products.
Right now we have the FELIX project in JIRA. We would need new projects
for the maven-osgi-plugin and the eclipse plugin. No big deal; I'd just
like to point this out since it recently bit me. We have a "Felix"
category to help group Felix project related subprojects like these
together.
Enrique
Re: Tooling
Posted by Jeff McAffer <Je...@ca.ibm.com>.
The problem of community coordination is difficult no matter what.
Certainly there are setup and convention issues. I believe this to be
true of any community/society. The current discussion on where to put
what and how to arrange the repository is a perfect example. This is not
inherent in IDEs (GUI or otherwise). The point of tooling, including
IDEs, is to help the community to produce better output faster and with
less pain.
Your message below highlights that there are different points of view on
how to develop software and in fact, whether not IDEs help. For example,
the Eclipse tooling emphasizes developer experience in the code, compile,
debug cycle to make this basically free. No classpath maintenance, no
building, no deploying, .... Some people prefer to manage their
classpaths, build JARs, deploy them and then debug them. This, like
formatting, is a religious discussion best left for beer time.
My main reason I sent the original message was to point out that there are
many Eclipse developers out there. Many of them are "plugin/bundle"
developers. In the process of building an OSGi community it seems that
Felix would do well to embrace these people and not prohibit their
participation through ignorance. To that end, since you have complete
freedom in setting up your conventions and structures, I suggest that you
not set things up such that Eclipse users have a hard time living in this
community.
Jeff
Niclas Hedhman <ni...@hedhman.org> wrote on 08/23/2005 01:43:28 PM:
> On Tuesday 23 August 2005 23:26, Jeff McAffer wrote:
> > The summary is that we can (and will) do better in the tooling but the
> > present tooling addresses the very significant issues of classpath
> > management and incremental building/launching/testing. In our
experience,
> > those are the places that developers really get tripped up and spend
time.
>
> I have a perpetual fear of becoming dependent on (to whatever degree) on
GUI
> based tools, as experience generally shows that there are several issues
> related to IDEs and collaborated efforts;
>
> 1. It is difficult to get people to have the *exactly* same setup for
the
> IDE. This results in for instance "automatic formatting" being
executed
> by individuals, committing code into the repository with no
positive
> content, only creating larger commits which are hard to review.
> If several such individuals are let free, review deteriorate to
"none"
> and is a "no go" for auto formatting.
> I agree this is the developer's responsibility, but the IDEs does
not
> seem to take this very seriously. I am sure you (Jeff) will
highlight
> that the entire eclipse community manages this "issue", so I guess;
> - each part of the codebase is only coded by one person, or
> - draconian enforcement of a common setup, or
> - checkstyle is enforced in Subversion pre-commit hook, or
> - peer review is not done by the mails sent from commits, or
> - everyone thinks it is Ok.
> Perhaps I have missed some better way... but any of the above seem
> "difficult".
>
> 2. It is still unclear to me, whether the hidden .classpath and
.project
> files should be committed to a shared code repository or not. Some
> claim it is possible to solve the issue with "Variable" in
Libraries.
> IIRC, generation of Jar files and other artifacts also seemed very
> sensitive to introduce "local conditions" making it troublesome.
> If they are not committed, it is hard to keep up with changes
> made by other people (introduction of new packages for instance).
> If they are committed, the commits become "large", more frequent
and
> harder to review.
>
> 3. People who have "strong" IDE background tend to do many "sensitive"
> tasks manually, since it "is so easy, just click...", which to me
is
> insane. Maybe it is a coincidence that my experience is that
> "Eclipse-only releases" are more riddled with problems than those
with
> automated processes. (By the way, that goes for other manual tools
> used as well, so not an Eclipse problem per se.)
>
> 4. The IDEs I have used so far (Eclipse, Netbeans and IDEA) are all
> extremely weak in dependency management. No separation between
build,
> runtime and testtime dependencies, which would create incorrect
> dependencies for the bundles (if used), AFAICT.
>
> I don't want to discourage people to use Eclipse in any way, but I am
> convinced that it, and all other IDEs, are not good "build tools", but
is
> excellent in other areas to improve productivity, such as editing,
access to
> relevant information, navigation, refactoring and so on.
>
>
> Another related note;
>
> Small detail about Bundle development with Eclipse 3.1, that I am
currently
> being faced with;
> The Eclipse developers (I am not one of them) claim that Eclipse "must
have"
> the bundle manifest in <projectroot>/META-INF. I think I have also heard
that
> Eclipse "own" that manifest and will populate it as one "go along",
whereas
> we depend on automated build processes which will generate the manifest
> during each run, from the overall project model (similar to Maven's
POM).
>
> Somehow I get the impression that this is an example of a
"all-or-nothing"
> approach that does not improve group productivity and is potentially a
> quality risk.
>
> I hope I don't sound too negative. Just trying to raise awareness
ofexisting,
> and definately unsolved, issues around the "IDE as build tool", and to
some
> lesser degree "Eclipse for collaborative efforts".
>
>
> Cheers
> Niclas
Re: Tooling
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 24 August 2005 11:55, Mike Milinkovich wrote:
> All of us at Eclipse recognize that there are many people who prefer to
> not use IDEs. The point of Jeff's post was not to encourage anyone to
> move to GUI-based tools who don't want them.
Yes. I am very happy with Jeff's and your response.
> As external observers, it seems that a sensible alternative to
> writing YAPI (yet another plug in) may be to evaluate the PDE to see if
> can address your requirements.
Ok, I agree on that.
> It seems quite possible the Felix team may draw a distinction between the
> tools that you want to use within the team for Felix development (likely
> non-GUI, based on your comments)
This is not for me to decide. I am just high-lighting past experiences using
IDEs in Apache-style collaboration efforts.
> and the tools which you would like to make
> available to your consumers (likely GUI, based on the "Oscar's Studio"
> thread) to help encourage adoption.
Yes, good tools of both kinds are essential to adoption. Considering the
diversity in this community, I am sure we will get there in due time.
Cheers
Niclas
RE: Tooling
Posted by Mike Milinkovich <mi...@eclipse.org>.
Niclas,
All of us at Eclipse recognize that there are many people who prefer to not
use IDEs. The point of Jeff's post was not to encourage anyone to move to
GUI-based tools who don't want them.
However, there is a thread from a while back entitled "Oscar's Studio" that
talks about building an Eclipse plug-in for Felix (nee Oscar). What Jeff is
suggesting is that a highly functional GUI tool already exists for building
bundles already exists with the Eclipse 3.1 Plug-In Development Environment
(PDE). As external observers, it seems that a sensible alternative to
writing YAPI (yet another plug in) may be to evaluate the PDE to see if can
address your requirements.
If there are deficiencies in the tools, file bugs and I'm sure Jeff's team
will try their very best to address them.
But this is not an assertion that non-GUI tools are unnecessary or
undesirable. Clearly, many very good developers prefer that approach.
It seems quite possible the Felix team may draw a distinction between the
tools that you want to use within the team for Felix development (likely
non-GUI, based on your comments) and the tools which you would like to make
available to your consumers (likely GUI, based on the "Oscar's Studio"
thread) to help encourage adoption.
> -----Original Message-----
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
> Sent: August 23, 2005 1:43 PM
> To: oscar-dev@incubator.apache.org
> Subject: Re: Tooling
>
> On Tuesday 23 August 2005 23:26, Jeff McAffer wrote:
> > The summary is that we can (and will) do better in the
> tooling but the
> > present tooling addresses the very significant issues of classpath
> > management and incremental building/launching/testing. In our
> > experience, those are the places that developers really get
> tripped up and spend time.
>
> I have a perpetual fear of becoming dependent on (to whatever
> degree) on GUI based tools, as experience generally shows
> that there are several issues related to IDEs and
> collaborated efforts;
>
> 1. It is difficult to get people to have the *exactly* same
> setup for the
> IDE. This results in for instance "automatic formatting"
> being executed
> by individuals, committing code into the repository with
> no positive
> content, only creating larger commits which are hard to review.
> If several such individuals are let free, review
> deteriorate to "none"
> and is a "no go" for auto formatting.
> I agree this is the developer's responsibility, but the
> IDEs does not
> seem to take this very seriously. I am sure you (Jeff)
> will highlight
> that the entire eclipse community manages this "issue",
> so I guess;
> - each part of the codebase is only coded by one person, or
> - draconian enforcement of a common setup, or
> - checkstyle is enforced in Subversion pre-commit hook, or
> - peer review is not done by the mails sent from commits, or
> - everyone thinks it is Ok.
> Perhaps I have missed some better way... but any of the
> above seem
> "difficult".
>
> 2. It is still unclear to me, whether the hidden .classpath
> and .project
> files should be committed to a shared code repository or
> not. Some
> claim it is possible to solve the issue with "Variable"
> in Libraries.
> IIRC, generation of Jar files and other artifacts also
> seemed very
> sensitive to introduce "local conditions" making it troublesome.
> If they are not committed, it is hard to keep up with changes
> made by other people (introduction of new packages for instance).
> If they are committed, the commits become "large", more
> frequent and
> harder to review.
>
> 3. People who have "strong" IDE background tend to do many
> "sensitive"
> tasks manually, since it "is so easy, just click...",
> which to me is
> insane. Maybe it is a coincidence that my experience is that
> "Eclipse-only releases" are more riddled with problems
> than those with
> automated processes. (By the way, that goes for other
> manual tools
> used as well, so not an Eclipse problem per se.)
>
> 4. The IDEs I have used so far (Eclipse, Netbeans and IDEA) are all
> extremely weak in dependency management. No separation
> between build,
> runtime and testtime dependencies, which would create incorrect
> dependencies for the bundles (if used), AFAICT.
>
> I don't want to discourage people to use Eclipse in any way,
> but I am convinced that it, and all other IDEs, are not good
> "build tools", but is excellent in other areas to improve
> productivity, such as editing, access to relevant
> information, navigation, refactoring and so on.
>
>
> Another related note;
>
> Small detail about Bundle development with Eclipse 3.1, that
> I am currently being faced with; The Eclipse developers (I am
> not one of them) claim that Eclipse "must have"
> the bundle manifest in <projectroot>/META-INF. I think I have
> also heard that Eclipse "own" that manifest and will populate
> it as one "go along", whereas we depend on automated build
> processes which will generate the manifest during each run,
> from the overall project model (similar to Maven's POM).
>
> Somehow I get the impression that this is an example of a
> "all-or-nothing"
> approach that does not improve group productivity and is
> potentially a quality risk.
>
> I hope I don't sound too negative. Just trying to raise
> awareness of existing, and definately unsolved, issues around
> the "IDE as build tool", and to some lesser degree "Eclipse
> for collaborative efforts".
>
>
> Cheers
> Niclas
Re: Tooling
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 23 August 2005 23:26, Jeff McAffer wrote:
> The summary is that we can (and will) do better in the tooling but the
> present tooling addresses the very significant issues of classpath
> management and incremental building/launching/testing. In our experience,
> those are the places that developers really get tripped up and spend time.
I have a perpetual fear of becoming dependent on (to whatever degree) on GUI
based tools, as experience generally shows that there are several issues
related to IDEs and collaborated efforts;
1. It is difficult to get people to have the *exactly* same setup for the
IDE. This results in for instance "automatic formatting" being executed
by individuals, committing code into the repository with no positive
content, only creating larger commits which are hard to review.
If several such individuals are let free, review deteriorate to "none"
and is a "no go" for auto formatting.
I agree this is the developer's responsibility, but the IDEs does not
seem to take this very seriously. I am sure you (Jeff) will highlight
that the entire eclipse community manages this "issue", so I guess;
- each part of the codebase is only coded by one person, or
- draconian enforcement of a common setup, or
- checkstyle is enforced in Subversion pre-commit hook, or
- peer review is not done by the mails sent from commits, or
- everyone thinks it is Ok.
Perhaps I have missed some better way... but any of the above seem
"difficult".
2. It is still unclear to me, whether the hidden .classpath and .project
files should be committed to a shared code repository or not. Some
claim it is possible to solve the issue with "Variable" in Libraries.
IIRC, generation of Jar files and other artifacts also seemed very
sensitive to introduce "local conditions" making it troublesome.
If they are not committed, it is hard to keep up with changes
made by other people (introduction of new packages for instance).
If they are committed, the commits become "large", more frequent and
harder to review.
3. People who have "strong" IDE background tend to do many "sensitive"
tasks manually, since it "is so easy, just click...", which to me is
insane. Maybe it is a coincidence that my experience is that
"Eclipse-only releases" are more riddled with problems than those with
automated processes. (By the way, that goes for other manual tools
used as well, so not an Eclipse problem per se.)
4. The IDEs I have used so far (Eclipse, Netbeans and IDEA) are all
extremely weak in dependency management. No separation between build,
runtime and testtime dependencies, which would create incorrect
dependencies for the bundles (if used), AFAICT.
I don't want to discourage people to use Eclipse in any way, but I am
convinced that it, and all other IDEs, are not good "build tools", but is
excellent in other areas to improve productivity, such as editing, access to
relevant information, navigation, refactoring and so on.
Another related note;
Small detail about Bundle development with Eclipse 3.1, that I am currently
being faced with;
The Eclipse developers (I am not one of them) claim that Eclipse "must have"
the bundle manifest in <projectroot>/META-INF. I think I have also heard that
Eclipse "own" that manifest and will populate it as one "go along", whereas
we depend on automated build processes which will generate the manifest
during each run, from the overall project model (similar to Maven's POM).
Somehow I get the impression that this is an example of a "all-or-nothing"
approach that does not improve group productivity and is potentially a
quality risk.
I hope I don't sound too negative. Just trying to raise awareness of existing,
and definately unsolved, issues around the "IDE as build tool", and to some
lesser degree "Eclipse for collaborative efforts".
Cheers
Niclas
Re: Tooling
Posted by Jeff McAffer <Je...@ca.ibm.com>.
Enrique
This does make sense. At this point we have not called out OSGi
specific/particular things in the doc. We have looked at providing a
"pure OSGi mode" in the tooling but in the end that amounted to turning
off the Extensions and Extension Points tabs and filtering a few of the
options in the wizards (e.g., trimming the Templates). For example, if
you don't create Extensions or Extension points then the plugin.xml is not
created. Things like Fragments are part of OSGi R4. In general, if you
look at a manifest.mf and see "Eclipse" in the headers or "x-" in the
attributes/directives then it is extra. If not, it is standard. Other
than that, Eclipse plugins are OSGi bundles.
WRT using things like SWT etc, those are just bundles. Dependencies on
these are not added unless you need/want them (e.g., if you pick a
template that has UI). Coding against these bundle is the same as coding
against any bundle. There are dependencies to be met and API to be used
if needed. This point is more one of having a rich set of bundles
available and needed to sort out what is what.
The summary is that we can (and will) do better in the tooling but the
present tooling addresses the very significant issues of classpath
management and incremental building/launching/testing. In our experience,
those are the places that developers really get tripped up and spend time.
Jeff
Enrique Rodriguez <en...@gmail.com>
08/23/2005 10:33 AM
Please respond to
oscar-dev
To
oscar-dev@incubator.apache.org
cc
Subject
Re: Tooling
On 8/23/05, Jeff McAffer <Je...@ca.ibm.com> wrote:
> I noticed some posts here on tooling to support bundle development. I
> thought I would take the opportunity to point out that Eclipse has a
> comprehensive suite of support for bundle development in the form of a
> Plugin Development Environment (PDE)...
Hi, Jeff,
Is there by any chance a tutorial (with pictures) on using Eclipse for
straight-up OSGi bundle development? Something that expands on the
plugin --> bundle mapping? Something for total beginners to both
Eclipse and OSGi? In particular, something targeted to those of us
wishing to create OSGi bundles for server-side components that won't be
using any Eclipse UI/SWT, etc.? The 3.1 PDE Guide and the PDE screens
don't make it clear what's OSGi and what's Eclipse, eg plugin.xml,
Fragments, and Extension Points. I have an idea of what's OSGi and
what's Eclipse, but I don't think most people do, and the mental mapping
of plugin --> bundle breaks down at some point. I'd like to make sure
I'm not relying on or generating anything that is not "pure" OSGi, since
I'm working on purely server-side bundles and I'm sure that other
developers at Apache have the fear that the IDE is automatically
generating unnecessary artifacts behind the scenes. Perhaps a mode is
in order for pure bundle development, with pure OSGi semantics. Does
that make sense?
Enrique
Re: Tooling
Posted by Enrique Rodriguez <en...@gmail.com>.
On 8/23/05, Jeff McAffer <Je...@ca.ibm.com> wrote:
> I noticed some posts here on tooling to support bundle development. I
> thought I would take the opportunity to point out that Eclipse has a
> comprehensive suite of support for bundle development in the form of a
> Plugin Development Environment (PDE)...
Hi, Jeff,
Is there by any chance a tutorial (with pictures) on using Eclipse for
straight-up OSGi bundle development? Something that expands on the
plugin --> bundle mapping? Something for total beginners to both
Eclipse and OSGi? In particular, something targeted to those of us
wishing to create OSGi bundles for server-side components that won't be
using any Eclipse UI/SWT, etc.? The 3.1 PDE Guide and the PDE screens
don't make it clear what's OSGi and what's Eclipse, eg plugin.xml,
Fragments, and Extension Points. I have an idea of what's OSGi and
what's Eclipse, but I don't think most people do, and the mental mapping
of plugin --> bundle breaks down at some point. I'd like to make sure
I'm not relying on or generating anything that is not "pure" OSGi, since
I'm working on purely server-side bundles and I'm sure that other
developers at Apache have the fear that the IDE is automatically
generating unnecessary artifacts behind the scenes. Perhaps a mode is
in order for pure bundle development, with pure OSGi semantics. Does
that make sense?
Enrique
Tooling
Posted by Jeff McAffer <Je...@ca.ibm.com>.
I noticed some posts here on tooling to support bundle development. I
thought I would take the opportunity to point out that Eclipse has a
comprehensive suite of support for bundle development in the form of a
Plugin Development Environment (PDE). Historically we call them plugins
but if you do the mental text replacement of "plugin" -> "bundle" in the
UI then it becomes a Bundle Development Environment :-) Eclipse plugins
== OSGi bundles. The online help details the use of PDE but the key
attributes of PDE in this context are:
- Automatic computation and management of the dynamic classpaths dictated
by bundle dependency statements. For example, when developing a bundle you
only get to see the classes you are supposed to see based on your stated
dependency information.
- "In-place" launching and debugging without building or deploying
- Manifest checking and validation
- Wizards for bundle creation
- High-level bundle editors
- Offline build based on dependencies in the manifests
- ... lots more ...
A couple of things to note:
- As was pointed out in some other posts, Eclipse has a convention of
using one project per bundle. I would encourage you to take this into
account in structuring your repository setup. Doing so allows the Eclipse
user community to join in developing bundles at Felix.
- Currently PDE can only launch the Eclipse OSGi implementation. It would
be interesting to see someone in the Felix community contribute support
for launching Felix. Note that this is really only an issue if you are
developing Felix itself. If you are developing standard bundles, it
doesn't matter which OSGi you test on.
Jeff
Re: JIRA Components
Posted by Enrique Rodriguez <en...@gmail.com>.
Bennett, Timothy (JIS - Applications) wrote:
...
> Now that we have at least two products in SVN (framework + maven-osgi-plugin), I think we might need to start thinking about organizing JIRA issues according to products.
To add JIRA projects for the maven and eclipse plugins we just need to
know the name and key. We'll prepend "FELIX" to the key of the new
projects. So, if people want to take a stab at the names and keys,
we'll get them created. Really only the creation needs to get done by a
JIRA admin. There are schemes and groups for Felix projects in JIRA so
as new Felix projects are added, these should be used:
Felix permissions
Felix notifications
(Group) felix-administrators
(Group) felix-developers
Enrique