Hi,
Just want to clarify that you aren’t forced to use the ‘bundle’ packaging type
with the maven-bundle-plugin, the ‘bundle’ packaging is a convenience which
avoids having to add explicit executions to invoke goals at the right points of
the maven build lifecycle (such as using bndlib to pul
My 2 cents as a non developer for felix or karaf
I have made the switch for my core packages to the bnd-maven-plugin and
like that I can copy things between my bnd.bnd file and my bndrun file
that I use for testing in eclipse. I am looking forward to when they get
launcher and test support for
Thanks for the suggestions Christian. I may indeed write a blog post. In the
meantime, you can place this in the bnd.bnd of your parent project:
-exportcontents:
${packages;ANNOTATED;org.osgi.annotation.versioning.Version}
This exports any packages that have the @Version annotation on t
Thanks for the clarifications.
I personally like the external bnd.bnd files. They are more concise than
xml configs.
You should maybe write a blog entry about the annotations and also the
parent configs. I liked the way you generically set up the exports based
on the version annotations but fo
Just addressing a couple of points made on this list.
Yes, we support only instructions in the separate bnd.bnd file (currently).
However with judicious use of Java annotations, we find that you very rarely
need bnd instructions at all! However I don’t agree that this is the "biggest
difference
Is there an Embed-Dependency analog?
On Nov 9, 2015 12:07 PM, "Konrad Windszus" wrote:
> The biggest difference is that currently the bnd-maven-plugin does not
> support instructions within pom files (
> https://github.com/bndtools/bnd/issues/952) but rather only in dedicated
> bnd files.
> There
The biggest difference is that currently the bnd-maven-plugin does not support
instructions within pom files (https://github.com/bndtools/bnd/issues/952) but
rather only in dedicated bnd files.
Therefore for existing users of maven-bundle-plugin it is not so easy to
migrate.
Konrad
> On 09 Nov
Hi Christian,
it sounds promising, but maybe a bit early to have a strong opinion.
From a technology standpoint, it's good to converge.
However, we talk about two different community there, and maybe license.
As a tooling, it's not a big deal.
Regards
JB
On 11/09/2015 11:02 AM, Christian Schn
Is this the one that is 'owned' by the bndlib people, or are there
more than one?
The 'bnd' mailing list told me that it had less capability than the
maven-bundle-plugin, so that would be a reason not to retire.
I'll take on the lifecycle, but I'll make it a plugin that requires
maven 3, first. T
I recently looked into the bnd-maven-plugin from paremus. It features a
better maven lifecycle integration than the felix one.
So for example you do not need the packaging "bundle" anymore which is a
big obstacle for some projects.
It also will probably be part of the maven support for bdntools.
big push to get the
various tools (bndtools, m-b-p, etc) onto the latest level of bnd, which meant
a fair bit of churn in the codebase, but it should be stable now.
> thanks
> david jencks
>
> On Dec 2, 2011, at 10:15 AM, Stuart McCulloch wrote:
>
>> Hi folks,
>>
>
vid jencks
On Dec 2, 2011, at 10:15 AM, Stuart McCulloch wrote:
> Hi folks,
>
> Just a quick overview of the general roadmap for maven-bundle-plugin 2.4.0...
> basically I'd like to go through the codebase and try to tidy up all the
> accumulated patches and tweaks to reduce
Hi folks,
Just a quick overview of the general roadmap for maven-bundle-plugin 2.4.0...
basically I'd like to go through the codebase and try to tidy up all the
accumulated patches and tweaks to reduce code duplication and make things more
maintainable and understandable. Not the most exc
On Friday 17 June 2011 09:29 PM, Stuart McCulloch wrote:
thanks Sahoo -https://issues.apache.org/jira/browse/FELIX-2934 is the issue
I believe
Yes, that's the one. Thanks.
On 17 June 2011 14:46, Sahoo wrote:
> Stuart,
>
> I have had difficulty in building WABs using maven-bundle-plugin. If there
> is no embedded jar in the WAB (i.e., only WEB-INF/classes), then one can
> easily use war type project and configure bundle plugin to just run the
> manifest goal in proc
Stuart,
I have had difficulty in building WABs using maven-bundle-plugin. If
there is no embedded jar in the WAB (i.e., only WEB-INF/classes), then
one can easily use war type project and configure bundle plugin to just
run the manifest goal in process-classes phase and configuring maven
pack
with default mapping to process-classes; that
should resolve this nicely?
Original Message ----
Subject: maven-bundle-plugin roadmap
From: Stuart McCulloch
To: dev@felix.apache.org
Date: Thu 16 Jun 2011 01:04:08 PM CDT
> FYI, I'm doing a triage of maven-bundle-plugin iss
FYI, I'm doing a triage of maven-bundle-plugin issues this week with the aim of
fixing small bugs before staging a new maintenance release.
I'll also be planning what features should go into the next major release, so
now's the time to vote / flag issues so they get some attention :)
--
Cheers,
Ok, it is fixed in trunk now. Just a silly bug.
-> richard
On 3/11/11 9:16, Richard S. Hall wrote:
On 3/11/11 9:14, Richard S. Hall wrote:
On 3/11/11 2:35, Guillaume Nodet wrote:
Btw, the bundle is available at:
http://repo2.maven.org/maven2/org/ops4j/pax/url/pax-url-mvn/1.2.4/pax-url-mvn
On 3/11/11 9:14, Richard S. Hall wrote:
On 3/11/11 2:35, Guillaume Nodet wrote:
Btw, the bundle is available at:
http://repo2.maven.org/maven2/org/ops4j/pax/url/pax-url-mvn/1.2.4/pax-url-mvn-1.2.4.jar
I just have to try to start this bundle to see the error?
Answering myself, yes.
Ok, I
On 3/11/11 2:35, Guillaume Nodet wrote:
Btw, the bundle is available at:
http://repo2.maven.org/maven2/org/ops4j/pax/url/pax-url-mvn/1.2.4/pax-url-mvn-1.2.4.jar
I just have to try to start this bundle to see the error?
-> richard
On Fri, Mar 11, 2011 at 08:33, Guillaume Nodet wrote:
I'
Btw, the bundle is available at:
http://repo2.maven.org/maven2/org/ops4j/pax/url/pax-url-mvn/1.2.4/pax-url-mvn-1.2.4.jar
On Fri, Mar 11, 2011 at 08:33, Guillaume Nodet wrote:
> I've had a look at the resolution problem i had with 3.0.8 but now hit
> a weird resolution exception on a singleton
I've had a look at the resolution problem i had with 3.0.8 but now hit
a weird resolution exception on a singleton bundle:
karaf@root> osgi:start --force 1
Error executing command: Unresolved constraint in bundle
org.ops4j.pax.url.mvn [1]: Unable to resolve 1.0
karaf@root> headers 1
OPS4J Pax Url
On 3/10/11 15:29, David Bosschaert wrote:
Hi Richard,
On 10 March 2011 20:01, Richard S. Hall wrote:
A heads up...
I've committed a pretty substantial patch to the framework resolver, which
furthers the goal of eventually making it a separate module/subproject.
Previously, the resolver did no
Hi Richard,
On 10 March 2011 20:01, Richard S. Hall wrote:
> A heads up...
>
> I've committed a pretty substantial patch to the framework resolver, which
> furthers the goal of eventually making it a separate module/subproject.
> Previously, the resolver did not actually handle fragments or singl
A heads up...
I've committed a pretty substantial patch to the framework resolver,
which furthers the goal of eventually making it a separate
module/subproject. Previously, the resolver did not actually handle
fragments or singleton bundles and instead left this up to the user of
the resolver
On Jun 15, 2007, at 7:51 PM, Marcel Offermans wrote:
On Jun 15, 2007, at 21:37 , Richard S. Hall wrote:
I, for one, like how the wiki formats code blocks (with syntax
highlighting, etc.) and with more color. Our generated static
pages look cute boring and mundane by comparison.
I think t
On Jun 15, 2007, at 21:37 , Richard S. Hall wrote:
I, for one, like how the wiki formats code blocks (with syntax
highlighting, etc.) and with more color. Our generated static pages
look cute boring and mundane by comparison.
I think this could be the first step in updating our web page...
J Aaron Farr wrote:
Okay, I hear the message about the wiki. :-) I'm going to first review
all the current documentation again and then I'll ping the mailing
list before I make any changes.
Following up on the topic of improving the web page...
I just finished moving some tutorials to the F
Okay, I hear the message about the wiki. :-) I'm going to first review
all the current documentation again and then I'll ping the mailing
list before I make any changes.
"Richard S. Hall" <[EMAIL PROTECTED]> writes:
> Ultimately, I agree with everything you had to say about the web site,
> excep
On 23/05/07, Tim Moloney <[EMAIL PROTECTED]> wrote:
Richard S. Hall wrote:
> Stuart McCulloch wrote:
>> On 22/05/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
>>> In summary, the dilemma we had was that everyone wanted the artifactId
>>> to be the short name and the JAR file to be the long name.
Richard S. Hall wrote:
Stuart McCulloch wrote:
On 22/05/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
In summary, the dilemma we had was that everyone wanted the artifactId
to be the short name and the JAR file to be the long name. But if we
made the artifactId the short name, then we also got
Stuart McCulloch wrote:
On 22/05/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
In summary, the dilemma we had was that everyone wanted the artifactId
to be the short name and the JAR file to be the long name. But if we
made the artifactId the short name, then we also got the short name for
the
On 22/05/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
In summary, the dilemma we had was that everyone wanted the artifactId
to be the short name and the JAR file to be the long name. But if we
made the artifactId the short name, then we also got the short name for
the JAR.
FYI, it is possibl
On May 21, 2007, at 20:44 , Richard S. Hall wrote:
In summary, the dilemma we had was that everyone wanted the
artifactId to be the short name and the JAR file to be the long
name. But if we made the artifactId the short name, then we also
got the short name for the JAR.
+1
Exactly, as s
Carlos Sanchez wrote:
On 5/21/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
I don't care how it is stored in the repository. The issue I have is
that the generated artifact in target/ has a name...I don't want to
manually have to change the name after doing "mvn clean
install"...however, it is
On 5/21/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
I don't care how it is stored in the repository. The issue I have is
that the generated artifact in target/ has a name...I don't want to
manually have to change the name after doing "mvn clean
install"...however, it is probably better if the
d. So, do you recommend that we use maven-bundle-plugin for the
artifactId of the bundle plugin?
-> richard
-> richard
>
>
> On 5/21/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
>> Tim Moloney wrote:
>> > I agree with the proposed roadmap. My only comment
ed to rename it so you can use "y" as artifactId
Still, I am not altogether clear how this issue relates to our
discussion of what the artifactId for our plugin should be. Are these
two related?
right, it's not related to plugin autodiscovery
-> richard
>
>
> On 5/
Chris Custine wrote:
I am in the process of reworking the Apache Directory installers,
which the
Felix installers project is based on, so I could see about fixing up the
installers here in the next couple of weeks. Are there any changes
you need
for the setup or do you just need the existing
ing the rename.
Still, I am not altogether clear how this issue relates to our
discussion of what the artifactId for our plugin should be. Are these
two related?
-> richard
On 5/21/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
Tim Moloney wrote:
> I agree with the proposed ro
Hi,
I've been thinking about the wiki / offline documentation
scenarios for a while as well.
Another great thing about the wiki is that
edits are immediately visible for everyone.
Personally though I have a need to automate
things like look and feel, table of contents,
etc. so I created a mojo
Ok here is some doco but there was something more extensive written by
Pierre. I will
CC him in case my link is wrong:
http://cwiki.apache.org/DIRxPMGT/web-site-management.html
Alex
On 5/21/07, Alex Karasulu <[EMAIL PROTECTED]> wrote:
Yeah and there is some doco on this that we have... Let
Yeah and there is some doco on this that we have... Let me post the link to
it ...
Alex
On 5/21/07, Chris Custine <[EMAIL PROTECTED]> wrote:
Apache Directory also uses the Confluence export plugin to produce
http://directory.apache.org and I think the setup works really well for
that
site. I
ols/plugins the ones renaming appropriately
for the target environment
it'd also map easier to the maven repo
WDYT?
On 5/21/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
Tim Moloney wrote:
> I agree with the proposed roadmap. My only comment is on the name of
> the plugin.
a to lock
down the versions you want.
-> richard
>
> Regards,
> Alin Dreghiciu
>
> On 5/21/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
>>
>> Tim Moloney wrote:
>> > I agree with the proposed roadmap. My only comment is on the name of
>> > t
> I'd love to see the release of the bundle plugin to use it in the
> Maven project.
I would like to see the "tools" stabilized and released first. Then felix
1.0 should be built using the released tools and itself then released. The
time delta between these 2 events can be short but it should
I am in the process of reworking the Apache Directory installers, which the
Felix installers project is based on, so I could see about fixing up the
installers here in the next couple of weeks. Are there any changes you need
for the setup or do you just need the existing setup to work? I haven't
Apache Directory also uses the Confluence export plugin to produce
http://directory.apache.org and I think the setup works really well for that
site. I am sure the setup and export template could be borrowed and used in
conjunction with some minor graphics work to improve the aesthetics of the
Fe
On Monday 21 May 2007 03:11, Karl Pauls wrote:
> 1) Should it be yet another tarball release or does somebody volunteer to
> get our installer up and running again?
As long as the sources are generated in a tarball and placed
in /www/www.apache/org/dist, the legal requirement is met.
Any binary s
Ultimately, I agree with everything you had to say about the web site,
except for the recommendation not to use a wiki. I don't have a love
affair with wikis and I agree that often they do not look good, but the
number one reason why I want to use a wiki is that I hate to do
documentation, but
Marcel Offermans wrote:
On May 21, 2007, at 15:08 , Richard S. Hall wrote:
Tim Moloney wrote:
I agree with the proposed roadmap. My only comment is on the name
of the plugin. bundleplugin doesn't follow the Maven convention of
maven-foo-plugin or foo-maven-plugin.
Is there some r
5/21/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
>>
>> Tim Moloney wrote:
>> > I agree with the proposed roadmap. My only comment is on the
name of
>> > the plugin. bundleplugin doesn't follow the Maven convention of
>> > maven-foo-plugin o
+1
On 5/21/07, Marcel Offermans <[EMAIL PROTECTED]> wrote:
On May 21, 2007, at 15:08 , Richard S. Hall wrote:
> Tim Moloney wrote:
>> I agree with the proposed roadmap. My only comment is on the name
>> of the plugin. bundleplugin doesn't follow the Maven convent
released more
frequently, fact that will allow me to keep the dependency on the released
version and not the snapshot one. Bassicaly this is what I ment by "a life
of it's own"
Regards,
Alin Dreghiciu
-> richard
>
> Regards,
> Alin Dreghiciu
>
> On 5/21/07, Richa
On May 21, 2007, at 15:08 , Richard S. Hall wrote:
Tim Moloney wrote:
I agree with the proposed roadmap. My only comment is on the name
of the plugin. bundleplugin doesn't follow the Maven convention
of maven-foo-plugin or foo-maven-plugin.
Is there some reason for this conventio
Hello Aaron,
On May 21, 2007, at 7:38 , J Aaron Farr wrote:
"Richard S. Hall" <[EMAIL PROTECTED]> writes:
Matthias Luebken wrote:
I suggest that you update the website felix.apache.org so that the
ongoing improvements are reflected on the website. If you don't look
into the Jira Issue Tracke
,
Alin Dreghiciu
On 5/21/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
Tim Moloney wrote:
> I agree with the proposed roadmap. My only comment is on the name of
> the plugin. bundleplugin doesn't follow the Maven convention of
> maven-foo-plugin or foo-maven-plugin
te:
> I agree with the proposed roadmap. My only comment is on the name of
> the plugin. bundleplugin doesn't follow the Maven convention of
> maven-foo-plugin or foo-maven-plugin.
Is there some reason for this convention? It ends up violating our own
convention of naming generated artif
Tim Moloney wrote:
I agree with the proposed roadmap. My only comment is on the name of
the plugin. bundleplugin doesn't follow the Maven convention of
maven-foo-plugin or foo-maven-plugin.
Is there some reason for this convention? It ends up violating our own
convention of n
I agree with the proposed roadmap. My only comment is on the name of
the plugin. bundleplugin doesn't follow the Maven convention of
maven-foo-plugin or foo-maven-plugin.
Richard S. Hall wrote:
Richard S. Hall wrote:
Carlos Sanchez wrote:
A release as TLP is very important as it&#x
"Richard S. Hall" <[EMAIL PROTECTED]> writes:
> Matthias Luebken wrote:
>> I suggest that you update the website felix.apache.org so that the
>> ongoing improvements are reflected on the website. If you don't look
>> into the Jira Issue Tracker, you don't have the impression that there
>> is much
Hi,
Thanks for taking the initiative.
I completely agree that doing a core 1.0 release is probably best. I do not
have a strong opinion regarding the installer, but maybe it would help
promote Felix if we had one.
I also agree, that we should include the maven plugin.
Regards
Felix
o follow-up on recent discussions - and our new status as a
TLP - I'd like to get a roadmap towards a new release going. Let me
try to get a few thoughts across and see what the general reactions
are :-)
Looking back at recent comments and events I believe it would be
beneficial to get a new (an
r to follow-up on recent discussions - and our new status as a
TLP - I'd like to get a roadmap towards a new release going. Let me
try to get a few thoughts across and see what the general reactions
are :-)
Looking back at recent comments and events I believe it would be
beneficial to get a new (an
Yes, this is basically my thinking for the roadmap too.
I would prefer to get the installer back working, especially since it
will give us the possibility to install Felix as a daemon.
-> richard
Karl Pauls wrote:
Dear Felix Community,
in order to follow-up on recent discussions - and
l Pauls <[EMAIL PROTECTED]> wrote:
Dear Felix Community,
in order to follow-up on recent discussions - and our new status as a
TLP - I'd like to get a roadmap towards a new release going. Let me
try to get a few thoughts across and see what the general reactions
are :-)
Looking back at re
I agree that it's beneficial to get a release of the core framework
done quickly, to give others using Felix a stable base to work on. I
have no problems whatsoever calling it 1.0 (it sure is stable and
proven enough to be called at least that), and I don't have an
outspoken opinion about r
Dear Felix Community,
in order to follow-up on recent discussions - and our new status as a
TLP - I'd like to get a roadmap towards a new release going. Let me
try to get a few thoughts across and see what the general reactions
are :-)
Looking back at recent comments and events I belie
atthias
On 5/18/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
Matthias,
> I am wandering what the current status of your roadmap is?
> I've read on some slides that you wanted to go to 1.0 soon?
Yes, we will be working on updating our roadmap very soon (i.e., within
a week)
7, Richard S. Hall <[EMAIL PROTECTED]> wrote:
Matthias,
> I am wandering what the current status of your roadmap is?
> I've read on some slides that you wanted to go to 1.0 soon?
Yes, we will be working on updating our roadmap very soon (i.e., within
a week)...
> If so, w
Matthias,
I am wandering what the current status of your roadmap is?
I've read on some slides that you wanted to go to 1.0 soon?
Yes, we will be working on updating our roadmap very soon (i.e., within
a week)...
If so, what will be the changes to the current version?
As part of the
Hi Felixens
I am wandering what the current status of your roadmap is?
I've read on some slides that you wanted to go to 1.0 soon?
If so, what will be the changes to the current version?
I am especially asking in regards to this comparison:
http://www.pierocampanelli.info/articles/2007/
73 matches
Mail list logo
