Open GoogleCodeExporter opened 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
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
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
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
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
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
@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
@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
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
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
[deleted comment]
Original comment by gk5...@gmail.com
on 9 Feb 2009 at 11:15
@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:
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
Original issue reported on code.google.com by
erik.put...@nrc-cnrc.gc.ca
on 17 Nov 2008 at 6:54