Ugo Cei wrote:
Il giorno 30/ott/04, alle 20:05, Unico Hommes ha scritto:
Rather than undoing all the changes (would make me really feel bad
about the wasted time I invested :-) I think it is no problem to
provide compatibility. I think that all that is needed is that
block/lib is added to the bl
Ralph Goers wrote:
Vadim Gritsenko wrote:
Ugo Cei wrote:
Looks like this is not a backward-compatible change. Blocks which are
distributed outside of Cocoon (like Fins or my Spring Petstore) must
change their deployment instructions to add all those
elements (and put dependencies in gump too, w
Il giorno 30/ott/04, alle 20:05, Unico Hommes ha scritto:
Rather than undoing all the changes (would make me really feel bad
about the wasted time I invested :-) I think it is no problem to
provide compatibility. I think that all that is needed is that
block/lib is added to the block compilation
Unico Hommes dijo:
> Not that I no longer care what you guys think ;-) but I went ahead and
> made the proposed changes. It should be compatible now.
:-D
Best Regards,
Antonio Gallardo
On 30-okt-04, at 20:05, Unico Hommes wrote:
On 30-okt-04, at 19:29, Stefano Mazzocchi wrote:
Ugo Cei wrote:
Il giorno 25/ott/04, alle 19:14, Unico Hommes ha scritto:
I've completed the changes to the build system discussed earlier
[1]. In order to do so I have extended the gump descriptor with
ad
Ralph Goers wrote:
> >No :) our policy says that no incompatible changes should
> occur between
> >maintenance releases. They might happen between minor
> version changes.
> >Now of course these rules are not fixed which means we can
> decide on a
> >case by case basis.
> >
> >Carsten
> >
>
On 30-okt-04, at 19:29, Stefano Mazzocchi wrote:
Ugo Cei wrote:
Il giorno 25/ott/04, alle 19:14, Unico Hommes ha scritto:
I've completed the changes to the build system discussed earlier
[1]. In order to do so I have extended the gump descriptor with
additional information that allows the build s
Carsten Ziegeler wrote:
Ralph Goers wrote:
I believe the policy says that these sort of changes (like deprecating
something) require that they be announced in one maintenance
release and then they can be put in the next. So this change
can only happen in 2.1.7, if I have it right.
No
Ugo Cei wrote:
Il giorno 25/ott/04, alle 19:14, Unico Hommes ha scritto:
I've completed the changes to the build system discussed earlier [1].
In order to do so I have extended the gump descriptor with additional
information that allows the build system to locate one or more
dependency jars per
Ralph Goers wrote:
> I believe the policy says that these sort of changes (like deprecating
> something) require that they be announced in one maintenance
> release and then they can be put in the next. So this change
> can only happen in 2.1.7, if I have it right.
>
No :) our policy says tha
Vadim Gritsenko wrote:
Ugo Cei wrote:
Looks like this is not a backward-compatible change. Blocks which are
distributed outside of Cocoon (like Fins or my Spring Petstore) must
change their deployment instructions to add all those
elements (and put dependencies in gump too, which wasn't require
Il giorno 30/ott/04, alle 15:49, Vadim Gritsenko ha scritto:
It was required for libs dependencies cleanup. Before, you either had
to duplicate the lib, or put fake dependency between blocks. Now we
can cleanup these unnecessary dependencies, and build will find
required libs for the blocks.
I c
Ugo Cei wrote:
Il giorno 25/ott/04, alle 19:14, Unico Hommes ha scritto:
I've completed the changes to the build system discussed earlier [1].
In order to do so I have extended the gump descriptor with additional
information that allows the build system to locate one or more
dependency jars per
Il giorno 25/ott/04, alle 19:14, Unico Hommes ha scritto:
I've completed the changes to the build system discussed earlier [1].
In order to do so I have extended the gump descriptor with additional
information that allows the build system to locate one or more
dependency jars per project within
Stefano Mazzocchi wrote:
Vadim Gritsenko wrote:
Two points;
* Gump is about continuous integration, i.e. always trunk, right?
so far ;-)
And our build does not need version information too. Then,
who needs it?
My idea is the following: gump should be *both* a build system and a
continous
Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
We really gotta start thinking about our build system and gump
integration.
Vadim Gritsenko wrote:
Unico Hommes wrote:
I've completed the changes to the build system discussed earlier
[1]. In order to do so I have extended the gump descriptor with
Stefano Mazzocchi wrote:
We really gotta start thinking about our build system and gump integration.
Vadim Gritsenko wrote:
Unico Hommes wrote:
I've completed the changes to the build system discussed earlier [1].
In order to do so I have extended the gump descriptor with additional
information t
We really gotta start thinking about our build system and gump integration.
Vadim Gritsenko wrote:
Unico Hommes wrote:
I've completed the changes to the build system discussed earlier [1].
In order to do so I have extended the gump descriptor with additional
information that allows the build syst
On 25-okt-04, at 20:35, Vadim Gritsenko wrote:
Unico Hommes wrote:
I've completed the changes to the build system discussed earlier [1].
In order to do so I have extended the gump descriptor with additional
information that allows the build system to locate one or more
dependency jars per proje
Unico Hommes wrote:
I've completed the changes to the build system discussed earlier [1]. In
order to do so I have extended the gump descriptor with additional
information that allows the build system to locate one or more
dependency jars per project within ./lib/optional. See for an
example t
I've completed the changes to the build system discussed earlier [1]. In
order to do so I have extended the gump descriptor with additional
information that allows the build system to locate one or more
dependency jars per project within ./lib/optional. See for an
example the cocoon-block-axis
21 matches
Mail list logo
