Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
On Tue, Jul 5, 2011 at 2:50 AM, Kasun Gajasinghe kasu...@gmail.com wrote: snip On Jul 4, 2011, at 11:48 AM, Robert Burrell Donkin wrote: snip After many problems, I've now opted to uninstall the official Maven and Ant packages (and Eclipse...), and use instead a set of scripts which accurately and flexibly allow me to configure exactly the official bytecode I want to use (a little bit like a better eselect). By official did you meant the upstream packages available as binary like maven-bin? If that's the case, these -bins are the same as upstream build. I guess you meant that since there's only the binary maven is available now. What did you find wrong? I've given up wasting my time tracking them Developers need good switchable support for multiple, official versions. Ideally, Gentoo would use it's slots system to maintain the official bytecode sources used to compose the applications I'm interested in using. This would allow me to use this local repository to provision OSGI and Maven without downloading them dynamically. The Gentoo approach (hacking together replacement builds for the bytecode) means all the source bytecode is an unreliable and unmaintainable way to provision a library infrastructure for bytecode languages. rant It has always struck me as somewhat ironic that if the Gentoo team donned their clue-hats and treated bytecode as the source form then they might quickly have one of the best development environments for the bytecode languages... I too kind of agree to this since the point being the built jars are platform independent. If anybody like to know the points for it - http://www.gentoo.org/proj/en/java/why-build-from-source.xml I'm not going to discuss why building from source is good or bad any further and is off-topic! ;) For bytecode languages, the compressed bytecode archive (for example, a jar) is the source. I've been using Gentoo for the better part of a decade and understand the arguments about bytecode languages very well used by Java team (and others). The problem is that they are just simply and plainly factually incorrect. This systematic dissemination of disinformation has IMO been tolerated by the wider community for too long. In particular, the phrase In the future building, native compiling from Java source code using gcj could become a serious option. would be laughable if it didn't represent such an important and fundamental misunderstanding of how virtual machines work. On reflection and after many years of consideration, I've come to the conclusion that the main reason why these rules were picked were to ensure patchy and buggy support for bytecode languages on Linux. /rant Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
The point I am making is that if you have all those jars together something is not going to work correctly. SLF4J only allows one logging implementation. If you have all of SLF4J's jars, including the binding for Log4j as well as Logback, then SLF4J will throw a runtime exception. Commons Logging also has quirks. If Log4j is present then it will be used by default, otherwise it will do something else. When you start dumping a whole bunch of jars together in one directory you had better understand how they are all going to relate to each other. Ralph On Jul 3, 2011, at 10:54 AM, Kasun Gajasinghe wrote: On Sun, Jul 3, 2011 at 10:42 PM, Ralph Goers ralph.go...@dslextreme.comwrote: Out of curiosity, you said you are putting building your jars and putting them in a shared library. What are you going to do with SLF4J, Log4J, Commons Logging and Logback? slf4j, commons-logging etc. will also be installed at /usr/share as usual. Maven needs to shade these jars and few others. So, these jars will be shaded, and packaged together to make an uber-jar. slf4j, commons-logging system jars won't be changed. What exactly the point you are trying to make? And, how does log4j and Logback relates to core maven? I haven't seen these as dependencies! --Kasun Ralph On Jul 3, 2011, at 9:57 AM, Kasun Gajasinghe wrote: On Sun, Jul 3, 2011 at 6:30 PM, Benson Margulies bimargul...@gmail.com wrote: I'm not sure that the operation you are asking for is well-defined. Shade combines, renames, and transforms, using arbitrary Java plugins that operate entirely on binaries, which can themselves be the output of, well, shade. Trying to read the source and perform the same transformations would be very, very, hard. You might be able to grab jarjar, a non-maven tool with similar capabilities, build it from source, and use it for these simple cases as part of your bootstrap. Or, for bootstrap, you could leave out the shading and just depend on Xerces unrenamed, go all the way around, build shade, and then rebuild. I've ran jarjar with some samples and checked. This would indeed do the job. I hope there is no concerning bugs. I see a bug report saying it fails with ant 1.8. Well, I'm going to go ahead with this. Thanks for the suggestion Benson! --Kasun Or you might be able to cherry-pick the maven-shade-plugin source. It could be that there is a clean separation in there between code connected to the plugin framework and code that does the work. On Sun, Jul 3, 2011 at 7:38 AM, Kasun Gajasinghe kasu...@gmail.com wrote: On Sun, Jul 3, 2011 at 4:23 PM, Benson Margulies bimargul...@gmail.com wrote: I'm not sure what you are asking. Shade is a binary operation that uses asm. It renames packages. There is no feature of creating corresponding source. I see. It means what I asked is not possible. I wasn't aware that it's a binary operation. What I want to do is to relocate the packages such as org.codehaus.plexus.util, org.apache.xerces that are shaded by maven in the official build. As you know, these should be shaded, else these classes will conflict with a different version of the same class that a project would be using. Because of the approach we are taking, we can't invoke maven-shade-plugin and get the job done. I think I'll have to manually patch the maven sources to get the said functionality. Have to proceed on this track if there's no other way. Can you please let me know the changes required to get this done? Thanks, --Kasun If you just want the original source, the plugin doesn't get into that business either, that would be a whole 'nother plugin. On Sun, Jul 3, 2011 at 6:39 AM, Kasun Gajasinghe kasu...@gmail.com wrote: Hi, Is it possible to have the .java source files which got shaded by maven-shade-plugin? Currently, it generates the uberjar without leaving the shaded sources files. There's obviously an intermediary step in which these source files will be transformed to shaded java packages like hidden.org.codehaus.plexus.util.*. So, like to know whether it's possible to have those .java files. Any complications involved? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
On Mon, Jul 4, 2011 at 11:31 AM, Ralph Goers ralph.go...@dslextreme.comwrote: The point I am making is that if you have all those jars together something is not going to work correctly. SLF4J only allows one logging implementation. If you have all of SLF4J's jars, including the binding for Log4j as well as Logback, then SLF4J will throw a runtime exception. Commons Logging also has quirks. If Log4j is present then it will be used by default, otherwise it will do something else. When you start dumping a whole bunch of jars together in one directory you had better understand how they are all going to relate to each other. I don't get it. log4j and logback won't be included in gentoo's uber-jar since they aren't dependencies of apache-maven [1]. commons-logging and slf4j will be integrated since they are integrated in the upstream official build as well. What makes you think that I'm bundling together all the available logging implementations? Is there a need to? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Regards, --Kasun
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
The question I asked was, will you be putting the slf4j, Log4j, commons-logging, and Logback into your shared library - presumably under /usr/shared. This has nothing to do with Maven, per se. Maybe I'm not clear on what you are doing but I see two possibilities: 1. You are placing all the resultant jars in a common directory, such as /usr/share/lib, where applications will use them. This won't work for the reasons below. 2. You are building all these projects as independent entities under /usr/share. If this is the case then it sounds like you are (sort of) duplicating the Maven repository and I have no idea why this is of benefit to anyone, especially since you will only support a single version of an artifact. I could understand this if you are building applications end users can use that are written in Java, but in that case I'd wonder why you don't just use out-of-the-box Maven and either a) just download the dependencies from the central repo or b) build the dependencies from their source and deploy them to your local repository. Of course, with the second option you would have to build several versions of the dependencies. Ralph On Jul 4, 2011, at 6:11 AM, Kasun Gajasinghe wrote: On Mon, Jul 4, 2011 at 11:31 AM, Ralph Goers ralph.go...@dslextreme.comwrote: The point I am making is that if you have all those jars together something is not going to work correctly. SLF4J only allows one logging implementation. If you have all of SLF4J's jars, including the binding for Log4j as well as Logback, then SLF4J will throw a runtime exception. Commons Logging also has quirks. If Log4j is present then it will be used by default, otherwise it will do something else. When you start dumping a whole bunch of jars together in one directory you had better understand how they are all going to relate to each other. I don't get it. log4j and logback won't be included in gentoo's uber-jar since they aren't dependencies of apache-maven [1]. commons-logging and slf4j will be integrated since they are integrated in the upstream official build as well. What makes you think that I'm bundling together all the available logging implementations? Is there a need to? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Regards, --Kasun - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
On Mon, Jul 4, 2011 at 8:34 PM, Ralph Goers ralph.go...@dslextreme.comwrote: The question I asked was, will you be putting the slf4j, Log4j, commons-logging, and Logback into your shared library - presumably under /usr/shared. This has nothing to do with Maven, per se. Maybe I'm not clear on what you are doing but I see two possibilities: 1. You are placing all the resultant jars in a common directory, such as /usr/share/lib, where applications will use them. This won't work for the reasons below. This isn't the case. 2. You are building all these projects as independent entities under /usr/share. If this is the case then it sounds like you are (sort of) duplicating the Maven repository and I have no idea why this is of benefit to anyone, especially since you will only support a single version of an artifact. Almost true. For example, slf4j jar is under /usr/share/slf4j/lib/slf4j.jar. And, we have a concept called SLOT which is almost acts like the first level of a two level index if you are familiar with DBMS. A particular SLOT contains a set of versions (ex. 1.1, 1.12, 1.2 etc.) which are compatible with each other. So, only one jar can be installed in a particular SLOT. There can be several SLOTs, implying we can have more than one version of an artifact. ex. jarjar new version is in SLOT 1, i.e. /usr/share/jarjar-1/ And, these jars in /usr/share/*/lib/*.jar are not only for maven. To be specific not intended for maven. These are for system use. Any application maven or not is able to benefit from these. What we are doing is using these jars under maven, so we don't have to download these again. I could understand this if you are building applications end users can use that are written in Java, but in that case I'd wonder why you don't just use out-of-the-box Maven and either a) just download the dependencies from the central repo or b) build the dependencies from their source and deploy them to your local repository. Of course, with the second option you would have to build several versions of the dependencies. To reiterate, our main usecase is supporting packagers at system level. There's a need to have a custom build for them. It's not like we blind-foldly building maven again instead of using official maven build! To answer your question; at system-level, maven should be run completely offline (even at first time!). We have mechanisms in place to take care of the deps via DEPEND in ebuilds, which I'm not going to explain. Read about Gentoo if you got spare time. It'll be interesting! :) --Kasun Ralph On Jul 4, 2011, at 6:11 AM, Kasun Gajasinghe wrote: On Mon, Jul 4, 2011 at 11:31 AM, Ralph Goers ralph.go...@dslextreme.com wrote: The point I am making is that if you have all those jars together something is not going to work correctly. SLF4J only allows one logging implementation. If you have all of SLF4J's jars, including the binding for Log4j as well as Logback, then SLF4J will throw a runtime exception. Commons Logging also has quirks. If Log4j is present then it will be used by default, otherwise it will do something else. When you start dumping a whole bunch of jars together in one directory you had better understand how they are all going to relate to each other. I don't get it. log4j and logback won't be included in gentoo's uber-jar since they aren't dependencies of apache-maven [1]. commons-logging and slf4j will be integrated since they are integrated in the upstream official build as well. What makes you think that I'm bundling together all the available logging implementations? Is there a need to? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Regards, --Kasun - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
look, what you are trying to do is move an object of infinite mass, keeping the lever length and force applied finite. good luck, it will be fun for us watching from the sidelines... fundamentally maven is about downloading dependencies on demand from the network rather than building from source... gentoo is about building from source rather than downloading binaries from the network... - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 4 Jul 2011 16:56, Kasun Gajasinghe kasu...@gmail.com wrote: On Mon, Jul 4, 2011 at 8:34 PM, Ralph Goers ralph.go...@dslextreme.com wrote: The question I asked was, will you be putting the slf4j, Log4j, commons-logging, and Logback into your shared library - presumably under /usr/shared. This has nothing to do with Maven, per se. Maybe I'm not clear on what you are doing but I see two possibilities: 1. You are placing all the resultant jars in a common directory, such as /usr/share/lib, where applications will use them. This won't work for the reasons below. This isn't the case. 2. You are building all these projects as independent entities under /usr/share. If this is the case then it sounds like you are (sort of) duplicating the Maven repository and I have no idea why this is of benefit to anyone, especially since you will only support a single version of an artifact. Almost true. For example, slf4j jar is under /usr/share/slf4j/lib/slf4j.jar. And, we have a concept called SLOT which is almost acts like the first level of a two level index if you are familiar with DBMS. A particular SLOT contains a set of versions (ex. 1.1, 1.12, 1.2 etc.) which are compatible with each other. So, only one jar can be installed in a particular SLOT. There can be several SLOTs, implying we can have more than one version of an artifact. ex. jarjar new version is in SLOT 1, i.e. /usr/share/jarjar-1/ And, these jars in /usr/share/*/lib/*.jar are not only for maven. To be specific not intended for maven. These are for system use. Any application maven or not is able to benefit from these. What we are doing is using these jars under maven, so we don't have to download these again. I could understand this if you are building applications end users can use that are written in Java, but in that case I'd wonder why you don't just use out-of-the-box Maven and either a) just download the dependencies from the central repo or b) build the dependencies from their source and deploy them to your local repository. Of course, with the second option you would have to build several versions of the dependencies. To reiterate, our main usecase is supporting packagers at system level. There's a need to have a custom build for them. It's not like we blind-foldly building maven again instead of using official maven build! To answer your question; at system-level, maven should be run completely offline (even at first time!). We have mechanisms in place to take care of the deps via DEPEND in ebuilds, which I'm not going to explain. Read about Gentoo if you got spare time. It'll be interesting! :) --Kasun Ralph On Jul 4, 2011, at 6:11 AM, Kasun Gajasinghe wrote: On Mon, Jul 4, 2011 at 11:31 AM, Ralph Goers ralph.go...@dslextreme.com wrote: The point I am making is that if you have all those jars together something is not going to work correctly. SLF4J only allows one logging implementation. If you have all of SLF4J's jars, including the binding for Log4j as well as Logback, then SLF4J will throw a runtime exception. Commons Logging also has quirks. If Log4j is present then it will be used by default, otherwise it will do something else. When you start dumping a whole bunch of jars together in one directory you had better understand how they are all going to relate to each other. I don't get it. log4j and logback won't be included in gentoo's uber-jar since they aren't dependencies of apache-maven [1]. commons-logging and slf4j will be integrated since they are integrated in the upstream official build as well. What makes you think that I'm bundling together all the available logging implementations? Is there a need to? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Regards, --Kasun - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
On Mon, Jul 4, 2011 at 7:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: look, what you are trying to do is move an object of infinite mass, keeping the lever length and force applied finite. good luck, it will be fun for us watching from the sidelines... fundamentally maven is about downloading dependencies on demand from the network rather than building from source... gentoo is about building from source rather than downloading binaries from the network... (as a gentoo user myself...) The bytecode languages don't fit well into the Gentoo model. Even though bytecode is an intermediary source form compiled from source, Gentoo tries to treat it as a platform dependent binary. The Java team then fights a losing battle to cobble together enough accurate builds for the library chain to get anything useful to work. Even then, because the source bytecode doesn't necessarily match the official release, strange issue keep cropping up. After many problems, I've now opted to uninstall the official Maven and Ant packages (and Eclipse...), and use instead a set of scripts which accurately and flexibly allow me to configure exactly the official bytecode I want to use (a little bit like a better eselect). It has always struck me as somewhat ironic that if the Gentoo team donned their clue-hats and treated bytecode as the source form then they might quickly have one of the best development environments for the bytecode languages... Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
From Kasun's answers it is quite clear to me that we will need to add something to Jira where it asks for the operating system for all the Java projects I work on at the ASF. If the O.S. is Gentoo then we will have to reject any issues coming from the stuff that comes as part of the O.S. as it can't be trusted. Ralph On Jul 4, 2011, at 11:48 AM, Robert Burrell Donkin wrote: On Mon, Jul 4, 2011 at 7:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: look, what you are trying to do is move an object of infinite mass, keeping the lever length and force applied finite. good luck, it will be fun for us watching from the sidelines... fundamentally maven is about downloading dependencies on demand from the network rather than building from source... gentoo is about building from source rather than downloading binaries from the network... (as a gentoo user myself...) The bytecode languages don't fit well into the Gentoo model. Even though bytecode is an intermediary source form compiled from source, Gentoo tries to treat it as a platform dependent binary. The Java team then fights a losing battle to cobble together enough accurate builds for the library chain to get anything useful to work. Even then, because the source bytecode doesn't necessarily match the official release, strange issue keep cropping up. After many problems, I've now opted to uninstall the official Maven and Ant packages (and Eclipse...), and use instead a set of scripts which accurately and flexibly allow me to configure exactly the official bytecode I want to use (a little bit like a better eselect). It has always struck me as somewhat ironic that if the Gentoo team donned their clue-hats and treated bytecode as the source form then they might quickly have one of the best development environments for the bytecode languages... Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
Ralph Goers wrote: From Kasun's answers it is quite clear to me that we will need to add something to Jira where it asks for the operating system for all the Java projects I work on at the ASF. If the O.S. is Gentoo then we will have to reject any issues coming from the stuff that comes as part of the O.S. as it can't be trusted. Actually not every Gentoo user would ever install a Gentoo-built Maven. At least not me ;-) - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
On Tue, Jul 5, 2011 at 1:57 AM, Ralph Goers ralph.go...@dslextreme.comwrote: From Kasun's answers it is quite clear to me that we will need to add something to Jira where it asks for the operating system for all the Java projects I work on at the ASF. If the O.S. is Gentoo then we will have to reject any issues coming from the stuff that comes as part of the O.S. as it can't be trusted. Binary official build also available in Gentoo already. On Jul 4, 2011, at 11:48 AM, Robert Burrell Donkin wrote: On Mon, Jul 4, 2011 at 7:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: look, what you are trying to do is move an object of infinite mass, keeping the lever length and force applied finite. good luck, it will be fun for us watching from the sidelines... fundamentally maven is about downloading dependencies on demand from the network rather than building from source... gentoo is about building from source rather than downloading binaries from the network... (as a gentoo user myself...) The bytecode languages don't fit well into the Gentoo model. Even though bytecode is an intermediary source form compiled from source, Gentoo tries to treat it as a platform dependent binary. The Java team then fights a losing battle to cobble together enough accurate builds for the library chain to get anything useful to work. Even then, because the source bytecode doesn't necessarily match the official release, strange issue keep cropping up. After many problems, I've now opted to uninstall the official Maven and Ant packages (and Eclipse...), and use instead a set of scripts which accurately and flexibly allow me to configure exactly the official bytecode I want to use (a little bit like a better eselect). By official did you meant the upstream packages available as binary like maven-bin? If that's the case, these -bins are the same as upstream build. I guess you meant that since there's only the binary maven is available now. What did you find wrong? It has always struck me as somewhat ironic that if the Gentoo team donned their clue-hats and treated bytecode as the source form then they might quickly have one of the best development environments for the bytecode languages... I too kind of agree to this since the point being the built jars are platform independent. If anybody like to know the points for it - http://www.gentoo.org/proj/en/java/why-build-from-source.xml I'm not going to discuss why building from source is good or bad any further and is off-topic! ;) Regards, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
I'm not sure what you are asking. Shade is a binary operation that uses asm. It renames packages. There is no feature of creating corresponding source. If you just want the original source, the plugin doesn't get into that business either, that would be a whole 'nother plugin. On Sun, Jul 3, 2011 at 6:39 AM, Kasun Gajasinghe kasu...@gmail.com wrote: Hi, Is it possible to have the .java source files which got shaded by maven-shade-plugin? Currently, it generates the uberjar without leaving the shaded sources files. There's obviously an intermediary step in which these source files will be transformed to shaded java packages like hidden.org.codehaus.plexus.util.*. So, like to know whether it's possible to have those .java files. Any complications involved? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
On Sun, Jul 3, 2011 at 4:23 PM, Benson Margulies bimargul...@gmail.comwrote: I'm not sure what you are asking. Shade is a binary operation that uses asm. It renames packages. There is no feature of creating corresponding source. I see. It means what I asked is not possible. I wasn't aware that it's a binary operation. What I want to do is to relocate the packages such as org.codehaus.plexus.util, org.apache.xerces that are shaded by maven in the official build. As you know, these should be shaded, else these classes will conflict with a different version of the same class that a project would be using. Because of the approach we are taking, we can't invoke maven-shade-plugin and get the job done. I think I'll have to manually patch the maven sources to get the said functionality. Have to proceed on this track if there's no other way. Can you please let me know the changes required to get this done? Thanks, --Kasun If you just want the original source, the plugin doesn't get into that business either, that would be a whole 'nother plugin. On Sun, Jul 3, 2011 at 6:39 AM, Kasun Gajasinghe kasu...@gmail.com wrote: Hi, Is it possible to have the .java source files which got shaded by maven-shade-plugin? Currently, it generates the uberjar without leaving the shaded sources files. There's obviously an intermediary step in which these source files will be transformed to shaded java packages like hidden.org.codehaus.plexus.util.*. So, like to know whether it's possible to have those .java files. Any complications involved? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
I'm not sure that the operation you are asking for is well-defined. Shade combines, renames, and transforms, using arbitrary Java plugins that operate entirely on binaries, which can themselves be the output of, well, shade. Trying to read the source and perform the same transformations would be very, very, hard. You might be able to grab jarjar, a non-maven tool with similar capabilities, build it from source, and use it for these simple cases as part of your bootstrap. Or, for bootstrap, you could leave out the shading and just depend on Xerces unrenamed, go all the way around, build shade, and then rebuild. Or you might be able to cherry-pick the maven-shade-plugin source. It could be that there is a clean separation in there between code connected to the plugin framework and code that does the work. On Sun, Jul 3, 2011 at 7:38 AM, Kasun Gajasinghe kasu...@gmail.com wrote: On Sun, Jul 3, 2011 at 4:23 PM, Benson Margulies bimargul...@gmail.comwrote: I'm not sure what you are asking. Shade is a binary operation that uses asm. It renames packages. There is no feature of creating corresponding source. I see. It means what I asked is not possible. I wasn't aware that it's a binary operation. What I want to do is to relocate the packages such as org.codehaus.plexus.util, org.apache.xerces that are shaded by maven in the official build. As you know, these should be shaded, else these classes will conflict with a different version of the same class that a project would be using. Because of the approach we are taking, we can't invoke maven-shade-plugin and get the job done. I think I'll have to manually patch the maven sources to get the said functionality. Have to proceed on this track if there's no other way. Can you please let me know the changes required to get this done? Thanks, --Kasun If you just want the original source, the plugin doesn't get into that business either, that would be a whole 'nother plugin. On Sun, Jul 3, 2011 at 6:39 AM, Kasun Gajasinghe kasu...@gmail.com wrote: Hi, Is it possible to have the .java source files which got shaded by maven-shade-plugin? Currently, it generates the uberjar without leaving the shaded sources files. There's obviously an intermediary step in which these source files will be transformed to shaded java packages like hidden.org.codehaus.plexus.util.*. So, like to know whether it's possible to have those .java files. Any complications involved? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
On Sun, Jul 3, 2011 at 6:30 PM, Benson Margulies bimargul...@gmail.comwrote: I'm not sure that the operation you are asking for is well-defined. Shade combines, renames, and transforms, using arbitrary Java plugins that operate entirely on binaries, which can themselves be the output of, well, shade. Trying to read the source and perform the same transformations would be very, very, hard. You might be able to grab jarjar, a non-maven tool with similar capabilities, build it from source, and use it for these simple cases as part of your bootstrap. Or, for bootstrap, you could leave out the shading and just depend on Xerces unrenamed, go all the way around, build shade, and then rebuild. I've ran jarjar with some samples and checked. This would indeed do the job. I hope there is no concerning bugs. I see a bug report saying it fails with ant 1.8. Well, I'm going to go ahead with this. Thanks for the suggestion Benson! --Kasun Or you might be able to cherry-pick the maven-shade-plugin source. It could be that there is a clean separation in there between code connected to the plugin framework and code that does the work. On Sun, Jul 3, 2011 at 7:38 AM, Kasun Gajasinghe kasu...@gmail.com wrote: On Sun, Jul 3, 2011 at 4:23 PM, Benson Margulies bimargul...@gmail.com wrote: I'm not sure what you are asking. Shade is a binary operation that uses asm. It renames packages. There is no feature of creating corresponding source. I see. It means what I asked is not possible. I wasn't aware that it's a binary operation. What I want to do is to relocate the packages such as org.codehaus.plexus.util, org.apache.xerces that are shaded by maven in the official build. As you know, these should be shaded, else these classes will conflict with a different version of the same class that a project would be using. Because of the approach we are taking, we can't invoke maven-shade-plugin and get the job done. I think I'll have to manually patch the maven sources to get the said functionality. Have to proceed on this track if there's no other way. Can you please let me know the changes required to get this done? Thanks, --Kasun If you just want the original source, the plugin doesn't get into that business either, that would be a whole 'nother plugin. On Sun, Jul 3, 2011 at 6:39 AM, Kasun Gajasinghe kasu...@gmail.com wrote: Hi, Is it possible to have the .java source files which got shaded by maven-shade-plugin? Currently, it generates the uberjar without leaving the shaded sources files. There's obviously an intermediary step in which these source files will be transformed to shaded java packages like hidden.org.codehaus.plexus.util.*. So, like to know whether it's possible to have those .java files. Any complications involved? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
Out of curiosity, you said you are putting building your jars and putting them in a shared library. What are you going to do with SLF4J, Log4J, Commons Logging and Logback? Ralph On Jul 3, 2011, at 9:57 AM, Kasun Gajasinghe wrote: On Sun, Jul 3, 2011 at 6:30 PM, Benson Margulies bimargul...@gmail.comwrote: I'm not sure that the operation you are asking for is well-defined. Shade combines, renames, and transforms, using arbitrary Java plugins that operate entirely on binaries, which can themselves be the output of, well, shade. Trying to read the source and perform the same transformations would be very, very, hard. You might be able to grab jarjar, a non-maven tool with similar capabilities, build it from source, and use it for these simple cases as part of your bootstrap. Or, for bootstrap, you could leave out the shading and just depend on Xerces unrenamed, go all the way around, build shade, and then rebuild. I've ran jarjar with some samples and checked. This would indeed do the job. I hope there is no concerning bugs. I see a bug report saying it fails with ant 1.8. Well, I'm going to go ahead with this. Thanks for the suggestion Benson! --Kasun Or you might be able to cherry-pick the maven-shade-plugin source. It could be that there is a clean separation in there between code connected to the plugin framework and code that does the work. On Sun, Jul 3, 2011 at 7:38 AM, Kasun Gajasinghe kasu...@gmail.com wrote: On Sun, Jul 3, 2011 at 4:23 PM, Benson Margulies bimargul...@gmail.com wrote: I'm not sure what you are asking. Shade is a binary operation that uses asm. It renames packages. There is no feature of creating corresponding source. I see. It means what I asked is not possible. I wasn't aware that it's a binary operation. What I want to do is to relocate the packages such as org.codehaus.plexus.util, org.apache.xerces that are shaded by maven in the official build. As you know, these should be shaded, else these classes will conflict with a different version of the same class that a project would be using. Because of the approach we are taking, we can't invoke maven-shade-plugin and get the job done. I think I'll have to manually patch the maven sources to get the said functionality. Have to proceed on this track if there's no other way. Can you please let me know the changes required to get this done? Thanks, --Kasun If you just want the original source, the plugin doesn't get into that business either, that would be a whole 'nother plugin. On Sun, Jul 3, 2011 at 6:39 AM, Kasun Gajasinghe kasu...@gmail.com wrote: Hi, Is it possible to have the .java source files which got shaded by maven-shade-plugin? Currently, it generates the uberjar without leaving the shaded sources files. There's obviously an intermediary step in which these source files will be transformed to shaded java packages like hidden.org.codehaus.plexus.util.*. So, like to know whether it's possible to have those .java files. Any complications involved? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
On Sun, Jul 3, 2011 at 10:42 PM, Ralph Goers ralph.go...@dslextreme.comwrote: Out of curiosity, you said you are putting building your jars and putting them in a shared library. What are you going to do with SLF4J, Log4J, Commons Logging and Logback? slf4j, commons-logging etc. will also be installed at /usr/share as usual. Maven needs to shade these jars and few others. So, these jars will be shaded, and packaged together to make an uber-jar. slf4j, commons-logging system jars won't be changed. What exactly the point you are trying to make? And, how does log4j and Logback relates to core maven? I haven't seen these as dependencies! --Kasun Ralph On Jul 3, 2011, at 9:57 AM, Kasun Gajasinghe wrote: On Sun, Jul 3, 2011 at 6:30 PM, Benson Margulies bimargul...@gmail.com wrote: I'm not sure that the operation you are asking for is well-defined. Shade combines, renames, and transforms, using arbitrary Java plugins that operate entirely on binaries, which can themselves be the output of, well, shade. Trying to read the source and perform the same transformations would be very, very, hard. You might be able to grab jarjar, a non-maven tool with similar capabilities, build it from source, and use it for these simple cases as part of your bootstrap. Or, for bootstrap, you could leave out the shading and just depend on Xerces unrenamed, go all the way around, build shade, and then rebuild. I've ran jarjar with some samples and checked. This would indeed do the job. I hope there is no concerning bugs. I see a bug report saying it fails with ant 1.8. Well, I'm going to go ahead with this. Thanks for the suggestion Benson! --Kasun Or you might be able to cherry-pick the maven-shade-plugin source. It could be that there is a clean separation in there between code connected to the plugin framework and code that does the work. On Sun, Jul 3, 2011 at 7:38 AM, Kasun Gajasinghe kasu...@gmail.com wrote: On Sun, Jul 3, 2011 at 4:23 PM, Benson Margulies bimargul...@gmail.com wrote: I'm not sure what you are asking. Shade is a binary operation that uses asm. It renames packages. There is no feature of creating corresponding source. I see. It means what I asked is not possible. I wasn't aware that it's a binary operation. What I want to do is to relocate the packages such as org.codehaus.plexus.util, org.apache.xerces that are shaded by maven in the official build. As you know, these should be shaded, else these classes will conflict with a different version of the same class that a project would be using. Because of the approach we are taking, we can't invoke maven-shade-plugin and get the job done. I think I'll have to manually patch the maven sources to get the said functionality. Have to proceed on this track if there's no other way. Can you please let me know the changes required to get this done? Thanks, --Kasun If you just want the original source, the plugin doesn't get into that business either, that would be a whole 'nother plugin. On Sun, Jul 3, 2011 at 6:39 AM, Kasun Gajasinghe kasu...@gmail.com wrote: Hi, Is it possible to have the .java source files which got shaded by maven-shade-plugin? Currently, it generates the uberjar without leaving the shaded sources files. There's obviously an intermediary step in which these source files will be transformed to shaded java packages like hidden.org.codehaus.plexus.util.*. So, like to know whether it's possible to have those .java files. Any complications involved? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter:
