Menu
▾
▴
exist-development — eXist Developer's List
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(22) |
Nov
(85) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(47) |
Feb
(127) |
Mar
(268) |
Apr
(78) |
May
(47) |
Jun
(38) |
Jul
(131) |
Aug
(221) |
Sep
(187) |
Oct
(54) |
Nov
(111) |
Dec
(84) |
| 2011 |
Jan
(152) |
Feb
(106) |
Mar
(94) |
Apr
(90) |
May
(53) |
Jun
(20) |
Jul
(24) |
Aug
(37) |
Sep
(32) |
Oct
(70) |
Nov
(22) |
Dec
(15) |
| 2012 |
Jan
(33) |
Feb
(110) |
Mar
(24) |
Apr
(1) |
May
(11) |
Jun
(8) |
Jul
(12) |
Aug
(37) |
Sep
(39) |
Oct
(81) |
Nov
(38) |
Dec
(50) |
| 2013 |
Jan
(23) |
Feb
(53) |
Mar
(23) |
Apr
(5) |
May
(19) |
Jun
(16) |
Jul
(16) |
Aug
(9) |
Sep
(21) |
Oct
(1) |
Nov
(2) |
Dec
(8) |
| 2014 |
Jan
(16) |
Feb
(6) |
Mar
(27) |
Apr
(1) |
May
(10) |
Jun
(1) |
Jul
(4) |
Aug
(10) |
Sep
(19) |
Oct
(22) |
Nov
(4) |
Dec
(6) |
| 2015 |
Jan
(3) |
Feb
(6) |
Mar
(9) |
Apr
|
May
(11) |
Jun
(23) |
Jul
(14) |
Aug
(10) |
Sep
(10) |
Oct
(9) |
Nov
(18) |
Dec
(4) |
| 2016 |
Jan
(5) |
Feb
(5) |
Mar
|
Apr
(2) |
May
(15) |
Jun
(2) |
Jul
(8) |
Aug
(2) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
(2) |
Feb
(12) |
Mar
(22) |
Apr
(6) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(5) |
Oct
(2) |
Nov
|
Dec
|
| 2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
(3) |
Aug
|
Sep
(7) |
Oct
(19) |
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Joern T. <joe...@go...> - 2010-08-16 11:28:42
|
On Sun, Aug 15, 2010 at 9:22 PM, Dannes Wessels <da...@ex...> wrote: > Hi, > I have some thoughts on what we can improve the betterforms integration: > (1) Split build and install > If a rebuild of exist is performed, the betterform scrips actually block > this action: > [xslt] betterFORM is allready installed. Please run 'ant uninstall' > before installing it again > [xslt] Failed to process > /Users/wessels/Development/eXist-db/Contrib/Betterforms/webapp/WEB-INF/web.xml > Better is to provide instructions to do this install manually: > ./build.sh -f extensions/betterform/build.xml install > ./build.sh -f extensions/betterform/build.xml uninstall Think this is solved by Wolfgangs change to the build.xml > (2) Remove jars from lib/user > -rw-r--r-- 1 wessels staff 261809 Aug 15 20:37 commons-lang-2.4.jar > move to lib/optional , remove ancient version from cocoon, start.config > needs to be updated > -rw-r--r-- 1 wessels staff 502402 Aug 15 20:37 dwr-2.0.5.jar > can stay here.... Just to clarify: we have agreed that libs that are only used by betterFORM should go to extensions/betterform lib directory. So, if commons-lang is not used elsewhere in eXist we would move it there. The same is true for the DWR lib. > -rw-r--r-- 1 wessels staff 203035 Aug 15 20:37 ehcache-1.6.2.jar > for this one I need to think what to do (experiment) At least we need to get > rid of the following message in stdout: > Aug 15, 2010 9:09:17 PM net.sf.ehcache.Cache <init> > WARNING: An API change between ehcache-1.1 and ehcache-1.2 results in the > persistence path being set to > /Users/wessels/Development/eXist-db/Contrib/Betterforms/tools/jetty/work/Jetty_0_0_0_0_8080_webapp__exist__.8xgt21/cocoon-files/cache-dir/ > when the ehcache-1.1 constructor is used. Please change to the 1.2 > constructor. This should go away when Cocoon is removed. > Logging already initialized. Skipping... > (3) log4j > In std out there are many messages like > log4j:ERROR Attempted to append to closed appender named [exist.core]. > This is clearly caused due to a 2nd time initialization of log4j. We must > think of a way preventing log4j to initialize by the betterform code. At the moment we still have our own log4j.xml in WEB-INF. This should be removed. Please direct us to the right location to add our debugging. > (4) Saxon > It became clear that we have some issues with the newest saxon jar files. In > november I found out about a work around, i'd like to propose to follow the > work around: install saxon in lib/user [for this we have already an > excellent download task], remove all lib/endorsed/saxon*jar files. If we > decide to install saxon into the exist-db distribution [adam] this download > code can be removed. Would be nice to have a decision here - i have conflicting opinions about that at the moment. The last statement i remember was that Saxon is in lib/endorsed. If that is changed we need to know about that as our build relies on XSLT2 > Under all conditions, LICENSE.txt files are required for all jar files (the > ones that are *in* the exist svn) yes. Joern > > > Kind regards > Dannes > -- > eXist-db Native XML Database - http://exist-db.org > Join us on linked-in: http://www.linkedin.com/groups?gid=35624 > > > > > > > > |
|
From: Dmitriy S. <sha...@gm...> - 2010-08-16 06:19:39
|
On Sun, 2010-08-15 at 21:09 +0200, Wolfgang Meier wrote: > >> There are more changes to come soon, so I would not upgrade just yet. > >> Once the new pluggable security realms are in place, we'll provide an > >> automatic migration path. > > > > OK....I'll hold off for a while. How soon is soon? > > Dmitryi has just submitted a patch for review which will be applied > once we could study it. I think there will be more changes after that, > but hopefully not too many. Dmitryi can probably say more. I want to stabilize changes this week, waiting for core team reviews. -- Cheers, Dmitriy Shabanov |
|
From: Dannes W. <da...@ex...> - 2010-08-15 20:42:08
|
for more details see recent trunk: http://localhost:8080/exist/devguide_manifesto.xml#d20e504 On 15 Aug 2010, at 21:52 , Dannes Wessels wrote: > I'd like to remember all committers to think of the developers manifesto when committing code.... > > - always run the junit test suite before commiting > > but we MUST think of switching on all dependancies..... > > - switch on the spatial index > - switch on ALL extensions in extensions/local.build.properties (except the oracle thing) > > only when you do this, you can be sure you do not break anything...... Kind regards Dannes -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
|
From: Dannes W. <da...@ex...> - 2010-08-15 19:53:01
|
All, I'd like to remember all committers to think of the developers manifesto when committing code.... - always run the junit test suite before commiting but we MUST think of switching on all dependancies..... - switch on the spatial index - switch on ALL extensions in extensions/local.build.properties (except the oracle thing) only when you do this, you can be sure you do not break anything...... Kind regards Dannes -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
|
From: Wolfgang M. <wol...@ex...> - 2010-08-15 19:50:07
|
> (1) Split build and install > If a rebuild of exist is performed, the betterform scrips actually block > this action: > [xslt] betterFORM is allready installed. Please run 'ant uninstall' > before installing it again > [xslt] Failed to process I temporarily fixed this by having the ant script check for webapp/betterform. See http://exist.svn.sourceforge.net/exist/?rev=12422&view=rev I think we can leave it like this unless there are objections. Wolfgang |
|
From: Dannes W. <da...@ex...> - 2010-08-15 19:22:52
|
Hi,
I have some thoughts on what we can improve the betterforms integration:
(1) Split build and install
If a rebuild of exist is performed, the betterform scrips actually block this action:
[xslt] betterFORM is allready installed. Please run 'ant uninstall' before installing it again
[xslt] Failed to process /Users/wessels/Development/eXist-db/Contrib/Betterforms/webapp/WEB-INF/web.xml
Better is to provide instructions to do this install manually:
./build.sh -f extensions/betterform/build.xml install
./build.sh -f extensions/betterform/build.xml uninstall
(2) Remove jars from lib/user
-rw-r--r-- 1 wessels staff 261809 Aug 15 20:37 commons-lang-2.4.jar
move to lib/optional , remove ancient version from cocoon, start.config needs to be updated
-rw-r--r-- 1 wessels staff 502402 Aug 15 20:37 dwr-2.0.5.jar
can stay here....
-rw-r--r-- 1 wessels staff 203035 Aug 15 20:37 ehcache-1.6.2.jar
for this one I need to think what to do (experiment) At least we need to get rid of the following message in stdout:
Aug 15, 2010 9:09:17 PM net.sf.ehcache.Cache <init>
WARNING: An API change between ehcache-1.1 and ehcache-1.2 results in the persistence path being set to /Users/wessels/Development/eXist-db/Contrib/Betterforms/tools/jetty/work/Jetty_0_0_0_0_8080_webapp__exist__.8xgt21/cocoon-files/cache-dir/ when the ehcache-1.1 constructor is used. Please change to the 1.2 constructor.
Logging already initialized. Skipping...
(3) log4j
In std out there are many messages like
log4j:ERROR Attempted to append to closed appender named [exist.core].
This is clearly caused due to a 2nd time initialization of log4j. We must think of a way preventing log4j to initialize by the betterform code.
(4) Saxon
It became clear that we have some issues with the newest saxon jar files. In november I found out about a work around, i'd like to propose to follow the work around: install saxon in lib/user [for this we have already an excellent download task], remove all lib/endorsed/saxon*jar files. If we decide to install saxon into the exist-db distribution [adam] this download code can be removed.
Under all conditions, LICENSE.txt files are required for all jar files (the ones that are *in* the exist svn)
Kind regards
Dannes
--
eXist-db Native XML Database - http://exist-db.org
Join us on linked-in: http://www.linkedin.com/groups?gid=35624
|
|
From: Wolfgang M. <wol...@ex...> - 2010-08-15 19:09:18
|
>> There are more changes to come soon, so I would not upgrade just yet. >> Once the new pluggable security realms are in place, we'll provide an >> automatic migration path. > > OK....I'll hold off for a while. How soon is soon? Dmitryi has just submitted a patch for review which will be applied once we could study it. I think there will be more changes after that, but hopefully not too many. Dmitryi can probably say more. Wolfgang |
|
From: Andrzej J. T. <an...@ch...> - 2010-08-15 18:45:16
|
Wolfgang: > There are more changes to come soon, so I would not upgrade just yet. > Once the new pluggable security realms are in place, we'll provide an > automatic migration path. OK....I'll hold off for a while. How soon is soon? Just curious so I can plan to test when it's ready. Thanks! -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Wolfgang M. <wol...@ex...> - 2010-08-15 14:42:55
|
> Is there a migration process for an existing database that needs to be performed to get the latest SVN revisions to work > correctly? There are more changes to come soon, so I would not upgrade just yet. Once the new pluggable security realms are in place, we'll provide an automatic migration path. Wolfgang |
|
From: Andrzej J. T. <an...@ch...> - 2010-08-15 13:12:49
|
Hi guys! I tried to upgrade to latest SVN yesterday (last build I am currently using is from late July), but many parts of our application were failing or acting strangely when I did this. I suspect that security constraints are causing all the trouble. Reverting to a revision from a few weeks ago seems to fix everything. Is there a migration process for an existing database that needs to be performed to get the latest SVN revisions to work correctly? Thanks! -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Joern T. <joe...@go...> - 2010-08-13 15:25:50
|
Thomas, we got no problem to be an extension. And i think it's also already decided that there should be an opt out. Joern On Fri, Aug 13, 2010 at 4:58 PM, Thomas White <tho...@gm...> wrote: > Dear group, > > I do not know if eXist team has made its final decision to make BetterForms > part of the core code instead of being an extension, but I decided speak up > and add one more perspective to the case. > > In large scale projects like eXist there are always two opposite tendencies: > 1. Keep the core lean and use a mechanism like extensions to allow > developers to pick and choose only what they need. This model allows > unlimited flexability. > 2. Add more and more to the core believing the more the better. > > I strongly believe that keeping the core as light as possible is always a > good thing - it is easier to maintain, it is more stable and it has a small > footprint. > > For everybody else who is not interested in using XForm, this code located > in the core will be just dormant megabites (7000+ files, 40Mb at the > moment) that are never used but always installed and dragged around. > An example for this approach is Cocoon. Long time ago become clear it is not > used by the community any more and it is still part of the core. (no > judgement, just an example) > > I do not think that if a code is made as an extension module it makes it > less useful or diminishes its value in any way. It is just much easier to > opt out. > > Having said all this I would like to stress the fact that I respect and > appreciate the work Betterform team has done. > > Regards, > Thomas > ------ > > Thomas White > > Mobile:+44 7711 922 966 > Skype: thomaswhite > gTalk: thomas.0007 > Linked-In:http://www.linkedin.com/in/thomaswhite0007 > facebook: http://www.facebook.com/thomas.0007 > |
|
From: Dmitriy S. <sha...@gm...> - 2010-08-13 15:06:53
|
On Fri, 2010-08-13 at 15:58 +0100, Thomas White wrote: > I do not know if eXist team has made its final decision to make > BetterForms part of the core code instead of being an extension, but I > decided speak up and add one more perspective to the case. Be extension mean be eXist, IMHO -- Cheers, Dmitriy Shabanov |
|
From: Thomas W. <tho...@gm...> - 2010-08-13 14:58:55
|
Dear group, I do not know if eXist team has made its final decision to make BetterForms part of the core code instead of being an extension, but I decided speak up and add one more perspective to the case. In large scale projects like eXist there are always two opposite tendencies: 1. Keep the core lean and use a mechanism like extensions to allow developers to pick and choose only what they need. This model allows unlimited flexability. 2. Add more and more to the core believing the more the better. I strongly believe that keeping the core as light as possible is always a good thing - it is easier to maintain, it is more stable and it has a small footprint. For everybody else who is not interested in using XForm, this code located in the core will be just dormant megabites (7000+ files, 40Mb at the moment) that are never used but always installed and dragged around. An example for this approach is Cocoon. Long time ago become clear it is not used by the community any more and it is still part of the core. (no judgement, just an example) I do not think that if a code is made as an extension module it makes it less useful or diminishes its value in any way. It is just much easier to opt out. Having said all this I would like to stress the fact that I respect and appreciate the work Betterform team has done. Regards, Thomas ------ Thomas White Mobile:+44 7711 922 966 Skype: thomaswhite gTalk: thomas.0007 Linked-In:http://www.linkedin.com/in/thomaswhite0007 facebook: http://www.facebook.com/thomas.0007 |
|
From: Joern T. <joe...@go...> - 2010-08-13 14:04:08
|
Wolfgang, can i take your statements below as a decision for the way we should go for now? And, have i understood right that Dannes is now the guy to coordinate with? On Thu, Aug 12, 2010 at 7:27 PM, Wolfgang Meier <wol...@ex...> wrote: >> Sorry for the conflicting statements, even the core-dev's have >> different ideas - hence this eXist development mailing list. For the >> time being it really does not matter where you put them as long as it >> works, right ;-) > > Sure, it's not a problem to move some jars around. > >> But when it comes to tidying up then following existing convention >> extensions/betterform/lib would seem the right place IMHO - but I have >> no idea how this translates at runtime i.e. will they be available on >> the classpath? I just dont know! > > Even if we enable betterform by default in the distribution, it would > still be good to make it easy for people to disable it and remove the > jars they don't need. I think the general convention should thus be: > > lib/extensions - contains eXist extension code i assume this dir is then not relevant for us > extension/.../lib - contains libraries an extension depends on ok, so we move back to where we started ;) > > We followed this convention for the Lucene as well as the spatial > extensions.I would thus suggest to put your libs into > extensions/betterform/lib, except for those libraries needed by other > parts of eXist as well (saxon should go into lib/endorsed). The > classloader is not a problem: you can extend > src/org/exist/start/start.config to load jars form > extensions/betterform/lib by default. It's not a problem if the jars > are not found. Yes, of course we don't add libs that are already present. Hope we can quickly upgrade to Saxon 9.1.0.8. Got a problem with that yesterday but now it's compiling again and also our unit-tests run. So i hope that gets commited in the next days. Please let me know if you find issues with the XFormsFilter configured after XQueryURLRewrite. We'll test that for ourselves but anyway - more eyes see more. > > Wolfgang > |
|
From: Joern T. <joe...@go...> - 2010-08-13 13:54:26
|
James, On Thu, Aug 12, 2010 at 7:53 PM, James Fuller <jam...@ex...> wrote: > sorry, just picking up this thread (was doing Other Stuff) and I make > my apologies to Joern, don't worry. At least we have learned something about eXist ;) No, seriously - we are long enough in open source ourselves to know such situations. best, Joern > > a few thoughts: > > I) Joern (and people in the future) should have a single point of > contact when integrating, I made the decision to limit the integration > as much as possible to get betterforms working then we could all > analysis and play with before going towards full integration. > > II) Whilst everyone pitching in is useful it can sometimes be > unhelpful; Dannes & Wolf I did offer my help to assist Joern in > integrating and whilst I understand you want things done correctly, I > don't understand why you didn't check with me first where we were at. > > III) open source development is by its nature messy > > In the interest that things are clear from here on out, Joern please > liaison with Dannes from here on out. > > I very much look forward to seeing betterforms integrated into eXist > and apologies once again if I caused any confusion! > > cau, J > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > |
|
From: James F. <jam...@ex...> - 2010-08-12 19:35:39
|
thx ... all cool, and yes I think betterforms is good software ... note I am now building a 'web testing' suite I mentioned about sometime ago (for higher level functional testing of web pages/forms) using xproc e.g. to test stuff like web forms, gonna point it at betterforms examples as my starting test case ;) J |
|
From: Wolfgang M. <wol...@ex...> - 2010-08-12 19:12:12
|
> II) Whilst everyone pitching in is useful it can sometimes be > unhelpful; Dannes & Wolf I did offer my help to assist Joern in > integrating and whilst I understand you want things done correctly, I > don't understand why you didn't check with me first where we were at. Sorry about that. As you said, the first goal is to get betterform up and running with eXist. I think Dannes - being the one who does most of the maintenance stuff - just wanted to give some hints on how things could be arranged and I tried to step in to clarify it. It's not important at all. James, please excuse if our attempts caused more confusion and were not helpful. This certainly isn't our intention. In an open source project, it is important that someone takes initiative and everyone supports that. I'm extremely happy to see how well betterform works. I tried to write some forms yesterday and it's straightforward. Wolfgang |
|
From: James F. <jam...@ex...> - 2010-08-12 17:53:19
|
sorry, just picking up this thread (was doing Other Stuff) and I make my apologies to Joern, a few thoughts: I) Joern (and people in the future) should have a single point of contact when integrating, I made the decision to limit the integration as much as possible to get betterforms working then we could all analysis and play with before going towards full integration. II) Whilst everyone pitching in is useful it can sometimes be unhelpful; Dannes & Wolf I did offer my help to assist Joern in integrating and whilst I understand you want things done correctly, I don't understand why you didn't check with me first where we were at. III) open source development is by its nature messy In the interest that things are clear from here on out, Joern please liaison with Dannes from here on out. I very much look forward to seeing betterforms integrated into eXist and apologies once again if I caused any confusion! cau, J |
|
From: Wolfgang M. <wol...@ex...> - 2010-08-12 17:27:13
|
> Sorry for the conflicting statements, even the core-dev's have > different ideas - hence this eXist development mailing list. For the > time being it really does not matter where you put them as long as it > works, right ;-) Sure, it's not a problem to move some jars around. > But when it comes to tidying up then following existing convention > extensions/betterform/lib would seem the right place IMHO - but I have > no idea how this translates at runtime i.e. will they be available on > the classpath? I just dont know! Even if we enable betterform by default in the distribution, it would still be good to make it easy for people to disable it and remove the jars they don't need. I think the general convention should thus be: lib/extensions - contains eXist extension code extension/.../lib - contains libraries an extension depends on We followed this convention for the Lucene as well as the spatial extensions.I would thus suggest to put your libs into extensions/betterform/lib, except for those libraries needed by other parts of eXist as well (saxon should go into lib/endorsed). The classloader is not a problem: you can extend src/org/exist/start/start.config to load jars form extensions/betterform/lib by default. It's not a problem if the jars are not found. Wolfgang |
|
From: Evgeny G. <gaz...@gm...> - 2010-08-12 15:36:11
|
2010/8/12 Dmitriy Shabanov <sha...@gm...>: > On Thu, 2010-08-12 at 16:31 +0200, Joern Turner wrote: >> Ok - don't worry - managed to make our code compile again against 9.1.0.8 >> > > BTW, I'll try to make eXist's xslt engine to do a job for your staff, as > soon as get time for it. > I'd tested XSLT extensions with simplest XML (one element) and simplest XSL (one dummy template). And like one have a problem with LF/RF symbols. Can try to night and say more details. -- Evgeny |
|
From: Adam R. <ad...@ex...> - 2010-08-12 15:00:00
|
On 12 August 2010 15:55, Joern Turner <joe...@go...> wrote: > On Thu, Aug 12, 2010 at 4:40 PM, Adam Retter <ad...@ex...> wrote: >> On 12 August 2010 13:48, Joern Turner <joe...@go...> wrote: >>> On Thu, Aug 12, 2010 at 2:46 PM, Adam Retter <ad...@ex...> wrote: >>>>> At least James said Cocoon will be removed. We initially put the >>>>> cocoon lib into our uninstall dir but skipped that after James' >>>>> statement. >>> We do not depend on it. We just depend on ehcache in a newer version >>> that cocoon also uses. >>> >>>> >>>> Cocoon is now an extension, so you should not depend on it - I would >>>> recommend putting libs you need into lib/optional as you are >>>> practically a core part of eXist now, i.e. you are not an extension - >>>> or do I have that wrong? >>> i fear yes ;) As a first step we are an extension. >> >> Okay perhaps a extension/betterForm/lib would work for you? I see that >> the cocoon extension does this also? > Of course that will work for us - the problem at the moment is that we > followed the suggestions of James who guided the first step of > integration. He suggested to put the lib in lib/user. We can put them > anywhere but at the moment we get several varying statements from > different people in the team. > > it would be great if that can get coordinated somehow and we will > happily follow that path. The question is maybe where we are heading. > Tighter integration (what would THAT mean in term of locating our > sources and libs), an expath extension, an extension as it is ... > > Don't get me wrong: i'm not nerved or something but it would be good > if someone of the core eXist developers would get the hat on to guide > us (thought that was James). We are surely not the experts for core > eXist dev and where its heading. Sorry for the conflicting statements, even the core-dev's have different ideas - hence this eXist development mailing list. For the time being it really does not matter where you put them as long as it works, right ;-) But when it comes to tidying up then following existing convention extensions/betterform/lib would seem the right place IMHO - but I have no idea how this translates at runtime i.e. will they be available on the classpath? I just dont know! > Anyway, we are happy about the integration and becoming a part of the > great eXist community. > > Suggestions welcome. > >> >>> >>>> >>>>>> >>>>>> trunk/eXist/lib/user/saxon-9.0.jar >>>>>> trunk/eXist/lib/user/saxon-dom-9.0.jar >>>>>> >>>>>> Saxon jars should go in the endorsed directory, for the HE version only one >>>>>> jar file is required. Would that work for betterforms> >>>>>> the purpose of lib/user is to allow endusers to add new jar files. Other >>>>>> files should go to lib/optional. >>>>>> last: please add LICENSE.txt files for each jar file you add (see all other >>>>>> jar files). WIth this we can estimate whether the license actually allows us >>>>>> to include that jar file. >>>>> Will do. >>>>> >>>>> Cheers, >>>>> >>>>> Joern >>>>> >>>>> >>>>>> Kind regards >>>>>> Dannes >>>>>> -- >>>>>> eXist-db Native XML Database - http://exist-db.org >>>>>> Join us on linked-in: http://www.linkedin.com/groups?gid=35624 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> This SF.net email is sponsored by >>>>>> >>>>>> Make an app they can't live without >>>>>> Enter the BlackBerry Developer Challenge >>>>>> http://p.sf.net/sfu/RIM-dev2dev >>>>>> _______________________________________________ >>>>>> Exist-development mailing list >>>>>> Exi...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/exist-development >>>>>> >>>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> This SF.net email is sponsored by >>>>> >>>>> Make an app they can't live without >>>>> Enter the BlackBerry Developer Challenge >>>>> http://p.sf.net/sfu/RIM-dev2dev >>>>> _______________________________________________ >>>>> Exist-development mailing list >>>>> Exi...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/exist-development >>>>> >>>> >>>> >>>> >>>> -- >>>> Adam Retter >>>> >>>> eXist Developer >>>> { United Kingdom } >>>> ad...@ex... >>>> irc://irc.freenode.net/existdb >>>> >>> >> >> >> >> -- >> Adam Retter >> >> eXist Developer >> { United Kingdom } >> ad...@ex... >> irc://irc.freenode.net/existdb >> > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
|
From: Joern T. <joe...@go...> - 2010-08-12 14:55:14
|
On Thu, Aug 12, 2010 at 4:40 PM, Adam Retter <ad...@ex...> wrote: > On 12 August 2010 13:48, Joern Turner <joe...@go...> wrote: >> On Thu, Aug 12, 2010 at 2:46 PM, Adam Retter <ad...@ex...> wrote: >>>> At least James said Cocoon will be removed. We initially put the >>>> cocoon lib into our uninstall dir but skipped that after James' >>>> statement. >> We do not depend on it. We just depend on ehcache in a newer version >> that cocoon also uses. >> >>> >>> Cocoon is now an extension, so you should not depend on it - I would >>> recommend putting libs you need into lib/optional as you are >>> practically a core part of eXist now, i.e. you are not an extension - >>> or do I have that wrong? >> i fear yes ;) As a first step we are an extension. > > Okay perhaps a extension/betterForm/lib would work for you? I see that > the cocoon extension does this also? Of course that will work for us - the problem at the moment is that we followed the suggestions of James who guided the first step of integration. He suggested to put the lib in lib/user. We can put them anywhere but at the moment we get several varying statements from different people in the team. it would be great if that can get coordinated somehow and we will happily follow that path. The question is maybe where we are heading. Tighter integration (what would THAT mean in term of locating our sources and libs), an expath extension, an extension as it is ... Don't get me wrong: i'm not nerved or something but it would be good if someone of the core eXist developers would get the hat on to guide us (thought that was James). We are surely not the experts for core eXist dev and where its heading. Anyway, we are happy about the integration and becoming a part of the great eXist community. Suggestions welcome. > >> >>> >>>>> >>>>> trunk/eXist/lib/user/saxon-9.0.jar >>>>> trunk/eXist/lib/user/saxon-dom-9.0.jar >>>>> >>>>> Saxon jars should go in the endorsed directory, for the HE version only one >>>>> jar file is required. Would that work for betterforms> >>>>> the purpose of lib/user is to allow endusers to add new jar files. Other >>>>> files should go to lib/optional. >>>>> last: please add LICENSE.txt files for each jar file you add (see all other >>>>> jar files). WIth this we can estimate whether the license actually allows us >>>>> to include that jar file. >>>> Will do. >>>> >>>> Cheers, >>>> >>>> Joern >>>> >>>> >>>>> Kind regards >>>>> Dannes >>>>> -- >>>>> eXist-db Native XML Database - http://exist-db.org >>>>> Join us on linked-in: http://www.linkedin.com/groups?gid=35624 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> This SF.net email is sponsored by >>>>> >>>>> Make an app they can't live without >>>>> Enter the BlackBerry Developer Challenge >>>>> http://p.sf.net/sfu/RIM-dev2dev >>>>> _______________________________________________ >>>>> Exist-development mailing list >>>>> Exi...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/exist-development >>>>> >>>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.net email is sponsored by >>>> >>>> Make an app they can't live without >>>> Enter the BlackBerry Developer Challenge >>>> http://p.sf.net/sfu/RIM-dev2dev >>>> _______________________________________________ >>>> Exist-development mailing list >>>> Exi...@li... >>>> https://lists.sourceforge.net/lists/listinfo/exist-development >>>> >>> >>> >>> >>> -- >>> Adam Retter >>> >>> eXist Developer >>> { United Kingdom } >>> ad...@ex... >>> irc://irc.freenode.net/existdb >>> >> > > > > -- > Adam Retter > > eXist Developer > { United Kingdom } > ad...@ex... > irc://irc.freenode.net/existdb > |
|
From: Dmitriy S. <sha...@gm...> - 2010-08-12 14:40:38
|
On Thu, 2010-08-12 at 16:31 +0200, Joern Turner wrote: > Ok - don't worry - managed to make our code compile again against 9.1.0.8 > BTW, I'll try to make eXist's xslt engine to do a job for your staff, as soon as get time for it. -- Cheers, Dmitriy Shabanov |
|
From: Dmitriy S. <sha...@gm...> - 2010-08-12 14:40:30
|
On Thu, 2010-08-12 at 16:31 +0200, Joern Turner wrote: > Ok - don't worry - managed to make our code compile again against 9.1.0.8 > BTW, I'll try to make eXist's xslt engine to do a job for your staff, as soon as get time for it. -- Cheers, Dmitriy Shabanov |
|
From: Adam R. <ad...@ex...> - 2010-08-12 14:40:25
|
On 12 August 2010 13:48, Joern Turner <joe...@go...> wrote: > On Thu, Aug 12, 2010 at 2:46 PM, Adam Retter <ad...@ex...> wrote: >>> At least James said Cocoon will be removed. We initially put the >>> cocoon lib into our uninstall dir but skipped that after James' >>> statement. > We do not depend on it. We just depend on ehcache in a newer version > that cocoon also uses. > >> >> Cocoon is now an extension, so you should not depend on it - I would >> recommend putting libs you need into lib/optional as you are >> practically a core part of eXist now, i.e. you are not an extension - >> or do I have that wrong? > i fear yes ;) As a first step we are an extension. Okay perhaps a extension/betterForm/lib would work for you? I see that the cocoon extension does this also? > >> >>>> >>>> trunk/eXist/lib/user/saxon-9.0.jar >>>> trunk/eXist/lib/user/saxon-dom-9.0.jar >>>> >>>> Saxon jars should go in the endorsed directory, for the HE version only one >>>> jar file is required. Would that work for betterforms> >>>> the purpose of lib/user is to allow endusers to add new jar files. Other >>>> files should go to lib/optional. >>>> last: please add LICENSE.txt files for each jar file you add (see all other >>>> jar files). WIth this we can estimate whether the license actually allows us >>>> to include that jar file. >>> Will do. >>> >>> Cheers, >>> >>> Joern >>> >>> >>>> Kind regards >>>> Dannes >>>> -- >>>> eXist-db Native XML Database - http://exist-db.org >>>> Join us on linked-in: http://www.linkedin.com/groups?gid=35624 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.net email is sponsored by >>>> >>>> Make an app they can't live without >>>> Enter the BlackBerry Developer Challenge >>>> http://p.sf.net/sfu/RIM-dev2dev >>>> _______________________________________________ >>>> Exist-development mailing list >>>> Exi...@li... >>>> https://lists.sourceforge.net/lists/listinfo/exist-development >>>> >>>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by >>> >>> Make an app they can't live without >>> Enter the BlackBerry Developer Challenge >>> http://p.sf.net/sfu/RIM-dev2dev >>> _______________________________________________ >>> Exist-development mailing list >>> Exi...@li... >>> https://lists.sourceforge.net/lists/listinfo/exist-development >>> >> >> >> >> -- >> Adam Retter >> >> eXist Developer >> { United Kingdom } >> ad...@ex... >> irc://irc.freenode.net/existdb >> > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
64 messages has been excluded from this view by a project administrator.
