jbonofre commented on issue #5: FELIX-6189 - Make sure jar/zip files are jailed
to the destination di…
URL: https://github.com/apache/felix-dev/pull/5#issuecomment-612755078
@karlpauls I will, but definitely, the same change broke Felix Utils (it has
to be fixed by the way). So, I will do
Hi Christian,
I will push the devx (for developer experience) branch today or tomorrow
morning.
Basically, it contains:
- a BOM providing the dependencies (osgi.annotation, jarxrs, …)
- a core/SDK
- extension for the sdk (gradle, maven, cli, junit5) building artifacts and
runtime
It comes
Inline...
> On Apr 12, 2020, at 3:23 PM, Christian Schneider
> wrote:
>
> Hi David,
>
> actually I did not think about Aries but you are right, it could also fit
> there. If the Felix community thinks Aries is the better place I will
> propose it there too.
> I think for marketing purposes
Hi David,
actually I did not think about Aries but you are right, it could also fit
there. If the Felix community thinks Aries is the better place I will
propose it there too.
I think for marketing purposes Felix is a lot more known than Aries.
The main purpose I want to achieve is that people
Hi Christian,
I’d like to know why felix is a better location for this than aries.
I also think that you should find a description or name other than “blueprint”
as that term has unfortunately been taken by the osgi blueprint spec. Seeing
your subject line I wondered why a blueprint (as in
karlpauls commented on issue #5: FELIX-6189 - Make sure jar/zip files are
jailed to the destination di…
URL: https://github.com/apache/felix-dev/pull/5#issuecomment-612676490
@jbonofre, did you manage to try it out?
This is
Hi Christian,
I don't think we are at that point just yet. Given that this is a
holiday surrounded weekend for a lot of us (due to the easter break) I
would say we should at least give it a couple of more days to see
where the discussion is going.
That said, I personally would like to see a
Howdy Christian, J-B, et al….
I’ve been working on such a thing for the last few weeks in a cloud of
shelter-in-place frustration, and I believe I can donate what I have
if it’s helpful at all (otherwise, I’ll be very interested in what you
have to see how it differs). I had that moment of
There seems to be some interest in having such a blueprint or even more
than one variant at felix.
Should I start in felix-dev or use a new repo?
I would prefer a new repo as the code will be a multi module maven project.
I propose a repo name "felix-cloud-native-starter".
We could have and have
Looking forward to what you come up with. Do you already have something to
look into or help with?
I will try to get along without a special runtime (basically just felix
framework + suitably configured bundles).
For a first application assembly I plan to use bnd maven plugins like in
the enroute
Hi Christian,
That’s interesting, but I think that people are expecting more than that.
1. Most of the time, we do things too much complex.
2. Assembly again layers is not always easy
3. Where’s the runtime ?
Your main point is valid: lot of people went too far in fine grained services
and
I don’t think anyone should take my opinion as definitive, but when I (briefly)
reviewed this some time ago I thought the proposed changes were fine. Since
the spec apparently suggests that this “service on demand” scenario should be
supported, I think this is a good idea.
David Jencks
> On
One interesting question is if CDI based applications and declarative
services based applications share enough commonalities to share the same
repo. CDI builds a lot upon its extensions which are not reusable in
declarative services.
I definitively support an Aries CDI based blueprint for
Hi Christian,
I also think it's a good idea. You might be aware that Aries CDI project is
also working toward this exact goal by implementing key Eclipse
MicroProfile parts (with the assistance of Apache Geronimo) which deliver
some of the feature areas you've outlined. The Apache Aries CDI BOM
[
https://issues.apache.org/jira/browse/FELIX-6203?focusedWorklogId=420936=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-420936
]
ASF GitHub Bot logged work on FELIX-6203:
-
Author: ASF GitHub Bot
doggy-dev opened a new pull request #17: FELIX-6203 skip adding comments in
pom.properties
URL: https://github.com/apache/felix-dev/pull/17
This is an automated message from the Apache Git Service.
To respond to the
Hi Neil,
indeed the idea is to build upon the same building blocks as the enroute
microservice example but enrich it with everything you need to get a fully
cloud ready service. It would be ideal to make it modular like spring boot
with the individual starters you can simply combine. Not sure
Hi Christian,
I think this would be great, but it does have a fair degree of overlap with
enRoute, at least in the early stages. It's always been a problem that OSGi
offers too many competing ways to do simple things, and if not done well
your idea would exacerbate the problem.
On the other
[
https://issues.apache.org/jira/browse/FELIX-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17081724#comment-17081724
]
mohamed chebbi commented on FELIX-6233:
---
No I don't have the TERM system variable in my system
Hi,
I agree it would be good to get to a conclusion on this one in one way
or the other.
@Tom, @David J - WDYT?
Regards
Carsten
On 23.03.2020 14:29, GLIMMERVEEN Arnoud wrote:
Hi all,
Last July I opened an issue [1] regarding SCR's behaviour with respect to
tracking services and how it
In recent years we saw a big trend towards micro services and cloud.
Lately people discovered though that such services are often made too fine
grained.
The newest trend goes to building bigger micro services on the level of
domain driven design bounded contexts.
Especially for these services
21 matches
Mail list logo
