CometD 5.0.2 Released
79 views
Skip to first unread message
Simone Bordet
Oct 28, 2020, 6:10:30 AM10/28/20
to cometd-users, cometd-dev
Hi all,
CometD 5.0.2 has been released.
CometD 5.0.2 is a minor bugfix release, see here for the list of fixed issues:
https://github.com/cometd/cometd/projects/13
Note that the Jetty dependency has been updated to 9.4.33.v20201020
due to a vulnerability discovered in Jetty, so you should consider
upgrading Jetty even if you don't upgrade CometD.
Note also that the resolution of
https://github.com/cometd/cometd/issues/905 makes stricter checks on
the channel names that client applications can use.
These checks were already performed on the server side, so chances are
that you were not using illegal channel names already and therefore
your application do not need any change.
Users that are still using CometD 4.0.x are encouraged to move to CometD 5.0.x.
Follow the migration guide:
https://docs.cometd.org/current5/reference/#_migration_40_to_50.
As a minor update, I have also released in the past days CometD 4.0.9.
This is a release that was made for CometD customers that have
commercial support (see
https://docs.cometd.org/current/reference/#_support), but is
available to anyone.
However, these releases are quite ad-hoc, i.e. they don't incorporate
all fixes and improvements that the 5.0.x line has. As such, you are
suggested to upgrade to 5.0.x as soon as possible.
Enjoy!
--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
CometD 5.0.2 has been released.
CometD 5.0.2 is a minor bugfix release, see here for the list of fixed issues:
https://github.com/cometd/cometd/projects/13
Note that the Jetty dependency has been updated to 9.4.33.v20201020
due to a vulnerability discovered in Jetty, so you should consider
upgrading Jetty even if you don't upgrade CometD.
Note also that the resolution of
https://github.com/cometd/cometd/issues/905 makes stricter checks on
the channel names that client applications can use.
These checks were already performed on the server side, so chances are
that you were not using illegal channel names already and therefore
your application do not need any change.
Users that are still using CometD 4.0.x are encouraged to move to CometD 5.0.x.
Follow the migration guide:
https://docs.cometd.org/current5/reference/#_migration_40_to_50.
As a minor update, I have also released in the past days CometD 4.0.9.
This is a release that was made for CometD customers that have
commercial support (see
https://docs.cometd.org/current/reference/#_support), but is
available to anyone.
However, these releases are quite ad-hoc, i.e. they don't incorporate
all fixes and improvements that the 5.0.x line has. As such, you are
suggested to upgrade to 5.0.x as soon as possible.
Enjoy!
--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
rijkr
Nov 27, 2020, 4:36:27 AM11/27/20
to cometd-users
I migrated from version 4.0.9 to 5.0.2 of <artifactId>cometd-java-server</artifactId> <type>pom</type> as dependency in my pom.xml, but this does not trigger the inclusion of dependent modules. As a workaround I explicitly added the modules as dependency, i.e: cometd-java-server-common, cometd-java-server-websocket-common, cometd-java-server-websocket-javax and cometd-java-server-websocket-jetty. Am I missing something?
-- Rijk
-- Rijk
Op woensdag 28 oktober 2020 om 11:10:30 UTC+1 schreef Simone Bordet:
Simone Bordet
Nov 27, 2020, 4:55:48 AM11/27/20
to cometd-users
Hi,
On Fri, Nov 27, 2020 at 10:36 AM rijkr <ri...@datraverse.nl> wrote:
>
> I migrated from version 4.0.9 to 5.0.2 of <artifactId>cometd-java-server</artifactId> <type>pom</type> as dependency in my pom.xml,
That's a bit weird to depend on a type=pom, is there a particular
reason you do that?
How exactly do you depend on it?
> but this does not trigger the inclusion of dependent modules. As a workaround I explicitly added the modules as dependency, i.e: cometd-java-server-common, cometd-java-server-websocket-common, cometd-java-server-websocket-javax and cometd-java-server-websocket-jetty.
That's better I guess.
> Am I missing something?
Did you upgrade Maven as well?
On Fri, Nov 27, 2020 at 10:36 AM rijkr <ri...@datraverse.nl> wrote:
>
> I migrated from version 4.0.9 to 5.0.2 of <artifactId>cometd-java-server</artifactId> <type>pom</type> as dependency in my pom.xml,
reason you do that?
How exactly do you depend on it?
> but this does not trigger the inclusion of dependent modules. As a workaround I explicitly added the modules as dependency, i.e: cometd-java-server-common, cometd-java-server-websocket-common, cometd-java-server-websocket-javax and cometd-java-server-websocket-jetty.
> Am I missing something?
Did you upgrade Maven as well?
rijkr
Nov 30, 2020, 4:22:22 AM11/30/20
to cometd-users
Hi Simone,
I use Eclipse IDE and tried ...
Eclipse 2019-03 (4.11.0) : Embedded Maven: 3.5.3/1.11.0.20190220-2117
Eclipse 2020-06 (4.16.0) : Embedded Maven: 3.6.3/1.16.0.20200610-1735
"Note: Embedded runtime is always used for dependency resolution"
I use Eclipse IDE and tried ...
Eclipse 2019-03 (4.11.0) : Embedded Maven: 3.5.3/1.11.0.20190220-2117
Eclipse 2020-06 (4.16.0) : Embedded Maven: 3.6.3/1.16.0.20200610-1735
"Note: Embedded runtime is always used for dependency resolution"
In both cases, without the <type>pom</type>, the pom.xml container is invalid ("Missing artifact org.cometd.java:cometd-java-server:jar:5.0.2").
--
Rijk Ravestein
Op vrijdag 27 november 2020 om 10:55:48 UTC+1 schreef Simone Bordet:
Simone Bordet
Dec 3, 2020, 10:11:25 AM12/3/20
to cometd-users
Hi,
On Mon, Nov 30, 2020 at 10:22 AM rijkr <ri...@datraverse.nl> wrote:
>
> Hi Simone,
>
> I use Eclipse IDE and tried ...
>
> Eclipse 2019-03 (4.11.0) : Embedded Maven: 3.5.3/1.11.0.20190220-2117
> Eclipse 2020-06 (4.16.0) : Embedded Maven: 3.6.3/1.16.0.20200610-1735
>
> "Note: Embedded runtime is always used for dependency resolution"
>
> In both cases, without the <type>pom</type>, the pom.xml container is invalid ("Missing artifact org.cometd.java:cometd-java-server:jar:5.0.2").
I'm not familiar with Eclipse IDE so I cannot really help.
The artifact is there, it's valid and it should work when using Maven
from the command line.
If it does, then it's an Eclipse IDE issue.
On Mon, Nov 30, 2020 at 10:22 AM rijkr <ri...@datraverse.nl> wrote:
>
> Hi Simone,
>
> I use Eclipse IDE and tried ...
>
> Eclipse 2019-03 (4.11.0) : Embedded Maven: 3.5.3/1.11.0.20190220-2117
> Eclipse 2020-06 (4.16.0) : Embedded Maven: 3.6.3/1.16.0.20200610-1735
>
> "Note: Embedded runtime is always used for dependency resolution"
>
> In both cases, without the <type>pom</type>, the pom.xml container is invalid ("Missing artifact org.cometd.java:cometd-java-server:jar:5.0.2").
The artifact is there, it's valid and it should work when using Maven
from the command line.
If it does, then it's an Eclipse IDE issue.
rijkr
Dec 4, 2020, 7:29:26 AM12/4/20
to cometd-users
Hi Simone,
To get away from Eclipse IDE, I created a simple Maven project as explained in https://maven.apache.org/guides/getting-started/maven-in-five-minutes.html .
As suggested by https://mvnrepository.com/artifact/org.cometd.java/cometd-java-server/5.0.2 , I added this dependency to the pom.xml :
<dependency>
<groupId>org.cometd.java</groupId>
<artifactId>cometd-java-server</artifactId>
<version>5.0.2</version>
<type>pom</type>
</dependency>
When executing 'mvn package' on the command line (using latest maven 3.6.3) just this message is shown ...
Downloading from central: https://repo.maven.apache.org/maven2/org/cometd/java/cometd-java-server/5.0.2/cometd-java-server-5.0.2.pom
Inspection of subdirectories of '~/.m2/repository/~/.m2/repository/org/cometd/javaorg/cometd/java' confirms that 'cometd-java-server-5.0.2.pom' is present, but I can't find anything for the 'cometd-java-server-common' and 'cometd-java-server-websocket' modules.
As suggested by https://mvnrepository.com/artifact/org.cometd.java/cometd-java-server/5.0.2 , I added this dependency to the pom.xml :
<dependency>
<groupId>org.cometd.java</groupId>
<artifactId>cometd-java-server</artifactId>
<version>5.0.2</version>
<type>pom</type>
</dependency>
When executing 'mvn package' on the command line (using latest maven 3.6.3) just this message is shown ...
Downloading from central: https://repo.maven.apache.org/maven2/org/cometd/java/cometd-java-server/5.0.2/cometd-java-server-5.0.2.pom
Inspection of subdirectories of '~/.m2/repository/~/.m2/repository/org/cometd/javaorg/cometd/java' confirms that 'cometd-java-server-5.0.2.pom' is present, but I can't find anything for the 'cometd-java-server-common' and 'cometd-java-server-websocket' modules.
Op donderdag 3 december 2020 om 16:11:25 UTC+1 schreef Simone Bordet:
Simone Bordet
Dec 4, 2020, 8:58:44 AM12/4/20
to cometd-users
Hi,
If you need the `cometd-java-server` you just depend on it with
type=jar and the transitive dependencies will be pulled consequently.
Why do you want type=pom?
> To get away from Eclipse IDE, I created a simple Maven project as explained in https://maven.apache.org/guides/getting-started/maven-in-five-minutes.html .
>
> As suggested by https://mvnrepository.com/artifact/org.cometd.java/cometd-java-server/5.0.2 , I added this dependency to the pom.xml :
>
> <dependency>
> <groupId>org.cometd.java</groupId>
> <artifactId>cometd-java-server</artifactId>
> <version>5.0.2</version>
> <type>pom</type>
> </dependency>
>
> When executing 'mvn package' on the command line (using latest maven 3.6.3) just this message is shown ...
>
> Downloading from central: https://repo.maven.apache.org/maven2/org/cometd/java/cometd-java-server/5.0.2/cometd-java-server-5.0.2.pom
>
> Inspection of subdirectories of '~/.m2/repository/~/.m2/repository/org/cometd/javaorg/cometd/java' confirms that 'cometd-java-server-5.0.2.pom' is present, but I can't find anything for the 'cometd-java-server-common' and 'cometd-java-server-websocket' modules.
I frankly don't understand what you're trying to do.
>
> As suggested by https://mvnrepository.com/artifact/org.cometd.java/cometd-java-server/5.0.2 , I added this dependency to the pom.xml :
>
> <dependency>
> <groupId>org.cometd.java</groupId>
> <artifactId>cometd-java-server</artifactId>
> <version>5.0.2</version>
> <type>pom</type>
> </dependency>
>
> When executing 'mvn package' on the command line (using latest maven 3.6.3) just this message is shown ...
>
> Downloading from central: https://repo.maven.apache.org/maven2/org/cometd/java/cometd-java-server/5.0.2/cometd-java-server-5.0.2.pom
>
> Inspection of subdirectories of '~/.m2/repository/~/.m2/repository/org/cometd/javaorg/cometd/java' confirms that 'cometd-java-server-5.0.2.pom' is present, but I can't find anything for the 'cometd-java-server-common' and 'cometd-java-server-websocket' modules.
If you need the `cometd-java-server` you just depend on it with
type=jar and the transitive dependencies will be pulled consequently.
Why do you want type=pom?
rijkr
Dec 7, 2020, 5:53:26 AM12/7/20
to cometd-users
Hi Simone,
I try to isolate my problem by creating a minimal maven project with "cometd-java-server' <version>5.0.2</version> as single <dependency>. I'm sorry, but the <type>pom</type> qualification is really needed. When omitted (falling back to default 'jar'), an error occurs when executing 'mvn package':
[ERROR] Failed to execute goal on project my-app: Could not resolve dependencies for project com.mycompany.app:my-app:jar:1.0-SNAPSHOT: Could not find artifact org.cometd.java:cometd-java-server:jar:5.0.2 in central (https://repo.maven.apache.org/maven2)
When using <version>4.0.9</version> there are no errors: cometd-java-server-4.0.9.jar is downloaded and everything is fine.
So, what's the difference? Inspecting the two pom files, I see cometd-java-server-4.0.9.pom contains many <dependency> instances, while cometd-java-server-5.0.2.pom contains a couple of <module> instances instead.
I'm not a Maven expert. But it looks like dependencies and modules have different purposes. For building the "cometd-java-server' project itself, a multimodule design obviously works fine. Could it be that a third-party project, that just "uses" the 'cometd-java-server' artifact, needs a different kind of pom that only contains dependencies? See: https://stackoverflow.com/questions/35589017/maven-dependency-vs-module
I try to isolate my problem by creating a minimal maven project with "cometd-java-server' <version>5.0.2</version> as single <dependency>. I'm sorry, but the <type>pom</type> qualification is really needed. When omitted (falling back to default 'jar'), an error occurs when executing 'mvn package':
[ERROR] Failed to execute goal on project my-app: Could not resolve dependencies for project com.mycompany.app:my-app:jar:1.0-SNAPSHOT: Could not find artifact org.cometd.java:cometd-java-server:jar:5.0.2 in central (https://repo.maven.apache.org/maven2)
When using <version>4.0.9</version> there are no errors: cometd-java-server-4.0.9.jar is downloaded and everything is fine.
So, what's the difference? Inspecting the two pom files, I see cometd-java-server-4.0.9.pom contains many <dependency> instances, while cometd-java-server-5.0.2.pom contains a couple of <module> instances instead.
I'm not a Maven expert. But it looks like dependencies and modules have different purposes. For building the "cometd-java-server' project itself, a multimodule design obviously works fine. Could it be that a third-party project, that just "uses" the 'cometd-java-server' artifact, needs a different kind of pom that only contains dependencies? See: https://stackoverflow.com/questions/35589017/maven-dependency-vs-module
-- Rijk
Op vrijdag 4 december 2020 om 14:58:44 UTC+1 schreef Simone Bordet:
Simone Bordet
Dec 7, 2020, 6:03:17 AM12/7/20
to cometd-users
Hi,
Artifact `cometd-java-server:4.0.x` has been renamed to
`cometd-java-server-common:5.0.x`.
I thought I put this into the migration guide but I did not.
Don't use type=pom dependencies.
Just update your dependency artifactId to `cometd-java-server-common`.
I'll update the migration guide.
Thanks for your patience and sorry for me being so thick.
> I try to isolate my problem by creating a minimal maven project with "cometd-java-server' <version>5.0.2</version> as single <dependency>. I'm sorry, but the <type>pom</type> qualification is really needed. When omitted (falling back to default 'jar'), an error occurs when executing 'mvn package':
>
> [ERROR] Failed to execute goal on project my-app: Could not resolve dependencies for project com.mycompany.app:my-app:jar:1.0-SNAPSHOT: Could not find artifact org.cometd.java:cometd-java-server:jar:5.0.2 in central (https://repo.maven.apache.org/maven2)
>
> When using <version>4.0.9</version> there are no errors: cometd-java-server-4.0.9.jar is downloaded and everything is fine.
>
> So, what's the difference? Inspecting the two pom files, I see cometd-java-server-4.0.9.pom contains many <dependency> instances, while cometd-java-server-5.0.2.pom contains a couple of <module> instances instead.
All right, my apologies.
>
> [ERROR] Failed to execute goal on project my-app: Could not resolve dependencies for project com.mycompany.app:my-app:jar:1.0-SNAPSHOT: Could not find artifact org.cometd.java:cometd-java-server:jar:5.0.2 in central (https://repo.maven.apache.org/maven2)
>
> When using <version>4.0.9</version> there are no errors: cometd-java-server-4.0.9.jar is downloaded and everything is fine.
>
> So, what's the difference? Inspecting the two pom files, I see cometd-java-server-4.0.9.pom contains many <dependency> instances, while cometd-java-server-5.0.2.pom contains a couple of <module> instances instead.
Artifact `cometd-java-server:4.0.x` has been renamed to
`cometd-java-server-common:5.0.x`.
I thought I put this into the migration guide but I did not.
Don't use type=pom dependencies.
Just update your dependency artifactId to `cometd-java-server-common`.
I'll update the migration guide.
Thanks for your patience and sorry for me being so thick.
rijkr
Dec 8, 2020, 5:36:38 AM12/8/20
to cometd-users
Hi Simone,
Yes, 'cometd-java-server-common' did the trick. Glad the issue is solved :-)
Thanks for CometD. It's a great solution and I'm happy I had a chance to contribute in this minor way.
--
Best regards,
Rijk Ravestein, Technical Lead
https://www.savapage.org
Yes, 'cometd-java-server-common' did the trick. Glad the issue is solved :-)
Thanks for CometD. It's a great solution and I'm happy I had a chance to contribute in this minor way.
--
Best regards,
Rijk Ravestein, Technical Lead
https://www.savapage.org
Op maandag 7 december 2020 om 12:03:17 UTC+1 schreef Simone Bordet:
Reply all
Reply to author
Forward
0 new messages