| Source vs. binaries vs. docs/javadocs [message #6126] |
Fri, 01 September 2006 22:53  |
Eclipse User |
|
|
|
A topic I did not see addressed so far is that of source code for provided
bundles.
There is no standard way suggested by OSGi for that afaik .
There is a standard way offered by PDE for that.
Keeping the sources accessible is *important* imho.
Being able to build from source can be important too.
Providing ways for sources and javadocs that can contribute to their parent
jar's Eclipse classpath entries is also nice for consumers.
Given the large number of bundles that already exists and the even larger
number of jars that Orbit could provide access to, this is a serious issue
to consider.
For instance, I find it very unreliable over time to rely on a jar provider
to consistenly provide over time a proper source for a jar, or an accessible
SVN/CVS repo (do not even think that the repo will be tagged properly).
I save religiously the source and docs of every jar I use, even when it
comes from a reputable provider.
This is a duanting task for a developer.
It is wild out there.
Note that this will be important for linux distros that recompile from
sources.
I do not have an answer.
Just another 2 cents ( I must on a roll with yet another post today).
--
Cheers, Philippe
philippe ombredanne | nexB
1 650 799 0949 | pombredanne at nexb.com
http://www.nexb.com
http://EasyEclipse.org
|
|
|
|
| Re: Source vs. binaries vs. docs/javadocs [message #6230 is a reply to message #6186] |
Sun, 03 September 2006 22:34  |
| Eclipse User |
|
|
|
"Jeff McAffer" <jeff_mcaffer@REMOVE.ca.ibm.com> wrote in message
news:edfriq$dvd$1@utils.eclipse.org...
> Philippe Ombredanne wrote:
> > Being able to build from source can be important too.
> Yes and no. I agree that we should not get in the way of this however,
> we are simply consuming something that others are producing. People
> should look to the originator of the JAR we are bundling for source
> compilation. In Orbit the build scripts we have (if any) should simply
> package the BINARY output of someone else's build to create a bundle.
Since there is a need to apply some intelligence in that anyway, going the
extra mile to make sure that we keep a source archive too is not a big step.
But KISS at first.
> > Providing ways for sources and javadocs that can contribute to their
parent
> > jar's Eclipse classpath entries is also nice for consumers.
>
> Not sure what this means...
just to be able to provide JDT sources attachments and javadoc locations
Definitely a refinement, since this is not only about manifest injection
only.
--
Cheers, Philippe
philippe ombredanne | nexB
1 650 799 0949 | pombredanne at nexb.com
http://www.nexb.com
http://EasyEclipse.org
|
|
|
| Re: Source vs. binaries vs. docs/javadocs [message #561497 is a reply to message #6126] |
Sun, 03 September 2006 20:20 |
| Eclipse User |
|
|
|
Philippe Ombredanne wrote:
> A topic I did not see addressed so far is that of source code for provided
> bundles.
> There is no standard way suggested by OSGi for that afaik .
> There is a standard way offered by PDE for that.
> Keeping the sources accessible is *important* imho.
Yes, having source available is very important. There are at least a
few issues in that area.
- The originator does not always package their source very well
- PDE's source mechanism is geared more towards bulk supply of source
for many plugins rather than supplying source for individual plugins.
- others to be sure...
> Being able to build from source can be important too.
Yes and no. I agree that we should not get in the way of this however,
we are simply consuming something that others are producing. People
should look to the originator of the JAR we are bundling for source
compilation. In Orbit the build scripts we have (if any) should simply
package the BINARY output of someone else's build to create a bundle.
> Providing ways for sources and javadocs that can contribute to their parent
> jar's Eclipse classpath entries is also nice for consumers.
Not sure what this means...
> Given the large number of bundles that already exists and the even larger
> number of jars that Orbit could provide access to, this is a serious issue
> to consider.
> For instance, I find it very unreliable over time to rely on a jar provider
> to consistenly provide over time a proper source for a jar, or an accessible
> SVN/CVS repo (do not even think that the repo will be tagged properly).
> I save religiously the source and docs of every jar I use, even when it
> comes from a reputable provider.
> This is a duanting task for a developer.
>
> It is wild out there.
Indeed! We are likely going to have to make the best of it. I don't
see Orbit "fixing" the problems.
Jeff
|
|
|
| Re: Source vs. binaries vs. docs/javadocs [message #561557 is a reply to message #6186] |
Sun, 03 September 2006 22:34 |
| Eclipse User |
|
|
|
"Jeff McAffer" <jeff_mcaffer@REMOVE.ca.ibm.com> wrote in message
news:edfriq$dvd$1@utils.eclipse.org...
> Philippe Ombredanne wrote:
> > Being able to build from source can be important too.
> Yes and no. I agree that we should not get in the way of this however,
> we are simply consuming something that others are producing. People
> should look to the originator of the JAR we are bundling for source
> compilation. In Orbit the build scripts we have (if any) should simply
> package the BINARY output of someone else's build to create a bundle.
Since there is a need to apply some intelligence in that anyway, going the
extra mile to make sure that we keep a source archive too is not a big step.
But KISS at first.
> > Providing ways for sources and javadocs that can contribute to their
parent
> > jar's Eclipse classpath entries is also nice for consumers.
>
> Not sure what this means...
just to be able to provide JDT sources attachments and javadoc locations
Definitely a refinement, since this is not only about manifest injection
only.
--
Cheers, Philippe
philippe ombredanne | nexB
1 650 799 0949 | pombredanne at nexb.com
http://www.nexb.com
http://EasyEclipse.org
|
|
|
Powered by
FUDForum. Page generated in 0.04253 seconds
Home