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
