I've moved the open issues and started the vote
Carsten
> last release of maven-bundle-plugin was last november - there have been some
> important updates e.g. latest bndlib since then. [1]
>
> is it possible to make a new release for it?
>
> there are two open issues assigned to the next vers
The Project Management Committee (PMC) for Apache Felix
has asked Jean-Baptiste Onofré to become a committer and
join the Apache Felix PMC as well. We are pleased to
announce that he has accepted.
Please join me in welcoming Jean-Baptiste.
Being a committer enables easier contribution to the
pro
+1
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
I would like to call a vote for the maven bundle plugin
We solved six issues in this release:
https://issues.apache.org/jira/browse/FELIX/fixforversion/12335566
Staging repositories:
https://repository.apache.org/content/repositories/orgapachefelix-1130/
You can use this UNIX script to download
[
https://issues.apache.org/jira/browse/FELIX-5241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated FELIX-5241:
Fix Version/s: (was: maven-bundle-plugin-3.1.0)
maven-bundle-plugin-fu
[
https://issues.apache.org/jira/browse/FELIX-5240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated FELIX-5240:
Fix Version/s: (was: maven-bundle-plugin-3.1.0)
maven-bundle-plugin-fu
last release of maven-bundle-plugin was last november - there have been some
important updates e.g. latest bndlib since then. [1]
is it possible to make a new release for it?
there are two open issues assigned to the next version [2] - i'm not sure if
they are release blockers.
stefan
[1]
h
[
https://issues.apache.org/jira/browse/FELIX-5304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed FELIX-5304.
---
> SERVICE_PID property should not be created
> --
>
>
The vote passes with three binding +1 and one non-binding +1 vote
Thanks
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
+1
Regards
Pierre
Le 14 juil. 2016 21:07, "Carsten Ziegeler" a écrit :
> We're missing a binding vote, anyone please?
>
> Thanks
>
> Carsten
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>
>
We're missing a binding vote, anyone please?
Thanks
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
That's also my point: as Felix provides atomic projects, it's so useful
for Felix itself. That's why it makes more sense in Karaf as it already
"packages" different Felix projects all together.
My $0.01.
Regards
JB
On 07/14/2016 03:40 PM, Carsten Ziegeler wrote:
Maybe we should ask who would
[
https://issues.apache.org/jira/browse/FELIX-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15376951#comment-15376951
]
Cristiano Gavião commented on FELIX-5116:
-
Thanks Carsten !
> Dump SCR component
Maybe we should ask who would really actually use this?
I'm not saying it is not useful, but still I would like to know if there
is some existing interest
Regards
Carsten
> Yes. That is the reason why I propose to adapt and release the bom about
> every 6 months to catch up with the changes.
> O
Yes. That is the reason why I propose to adapt and release the bom about
every 6 months to catch up with the changes.
Of course we can choose any time interval.
I would volunteer to provide the initial pom and also do the regular
updates if no one else does it.
Christian
On 14.07.2016 14:58,
"most for us", that's the point ;)
I'm still puzzled where to define such BoM.
In Karaf, we already do the validation of the versions all together
(that's one of the Karaf purpose). So, it's the most straight forward way.
In Felix, as we provide each dependency individually, we have to
remember
I think we will not be able to globally align dependencies for all
projects but the resolver should figure out most for us.
For the worst cases people can use excludes and overrides when the
depend on the boms.
Christian
On 14.07.2016 14:51, Jean-Baptiste Onofré wrote:
On the other hand, the s
On the other hand, the same issue can happen to maintain dependencies
aligned in different BoMs.
On 07/14/2016 02:49 PM, Christian Schneider wrote:
We can provide boms for projects in karaf but it then means that the
karaf team must monitor all upstream projects for changes and adapt the
boms.
We can provide boms for projects in karaf but it then means that the
karaf team must monitor all upstream projects for changes and adapt the
boms.
I think it makes more sense to let each project do this during their
releases.
It is like with features currently we still provide e.g. the hiberna
Ok, it makes sense.
As we already have kind of assembly of these Felix dependencies in
Karaf, why not providing this BoM in Karaf, with version aligned to the
Karaf release, and dependencies defined.
WDYT ?
Regards
JB
On 07/14/2016 10:50 AM, Christian Schneider wrote:
Yes. I propose to cre
Yes. I propose to create a module in felix for this purpose. A "bom" pom
to be
used by end users to easily create indexes. The pom would already have
all excludes and whatever is necessary to
produce a good list of bundles.
We could release this bom like every 6 months to bring all modules to
Hi Everyone
I'm forwarding the following message on behalf of Rich Bowen and the Apachecon
team
===
As you are aware, we are holding ApacheCon in Seville in November. While this
seems like a long way away, it is critical that we get on people's calendar
now, so that they can plan, get b
22 matches
Mail list logo
