As far as I can see that JPQL error has nothing todo with the source code refactoring, I will commit now a fix that reverts the changes to the build.xml but makes the sources compile and build a package.
I will suggest we first fix the existing issues and then simply package separated JARs files and put them into the lib folder for each of those source folders. If you want to re-apply further your changes to the build xml file, feel free to do so, but from my point of view those changes made it just more hard to read that file then making it more easy. Sebastian 2013/10/5 seba.wag...@gmail.com <seba.wag...@gmail.com> > Further there is a broken SQL query: > , @NamedQuery(name = "getFieldByIdAndLanguage", query = "SELECT fv > FROM Fieldvalues fv " + > "LEFT OUTER JOIN FETCH fv.fieldlanguagesvalues flv WHERE " + > " fv.fieldvalues_id = :id AND fv.deleted = false AND > flv.language_id = :lang") > > Throws the error: > > Caused by: <openjpa-2.2.2-r422266:1468616 nonfatal user error> > org.apache.openjpa.persistence.ArgumentException: Encountered "flv" at > character 77, but expected: [",", ".", "GROUP", "HAVING", "INNER", "JOIN", > "LEFT", "ORDER", "WHERE", <EOF>]. > at > org.apache.openjpa.kernel.jpql.JPQL.generateParseException(JPQL.java:13162) > > > > > 2013/10/5 seba.wag...@gmail.com <seba.wag...@gmail.com> > > The more I edit this build.xml the more I think it is a good idea to move >> away from it :) >> Its a horrible historical grown file. >> This was one of the first versions: >> >> https://code.google.com/p/openmeetings/source/browse/trunk/webapp/build.xml?r=1329 >> >> And since then we just grow it :)) >> >> Sebastian >> >> >> 2013/10/5 seba.wag...@gmail.com <seba.wag...@gmail.com> >> >> There are also some pre-existing issues with our JAR packaging. >>> If you download the existing openmeetings.jar (for example from the last >>> https://builds.apache.org/view/M-R/view/OpenMeetings/job/openmeetings/610/and >>> unpack just unzip openmeetings-3.0.0-SNAPSHOT.jar) , you see a lot of >>> directories and files in that JAR file that have no meaning and/or are >>> duplicated. >>> >>> For example: Why there is a folder /main/webapp/ (and xx subfolders) >>> packaged into the JAR file ?! >>> >>> Sebastian >>> >>> >>> 2013/10/5 seba.wag...@gmail.com <seba.wag...@gmail.com> >>> >>> I did not intend to say that you need to immediatelly do everything in >>>> one flush. >>>> >>>> I also do not understand the full refactoring you have done, there are >>>> so many changes in the build.xml that it is impossible to follow up what >>>> exactly is wrong at the moment. >>>> >>>> It seems like there are several issues, if you run a "clean" you might >>>> see. >>>> >>>> I can try o fix that. But potentially you will need to reply some of >>>> those fixes that you have done on top of it (like the replace of "." with >>>> "-" in some of the build targets) >>>> >>>> Sebastian >>>> >>>> >>>> 2013/10/5 Maxim Solodovnik <solomax...@gmail.com> >>>> >>>>> I'm going to commit the changes >>>>> Please let me know know if anything is broken >>>>> >>>>> Was unable to test everything :( >>>>> >>>>> >>>>> On Fri, Oct 4, 2013 at 11:59 AM, Maxim Solodovnik < >>>>> solomax...@gmail.com> wrote: >>>>> >>>>>> I have started 1+2 >>>>>> everything is OK on Eclipse level BUT >>>>>> there are troubles on the ant level :( >>>>>> >>>>>> all modules you have mention are dependent on each other (except for >>>>>> screensharing). This mean modules can not be compiled separately :( >>>>>> Will try to resolve it somehow >>>>>> >>>>>> >>>>>> On Thu, Oct 3, 2013 at 1:46 PM, seba.wag...@gmail.com < >>>>>> seba.wag...@gmail.com> wrote: >>>>>> >>>>>>> 1+2 now >>>>>>> >>>>>>> 3+4 after the release of version 3.0 >>>>>>> >>>>>>> Sebastian >>>>>>> >>>>>>> >>>>>>> 2013/10/3 Maxim Solodovnik <solomax...@gmail.com> >>>>>>> >>>>>>>> OK >>>>>>>> in what version this should be implemented? >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Oct 3, 2013 at 1:12 PM, seba.wag...@gmail.com < >>>>>>>> seba.wag...@gmail.com> wrote: >>>>>>>> >>>>>>>>> You just concentrate so much about "what can anybody do with those >>>>>>>>> jars". >>>>>>>>> The question is more: What can WE do with those jars. >>>>>>>>> >>>>>>>>> We can test functionality in isolation. >>>>>>>>> We can switch different versions without changing source code. >>>>>>>>> We can improve our build structure to a common standard that makes >>>>>>>>> it easier for 3rd parties to get involved >>>>>>>>> We can improve our build structure to a common standard that makes >>>>>>>>> it easier for us to maintain changes >>>>>>>>> We can benefit from the usage of Maven by having out of the box >>>>>>>>> support for the most common tasks in the software life-cycle >>>>>>>>> (distribution, >>>>>>>>> dependency management, testing, ...) >>>>>>>>> >>>>>>>>> Just one example: In Maven you simply run "mvn eclipse:eclipse" >>>>>>>>> and it will build all the necessary project files based on your pom >>>>>>>>> file >>>>>>>>> that you need for Eclipse. >>>>>>>>> >>>>>>>>> So no back and forth about checking in Eclipse files with "Apache >>>>>>>>> Headers" in the SVN and syncing, and then Eclipse overwrites it again >>>>>>>>> and >>>>>>>>> all this kind of mucking around. You simply never check those files >>>>>>>>> in, >>>>>>>>> cause everybody that needs them simply runs "mvn eclipse:eclipse". And >>>>>>>>> that's it. That is why nobody else has issues with "checking in >>>>>>>>> Eclipse >>>>>>>>> files in SVN with Apache Headers". Maven users just wonder why anybody >>>>>>>>> would do that if Maven already handles it for you. >>>>>>>>> >>>>>>>>> My proposal would be to refactor in multiple steps to use Maven >>>>>>>>> for building the project. >>>>>>>>> Step 1 + 2 would not introduce Maven, it just prepares for it. >>>>>>>>> >>>>>>>>> 1) First step would be to identify/discuss possible artefact's >>>>>>>>> that can be build as a separated JAR. >>>>>>>>> That would be: >>>>>>>>> - Wicket >>>>>>>>> - Persistence >>>>>>>>> - Axis >>>>>>>>> - ScreenSharing >>>>>>>>> - Utils >>>>>>>>> - Core ("the rest", mainly business logic or things that are too >>>>>>>>> small or have no real scope) >>>>>>>>> >>>>>>>>> 2) Group them in a separated source-folders and package them in a >>>>>>>>> separated JAR >>>>>>>>> >>>>>>>>> -------- >>>>>>>>> >>>>>>>>> That would be it for the moment. >>>>>>>>> >>>>>>>>> At some later stage: >>>>>>>>> 3) Externalise, each of those JARs, step by step, into a separated >>>>>>>>> Maven build project. >>>>>>>>> Each of those Maven projects would have its own "test" source >>>>>>>>> folder. So the tests then move from the "core" to the sub projects >>>>>>>>> they >>>>>>>>> belong to. >>>>>>>>> >>>>>>>>> 4) At some stage we might only have the core project left over >>>>>>>>> that builds using ANT+Ivy. At that time we can then discuss further >>>>>>>>> on how >>>>>>>>> to refactor that project to Maven. >>>>>>>>> >>>>>>>>> Steps 3) or 4) depend more on individuals that are willing to put >>>>>>>>> time into that then on Release Cycles. >>>>>>>>> >>>>>>>>> It basically should not have any effect on how the application >>>>>>>>> works / functionality, its only a source code / build tools >>>>>>>>> refactoring. >>>>>>>>> However I would like to get step 1 and 2 done. Because those are >>>>>>>>> basically the ones that require consens. Steps 3+4 can be done at any >>>>>>>>> time >>>>>>>>> later. >>>>>>>>> >>>>>>>>> Sebastian >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2013/10/3 Maxim Solodovnik <solomax...@gmail.com> >>>>>>>>> >>>>>>>>>> I don't think they wrong or we right >>>>>>>>>> I just can't see how one can use any of our jars without others :) >>>>>>>>>> >>>>>>>>>> Could you please propose the structure you would like? >>>>>>>>>> I believe we shouldn't switch to maven until 3.1 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Oct 3, 2013 at 11:48 AM, seba.wag...@gmail.com < >>>>>>>>>> seba.wag...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> But it is not about creating *standalone* artefacts. >>>>>>>>>>> It is just a different way of architecture. >>>>>>>>>>> >>>>>>>>>>> For instance if we switch to a more Maven styled architecture >>>>>>>>>>> the openmeetings wicket related stuff could become even a standalone >>>>>>>>>>> eclipse project. >>>>>>>>>>> >>>>>>>>>>> And in the OpenMeetings "core" project the >>>>>>>>>>> openmeetings-wicket-$version.jar is simply a dependency that you >>>>>>>>>>> add and >>>>>>>>>>> update in your pom (or ivy) file. >>>>>>>>>>> >>>>>>>>>>> That has several advantages, for instance that somebody that has >>>>>>>>>>> no idea about red5 can purely concentrate on editing and writing >>>>>>>>>>> test cases >>>>>>>>>>> for what he knows. And you might test things more in isolation. The >>>>>>>>>>> same >>>>>>>>>>> about the persistance/OpenJPA related stuff. You can simply >>>>>>>>>>> externalize >>>>>>>>>>> that and add it as a dependency. >>>>>>>>>>> I mean externalizing things is a quite basic process that you do >>>>>>>>>>> with every string, code, class, it seems just natural that you do >>>>>>>>>>> the same >>>>>>>>>>> with organizing source code and grouping JARs. >>>>>>>>>>> >>>>>>>>>>> So it is really not about building standalone artefacts that can >>>>>>>>>>> be distributed. They have of course dependencies. But that is what >>>>>>>>>>> you >>>>>>>>>>> might manage then in your pom.xml or ivy file. >>>>>>>>>>> >>>>>>>>>>> So having those kind of separation is one step in a bigger >>>>>>>>>>> process to organize our project and move to a more standardized >>>>>>>>>>> architecture in line with other Apache products. Instead of having >>>>>>>>>>> this >>>>>>>>>>> heavily customized build process. >>>>>>>>>>> >>>>>>>>>>> By having a more standardized process it will be also easier for >>>>>>>>>>> new committers to join the project and provide patches. >>>>>>>>>>> And for example having our JARs in the Maven repositories. I >>>>>>>>>>> doubt that we can really judge what others can do with those JARs. >>>>>>>>>>> There >>>>>>>>>>> might be not some user xyz out there that exactly could use some >>>>>>>>>>> part of >>>>>>>>>>> our code for his project. I mean its all about getting connected >>>>>>>>>>> with other >>>>>>>>>>> projects. We benefit from so many other projects, but we are not >>>>>>>>>>> willing to >>>>>>>>>>> switch our project to a more standardised architecture so that >>>>>>>>>>> others can >>>>>>>>>>> benefit from us. While we could very much benefit if we would >>>>>>>>>>> integrate our >>>>>>>>>>> project better in the Open Source landscape. >>>>>>>>>>> >>>>>>>>>>> Take _any_ Apache project, they are all using Maven and they all >>>>>>>>>>> follow those principles. Do you really think that they are all >>>>>>>>>>> wrong ? And >>>>>>>>>>> is it really that good that we follow our very own way ? >>>>>>>>>>> >>>>>>>>>>> Sebastian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2013/10/3 Maxim Solodovnik <solomax...@gmail.com> >>>>>>>>>>> >>>>>>>>>>>> Hello Sebastian, >>>>>>>>>>>> >>>>>>>>>>>> We surely can add additional targets, but unfortunately the >>>>>>>>>>>> only pard able to live with no others is docs :) >>>>>>>>>>>> All other "jar"s will be dependent on each other. >>>>>>>>>>>> >>>>>>>>>>>> If you OK with it we can try to create more artifacts. >>>>>>>>>>>> Right now I can see no additional "standalone" artifacts :( >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Oct 3, 2013 at 11:02 AM, seba.wag...@gmail.com < >>>>>>>>>>>> seba.wag...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Maxim, >>>>>>>>>>>>> >>>>>>>>>>>>> just another example: >>>>>>>>>>>>> >>>>>>>>>>>>> Look at what this project does release, they group it in >>>>>>>>>>>>> separated JAR packages. >>>>>>>>>>>>> Or have a look at: >>>>>>>>>>>>> http://www.apache.org/dist/sling/ >>>>>>>>>>>>> >>>>>>>>>>>>> I doubt that anybody could use the >>>>>>>>>>>>> org.apache.sling.junit.healthcheck-1.0.6 >>>>>>>>>>>>> without having the core or other JARs. However they split it >>>>>>>>>>>>> up, cause it is just makes it a lot more clear what is what. >>>>>>>>>>>>> >>>>>>>>>>>>> I still believe we should actually do that same. Package for >>>>>>>>>>>>> example the JPA related packages and the wicket related packages >>>>>>>>>>>>> in >>>>>>>>>>>>> separated JAR files. >>>>>>>>>>>>> A single "mega" jar just seems to be a quite outdated >>>>>>>>>>>>> distribution model. >>>>>>>>>>>>> >>>>>>>>>>>>> Sebastian >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ---------- Forwarded message ---------- >>>>>>>>>>>>> From: Bertrand Delacretaz <bdelacre...@apache.org> >>>>>>>>>>>>> Date: 2013/10/1 >>>>>>>>>>>>> Subject: [ANN] Apache Sling Health Check Tools released >>>>>>>>>>>>> To: dev <d...@sling.apache.org>, users <us...@sling.apache.org>, >>>>>>>>>>>>> Apache Announcements <annou...@apache.org> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> The Apache Sling team is pleased to announce the initial >>>>>>>>>>>>> release of >>>>>>>>>>>>> the Apache Sling Health Check Tools, which consist of the >>>>>>>>>>>>> following >>>>>>>>>>>>> modules: >>>>>>>>>>>>> >>>>>>>>>>>>> org.apache.sling.hc.core-1.0.4 >>>>>>>>>>>>> org.apache.sling.hc.it-1.0.4 >>>>>>>>>>>>> org.apache.sling.hc.jmx-1.0.4 >>>>>>>>>>>>> org.apache.sling.hc.samples-1.0.4 >>>>>>>>>>>>> org.apache.sling.hc.support-1.0.4 >>>>>>>>>>>>> org.apache.sling.hc.webconsole-1.0.4 >>>>>>>>>>>>> org.apache.sling.junit.healthcheck-1.0.6 >>>>>>>>>>>>> >>>>>>>>>>>>> Apache Sling is a web framework that uses a Java Content >>>>>>>>>>>>> Repository, >>>>>>>>>>>>> such as Apache Jackrabbit, to store and manage content. Sling >>>>>>>>>>>>> applications use either scripts or Java servlets, selected >>>>>>>>>>>>> based on >>>>>>>>>>>>> simple name conventions, to process HTTP requests in a RESTful >>>>>>>>>>>>> way. >>>>>>>>>>>>> >>>>>>>>>>>>> Based on simple HealthCheck OSGi services, the Sling Health >>>>>>>>>>>>> Check >>>>>>>>>>>>> Tools ("hc" in short form) are used to check the health of >>>>>>>>>>>>> live Sling >>>>>>>>>>>>> systems, based on inputs like JMX MBean attribute values, OSGi >>>>>>>>>>>>> framework information, Sling requests status, JUnit tests, etc. >>>>>>>>>>>>> >>>>>>>>>>>>> See >>>>>>>>>>>>> http://sling.apache.org/documentation/bundles/sling-health-check-tool.html >>>>>>>>>>>>> for more information. >>>>>>>>>>>>> >>>>>>>>>>>>> This release is available from >>>>>>>>>>>>> http://sling.apache.org/site/downloads.cgi and the usual Maven >>>>>>>>>>>>> repositories. >>>>>>>>>>>>> >>>>>>>>>>>>> Enjoy! >>>>>>>>>>>>> >>>>>>>>>>>>> -The Apache Sling team >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Sebastian Wagner >>>>>>>>>>>>> https://twitter.com/#!/dead_lock >>>>>>>>>>>>> http://www.webbase-design.de >>>>>>>>>>>>> http://www.wagner-sebastian.com >>>>>>>>>>>>> seba.wag...@gmail.com >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> WBR >>>>>>>>>>>> Maxim aka solomax >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Sebastian Wagner >>>>>>>>>>> https://twitter.com/#!/dead_lock >>>>>>>>>>> http://www.webbase-design.de >>>>>>>>>>> http://www.wagner-sebastian.com >>>>>>>>>>> seba.wag...@gmail.com >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> WBR >>>>>>>>>> Maxim aka solomax >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Sebastian Wagner >>>>>>>>> https://twitter.com/#!/dead_lock >>>>>>>>> http://www.webbase-design.de >>>>>>>>> http://www.wagner-sebastian.com >>>>>>>>> seba.wag...@gmail.com >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> WBR >>>>>>>> Maxim aka solomax >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Sebastian Wagner >>>>>>> https://twitter.com/#!/dead_lock >>>>>>> http://www.webbase-design.de >>>>>>> http://www.wagner-sebastian.com >>>>>>> seba.wag...@gmail.com >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> WBR >>>>>> Maxim aka solomax >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> WBR >>>>> Maxim aka solomax >>>>> >>>> >>>> >>>> >>>> -- >>>> Sebastian Wagner >>>> https://twitter.com/#!/dead_lock >>>> http://www.webbase-design.de >>>> http://www.wagner-sebastian.com >>>> seba.wag...@gmail.com >>>> >>> >>> >>> >>> -- >>> Sebastian Wagner >>> https://twitter.com/#!/dead_lock >>> http://www.webbase-design.de >>> http://www.wagner-sebastian.com >>> seba.wag...@gmail.com >>> >> >> >> >> -- >> Sebastian Wagner >> https://twitter.com/#!/dead_lock >> http://www.webbase-design.de >> http://www.wagner-sebastian.com >> seba.wag...@gmail.com >> > > > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > http://www.webbase-design.de > http://www.wagner-sebastian.com > seba.wag...@gmail.com > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com seba.wag...@gmail.com
