Closed GoogleCodeExporter closed 8 years ago
Is there any way to do this without making it a maven project?
Original comment by ff...@gmx.de
on 29 Aug 2009 at 10:18
[deleted comment]
I guess not:
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
Original comment by nils.bre...@gmail.com
on 29 Aug 2009 at 3:29
Hi,
I have forked this project on github and created a Maven Project for this...
github.com/truemped/jcouchdb
Daniel
Original comment by truem...@gmail.com
on 1 Sep 2009 at 9:40
Maybe I can upload this to the maven central repository. There is only one
question:
in my repository I have recreated the SpringCouchDB... stuff because I think
these
are really useful and don't disturb anyone lying around there. So, would it be
ok if
I just publish my version?
Daniel
Original comment by truem...@gmail.com
on 1 Sep 2009 at 10:02
The maven integration doesn't look half as bad I as feared. Generally we can
switch
to that.. There are some minor dependency adjustments to be made. I think
jcouchdb
doesn't use jmock after all etc. svenson needs to be mavenized, too. And I
think we
must use another groupId.. Normally I would go for "org.jcouchdb" but the maven
site
says you need to own the domain etc.
So that means we should use "com.google.code.jcouchdb", right?
The reason I took out the spring updater was that spring seemed like a very big
depedency and the benefit from it was so small. The in-context declaration of
design
docs seemed not so brilliant in the first place with all it's intermixing of
languages and CDATA sections -- especially compared to the file system based
version
which can just as well be used from spring.
Original comment by ff...@gmx.de
on 5 Sep 2009 at 9:30
[deleted comment]
> There are some minor dependency adjustments to be made.
The only dependency that I was not able to get with Maven was the random number
generator for the unit tests. I simply used the one shipped with the JDK which
worked
fine for me.
> svenson needs to be mavenized, too
Have at look at this: http://github.com/truemped/svenson/tree/master
I think it would suffice if you simply copy the pom.xml into your source tree.
(groupId should be changed as you wrote).
Regarding the SpringUpdater I guess your points are good. But: with the file
system
based version I think you are wrong. I wrote a library for abstracting storage
from
the application and had the experience that the filebased version does not
work, if
you store the Map/Reduce files in the jar. The Spring ClassPathResource cannot
load a
directory from the jar file...
What about modularizing the project? This would mean you have a parent pom
where only
metadata is stored, a module for the core jcouchdb classes and a module for
spring
extensions. This way the spring dependencies are optional or, even better, we
could
mark them as being "provided", i.e. the user has to add the spring dependency
on his own.
If I can do anything to help you, let me know!
Original comment by truem...@gmail.com
on 5 Sep 2009 at 10:21
The issue with not being able to load from a jar is unfortunate. Maybe I should
add
jar ability to the updater. This means basically parsing all entries in the jar
file
but compared to view recreation etc this is still a cheap operation and not a
very
frequent one either.
Modularizing would definitely be the way to go if we have spring dependencies.
Just
trying to see if we can still avoid those. Personally, I'm a big fan of spring
(work
for a spring partner company, co-authored a spring book etc), but I don't want
to
have such a big dependency for jcouchdb if I can avoid it.
Original comment by ff...@gmx.de
on 5 Sep 2009 at 11:46
committed the jar based updater in r148
Original comment by ff...@gmx.de
on 12 Sep 2009 at 9:49
@truemped Can you check out the jar based updater to see if it's what you need?
Original comment by ff...@gmx.de
on 16 Sep 2009 at 10:34
Sorry for the late reply. I guess it would be fine for me.
What about the pom? I'd write one in the next days and send it to you? For
svenson as
well of course...
Daniel
Original comment by truem...@gmail.com
on 16 Sep 2009 at 11:29
I already have the poms for jcouchdb and svenson which I can clean up and send
to you guys in the next days.
But there was a problem with the mersenne-twister dependency. I couldn't find
it in any of the public
repositories. Without this I can't finalize svenson and without svenson I can't
finalize jcouchdb. Any ideas what
we can do about that? Do you probably know a repository that contains
mersenne-twister?
(Another) Daniel
Original comment by dbech...@gmail.com
on 16 Sep 2009 at 3:34
No, I did not find the mersenne-twister either. But: why can't we use the
default JDK
RNG? As far as I remember it was only used in unittests...
(theother) Daniel
Original comment by truem...@gmail.com
on 16 Sep 2009 at 3:41
That would be fine with me. If there aren't any complaints, I'd go ahead and
replace it...
Original comment by dbech...@gmail.com
on 16 Sep 2009 at 4:44
I already added a pom.xml to svenson and changed the ant task to build on copied
maven dependencies. This way svenson can be built with both maven and ant and an
source-without-dependencies archive is created from it for the releases. I hope
the
pom.xml is right the way it is now. I'm not really a fan of maven and the
simple pom
for svenson already involved more trouble than I wanted.. (Is there any way to
actually solve the commons-logging dependency issue.. maven does not offer a
debian
package like "this can replace that", does it?)
As far as the mersenne twister random is concerned, I already removed it from
svenson
Original comment by ff...@gmx.de
on 16 Sep 2009 at 5:56
The pom looks good. Could you give me more details about the commons-logging
problem? What exactly are
you trying to do?
Original comment by dbech...@gmail.com
on 16 Sep 2009 at 10:05
svenson and jcouchdb are switching to slf4j, which also offers jcl-over-slf4j
which
is basically a commons logging API impl for slf4j. there is also one for log4j,
so no
matter which API you finally want to receive log messages on, you can just add
*-over-slf4j for all other ones so that they're routed over the slf4j API to
your
logging API of choice. So when I say, e.g. I'm dependend on jcl-over-sl4j, it
basically means that I *don't* want commons-logging but except it to be routed
to
slf4j..
Original comment by ff...@gmx.de
on 16 Sep 2009 at 10:12
Alright, got it. Do you want to get rid of the commons-logging dependency
completely or do you want to be
able to switch between commons-logging and jcl-over-sl4j under certain
circumstances?
Original comment by dbech...@gmail.com
on 16 Sep 2009 at 10:24
this is mostly just an issue for the tests, because compile is only dependent
on the
slf4j API. and I was wondering what this means for apps using jcouchdb etc
Original comment by ff...@gmx.de
on 16 Sep 2009 at 10:26
I suppose in order to log entries, that are logged via SLF4J, they would need
to add the appropriate SLF4J binding
to redirect those entries to their preferred logging framework. Otherwise those
events would just be silently
dropped. That binding stuff sounds actually pretty cool. I should give SLF4J a
try for one of my future projects.
I'll open a ticket with an attached patch for the svenson pom.xml later...
Original comment by dbech...@gmail.com
on 16 Sep 2009 at 11:00
I merged my local pom with your changes from the svenson pom. I only had a few
minutes, since I have to catch
my plane to Germany soon, but this pom seems to work pretty well. Let me know
if it works on your machine as
well. Hope that helps!
Original comment by dbech...@gmail.com
on 17 Sep 2009 at 8:03
Attachments:
Added the pom.xml with some changes.
(it's "properties" not "proerties". Same error in the svenson pom)
@truemped
I've removed the spring dependency for now. Are the changes for the
JarBasedCouchDBUpdater enough for you to allow that permantly?
Original comment by ff...@gmx.de
on 21 Sep 2009 at 7:43
Yeah! Looks perfect for me! Thanks a lot!
Original comment by truem...@gmail.com
on 22 Sep 2009 at 8:59
Well.. this looks like we're mostly ready for a new double release of mavenized
jouchdb / svenson..
Original comment by ff...@gmx.de
on 22 Sep 2009 at 9:49
The new releases have been copied to my server and should be available in maven
soon,
if my rsynch request is followed.
Original comment by ff...@gmx.de
on 26 Sep 2009 at 3:46
Very cool!
Original comment by dbech...@gmail.com
on 26 Sep 2009 at 3:50
( http://jira.codehaus.org/browse/MAVENUPLOAD-2615 )
Original comment by ff...@gmx.de
on 28 Sep 2009 at 6:43
In the mean time... Can someone of you access http://fforw.de/m2repo/ as
repository?
Original comment by ff...@gmx.de
on 14 Oct 2009 at 9:36
Works like a charm:
<repositories>
<repository>
<id>de.fforw.releases</id>
<url>http://fforw.de/m2repo/releases/</url>
<releases>
<enabled>true</enabled>
<checksumPolicy>warn</checksumPolicy>
<updatePolicy>never</updatePolicy>
</releases>
<snapshots>
<enabled>false</enabled>
<checksumPolicy>warn</checksumPolicy>
<updatePolicy>always</updatePolicy>
</snapshots>
</repository>
<repository>
<id>de.fforw.snapshots</id>
<url>http://fforw.de/m2repo/snapshots/</url>
<releases>
<enabled>false</enabled>
<checksumPolicy>warn</checksumPolicy>
<updatePolicy>never</updatePolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<checksumPolicy>warn</checksumPolicy>
<updatePolicy>always</updatePolicy>
</snapshots>
</repository>
</repositories>
One more thing would be nice: Could you deploy the projects using the property
"-DperformRelease=true"?
This will cause Maven to add JARs containing the sources and JavaDocs to the
repository, which will be
automatically downloaded and used by most IDEs. (Or can be manually downloaded
by using "mvn
dependency:sources")
Original comment by dbech...@gmail.com
on 14 Oct 2009 at 2:17
done..
does this mean I can stop offering maven source downloads via google code web?
the less downloads hassle the better..
(is there a script to ease that ?)
Original comment by ff...@gmx.de
on 14 Oct 2009 at 7:03
Yes, that should be fine. The JARs are completely independent of Maven. The
only thing is, that tests are not
automatically included, but it's pretty easy to also generate a test jar by
adding this to the pom.xml:
http://maven.apache.org/guides/mini/guide-attached-tests.html
What exactly do you want a script for? To post the latest download links to the
page?
Original comment by dbech...@gmail.com
on 14 Oct 2009 at 7:18
post two downloads per jcouchdb and svenson, properly tag them and deprecate
the old ones
Original comment by ff...@gmx.de
on 14 Oct 2009 at 7:57
This looks promising: http://code.google.com/p/maven-googlecode/
Original comment by dbech...@gmail.com
on 14 Oct 2009 at 8:07
http://jira.codehaus.org/browse/MAVENUPLOAD-2615
Sorry, I'm not going to change my SSH port back.. bad enough that I had to
publish it..
Original comment by ff...@gmx.de
on 23 Oct 2009 at 6:30
They say they have fixed the sync issue with port. Can someone confirm this?
Original comment by ff...@gmx.de
on 14 Feb 2010 at 4:38
[deleted comment]
Hey guys, I have read the thread and I added this to my project:
<dependency>
<groupId>com.google.code.jcouchdb</groupId>
<artifactId>jcouchdb</artifactId>
<version>0.11.0-1</version>
</dependency>
It seems it works. Can you please confirm and add that in documentation please?
:)
Thanks, keep up the amazing work!
Original comment by vojtech.hordejcuk
on 4 Aug 2010 at 9:21
Yes, now that we're finally synced it's enough to do what you wrote for
jcouchdb and
<dependency>
<groupId>com.google.code.svenson</groupId>
<artifactId>svenson</artifactId>
<version>1.3.7</version>
<type>jar</type>
</dependency>
for svenson alone.
Original comment by ff...@gmx.de
on 4 Aug 2010 at 9:30
I close this now. If anyone has problems, reopen this.
Original comment by ff...@gmx.de
on 4 Aug 2010 at 9:30
Original issue reported on code.google.com by
nils.bre...@gmail.com
on 12 Aug 2009 at 1:01