Jarjarify librairy in maven

[GoogleCodeExporter]

When using the mvn package command we should package require library using
jarjar

Original issue reported on code.google.com by julien.g...@gmail.com on 6 Dec 2008 at 10:47

[GoogleCodeExporter]

Original comment by JohnnyJianHY on 6 Dec 2008 at 11:32

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by julien.g...@gmail.com on 13 Dec 2008 at 11:17

• Changed state: Started

[GoogleCodeExporter]

I've got something which seems to work pretty well. 

However I was hopping I could run the tests a second time against the generated 
jar.
That might be a good thing to do but didn't had much luck.

Original comment by julien.g...@gmail.com on 14 Dec 2008 at 4:12

• Changed state: Fixed

[GoogleCodeExporter]

Reopened.

We should also jarjarify the asm library, on which cglib depends. And should we 
provide a different pom.xml with a different artifactId and different 
dependencies 
in the gmock-*-all.jar file? Maybe we should create a module(or a new project?) 
for 
gmock-all.

I wanted to help testing the gmock-*-all.jar file, but unfortunately didn't 
know how 
to do so. Should we create a new project and add a dependency of gmock-all, or 
just 
use some maven plugin in the original project?

Original comment by JohnnyJianHY on 15 Dec 2008 at 2:59

• Changed state: Started

[GoogleCodeExporter]

You are right about the asm library dependency missing. And that why I think we
should run the test suite against the generated jar. I did quite a few search 
on that
and it seems that the way for doing it is to run the surefire maven plugin a 
second
time during the integration test.

I understand your point about creating a second project for gmock-all but I 
think it
might just had confusing. At the moment you run mvn package as you always do 
and you
get both jar. Do you think we should only have the gmock-all at the end of the
package phase?

Original comment by julien.g...@gmail.com on 15 Dec 2008 at 7:58

[GoogleCodeExporter]

No, I think we should provide both jars. What's more, we may upload gmock and 
gmock-
all to the maven central repository, so we may need two different pom.xml.

Original comment by JohnnyJianHY on 15 Dec 2008 at 8:05

[GoogleCodeExporter]

Ok. What I will probably do is to create two directory under the trunk gmock and
gmock-all. Both will have their own pom.

Original comment by julien.g...@gmail.com on 17 Dec 2008 at 12:57

[GoogleCodeExporter]

Actually, we should have two different pom.xml and the same copy of source 
code. But
it seems that maven doesn't have a good solution of this.

I have checked out the solution of groovy, which uses ant and xsl. Maybe we can
follow this or find if gradle has a better solution.

Original comment by JohnnyJianHY on 20 Dec 2008 at 6:05

[GoogleCodeExporter]

I've added the missing asm dependency. 

I've modify the pom to provide by default gmock-{version}.jar as the artifacts
containing all the jarjarified dependencies. We've been through all the trouble 
of
using jarjar so our users don't have to think about dependencies. If someone is
interested in the non jarjarify jar they would find it in the target directory 
under
gmock-only-{version}.jar.

I try pretty hard to had an integration step that would run the test against the
artifact without any luck. It seems like we should be doing something like: 
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.4.2</version>
                <executions>
                    <execution>
                        <phase>integration-test</phase>
                        <goals><goal>test</goal></goals>
                        <configuration>
                            <classesDirectory>none</classesDirectory>
                            <additionalClasspathElements>

<additionalClasspathElement>target/gmock-${project.version}.jar</additionalClass
pathElement>
                            </additionalClasspathElements>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

But the execution always see all the dependencies including cglib, asm... and it
didn't catch it when I missed the asm...

Original comment by julien.g...@gmail.com on 20 Dec 2008 at 12:13

• Changed state: Fixed

[GoogleCodeExporter]

It does not work correctly, try "mvn install", then you will find that the
gmock-only-*.jar file has been installed into the repository.

What's more, the scopes of cglib and objenesis should be changed into 
"provided".

I have an idea about how to test the jar file. First, use
test-jar(http://maven.apache.org/guides/mini/guide-attached-tests.html). Second,
create a new project which depends on gmock and gmock's test-jar but not cglib 
and
objenesis. Last, test this project. I have not tried this idea yet.

Original comment by JohnnyJianHY on 20 Dec 2008 at 3:17

[GoogleCodeExporter]

Instead of setting the final name of the jar, I think you can just rename the 
jar by
ant task:

<move file="target/gmock-${project.version}.jar"
tofile="target/gmock-only-${project.version}.jar" />
...
<jarjar jarfile="target/gmock-${project.version}.jar">
  <zipfileset src="target/gmock-only-${project.version}.jar"/>
  ...
</jarjar>

Then the problem will be solved.

Original comment by JohnnyJianHY on 20 Dec 2008 at 3:29

[GoogleCodeExporter]

You are right about the "mvn install" broken. I've applied your suggestion.

I thought about the test-jar artifact. It might work but having it on a 
different
project would probably will forgotten about. Ideally this should really be the
integration-test step, the artifact couldn't be published without passing it. 

Another direction I try was to run the unit test through the maven ant task 
without
much luck.

I think we should leave it for the moment as we won't be making much 
modification on
that particular area.

Original comment by julien.g...@gmail.com on 20 Dec 2008 at 5:48

[GoogleCodeExporter]

OK. But I think there are two things we should do:

1. Change the scopes of cglib and objenesis into "provided", otherwise these
dependencies will be transited.
2. Raise another issue for testing the jarjarified jar file.

Original comment by JohnnyJianHY on 21 Dec 2008 at 7:26

[GoogleCodeExporter]

Good thinking about changing the scope of cglib and objenesis. I haven't really 
use
scoping much but I wonder if this could help testing the jarjarified jar.
(http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanis
m.html)

Original comment by julien.g...@gmail.com on 21 Dec 2008 at 7:44