You are viewing a plain text version of this content. The canonical link for it is here.
Posted to announce@apache.org by Bertrand Delacretaz <bd...@apache.org> on 2013/10/01 11:08:08 UTC
[ANN] Apache Sling Health Check Tools released
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
Re: [ANN] Apache Sling Health Check Tools released
Posted by Maxim Solodovnik <so...@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.wagner@gmail.com <
seba.wagner@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 <so...@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.wagner@gmail.com <
>> seba.wagner@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 <bd...@apache.org>
>>> Date: 2013/10/1
>>> Subject: [ANN] Apache Sling Health Check Tools released
>>> To: dev <de...@sling.apache.org>, users <us...@sling.apache.org>, Apache
>>> Announcements <an...@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.wagner@gmail.com
>>>
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>
--
WBR
Maxim aka solomax
Re: [ANN] Apache Sling Health Check Tools released
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
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 <so...@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.wagner@gmail.com <
> seba.wagner@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 <bd...@apache.org>
>> Date: 2013/10/1
>> Subject: [ANN] Apache Sling Health Check Tools released
>> To: dev <de...@sling.apache.org>, users <us...@sling.apache.org>, Apache
>> Announcements <an...@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.wagner@gmail.com
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: [ANN] Apache Sling Health Check Tools released
Posted by Maxim Solodovnik <so...@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.wagner@gmail.com <
seba.wagner@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 <bd...@apache.org>
> Date: 2013/10/1
> Subject: [ANN] Apache Sling Health Check Tools released
> To: dev <de...@sling.apache.org>, users <us...@sling.apache.org>, Apache
> Announcements <an...@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.wagner@gmail.com
>
--
WBR
Maxim aka solomax
Fwd: [ANN] Apache Sling Health Check Tools released
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
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 <bd...@apache.org>
Date: 2013/10/1
Subject: [ANN] Apache Sling Health Check Tools released
To: dev <de...@sling.apache.org>, users <us...@sling.apache.org>, Apache
Announcements <an...@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.wagner@gmail.com