On Saturday, 18 January 2014, Jason van Zyl ja...@takari.io wrote:
I don't think you want the CI element propagating. In the case of a
multi-module project you're likely only to have one CI job for that set of
projects.
But in the multi module case, the CI for the multi-module *is the exact
Hi,
just a question...based on the top right side on the site
Last Published: 2014-01-11
I have changed this in svn on 03. January of 2014 ...but i can't see
those change ?
Is anything special which has to be done ? Or has something gone wrong
or better how can i fix that ?
Kind regards
you updated parent pom on january 3rd
but it was deployed to snapshot repository only on 11th [1]
next site publication should catch the change
notice Jenkins should have done the job earlier: I just checked, and there is
a failure on poll [2]
I'll report on builds@a.o
Regards,
Hervé
[1]
Hi Hervé
i knew i overlooked something...
Thanks for the explanation...
Many thanks for help...
Kind regards
Karl Heinz Marbaise
notice Jenkins should have done the job earlier: I just checked, and
there is
a failure on poll [2]
I'll report on builds@a.o
Regards,
Hervé
[1]
Op Sun, 19 Jan 2014 09:59:25 +0100 schreef Stephen Connolly
stephen.alan.conno...@gmail.com:
On Saturday, 18 January 2014, Jason van Zyl ja...@takari.io wrote:
I don't think you want the CI element propagating. In the case of a
multi-module project you're likely only to have one CI job for
I don't think there are really any valid use cases for trying to build an
extension where it is used in the same reactor. Extensions really need to be
present before the reactor starts and trying to do this is a contortion I
really don't want to support.
I would like to close this as won't
no, quite the opposite, I will applaud the decision :)
Milos
On Sun, Jan 19, 2014 at 7:36 PM, Jason van Zyl ja...@takari.io wrote:
I don't think there are really any valid use cases for trying to build an
extension where it is used in the same reactor. Extensions really need to be
present
There are quite a number of users who want this functionality and the
corresponding ability to build a plugin from the same reactor as it is
consumed in.
Usually this is due to lazyness, ie not wanting to cut a release of a
plugin/extension just to make the build... Iow the use case were somebody
On Jan 19, 2014, at 2:13 PM, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
There are quite a number of users who want this functionality and the
corresponding ability to build a plugin from the same reactor as it is
consumed in.
Building a plugin in the same reactor works,
On Sunday, 19 January 2014, Jason van Zyl ja...@takari.io wrote:
On Jan 19, 2014, at 2:13 PM, Stephen Connolly
stephen.alan.conno...@gmail.com javascript:; wrote:
There are quite a number of users who want this functionality and the
corresponding ability to build a plugin from the same
That extensions are required very early on in the build and too support them
being produced in a build where they are additionally used would require
contortions in the core and would also make supporting this in the various IDEs
also very complicated.
Is what I would say.
On Jan 19, 2014, at
On Sun, Jan 19, 2014 at 9:09 PM, Jason van Zyl ja...@takari.io wrote:
That extensions are required very early on in the build and too support them
being produced in a build where they are additionally used would require
contortions in the core and would also make supporting this in the
Shouldn't we be able to detect such abuse and warn for it (maybe even
fail?).
Now it'll only work if the extension-plugin is available in the local
repo, which is probably not what users will expect. The plugin will always
be one step/execution behind compared to the reactor build.
Robert
Sure, so this issue I think can be closed and another one created to warn
people about attempting to build an extension for use in the same build.
On Jan 19, 2014, at 3:48 PM, Robert Scholte rfscho...@apache.org wrote:
Shouldn't we be able to detect such abuse and warn for it (maybe even
How about asking also asking this question: should all the function
currently in packaging need to be extensions? What users want is to
define certain kinds of things as one big build.
On Sun, Jan 19, 2014 at 4:06 PM, Jason van Zyl ja...@takari.io wrote:
Sure, so this issue I think can be closed
15 matches
Mail list logo
