There might be references from Core to DB. And that is quite natural as we have not given a lot of though on encapsulating those functionalities and designing real APIs where modules communicate with each other.
However from a Maven perspective there is no need to resolve those now. Everything will work fine. On compile and on developer level. However you are right, those cross links are basically a bad design, that is now more clear to everybody. And I think that is already a good thing to learn and to improve for our future. So what you experience is from my point of view the right thing: There are cross references and those are basically bad design and implementation decisisons. However there is no need to resolve them now, neither from comilation perspective nor from working with the sources. Those cross references are still allowed when we have a multi-project design. Sebastian 2013/10/5 Maxim Solodovnik <solomax...@gmail.com> > What I understand from yesterday refactoring was: > you have 2 modules > 1) core > 2) db > core is dependent on db, db is dependent on core > I believe this is > 1) bad design > 2) will not compile > > what I tried to achieve is to made things right. > > Additionally copy/paste was extremely reduced :) > > > > On Sat, Oct 5, 2013 at 9:12 AM, seba.wag...@gmail.com < > seba.wag...@gmail.com> wrote: > >> I really don't understand the point.Of course if you need older or new >> version of the sub projects then it would add them, however as its a >> multi-level project you don't need that ? >> >> AFAIK you have one master pom.xml that sits directly in trunk. >> And a pom.xml in each of the sub-projects. >> >> The subprojects reference each other of course. >> >> Compiling standalone is actually solved I think by two things: >> >> Inside Eclipse you configure with the help of Maven those sub projects as >> "dependencies". I think you just register them in the pom.xml and Maven >> will then create the necessary links in your Eclipse project files to make >> it compile inside Eclipse and runnable for the tests. >> >> And in the build itself I think the pom will reference those compilation >> units already. You can make them available either by linking between >> projects or by binary dependncies. But I think the most common way to do >> that is to simply link the other Maven. >> >> I think each of the sub-project is called a "Maven Module". So that each >> of our source folders (core, db, web, et cetera) becomes one Maven Module. >> >> Sebastian >> >> >> >> 2013/10/5 Maxim Solodovnik <solomax...@gmail.com> >> >>> imaging separation already happend. >>> You perform checkout >>> Start build >>> And the build need to download earlier versions of jars being compiled >>> to complete >>> And fails in case old versions are not compatible with new ones :))) >>> >>> >>> On Sat, Oct 5, 2013 at 8:54 AM, seba.wag...@gmail.com < >>> seba.wag...@gmail.com> wrote: >>> >>>> --- missed to include @dev list cc --- >>>> >>>> *In case you are compiling all sources in one big target it would be >>>> impossible, since all modules were tightly dependend on each other.* >>>> >>>> If you have those "dependencies" as JAR file in binary form or if you >>>> simply compile all at once makes no difference. Both will (and does) work. >>>> >>>> And as those new projects will be build using Maven I also don't see >>>> how compiling those one-by-one will help us. Once there are multiple >>>> projects those single compilation units are produced by Maven. So whatever >>>> you write now in the ANT build file, you can't re-use it. >>>> >>>> So after all, I think you can of course go ahead and refactor it >>>> further to what you intended to do. However I see no additional value in >>>> doing. >>>> >>>> Sebastian >>>> >>>> >>>> 2013/10/5 Maxim Solodovnik <solomax...@gmail.com> >>>> >>>>> To test my changes I have deleted dist folder, run ant and then was >>>>> able to successfully run OM using red5-debug.sh >>>>> >>>>> Since the goal was to create >>>>> 1) vital >>>>> 2) separated >>>>> projects >>>>> >>>>> I have decided to split current project to the units able to be >>>>> compilable one by one. >>>>> In case you are compiling all sources in one big target it would be >>>>> impossible, since all modules were tightly dependend on each other. >>>>> >>>>> I believe my approach is better since modules are compiled and stored >>>>> separately. This will allow to move them into separate project any time >>>>> (with one exclusion: those projects can do nothing until all of them >>>>> together) >>>>> >>>>> >>>>> On Sat, Oct 5, 2013 at 8:35 AM, seba.wag...@gmail.com < >>>>> seba.wag...@gmail.com> wrote: >>>>> >>>>>> Sorry but what you committed did not even compile. And the >>>>>> dependencies in the build.xml was just a network of things. >>>>>> >>>>>> I have fixed now the things back to what I thought would be the >>>>>> result of step 1 and 2. >>>>>> R1529374 is functional ready from my point of view. >>>>>> >>>>>> What on top of it do we need to do ? >>>>>> I mean if you have optimizations you can apply those. >>>>>> >>>>>> You can theoretically now simply create a separated project (for >>>>>> instance for the src/db folder), remove those sources and add >>>>>> openmeetings-db-3.0.0-SNAPSHOT.jar as dependency. >>>>>> And that was the goal. >>>>>> >>>>>> What on top of it would be needed ? >>>>>> >>>>>> Sebastian >>>>>> >>>>>> >>>>>> 2013/10/5 Maxim Solodovnik <solomax...@gmail.com> >>>>>> >>>>>>> Your current approach will not lead you to multiproject structure :( >>>>>>> While refactoring build.xml I tried to compile each folder >>>>>>> separately and finally it was successfull >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Oct 5, 2013 at 8:25 AM, Maxim Solodovnik < >>>>>>> solomax...@gmail.com> wrote: >>>>>>> >>>>>>>> I'll try to explain what I did step by step: >>>>>>>> 1) create 6 folders for 6 types of sources >>>>>>>> 2) move java files >>>>>>>> Everything fine on this stage on the eclipse level >>>>>>>> 3) open build.xml >>>>>>>> 4) found multiple problems with it: >>>>>>>> 1. lots of 'relict' targets >>>>>>>> 2. combined naming style of targets: web.only, dist-bin, >>>>>>>> buildOnlyWebDoc etc. >>>>>>>> 3. lots of copy/paste: creating of each jar was made by >>>>>>>> copy/pasting certain code block >>>>>>>> 5) I have decided to unify build.xml file >>>>>>>> 6) due to file system changes are huge I have desided to commit >>>>>>>> first version partially mailfunctioning >>>>>>>> >>>>>>>> I believe the better option to commit my changes and fix/recreate >>>>>>>> missing/broken functionality. >>>>>>>> buld.xml as it is now is almost unreadable >>>>>>>> >>>>>>>> Please let me know what do you think >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Oct 5, 2013 at 6:49 AM, seba.wag...@gmail.com < >>>>>>>> seba.wag...@gmail.com> wrote: >>>>>>>> >>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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
