You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Kasun Gajasinghe <ka...@gmail.com> on 2011/07/03 12:39:12 UTC
[Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
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
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, Jul 5, 2011 at 2:50 AM, Kasun Gajasinghe <ka...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
Posted by Kasun Gajasinghe <ka...@gmail.com>.
On Tue, Jul 5, 2011 at 1:57 AM, Ralph Goers <ra...@dslextreme.com>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.
>
>
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
> > <st...@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
Posted by Ralph Goers <ra...@dslextreme.com>.
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
> <st...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
Posted by Jörg Schaible <jo...@gmx.de>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Jul 4, 2011 at 7:32 PM, Stephen Connolly
<st...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
Posted by Stephen Connolly <st...@gmail.com>.
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" <ka...@gmail.com> wrote:
> On Mon, Jul 4, 2011 at 8:34 PM, Ralph Goers <ralph.goers@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.goers@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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
Posted by Kasun Gajasinghe <ka...@gmail.com>.
On Mon, Jul 4, 2011 at 8:34 PM, Ralph Goers <ra...@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.goers@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ra...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
Posted by Kasun Gajasinghe <ka...@gmail.com>.
On Mon, Jul 4, 2011 at 11:31 AM, Ralph Goers <ra...@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
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ra...@dslextreme.com>wrote:
>
>> 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 <bimargulies@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 <ka...@gmail.com>
>>>> wrote:
>>>>> On Sun, Jul 3, 2011 at 4:23 PM, Benson Margulies <
>> bimargulies@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 <ka...@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
Posted by Kasun Gajasinghe <ka...@gmail.com>.
On Sun, Jul 3, 2011 at 10:42 PM, Ralph Goers <ra...@dslextreme.com>wrote:
> 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 <bimargulies@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 <ka...@gmail.com>
> >> wrote:
> >>> On Sun, Jul 3, 2011 at 4:23 PM, Benson Margulies <
> bimargulies@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 <ka...@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-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <bi...@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 <ka...@gmail.com>
>> wrote:
>>> On Sun, Jul 3, 2011 at 4:23 PM, Benson Margulies <bimargulies@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 <ka...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
Posted by Kasun Gajasinghe <ka...@gmail.com>.
On Sun, Jul 3, 2011 at 6:30 PM, Benson Margulies <bi...@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 <ka...@gmail.com>
> wrote:
> > On Sun, Jul 3, 2011 at 4:23 PM, Benson Margulies <bimargulies@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 <ka...@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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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
Posted by Benson Margulies <bi...@gmail.com>.
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 <ka...@gmail.com> wrote:
> On Sun, Jul 3, 2011 at 4:23 PM, Benson Margulies <bi...@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 <ka...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
Posted by Kasun Gajasinghe <ka...@gmail.com>.
On Sun, Jul 3, 2011 at 4:23 PM, Benson Margulies <bi...@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 <ka...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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
Posted by Benson Margulies <bi...@gmail.com>.
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 <ka...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org