Cool, just start creating these Jira issues.
The one you've mentioned is probably already covered by MNG-6444[1].
Depending on the set of changes, we can add related issues or just add
them here.
thanks,
Robert
[1] https://issues.apache.org/jira/browse/MNG-6444
On Fri, 02 Nov 2018
Hi Robert,
I'm Alex Porcelli and I work with Max. I can also create some jiras
about things that we couldn't do.
Here's an example (likely my first JIRA):
In our use case, all sources are stored in bare Git repositories and
we manipulate it using NIO2 API [1], if Maven accepted NIO2 Path
On Wed, 08 Aug 2018 09:49:17 +0200, Massimiliano Dessì
wrote:
Hi Robert
2018-08-07 18:35 GMT+02:00 Robert Scholte :
Hi Max,
regarding the contribution, I would like to propose the following:
- At least create a JIRA issue for every feature.
Can we start creating these JIRA issues? I'd
Hi Robert
2018-08-07 18:35 GMT+02:00 Robert Scholte :
> Hi Max,
>
> regarding the contribution, I would like to propose the following:
> - At least create a JIRA issue for every feature.
> - Due to the large amount of code I can imagine there are some
> dependencies between the features, i.e
Related to Incremental - idempotent builds would be good.
Having been exposed to Google's Blaze (now Bazel in OSSland) and directed
graph build system science (as opposed to recursive build systems) there's
a great efficiency from skipping parts of a build that don't need to be
done.
Also
Hi Max,
regarding the contribution, I would like to propose the following:
- At least create a JIRA issue for every feature.
- Due to the large amount of code I can imagine there are some
dependencies between the features, i.e some features should be implemented
first.
- Based on that we can
Hi Karl,
the first "public and official" version is here:
https://github.com/kiegroup/kie-wb-common/tree/master/kie-wb-common-services/kie-wb-common-compiler
one of the changes to do for the contribution is to replace our git FS NIO2
implementation with the JDK NIO2.
p.s.: One nice side effects
Hi Tibor
the pom is changed the rirst time the compiler discover the project,
it turning off the default Maven compiler and adding Takari,
I've contributed the failOnError flag in Takari projects because we need to
provide a real incremental behaviour
to the user, compile all the correct stuff and
Hi,
is the code somewhere available? Usable ?
kind regards
Karl Heinz Marbaise
On 06/08/18 13:15, Karl Heinz Marbaise wrote:
Hi,
On 06/08/18 11:16, Massimiliano Dessì wrote:
Hi all,
as a part of my daily job in Red Hat
I've worked on a "customization" of Maven for our Kie Workbench used
I am interested in the incremental builds.
Takari has some extension for incremental build, and there are also some
extensions for children in Maven multi-module project when you update it
via Git.
On Mon, Aug 6, 2018 at 11:16 AM, Massimiliano Dessì <
massimiliano.de...@gmail.com> wrote:
> Hi
Hi,
On 06/08/18 11:16, Massimiliano Dessì wrote:
Hi all,
as a part of my daily job in Red Hat
I've worked on a "customization" of Maven for our Kie Workbench used with
Drools, JBPM and Optaplanner.
The starting point was exports Objects created by Drools inside our Maven
plugin, but the
Hi all,
as a part of my daily job in Red Hat
I've worked on a "customization" of Maven for our Kie Workbench used with
Drools, JBPM and Optaplanner.
The starting point was exports Objects created by Drools inside our Maven
plugin, but the features are growed a lot.
A brief and not exhaustive list
12 matches
Mail list logo
