You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2008/07/13 23:32:27 UTC
Re: Tapestry and OSGi
It's very late in the 5.0 cycle to introduce something new. I'd
prefer to see this as part of 5.1 ... it may be time to start thinking
about cutting a branch for 5.1 work that we can merge into trunk once
5.0 is GA. My gut feeling is that this could be a tapestry-osgi
add-on library.
On Sun, Jul 13, 2008 at 8:41 AM, Igor Drobiazko
<ig...@gmail.com> wrote:
> Hello Howard,
>
> as already mentioned in the tapestry user list I'm working on embedding
> Tapestry into an OSGi application.
> We already solved the problems mentioned in this thread
> http://www.nabble.com/ClassNameLocatorImpl-in-OSGi-td18204202.html#a18204202
>
> I would like to make the OSGi support available for all. Do you think we can
> add it to tapestry-core? Shall we maybe start a new module tapestry-osgi?
> This OSGi integration doesn't require new dependencies and consists of 4-6
> classes (most of them are decorators of the Servlet API). It allows you to
> start Tapestry within OSGi environment. Furthermore it allows you to inject
> OSGi services into Tapestry pages in the same way we inject Spring beans.
>
> Shall I add a jira issue for it and assign it to me?
>
>
> May I also ask you to comment this issue?
> https://issues.apache.org/jira/browse/TAPESTRY-2519
>
> --
> Best regards,
>
> Igor Drobiazko
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry and OSGi
Posted by Mike Sandman <mi...@thesandmans.com>.
if the release cycle is indeed only 2-3 months for major releases, then
i would have to agree that my previous comment is invalid--i would keep
it as one complete project released-at-once. for such a large body of
code it is hard to be much more agile than 2 months.
that said they may be uses for subproject dev release. but that still
seems of little benefit given the SNAPSHOT feature of maven.
Howard Lewis Ship wrote:
> Exactly; Hibernate has made this mistake and it's impossible to tell
> what versions go with what. Ditto for Maven.
>
> I'd rather we have a process where we can come out with a 5.1, 5.2,
> 5.3 release every few months. That's my vision, anyway, add a couple
> of significant features, work towards a GA release, lather rinse
> repeat.
>
> On Mon, Jul 14, 2008 at 12:00 PM, Robert Zeigler <ro...@scazdl.org> wrote:
>
>> Yes and no.
>> On the one hand, it's nice for each sub-project to have its own release
>> lifecycle, etc.
>> On the other hand, it makes it really easy to know what is compatible with
>> what.
>> Consider a scenario like:
>> tapestry-core 5.0.14 requires:
>> tapestry-ioc 5.0.7
>> tapestry-annotations 5.0.3
>> Since it's a hibernate-based app, we'll be using:
>> tapestry-hibernate 5.0.9
>>
>> Hm... what are the dependencies of tapestry-hibernate 5.0.9? Is it on
>> tapestry-core 5.0.9? Or later? Or 5.0.14? Or...?
>> Keeping the version numbers and the releases in-sync makes it easier for a
>> person to wrap his/her head around what goes with what.
>>
>> Robert
>>
>> On Jul 14, 2008, at 7/141:19 PM , Andreas Andreou wrote:
>>
>>
>>> Wouldn't it make sense to consider subprojects having different lifecycle
>>> that
>>> the master project?
>>>
>>> So that you could have a release as soon as a major issue in that
>>> specific project
>>> is fixed - instead of having to do a global release and update version
>>> numbers of
>>> everything else?
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry and OSGi
Posted by Christian Edward Gruber <ch...@gmail.com>.
If you're going to have regular, consistent, and fairly frequent
releases, then I'd leave 5.0.1, 5.0.2, etc. as patch updates for bug
fixes only. But if you want newer functionality not in 5.0.x that's
slated for 5.1, then track 5.1-SNAPSHOT - but don't expect it to show
up in 5.0.25.
Is that a fair assessment Howard?
Christian
On 15-Jul-08, at 12:06 , Hilco Wijbenga wrote:
> On Mon, Jul 14, 2008 at 11:20 PM, Howard Lewis Ship
> <hl...@gmail.com> wrote:
>> I'd rather we have a process where we can come out with a 5.1, 5.2,
>> 5.3 release every few months. That's my vision, anyway, add a couple
>> of significant features, work towards a GA release, lather rinse
>> repeat.
>
> Wouldn't that then also allow subprojects to release in between using
> 5.1.x, 5.2.y, etcetera? I mean, can't we have both? It doesn't seem
> too difficult to come up with some sort of scheme that allows
> subprojects to release bug fixes right away without losing the ability
> to easily identify what Tapestry release the subproject belongs to.
>
> (The next Tapestry release could then bump everything up to 5.z so
> that all versions are the same again.)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry and OSGi
Posted by Christian Edward Gruber <ch...@gmail.com>.
I've found googlecode to be quite handy, though obviously if you have
your own infrastructure, you can always use that.
Christian.
On 16-Jul-08, at 01:53 , Howard Lewis Ship wrote:
> I think a good pattern may be to create a Tapestry commons that
> contains smaller projects on their own schedule, separate from the
> "core" modules.
>
> Further, I'm looking into setting up SVN, project home pages and
> downloads at tapestry.formos.com, to support auxilliary projects that
> (due to licensing or maturity reasons) can't be hosted at Apache.
>
> On Tue, Jul 15, 2008 at 12:09 PM, Igor Drobiazko
> <ig...@gmail.com> wrote:
>> I personally don't like the idea of "version-per-subproject".
>> Managing these
>> versions without Maven can be very ugly. There are still a lot of
>> developers
>> who download Tapestry binaries manually and put them into their
>> version
>> control system.
>>
>> Another idea of increasing the developer activity would be a so
>> called
>> "sandbox" or "incubator" project (see MyFaces or Eclipse). Some
>> cool stuff
>> can be developed in the sandbox. Reaching maturity this stuff can
>> be moved
>> into main production.
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry and OSGi
Posted by Igor Drobiazko <ig...@gmail.com>.
Going back to the original question. I completely agree that it is to late
to introduce OSGi integration the 5.0.x cycle.
Can we at least resolve the issue TAPESTRY-2519 before 5.1?
https://issues.apache.org/jira/browse/TAPESTRY-2519
It is just an improvement which will stay invisible for the most Tapestry
users. It is really ugly to copy the ClassNameLocatorImpl to be able to
override it.
On Wed, Jul 16, 2008 at 7:53 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
> I think a good pattern may be to create a Tapestry commons that
> contains smaller projects on their own schedule, separate from the
> "core" modules.
>
> Further, I'm looking into setting up SVN, project home pages and
> downloads at tapestry.formos.com, to support auxilliary projects that
> (due to licensing or maturity reasons) can't be hosted at Apache.
>
> On Tue, Jul 15, 2008 at 12:09 PM, Igor Drobiazko
> <ig...@gmail.com> wrote:
> > I personally don't like the idea of "version-per-subproject". Managing
> these
> > versions without Maven can be very ugly. There are still a lot of
> developers
> > who download Tapestry binaries manually and put them into their version
> > control system.
> >
> > Another idea of increasing the developer activity would be a so called
> > "sandbox" or "incubator" project (see MyFaces or Eclipse). Some cool
> stuff
> > can be developed in the sandbox. Reaching maturity this stuff can be
> moved
> > into main production.
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
Re: Tapestry and OSGi
Posted by Howard Lewis Ship <hl...@gmail.com>.
I think a good pattern may be to create a Tapestry commons that
contains smaller projects on their own schedule, separate from the
"core" modules.
Further, I'm looking into setting up SVN, project home pages and
downloads at tapestry.formos.com, to support auxilliary projects that
(due to licensing or maturity reasons) can't be hosted at Apache.
On Tue, Jul 15, 2008 at 12:09 PM, Igor Drobiazko
<ig...@gmail.com> wrote:
> I personally don't like the idea of "version-per-subproject". Managing these
> versions without Maven can be very ugly. There are still a lot of developers
> who download Tapestry binaries manually and put them into their version
> control system.
>
> Another idea of increasing the developer activity would be a so called
> "sandbox" or "incubator" project (see MyFaces or Eclipse). Some cool stuff
> can be developed in the sandbox. Reaching maturity this stuff can be moved
> into main production.
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry and OSGi
Posted by Igor Drobiazko <ig...@gmail.com>.
I personally don't like the idea of "version-per-subproject". Managing these
versions without Maven can be very ugly. There are still a lot of developers
who download Tapestry binaries manually and put them into their version
control system.
Another idea of increasing the developer activity would be a so called
"sandbox" or "incubator" project (see MyFaces or Eclipse). Some cool stuff
can be developed in the sandbox. Reaching maturity this stuff can be moved
into main production.
Re: Tapestry and OSGi
Posted by Jesse Kuhnert <jk...@gmail.com>.
I agree that it might make sense to allow sub-projects to release
independently of the core releases.
For instance, intellij release many EAP versions of their editor
which have a small set of "core" plugins that they
maintain themselves and the rest of the plug-in authors eventually
catch up when they can.
It sounds ironic to have a "component oriented" framework that can't
have independent parts/releases going out. ;)
I do see how it may start to become a major headache to worry about
too many sub-projects and how they sync up with the core
but it's also a great place to allow committers to work on the project
and stretch their coding muscles.. Ie I think it will be healthy for
Tapestry
to allow ~some~ leniency in allowing people to own their own
sub-projects without having to be overly accountable to the main
release
cycle. (there are of course some add-ons that do make since to keep
in sync with the mainline releases as they are so commonly
needed /critical to every day use of the framework, such as the
hibernate support....but OSGI could probably certainly get away with
being released separately. ) You could even go as far as having a
specific core "tapestry add-ons" (or similar sounding) project web
site
where it is made clear which add-ons are core to the framework and
something people can expect to always be present/up to date for every
release
and which add-ons are independently released.
Anyways, there was another thread not too long ago asking what could
be done to get more developers actively involved and I think
allowing people to work somewhat independently on sub-projects could
be a very easy way to make this happen. (also becomes easier
for people like Howard to occasionally view a commit log message on a
sub-project without necessarily feeling like everything ~must~ be
poured over carefully if it isn't a core framework/add-on kind of
commit) Can't have the development team grow and get better at
designing
things as it would "be preferred" without having an outlet for them to
do so that isn't as strict/critical as the core libraries. imho..
On Tue, Jul 15, 2008 at 12:06 PM, Hilco Wijbenga
<hi...@gmail.com> wrote:
> On Mon, Jul 14, 2008 at 11:20 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>> I'd rather we have a process where we can come out with a 5.1, 5.2,
>> 5.3 release every few months. That's my vision, anyway, add a couple
>> of significant features, work towards a GA release, lather rinse
>> repeat.
>
> Wouldn't that then also allow subprojects to release in between using
> 5.1.x, 5.2.y, etcetera? I mean, can't we have both? It doesn't seem
> too difficult to come up with some sort of scheme that allows
> subprojects to release bug fixes right away without losing the ability
> to easily identify what Tapestry release the subproject belongs to.
>
> (The next Tapestry release could then bump everything up to 5.z so
> that all versions are the same again.)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tapestry / OGNL / Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry and OSGi
Posted by Hilco Wijbenga <hi...@gmail.com>.
On Mon, Jul 14, 2008 at 11:20 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> I'd rather we have a process where we can come out with a 5.1, 5.2,
> 5.3 release every few months. That's my vision, anyway, add a couple
> of significant features, work towards a GA release, lather rinse
> repeat.
Wouldn't that then also allow subprojects to release in between using
5.1.x, 5.2.y, etcetera? I mean, can't we have both? It doesn't seem
too difficult to come up with some sort of scheme that allows
subprojects to release bug fixes right away without losing the ability
to easily identify what Tapestry release the subproject belongs to.
(The next Tapestry release could then bump everything up to 5.z so
that all versions are the same again.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry and OSGi
Posted by Howard Lewis Ship <hl...@gmail.com>.
Exactly; Hibernate has made this mistake and it's impossible to tell
what versions go with what. Ditto for Maven.
I'd rather we have a process where we can come out with a 5.1, 5.2,
5.3 release every few months. That's my vision, anyway, add a couple
of significant features, work towards a GA release, lather rinse
repeat.
On Mon, Jul 14, 2008 at 12:00 PM, Robert Zeigler <ro...@scazdl.org> wrote:
> Yes and no.
> On the one hand, it's nice for each sub-project to have its own release
> lifecycle, etc.
> On the other hand, it makes it really easy to know what is compatible with
> what.
> Consider a scenario like:
> tapestry-core 5.0.14 requires:
> tapestry-ioc 5.0.7
> tapestry-annotations 5.0.3
> Since it's a hibernate-based app, we'll be using:
> tapestry-hibernate 5.0.9
>
> Hm... what are the dependencies of tapestry-hibernate 5.0.9? Is it on
> tapestry-core 5.0.9? Or later? Or 5.0.14? Or...?
> Keeping the version numbers and the releases in-sync makes it easier for a
> person to wrap his/her head around what goes with what.
>
> Robert
>
> On Jul 14, 2008, at 7/141:19 PM , Andreas Andreou wrote:
>
>> Wouldn't it make sense to consider subprojects having different lifecycle
>> that
>> the master project?
>>
>> So that you could have a release as soon as a major issue in that
>> specific project
>> is fixed - instead of having to do a global release and update version
>> numbers of
>> everything else?
>>
>> On Mon, Jul 14, 2008 at 8:59 PM, Robert Zeigler <ro...@scazdl.org>
>> wrote:
>>>
>>> +1 on keeping "integration" code in separate modules from core.
>>>
>>> Robert
>>>
>>> On Jul 13, 2008, at 7/134:32 PM , Howard Lewis Ship wrote:
>>>
>>>> It's very late in the 5.0 cycle to introduce something new. I'd
>>>> prefer to see this as part of 5.1 ... it may be time to start thinking
>>>> about cutting a branch for 5.1 work that we can merge into trunk once
>>>> 5.0 is GA. My gut feeling is that this could be a tapestry-osgi
>>>> add-on library.
>>>>
>>>> On Sun, Jul 13, 2008 at 8:41 AM, Igor Drobiazko
>>>> <ig...@gmail.com> wrote:
>>>>>
>>>>> Hello Howard,
>>>>>
>>>>> as already mentioned in the tapestry user list I'm working on embedding
>>>>> Tapestry into an OSGi application.
>>>>> We already solved the problems mentioned in this thread
>>>>>
>>>>>
>>>>> http://www.nabble.com/ClassNameLocatorImpl-in-OSGi-td18204202.html#a18204202
>>>>>
>>>>> I would like to make the OSGi support available for all. Do you think
>>>>> we
>>>>> can
>>>>> add it to tapestry-core? Shall we maybe start a new module
>>>>> tapestry-osgi?
>>>>> This OSGi integration doesn't require new dependencies and consists of
>>>>> 4-6
>>>>> classes (most of them are decorators of the Servlet API). It allows you
>>>>> to
>>>>> start Tapestry within OSGi environment. Furthermore it allows you to
>>>>> inject
>>>>> OSGi services into Tapestry pages in the same way we inject Spring
>>>>> beans.
>>>>>
>>>>> Shall I add a jira issue for it and assign it to me?
>>>>>
>>>>>
>>>>> May I also ask you to comment this issue?
>>>>> https://issues.apache.org/jira/browse/TAPESTRY-2519
>>>>>
>>>>> --
>>>>> Best regards,
>>>>>
>>>>> Igor Drobiazko
>>>>
>>>>
>>>>
>>>> --
>>>> Howard M. Lewis Ship
>>>>
>>>> Creator Apache Tapestry and Apache HiveMind
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
>> Tapestry / Tacos developer
>> Open Source / JEE Consulting
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry and OSGi
Posted by Andreas Andreou <an...@gmail.com>.
Exactly, that's why i'm wondering if there's a third alternative...
And keep in mind i'm mostly talking about the (possible) new subprojects
like osgi and not the existing ones that people expect to be in sync
On Mon, Jul 14, 2008 at 10:00 PM, Robert Zeigler <ro...@scazdl.org> wrote:
> Yes and no.
> On the one hand, it's nice for each sub-project to have its own release
> lifecycle, etc.
> On the other hand, it makes it really easy to know what is compatible with
> what.
> Consider a scenario like:
> tapestry-core 5.0.14 requires:
> tapestry-ioc 5.0.7
> tapestry-annotations 5.0.3
> Since it's a hibernate-based app, we'll be using:
> tapestry-hibernate 5.0.9
>
> Hm... what are the dependencies of tapestry-hibernate 5.0.9? Is it on
> tapestry-core 5.0.9? Or later? Or 5.0.14? Or...?
> Keeping the version numbers and the releases in-sync makes it easier for a
> person to wrap his/her head around what goes with what.
>
> Robert
>
> On Jul 14, 2008, at 7/141:19 PM , Andreas Andreou wrote:
>
>> Wouldn't it make sense to consider subprojects having different lifecycle
>> that
>> the master project?
>>
>> So that you could have a release as soon as a major issue in that
>> specific project
>> is fixed - instead of having to do a global release and update version
>> numbers of
>> everything else?
>>
>> On Mon, Jul 14, 2008 at 8:59 PM, Robert Zeigler <ro...@scazdl.org>
>> wrote:
>>>
>>> +1 on keeping "integration" code in separate modules from core.
>>>
>>> Robert
>>>
>>> On Jul 13, 2008, at 7/134:32 PM , Howard Lewis Ship wrote:
>>>
>>>> It's very late in the 5.0 cycle to introduce something new. I'd
>>>> prefer to see this as part of 5.1 ... it may be time to start thinking
>>>> about cutting a branch for 5.1 work that we can merge into trunk once
>>>> 5.0 is GA. My gut feeling is that this could be a tapestry-osgi
>>>> add-on library.
>>>>
>>>> On Sun, Jul 13, 2008 at 8:41 AM, Igor Drobiazko
>>>> <ig...@gmail.com> wrote:
>>>>>
>>>>> Hello Howard,
>>>>>
>>>>> as already mentioned in the tapestry user list I'm working on embedding
>>>>> Tapestry into an OSGi application.
>>>>> We already solved the problems mentioned in this thread
>>>>>
>>>>>
>>>>> http://www.nabble.com/ClassNameLocatorImpl-in-OSGi-td18204202.html#a18204202
>>>>>
>>>>> I would like to make the OSGi support available for all. Do you think
>>>>> we
>>>>> can
>>>>> add it to tapestry-core? Shall we maybe start a new module
>>>>> tapestry-osgi?
>>>>> This OSGi integration doesn't require new dependencies and consists of
>>>>> 4-6
>>>>> classes (most of them are decorators of the Servlet API). It allows you
>>>>> to
>>>>> start Tapestry within OSGi environment. Furthermore it allows you to
>>>>> inject
>>>>> OSGi services into Tapestry pages in the same way we inject Spring
>>>>> beans.
>>>>>
>>>>> Shall I add a jira issue for it and assign it to me?
>>>>>
>>>>>
>>>>> May I also ask you to comment this issue?
>>>>> https://issues.apache.org/jira/browse/TAPESTRY-2519
>>>>>
>>>>> --
>>>>> Best regards,
>>>>>
>>>>> Igor Drobiazko
>>>>
>>>>
>>>>
>>>> --
>>>> Howard M. Lewis Ship
>>>>
>>>> Creator Apache Tapestry and Apache HiveMind
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
>> Tapestry / Tacos developer
>> Open Source / JEE Consulting
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry and OSGi
Posted by Mike Sandman <mi...@thesandmans.com>.
Robert Zeigler wrote:
> Yes and no.
> On the one hand, it's nice for each sub-project to have its own
> release lifecycle, etc.
> On the other hand, it makes it really easy to know what is compatible
> with what.
> Consider a scenario like:
> tapestry-core 5.0.14 requires:
> tapestry-ioc 5.0.7
> tapestry-annotations 5.0.3
> Since it's a hibernate-based app, we'll be using:
> tapestry-hibernate 5.0.9
>
> Hm... what are the dependencies of tapestry-hibernate 5.0.9? Is it on
> tapestry-core 5.0.9? Or later? Or 5.0.14? Or...?
> Keeping the version numbers and the releases in-sync makes it easier
> for a person to wrap his/her head around what goes with what.
>
> Robert
>
i do like the (theoretical) increase in agility from
release-per-subproject. i also concede that a big-thump release is
simpler. however, isn't the intent of Maven to make just these kinds of
dependencies trivial to manage? i think the more important
question--rather than is it manageable--is: is it needed?
one thought would be to review "release-readiness" for each subproject
on an on-going basis. meaning, for each subproject make note of when
that subproject is ready for another release relative to the time to
next release of the whole project. it should be straight forward to
determine if the agility gained by releasing subprojects independently
is worth the added work of configuring the Maven builds to manage
subprojects.
thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry and OSGi
Posted by Robert Zeigler <ro...@scazdl.org>.
Yes and no.
On the one hand, it's nice for each sub-project to have its own
release lifecycle, etc.
On the other hand, it makes it really easy to know what is compatible
with what.
Consider a scenario like:
tapestry-core 5.0.14 requires:
tapestry-ioc 5.0.7
tapestry-annotations 5.0.3
Since it's a hibernate-based app, we'll be using:
tapestry-hibernate 5.0.9
Hm... what are the dependencies of tapestry-hibernate 5.0.9? Is it on
tapestry-core 5.0.9? Or later? Or 5.0.14? Or...?
Keeping the version numbers and the releases in-sync makes it easier
for a person to wrap his/her head around what goes with what.
Robert
On Jul 14, 2008, at 7/141:19 PM , Andreas Andreou wrote:
> Wouldn't it make sense to consider subprojects having different
> lifecycle that
> the master project?
>
> So that you could have a release as soon as a major issue in that
> specific project
> is fixed - instead of having to do a global release and update version
> numbers of
> everything else?
>
> On Mon, Jul 14, 2008 at 8:59 PM, Robert Zeigler <ro...@scazdl.org>
> wrote:
>> +1 on keeping "integration" code in separate modules from core.
>>
>> Robert
>>
>> On Jul 13, 2008, at 7/134:32 PM , Howard Lewis Ship wrote:
>>
>>> It's very late in the 5.0 cycle to introduce something new. I'd
>>> prefer to see this as part of 5.1 ... it may be time to start
>>> thinking
>>> about cutting a branch for 5.1 work that we can merge into trunk
>>> once
>>> 5.0 is GA. My gut feeling is that this could be a tapestry-osgi
>>> add-on library.
>>>
>>> On Sun, Jul 13, 2008 at 8:41 AM, Igor Drobiazko
>>> <ig...@gmail.com> wrote:
>>>>
>>>> Hello Howard,
>>>>
>>>> as already mentioned in the tapestry user list I'm working on
>>>> embedding
>>>> Tapestry into an OSGi application.
>>>> We already solved the problems mentioned in this thread
>>>>
>>>> http://www.nabble.com/ClassNameLocatorImpl-in-OSGi-td18204202.html#a18204202
>>>>
>>>> I would like to make the OSGi support available for all. Do you
>>>> think we
>>>> can
>>>> add it to tapestry-core? Shall we maybe start a new module
>>>> tapestry-osgi?
>>>> This OSGi integration doesn't require new dependencies and
>>>> consists of
>>>> 4-6
>>>> classes (most of them are decorators of the Servlet API). It
>>>> allows you
>>>> to
>>>> start Tapestry within OSGi environment. Furthermore it allows you
>>>> to
>>>> inject
>>>> OSGi services into Tapestry pages in the same way we inject
>>>> Spring beans.
>>>>
>>>> Shall I add a jira issue for it and assign it to me?
>>>>
>>>>
>>>> May I also ask you to comment this issue?
>>>> https://issues.apache.org/jira/browse/TAPESTRY-2519
>>>>
>>>> --
>>>> Best regards,
>>>>
>>>> Igor Drobiazko
>>>
>>>
>>>
>>> --
>>> Howard M. Lewis Ship
>>>
>>> Creator Apache Tapestry and Apache HiveMind
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
>
> --
> Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
> Tapestry / Tacos developer
> Open Source / JEE Consulting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry and OSGi
Posted by Andreas Andreou <an...@gmail.com>.
Wouldn't it make sense to consider subprojects having different lifecycle that
the master project?
So that you could have a release as soon as a major issue in that
specific project
is fixed - instead of having to do a global release and update version
numbers of
everything else?
On Mon, Jul 14, 2008 at 8:59 PM, Robert Zeigler <ro...@scazdl.org> wrote:
> +1 on keeping "integration" code in separate modules from core.
>
> Robert
>
> On Jul 13, 2008, at 7/134:32 PM , Howard Lewis Ship wrote:
>
>> It's very late in the 5.0 cycle to introduce something new. I'd
>> prefer to see this as part of 5.1 ... it may be time to start thinking
>> about cutting a branch for 5.1 work that we can merge into trunk once
>> 5.0 is GA. My gut feeling is that this could be a tapestry-osgi
>> add-on library.
>>
>> On Sun, Jul 13, 2008 at 8:41 AM, Igor Drobiazko
>> <ig...@gmail.com> wrote:
>>>
>>> Hello Howard,
>>>
>>> as already mentioned in the tapestry user list I'm working on embedding
>>> Tapestry into an OSGi application.
>>> We already solved the problems mentioned in this thread
>>>
>>> http://www.nabble.com/ClassNameLocatorImpl-in-OSGi-td18204202.html#a18204202
>>>
>>> I would like to make the OSGi support available for all. Do you think we
>>> can
>>> add it to tapestry-core? Shall we maybe start a new module tapestry-osgi?
>>> This OSGi integration doesn't require new dependencies and consists of
>>> 4-6
>>> classes (most of them are decorators of the Servlet API). It allows you
>>> to
>>> start Tapestry within OSGi environment. Furthermore it allows you to
>>> inject
>>> OSGi services into Tapestry pages in the same way we inject Spring beans.
>>>
>>> Shall I add a jira issue for it and assign it to me?
>>>
>>>
>>> May I also ask you to comment this issue?
>>> https://issues.apache.org/jira/browse/TAPESTRY-2519
>>>
>>> --
>>> Best regards,
>>>
>>> Igor Drobiazko
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator Apache Tapestry and Apache HiveMind
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry and OSGi
Posted by Robert Zeigler <ro...@scazdl.org>.
+1 on keeping "integration" code in separate modules from core.
Robert
On Jul 13, 2008, at 7/134:32 PM , Howard Lewis Ship wrote:
> It's very late in the 5.0 cycle to introduce something new. I'd
> prefer to see this as part of 5.1 ... it may be time to start thinking
> about cutting a branch for 5.1 work that we can merge into trunk once
> 5.0 is GA. My gut feeling is that this could be a tapestry-osgi
> add-on library.
>
> On Sun, Jul 13, 2008 at 8:41 AM, Igor Drobiazko
> <ig...@gmail.com> wrote:
>> Hello Howard,
>>
>> as already mentioned in the tapestry user list I'm working on
>> embedding
>> Tapestry into an OSGi application.
>> We already solved the problems mentioned in this thread
>> http://www.nabble.com/ClassNameLocatorImpl-in-OSGi-td18204202.html#a18204202
>>
>> I would like to make the OSGi support available for all. Do you
>> think we can
>> add it to tapestry-core? Shall we maybe start a new module tapestry-
>> osgi?
>> This OSGi integration doesn't require new dependencies and consists
>> of 4-6
>> classes (most of them are decorators of the Servlet API). It allows
>> you to
>> start Tapestry within OSGi environment. Furthermore it allows you
>> to inject
>> OSGi services into Tapestry pages in the same way we inject Spring
>> beans.
>>
>> Shall I add a jira issue for it and assign it to me?
>>
>>
>> May I also ask you to comment this issue?
>> https://issues.apache.org/jira/browse/TAPESTRY-2519
>>
>> --
>> Best regards,
>>
>> Igor Drobiazko
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org