| Re: [cdt-dev] Why is org.eclipse.cdt.internal.errorparsers internal? |
Thanks,
That's sounds like an ideal solution.
Andrew
I can apply it, is everybody ok with that? To be save I can keep classes in internal (extending originals) and deprecate them.
This patch basically moves ErrorPattern and AbstractErrorParser from org.eclipse.cdt.internal.errorparsers to org.eclipse.cdt.errorparsers
Andrew Gvozdev wrote:
Hi,That sounds promising. Perhaps you can arrange review of the patch attached to bug 215492 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=215492> last January? I would volunteer to make any corrections if necessary if the author is not available.
On Fri, Aug 8, 2008 at 10:57 AM, Schaefer, Doug <Doug.Schaefer@xxxxxxxxxxxxx <mailto:Doug.Schaefer@xxxxxxxxxxxxx>> wrote:
AFAIK, this is ancient history. I'm not sure anyone would remember
why it's like that. We'd certainly accept contributions to clean
this up in 5.1.
Thanks,
Andrew
Cheers,
Doug.
I am sure Doug is very busy with all that's going on but maybe somebody else from commiters could take a look at the patch? This is as simple as moving a couple of internal but very useful classes to public package. Should not be a problem from the point of API change, should it? Last time Elena was nice to me and all of us who use make targets are very grateful.
Thanks,
Andrew
------------------------------------------------------------------------
*From:* cdt-dev-bounces@xxxxxxxxxxx
<mailto:cdt-dev-bounces@xxxxxxxxxxx>
[mailto:cdt-dev-bounces@xxxxxxxxxxx
<mailto:cdt-dev-bounces@xxxxxxxxxxx>] *On Behalf Of *Andrew Gvozdev
*Sent:* Friday, August 08, 2008 10:53 AM
*To:* CDT General developers list.
*Subject:* Re: [cdt-dev] Why is
org.eclipse.cdt.internal.errorparsers internal?
On Fri, Aug 8, 2008 at 5:51 AM, Achim Bursian<abu.aud@xxxxxxxxxxx <mailto:abu.aud@xxxxxxxxxxx>> wrote:<https://bugs.eclipse.org/bugs/show_bug.cgi?id=215492> which
Hi!
Is there any specific reason why *package
org.eclipse.cdt.internal.errorparsers* is internal?
It would be very helpful to use the base class
/AbstractErrorParser/ and the /ErrorPattern/ class in other
error parsers.
I happen to agree with this opinion. See bug 215492cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>
unfortunately did not get much traction. I also think that it
would be very useful to have some kind of user-configurable
generic parser in CDT. We use many tools in our builds emitting
various warnings and it would be nice to get
errors/warnings/infos in problems view and hightlighted in the
code. So far we are stuck to using perl script to reformat to
GCC error parser and XLC errorparser likings (where a format is
kind of weird but it allows to populate the view with Infos).
I think that this would also help expanding using of CDT as a
platform to development in different languages. For example, a
while ago I used it to parse PHPUnit output. Worked fine after
you invest some time to set it up
Thanks,
Andrew
Why is that discouraged?
Cheers,
Achim
_______________________________________________
cdt-dev mailing listcdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
https://dev.eclipse.org/mailman/listinfo/cdt-dev
------------------------------------------------------------------------
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev