Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Orbit » Source vs. binaries vs. docs/javadocs
Source vs. binaries vs. docs/javadocs [message #6126] Sat, 02 September 2006 02:53 Go to next message
Philippe Ombredanne is currently offline Philippe Ombredanne
Messages: 386
Registered: July 2009
Senior Member
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 #6186 is a reply to message #6126] Mon, 04 September 2006 00:20 Go to previous messageGo to next message
Eclipse User
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com

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 #6230 is a reply to message #6186] Mon, 04 September 2006 02:34 Go to previous message
Philippe Ombredanne is currently offline Philippe Ombredanne
Messages: 386
Registered: July 2009
Senior Member
"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] Mon, 04 September 2006 00:20 Go to previous message
Jeff McAffer is currently offline Jeff McAffer
Messages: 104
Registered: July 2009
Senior Member
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] Mon, 04 September 2006 02:34 Go to previous message
Philippe Ombredanne is currently offline Philippe Ombredanne
Messages: 386
Registered: July 2009
Senior Member
"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
Previous Topic:Creation review
Next Topic:Dynamic bundle wrapping/manifest injection
Goto Forum:
  


Current Time: Thu Oct 23 01:53:27 GMT 2014

Powered by FUDForum. Page generated in 0.03131 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software