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
