Joshua St. Clair Il y a 6 années Great blog David! Thank you for clarifying that! This was always a confusing topic for me whenever I specified my module versions. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler David H Nebinger Joshua St. Clair Il y a 6 années I struggled with it too. I'm hoping, though, that this blog will help you and others avoid the same struggle Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
David H Nebinger Joshua St. Clair Il y a 6 années I struggled with it too. I'm hoping, though, that this blog will help you and others avoid the same struggle Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
sunny huang Il y a 6 années Great gob.It seems that many people have encountered this problem.You solved my problem in this post(https://web.liferay.com/zh/community/forums/-/message_boards/message/102513997).This blog explains better. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Joye Luo Il y a 6 années That's really extremely helpful. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Dominik Marks Il y a 6 années I totally agree with you David. It should be enough to compile against the "oldest" version you would like to support. In terms of semantic versioning a minor version should not have any breaking changes, so it should not matter if you compile against an older version that the one currently running in your Liferay environment.However when it comes to debugging, it is very useful to know the exact version of a module currently running in your Liferay development server. IMO it is very annoying when stepping through the code (of a dependency) and the line numbers do not match. In those cases I set the exact version number in my maven/gradle dependencies temporarily (determined by using the Gogo Shell). Veuillez vous identifier pour voter. Répondre en tant que ... Annuler David H Nebinger Dominik Marks Il y a 6 années - Edité So while your position is true and valid, it also happens to be moot.For development, you just need to ensure you support the version range of dependencies in the container you're deploying to.For debugging, you are also concerned somewhat about version, but because Liferay does not distribute individual modules separately, we don't have to worry about it. If you are using CE GA 2, then you use the source for CE GA 2 to debug against; when you change to CE GA 5, you change your source also.Same goes for DXP; if you are on fixpack 27, you use the source for FP27 (also available in the downloads). When you update to FP41, you also use the source for FP41.We can keep things simple like this until the day comes (if it comes) that individual modules are distributed separately. At that point things can definitely get weird if we all have some hodgepodge of bundle versions floating around in the container.If that day comes, I think my personal recommendation would be to avoid it. Stick with Liferay GAs or Service Packs or whatever they want to call them, but avoid separate module updates as it will likely be too confusing to manage those containers. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
David H Nebinger Dominik Marks Il y a 6 années - Edité So while your position is true and valid, it also happens to be moot.For development, you just need to ensure you support the version range of dependencies in the container you're deploying to.For debugging, you are also concerned somewhat about version, but because Liferay does not distribute individual modules separately, we don't have to worry about it. If you are using CE GA 2, then you use the source for CE GA 2 to debug against; when you change to CE GA 5, you change your source also.Same goes for DXP; if you are on fixpack 27, you use the source for FP27 (also available in the downloads). When you update to FP41, you also use the source for FP41.We can keep things simple like this until the day comes (if it comes) that individual modules are distributed separately. At that point things can definitely get weird if we all have some hodgepodge of bundle versions floating around in the container.If that day comes, I think my personal recommendation would be to avoid it. Stick with Liferay GAs or Service Packs or whatever they want to call them, but avoid separate module updates as it will likely be too confusing to manage those containers. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
David Weitzel Il y a 6 années Another great BLog David. I ran against this compile issue when using the MailMessage interface needing to set headrers that was added somewhere between portal.kernal 2.0.0 and 2.35.0 currently it is at 2.63.0 or somewhere.the explanation between runtime and compile time decisions is useful.What would be very useful though is a table/page/service that would let you find out which versions were in each FP or at least each SP (for DXP). It seems the standard new module routines assume 2.0.0 which is rather old. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler David H Nebinger David Weitzel Il y a 6 années I don't know that such a table exists, but I wonder how useful it would be. I mean, if you are looking for a specific API method, you need to know when the method was introduced in the interface and then back track that to the bundle version of its introduction.The only thing I've found that works is to pick a valid version number and then start decrementing until I get to a point where a clean compile breaks; it is super tedious, so I'll typically find some sort of version number that it works and call it the day. Like in your case, I'd go with 2.35.0 and be happy with it.The "new module routines assume 2.0.0 which is rather old", while true, is the wrong way of thinking about it, the way that we as developers want the latest version.Don't think of it as "this module uses old versions", think of it like "this module doesn't need any changes introduced since 2.0.0". Its what allows the module to be compatible with the earliest 7.0 GAs even if nobody is running GA1. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
David H Nebinger David Weitzel Il y a 6 années I don't know that such a table exists, but I wonder how useful it would be. I mean, if you are looking for a specific API method, you need to know when the method was introduced in the interface and then back track that to the bundle version of its introduction.The only thing I've found that works is to pick a valid version number and then start decrementing until I get to a point where a clean compile breaks; it is super tedious, so I'll typically find some sort of version number that it works and call it the day. Like in your case, I'd go with 2.35.0 and be happy with it.The "new module routines assume 2.0.0 which is rather old", while true, is the wrong way of thinking about it, the way that we as developers want the latest version.Don't think of it as "this module uses old versions", think of it like "this module doesn't need any changes introduced since 2.0.0". Its what allows the module to be compatible with the earliest 7.0 GAs even if nobody is running GA1. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Enrico Oliosi Il y a 5 années Hi David, - Import-Package: com.liferay.portal.kernel.dao.search;version="[2.6.0,2.13.0)" - 2.6.0 and 2.13.0 are the versions of the package included into portal-kernel.jar and NOT the versions of portal-kernel boundle. The package version of "com.liferay.portal.kernel.dao.search" into portal-kernel-2.6.0.jar is 7.2.0. In you article you talk about portal-kernel boundle version when you write 2.6.0 and 2.13.0... Veuillez vous identifier pour voter. Répondre en tant que ... Annuler David H Nebinger Enrico Oliosi Il y a 5 années Yep, my bad, kernel is a bad example because the packages version differently. The "normal" modules typically version as a whole, so in general it would work. I'll look up the package versions for 2.6.0 and 2.13.0 and update accordingly... Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
David H Nebinger Enrico Oliosi Il y a 5 années Yep, my bad, kernel is a bad example because the packages version differently. The "normal" modules typically version as a whole, so in general it would work. I'll look up the package versions for 2.6.0 and 2.13.0 and update accordingly... Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Gnaniyar Zubair Il y a 4 années Very informative . Thanks David. I was facing the issue recently for 2 different versions of portal-kernel.jar of this package "com.liferay.portal.kernel.portlet.bridges.mvc" which has different version from gradle home and server. Gradle Repository: 3.6.2 Tomcat/lib: 2.0.0 I didn't mention any version in build.gradle file and my .bnd file has: Import-Package:\ com.liferay.portal.kernel.portlet.bridges.mvc;version="[2.0.0,3.6.2)",\ * So compile time it takes 3.6.2 and run time . can we follow the same approach for all the dependency issues? Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Gnaniyar Zubair Gnaniyar Zubair Il y a 4 années By default, manifest.mf file is generating some interval range. For example, it is generating the version 1.6.0 to 2.0.0 as mentioned here. how it took this range ? "Import-Package: com.liferay.portal.kernel.portlet.bridges.mvc; version="[1.6.0,2.0.0)" Veuillez vous identifier pour voter. Répondre en tant que ... Annuler David H Nebinger Gnaniyar Zubair Il y a 4 années When you pick version 1.6.0, you are actually saying you need at least version 1.6.0 but you are okay with a higher compatible version. The tooling fills out the rest of the range. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler David H Nebinger Gnaniyar Zubair Il y a 4 années Kernel 2.x is 7.0, and 3.x is 7.1. You need to know which version you're deploying to and select the right version. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Gnaniyar Zubair Gnaniyar Zubair Il y a 4 années By default, manifest.mf file is generating some interval range. For example, it is generating the version 1.6.0 to 2.0.0 as mentioned here. how it took this range ? "Import-Package: com.liferay.portal.kernel.portlet.bridges.mvc; version="[1.6.0,2.0.0)" Veuillez vous identifier pour voter. Répondre en tant que ... Annuler David H Nebinger Gnaniyar Zubair Il y a 4 années When you pick version 1.6.0, you are actually saying you need at least version 1.6.0 but you are okay with a higher compatible version. The tooling fills out the rest of the range. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
David H Nebinger Gnaniyar Zubair Il y a 4 années When you pick version 1.6.0, you are actually saying you need at least version 1.6.0 but you are okay with a higher compatible version. The tooling fills out the rest of the range. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
David H Nebinger Gnaniyar Zubair Il y a 4 années Kernel 2.x is 7.0, and 3.x is 7.1. You need to know which version you're deploying to and select the right version. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler