Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [orbit-dev] Contributed Jakarta ORO and Commons Net


Most of the other Orbit projects have this characteristic.  That is, they have a bundle manifest that has not Bundle-Classpath header (thus implying '.' as the classpath) and an "org" (whatever) dir at the root of the project.  In an Apache case for example there would be <project root>/org/apache/... with the leaves being the actual class files.  This way everything works fine at runtime and the building simply gathers up the contents of org (you have to put that in your build.properties) and away you go.

As for putting the original JAR in there, sure, that is possible for historical/tracking purposes but as David points out, from an operational point of view the JAR would not  play a role.

Jeff



David M Williams <david_williams@xxxxxxxxxx>
Sent by: orbit-dev-bounces@xxxxxxxxxxx

01/26/2007 08:25 AM

Please respond to
Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>

To
Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
cc
Subject
RE: [orbit-dev] Contributed Jakarta ORO and Commons Net






 

> My hope was that I could hold the unexploded jar in the Repository (ie a verbatim

> jar from apache), and have the build process explode and repackage it to a non-nested

> jar on the fly during the build. Would that make sense?


There is a lot of merit to exploring this type of thing, long run, but there's nothing in build
process (or PDE) that would do this now.


And, a potentially larger problem to think about and discuss: Its sort of an unwritten rule that
developers should be able to check something out of CVS into workspace and have it behave mostly like
it would in a pre-built version.  
It's hard for me to even imagine what that would look like. _______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev


Back to the top