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
