Hi Alex ...
So let me copy this from the official maven documentation found here:
https://maven.apache.org/guides/introduction/introduction-to-profiles.html
"Profiles can also be active by default using a configuration like the
following:
<profiles>
<profile>
<id>profile-1</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
...
</profile>
</profiles>
This profile will automatically be active for all builds unless another profile
in the same POM is activated using one of the previously described methods. All
profiles that are active by default are automatically deactivated when a
profile in the POM is activated on the command line or through its activation
config."
I have no Idea why you needed to disable the profile, but I have to admit in
the old state the hierarchies of profiles was a nightmare.
My concern it that we should keep things simple for the new contributors and
for the normal workflow, even if this makes things more complicated for one
execution during a release which is currently done once a year. Ok you are
planning on speeding things up a little, but even if it's one execution per
month, this should not have a negative effect on every build done multiple
times a day by multiple people.
Stackoverflow is not a good tutor ... you usually get one answer that might
address the one problem you were having but that usually doesn't know about the
other constraints. Also you really don't get good explanations most of the time
so you don't even know what you're doing and what the implications are. I would
consider myself a Maven expert with really a lot of experience with different
situations. So please trust my before copy-pasting some half-baked "solution"
from stack overflow.
I will do my best to help you folks help you adjust the ant scripts as much as
possible.
Chris
Am 01.05.20, 10:04 schrieb "Alex Harui" <[email protected]>:
Hi Chris,
If what you say about "activeByDefault" is true, I don't understand why I
had to specify "-main" in the profiles in the releasesteps in order to get this
to work in the past. If we restore the "main" profile that is activebydefault,
I don't understand why the other profiles couldn't activate the "main" profile.
My concern is that specifying no modules as we used to is not quite the
same as specifying a single project called royale-framework-parent which isn't
clear to me that it is a module or project, and there will be difference that
we have to spend time looking for.
My 2 cents,
-Alex
I have to stop work for tonight, so will see where we are in my morning.
On 5/1/20, 12:56 AM, "Christofer Dutz" <[email protected]> wrote:
Hi Yishay,
relying on "activeByDefault" is bad. Cause as soon as you just select
one single other profile, the activeByDefault profile gets disabled.
So if you have a profile "buildMainModules" and that's active by
default, and (as the name says) adds the main modules and you now want to have
them also build the SWF parts, you enable "witt-swf" profile and nothing is
built at all ... now you manually need to enable the buildMainModules profile
too to continue. That's just bad style.
So if the maven folks have to live with this inconvenience just because
in case of an Ant scripted release you didn't want to just add “-pl
royale-framework-parent" or even "-pl ." (which should do the same) ... then I
can't help you folks.
Chris
Am 01.05.20, 09:26 schrieb "Yishay Weiss" <[email protected]>:
Hi Chris,
Can you explain why the cleanup was necessary? If Alex is right,
and as a result of this cleanup is that an Ant tasks in releasesteps.xml is no
longer working as expected, then someone needs to spend time to make sure the
rest of the tasks are.
It could be that the best way ends up keeping your changes and
adding “-pl royale-framework-parent” to the wagon call, but I’d like to make
sure this refactor is actually necessary. Frankly, I don’t think it should have
been merged in without testing the release steps.
Thanks,
Yishay
From: Christofer Dutz<mailto:[email protected]>
Sent: Friday, May 1, 2020 10:01 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: wagon:upload problems
I Alex,
If you do that you're undoing all the cleanup I had been doing.
Please don't do that.
I sent you what's needed to make it run in only one module, so
could you please just use that?
I also said there were two things wrong. Uploading it for every
module was one and the included pattern being wrong s the second. If you fix
both, you should be set.
Chris
________________________________
Von: Alex Harui <[email protected]>
Gesendet: Freitag, 1. Mai 2020 08:29
An: [email protected] <[email protected]>
Betreff: Re: wagon:upload problems
Could be that the answer is in this commit:
9e410b29b5f11c832a0005a7feb6d85d6419d3ac
The way it was setup before was that all <modules> were specified
in profiles. If you look at the Upload task from that commit, it turns off the
main profile and enables the upload profile thus keeping wagon from rummaging
through the modules. I think if we set it up that way again, it will work
better.
HTH,
-Alex
On 4/30/20, 10:55 PM, "Alex Harui" <[email protected]> wrote:
Looking through the history, it looks like we've been trying to
get Maven to not have Wagon run on the modules. Here's a post that implies
that the way we specified the modules in the profile should have kept the
submodules from running:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F10682186%2Fin-maven-can-a-profile-override-the-modules-to-not-include-any&data=02%7C01%7Caharui%40adobe.com%7Cc5b527930a4c406e79f708d7eda51ec4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239165756301163&sdata=q%2BPQ9%2Bf9WvVSL3e0x%2FGr3ao7wMVgbJgdrNkxuWQXAdM%3D&reserved=0
It is interesting that the mechanism in that post seems to no
longer be working. But it is definitely the goal to not have the submodules in
the run.
HTH,
-Alex
On 4/30/20, 2:51 PM, "Alex Harui" <[email protected]>
wrote:
Yes, Yishay should try that the "-pl
royale-framework-parent" but will it then search for artifacts generated by the
submodules? I got concerned when you said there would only be one .asc file.
There should be one per .swc.
Don't know if it is related, but I went to the staging
server and found that there were several staging repos open. I thought it
wouldn't open a new one until the previous one was closed. None of the staging
repos are complete. Some contain only compiler and typedefs. Others the
framework but with examples and manualtests as sibling to framework. In the
past all 3 of compiler, typedefs, and framework end up in the staging repo.
Thus, we need to understand how staging repos work. Does it open a staging
repo per IP?
Thanks
-Alex
On 4/30/20, 2:43 PM, "Christofer Dutz"
<[email protected]> wrote:
Hi folks,
are you actually reading what I wrote? I thought I had
explained why it's running so often?
You can see that it's executing the upload thing for
every maven module in the project (You can see the titles of the projects
changing)
Please just try and add the "-pl
royale-framework-parent" to the command line and it should only run for the
main module.
And if you adjust the "include" pattern back to
"**/*.asc" then it should deploy all asc files.
I would also expect this to be the root cause of the
general deployment problems ...
I could imagine if you deploy every artifact 160 times
that Nexus might kick you.
Chris
Am 30.04.20, 23:37 schrieb "Yishay Weiss"
<[email protected]>:
I’m out of time for the next 16 hours or so. BTW,
the artifacts were probably uploaded days ago. So in theory we could continue
with the release and figure this out at some other time.
Thanks.
From: Alex Harui<mailto:[email protected]>
Sent: Friday, May 1, 2020 12:32 AM
To:
[email protected]<mailto:[email protected]>
Subject: Re: wagon:upload problems
I hope to have time to think about this more later
(about 7 hours). I think we want to run Wagon in a way that from the main pom,
it will know about all of the artifacts to upload from all of the SWCs, etc.
I think that's what the reactor does (look through
the poms) but it seems to want to upload the parent source-release every time.
So maybe try the param Chris suggested so it only tries framework-parent, but
then it might miss the other artifacts.
BTW, do you have a log of the typedefs upload to
see if it did the same thing?
-Alex
On 4/30/20, 2:26 PM, "Yishay Weiss"
<[email protected]> wrote:
> My hunch is that specifying <includes> causes
this loop.
That wasn’t it. It completed one run and went
on to the next run. I now realize that instead of waiting for it to finish and
seeing whether or not it’ll run again I can just look at this line, which
happens in the beginning
Building Apache Royale: Framework: Themes:
Jewel-Light-NoFlat-Secondary-Violet-Theme 0.9.7 [66/157]
66/157 means it’s gonna run 157 times before it
finished.
From: Alex
Harui<mailto:[email protected]>
Sent: Thursday, April 30, 2020 10:49 PM
To:
[email protected]<mailto:[email protected]>
Subject: Re: wagon:upload problems
Hi Chris,
As I understand it, Yishay is only running one
Wagon call. The Jewel calls are not being run, but in that one Wagon call, the
source-release for the parent is being uploaded many times and it doesn't look
like it is trying to upload the artifacts. Check out the log he posted at [1].
How did we give the commands incorrectly that caused it to do what it did?
[1]
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Ftpdkh&data=02%7C01%7Caharui%40adobe.com%7Cc5b527930a4c406e79f708d7eda51ec4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239165756301163&sdata=AH%2FiNcm%2F6uSUsgWfNwRMqRxhnecMt3OfyOvPY4UlpYU%3D&reserved=0
On 4/30/20, 12:41 PM, "Christofer Dutz"
<[email protected]> wrote:
Hi folks,
Just to try it out ... almost anyone that
has setup his credentials in the settings.xml could try to deploy asjs by
running:
mvn clean deploy
-Papache-release,apache-release,with-distribution,option-with-swf
On the develop branch.
It would automatically build the same
artifacts, sign them and instead of creating a staging repo, would upload them
to the SNAPSHOT repo.
Would be really interesting on if you
really are having these upload problems. And I mean anyone could test this
without having to be RM.
It's just one command, nothing more and you
can't even mess up anything as the code isn't changed.
And by the way ... the releasesteps.xml
does actually deploy a large portion of the artifacts multiple times ...
The ant target uploadSWCs already deploys
the entire artifact tree ... there's no need for uploadJewelDark and
uploadJewelLight
Chris
Am 30.04.20, 20:43 schrieb "Alex Harui"
<[email protected]>:
Gee I hope that didn't cause that IP to
be blocked by Apache. Keep that in mind if you have trouble uploading from the
CI server next time you try. Find the IP address of the CI server and ask
Infra if it got blocked. There is a chance that Azure blocked as well. I
guess I'll find out if I have to pay Azure a huge bandwidth overage bill or not.
It does tell us something about the
reliability of the connection on a windows machine in the US vs your computer
outside the US.
Anyway, I think you can test locally
with the .asc files and figure out the right params.
Good luck,
-Alex
On 4/30/20, 11:34 AM, "Yishay Weiss"
<[email protected]> wrote:
I suspect this might be related to
recent maven profile changes not meshing well with the release script targets.
I’ll see what I can dig up.
From: Yishay
Weiss<mailto:[email protected]>
Sent: Thursday, April 30, 2020 9:32
PM
To:
[email protected]<mailto:[email protected]>
Subject: RE: wagon:upload problems
>I think it might be repeating the
upload for each project.
Upload happens 67 times [1] in a
loop. That explains why even on the CI server after 5.5 hours it finally failed
[2].
[1]
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Fzh3rj&data=02%7C01%7Caharui%40adobe.com%7Cc5b527930a4c406e79f708d7eda51ec4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637239165756301163&sdata=4QXwlQfxtrs1qrvnkdnDJ9z7oyAc2ENxbn%2BkqK4uVwg%3D&reserved=0
[2]
[exec] [INFO] BUILD FAILURE
[exec] [INFO]
------------------------------------------------------------------------
[exec] [INFO] Total time:
05:36 h
[exec] [INFO] Finished at:
2020-04-30T18:01:58Z
[exec] [INFO]
------------------------------------------------------------------------
[exec] [ERROR] Failed to
execute goal org.codehaus.mojo:wagon-maven-plugin:2.0.0:upload (default-cli) on
project Effects: Error handling resource: Failed to transfer file http
s://repository.apache.org/service/local/staging/deploy/maven2/org/apache/royale/framework/Jewel-Light-NoFlat-Emphasized-Emerald-Theme/0.9.7/Jewel-Light-NoFlat-Emphasized-Emerald-Th
eme-0.9.7-js.swc with status code
400 -> [Help 1]
[exec]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.codehaus.mojo:wagon-maven-plugin:2.0.0:upload (default-cli) on project
Effects: Error
handling resource
