Ray Augé 5 Years Ago I think you meant `compileOnly` in gradle? Please sign in to reply. Reply as... Cancel David H Nebinger Ray Augé 5 Years Ago Good catch. I keep forgetting "compile" has been deprecated. Fixed. Please sign in to reply. Reply as... Cancel Adrian Rodriguez Monedero David H Nebinger 4 Years Ago I didn't know that the compile configuration is deprecated! I could not tell any difference between compile and compileOnly until I recently tried to run some unit tests in Eclipse and the compile dependencies were being ignored. That's why I'm preferring compile over compileOnly. Is there any other reason to prefer the compileOnly configuration? Should I file a bug with my problem? Please sign in to reply. Reply as... Cancel David H Nebinger Adrian Rodriguez Monedero 4 Years Ago - Edited The Gradle doco actually states that "compile" is deprecated: https://docs.gradle.org/current/userguide/java_library_plugin.html However, generally Liferay recommends the following: * compileOnly for dependencies provided by the portal, so that's all of Liferay's modules, commons-lang2, things of that nature. * compileInclude for dependencies that you are including into your module. * compile This directive would be for dependencies provided in OSGi but for ones that you are deploying into the container. compileOnly and compile have the same effect, they will become dependencies that are part of the Import-Package in the Manifest, and OSGi will require them to be resolvable. Now these distinctions, well they tend to satisfy Liferay's needs. As an external developer, I don't see a great difference between compile and compileOnly. I tend to want to use compileOnly because I think it makes it explicit to another developer checking out my project that the dependency has to be provided by the container. I don't think it matters so much whether the dependency is satisfied by the portal or by my own deployed artifacts. But Liferay does have visions for the future related to creation of custom boms to use in conjunction with the Liferay boms, and in that future it may be necessary to make these kinds of distinctions. So using the right compile or compileOnly directive may actually serve you in the long run although there's no actual benefit today. Please sign in to reply. Reply as... Cancel
David H Nebinger Ray Augé 5 Years Ago Good catch. I keep forgetting "compile" has been deprecated. Fixed. Please sign in to reply. Reply as... Cancel Adrian Rodriguez Monedero David H Nebinger 4 Years Ago I didn't know that the compile configuration is deprecated! I could not tell any difference between compile and compileOnly until I recently tried to run some unit tests in Eclipse and the compile dependencies were being ignored. That's why I'm preferring compile over compileOnly. Is there any other reason to prefer the compileOnly configuration? Should I file a bug with my problem? Please sign in to reply. Reply as... Cancel David H Nebinger Adrian Rodriguez Monedero 4 Years Ago - Edited The Gradle doco actually states that "compile" is deprecated: https://docs.gradle.org/current/userguide/java_library_plugin.html However, generally Liferay recommends the following: * compileOnly for dependencies provided by the portal, so that's all of Liferay's modules, commons-lang2, things of that nature. * compileInclude for dependencies that you are including into your module. * compile This directive would be for dependencies provided in OSGi but for ones that you are deploying into the container. compileOnly and compile have the same effect, they will become dependencies that are part of the Import-Package in the Manifest, and OSGi will require them to be resolvable. Now these distinctions, well they tend to satisfy Liferay's needs. As an external developer, I don't see a great difference between compile and compileOnly. I tend to want to use compileOnly because I think it makes it explicit to another developer checking out my project that the dependency has to be provided by the container. I don't think it matters so much whether the dependency is satisfied by the portal or by my own deployed artifacts. But Liferay does have visions for the future related to creation of custom boms to use in conjunction with the Liferay boms, and in that future it may be necessary to make these kinds of distinctions. So using the right compile or compileOnly directive may actually serve you in the long run although there's no actual benefit today. Please sign in to reply. Reply as... Cancel
Adrian Rodriguez Monedero David H Nebinger 4 Years Ago I didn't know that the compile configuration is deprecated! I could not tell any difference between compile and compileOnly until I recently tried to run some unit tests in Eclipse and the compile dependencies were being ignored. That's why I'm preferring compile over compileOnly. Is there any other reason to prefer the compileOnly configuration? Should I file a bug with my problem? Please sign in to reply. Reply as... Cancel David H Nebinger Adrian Rodriguez Monedero 4 Years Ago - Edited The Gradle doco actually states that "compile" is deprecated: https://docs.gradle.org/current/userguide/java_library_plugin.html However, generally Liferay recommends the following: * compileOnly for dependencies provided by the portal, so that's all of Liferay's modules, commons-lang2, things of that nature. * compileInclude for dependencies that you are including into your module. * compile This directive would be for dependencies provided in OSGi but for ones that you are deploying into the container. compileOnly and compile have the same effect, they will become dependencies that are part of the Import-Package in the Manifest, and OSGi will require them to be resolvable. Now these distinctions, well they tend to satisfy Liferay's needs. As an external developer, I don't see a great difference between compile and compileOnly. I tend to want to use compileOnly because I think it makes it explicit to another developer checking out my project that the dependency has to be provided by the container. I don't think it matters so much whether the dependency is satisfied by the portal or by my own deployed artifacts. But Liferay does have visions for the future related to creation of custom boms to use in conjunction with the Liferay boms, and in that future it may be necessary to make these kinds of distinctions. So using the right compile or compileOnly directive may actually serve you in the long run although there's no actual benefit today. Please sign in to reply. Reply as... Cancel
David H Nebinger Adrian Rodriguez Monedero 4 Years Ago - Edited The Gradle doco actually states that "compile" is deprecated: https://docs.gradle.org/current/userguide/java_library_plugin.html However, generally Liferay recommends the following: * compileOnly for dependencies provided by the portal, so that's all of Liferay's modules, commons-lang2, things of that nature. * compileInclude for dependencies that you are including into your module. * compile This directive would be for dependencies provided in OSGi but for ones that you are deploying into the container. compileOnly and compile have the same effect, they will become dependencies that are part of the Import-Package in the Manifest, and OSGi will require them to be resolvable. Now these distinctions, well they tend to satisfy Liferay's needs. As an external developer, I don't see a great difference between compile and compileOnly. I tend to want to use compileOnly because I think it makes it explicit to another developer checking out my project that the dependency has to be provided by the container. I don't think it matters so much whether the dependency is satisfied by the portal or by my own deployed artifacts. But Liferay does have visions for the future related to creation of custom boms to use in conjunction with the Liferay boms, and in that future it may be necessary to make these kinds of distinctions. So using the right compile or compileOnly directive may actually serve you in the long run although there's no actual benefit today. Please sign in to reply. Reply as... Cancel
Denis Signoretto 5 Years Ago Hey, if Liferay is working on logging system is time to take care of MDC? (ref. https://issues.liferay.com/browse/LPS-44869 and https://issues.liferay.com/browse/LPS-44900 ) Please sign in to reply. Reply as... Cancel David H Nebinger Denis Signoretto 5 Years Ago - Edited Well, it is not so much that they are working on a logging system, it is more like they have added the SLF4J bridge so the same SLF4J API used in other projects can be leveraged under Liferay. I know the MDC is a like to have and can really improve traceability in logs, but I'm not aware of any ongoing effort to switch out the logging. That said, neither am I necessarily privy to all of the activity and planning for 7.2 and/or future releases. I think moving to SLF4J is a solid recommendation to be ready for when (if) the MDC support comes, though. Please sign in to reply. Reply as... Cancel Matthew K. Denis Signoretto 4 Years Ago Yeah, it really is a pain in the ass that Liferay does not support MDC out of the box especially because many clients are asking for that feature. Luckily it is not that difficult to manually enable it. Please sign in to reply. Reply as... Cancel Aldo De Vleeschauwer Matthew K. 2 Years Ago Interesting ... where can I find more info on how to enable it ? Please sign in to reply. Reply as... Cancel
David H Nebinger Denis Signoretto 5 Years Ago - Edited Well, it is not so much that they are working on a logging system, it is more like they have added the SLF4J bridge so the same SLF4J API used in other projects can be leveraged under Liferay. I know the MDC is a like to have and can really improve traceability in logs, but I'm not aware of any ongoing effort to switch out the logging. That said, neither am I necessarily privy to all of the activity and planning for 7.2 and/or future releases. I think moving to SLF4J is a solid recommendation to be ready for when (if) the MDC support comes, though. Please sign in to reply. Reply as... Cancel
Matthew K. Denis Signoretto 4 Years Ago Yeah, it really is a pain in the ass that Liferay does not support MDC out of the box especially because many clients are asking for that feature. Luckily it is not that difficult to manually enable it. Please sign in to reply. Reply as... Cancel Aldo De Vleeschauwer Matthew K. 2 Years Ago Interesting ... where can I find more info on how to enable it ? Please sign in to reply. Reply as... Cancel
Aldo De Vleeschauwer Matthew K. 2 Years Ago Interesting ... where can I find more info on how to enable it ? Please sign in to reply. Reply as... Cancel