search

nlight-jdev / jcouchdb

Automatically exported from code.google.com/p/jcouchdb
Other
0 stars 0 forks source link

Publish to Maven repository #18

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
It would be very nice if jcouchdb was available from a Maven repository for
easy integration in Maven projects.

Original issue reported on code.google.com by nils.bre...@gmail.com on 12 Aug 2009 at 1:01

GoogleCodeExporter commented 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

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 

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

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
> 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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
committed the jar based updater in r148

Original comment by ff...@gmx.de on 12 Sep 2009 at 9:49

GoogleCodeExporter commented 8 years ago 
@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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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:

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
Yeah! Looks perfect for me! Thanks a lot!

Original comment by truem...@gmail.com on 22 Sep 2009 at 8:59

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
Very cool!

Original comment by dbech...@gmail.com on 26 Sep 2009 at 3:50

GoogleCodeExporter commented 8 years ago 
( http://jira.codehaus.org/browse/MAVENUPLOAD-2615 )

Original comment by ff...@gmx.de on 28 Sep 2009 at 6:43

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
This looks promising: http://code.google.com/p/maven-googlecode/

Original comment by dbech...@gmail.com on 14 Oct 2009 at 8:07

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
I close this now. If anyone has problems, reopen this.

Original comment by ff...@gmx.de on 4 Aug 2010 at 9:30