Hi all,
I have started and made good progress on getting Maven resolver all into the
master branch instead of having master, demos and ant-tasks in separate
branches.
Details are tracked in https://issues.apache.org/jira/browse/MRESOLVER-28
All of it is now in a new branch called master-all fo
Am 2017-11-15 um 23:05 schrieb Hervé BOUTEMY:
it seems I have not been clear: I'll try to explain better
1. maven-resolver-ant-tasks depends on maven-resolver-provider (from Maven
core)
2. maven-resolver-provider (then Maven core) depends on maven-resolver
if we put maven-resolver-ant-tasks in
Status update and questions:
- demos are all now in master and part of the multi module build
- no changes on the ant tasks for now
Questions:
1. Can I delete the demos branch now or do we wait until next release? I would
prefer to delete the branch and close the ticket to be honest.
2. I lik
On Thu 23 Nov 2017 at 04:20, Manfred Moser wrote:
> Status update and questions:
>
> - demos are all now in master and part of the multi module build
> - no changes on the ant tasks for now
>
> Questions:
>
> 1. Can I delete the demos branch now or do we wait until next release? I
> would prefer
So how do I make this repo copy happen? An infra ticket or something like that?
Stephen Connolly wrote on 2017-11-22 23:53:
> On Thu 23 Nov 2017 at 04:20, Manfred Moser wrote:
>
>> Status update and questions:
>>
>> - demos are all now in master and part of the multi module build
>> - no chang
Hervé might know... could be self-service on gitbox!
I have two repos to create after the Jenkins Server is upgraded on Sunday,
so let me know the process
On Thu 23 Nov 2017 at 16:13, Manfred Moser wrote:
> So how do I make this repo copy happen? An infra ticket or something like
> that?
>
> St
yes, that's GitBox self service [1], easy to use, just:
1. start by choosing your PMC before doing any other change (or you may create
a "maven-maven-something.git" like I did)
2. change "GitHub notification list" to iss...@maven.apache.org
the only issue I see is the mix of Artifact Resolver on
So .. I tried this now. Seems like something on gitbox is not configured
correctly for me because the Your PMCs drop down contains no entries apart from
Your PMCs.
Can someone either fix this for me or create maven-resolver-ant-tasks
repository? Then I can do the rest.
thx
manfred
Hervé BOUT
ok, done: https://github.com/apache/maven-resolver-ant-tasks
Regards,
Hervé
Le samedi 25 novembre 2017, 22:07:12 CET Manfred Moser a écrit :
> So .. I tried this now. Seems like something on gitbox is not configured
> correctly for me because the Your PMCs drop down contains no entries apart
> f
Awesome ... setting up my github account and such now. In terms of pom.xml ..
should the scm info just point to github then?
Manfred
Hervé BOUTEMY wrote on 2017-11-25 14:00:
> ok, done: https://github.com/apache/maven-resolver-ant-tasks
>
> Regards,
>
> Hervé
>
> Le samedi 25 novembre 2017,
please look at what I did in Doxia or skins: I chose to point to gitbox for
connection and developerConnection and github for url
that's only a convention in our pom.xml: but gitbox and github work
Regards,
Hervé
Le samedi 25 novembre 2017, 23:08:27 CET Manfred Moser a écrit :
> Awesome ... set
All done on demos including cleanup and closing the issue.
For the ant tasks everything is ready in the new repo. If someone could set up
the CI jenkins build that would be good.
Once we are happy I can delete the branch in the old repo.
And I think we also have to cut a release of the ant task
All done on the ant-tasks migration now as well.
Next would be a release of the ant-tasks for which I filed
https://issues.apache.org/jira/browse/MRESOLVER-37
Imho we should do that but I don't know what is involved and wont be able to
work on it until some time in January.
manfred
Hi,
I like the idea of simplification: I just factorized mavenVersion property to
parent pom.
I have only one fear: what happens when the API changes in an incompatible way
then we must release maven-artifact-resolver, then maven-resolver provider,
then ant-tasks and demos.
AFAIK, this chicke
Any feedback or should I just go ahead with the cleanup?
Manfred
Manfred Moser wrote on 2017-11-08 21:35:
> Hi all,
>
> I have started and made good progress on getting Maven resolver all into the
> master branch instead of having master, demos and ant-tasks in separate
> branches.
>
> Details
I answered on the mailing list and on the 2 Jira issues
In summary, +1 to merge demos, -1 to merge ant-tasks
Regards,
Hervé
Le mardi 14 novembre 2017, 18:19:40 CET Manfred Moser a écrit :
> Any feedback or should I just go ahead with the cleanup?
>
> Manfred
>
> Manfred Moser wrote on 2017-11-
Why -1 on the Ant tasks?
Am 2017-11-15 um 00:50 schrieb Hervé BOUTEMY:
I answered on the mailing list and on the 2 Jira issues
In summary, +1 to merge demos, -1 to merge ant-tasks
Regards,
Hervé
Le mardi 14 novembre 2017, 18:19:40 CET Manfred Moser a écrit :
Any feedback or should I just go
Sorry herve. For some reason I totally missed those. I commented on the issues.
In summary I would like to get the ant-tasks merged as well since that makes a
lot more sense to me than keeping it separate.
Manfred
Hervé BOUTEMY wrote on 2017-11-14 15:50:
> I answered on the mailing list and
it seems I have not been clear: I'll try to explain better
1. maven-resolver-ant-tasks depends on maven-resolver-provider (from Maven
core)
2. maven-resolver-provider (then Maven core) depends on maven-resolver
if we put maven-resolver-ant-tasks in the same reactor than maven-resolver, we
can't
let's start with demos: this one is really a great idea
on ant-tasks, I hope my new explanations make the issue more clear
Regards,
Hervé
Le mercredi 15 novembre 2017, 18:39:06 CET Manfred Moser a écrit :
> Sorry herve. For some reason I totally missed those. I commented on the
> issues.
>
> I
I just pushed an update of dependencies image that shows the external maven-
resolver-provider (in yellow) inside the reactor dependency graph (in blue)
That shows the chicken and egg issue on releasing we'll have on API breaking
change. People always building from source (like Debian) will have
On Thu 16 Nov 2017 at 07:51, Hervé BOUTEMY wrote:
> I just pushed an update of dependencies image that shows the external
> maven-
> resolver-provider (in yellow) inside the reactor dependency graph (in blue)
>
> That shows the chicken and egg issue on releasing we'll have on API
> breaking
> cha
feasible, but I really don't like it: separation is good.
seriously, just merge demos and let ant-tasks separate, and we have a pretty
good compromise on every aspect
(or even drop ant tasks if really this is causing us too much headache...)
Regards,
Hervé
Le jeudi 16 novembre 2017, 10:03:07 C
Thanks for the explanation and details Herve. Seems to be that to do this
cleanly we have to break the circle. From my limited knowledge there are two
ways to do that.
1. As stephen suggested.. get the resolver into maven core tree. That makes
core bigger again and ties the two projects into on
on the second option, I was ready to just answer "not possible", but decided I
could try at high level before answering...
I took Maven core dependency tree [1], picked green color as the definition of
Maven Artifact Resolver, put maven-resolver-provider in green + settings
builder (since used
attachment removed by mailing list
I put it in
https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0?
focusedCommentId=74687410&refresh=1510912447661#comment-74687410
Regards,
Hervé
Le vendredi 17 novembre 2017, 09:40:22 CET Hervé BOUTEMY a écrit :
> on the second option, I
"We can solve any problem by introducing an extra level of indirection."
[1]
Looking at this new image[1] it is weird to me that ant-tasks has a direct
dependency on maven-resolver-provider. I would have expected some provider
abstraction where you can choose to use the maven-resolver-provi
Hahah ... what a pain. Since so at this stage I think I will move the demos
into the master and leave the ant tasks as they stand and
close the relevant tickets with remarks that details this situation.
Manfred
Robert Scholte wrote on 2017-11-17 03:10:
> "We can solve any problem by introducin
this won't work: you'll be able to fool the compiler, but not maven-shade-
plugin when it builds the full jar with runtime dependencies
Regards,
Hervé
Le vendredi 17 novembre 2017, 12:10:49 CET Robert Scholte a écrit :
> "We can solve any problem by introducing an extra level of indirection."
>
29 matches
Mail list logo