OK let it be as is.
On Sat, Oct 5, 2013 at 9:27 AM, seba.wag...@gmail.com <seba.wag...@gmail.com > wrote: > 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 > -- WBR Maxim aka solomax
