Maven-ize GuiceBerry

[GoogleCodeExporter]

Is there any chance GuiceBerry to be mavenized ? 

It would be really nice if GuiceBerry can be used as a maven artifact.

Original issue reported on code.google.com by MGe...@gmail.com on 29 Mar 2009 at 12:20

[GoogleCodeExporter]

I'd be delighted if you (or anyone) can send a patch for this. Currently, the 
process
of making a release is kind of a drag, and maven is awesome at this sort of 
stuff.

Now, caveat emptor: a co-worker who is a maven-fan tried to bootstrap me on 
maven for
GuiceBerry a while back, but it never really worked for me. If I recall 
correctly the
main sticking point was that maven, out of the box, makes a number of 
assumptions
about how your project is structured. And, to stray of that was not something we
figured out how to do. In particular, a GuiceBerry release needs a separate jar 
file
for the tutorial. I think another issue we had is that (back then, at least), 
there
was no integration with googlecode.

Again, if you can figure out how to make it work, I'll be happy to apply a 
patch. And
if you need to make some structural changes to directory location, etc, let me 
know.

Original comment by zorze...@gmail.com on 29 Mar 2009 at 3:48

• Changed title: Maven-ize GuiceBerry
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Hello, 

  I had started to work on it but currently I'm encountering some problems. The most 
generic problem is that GuiceBerry has e dependency to: 
Guice-Commands (Not in any maven repository)
tl4j- same problem as with Guice-Commands and also I think that dependency is 
only to 
two classes only  

I don't know how good is the idea for moving to Guice-2. I though about this 
because 
it seems that most of the Guice-Commands functionality has been moved to Guice 
2. 
Unfortunately there are some classes that are missing or they are changed or 
deprecated for some reasons.

