[JBoss JIRA] (JBIDE-21105) Remove BIRT?
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21105?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-21105:
------------------------------------
Steps 1-3 are done:
{quote}1. Update our TP to whatever jetty 9.3.* we need (and what is included in neon) for livereload, browsersim, etc.
2. Remove other jettys from our TP.
3. Update birt to the latest version in our TP. {quote}
I will continue to watch for new Birt in Neon as we move closer to Neon.0.
> Remove BIRT?
> ------------
>
> Key: JBIDE-21105
> URL: https://issues.jboss.org/browse/JBIDE-21105
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: birt, target-platform
> Affects Versions: 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.4.0.Alpha1
>
> Attachments: birt-4.5-vs-mars-interim.txt, birt-4.5-vs-mars-interim_summary.txt, birt-depends-on-jetty-deploy-929.png, birt-depends-on-jetty-osgi-boot-929.png, birt-wizard-new-library.png, birt-wizard-new-library__NEON.png, birt-wizards.png, birt-wizards__NEON.png, eclipse-after-birt.png, install-jboss-birt-sites.png, install-jboss-birt-sites__NEON.png, install-jboss-birt.png, install-jboss-birt__NEON.png
>
>
> {quote}
> (2015-11-17 11:42:50) kmarmaliykov: nickboldt: I look into neon M3 and see that there is no jetty 9.2.9 there
> (2015-11-17 11:43:18) nickboldt: kmarmaliykov: yes, 9.2.9 is from Birt site
> (2015-11-17 11:43:21) nickboldt: because Birt needs it
> (2015-11-17 11:43:33) nickboldt: but there's no Birt for Neon yet so we have to include the Birt for Mars
> (2015-11-17 11:43:37) maxandersen: nickboldt: akazakov: are you talking about having birt in Neon ?
> (2015-11-17 11:43:44) maxandersen: afaik birt is dead.
> (2015-11-17 11:43:53) maxandersen: won't participate in neon release afaik.
> (2015-11-17 11:43:56) nickboldt: maxandersen: so we should remove birt from JBT 4.4?
> (2015-11-17 11:44:24) maxandersen: well, check first if birt is actually in neon. if it is not the decision is very easy.
> (2015-11-17 11:44:38) akazakov: +1
> (2015-11-17 11:45:36) maxandersen: if it is in, then lets talk options. but if birt requires us to jump through too many hoops its not worth keeping it in.
> (2015-11-17 11:45:55) nickboldt: birt 4.5.0.v201506092134 is in Neon from 201511131000 (M3) - http://download.eclipse.org/releases/neon/201511131000/
> (2015-11-17 11:47:08) nickboldt: and there's a newer birt 4.5.0.v201510231925 (same major.minor.service, newer datestamp) in http://download.eclipse.org/birt/update-site/mars-interim/
> {quote}
> So, yesterday as part of updates for JBIDE-20976, I pulled a new BIRT mirror here:
> http://download.jboss.org/jbosstools/updates/requirements/birt/4.5.0.v201...
> But we could also just use the old one from Mars.0:
> http://download.jboss.org/jbosstools/updates/requirements/birt/4.5.0.v201...
> Or we could remove support for BIRT and its webtools / charting integration entirely from JBT 4.4.0.Alpha1, since as Max says BIRT is at EOL.
> *DISCUSS*.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-18876) Improve TP publishing so changes released to git or deployed to nexus would not break developer local builds
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18876?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-18876:
------------------------------------
So, you want me to publish TPs like we do component jobs, using rysnc.sh and publishing 1+ build folders into this location:
http://download.jboss.org/jbosstools/neon/snapshots/builds/
That would certainly be doable for the bits on dl.jb.org/ds.rh.c but I'm not sure that would help w/ the lag between "new bits on dl server" and "new entity in nexus". But if the nexus entity just points to the .target which points to builds/TP-job/latest/composite*.xml then the change seen by the dl server would be much smaller than a full 1G republish, and would (hopefully) appear faster.
Anyway, I'm good to try migrating the TP publishing to use the rsync.sh system, since it appears that that would solve at least MOST of your issues here.
Would you agree that our current solution for everything in /builds/<JOB_NAME>/latest/ works for you most of the time, and the only thing still prone to failure is the /targetplatforms/ content?
> Improve TP publishing so changes released to git or deployed to nexus would not break developer local builds
> ------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-18876
> URL: https://issues.jboss.org/browse/JBIDE-18876
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.0.Alpha1
> Reporter: Denis Golovin
> Assignee: Denis Golovin
> Fix For: 4.4.0.Alpha1
>
>
> Latest Thym update is 'good' example for this problem. I was in the middle of testing some changes in parent/pom.xml and suddenly build start to fail with Thym resolution problem. IMO what happened is TP .target files were published to nexus before actual p2-repos appeared online. Building from latest revision didn't help ether because of the same problem. I had to revert to previous revision to continue my task.
> So it would be good if TP builds publish binaries first and then release TP sources to git and deploy to nexus.
> Please note, that when sftp/rsync for unified TP binaries is finished it doesn't mean p2-repos are available from download.jboss.org right away.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-18876) Improve TP publishing so changes released to git or deployed to nexus would not break developer local builds
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18876?page=com.atlassian.jira.plugi... ]
Denis Golovin commented on JBIDE-18876:
---------------------------------------
We should do that step by step with these facts in mind:
1. Builds might be running at the same time while we deploying new tp over current one;
2. Even tp p2 repo synchronization is over it is still no available for public and time to sync it with public server may vary;
3. Before new TP published in nexus it should be verified against public url and it should not be published until it is valid (see point 2);
4. compositeArtifacts.xml should be updated first with new uploaded tp and then compositeContent.xml to prevent "missing artifact" errors;
5. before deleting child tp repo from composite repo compositeContent.xml should be updated first and then compositeArtifacts.xml;
6. Some builds can have slow connection so we have to keep previously published TP for some time and then run clean up script and remove child repos that are not referenced in xml files.
> Improve TP publishing so changes released to git or deployed to nexus would not break developer local builds
> ------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-18876
> URL: https://issues.jboss.org/browse/JBIDE-18876
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.0.Alpha1
> Reporter: Denis Golovin
> Assignee: Denis Golovin
> Fix For: 4.4.0.Alpha1
>
>
> Latest Thym update is 'good' example for this problem. I was in the middle of testing some changes in parent/pom.xml and suddenly build start to fail with Thym resolution problem. IMO what happened is TP .target files were published to nexus before actual p2-repos appeared online. Building from latest revision didn't help ether because of the same problem. I had to revert to previous revision to continue my task.
> So it would be good if TP builds publish binaries first and then release TP sources to git and deploy to nexus.
> Please note, that when sftp/rsync for unified TP binaries is finished it doesn't mean p2-repos are available from download.jboss.org right away.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21105) Remove BIRT?
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21105?page=com.atlassian.jira.plugi... ]
Denis Golovin commented on JBIDE-21105:
---------------------------------------
I keep having this issue JBIDE-18876 then
> Remove BIRT?
> ------------
>
> Key: JBIDE-21105
> URL: https://issues.jboss.org/browse/JBIDE-21105
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: birt, target-platform
> Affects Versions: 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.4.0.Alpha1
>
> Attachments: birt-4.5-vs-mars-interim.txt, birt-4.5-vs-mars-interim_summary.txt, birt-depends-on-jetty-deploy-929.png, birt-depends-on-jetty-osgi-boot-929.png, birt-wizard-new-library.png, birt-wizard-new-library__NEON.png, birt-wizards.png, birt-wizards__NEON.png, eclipse-after-birt.png, install-jboss-birt-sites.png, install-jboss-birt-sites__NEON.png, install-jboss-birt.png, install-jboss-birt__NEON.png
>
>
> {quote}
> (2015-11-17 11:42:50) kmarmaliykov: nickboldt: I look into neon M3 and see that there is no jetty 9.2.9 there
> (2015-11-17 11:43:18) nickboldt: kmarmaliykov: yes, 9.2.9 is from Birt site
> (2015-11-17 11:43:21) nickboldt: because Birt needs it
> (2015-11-17 11:43:33) nickboldt: but there's no Birt for Neon yet so we have to include the Birt for Mars
> (2015-11-17 11:43:37) maxandersen: nickboldt: akazakov: are you talking about having birt in Neon ?
> (2015-11-17 11:43:44) maxandersen: afaik birt is dead.
> (2015-11-17 11:43:53) maxandersen: won't participate in neon release afaik.
> (2015-11-17 11:43:56) nickboldt: maxandersen: so we should remove birt from JBT 4.4?
> (2015-11-17 11:44:24) maxandersen: well, check first if birt is actually in neon. if it is not the decision is very easy.
> (2015-11-17 11:44:38) akazakov: +1
> (2015-11-17 11:45:36) maxandersen: if it is in, then lets talk options. but if birt requires us to jump through too many hoops its not worth keeping it in.
> (2015-11-17 11:45:55) nickboldt: birt 4.5.0.v201506092134 is in Neon from 201511131000 (M3) - http://download.eclipse.org/releases/neon/201511131000/
> (2015-11-17 11:47:08) nickboldt: and there's a newer birt 4.5.0.v201510231925 (same major.minor.service, newer datestamp) in http://download.eclipse.org/birt/update-site/mars-interim/
> {quote}
> So, yesterday as part of updates for JBIDE-20976, I pulled a new BIRT mirror here:
> http://download.jboss.org/jbosstools/updates/requirements/birt/4.5.0.v201...
> But we could also just use the old one from Mars.0:
> http://download.jboss.org/jbosstools/updates/requirements/birt/4.5.0.v201...
> Or we could remove support for BIRT and its webtools / charting integration entirely from JBT 4.4.0.Alpha1, since as Max says BIRT is at EOL.
> *DISCUSS*.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-18876) Improve TP publishing so changes released to git or deployed to nexus would not break developer local builds
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18876?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-18876:
------------------------------------
6 months later, no better suggestions for a workflow that would avoid the problem of "waiting for bits to appear before pushing a new .target file to nexus".
maybe we could implement a sleep period between steps 4 and 5?
or we could composite "previous instance of the same snapshot version" with "latest instance of the same snapshot version" into a single URL, as we do for JBT component sites. That'll double the disk usage (each TP instance is 977 - 1.1G because it includes both the TP and the TP zip), but might save these once-a-month instances of TP updates causing builds to fail for 30-60 mins while a new change is rebuilt.
> Improve TP publishing so changes released to git or deployed to nexus would not break developer local builds
> ------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-18876
> URL: https://issues.jboss.org/browse/JBIDE-18876
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.0.Alpha1
> Reporter: Denis Golovin
> Assignee: Denis Golovin
> Fix For: 4.4.0.Alpha1
>
>
> Latest Thym update is 'good' example for this problem. I was in the middle of testing some changes in parent/pom.xml and suddenly build start to fail with Thym resolution problem. IMO what happened is TP .target files were published to nexus before actual p2-repos appeared online. Building from latest revision didn't help ether because of the same problem. I had to revert to previous revision to continue my task.
> So it would be good if TP builds publish binaries first and then release TP sources to git and deploy to nexus.
> Please note, that when sftp/rsync for unified TP binaries is finished it doesn't mean p2-repos are available from download.jboss.org right away.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-18876) Improve TP publishing so changes released to git or deployed to nexus would not break developer local builds
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18876?page=com.atlassian.jira.plugi... ]
Denis Golovin updated JBIDE-18876:
----------------------------------
Fix Version/s: 4.4.0.Alpha1
(was: 4.4.x)
> Improve TP publishing so changes released to git or deployed to nexus would not break developer local builds
> ------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-18876
> URL: https://issues.jboss.org/browse/JBIDE-18876
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.0.Alpha1
> Reporter: Denis Golovin
> Assignee: Denis Golovin
> Priority: Minor
> Fix For: 4.4.0.Alpha1
>
>
> Latest Thym update is 'good' example for this problem. I was in the middle of testing some changes in parent/pom.xml and suddenly build start to fail with Thym resolution problem. IMO what happened is TP .target files were published to nexus before actual p2-repos appeared online. Building from latest revision didn't help ether because of the same problem. I had to revert to previous revision to continue my task.
> So it would be good if TP builds publish binaries first and then release TP sources to git and deploy to nexus.
> Please note, that when sftp/rsync for unified TP binaries is finished it doesn't mean p2-repos are available from download.jboss.org right away.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-18876) Improve TP publishing so changes released to git or deployed to nexus would not break developer local builds
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18876?page=com.atlassian.jira.plugi... ]
Denis Golovin updated JBIDE-18876:
----------------------------------
Priority: Major (was: Minor)
> Improve TP publishing so changes released to git or deployed to nexus would not break developer local builds
> ------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-18876
> URL: https://issues.jboss.org/browse/JBIDE-18876
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.0.Alpha1
> Reporter: Denis Golovin
> Assignee: Denis Golovin
> Fix For: 4.4.0.Alpha1
>
>
> Latest Thym update is 'good' example for this problem. I was in the middle of testing some changes in parent/pom.xml and suddenly build start to fail with Thym resolution problem. IMO what happened is TP .target files were published to nexus before actual p2-repos appeared online. Building from latest revision didn't help ether because of the same problem. I had to revert to previous revision to continue my task.
> So it would be good if TP builds publish binaries first and then release TP sources to git and deploy to nexus.
> Please note, that when sftp/rsync for unified TP binaries is finished it doesn't mean p2-repos are available from download.jboss.org right away.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21120) Why do we deploy TP zips to Nexus snapshots repo?
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21120?page=com.atlassian.jira.plugi... ]
Denis Golovin commented on JBIDE-21120:
---------------------------------------
if we don't consume zips from nexus I don't see any reason to keep deploying them.
We often deploy almost the same bit especially when only one p2 repo updated in multiple TP .target file, like it was with jetty.
> Why do we deploy TP zips to Nexus snapshots repo?
> -------------------------------------------------
>
> Key: JBIDE-21120
> URL: https://issues.jboss.org/browse/JBIDE-21120
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, updatesite
> Affects Versions: 4.3.0.Final, 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> Currently, we deploy our TP update sites to the JBoss Nexus snapshots repo.
> {code}
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> ...
> {code}
> But other than Locus and the Browsersim Standalone zip, we don't ever use these artifacts, so they just:
> * eat disk space in Nexus
> * consume time/resources in Jenkins
> So, why don't we set a custome deployment strategy (eg., akin to *maven.deploy.skip=true*) in the jbosstools-targetplatform & jbosstools-discovery root pom to prevent this waste of time/space? Then we can just deploy the .target files, not the zips.
> This would certainly speed up builds, which currently take 30-60 mins per TP build.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21120) Why do we deploy TP zips to Nexus snapshots repo?
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21120?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-21120:
-------------------------------
Description:
Currently, we deploy our TP update sites to the JBoss Nexus snapshots repo.
{code}
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
...
{code}
But other than Locus and the Browsersim Standalone zip, we don't ever use these artifacts, so they just:
* eat disk space in Nexus
* consume time/resources in Jenkins
So, why don't we set a custome deployment strategy (eg., akin to *maven.deploy.skip=true*) in the jbosstools-targetplatform & jbosstools-discovery root pom to prevent this waste of time/space? Then we can just deploy the .target files, not the zips.
This would certainly speed up builds, which currently take 30-60 mins per TP build.
was:
Currently, we deploy our TP update sites to the JBoss Nexus snapshots repo.
{code}
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
...
{code}
But other than Locus and the Browsersim Standalone zip, we don't ever use these artifacts, so they just:
* eat disk space in Nexus
* consume time/resources in Jenkins
So, why don't we set *maven.deploy.skip=true* in the jbosstools-targetplatform & jbosstools-discovery root pom to prevent this waste of time/space? Then we can just deploy the .target files, not the zips.
This would certainly speed up builds, which currently take 30-60 mins per TP build.
> Why do we deploy TP zips to Nexus snapshots repo?
> -------------------------------------------------
>
> Key: JBIDE-21120
> URL: https://issues.jboss.org/browse/JBIDE-21120
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, updatesite
> Affects Versions: 4.3.0.Final, 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> Currently, we deploy our TP update sites to the JBoss Nexus snapshots repo.
> {code}
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> ...
> {code}
> But other than Locus and the Browsersim Standalone zip, we don't ever use these artifacts, so they just:
> * eat disk space in Nexus
> * consume time/resources in Jenkins
> So, why don't we set a custome deployment strategy (eg., akin to *maven.deploy.skip=true*) in the jbosstools-targetplatform & jbosstools-discovery root pom to prevent this waste of time/space? Then we can just deploy the .target files, not the zips.
> This would certainly speed up builds, which currently take 30-60 mins per TP build.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21120) Why do we deploy TP zips to Nexus snapshots repo?
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21120?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-21120:
-------------------------------
Description:
Currently, we deploy our TP update sites to the JBoss Nexus snapshots repo.
{code}
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
...
{code}
But other than Locus and the Browsersim Standalone zip, we don't ever use these artifacts, so they just:
* eat disk space in Nexus
* consume time/resources in Jenkins
So, why don't we set *maven.deploy.skip=true* in the jbosstools-targetplatform & jbosstools-discovery root pom to prevent this waste of time/space? Then we can just deploy the .target files, not the zips.
This would certainly speed up builds, which currently take 30-60 mins per TP build.
was:
Currently, we deploy our TP update sites to the JBoss Nexus snapshots repo.
{code}
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
...
{code}
But other than Locus and the Browsersim Standalone zip, we don't ever use these artifacts, so they just:
* eat disk space in Nexus
* consume time/resources in Jenkins
Since we have the custom profile deploy-to-jboss.org in place for all our artifacts, why don't we set *maven.deploy.skip=true* in the jbosstools-targetplatform & jbosstools-discovery root pom to prevent this waste of time/space?
> Why do we deploy TP zips to Nexus snapshots repo?
> -------------------------------------------------
>
> Key: JBIDE-21120
> URL: https://issues.jboss.org/browse/JBIDE-21120
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, updatesite
> Affects Versions: 4.3.0.Final, 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> Currently, we deploy our TP update sites to the JBoss Nexus snapshots repo.
> {code}
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
> ...
> {code}
> But other than Locus and the Browsersim Standalone zip, we don't ever use these artifacts, so they just:
> * eat disk space in Nexus
> * consume time/resources in Jenkins
> So, why don't we set *maven.deploy.skip=true* in the jbosstools-targetplatform & jbosstools-discovery root pom to prevent this waste of time/space? Then we can just deploy the .target files, not the zips.
> This would certainly speed up builds, which currently take 30-60 mins per TP build.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months