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
