Menu
▾
▴
javaxdelta-devel — Discussion of development issues related to javaxdelta
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(3) |
Jul
(8) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2008 |
Jan
(2) |
Feb
(2) |
Mar
(5) |
Apr
|
May
(1) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(8) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2016 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Elias R. <ge...@no...> - 2016-01-04 17:56:35
|
Hi, I'm not actively working on this project anymore. As you might have guessed given the commit logs. The Trove hash table was introduced since it is faster and uses less memory, but it's not critical. If you'd like to fork and put it on github with that change, that would be great. On Tue, Dec 29, 2015 at 4:33 AM, Andrew Hayden <and...@gm...> wrote: > Hi there, > > TLDR: Could javaxdelta just use HashMap<Long,Integer> instead of Trove's > LongIntHashMap and, if not, why? > > Longer: > I've been playing around with javaxdelta for a while and I'd like to be > able to import it into a few places without having to drag along GNU Trove > as a dependency just for these two files to use LongIntHashMap: > > > http://sourceforge.net/p/javaxdelta/code/HEAD/tree/trunk/javaxdelta/src/main/java/com/nothome/delta/Checksum.java > > http://sourceforge.net/p/javaxdelta/code/HEAD/tree/trunk/javaxdelta/src/main/java/com/nothome/delta/text/Checksum.java > > It seems like the dependency was added in r33, but there's no indication > in the commit message of why: > http://sourceforge.net/p/javaxdelta/code/33/ > > Was there a specific performance concern being addressed here for big > files with lots of chunks, or am I missing something? > > Thanks, > Andrew > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Javaxdelta-devel mailing list > Jav...@li... > https://lists.sourceforge.net/lists/listinfo/javaxdelta-devel > > |
|
From: Andrew H. <and...@gm...> - 2015-12-29 12:33:16
|
Hi there, TLDR: Could javaxdelta just use HashMap<Long,Integer> instead of Trove's LongIntHashMap and, if not, why? Longer: I've been playing around with javaxdelta for a while and I'd like to be able to import it into a few places without having to drag along GNU Trove as a dependency just for these two files to use LongIntHashMap: http://sourceforge.net/p/javaxdelta/code/HEAD/tree/trunk/javaxdelta/src/main/java/com/nothome/delta/Checksum.java http://sourceforge.net/p/javaxdelta/code/HEAD/tree/trunk/javaxdelta/src/main/java/com/nothome/delta/text/Checksum.java It seems like the dependency was added in r33, but there's no indication in the commit message of why: http://sourceforge.net/p/javaxdelta/code/33/ Was there a specific performance concern being addressed here for big files with lots of chunks, or am I missing something? Thanks, Andrew |
|
From: Alex K. <ale...@gm...> - 2012-10-16 13:33:31
|
Hello, I wrote an application using javaxdelta and want to upload my app to Maven central. With Sonatype OSS rules my app must have all it's dependencies in Maven central [1]. I can upload javaxdelta to central using my own groupId (old version of javaxdelta already exists at central with foreign groupId [2]). But it would be better (for library users) to have javaxdelta in central with the same coordinates as in SF maven repository. I can upload existed 2.0.1 binaries as a third party bundle [3] with groupId "com.nothome", but I need to confirm that I contacted original javaxdelta authors and they don't want to upload javaxdelta to central themselves as a Sonatype OSS project [4]. So, I ask for your permission to upload javaxdelta to Maven central with groupId "com.nothome". [1]: http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/ [2]: http://repo1.maven.org/maven2/org/codehaus/openxma/javaxdelta/1.1.0/ [3]: https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository [4]: https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository#Uploading3rd-partyArtifactstoTheCentralRepository-MyBundleisUploaded.WhatNext%3F -- Regards, Alex Kasko |
|
From: Elias R. <ge...@no...> - 2009-09-24 06:06:10
|
On Wed, Sep 23, 2009 at 9:38 PM, Elias Ross <ge...@no...> wrote: > I have copied your attachments and have reproduced the problem in my > sandbox. > > I'll let you know how it goes. > > Thank you very kindly for your efforts. > > I have addressed the issue. The new release is 2.0.1. Thanks! |
|
From: Elias R. <ge...@no...> - 2009-09-24 04:39:09
|
I have copied your attachments and have reproduced the problem in my sandbox. I'll let you know how it goes. Thank you very kindly for your efforts. On Wed, Sep 23, 2009 at 6:20 AM, Gruber Bernhard OSA sIT < Ber...@s-...> wrote: > I created a set of small reproducer files. > These are the smallest files I could find to reproduce the problem. > > java com.nothome.delta.Delta source.min target.min minpatch.gdiff > > Produces with the most current souces from svn an errornous patch file. > With javaxdelta 1.1.0 it produces a correct patch file. > > Here the content of both patch files in readable form: > Created with head revision > Magic: D1 FF D1 FF > Version: 04 > Command: 0F - append 15 > Data: E5 A8 C7 53 6E 79 FD 9C F8 B6 32 3B 47 37 31 > Command: 00 - EOF > > Created with Version 1.1.0 > Magic: D1 FF D1 FF > Version: 04 > Command: 10 - append 16 > Data: B5 E5 A8 C7 53 6E 79 FD 9C F8 B6 32 3B 47 37 31 > Command: 00 - EOF > > The difference is, that with the most current sources, the first byte of > the data to append is lost. > > |
|
From: Gruber B. O. s. <Ber...@s-...> - 2009-09-23 13:20:43
|
I created a set of small reproducer files. These are the smallest files I could find to reproduce the problem. java com.nothome.delta.Delta source.min target.min minpatch.gdiff Produces with the most current souces from svn an errornous patch file. With javaxdelta 1.1.0 it produces a correct patch file. Here the content of both patch files in readable form: Created with head revision Magic: D1 FF D1 FF Version: 04 Command: 0F - append 15 Data: E5 A8 C7 53 6E 79 FD 9C F8 B6 32 3B 47 37 31 Command: 00 - EOF Created with Version 1.1.0 Magic: D1 FF D1 FF Version: 04 Command: 10 - append 16 Data: B5 E5 A8 C7 53 6E 79 FD 9C F8 B6 32 3B 47 37 31 Command: 00 - EOF The difference is, that with the most current sources, the first byte of the data to append is lost. |
|
From: Gruber B. O. s. <Ber...@s-...> - 2009-09-23 07:29:45
|
Have you allready found the problem, or do you still need a small reproducer file? The Unittests in JarDeltaJarPatcherTest show the problem, too. But only if the harder longrunning tests are enabled. I can produce a small reproducer file from the faild tests. |
|
From: Torgeir V. <to...@po...> - 2009-03-10 12:27:36
|
http://www.daemonology.net/bsdiff/ It seems to use bzip2 to find deltas. In essence I figure it uses the left side file as a dictionary when traversing the right side file. Runtime is O((n+m) log n) time. -- Torgeir Veimo to...@po... |
|
From: Elias R. <ge...@no...> - 2009-01-27 17:19:01
|
http://javaxdelta.sourceforge.net/maven2/repository/com/nothome/javaxdelta/2.0.0/ On Mon, Jan 26, 2009 at 9:11 PM, Nick Crossley <nd...@nc...> wrote: > > However, it appears the 1.1 version has now completely replaced version 2.0, > so the latter is no longer available! > > I was able to test with both this 1.1 version and the previously-downloaded > 2.0 version, and my test case fails with 2.0 but passes with 1.1 - so it > does appear that this is a regression. I shall continue testing and try to > get a small test case. The current release is available through the Maven repository: I'll probably officially release 2.0.1 through the file tracker once I have this regression fixed. Thanks for your help. |
|
From: Nick C. <nd...@nc...> - 2009-01-27 05:11:42
|
Elias, Thanks for the upload of the previous version. > https://javaxdelta.svn.sourceforge.net/svnroot/javaxdelta/tags/MavenVersion_1_ > 1_0/javaxdelta/ > > contains the original version before I made any changes, built with ant. > > I also built/uploaded the older release, and you can find it on the > project page: > > https://sourceforge.net/projects/javaxdelta/ However, it appears the 1.1 version has now completely replaced version 2.0, so the latter is no longer available! I was able to test with both this 1.1 version and the previously-downloaded 2.0 version, and my test case fails with 2.0 but passes with 1.1 - so it does appear that this is a regression. I shall continue testing and try to get a small test case. Nick. |
|
From: Elias R. <ge...@no...> - 2009-01-26 19:46:47
|
Yes to both questions: https://javaxdelta.svn.sourceforge.net/svnroot/javaxdelta/tags/MavenVersion_1_1_0/javaxdelta/ contains the original version before I made any changes, built with ant. I also built/uploaded the older release, and you can find it on the project page: https://sourceforge.net/projects/javaxdelta/ On Mon, Jan 26, 2009 at 9:37 AM, Nick Crossley <nd...@nc...> wrote: > Sorry for the slow response to this - I have been away working on other > issues for a while. I am now back to work on the javaxdelta issue, and I > would like to test the regression idea. However, I see only the current > release available as a download from the sourceforge site. Is there > somewhere I can get prebuilt earlier releases, or should I just build from > source? To do the latter, is the Subversion tag MavenVersion_1_1_0 the > appropriate earlier rev? > > Nick. > |
|
From: Nick C. <nd...@nc...> - 2009-01-26 17:37:45
|
Sorry for the slow response to this - I have been away working on other issues for a while. I am now back to work on the javaxdelta issue, and I would like to test the regression idea. However, I see only the current release available as a download from the sourceforge site. Is there somewhere I can get prebuilt earlier releases, or should I just build from source? To do the latter, is the Subversion tag MavenVersion_1_1_0 the appropriate earlier rev? Nick. > Since I recently redid a lot of the code, it could be a regression. > Could you make an attempt to test an earlier version and see if the > problem is present? Also, a test case would be appreciated. > > On Thu, Jan 8, 2009 at 1:14 AM, Heiko Klein <hei...@me...> wrote: >> Hi Nick, >> >> thanks for reporting the problem. I think it would be most useful if you >> add your files and the problem to the sourceforge tracker >> https://sourceforge.net/tracker/?group_id=54817&atid=474943 (hope that >> link works). >> |
|
From: Elias R. <ge...@no...> - 2009-01-09 12:33:55
|
Since I recently redid a lot of the code, it could be a regression. Could you make an attempt to test an earlier version and see if the problem is present? Also, a test case would be appreciated. On Thu, Jan 8, 2009 at 1:14 AM, Heiko Klein <hei...@me...> wrote: > Hi Nick, > > thanks for reporting the problem. I think it would be most useful if you > add your files and the problem to the sourceforge tracker > https://sourceforge.net/tracker/?group_id=54817&atid=474943 (hope that > link works). > |
|
From: Nick C. <nd...@nc...> - 2009-01-09 05:25:19
|
As suggested, I have now raised a bug in the SourceForge tracker for the issue I mentioned yesterday. Since SourceForge would not let me attach the large files directly in the bug report, I have placed them in the public area of my .Mac/.me shared iDisk. I will continue to work on pinning down this bug myself, but probably not until the week after next or thereabouts, since I have some other things I have to get done first. I will leave the files on my iDisk until I can replace them with smaller test cases. Nick. |
|
From: Heiko K. <hei...@me...> - 2009-01-08 09:30:07
|
Hi Nick, thanks for reporting the problem. I think it would be most useful if you add your files and the problem to the sourceforge tracker https://sourceforge.net/tracker/?group_id=54817&atid=474943 (hope that link works). There is not a lot of continous development going on in javaxdelta, so I don't think somebody will jump at it immediately. You should try to reduce the scope or even find the bug. But if you don't manage, and when somebody is updating javaxdelta at a later stage, it might be good to have a critical case. Best wishes, Heiko > To introduce myself to the javaxdelta developers, my name is Nick > Crossley. > > I have just started to use javaxdelta, and I have found a pair of files > where the delta command produces a bad patch, and/or where the patch is > not correctly applied by gdiffpatcher. The end effect is that running > the patch succeeds, but produces a file that is not equal to the > original target. > > The files involved are about 7Mb. I have not yet identified if the > problem is in the delta or the patch parts, nor have I yet tried to cut > down the file size to a minimum necessary to reproduce the problem. > > Is there any interest is my providing the two files at this stage, or > not until/unless I can reduce the scope more? > > Nick. > > > -------------------------------------------------------------------- > mail2web LIVE Free email based on Microsoft® Exchange technology - > http://link.mail2web.com/LIVE > > > > ------------------------------------------------------------------------------ > Check out the new SourceForge.net Marketplace. > It is the best place to buy or sell services for > just about anything Open Source. > http://p.sf.net/sfu/Xq1LFB > _______________________________________________ > Javaxdelta-devel mailing list > Jav...@li... > https://lists.sourceforge.net/lists/listinfo/javaxdelta-devel |
|
From: <nd...@nc...> - 2009-01-07 19:58:36
|
To introduce myself to the javaxdelta developers, my name is Nick Crossley. I have just started to use javaxdelta, and I have found a pair of files where the delta command produces a bad patch, and/or where the patch is not correctly applied by gdiffpatcher. The end effect is that running the patch succeeds, but produces a file that is not equal to the original target. The files involved are about 7Mb. I have not yet identified if the problem is in the delta or the patch parts, nor have I yet tried to cut down the file size to a minimum necessary to reproduce the problem. Is there any interest is my providing the two files at this stage, or not until/unless I can reduce the scope more? Nick. -------------------------------------------------------------------- mail2web LIVE Free email based on Microsoft® Exchange technology - http://link.mail2web.com/LIVE |
|
From: Elias R. <ge...@no...> - 2008-06-19 07:21:03
|
2.0.0 is released. Some features: * Rewrite to use java.nio libraries, which should dramatically speed up processing * com.nothere.javaxdelta.text library for producing diffs for character streams * Support for variable chunk sizes * Integrated build with Maven * Improved documentation * Improved test coverage * Improved API which will allow for future expansion, if needed * Library now should work (in theory) with huge files > 2GB in length Take a look at a homepage I created: http://javaxdelta.sourceforge.net/ Code is now in SVN and there's a Maven repository: http://javaxdelta.sourceforge.net/maven2/ where you can download releases directly. I also uploaded 2.0.0 to Sourceforge. Since there were some dramatic changes, I figure calling the release "2.0.0" is appropriate. |
|
From: Torgeir V. <to...@po...> - 2008-06-04 23:12:23
|
On 5 Jun 2008, at 09:03, Elias Ross wrote: > On Wed, Jun 4, 2008 at 3:58 AM, Torgeir Veimo <to...@po...> > wrote: >> >> I was waiting for sourceforge to do the conversion. I didn't have >> the time >> to hassle them to get it done though. I guess it could be done >> manually by >> cvs2svn and svnadmin as well. > > I've done the manual conversion before. I don't think Sourceforge does > anything for you anymore. > > I'd be happy to do it for you. Ok. Can you send me your sourceforge id? >>> I created a patch for the text "diff". Look under "Tracker - >>> Patches". > There's a number of tests for the different files. The package is > "text" since "char" is a Java reserved word. > > I left off the code clean-up changes since I'd like to fix the > automated tests before I potentially break things. It seems there's > some files it needs that are missing. > > I also can't create a pom.xml until I can move the main source files > out of the project root directory. Ok. There was also a patch posted recently by Alexander Zhukov which should improve speed a bit. Can you have a look at applying that one as well? -- Torgeir Veimo to...@po... |
|
From: Elias R. <ge...@no...> - 2008-06-04 23:03:31
|
On Wed, Jun 4, 2008 at 3:58 AM, Torgeir Veimo <to...@po...> wrote: > > I was waiting for sourceforge to do the conversion. I didn't have the time > to hassle them to get it done though. I guess it could be done manually by > cvs2svn and svnadmin as well. I've done the manual conversion before. I don't think Sourceforge does anything for you anymore. I'd be happy to do it for you. >> Secondly, I'd also like to fix up the repository layout to be more >> "Maven-like". For editing, Eclipse doesn't like your directory >> structure, so it would seem wise to update it to be more >> Eclipse-friendly. I would like to keep the build.xml and create a >> Maven pom.xml as well for build integration as well. > >> Thirdly, I'd like to clean up the code. I do see a bunch of unused >> variables and junk floating around etc., though keep the public >> interface intact and compiling on JDK 1.3. There's also a number of >> potential issues where the return value from "read(byte b[] ...)" >> calls aren't checked. > >> And lastly, something I'd like to add for dealing with text strings is >> a character-based encoding for GDIFF. This is so that changes can be >> stored in a VARCHAR or CLOB type column. I would basically create a >> sub-package called "com.nothome.delta.char" which could use character >> streams. > > > All of this sounds interesting. Can you provide a patch with your > improvements? Once you've posted some code I can grant you committer access. I created a patch for the text "diff". Look under "Tracker - Patches". There's a number of tests for the different files. The package is "text" since "char" is a Java reserved word. I left off the code clean-up changes since I'd like to fix the automated tests before I potentially break things. It seems there's some files it needs that are missing. I also can't create a pom.xml until I can move the main source files out of the project root directory. |
|
From: Torgeir V. <to...@po...> - 2008-06-04 10:59:33
|
On 30 May 2008, at 09:41, Elias Ross wrote: > I'm starting work on JBoss Envers, which is a project that tracks > changes in database tables using Hibernate. > > I'm looking at being able to track changes to LOB (large objects) such > as binary files and also CLOB or large text strings. Welcome to the project. > There are a couple of things I'd like to be able to do as well. > > It looks like, according to the mail archives, you are still "waiting" > for a SVN migration from Source Forge. Could I help with this? I've > done one migration before on a project on Source Forge. See: > http://e-xml.svn.sourceforge.net/viewvc/e-xml/trunk/ I was waiting for sourceforge to do the conversion. I didn't have the time to hassle them to get it done though. I guess it could be done manually by cvs2svn and svnadmin as well. > Secondly, I'd also like to fix up the repository layout to be more > "Maven-like". For editing, Eclipse doesn't like your directory > structure, so it would seem wise to update it to be more > Eclipse-friendly. I would like to keep the build.xml and create a > Maven pom.xml as well for build integration as well. > Thirdly, I'd like to clean up the code. I do see a bunch of unused > variables and junk floating around etc., though keep the public > interface intact and compiling on JDK 1.3. There's also a number of > potential issues where the return value from "read(byte b[] ...)" > calls aren't checked. > And lastly, something I'd like to add for dealing with text strings is > a character-based encoding for GDIFF. This is so that changes can be > stored in a VARCHAR or CLOB type column. I would basically create a > sub-package called "com.nothome.delta.char" which could use character > streams. All of this sounds interesting. Can you provide a patch with your improvements? Once you've posted some code I can grant you committer access. For my own part, I don't use javaxdelta in any production project, thus it gets less of my attention that it deserves, so anyone interested to work on it are welcome. -- Torgeir Veimo to...@po... |
|
From: Elias R. <ge...@no...> - 2008-05-29 23:41:05
|
I'm starting work on JBoss Envers, which is a project that tracks changes in database tables using Hibernate. I'm looking at being able to track changes to LOB (large objects) such as binary files and also CLOB or large text strings. There are a couple of things I'd like to be able to do as well. It looks like, according to the mail archives, you are still "waiting" for a SVN migration from Source Forge. Could I help with this? I've done one migration before on a project on Source Forge. See: http://e-xml.svn.sourceforge.net/viewvc/e-xml/trunk/ Secondly, I'd also like to fix up the repository layout to be more "Maven-like". For editing, Eclipse doesn't like your directory structure, so it would seem wise to update it to be more Eclipse-friendly. I would like to keep the build.xml and create a Maven pom.xml as well for build integration as well. Thirdly, I'd like to clean up the code. I do see a bunch of unused variables and junk floating around etc., though keep the public interface intact and compiling on JDK 1.3. There's also a number of potential issues where the return value from "read(byte b[] ...)" calls aren't checked. And lastly, something I'd like to add for dealing with text strings is a character-based encoding for GDIFF. This is so that changes can be stored in a VARCHAR or CLOB type column. I would basically create a sub-package called "com.nothome.delta.char" which could use character streams. |
|
From: Torgeir V. <to...@ne...> - 2008-03-17 17:04:17
|
On 17 Mar 2008, at 15:49, Gruber Bernhard OSA SD wrote: > OK, I can do all of the work to put the jar-file into openXMAs maven > repository. > > There is only one issue open: Maven needs a version number for the > jar-file. > A date is not a valid version number for maven. > > I can take javaxdelta-2008-01-14.jar and put it as > javaxdelta-1.1.0.jar > into the repository. > Then I would put a tag called MavenVersion_1_1_0 on the sources in > CVS. Ok, I'll add you as a developer there. What is your sourceforge id? > But I would prefer to place it with the same version number in your > download area > at sourceforge, too. Will you do this, or do I have allready > sufficient > privileges on > javaxdelta project to do it myself? You can do that yourself if you like when you've got developer access on the sourceforge project. > By the way, javaxdelta-2008-01-14.jar does not contain the source > files > of the classes I > provided to you. Is this intentionally or just a mistake? Surely a mistake. Make sure to add your name to the files your working on for proper attribution. -- Torgeir Veimo to...@ne... |
|
From: Gruber B. O. S. <Ber...@s-...> - 2008-03-17 15:49:35
|
OK, I can do all of the work to put the jar-file into openXMAs maven repository. There is only one issue open: Maven needs a version number for the jar-file. A date is not a valid version number for maven. I can take javaxdelta-2008-01-14.jar and put it as javaxdelta-1.1.0.jar into the repository. Then I would put a tag called MavenVersion_1_1_0 on the sources in CVS. But I would prefer to place it with the same version number in your download area at sourceforge, too. Will you do this, or do I have allready sufficient privileges on javaxdelta project to do it myself? I can not access CVS from my PC in my office, but I can try from my private PC at home. By the way, javaxdelta-2008-01-14.jar does not contain the source files of the classes I provided to you. Is this intentionally or just a mistake? |
|
From: Torgeir V. <to...@ne...> - 2008-03-14 13:34:25
|
On 11 Mar 2008, at 16:00, Gruber Bernhard OSA SD wrote: > Our thin client framework using JavaXDelta, Open XMA goes open source > and will be soon online (see > http://xircles.codehaus.org/projects/openxma). > As we manage our libraries dependencies by the Maven dependency > mechanism it would be nice to have JavaXDelta available by Maven as > well. Agree, it would make it easier for anyone really. > There are two possibilities: > > 1: > We can host the JavaxDelta artifact at the Codehaus Maven repository > for > you (at http://repository.codehaus.org/org/codehaus/). > The Codehaus Maven repository is synchronized to the central Maven > repository . > There it would be deployed in a directory > 'org\codehaus\openxma\javaxdelta' (we are only to able to deploy it > there). Of course the Java package structure is not affected. > > 2: > Host JavaXDelta at the central Maven repository at > http://repo1.maven.org/maven2 (in a com.nothome.delta directory). > This can be done by a manual upload of the JavaxDelta artifact. We > would > be willing to do this for you, but note that this is not the > recommended > procedere: I would prefer option 1, if you'd take care of the details. I don't currently make use of javaxdelta in my work so there's hard to find time for maintenance work. -- Torgeir Veimo to...@ne... |
|
From: Gruber B. O. S. <Ber...@s-...> - 2008-03-11 16:00:46
|
Our thin client framework using JavaXDelta, Open XMA goes open source and will be soon online (see http://xircles.codehaus.org/projects/openxma). As we manage our libraries dependencies by the Maven dependency mechanism it would be nice to have JavaXDelta available by Maven as well. There are two possibilities: 1: We can host the JavaxDelta artifact at the Codehaus Maven repository for you (at http://repository.codehaus.org/org/codehaus/). The Codehaus Maven repository is synchronized to the central Maven repository . There it would be deployed in a directory 'org\codehaus\openxma\javaxdelta' (we are only to able to deploy it there). Of course the Java package structure is not affected. 2: Host JavaXDelta at the central Maven repository at http://repo1.maven.org/maven2 (in a com.nothome.delta directory). This can be done by a manual upload of the JavaxDelta artifact. We would be willing to do this for you, but note that this is not the recommended procedere: "Note that this manual process is time consuming and will only be accepted for a limited number of requests . If you want to upload frequently read the section above about automatic sync. Estimated process time is FOUR WEEKS . If you want to use the manual process, that is the estimated time to process if no problems are detected . It means that for each version you release and want to upload to the central repository you will have to wait that time. If a problem is detected it will be notified in the Jira issue and you will wait again until the next time the issues are processed." For details see http://maven.apache.org/guides/mini/guide-central-repository-upload.html Please let as know |
