Joshua St. Clair 6 Years Ago Great blog David! Thank you for clarifying that! This was always a confusing topic for me whenever I specified my module versions. Please sign in to reply. Reply as... Cancel David H Nebinger Joshua St. Clair 6 Years Ago I struggled with it too. I'm hoping, though, that this blog will help you and others avoid the same struggle Please sign in to reply. Reply as... Cancel
David H Nebinger Joshua St. Clair 6 Years Ago I struggled with it too. I'm hoping, though, that this blog will help you and others avoid the same struggle Please sign in to reply. Reply as... Cancel
sunny huang 6 Years Ago 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. Please sign in to reply. Reply as... Cancel
Dominik Marks 6 Years Ago 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). Please sign in to reply. Reply as... Cancel David H Nebinger Dominik Marks 6 Years Ago - Edited 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. Please sign in to reply. Reply as... Cancel
David H Nebinger Dominik Marks 6 Years Ago - Edited 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. Please sign in to reply. Reply as... Cancel
David Weitzel 5 Years Ago 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. Please sign in to reply. Reply as... Cancel David H Nebinger David Weitzel 5 Years Ago 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. Please sign in to reply. Reply as... Cancel
David H Nebinger David Weitzel 5 Years Ago 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. Please sign in to reply. Reply as... Cancel
Enrico Oliosi 5 Years Ago 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... Please sign in to reply. Reply as... Cancel David H Nebinger Enrico Oliosi 5 Years Ago 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... Please sign in to reply. Reply as... Cancel
David H Nebinger Enrico Oliosi 5 Years Ago 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... Please sign in to reply. Reply as... Cancel
Gnaniyar Zubair 4 Years Ago 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? Please sign in to reply. Reply as... Cancel Gnaniyar Zubair Gnaniyar Zubair 4 Years Ago 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)" Please sign in to reply. Reply as... Cancel David H Nebinger Gnaniyar Zubair 4 Years Ago 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. Please sign in to reply. Reply as... Cancel David H Nebinger Gnaniyar Zubair 4 Years Ago 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. Please sign in to reply. Reply as... Cancel
Gnaniyar Zubair Gnaniyar Zubair 4 Years Ago 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)" Please sign in to reply. Reply as... Cancel David H Nebinger Gnaniyar Zubair 4 Years Ago 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. Please sign in to reply. Reply as... Cancel
David H Nebinger Gnaniyar Zubair 4 Years Ago 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. Please sign in to reply. Reply as... Cancel
David H Nebinger Gnaniyar Zubair 4 Years Ago 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. Please sign in to reply. Reply as... Cancel