Am 24.02.10 13:33, schrieb Flick, Stefan:
As
original founder of this question I understand and accept your point of
view, but for our Team it's not possible to access the CVS (Customer
Firewall Policies...) to retrieve a "valid" SourceBundle Project. So we
have to import it from our target platform, apply our patch and
re-export or "build" it from the PDE Tools. By nature of the PDE
build the build.properties is very essential for a successful build.
Without those information the binary bundle lacks of all resources like
images and NLS files :(
So for us, it would be
nice, if the build.properties are part of a source bundle. Just as some
other kind of make files usually found in GCC projects for example.
Without them, it's hard to build the project and requires deep internal
knowledge.
then - of course - it makes sense to include the build.properties
ekke
The file is by default
very small and at least it is only necessary for bundles with specific
resources other than *.java, manifest.mf, plugin.xml... So why not put
it into the source bundle? Source bundles are only relevant for
development and the existence of a build.properties helps to eliminate
nasty "resource not found" bugs @ runtime.
Stefan
Am 23.02.10 22:37, schrieb Elias Volanakis:
By the way, as far as I know the src settings are additive (i.e. src =
"" + bin).
Personally, I think my typical use for source bundles is having the
source when debugging. If I wanted to work with the source I would get
it from CVS.
+1 makes sense for me, too
thx christian for asking this - was also a question for me what exactly
should be part of a source bundle
ekke
Just my 2c,
Elias.
On Tue, Feb 23, 2010 at 4:14 AM, Christian Campo
<Christian.Campo@xxxxxxxxxxxx> wrote:
I would like to start a discussion what belongs into a source bundle.
Currently we are putting basically all the stuff in there that can be used
for reference (at development time) from riena like source files.
So the bin jar contains
- class binary files
- schemas
- /icons directories
- plugin.xml
- about.html
the src jar contains
- class source files
- about.html
- plugin.properties
The usecase is now that I import (with source code) a bundle, I like to
patch it and reexport it into a new jar and source jar. And the question is,
do we supply enough content for that.
Now if you import a bundle with source code, you get all the content from
bin AND source jar and the class binary files are obviously compiled again
in your workspace.
One thing that was noted is that we dont supply is build.properties. Other
eclipse projects also dont supply them. We also have sometimes .gifs in the
source tree that are in the middle of the classes hierarchy)
(http://bugs.eclipse.org/303598). Those end up being in the bin jar but not
in the source jar (which seems wrong).
Any feedback from committers, contributers or community is highly
appreciated....
christian
-------------------------------------------------------------
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: 069 / 27 22 18 0
fax: 069 / 27 22 18 22
web: www.compeople.de
Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz
Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
Ust-Ident.-Nr: DE207665352
-------------------------------------------------------------
_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev
--
ekke (ekkehard gentz)
independent software-architect
senior erp-consultant
eclipse | osgi | equinox | mdsd | oaw | emf |
uml
max-josefs-platz 30, D-83022 rosenheim, germany
mailto:ekke@xxxxxxxxxxxxxxxx
homepage (de):
http://gentz-software.de
blog (en):
http://ekkes-corner.org
twitter: @ekkescorner
skype: ekkes-corner
Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID:
DE189929490
_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev
--
ekke (ekkehard gentz)
independent software-architect
senior erp-consultant
eclipse | osgi | equinox | mdsd | oaw | emf |
uml
max-josefs-platz 30, D-83022 rosenheim, germany
mailto:ekke@xxxxxxxxxxxxxxxx
homepage (de): http://gentz-software.de
blog (en): http://ekkes-corner.org
twitter: @ekkescorner
skype: ekkes-corner
Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID:
DE189929490
|
