Re: [epp-dev] Exceptions when starting Neon M4 packages

[Kaloyan Raev <kaloyan.r@xxxxxxxx>]

Hi,

I forgot that AERI is an EPP component.

I thought Andreas proposed an alternative workaround where those EPP packages, that does not have JDT, to include the org.eclipse.jdt.annotation bundles. This would require just a respin of the EPP packages only and not of the Simultaneous Release repository.

The error is in a dialog popup. The user can dismiss it, but it will appear on every start of the IDE. As I've said, it's not a blocker for a Milestone release, but still pretty annoying.

If a quick respin of the EPP packages is not possible then we can live with it until the next milestone.

Kaloyan

On Fri, Dec 18, 2015 at 2:13 PM, Markus Knauer <mknauer@xxxxxxxxxxxxxxxxx> wrote:

If I understood correctly Andreas wanted to commit something to AERI itself; its source code is part of the EPP project and therefore any EPP committer could review a patch in Gerrit. Independent from what we decide, I would say that it would be beneficial to have a patch available in Gerrit.

The problem that I see is that this change would need a new contribution to the Simultaneous Release, a rebuild of all packages, and finally retesting the packages and waiting for the download mirrors to get the new package version. That's nothing that could be done before early next week, and I fear that many people will be away on vacation then.

How severe is this exception, is it really a blocker? Does it prevent users from using the package, is it 'just' an entry in the log file, or a blocking dialog?

Maybe someone can answer these questions while I'm waiting for my download to finish.

Thanks,

Markus

On 18 December 2015 at 12:55, Kaloyan Raev <kaloyan.r@xxxxxxxx> wrote:

Hi Andreas,

> - Marcel, the core committer of AERI, is on parental leave; his twins(!)
are just a few days old, so I imagine he is rather busy right now.

Congratulations to Marcel and his family!

> - I could implement the above workaround (non-optional dependency) but
am not even a committer on ARI; hence, I would need an EPP committer to
submit the change in Gerrit and promote a new milestone, which would
then need to be integrated.

You can just push the patch to Gerrit for C/C++, PHP and other non-Java packages (Parallel, Testers?) and then let Markus decide if he will merge it and do the re-spin.

> Do you consider this a blocker for the PHP package?

It's really not nice to see this error on every startup, but I would not say this is a blocker for a Milestone release. However, if we can have a quick re-spin then let's do it.

Kaloyan

On Fri, Dec 18, 2015 at 1:40 PM, Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx> wrote:

Hi Kaloyan.

> Isn't it better if the org.eclipse.epp.logging.aeri.ui bundle changes
> the dependency to the org.eclipse.jdt.annotation bundle to be non-optional?
>
> This way, I believe, the org.eclipse.jdt.annotation bundle will be
> automatically included in the EPP packages wherever necessary.

I was not suggestion that the burden of deciding whether to include
org.eclipse.jdt.annotation should be placed on the package maintainers.
If org.eclipse.epp.logging.aeri.ui requires org.eclipse.jdt.annotation
to *run* (not just compile), it should be a non-optional dependency.
This would certainly be the workaround for now.

That being said, it would be even better if ECore could be made to not
introduce an unnecessary runtime dependency; a compile-time dependency
to @Nullable should be sufficient. But my ECore knowledge is rather
limited, so I have no idea how to achieve that.

Anyway, the question is how to proceed for M4:

- Marcel, the core committer of AERI, is on parental leave; his twins(!)
are just a few days old, so I imagine he is rather busy right now.

- I could implement the above workaround (non-optional dependency) but
am not even a committer on ARI; hence, I would need an EPP committer to
submit the change in Gerrit and promote a new milestone, which would
then need to be integrated.

Do you consider this a blocker for the PHP package?

Andreas

--
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/epp-dev

_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/epp-dev

_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/epp-dev