Here are the things that I've made to add partial maven support to the project.
Firstly I created a maven pom.xml and with the following directory structure:
GuiceBerry
 pom.xml
 doc/ 
 lib/ (probably will be removed if we fix the dependency problem)
 src/main/java/com/google/inject/testing/guiceberry/*
 src/main/resources/ (docs folder may be moved here)
 test/main/java/com/google/inject/testing/guiceberry/*

On this structure, I've added the following dependencies:

                <dependency>
            <groupId>com.google.code.google-collections</groupId>
            <artifactId>google-collect</artifactId>
            <version>snapshot-20080530</version>
        </dependency>

        <dependency>
            <groupId>com.google.inject</groupId>
            <artifactId>guice</artifactId>
            <version>2.0-SNAPSHOT</version>
        </dependency>

        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>servlet-api</artifactId>
            <version>2.5</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>3.8.2</version>
        </dependency>

After that I've added to the project classpath (in eclipse) the tl4j.jar to may 
compile the project. Here I encountered a problems with both classes described 
below: 
com.publicobject.interceptinginjectorbuilder.InterceptingInjectorBuilder
com.google.inject.commands.intercepting.ProvisionInterceptor
To fix the issue, I've added them to the project by copying them from the 
original 
projects. 

To check whether everything is okay I make e quick run of all tests and there 
were 
problems with the InjectionController class and also in 
GuiceBerryJunit3Test#testAnnotationWithModuleThatHasMissingBindingsThrowsExcepti
on. 
After a quick look I found that the InjectorControoler is providing a 
substitution of 
existing bindings which probably can be replaced by Guice-2's Modules#override. 
For 
the second problem I think that it's a concatenation issue or maybe some issue 
with 
change in the error message. But for sure have to be checked too. 

Here I'll try to describe my second thought about moving to maven. We can stay 
at all 
current libraries that are currently used (keeping at stick with Guice-1.0). We 
can 
create a windows/unix shell script that copies all currently available 
libraries to 
the local repository. This script have to be run after project checkout. After 
the 
libraries are copied, the maven can access them and may add them to the 
classpath 
respectively and also all other maven charms can be used.

Can you give me some notes about this things? It would be nice to hear your 
opinions 
about the situation.

Thanks in advace

Original comment by MGe...@gmail.com on 4 Apr 2009 at 8:49

Attachments:

• guiceberry-read-only-maven-draft.rar

[GoogleCodeExporter]

The test breakages against guice-2.0 are known (and harmless). The issue with
controllable injections (guice-commands dependency) are also known. I will make 
all
the necessary changes once guice 2.0 is actually released (I've been pestering 
Jesse
about this for months :^>). Until then, GuiceBerry is officially guice 1.0 
compatible
(even though it does work with the guice 2.0 pre-release, for all practical 
purposes).

Let's start with the "easy" part: tl4j. <rant>Let's discount for a second the 
fact
that I'm quite irked about maven being so incapable of dealing with anything 
that
does not come from another maven repo.</rant> I (co-)own tl4j. If you want to
maven-ize it, just file a bug report at
http://code.google.com/p/test-libraries-for-java/ with the maven patch. I'll 
discuss
the patch with the other developers, and we'll take it from there.

Back to GuiceBerry, a question: what about the tutorial sources/build target?

Original comment by zorze...@gmail.com on 4 Apr 2009 at 4:38

[GoogleCodeExporter]

Regarding the test-libraries I'll take a look over the project. 

Regarding the tutorials, I think that we can add them as a different project 
that is 
a child of the main project. We can create the following structure 

guiceberry (pom)
   tutorial (jar)
   guiceberry-core (jar)
And in the future if some extensions are required, we can add them as a new 
child 
modules of the parent module.

If you have some other ideas or any doubts, please let me know about them

Original comment by MGe...@gmail.com on 4 Apr 2009 at 5:48

[GoogleCodeExporter]

Let me see how it will look like once you have the child project stuff setup, 
and
we'll take it from there.

Thanks for doing the work,

Z

Original comment by zorze...@gmail.com on 4 Apr 2009 at 7:25

[GoogleCodeExporter]

How did this work go? Is guice-berry available in a Maven repository somewhere?

Thanks

Original comment by arun.ho...@gmail.com on 21 Dec 2010 at 2:29

[GoogleCodeExporter]

This bug seems to be talking about two things.  The first is building with 
Maven.  I personally have the same complaints as zorzella when it comes to 
Maven forcing a verbose directory structure upon the user.  I much prefer 
Gradle.  In any case, there's no reason Ant can't be used if that's what the 
project maintainers want to use.  I like Maven more than Ant, but there's no 
good reason for users of a project to dictate how it's built unless they're 
also contributing code to the project.

The second second issue is that Guiceberry is not available in the Maven 
repository.  This issue is much more serious because it means Guiceberry is a 
real pain to use compared to almost every other Java library out there.  It's 
not just Maven that uses the Maven repository, but also Ant (via Ivy), Gradle, 
and almost every other Java build system out there.

Original comment by bmcc...@google.com on 29 Mar 2011 at 11:58

[GoogleCodeExporter]

Here's a hopefully helpful writeup I did on how to create the bundle for 
uploading to the Maven repository:
http://www.benmccann.com/dev-blog/creating-asc-signature-files-with-gpg/

Original comment by bmcc...@google.com on 30 Mar 2011 at 12:40

[GoogleCodeExporter]

Enjoy!
http://repo2.maven.org/maven2/com/google/guiceberry/guiceberry/3.0.4/

I think you can mark this as closed now, but I've filed issues 16, 17, and 18 
as improvements for next time.

Note that this is only half useful since tl4j doesn't appear to be available in 
a Maven repository.  I've filed bugs with both GuiceBerry and tl4j to track 
that issue.

Original comment by bmcc...@google.com on 30 Mar 2011 at 2:46

[GoogleCodeExporter]

If you were to send me a patch (to my build.xml or whatever) that would cause 
the republishing of guiceberry to maven repos whenever a cut a new release, I'd 
be happy to apply.

Original comment by zorze...@google.com on 27 May 2011 at 6:09

[GoogleCodeExporter]

I don't really know Ant (it's not used much anymore for new projects), so it 
might take me awhile to figure out how to do that.  I just manually uploaded 
it.  How do you feel about using Maven or Gradle?

I think the most important thing for getting GuiceBerry uploaded into the 
public repositories is to get the com.google.common.testing code from tl4j 
migrated over to the Guava libraries (assuming that's still the plan)

Original comment by benjamin...@gmail.com on 27 May 2011 at 6:52

[GoogleCodeExporter]

Here is a better link for people that want to use it (contains the copy-paste 
pom section)

Original comment by ron.gr...@gmail.com on 1 Jun 2011 at 5:57

[GoogleCodeExporter]

Forgot to link: 
http://search.maven.org/#artifactdetails%7Ccom.google.guiceberry%7Cguiceberry%7C
3.0.4%7Cjar

Original comment by ron.gr...@gmail.com on 1 Jun 2011 at 5:57

[GoogleCodeExporter]

Can this issue be re-opened for updating the Maven version to 3.1.0? The 
release has been out for 4 months now, and Maven is still stuck at 3.0.4.

This is especially a problem because Guiceberry 3.0.4 does not work with Guava 
r09 (which removed com.google.common.testing.TearDownAccepter).

Original comment by apetresc on 10 Sep 2011 at 11:05

[GoogleCodeExporter]

I'll upload a new version when guava r10 is out (hopefully soon?) which will 
provide a separate jar containing the com.google.common.testing stuff.

Original comment by benjamin...@gmail.com on 12 Sep 2011 at 12:42

[GoogleCodeExporter]

I uploaded Guiceberry 3.1.0 today

Original comment by benjamin...@gmail.com on 1 Oct 2011 at 5:38

[GoogleCodeExporter]

Awesome :) Thank you for this.

Original comment by apetresc on 1 Oct 2011 at 5:40

[GoogleCodeExporter]

Awesome. Thank you for this :)

Original comment by apetresc on 1 Oct 2011 at 5:40

[GoogleCodeExporter]

If someone tells me what is the command I need to run to republish guiceberry, 
I'll be happy to have it as part of the release instructions, so it always gets 
uploaded on every release. Or a patch to build.xml as I asked before.

Original comment by zorze...@gmail.com on 29 May 2013 at 3:46

[GoogleCodeExporter]

I just uploaded Guiceberry 3.3.1 to the central Maven repo. Here are the steps 
to do it if you'd like to add them to the release instructions. I don't know 
ant very well, but if you'd like I could convert the ant build script to a 
gradle build script if you wanted everything handled in an automated fashion.

1. Get .jar, -sources.jar, -javadoc.jar, and .pom file (be careful to rename 
-src.jar to -sources.jar and make sure .pom has correct version number and 
dependencies within)
2. Create an .asc file for each of the above. See 
http://www.benmccann.com/blog/creating-asc-signature-files-with-gpg/
3. Upload to https://oss.sonatype.org. Go to Staging Upload and choose 
Artifact(s) with a POM
4. Go to Staging Repositories (hit refresh if it's already open) and then 
choose Release

Original comment by benjamin...@gmail.com on 5 Jun 2013 at 7:07