blob: a9d2c63a7f13032c83625a8ede772930929d70e2 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
This file try to explain the logic/problems/todo of java section spells.
(Basicli, this file servs as "remainder" for me to not forget to do
something:)
Logic:
1. All java packages go to /usr/lib/java
- becouse I'm pretty sure this will change => there is java-function.sh
in which are the "defines" for this. (also some function to make
the life of java sec. maintainer more easy :)
- exception from this "rule" will be the "end-user" app. which will
go to /usr/share/$SPELL ? (as example tomcat)
- all spells which are "realy compiled from src" or "the spell is the
only "right" provider of the jar file (even when the src. code is
not present) must put their jar files simlinks in apropriate */lib
dir. ( without version number )
(Reason: is much more easy to "find them" :)
2. There are several "big java projects which are made of subprojects"
- each "project" will have own dir in /usr/lib/java, and his sub.prj
will be installed to subdirs of this dir (which made possible to
easili modify the build.xml scripts for them
(as example: jakarta-commons-*)
- cos of some "possible spell name mismatch" - the name of spell is
composed as follows : project-subproject-* (or project-*) or only (*) :)
3. For moment - the spells are build without to much dependecies between
them
- so even when there is corresponding dep. spell in section I prefer use
the "tools" contained in given spell tarball (cos of recursive dependecies)
4. For moment - also the spells - which normaly goes to rejected are present
in java section (cos of possible "massive" changements of logick in java section).
5. For moment - all spell stuf is installed (means docs,tests,examples,sorce code).
(perhaps not good idea ?)
******
ToDo (What I/(perhaps you:) want to fix/do/create:
1. Try to realy use existing spell as dependecies for new one (get ride of
precompiled tools jar files
(Solution?:
a) two stage compilation ? (one with binary tools and after with compiled ones?)
b) creation of new "realy build all on this machine with dependecies on stuff
on this machine" spell ?
)
(Q: does it have sence to try to do this ? (cos of java nature) )
2. Try to get ride of java-functions.sh in java sec. (so move this fncs. to sorcery
function ?)
3. Move rejected spells to z-rejected sec.
4. Try to compile all spells from sources. (Ok, there is question if it's realy necesary
but I think it can be coool :)
5. Fix the spells - which was made as "quick" hack to compile the source "normaly".
6. What to do with spells which source code has "license issue" - can't be downloaded
directly => $SOURCE_URL is for an moment empty ? (perhaps add some new
"standardized $SOURCE_URL_DOWNLOAD_PAGE url" which will be shown to user =>
so the user will be aware of this and will know where to register and where
to download the src ?)
7. Fix PROVIDES in all spells .
8. Make user aware - if the spell has source code but is not compiled => "precompiled"
jar file is used. (So I mean - make the "better diference as actualy" ..)
9. fill bug to sercery team about javamail which provides javamail - which cause
"sorcery cast" to thing that javamail provides java ... (strange one)
10. fill bug to sorcery team about "md5sum tracking of installed files" - which
fail when "file name" contains white space.
12. fill "bug?"/suggestion - about some "standardized and not so big" "PRE_BUILD"
file for z-rejected - I mean - Why to have almost 1K of message stuff if
we can have it as one sorcery (aka message_zrejected) function ?
13. Create an http page about java section - which will contain "some more cool"
version of this file.?
14. Do something with crimson spell colision (temporary fix: spell name = crimson-apache)
15. Finish finalli tomcat spell (this was the one - cos of which all this java stuff was/is
"necesary" :)
16. Add more todo in this todo file :)
17. After fixing all the stuff in this file - get ride of this file :)
------
If you have some suggestions, ideas, comments, feel free to send email at :
vvydra@sourcemage.sk
or, the much more cool/better way :
fill bug for java section in bugs.sourcemage.org .
Thanks for your interes about java section,
V. Vydra
|
