bineanzhou / google-guice

Automatically exported from code.google.com/p/google-guice
Apache License 2.0
0 stars 0 forks source link

Support Guice extensions for Maven #219

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Ideally, you would get these published in the maven central repository. 

But since that takes too much effort, how about just publishing it under
this project itself. See how Google Gson project does it. For it, the
repository is available at http://google-gson.googlecode.com/svn/mavenrepo/

Also see the pom.xml for the gson. We just run 

mvn package
mvn source:jar
mvn javadoc:jar
mvn assembly:assembly
mvn deploy 

and then cd ../mavenrepo/com/google/code/gson/gson and add new files to
subersion. This gets the new releases published under our maven2
repository. You can follow a similar process to publish these locally. Thanks.

Original issue reported on code.google.com by inder123 on 17 Jul 2008 at 12:00

GoogleCodeExporter commented 9 years ago
Woah that's really cool trick with google code hosting!

btw, do you actually do 
mvn -ff package source:jar javadoc:jar assembly:assembly deploy 
?

Original comment by antony.s...@gmail.com on 13 Aug 2008 at 12:04

GoogleCodeExporter commented 9 years ago
I'd also like to see this!

Original comment by pligh...@gmail.com on 15 Aug 2008 at 6:13

GoogleCodeExporter commented 9 years ago
There is even an easier way without the need to upload / commit manually, just 
try
the svn wagon. A working example is shown here

http://code.google.com/p/jamailia/source/browse/maven/repo/org/jamailia/jamailia
/1.0.0-SNAPSHOT/jamailia-1.0.0-SNAPSHOT.pom

Note the <distributionManagement/> and the <build/extensions/> section.

Additionally, as the deployer, you will have to add server authentication 
settings to
your ~/.m2/settings.xml similar to this:

...
<servers>
    <server>
        <id>jamailia-snapshots-maven-repo</id>
        <username>foo</username>
        <password>bar</password>
    </server>
</servers>
...

Original comment by rene.gie...@gmail.com on 19 Aug 2008 at 12:46

GoogleCodeExporter commented 9 years ago
Additional notes to my last comment: 
- the actual deployment is calling mvn clean package source:jar javadoc:jar
assembly:assembly deploy
- automatic deployment works really fine and self-contained with a CI 
environment
like Husdon etc. that way

Original comment by rene.gie...@gmail.com on 19 Aug 2008 at 12:59

GoogleCodeExporter commented 9 years ago
rene, I consider adding anything to ~/.m2/settings.xml as a big issue so we 
should
avoid that as much as possible. 

Anthony: yes, it can certainly be run that way as well. 

I am disappointed to not see any progress on this issue. Can someone from the 
Guice
team comment here why this is not being addressed? If needed, I will be happy 
to make
changes or submit a patch.  

Original comment by inder123 on 1 Sep 2008 at 3:57

GoogleCodeExporter commented 9 years ago
inder123,

I'm with you on having to configure unneeded stuff in settings.xml is bad and 
should
be avoided. However there are a couple of situations where you would find it
necessary to touch this file.

settings.xml is, among others, for providing configuration that would be 
misplaced in
the project specific configuration, such as
- workplace specific configuration, eg. chose gwt-linux installation on a linux
workstation as gwt-home, gwt-windows on a windows machine
- user specific configuration, such as user secrets / credentials

Each maven wagon (ssh, ftp etc.) with need for authentication relies on 
configuring
your credentials in settings.xml, it's a documented feature and the wanted 
behaviour.
Since there are only a couple of people having write access to the svn / being 
in the
role of a release manager, only they would need to configure those credentials,
simlilar to them locally having to configure svn write access in their svn
credentials store or IDE. 99,9999% of the users won't have configure anything 
besides
the given configuration in the pom.

Deploying in your local repository, manually identifying, copying and adding the
output to a subversion checkout and committing afterwards for each release is 
more
error prone, more steps to do and does not integrate well with automated nightly
build/ci, than simply doing a one time local configuration per workstation plus 
typing 
mvn jar source:jar javadoc:jar assembly:assembly deploy
for each deployment

Just my 2 cents,
Rene

Original comment by rene.gie...@gmail.com on 1 Sep 2008 at 5:30

GoogleCodeExporter commented 9 years ago
Just to bring this (somewhat) back on topic, is there any likelihood of seeing 
guice-servlet in the central maven 
repo any time soon?  Or do we just wait for guice 2.0?

Original comment by dom.happ...@gmail.com on 3 Oct 2008 at 8:56

GoogleCodeExporter commented 9 years ago
if its any help there's a maven repo of recent builds here...
http://code.google.com/p/guiceyfruit/wiki/Maven

Original comment by james.st...@gmail.com on 23 Oct 2008 at 12:51

GoogleCodeExporter commented 9 years ago
No guice-spring jars in there....

Where can I find guice-spring in a m2 repo?

Original comment by jpgorr...@gmail.com on 7 Dec 2008 at 1:19

GoogleCodeExporter commented 9 years ago
 Sorry misread the title 'guice-servlet and guice-struts2' too late to add
guice-spring? :)

Original comment by jpgorr...@gmail.com on 7 Dec 2008 at 1:22

GoogleCodeExporter commented 9 years ago

Original comment by limpbizkit on 31 Dec 2008 at 12:21

GoogleCodeExporter commented 9 years ago
This issue appears to be fixed:

http://repo1.maven.org/maven2/com/google/inject/integration/

Original comment by m...@j.maxb.eu on 13 Aug 2009 at 4:36

GoogleCodeExporter commented 9 years ago

Original comment by sberlin on 19 Feb 2011 at 8:35