[cross-project-issues-dev] Gotchas Building Against Eclipse 4.20

2021-03-19 Thread Ed Merks 

FYI,

So that others can short-circuit problems they're likely to have (may 
have) building against Eclipse 4.20, take note that IPlatformRunnable 
has now been removed, but Tycho Surefire <= 2.0.0 Surefire uses it (even 
though it's deprecated since 2006). There isn't much in the way of 
diagnosis why the Surefire test launches fail; you have to look in the 
*.log to see the class load failure is the cause.  As such, if your 
tests suddenly don't launch when building against 4.20, this most likely 
why.


I'm not sure about the state of Tycho 2.1.0; I switched to 2.2.0 for 
EMF's build to be able to launch tests.  Unfortunately with 2.2.0 I 
could not build certain of my Xcore plugins (strange "inconsistent class 
hierarchy" errors); it turned about that these failing bundles all had 
BREE 1.6  and when I moved them to BREE 1.8, that magically avoided the 
Tycho compile errors.  Probably others won't have such a problem, but 
maybe good to keep in mind.


Another issue is that there is a newer major version of Jetty in 4.20,  
(10.0.1 versus 9.4.27) so I cannot build Oomph until USS SDK provides a 
new build that does not exclude Jetty 10.x:


https://bugs.eclipse.org/bugs/show_bug.cgi?id=572026

Good luck building against 4.20.  Hopefully you can avoid the time 
consuming pitfalls.


Regards,
Ed


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Gotchas Building Against Eclipse 4.20

2021-03-19 Thread Wim Jongman 
Thanks, Ed! I was just starting to convert some builds to 4.20.

On Fri, Mar 19, 2021 at 9:17 AM Ed Merks  wrote:

>
> BREE 1.6  and when I moved them to BREE 1.8, that magically avoided the
> Tycho compile errors.  Probably others won't have such a problem, but
> maybe good to keep in mind.
>

Maybe: https://bugs.eclipse.org/bugs/show_bug.cgi?id=561363
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Restricting bugzilla issues creation/edition?

2021-03-19 Thread Mickael Istria 
Hi all,

I'm brainstorming about how to have a complete the migration to GitHub for
some projects (eg m2e, Tycho...). Currently, the main pain point would be
the bug tracker: the backlog on Bugzilla is huge and migrating it to GitHub
wouldn't be very relevant, but this backlog needs to remain accessible.
One approach would be to make the BZ tracker progressively "read-only", or
at least to prevent from creating new issues.
For a given product, is it possible to prevent creation of new issues? Is
it possible to block creation of issues while keeping edition access on
existing issues? Is it possible to make the product issues "read-only" (no
creation, no edition)?
My favorite one at the moment would be to block creation of new issues but
still allow edition.

Thanks in advance for your insights.

-- 
Mickael Istria
Eclipse IDE 
developer, for Red Hat Developers 
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Restricting bugzilla issues creation/edition?

2021-03-19 Thread Christoph Läubrich 
I don't know if it is possible in Buzilla but Github support "issue 
templates" (that is some predefined text is filled when creating a new bug).


If that also possible with Bugzilla one could simply put the info that 
Github should be used as the default text if someone tries to open a new 
report including a link to Github issues.


Am 19.03.21 um 09:42 schrieb Mickael Istria:

Hi all,

I'm brainstorming about how to have a complete the migration to GitHub 
for some projects (eg m2e, Tycho...). Currently, the main pain point 
would be the bug tracker: the backlog on Bugzilla is huge and migrating 
it to GitHub wouldn't be very relevant, but this backlog needs to remain 
accessible.
One approach would be to make the BZ tracker progressively "read-only", 
or at least to prevent from creating new issues.
For a given product, is it possible to prevent creation of new issues? 
Is it possible to block creation of issues while keeping edition access 
on existing issues? Is it possible to make the product issues 
"read-only" (no creation, no edition)?
My favorite one at the moment would be to block creation of new issues 
but still allow edition.


Thanks in advance for your insights.

--
Mickael Istria
Eclipse IDE  
developer, for Red Hat Developers 


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Restricting bugzilla issues creation/edition?

2021-03-19 Thread Rolf Theunissen 
RTFM:
https://bugzilla.readthedocs.io/en/5.0/administering/categorization.html#basic-product-group-restriction
Based on group permissions it is controlled who can enter, edit, read,
etc., on a product granularity,  So it should be possible to disable
create, while remain edit rights.

(Sorry to be blund, but manuals do have value although engineers tend to
just ignore them)

Op vr 19 mrt. 2021 om 09:43 schreef Mickael Istria :

> Hi all,
>
> I'm brainstorming about how to have a complete the migration to GitHub for
> some projects (eg m2e, Tycho...). Currently, the main pain point would be
> the bug tracker: the backlog on Bugzilla is huge and migrating it to GitHub
> wouldn't be very relevant, but this backlog needs to remain accessible.
> One approach would be to make the BZ tracker progressively "read-only", or
> at least to prevent from creating new issues.
> For a given product, is it possible to prevent creation of new issues? Is
> it possible to block creation of issues while keeping edition access on
> existing issues? Is it possible to make the product issues "read-only" (no
> creation, no edition)?
> My favorite one at the moment would be to block creation of new issues but
> still allow edition.
>
> Thanks in advance for your insights.
>
> --
> Mickael Istria
> Eclipse IDE 
> developer, for Red Hat Developers 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Restricting bugzilla issues creation/edition?

2021-03-19 Thread Mickael Istria 
On Fri, Mar 19, 2021 at 10:28 AM Rolf Theunissen 
wrote:

> RTFM:
> https://bugzilla.readthedocs.io/en/5.0/administering/categorization.html#basic-product-group-restriction
> Based on group permissions it is controlled who can enter, edit, read,
> etc., on a product granularity,  So it should be possible to disable
> create, while remain edit rights.
> (Sorry to be blund, but manuals do have value although engineers tend to
> just ignore them)
>

OK, so it's technically possible for Bugzilla in general. As I'm not a
Bugzilla admin, I'm more curious about whether it's something EMO
Infrastructure team can set up on bugs.eclipse.org.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Gotchas Building Against Eclipse 4.20

2021-03-19 Thread Ed Willink 

Hi

You may also find https://bugs.eclipse.org/bugs/show_bug.cgi?id=569379 
relevant if you move on from an old Tycho to avoid IPlatformRunnable.


It would appear that something in the auto-POM logic ignores the 
MANIFEST.MF BREE and instead picks one from an explicit pom.xml BREE so 
avoid vintage BREEs in test plugins.


Inconsistent org.eclipse.jdt.core.prefs between plugins can also be a 
problem. Maybe OOMPH can avoid this.


If you  use JDT's @NonNull annotations it is essential that you set 
deriveReleaseCompilerArgumentFromTargetLevel false.


    Regards

        Ed Willink


On 19/03/2021 08:33, Wim Jongman wrote:

Thanks, Ed! I was just starting to convert some builds to 4.20.

On Fri, Mar 19, 2021 at 9:17 AM Ed Merks > wrote:



BREE 1.6  and when I moved them to BREE 1.8, that magically
avoided the
Tycho compile errors.  Probably others won't have such a problem, but
maybe good to keep in mind.


Maybe: https://bugs.eclipse.org/bugs/show_bug.cgi?id=561363 



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev