google-code-export / google-guice

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

Snapshot repository for guice 2? #274

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I searched everywhere, it looks like guice is build on maven but I cannot
find anywhere a link for a snapshot repository... Is there such thing?

Original issue reported on code.google.com by erik.put...@nrc-cnrc.gc.ca on 17 Nov 2008 at 6:54

GoogleCodeExporter commented 9 years ago
No, we don't have our Maven repository setup for snapshots.

Greg, perhaps you can help with this?

Original comment by limpbizkit on 17 Nov 2008 at 11:54

GoogleCodeExporter commented 9 years ago
I'd be glad to.  I'll get on that this week.  

Original comment by gk5...@gmail.com on 18 Nov 2008 at 2:12

GoogleCodeExporter commented 9 years ago
For those, who can live with private repositories:
http://maven.kamalook.de/com/google/inject/guice/2.0-SNAPSHOT/

Original comment by sven.lin...@gmail.com on 19 Nov 2008 at 3:18

GoogleCodeExporter commented 9 years ago
Thanks sven, it does the trick. I don't know how maintains it but it would be 
nice if
the sources could be attached to the snapshot.

Original comment by erik.put...@nrc-cnrc.gc.ca on 19 Nov 2008 at 8:12

GoogleCodeExporter commented 9 years ago
As far as I see, all sources are attached. I use a CI create nightly builds and
deploy them irregular to the repository, when some new features are available.

Original comment by sven.lin...@gmail.com on 19 Nov 2008 at 9:43

GoogleCodeExporter commented 9 years ago
This might be relevant: http://code.google.com/p/google-apis-mavenized/ svn at
http://google-apis-mavenized.googlecode.com/svn/trunk/guice-mavenized/.

It is based on a svn:external based checkout of Guice which places the different
extensions into different Maven modules. This is an effort that I've been 
helping out
with and I plan to keep on working on this. 

Original comment by aquato...@gmail.com on 20 Nov 2008 at 11:01

GoogleCodeExporter commented 9 years ago
@aquatopia et al.

I have a difficult time seeing the merit of forks such as these.  As the sole 
person working on mavenizing 
google projects, I would be glad to work with contributors to get _correct_, 
authoritative metadata and 
repositories set up.  

Efforts like these just pollute the artifact pool with copies of the same 
artifacts with less-correct metadata.  In 
fact, distributing artifacts under a com.google groupId is contrary to the 
maven naming conventions 
(http://maven.apache.org/guides/mini/guide-naming-conventions.html) because it 
is _not_ a domain you 
control.

Please, please, please stop fragmenting the user base.  Contributions are 
welcome.

Original comment by gk5...@gmail.com on 21 Nov 2008 at 2:39

GoogleCodeExporter commented 9 years ago
@gk5885 

From my point of view, the purpose of this project was to create project files 
for
using Guice 2.0-snapshot in Maven projects. These project files could have then 
been
used by the Guice devs to provide Maven builds. This is in no way a repository 
with
the deployed artifacts which would as you say, pollute the artifact pool.  

The reason for the "fork" was simply to rearrange the code in such a way that it
would play a bit nicer with Maven in order to build it as a multi-module 
project.
Obviously not the nicest way to do so... :)

I simply had no idea that there was an internal effort within Google in 
Mavenizing
projects. I'm very glad to hear that and I would very much like to help you out 
with
that. So in short: how can I help? And btw: feel free to contact me.

Original comment by aquato...@gmail.com on 21 Nov 2008 at 3:27

GoogleCodeExporter commented 9 years ago
Any updates on this?
The private repository at
http://maven.kamalook.de/com/google/inject/guice/2.0-SNAPSHOT/ hasn't been 
updated
for a while...

Original comment by erik.put...@nrc-cnrc.gc.ca on 1 Dec 2008 at 5:33

GoogleCodeExporter commented 9 years ago
Also snapshot releases are created automatically every night, I have to push the
magic button to deploy them onto the mentioned repository. This disadvantage was
added by myself, because something the nightly builds are broken and maven is
actually a bit hasty when it comes to updates of snapshot dependencies. This is 
why I
choose to manually deploy snapshots.

Beside that I deployed the current guice artefact :) Just force maven, Eclipse 
or
whatever you use to update your snapshot dependencies (e.g. with "mvn -U 
install").

BR, Sven

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

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago

Original comment by gk5...@gmail.com on 9 Feb 2009 at 11:15

GoogleCodeExporter commented 9 years ago
@gk5885
"Please, please, please stop fragmenting the user base.  Contributions are 
welcome."

Here ya go...

I put this together last september to push some snapshots of Guice2 into our
company's private maven repo. I didn't package up the servlet, spring or struts2
extensions but those should not be too hard to add.

Things could be improved. If you could structure things so there is a master 
project
'guice2' and 'guice2-core','guice2-multibindings','guice2-servlet', etc below 
it,
then you could build everything from the top level using submodules. That would 
be
most easily done by restructing the source tree, something I didn't do to keep 
it
simple to update.

Also, some unit tests fail, maven refuses to package/deploy by default if you 
have
failing tests cases. Need to use -DskipTests=true to get a build packaged. 
We've been
using something built from r627 for many months now with no problems.

I'd love to see Guice2 release inlude an officially supported maven2 repo. 
(along
with packaged source & javadocs).

Original comment by mark.ren...@gmail.com on 26 Feb 2009 at 7:18

Attachments:

GoogleCodeExporter commented 9 years ago
Guice 2 is done & published into maven, and Guice 3 is setup to be easily 
mavenized (due to the poms in the project files).

Original comment by sberlin on 19 Feb 2011 at 10:06