7:36 a.m.
Hi everybody,
Soom we'll have API Tools part of the reports produced by build.
However, it seems to me that most (all?) JBoss Tools projects don't use
API Tools. But it's not too late to start using them in your IDE, in a
long-term view, it's very useful and can prevent from some serious bugs
and will help you to choose the best version to put for your
dependencies in your MANIFEST. Here is a reminder of how to set them up:
http://eclipsesource.com/blogs/2013/02/21/api-tools-revisited/ . In our
case, the "baseline" is the latest release of JBoss Tools or JBoss
Developer Studio.
Cheers,
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
9:56 a.m.
Hi everybody,
Soom we'll have API Tools part of the reports produced by build.
However, it seems to me that most (all?) JBoss Tools projects don't use API Tools.
There does not seem to be a way to enable it without killing eclipse.
i..e it works fine when you got 2-3 projects loaded but when you load more - slower than
slow.
Have you found a way to enable/disable it globally ?
But it's not too late to start using them in your IDE, in a
long-term view, it's very useful and can prevent from some serious bugs and will help
you to choose the best version to put for your dependencies in your MANIFEST. Here is a
reminder of how to set them up:
http://eclipsesource.com/blogs/2013/02/21/api-tools-revisited/ . In our case, the
"baseline" is the latest release of JBoss Tools or JBoss Developer Studio.
Cheers,
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
10:08 a.m.
On 02/22/2013 09:56 AM, Max Rydahl Andersen wrote:
Have you found a way to enable/disable it globally ?
https://issues.jboss.org/browse/JBIDE-12190
I think we already have some interesting stuff done, but it's not usable
yet because:
* We cannot deploy it on a Nexus repo yet (discussion in progress with
eng-ops to have full access to an "experimental" repo where we could
publish that stuff)
* Generated reports -using Rob's improvements to support bundles that
don't have apitools enabled- are not easy to read.
@Rob: yes the goal is to run API Tools analysis when no API annotations
are present. It's pretty useful since so far, we've not generated the
API description for bundles, so your fix is a requirement for making API
Tools usable in our build.
But, it's not because we did not use them before that it's a bad idea to
start using them from now on. FYI, we'll soon generate API description
of bundles, so if you want to start annotating your APIs, feel free to
do it, it's gonna be useful.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
10:14 a.m.
> Have you found a way to enable/disable it globally ?
>
https://issues.jboss.org/browse/JBIDE-12190
I think we already have some interesting stuff done, but it's not usable yet
because:
* We cannot deploy it on a Nexus repo yet (discussion in progress with eng-ops to have
full access to an "experimental" repo where we could publish that stuff)
Eh - why is normal jboss repository not ok for this now we know its not automatially
published to maven central?
* Generated reports -using Rob's improvements to support bundles
that don't have apitools enabled- are not easy to read.
@Rob: yes the goal is to run API Tools analysis when no API annotations are present.
It's pretty useful since so far, we've not generated the API description for
bundles, so your fix is a requirement for making API Tools usable in our build.
But, it's not because we did not use them before that it's a bad idea to start
using them from now on. FYI, we'll soon generate API description of bundles, so if you
want to start annotating your APIs, feel free to do it, it's gonna be useful.
Oh yes - using the annotations is all great and recommended.
It was the PDE API tools default behaviour of "scan all projects all the time"
that is killing my eclipse at least ;)
/max
10:19 a.m.
On 02/22/2013 10:14 AM, Max Rydahl Andersen wrote:
>> Have you found a way to enable/disable it globally ?
>>
> https://issues.jboss.org/browse/JBIDE-12190
> I think we already have some interesting stuff done, but it's not usable yet
because:
> * We cannot deploy it on a Nexus repo yet (discussion in progress with eng-ops to
have full access to an "experimental" repo where we could publish that stuff)
Eh - why is normal jboss repository not ok for this now we know its not automatially
published to maven central?
We need to deploy some Eclipse plugins as released
artifacts, so I had
to ask for some repos to do it without polluting the real JBoss repo.
When we find out the clean practices with having Eclipse bundles in
Maven repositories (this is also discussed as part of Eclipse CBI),
we'll be able to use the JBoss and Eclipse repositories to fetch/deploy
stuff.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
12:20 p.m.
>> https://issues.jboss.org/browse/JBIDE-12190
>>
>> I think we already have some interesting stuff done, but it's not usable yet
because:
>> * We cannot deploy it on a Nexus repo yet (discussion in progress with eng-ops to
have full access to an "experimental" repo where we could publish that stuff)
>>
> Eh - why is normal jboss repository not ok for this now we know its not automatially
published to maven central?
We need to deploy some Eclipse plugins as released artifacts, so I had to ask for some
repos to do it without polluting the real JBoss repo. When we find out the clean practices
with having Eclipse bundles in Maven repositories (this is also discussed as part of
Eclipse CBI), we'll be able to use the JBoss and Eclipse repositories to fetch/deploy
stuff.
got it.
/max
10 a.m.
I thought one of our primary use cases was generating API reports when
api tools is NOT enabled on the plugin. I thought that was one of the
main reasons I went through and debugged the api-tools ant tasks etc?
On 02/22/2013 02:36 PM, Mickael Istria wrote:
Hi everybody,
Soom we'll have API Tools part of the reports produced by build.
However, it seems to me that most (all?) JBoss Tools projects don't
use API Tools. But it's not too late to start using them in your IDE,
in a long-term view, it's very useful and can prevent from some
serious bugs and will help you to choose the best version to put for
your dependencies in your MANIFEST. Here is a reminder of how to set
them up:
http://eclipsesource.com/blogs/2013/02/21/api-tools-revisited/ . In
our case, the "baseline" is the latest release of JBoss Tools or JBoss
Developer Studio.
Cheers,
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
10:08 a.m.
I thought one of our primary use cases was generating API reports
when api tools is NOT enabled on the plugin. I thought that was one of the main reasons I
went through and debugged the api-tools ant tasks etc?
Yes, that was my understanding too.
On 02/22/2013 02:36 PM, Mickael Istria wrote:
> Hi everybody,
>
> Soom we'll have API Tools part of the reports produced by build.
> However, it seems to me that most (all?) JBoss Tools projects don't use API
Tools. But it's not too late to start using them in your IDE, in a long-term view,
it's very useful and can prevent from some serious bugs and will help you to choose
the best version to put for your dependencies in your MANIFEST. Here is a reminder of how
to set them up: http://eclipsesource.com/blogs/2013/02/21/api-tools-revisited/ . In our
case, the "baseline" is the latest release of JBoss Tools or JBoss Developer
Studio.
>
> Cheers,
> --
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat
> My blog - My Tweets
>
>
> _______________________________________________
> jbosstools-dev mailing list
>
> jbosstools-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
10:10 a.m.
On 02/22/2013 05:08 PM, Max Rydahl Andersen wrote:
But it's not too late to start using them in your IDE, in a
long-term view, it's very useful and can prevent from some serious bugs and will help
you to choose the best version to put for your dependencies in your MANIFEST.
As far
as I understood the situation, everyone agrees that we want to
know the best version to put, etc. However, most developers previously
agreed that enabling api tools on a large workspace is too much and
slows down a lot of progress.
We all want to know what versions to put, and we all want to be alerted
when such versions are wrong, or if api regressions have been made when
they shouldnt have. But we'd prefer this is done in a build, nightly or
weekly,
If you really thought about it, if all developers had api tools enabled
during development time, we wouldn't need it enabled in build, would we? ;)
10:16 a.m.
On 02/22/2013 10:10 AM, Rob Stryker wrote:
If you really thought about it, if all developers had api tools
enabled
during development time, we wouldn't need it enabled in build, would we? ;)
I
just suggest the one interested to use API Tools because it's helpful,
I'm not forcing anyone.
Anyhow, we'll enable API Tools at build time, since it's easier to
control how build behaves than having everyone using some tools,
especially if they slow down the workspace.
But I remember a presentation that said that fixing an error that
appears in IDE while writing code takes a few seconds, whereas fixing it
after a build report takes minutes. Having this is IDE is more
efficient, but I understand all te drawbacks, and you're free to set up
your environment as you want.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
12:23 p.m.
> If you really thought about it, if all developers had api tools
enabled
> during development time, we wouldn't need it enabled in build, would we? ;)
>
I just suggest the one interested to use API Tools because it's helpful, I'm not
forcing anyone.
Anyhow, we'll enable API Tools at build time, since it's easier to control how
build behaves than having everyone using some tools, especially if they slow down the
workspace.
Okey so when you say API Tools I understand that as the PDE API plugins' - the
annotations is not what I consider API tools - thats just part of osgi/manifest versioning
best practices.
But I remember a presentation that said that fixing an error that
appears in IDE while writing code takes a few seconds, whereas fixing it after a build
report takes minutes.
Yes, if you got just a few projects.
Having this is IDE is more efficient, but I understand all te
drawbacks, and you're free to set up your environment as you want.
The problem is there aren't no way to do this without affecting everyone else...but I
guess its better we see more usage of the api tools and I and others will just have to
manually disable them locally if any performance problems.
/max
4074
days inactive
4074
days old
jbosstools-dev@lists.jboss.org
10 comments
3 participants
participants (3)
-
Max Rydahl Andersen -
Mickael Istria -
Rob Stryker