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
