On Mon, 2004-02-02 at 10:39, Dalibor Topic wrote: > Hi Jason, > > thanks a lot for taking the time to reply so quickly. > > Compliancy to JDK APIs is a seal of approval given out by Sun for > passing the TCK. Since the TCK is not available under a free software or > open source license, it's hard for free implementations to claim > compatibility with JDK APIs, without risking to get sued anyway. ;)
They are available to OSS projects, we have licenses for many of them here at Apache. The folks working on it here have worked long and hard to get them for us but I'm sure you too can gain access to them. > That's why kaffe says quite prominently that it's not Java on it's web > page on http://www.kaffe.org. Nevertheless, it runs quite a few java > applications quite alright ;) > > The unwarrented assumptions (i.e. unportable java code) are breaking > applications even under compliant JVMs, as can be seen in a rather > famous apache.org project, Ant. Citing from the announcement of Ant's > 1.5.4 release: > > "(1) With JDK 1.4.2 Sun has changed the entry point for javah, > therefore Ant 1.5.3's <javah> task doesn't work on JDK 1.4.2 anymore." > > See http://nxnw.org/pipermail/sw-announce/2003-August/000181.html for > details. > > To me, that's a clear case of unwarranted assumptions: assuming that > sun.something.javah.something.else is an entry point to a javah tool > implemented in java. The JDK API docs explicitely discourage programmers > from using the sun.* packages directly. The JDK tool documentation makes > no statement in which language javah is written. It's an assumption that > leads to unportable java code, that (obviously) didn't work on some > compliant, certified JVMs. I don't think many people use sun.* packages. What's in Maven is vestigal and can certainly be fixed. I actually fixed it in the component based version of Maven last night when you mentioned it in your post. > > While I certainly agree with you that [1] can easily be remedied you are > > the first and probably only person to catch [1]. While it's nice having > > things like Kaffe and Jaguar they are not products that people reach for > > first when developing with Java. I would like to use Kaffe but in the > > few times I've tried it's been a world of hurt. But I will certainly fix > > [1], that's not really a big deal. > > I guess we can both quickly agree that the solution to [1] to use the > jakarta commons-codec package is a better solution for a variety of > reasons for a jakarta project, than to rely on an undocumented, > unspecified class for that functionality. There are a boatload of encoders lying around. I used one of them :-) > My most interesting problem with Maven and Kaffe combo so far was the > tools.jar reference in the forehead.conf file, as maven-1.0rc1 wouldn't > start up with it. Since Sun's tools.jar is distributed under a very > restrictive license, Kaffe (and other free runtimes) can't ship it, so > that any code which wants to mess with tools.jar is bound to fail. This is certainly something we can fix, but you have to keep in mind that 99% of folks are going to download a Sun or IBM JDK and consequently won't have that problem. There aren't many people more into OSS then I am but you have to pragmatic about these things. You have a simple patch I believe for the tools.jar problem so no biggie but ultimately we only have so much time and will more than likely focus on general usage patterns which unfortunately rarely includes Kaffe. > And there we are again in the 'unwarranted assumptions' case: the JDK > docs do say something about a tools.jar file in the 'How Classes are > found section', but they fail to name the classes present there, since > they are in a sun.* package, i.e. 'forbidden' territory. So tools.jar is > rather useless, if one writes his Java programs strictly according to > the JDK docs. There is no reason to include it, that can be deduced from > the JDK docs. Whatever assumptions Maven makes about tools.jar, these > assumptions are hardly backed up by the JDK documentation. Or I failed > to find it, in which case I'd appreciate an URL ;) > > I'd like to use Maven, and you'd like to use Kaffe, so I'm sure we can > find a common ground there, and a good solution. > > >>>If I understand you correctly, are you saying that for development > >>>purposes Maven should be leveraging platform specific repositories? > >> > >>Yes, if such repositories are available. Otherwise it becomes quite hard > >>to rebuild maven applications from source to verify their integrity, > >>i.e. that they haven't been tampered with. > > > > > > No, that's simply not true. How would using an OS repository over > > Maven's own repository help with this in any way shape or form? All the > > information necessary to build the project is available in the POM. So > > all you need to do is get your hands on the POM and you could very > > easily make a tool to build a project. > > Usually OS repositories can be rebuilt from source (if the license > permits so). There is also the need to be rebuildable from source in > order to apply bug fixes to the source code, or other patches. Ok, I still don't see what stops you from using Maven to do this. Which is what it's for and then use the packaging tool after Maven has done its job. > I've had the assumption that POM dependencies can only be specified to > jars, ejbs and plugins according to > http://maven.apache.org/reference/project-descriptor.html#dependencies > and not to sources. But I definitely agree that having the dependencies > listed in the POM makes building a tool that collects the necessary > sources and builds them easier. Thanks for providing that useful way of > documenting dependencies! There is a section in the POM about where the sources come from for a particular project. When the Maven repository is populated with POMs you will be able to look at a dependency, find the POM for it and build it if you like. Pick the point in the dependency graph at which you want to build from sources. No problem. You can build it all if you want. > >>You may want to be able to rebuild everything from scratch, > >>in order to be able to apply a quick source code patch for a security > >>problem for example, and be able to put it all back together. > > > > > > So what advantage would a native package manager have over Maven doing > > this? > > He could create the distribution specific patch for an urgent security > problem, test it on his native OS, and distribute it straight away for > his native OS. That's fine but I meant more for standard development practices where people work with native Java. What benefit is there is using packages installed by an OS specific packager as opposed to using artifacts from Maven's repository. We don't have a single OS native artifact in the repository as far as I know. > The way I understand the current Maven artifact distribution concept, > there is a central repository, that is updated by Maven developers upon > request through the Maven JIRA. Since a Maven artifact is supposed to be > used by more than one operating system, I'd assume that Maven developers > are very careful about patching things, and about creating artefacts > that are platform-specific. We don't create artifacts that are platform specific. As I said I don't think we have a single one and I would like to keep it that way. If packagers want to build from what's there or build from sources and do whatever with them then that's great. But for example I wouldn't endorse the use of a Maven binary compiled with gcj and I doubt many projects would want you making native binaries of their projects without their knowledge. > Let's say a java library has a native component. Let's say Maven > distributes both. After a few months, a security bug is discovered in > the native component, that manifests itself only under a very specific > (and rare) set of conditions on a nieche platform (let's say > playstation2-linux for the sake of the argument). I don't think it > should be expected from the Maven developers to maintain C++ libraries > for playstation2-linux ;) Someone has started a facility for doing native code, but storing native object code is not something I see us storing so you don't have to worry about it. I don't ever want to have to bother with native object code and anyone making a plugin so that native code in a build would then definitely have to do things in a platform specific way. But this can all be dealt with in a plugin that deals with using native code as part of their Java projects. I'll just nip the rest of that in the bud because I think you misunderstand what we're trying to do. The repository isn't going to store native object code artifacts. If someone wants to do that they can utilize a plugin that deals with the barrier between java and platform specific code. And that plugin can have any or all the information about platform specific packagers. Kasper Nielsen took a crack at a native plugin and that's where I would recommend you focus your efforts. You could provide a plugin that would deal with all the platform specifics for those who wish to combine Java code with platform native binaries. For this case I'm in 100% agreement that the plugin should leverage all information about platform specific packages. There is no argument there from me. But as far as pure Java development goes I would never encourage the use of native packages. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
