I removed the openmeetings-template-$VERSION.jar, it did not contain any kind of needed files.
Also by applying some filters to the existing "all-in-on" jar the file size of the jar is 50% :) BTW: The .xml files for the Web-Installer is now copied into the META-INF/classes directory (together with the other .html templates) and no more compiled into the .jar file. Sebastian 2013/10/5 seba.wag...@gmail.com <seba.wag...@gmail.com> > 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 > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com seba.wag...@gmail.com
