Yeah, perfect.
Il giorno gio 20 feb 2020 alle ore 17:24 Gregor Zurowski <
gre...@list.zurowski.org> ha scritto:
> OK, sure. With every new major/minor release, I usually create a new
> "camel-MAJOR.MINOR.x" branch anyway. And for the actual release I
> create another branch
OK, sure. With every new major/minor release, I usually create a new
"camel-MAJOR.MINOR.x" branch anyway. And for the actual release I
create another branch "release/camel-MAJOR.MINOR.PATCH". I would
apply corresponding branches for Camel Spring Boot.
I believe that should be sufficient?
On
I'm talking about the camel-spring-boot repository.
Suppose you cut an RC for camel-3.1.0, and after that someone push on
master. The gh action syncing master camel and camel-sb could open a PR on
Camel-spring-boot with alignments or someone may regen the
camel-spring-boot project with the latest
I've finished with Camel 3.1.0 and will now proceed with Camel Spring Boot.
What do you mean by "we should create a branch with the current
history"? Are you talking about the Camel repository or the Camel
Spring Boot repository? And what history are you referring to?
Thanks in advance,
Gregor
Probably we should create a branch with the current history, to avoid
mixing up the master with the master branch in camel-sb
Il giorno gio 20 feb 2020 alle ore 13:38 Andrea Cosentino
ha scritto:
> Hello Gregor,
>
> are you cutting also the camel-spring-boot release already?
>
> Il giorno gio
Hello Gregor,
are you cutting also the camel-spring-boot release already?
Il giorno gio 20 feb 2020 alle ore 06:30 Claus Ibsen
ha scritto:
> Hi Gregor
>
> The memory leaks should have been fixed now. The code base should be
> good for the release.
>
> On Wed, Feb 19, 2020 at 11:41 PM Gregor
Hi Gregor
The memory leaks should have been fixed now. The code base should be
good for the release.
On Wed, Feb 19, 2020 at 11:41 PM Gregor Zurowski
wrote:
>
> Sure, I can start cutting the release tomorrow.
>
> Thanks,
> Gregor
>
>
> On Wed, Feb 19, 2020, 11:05 PM Claus Ibsen wrote:
>
> > Hi
Sure, I can start cutting the release tomorrow.
Thanks,
Gregor
On Wed, Feb 19, 2020, 11:05 PM Claus Ibsen wrote:
> Hi
>
> Okay the leaks have finally been fixed.
>
> Pascal will test as well on his end, but it should be good.
>
> Gregor let us know if you have time tomorrow (thursday) or
Hi
Okay the leaks have finally been fixed.
Pascal will test as well on his end, but it should be good.
Gregor let us know if you have time tomorrow (thursday) or friday to
cut the release.
On Wed, Feb 19, 2020 at 8:29 PM Claus Ibsen wrote:
>
> Hi
>
> Just an update the recipient list EIP leak
Hi
Just an update the recipient list EIP leak with error handler has been fixed.
However I found hidden another leak in the producer service pool
https://issues.apache.org/jira/browse/CAMEL-14594
On Wed, Feb 19, 2020 at 2:33 PM Claus Ibsen wrote:
>
> Hi Gregor
>
> The fix for the memory leak
Hi Gregor
The fix for the memory leak in Recipient List EIP takes longer time to
resolve properly.
At this time I think I need the rest of the day, so if you have time
tomorrow to cut the release then that would be better.
On Wed, Feb 19, 2020 at 10:55 AM Claus Ibsen wrote:
>
> Hi Gregor
>
>
>
Hi Gregor
On Wed, Feb 19, 2020 at 9:19 AM Gregor Zurowski
wrote:
>
> Thanks Andrea. I will start the release process towards the end of the day.
>
Good to hear. Just a heads up that we have another bug that must be fixed
https://issues.apache.org/jira/browse/CAMEL-14591
But I am on top of
Thanks Andrea. I will start the release process towards the end of the day.
On Wed, Feb 19, 2020 at 8:46 AM Andrea Cosentino wrote:
>
> I disabled the integration tests by default on both restdsl-openapi-plugin
> and restdsl-swagger-plugin
>
> Locally they're passing for me.
>
> Gregor can you
I disabled the integration tests by default on both restdsl-openapi-plugin
and restdsl-swagger-plugin
Locally they're passing for me.
Gregor can you restart the RC when you've time?
Thanks.
Il giorno mar 18 feb 2020 alle ore 21:24 Andrea Cosentino
ha scritto:
> To me they must disabled by
We are going through attempts :-)
Il mar 18 feb 2020, 21:28 Pascal Schumacher ha
scritto:
> Normally I would not have done the update with an release in progress,
> but as the Groovy 3.0.0 was missing JKD9 classes (see:
>
>
Normally I would not have done the update with an release in progress,
but as the Groovy 3.0.0 was missing JKD9 classes (see:
https://mail-archives.apache.org/mod_mbox/groovy-dev/202002.mbox/%3CCAMbkE7RY7cRKD1HgwymRT1peV1YPD_9fO5DZt6%3DCfQT%2Bj-Ns6Q%40mail.gmail.com%3E)
and 3.0.1 contains only
To me they must disabled by default. Locally I have them passing
Can you try disabling them?
Il mar 18 feb 2020, 21:04 Gregor Zurowski ha
scritto:
> Unfortunately I am getting the same errors with a clean .m2 repository.
>
> On Tue, Feb 18, 2020 at 8:49 PM Gregor Zurowski
> wrote:
> >
> > I
Unfortunately I am getting the same errors with a clean .m2 repository.
On Tue, Feb 18, 2020 at 8:49 PM Gregor Zurowski
wrote:
>
> I will start a new build with a completely empty .m2 repo. Hope this will
> work.
>
> On Tue, Feb 18, 2020 at 8:23 PM Andrea Cosentino wrote:
> >
> > There is also
I will start a new build with a completely empty .m2 repo. Hope this will work.
On Tue, Feb 18, 2020 at 8:23 PM Andrea Cosentino wrote:
>
> There is also a groovy update today btw. Can you check with version 3.0.0?
>
> Il mar 18 feb 2020, 19:13 Andrea Cosentino ha scritto:
>
> > Zoran could you
Hi Andrea,
the log file contains the following errors:
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 4.554 s
[INFO] Finished at:
There is also a groovy update today btw. Can you check with version 3.0.0?
Il mar 18 feb 2020, 19:13 Andrea Cosentino ha scritto:
> Zoran could you have a look to the it tests please?
>
> Il mar 18 feb 2020, 19:12 Andrea Cosentino ha scritto:
>
>> Can you check in Target/it/test_name/build.log
Zoran could you have a look to the it tests please?
Il mar 18 feb 2020, 19:12 Andrea Cosentino ha scritto:
> Can you check in Target/it/test_name/build.log ?
>
> There should be the errors related to The failing tests.
>
> For me they are passing after removing that dep
>
> Il mar 18 feb 2020,
Can you check in Target/it/test_name/build.log ?
There should be the errors related to The failing tests.
For me they are passing after removing that dep
Il mar 18 feb 2020, 19:03 Gregor Zurowski ha
scritto:
> Hi Andrea,
>
> I don't have any commonmark artifacts in my local repository, but I
Hi Andrea,
I don't have any commonmark artifacts in my local repository, but I
also see a different error (now with debug output):
[INFO] Building: customized-v3/pom.xml
[DEBUG] Build log initialized in:
All should be fine now. Gregor, let me know if the workaround related to
commonmark jar works for you.
Thanks.
Il giorno mar 18 feb 2020 alle ore 14:47 Andrea Cosentino
ha scritto:
> For the restdsl-openapi-plugin my suggestion should work, just download
> again that commomark stuff..
>
> Il
For the restdsl-openapi-plugin my suggestion should work, just download
again that commomark stuff..
Il giorno mar 18 feb 2020 alle ore 14:46 Claus Ibsen
ha scritto:
> Hi Gregor
>
> Just to let you know that we are working on fixing all of this, and
> that we have done that, but running a full
oscerd@ghost:~/workspace/apache-camel/camel/tooling/maven/camel-restdsl-openapi-plugin$
mvn clean install
[INFO] BuildTimeEventSpy is registered.
[INFO] Scanning for projects...
[INFO]
[INFO] ---< org.apache.camel:camel-restdsl-openapi-plugin
>
[INFO] Building Camel :: Maven
Gregor, if you're hitting the same error, can you try to remove the
commonmark artifacts from your local repository?
Downloading the jar again make the tests pass for me. Maybe have a
corrupted version like me?
Il giorno mar 18 feb 2020 alle ore 12:38 Andrea Cosentino
ha scritto:
> It seems
It seems there is a missing class during the integration test
Exception in thread "main" java.util.ServiceConfigurationError:
io.swagger.codegen.v3.CodegenConfig: Provider
io.swagger.codegen.v3.generators.html.StaticHtmlCodegen could not be
instantiated
at
I still don't get why these integration tests are enabled by default..
Il giorno mar 18 feb 2020 alle ore 12:01 Gregor Zurowski <
gre...@list.zurowski.org> ha scritto:
> I started the dry run an hour ago and ran into an issue with the
> camel-restdsl-openapi-plugin module:
>
> [INFO] [INFO]
>
I started the dry run an hour ago and ran into an issue with the
camel-restdsl-openapi-plugin module:
[INFO] [INFO]
[INFO] [INFO] --- maven-invoker-plugin:3.1.0:integration-test
(integration-test) @ camel-restdsl-openapi-plugin ---
[INFO] [INFO] Building: customized-v3/pom.xml
[INFO] [INFO] run
Hi
@Gregor the bug has been fixed and pushed to master branch.
On Tue, Feb 18, 2020 at 10:21 AM Gregor Zurowski
wrote:
>
> @Guillaume: I confirm that your fix is working, thanks a lot for it.
>
> @Claus: I plan to start the release process later today. Just let me
> know once you've addressed
@Guillaume: I confirm that your fix is working, thanks a lot for it.
@Claus: I plan to start the release process later today. Just let me
know once you've addressed the bug.
Thanks,
Gregor
On Tue, Feb 18, 2020 at 10:13 AM Claus Ibsen wrote:
>
> Hi
>
> There is a potential bug I would like to
Hi
There is a potential bug I would like to investigate and get fixed for
3.1, so hold the release until further notice.
Of course you can test gnodets fixed in the meantime
https://issues.apache.org/jira/browse/CAMEL-14586
On Tue, Feb 18, 2020 at 8:26 AM Gregor Zurowski
wrote:
>
> Hi
Hi Guillaume,
Thanks for your fix, I will try it again in a bit and provide an update.
Thanks again,
Gregor
On Tue, Feb 18, 2020, 7:27 AM Guillaume Nodet wrote:
> Would you please try again ? I've pushed a change which will hopefully fix
> the problem.
>
> Le lun. 17 févr. 2020 à 21:14,
Would you please try again ? I've pushed a change which will hopefully fix
the problem.
Le lun. 17 févr. 2020 à 21:14, Gregor Zurowski a
écrit :
> You can reproduce the problem by simply running the following (dry
> run) command on the current master branch: "./mvnw release:prepare
> -DdryRun
You can reproduce the problem by simply running the following (dry
run) command on the current master branch: "./mvnw release:prepare
-DdryRun -Prelease"
On Mon, Feb 17, 2020 at 9:12 PM Gregor Zurowski
wrote:
>
> I agree, but I received that message when building version 3.1.0:
>
> [INFO]
I agree, but I received that message when building version 3.1.0:
[INFO] [INFO]
[INFO] [INFO] BUILD FAILURE
[INFO] [INFO]
[INFO] [INFO] Total time:
It should be the version you're releasing because is part of the 3.1 release
Il lun 17 feb 2020, 21:04 Andrea Cosentino ha scritto:
> It shouldn't be 3.0.1
>
> Il lun 17 feb 2020, 21:00 Gregor Zurowski ha
> scritto:
>
>> I've managed to work around the described problem regarding
>>
It shouldn't be 3.0.1
Il lun 17 feb 2020, 21:00 Gregor Zurowski ha
scritto:
> I've managed to work around the described problem regarding
> camel-bundle-plugin by removing all explicit "" tags, but now
> getting other problems:
>
> ===
> [INFO] [ERROR] Failed to parse plugin descriptor for
>
I've managed to work around the described problem regarding
camel-bundle-plugin by removing all explicit "" tags, but now
getting other problems:
===
[INFO] [ERROR] Failed to parse plugin descriptor for
org.apache.camel:camel-bundle-plugin:3.0.1
I am still working on it, and I believe I have found something to fix
it. I'll post an update shortly.
On Mon, Feb 17, 2020 at 7:39 PM Andrea Cosentino
wrote:
>
> Were you able to workaround it for the moment?
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC
On Mon, Feb 17, 2020 at 7:34 PM Gregor Zurowski
wrote:
>
> Yes, that's why I am not sure why the release plugin fails on it. I
> believe this worked without issues before the refactoring for
> CAMEL-1 that added the version tags explicitly to every occurrence
> where the camel-bundle-plugin
Were you able to workaround it for the moment?
--
Andrea Cosentino
--
Apache Camel PMC Chair
Apache Karaf Committer
Apache Servicemix PMC Member
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd
On Monday, February 17, 2020, 07:34:55 PM GMT+1,
Yes, that's why I am not sure why the release plugin fails on it. I
believe this worked without issues before the refactoring for
CAMEL-1 that added the version tags explicitly to every occurrence
where the camel-bundle-plugin is used.
On Mon, Feb 17, 2020 at 7:06 PM Andrea Cosentino wrote:
If you run help:effective-pom the version seems to be correct for it
3.1.0-SNAPSHOT
Il giorno lun 17 feb 2020 alle ore 17:42 Gregor Zurowski <
gre...@list.zurowski.org> ha scritto:
> Hi Claus,
>
> There's an assignment in the parent/pom.xml already:
>
>
> ${project.version}
>
> (see
Hi Claus,
There's an assignment in the parent/pom.xml already:
${project.version}
(see https://github.com/apache/camel/blob/master/parent/pom.xml#L37)
I am wondering why that isn't sufficient.
Thanks,
Gregor
On Mon, Feb 17, 2020 at 5:35 PM Claus Ibsen wrote:
>
> Hi Gregor
>
> Thanks for
Hi Gregor
Thanks for starting the release.
Yeah doing a git grep on that placeholders shows that its never
assigned a version.
Since the plugin is part of the release, then it can maybe just be
${project.version} instead.
On Mon, Feb 17, 2020 at 5:25 PM Gregor Zurowski
wrote:
>
> Hi Everyone:
Hi
Okay it should all be done now. The last bits at pushed and the code
base is ready for the release.
The RAT plugin has been run and fixed license issues and also CS
should be fixed.
On Sun, Feb 16, 2020 at 2:28 PM Claus Ibsen wrote:
>
> Hi
>
> I am still working, running final set of tests
Hi
I am still working, running final set of tests before pushing.
There were just a few too good optimizations in core type converter
that I couldn't let go without.
On Sun, Feb 16, 2020 at 10:28 AM Gregor Zurowski
wrote:
>
> Thanks for the heads-up.
>
> On Sun, Feb 16, 2020, 10:02 AM Claus
Thanks for the heads-up.
On Sun, Feb 16, 2020, 10:02 AM Claus Ibsen wrote:
> Hi
>
> There are a few things I am working on. I will let you know later
> today when its done and the code base should be ready for cutting the
> 3.1.0 release.
>
> On Sat, Feb 15, 2020 at 8:22 PM Andrea Cosentino
>
Hi
There are a few things I am working on. I will let you know later
today when its done and the code base should be ready for cutting the
3.1.0 release.
On Sat, Feb 15, 2020 at 8:22 PM Andrea Cosentino wrote:
>
> If we want to cut 3.1.0 I'm fine with it I can add the other aws2
> components
If we want to cut 3.1.0 I'm fine with it I can add the other aws2
components later
Il sab 15 feb 2020, 20:14 Andrea Cosentino ha scritto:
> So we want an RC right? So we are doing rc1? Or do we want a final
> release? I still have to finish the aws2 components
>
> Il sab 15 feb 2020, 19:42
So we want an RC right? So we are doing rc1? Or do we want a final release?
I still have to finish the aws2 components
Il sab 15 feb 2020, 19:42 Claus Ibsen ha scritto:
> Hi
>
> I actually think its fine with 3.1.0 release (eg GA) and not a RC1 RC2
> etc which we did for 3.0.
> After 3.1.0 we
Hi
I actually think its fine with 3.1.0 release (eg GA) and not a RC1 RC2
etc which we did for 3.0.
After 3.1.0 we can do a final 3.0.2 patch release and encourage users
to upgrade to 3.1.0.
And then we can work on 3.2 and get it released within a couple of
months or so, eg to get innovation out
I didn't read RC.. I'm getting old
Inviato da Yahoo Mail su Android
Il sab, 15 feb, 2020 alle 18:02, Andrea Cosentino ha
scritto: Ah yeah, an RC is super fine. I thought about the final release of
3.1.
Sorry, I misunderstood
Il sab 15 feb 2020, 17:50 Claus Ibsen ha scritto:
> Hi
>
>
Ah yeah, an RC is super fine. I thought about the final release of 3.1.
Sorry, I misunderstood
Il sab 15 feb 2020, 17:50 Claus Ibsen ha scritto:
> Hi
>
> Oh sorry I think its actually better to get an RC cut this weekend.
> The code is ready as-is.
> Even though I found a little optimization I
Hi
Oh sorry I think its actually better to get an RC cut this weekend.
The code is ready as-is.
Even though I found a little optimization I am currently working on.
There are end users whom want 3.1 now as 3.0 is "using too much object
allocations".
Gregor so if you can find time then let us
Hello Gregor,
There is still some work pending.
Probably torwards the end of February.
Thanks for your time
Il sab 15 feb 2020, 17:26 Gregor Zurowski ha
scritto:
> Absolutely, should we cut an RC this weekend already?
>
> On Fri, Feb 14, 2020, 6:53 PM Claus Ibsen wrote:
>
> > Hi
> >
> >
Absolutely, should we cut an RC this weekend already?
On Fri, Feb 14, 2020, 6:53 PM Claus Ibsen wrote:
> Hi
>
> The OSGi blueprint issue has been fixed, it works now again for both
> JDK8 and 11 on Karaf.
>
> Gregor if you are listening, then can you let us know if you have time
> in the
Hi
The OSGi blueprint issue has been fixed, it works now again for both
JDK8 and 11 on Karaf.
Gregor if you are listening, then can you let us know if you have time
in the foreseeable future to built the release?
On Fri, Feb 14, 2020 at 1:09 PM Claus Ibsen wrote:
>
> Hi
>
> Okay so things are
Hi
Okay so things are going well.
The examples has been migrated.
Spring Boot documentation is now online on the website. And the auto
configuration options is included in the component doc of those whom
support SB (see bottom).
Camel Kafka Connector doc is now also online.
There is one issue
Hi
Oh we have even more awesome progress now.
All the work with reflection vs source code generated configurers has bene done.
And also on the model with the property placeholders. Thats a great
win as we avoid loading 200 classes and have about 90kb map object
instance in memory (biggest object
On Tue, Feb 11, 2020 at 1:02 PM Omar Al-Safi wrote:
>
> Sure, we can do that.
> However, I was thinking would it make sense in the long run to combine all
> examples in one repo? What I mean examples for camel-spring, camel-quarkus,
> camel-k and camel-kafka-connect? then we can change the
Sure, we can do that.
However, I was thinking would it make sense in the long run to combine all
examples in one repo? What I mean examples for camel-spring, camel-quarkus,
camel-k and camel-kafka-connect? then we can change the structure of repo
a bit to have submodules for each project example.
On Tue, Feb 11, 2020 at 12:49 PM Omar Al-Safi wrote:
>
> Hello folks,
>
> Short update on the camel-examples. So now we have the repo for the
> camel-examples setup and compiled, also a basic github workflow is being
> added to build the project.
> However, the only missing piece, is to generate
Hello folks,
Short update on the camel-examples. So now we have the repo for the
camel-examples setup and compiled, also a basic github workflow is being
added to build the project.
However, the only missing piece, is to generate the docs for the examples
from the new repo instead of the current
On Tue, Feb 11, 2020 at 9:49 AM Zoran Regvart wrote:
>
> Hi Cameleers,
> I'll have a look at the docs + website today and see how far do I go.
>
> On Mon, Feb 10, 2020 at 2:15 PM Claus Ibsen wrote:
> > a) Add docs to camel-spring-boot with the docs website, ala spring
> > quarkus. Zoran can you
Hi Cameleers,
I'll have a look at the docs + website today and see how far do I go.
On Mon, Feb 10, 2020 at 2:15 PM Claus Ibsen wrote:
> a) Add docs to camel-spring-boot with the docs website, ala spring
> quarkus. Zoran can you help with this?
Yup, it's on my todo for today as well as the
On Mon, Feb 10, 2020 at 10:19 AM Claus Ibsen wrote:
>
> Hi
>
> We have had great progress on Camel 3.1 and are missing a few things left
>
> 1)
> Finish the separation of camel-spring-boot (there are some tools that
> update docs and generate component list) that needs to be completed.
>
> I will
Le lun. 10 févr. 2020 à 10:19, Claus Ibsen a écrit :
> Hi
>
> We have had great progress on Camel 3.1 and are missing a few things left
>
> 1)
> Finish the separation of camel-spring-boot (there are some tools that
> update docs and generate component list) that needs to be completed.
>
> I will
On Mon, Feb 10, 2020 at 11:09 AM Omar Al-Safi wrote:
>
> I can help on moving the camel-examples, of course if no one is working on
> it currently
Yeah sure that would be good. The git repo has been setup and there is
a basic readme file.
I think the examples can be moved under examples so they
I can help on moving the camel-examples, of course if no one is working on
it currently
On Mon, Feb 10, 2020 at 10:19 AM Claus Ibsen wrote:
> Hi
>
> We have had great progress on Camel 3.1 and are missing a few things left
>
> 1)
> Finish the separation of camel-spring-boot (there are some
In the meantime I'm trying to set up a github action which build camel master
and run a build of camel-spring-boot, if there is new stuff, it will open a PR.
It's still work in progress
--
Andrea Cosentino
--
Apache Camel PMC Chair
Apache Karaf Committer
Apache
Hi
We have had great progress on Camel 3.1 and are missing a few things left
1)
Finish the separation of camel-spring-boot (there are some tools that
update docs and generate component list) that needs to be completed.
I will work on making something similar to what we do with camel-quarkus.
Apache's documentation states that "Votes should generally be
permitted to run for at least 72 hours [...]" in [1] and "Release
votes SHOULD remain open for at least 72 hours." in [2]. It seems like
a general recommendation, but not a MUST. Therefore I believe we could
agree on a shorter time
---
Luca Burgazzoli
On Sun, Feb 2, 2020 at 6:33 PM Claus Ibsen wrote:
> Hi
>
> Yeah I would like to be able to more quickly cut a RC or Milestone
> release of an upcoming release.
>
> But it's the 72h voting delay that annoys me the most. We should check
> up on ASF policy if there can be
The effort to do a release now that we split between core and spring boot is
much more and we need more time.
--
Andrea Cosentino
--
Apache Camel PMC Chair
Apache Karaf Committer
Apache Servicemix PMC Member
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github:
The only problem I see is timing.
Il giorno dom 2 feb 2020 alle ore 18:33 Claus Ibsen
ha scritto:
> Hi
>
> Yeah I would like to be able to more quickly cut a RC or Milestone
> release of an upcoming release.
>
> But it's the 72h voting delay that annoys me the most. We should check
> up on ASF
Hi
Yeah I would like to be able to more quickly cut a RC or Milestone
release of an upcoming release.
But it's the 72h voting delay that annoys me the most. We should check
up on ASF policy if there can be quicker releases for example for
milestone releases or something like that.
And on top of
hey, what about having a 3.1 RCx in any case even if we have some open
issues ?
given the amount of changes we have in 3.1, having an RC could help
sub-projects like camel-quarkus and camel-k to start adapting
---
Luca Burgazzoli
On Thu, Jan 30, 2020 at 2:14 PM Claus Ibsen wrote:
> Hi
>
> We
Hi
We also have to look ad fix
JDK 11 compiling error and test errors that may be there
OSGi blueprint issue (Andrea created a JIRA)
On Mon, Jan 27, 2020 at 11:18 AM Claus Ibsen wrote:
>
> Hi
>
> I just wanted to start the process of getting closer to Camel 3.1 release.
> Despite 3.0 was
On Tue, Jan 28, 2020 at 7:58 AM Guillaume Nodet wrote:
>
> Le lun. 27 janv. 2020 à 11:19, Claus Ibsen a écrit :
>
> > Hi
> >
> > I just wanted to start the process of getting closer to Camel 3.1 release.
> > Despite 3.0 was released only a while back, then we have made great
> > progress on 3.1
On Mon, Jan 27, 2020 at 7:29 PM Andrea Cosentino wrote:
> By the way, I believe it is a good chance, to move the examples out of the
> main repository.
>
+1
>
> Il giorno lun 27 gen 2020 alle ore 11:28 Omar Al-Safi
> ha
> scritto:
>
> > +1
> >
> > I am working actively on the (3) the
Hi Guillaume,
If you mean about moving move all generated code this JIRA (
https://issues.apache.org/jira/browse/CAMEL-14448), the question is this
crucial has to be done soon? If not, I would say at least delay on it until
we have the componentdsl stable enough to be merged into master.
Le lun. 27 janv. 2020 à 11:19, Claus Ibsen a écrit :
> Hi
>
> I just wanted to start the process of getting closer to Camel 3.1 release.
> Despite 3.0 was released only a while back, then we have made great
> progress on 3.1 that is important to get in the hands of the Camel
> users. And for
On Mon, Jan 27, 2020 at 11:29 AM Andrea Cosentino wrote:
>
> By the way, I believe it is a good chance, to move the examples out of the
> main repository.
>
Yeah that is a good point. We have talked about this before. Lets see
if we can find the time to do this too.
> Il giorno lun 27 gen 2020
Working on some minor improvement for camel-main required for camel-k,
should be ready by this week
---
Luca Burgazzoli
On Mon, Jan 27, 2020 at 2:35 PM Jean-Baptiste Onofré
wrote:
> +1
>
> I still have my Karaf improvements local branch for Camel 3.x. But not a
> blocker for 3.1 release.
>
>
+1
I still have my Karaf improvements local branch for Camel 3.x. But not a
blocker for 3.1 release.
Regards
JB
On 27/01/2020 11:18, Claus Ibsen wrote:
> Hi
>
> I just wanted to start the process of getting closer to Camel 3.1 release.
> Despite 3.0 was released only a while back, then we have
By the way, I believe it is a good chance, to move the examples out of the
main repository.
Il giorno lun 27 gen 2020 alle ore 11:28 Omar Al-Safi ha
scritto:
> +1
>
> I am working actively on the (3) the component DSL, hopefully would be done
> this week or next week, so I guess should be on
+1
I am working actively on the (3) the component DSL, hopefully would be done
this week or next week, so I guess should be on track for 3.1.
Also I hope I can push some bug fixes for camel-debezium once done from the
fluent builder
Regards,
Omar
On Mon, Jan 27, 2020 at 11:22 AM Andrea
+1,
I'm working on AWS SDK2 components.
Il giorno lun 27 gen 2020 alle ore 11:19 Claus Ibsen
ha scritto:
> Hi
>
> I just wanted to start the process of getting closer to Camel 3.1 release.
> Despite 3.0 was released only a while back, then we have made great
> progress on 3.1 that is important
Hi
I just wanted to start the process of getting closer to Camel 3.1 release.
Despite 3.0 was released only a while back, then we have made great
progress on 3.1 that is important to get in the hands of the Camel
users. And for Camel users that migrate to 3.x can then skip 3.0 and
go straight to
93 matches
Mail list logo
