On Tue 7 Nov 2017 at 01:18, Charles Honton wrote:
> So doesn’t this require a new directive such as ‘ transitive=false”> scope or similar regardless of safe/rally points?
No. The plugin would have its descriptor metadata for the goal contain a
flag
Then the plugin is responsible for deciding w
On Tue 7 Nov 2017 at 01:32, Charles Honton wrote:
> Are these integration test for the plugin or do the integration tests use
> the plugin?
The integration tests use the plugin. (Though there are other use cases too)
If the former, then the invoker plugin is appropriate. If the latter, then
>
Are these integration test for the plugin or do the integration tests use the
plugin? If the former, then the invoker plugin is appropriate. If the latter,
then a non-code, non-transitive dependency scope is a possibility. Again, this
new scope has the backwards compatibility problem..
> On
So doesn’t this require a new directive such as ‘
scope or similar regardless of safe/rally points? And to provide backwards
compatibility, there must be a split between the legacy consumer view of the
pom and the new producer view of the pom?
> On Nov 5, 2017, at 11:30 PM, Stephen Connolly
Github user slachiewicz commented on the issue:
https://github.com/apache/maven/pull/118
This one can be closed.
---
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h..
'Lo.
I'm in the process of converting a ton of projects to Java 9 and am
currently blocked on MJAVADOC-498[0]. The issue has actually been
fixed, it just hasn't made it to a release yet.
If 3.0.0 isn't due for a while yet, is there any chance of getting a
3.0.0-M2?
[0] https://issues.apache.org/
Can't tackle it before next year but if not done in january sure.
2017-11-06 10:00 GMT+01:00 Stephen Connolly :
> FYI this seems something that doesnt need to wait for 4.0.0
>
> If there was a PR for this and enough other small changes I'd be happy to
> roll a 3.5.3
>
> Do you want to take a stab
Awesome work Hervé
Thanks a lot
For archetypes split I don't know. Technically we should split them and
they could have different lifecycles but in reality there is no real
activity thus I'm not sure it has some interest
On Sat, Nov 4, 2017 at 2:56 PM, Hervé BOUTEMY wrote:
> migration done [1]
FYI this seems something that doesnt need to wait for 4.0.0
If there was a PR for this and enough other small changes I'd be happy to
roll a 3.5.3
Do you want to take a stab at it?
(only complexity might be parallel execution, but we could just report the
linear plan number and when in parallel
indeed: https://issues.apache.org/jira/browse/MNG-6302
Romain Manni-Bucau
@rmannibucau | Blog | Old Blog | Github | LinkedIn
2017-11-06 9:37 GMT+01:00 Stephen Connolly :
> On Mon 6 Nov 2017 at 08:13, Romain Manni-Bucau
> wrote:
>
>> Forgot a user wish feature: some progress logging somehow. On
Thinking some more, this might be something we could leverage for
incremental builds.
If we save state at the end of each phase (last modified time stamps, hash
of dependencies, etc, also attached artifacts, additional source/resource
roots etc) then, on subsequent builds, if the state file is pre
On Mon 6 Nov 2017 at 08:13, Romain Manni-Bucau
wrote:
> Forgot a user wish feature: some progress logging somehow. On "big" project
> (actually on project logging a lot) you are easily lost on the progress,
> you know current module is X but you don't know anymore if it is 50% of the
> build or 5
Forgot a user wish feature: some progress logging somehow. On "big" project
(actually on project logging a lot) you are easily lost on the progress,
you know current module is X but you don't know anymore if it is 50% of the
build or 5%. Having at least "module X / Y" would be helpful. IMO it is
en
13 matches
Mail list logo