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
