tion model.
Sebastian
-- Forwarded message --
From: Bertrand Delacretaz
Date: 2013/10/1
Subject: [ANN] Apache Sling Health Check Tools released
To: dev , users , Apache
Announcements
Hi,
The Apache Sling team is pleased to announce the initial release of
the Apache Sling Health C
. 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 Delacreta
; 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
&
>>
>>> 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
es.
>>>> 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
o additional "standalone" artifacts :(
>>>>
>>>>
>>>> On Thu, Oct 3, 2013 at 11:02 AM, seba.wag...@gmail.com <
>>>> seba.wag...@gmail.com> wrote:
>>>>
>>>>> Hi Maxim,
>>>>>
>>>>> j
t;>> 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.
>>>>>
>
ke _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
>>&
e 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 a
>> 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
>>>>&
e
>>>>>>>> distributed. They have of course dependencies. But that is what you
>>>>>>>> might
>>>>>>>> manage then in your pom.xml or ivy file.
>>>>>>>>
>>>>>>>> So having those
do the
>>>>>>>>> same
>>>>>>>>> with organizing source code and grouping JARs.
>>>>>>>>>
>>>>>>>>> So it is really not about building standalone artefacts that can
>>>>>>&
gt;>>>>>> 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
>>>&
;>>>> the openmeetings wicket related stuff could become even a standalone
>>>>>>>>>>> eclipse project.
>>>>>>>>>>>
>>>>>>>>>>> And in the OpenMeetings "core" project the
>>>>>>>>>>>
..@gmail.com <
>>>>>>>>>>> seba.wag...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> But it is not about creating *standalone* artefacts.
>>>>>>>>>>>> It is just
;>>>>>>
>>>>>>>>>>> 2013/10/3 Maxim Solodovnik
>>>>>>>>>>>
>>>>>>>>>>>> I don't think they wrong or we right
>>>>>>>>>>>> I just can't se
that require consens. Steps 3+4 can be done
>>>>>>>>>>>> at any
>>>>>>>>>>>> time later.
>>>>>>>>>>>>
>>>>>>>>>>>> Sebastian
>>>>>>>>&
ling to
>>>>>>>>>>>>> put time into that then on Release Cycles.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It basically should not have any effect on how the application
>>>>>>&
long 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
>&g
t;>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That would be it for the moment.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A
;>>>>>>>>> - Axis
>>>>>>>>>>>>>>>> - ScreenSharing
>>>>>>>>>>>>>>>> - Utils
>>>>>>>>>>>>>>>> - Core ("the rest", mainly business logic or things that
>>>&
gt;>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 1) First step would be to identify/discuss possible
>>>>>>>>>>>>>>>&g
ders".
>>>>>>>>>>>>>>>>>> Maven users just
>>>>>>>>>>>>>>>>>> wonder why anybody would do that if Maven already handles it
>>>>>>>>>>&
gt;>>>>>>> "checking in Eclipse files in SVN with Apache Headers".
>>>>>>>>>>>>>>>>>> Maven users just
>>>>>>>>>>>>>>>>>> wonder why anybody would do that if
;> with "Apache Headers" in the SVN and syncing, and then
>>>>>>>>>>>>>>>>>>> Eclipse overwrites
>>>>>>>>>>>>>>>>>>> it again and all this kind o
t;>>>>>> (distribution, dependency management, testing, ...)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Just one example: In Maven you simply run "
;>>>> source code.
>>>>>>>>>>>>>>>>>>>>> We can improve our build structure to a common
>>>>>>>>>>>>>>>>>>>>> standard that makes it easier for 3rd parties to get
>>>&g
27 matches
Mail list logo
