[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] dependency on org.osgi.annotation?
- From: Neil Bartlett <njbartlett@xxxxxxxxx>
- Date: Sat, 9 May 2015 20:05:18 +0100
- Delivered-to: firstname.lastname@example.org
> On 8 May 2015, at 23:52, Stephan Herrmann <stephan.herrmann@xxxxxxxxx> wrote:
> I'm not responding to any of that religious anti-PDE flame war
> which is totally inappropriate in this discussion.
I find *that* comment totally inappropriate. BJ has given reasons why he thinks PDE gets certain things wrong. You may not agree with those reasons but it doesnât work to just claim they are âreligiousâ or inflammatory.
> On 05/08/2015 10:21 AM, BJ Hargrave wrote:
>> Well I suggest that (1) JDT not have a fatal error here since the goal is not to generate a class file
> Sounds like the obvious way to go, sure.
> Just note that reporting this kind of error is not connected
> to generating class files but to the semantic analysis,
> which indeed is desired in this use case - which only means:
> it's not as easy as just stopping before class file generation.
> Continuing compilation on broken input is a main contributor
> to complexity of this already very complex component.
> That's why avoiding unnecessarily broken input sounds like
> a much nicer option.
>> and (2) PDE should ... support a
>> way to specify compile dependencies different than runtime dependencies
> Well, if that's what the OSGi spec says, it shouldn't be hard
> to convince PDE â
As we all know, the OSGi spec is nearly silent on how to build stuff. But should we give up on a good idea just because itâs not in the spec?
After all, the benefits of building against an API are so obvious (you canât accidentally depend on implementation-specific code) that it seems we could convince the owners of PDE, whoever they are, on the merits of the idea alone.
> equinox-dev mailing list
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit