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