Re: new idea on maven usage?

[Dalibor Topic <ro...@kaffe.org>]

Hi Christian,

Christian Andersson wrote:
> well that is one possibility, but that system (building an installation
> set which have everything) does not take advantage of the fact that I
> might already have some "libraries" (jar files) installed/downloaded
>
> This is where maven comes in, since if I start te application from
> maven, maven will look in the "local" repository first for the files, if
> they are not there it will download them, so If a person already has
> some jar files (ofr the correct version) he does not have to download
> them and therfore saving perheps precious network bandwidth and time.

Maven doesn't know about native package management on a platform, afaik. 
I may have already installed ant, tomcat etc. on my debian system using 
the debian package manager, for example. But as far as I understand the 
maven concept, it will still go off fetching ant's jars from the 
Internet, without caring about the operating system's package 
management, or its dependencies, and so on.

Using Maven as a way to circumvent package management on an OS is, to 
put it simply, a waste of my resources. Of course, for operating systems 
that have no package management (like Microsoft's products), using Maven 
to download the dependencies is a way to work around the deficits of the 
operating system.

It's still an ugly hack. On systems that do have sane package 
management, like most Linux distributions, it's a Bad Thing(TM), and 
leads to hard-to-manage software.

Let's say, for example, that there is a security bug in some jar file 
Buggy.jar, that is also distributed with Maven, that only is triggered 
on a hypothetical MLinux distribution. The distribution's packagers of 
Buggy.package can fix the problem, update the jar package for their 
distribution, and have all the applications depending on that jar tested 
and automatically fixed by upgrading the single package. Maven can not, 
if the problem and fix is distribution (or operating system) specific. 
Furthermore, there is no way for Maven to update all project.xml files 
that use the Buggy.jar, so all the applications relying on Maven for 
distribution of their jars are vulnerable until their developers release 
a new package, if they do it at all. On the other hand, packagers of a 
distribution can do that work.

The Maven does not, and can not really do the package and operating 
system specific work of all the packagers on those systems.

> lets say that I make applications for persons to use, and I use some
> gui-objects provided from some other company. with maven (provided that
> the other company has their jar-files versioned and on the web)  I don't
> have to distribute their jar-file with my application since maven
> downloads it, I have to do that with an installer or if I use jnlp.
>
> The installer version can do some "optimisations based on the
> plattform,, but IF I use that, I have to make several installers  based
> on which plattforms I let my application run on, but wirh java, I want
> them to be run on any plattform.

That sounds quite nice in theory. In practice, there are differences 
between platforms that matter, and need to be considered, like typical 
locations of libraries, where native libs go, how dependencies are 
resolved, etc. Using Maven to distribute applications is conceptually no 
different than just statically linking everything in a big binary blob. 
The only difference in practice is that you have to distribute the big 
binary blob written in C yourself, whereas if it's written in java Maven 
would do the fetching and linking of binary blobs for you.

Big binary blobs are so 80s ;) They don't work that well with modern 
systems.

> I can also use the maven approach for starting the application from the
> init.d  (if I use an unix type of plattform) or from a cron job. that
> will be hard with webstart/jnlp (but possible with an installer)

I'd assume that different linux distributions have already found ways to 
deal with running tomcat, for example, from their startup scripts. The 
maven approach would seem to circumvent that.

> also with maven I can do some nifty update handling (similiar to
> webstart but more functional according to me) since all I have to do is
> to download the new project-xml file, stopp the application (maven stop)
> and then start it again (maven start) and it wpuld update ge
> application. webstart will update every time it starts the application
> since it checks the jnlp file, but an application that automaticly
> updates itself are usually discourraged by administrators (who knows
> what will be installed and when, I like to be able to controll when
> things gets updated).this is ofcourse also possible with an installer,
> but now it would be my application that would have to check for new
> versions etc, I have to "manually" build it inot my application.

In other words, all I have to do is to use some other tool to manage a 
part of my system. The tool doesn't know about the specifics of my 
system, the applications don't know either. That sounds like a recipe 
for desaster in the long run.

Let's say I update my java runtime to a new version because of a 
security problem that only occurs on my platform. I (and everyone else 
using applications on that platform that use Maven for distribution) 
have to manually check if all the applications still work. In a sane 
distribution system, the packager can do that work, and if necessary 
expose a conflict between an application and an specific runtime in the 
list of dependencies of the application. In the proposed system, 
everyone needs to do it all over.

> So I see many benefits to providing a "maven-execution" system that has
> the basic maven reopsitory handling and a couple of goals
> (start,stop,restart,check,....) and these benefits are mainly not
> covered by an installer or webstart/jnlp)

Both installers and webstart/jnlp are nieche solutions for distribution 
that don't meet the needs of modern operating systems. Legacy systems, 
like Microsoft Windows, that have no concept of package management, 
*may* profit from a Maven-based distribution system, but it would still 
be a nieche solution.

On the other hand, using Maven for distribution makes the job much 
harder for those that package applications for und use applications on 
modern operating systems.

See 
http://java.debian.net/index.php/What%20is%20required%20from%20upstream 
for a brief discourse on how to create packager-friendly releases of 
java software that is supposed to be packaged for linux distributions. 
It's part of a small wiki created by packagers of java applications for 
different Linux systems and free java runtime developers in order to 
find better ways to package java applications on unix systems[1].

cheers,
dalibor topic

[1] http://java.debian.net/index.php/CommonJavaPackaging


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: new idea on maven usage?

[__matthewHawthorne <ma...@apache.org>]

I think the easiest solution to this problem is to make a better effort 
to test Maven (and all other Java programs) on a many JDKs as possible: 
Sun, IBM, Kaffe, etc.  This effort would most likely come from users who 
have a vested interest in having the programs work on a specific 
platform, like BSD users.

Trying to involve Maven in anything native just sounds like a disaster, 
and a basic misinterpretation of what Java is supposed to be about.  If 
certain Java programs don't work on all platforms, then let's improve 
those programs -- instead of converting Maven into something else, 
letting some bad apples spoil the whole scene.

I worked at a place where the admins kept telling us to put our jar 
files in /usr/local/lib.  Most of the time we ignored them, but 
occasionally we couldn't and were forced to have our jars alongside 
billions of *.so files.  My point is that Java is platform-less, and any 
attempt to make it different just seems sideways.

While I'm sure that all Java code is not platform independent, I'd bet 
the farm that the vast majority of it is.  And isn't that the reason 
that we're using Java in the first place?

I'm confused.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: new idea on maven usage?

[Dalibor Topic <ro...@kaffe.org>]

Hi John,

John Casey wrote:
> Maven is a perfectly suited package management tool for its native
> language: Java. If you find some project which _happens_to_be_ built in
> a non-portable way, why not just throw up your own maven repository, and
> add a piece to the default build.properties, placing your repository
> first in the list to check for dependencies?  You can then distribute
> this file with the distro in question, and everyone will be happy. I

That's a nice idea, thanks. Dion proposed something similar, and it 
seems that it could be a way to make Maven play along with native 
package management. Joerg has discussed that aproach with gentoo 
developers, afaik.

> don't understand why it has to turn into such a ground-shifting change.
> While it's definitely not perfect, a very simple patch to maven (to
> remove the Base64 encoder dependency) will accommodate everything you've
> mentioned in your emails, Dalibor.

You must have joined us in the middle of the discussion. That was a 
different thread. Maven's small portability problems that prevent the 
CVS from working on kaffe are unrelated to this thread.

This thread is about a new idea of using maven for software management 
and distribution. There is nothing kaffe-specific in that idea, it's not 
even mine ;)

cheers,
dalibor topic


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: new idea on maven usage?

[John Casey <jd...@commonjava.org>]

Maven is a perfectly suited package management tool for its native
language: Java. If you find some project which _happens_to_be_ built in
a non-portable way, why not just throw up your own maven repository, and
add a piece to the default build.properties, placing your repository
first in the list to check for dependencies?  You can then distribute
this file with the distro in question, and everyone will be happy. I
don't understand why it has to turn into such a ground-shifting change.
While it's definitely not perfect, a very simple patch to maven (to
remove the Base64 encoder dependency) will accommodate everything you've
mentioned in your emails, Dalibor.

-john

On Wed, 2004-02-04 at 16:42, Jason van Zyl wrote:
> On Wed, 2004-02-04 at 16:02, Dalibor Topic wrote:
> 
> > I fully understand that you have to prioritize your schedule to fix the 
> > bugs that affect the most users, like any other OSS project with limited 
> > ressources.
> > 
> > But that clearly shows why Maven wouldn't make for a good software 
> > packaging mechanism to me: you'd have to settle for what works for most 
> > people. Now, what works for most people will not work for a minority. 
> > When they come to you to fix their problems you may not be able to, due 
> > to more pressing bugs on more popular platforms. I foresee a lot of 
> > 'Just use Sun - but Sun doesn't shine on my platform' flamewars down 
> > that road.
> 
> I honestly don't get that riled up about it. I fight the fights I can
> but I'm not going to spend my life battling Sun. I fight them by
> choosing not to use their APIs where I can. As far as Maven goes you can
> send us patches and we will apply them to make Maven work with Kaffe. I
> personally don't care whether anyone uses Maven or not. Obviously I
> would like it if they did but it's no skin off my back. You'll see from
> any history of discussions that involve me that I'm not very dogmatic.
> If Maven doesn't suit your needs, use whatever you like.
> 
> > It's not very clear to me why you'd want to do the work of system 
> > integrators and distributors instead of spending that time improving 
> > Maven. 
> 
> I don't think you really understand what Maven is about. It's about
> development in Java for Java developers. Platform OS packaging
> mechanisms are irrelavent essentially. 
> 
> What you are asking of us is to relinquish control over the repository
> that Maven users are accustomed to and hand that over to people making
> packages for a specific OS. That simply isn't reasonable because that
> immediately requires us to know about specific OS in order for Maven to
> work the way it does now. That is just not going to happen.
> 
> > Maybe you don't see a difference between software development, 
> > software distribution, and software management. I do, so let me try to 
> > explain it ;)
> > 
> > When you look around at UNIX programs as they are shipped in Linux 
> > distributions, or BSDs, or commercial UNIX implementations, most of them 
> > are customized by the distributors in order to make them fit in better 
> > into the platform. Of course there is POSIX, but in the real world, 
> > still everyone feels the need to be able to make (often necessary) 
> > changes to produce a better package than the original developers did (or 
> > can do, in case of small platforms) and they often succeed.
> > 
> > If I understood your arguments correctly, you seem to think that such 
> > platforms-specific adaptations are unnecessary with java applications 
> > and libraries. In my experience, that is not true, as soon as you move 
> > away from the setup the original developers used for developement and 
> > testing, even for java applications. The hidden, unwarrented assumptions 
> > only start to show where the code is used in an environment that breaks 
> > them.
> 
> After many years of writing Java applications I have not found many
> great difficulties running Java applications on different platforms.
> Most problems have been with platform specific startup scripts.
> 
> Maven having to deal with the innumerable inconsistencies of all the
> existing package managers would make Maven nearly impossible to use in
> my estimation and would lose all of what makes it attractive to use.
> 
> I have honestly never used a JDK that comes in a package. I download the
> JDK and use it in the same way on the different platforms I deploy the
> application on.
> 
> > >>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.
> > 
> > Nothing, if I understand your explanation about how Maven works correctly.
> > 
> > The thing is, I'd like to (have Maven) pick up the platform specific 
> > adaptations and fixes, instead of the generic binary/sources from the 
> > upstream. I'd also like versioning of dependencies, integration with 
> > native package management, etc. See for example 
> > http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/ch-rpm.html
> > for a description of what a package management tool can do, and what the 
> > design principles behind it are. I see Maven (or actually the POMs) as a 
> > tool that might be useful in the package management of Java 
> > applications, but not as replacement for native package management.
> 
> We don't want native package management, that's the whole point I think
> you're missing here. We do not want to have to deal with the platform at
> all. There would be widespread, immediate and problems if Maven had to
> deal with platform specifics.
> 
> How would you propose that we deal with the variances of every platform
> specific packager? Say all of here were Windows users and knew nothing
> about Linux platforms? What are we supposed to do rely on packages to
> make everything?
> 
> > > 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 artifact from Maven's repository may not work on the system, so an 
> > OS-native replacement may be necessary.
> 
> Huh? Maven's repository has all pure Java artifacts. For the number of
> problems that might occur it is not worth interacting with native
> packaging systems in my estimation.
> 
> > Take for example any ant-1.5*.jar artifact from Maven on JDK 1.4.2 and 
> > the Javah task will not work, according to the Ant 1.5.4 release 
> > annoucement. No, ant 1.5.4 was not on ibiblio.org/maven today ;)
> 
> The example involves native code does it not? Javah? I don't really find
> that a compelling reason to use native package management systems.
> 
> > > 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.
> > 
> > I think it depends on how you define platform specific. If we can agree 
> > that the runtime is a part of the platform description, then I'm quite 
> > positive that ibiblio.org/maven distributes quite a few platform 
> > specific artifacts.
> 
> The platform is the OS for which there is a standard JDK. Period. So I
> don't think you'll find many artifact in ibiblio that aren't usable by
> your typical Java developer.
> 
> > Whether the original developers endorse a native binary or not, doesn't 
> > mean that people can't do it, if the licensing terms permit it and are 
> > followed in the process. 
> 
> Of course they can, it's a matter of courtesy to inform the project
> what's been done with their code.
> 
> > See http://people.redhat.com/gbenson/naoko/ and 
> > http://sources.redhat.com/rhug/ for examples. That's the beaty of open 
> > source development to me.
> > 
> > I'm not aware of any OSI certified open source license that requires me 
> > to report back to the original authors what I'm doing with their code as 
> > long as I follow the license terms. ;)
> 
> Not a requirement, a simply courtesy. As I would not like to see a
> report of Maven not working on platformX and then find out they were
> using a something created with GCJ.
> 
> > > 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.
> > 
> > That's O.K. I wouldn't ask for that ;)
> > 
> > The problemaic thing is that, as I've tried to show with quite a few 
> > examples that you decided to nip in the bud, is that a lot of supposedly 
> > pure java code, is in fact using unwarranted assumptions about its 
> > runtime, and the platform it's running on. 
> 
> How is assuming the use of a standard JDK on different platforms
> erroneous? You think it's reasonable to use a native package management
> system because sun.* classes don't work on Kaffe?
> 
> > You may not realize it, but 
> > maven's ibiblio.org repository is also distributing platform-dependant 
> > code, despite that the code written in java, and not in C.
> 
> What code is that exactly? My assumption is the use of a standard JDK on
> a give platform. I don't consider sun.* classes to be a problem for
> example.
> 
> > Claiming that the JARs in Maven's repository are somehow more suited for 
> > running on a specific platform where they may never have been tested at 
> > all, rather than native packages which have gone through a quality 
> > assurance process by the distributors and have been verified to work, 
> > (or fixed on the specific platform,) doesn't make much sense to me, as a 
> > *user*, and even less, as an *administrator*. 
> 
> This entirely defeats the whole purpose of Java. We rely on JDKs kicked
> out by Sun or IBM where we don't have to worry about these things.
> 
> > Maven's concept of 
> > centralized distribution of binaries makes sense makes sense to me as a 
> > *developer*, though. And of course, it probably works great where 
> > developer == administrator == user [1] ;)
> 
> We have lots of normal users who aren't administrators. That's the
> beauty of Maven. You don't need to know anything about a native package
> manager for example. I can take Mr Developer who is used to Windows, put
> him on a RedHat box with Maven and he doesn't need to know squat about
> RPM. 
> 
> If you could provide seemless integration with the OS specifics then I
> might consider it but I know that's not even a remote possibility given
> the state of packaging mechanism. Who would do the work of assuring the
> that things would work as easily as they do now? I'm telling you now
> that no one would and things would fall into complete disarray. There
> isn't a snowballs chance in hell that volunteers would be able to spare
> the time needed required to do this task. But fortunately for us we
> don't have to worry about this because Maven works the same way on every
> platform that provides a standard JDK and that's the best we can ask
> for.
> 
> You're not going to convince of flipping Maven over to using native
> packaging systems but I would be curious to know how you would propose
> we use native packaging systems. How would you go about even maintaining
> the N interfaces we would require to take artifacts from the OS specific
> repository?
> 
> > cheers,
> > dalibor topic
> > 
> > [1] Windows, I guess.
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: new idea on maven usage?

[Dalibor Topic <ro...@kaffe.org>]

Hi Jason,

thanks a lot for the quick and insightful reply!

Jason van Zyl wrote:
> On Wed, 2004-02-04 at 16:02, Dalibor Topic wrote:

> I honestly don't get that riled up about it. I fight the fights I can
> but I'm not going to spend my life battling Sun. I fight them by
> choosing not to use their APIs where I can. As far as Maven goes you can
> send us patches and we will apply them to make Maven work with Kaffe. I
> personally don't care whether anyone uses Maven or not. Obviously I
> would like it if they did but it's no skin off my back. You'll see from
> any history of discussions that involve me that I'm not very dogmatic.
> If Maven doesn't suit your needs, use whatever you like.

It suits my needs well, thanks a lot for developing on it.

I hope you are not taking my comments about what I consider to be an 
inferiority of Maven compared to other solutions in one, still mostly 
hypothetical use context (we're in this new idea - software distribution 
and management thread, remember?) as personal insult. I'm not asking you 
to fight any fights, for skin samples, etc, I'm interested in discussing 
what I consider to be limitations of the new-idea approach, and in your 
insightful comments.

I hope to gain better understanding through such discussion where this 
very cool software is going and how Linux distributions can cooperate 
with Maven developers on creating a better way of distributing and 
managing java libraries and applications on Linux, specifically. Better 
hopefully meaning 'even better than with Maven alone'.

> I don't think you really understand what Maven is about. It's about
> development in Java for Java developers. Platform OS packaging
> mechanisms are irrelavent essentially. 

Well, saying that platform specific package management mechanism are 
irrelevant doesn't magically make them so ;) They are about using 
software (for users) and distributing and managing software (for 
administrators).

I'm not saying that Maven can not be used for those things, I'm saying 
that better solutions exist for some platforms, and that it would be 
nice to have Maven somehow integrate with them.

The premise being that Maven as a software distribution and management 
mechanism is a solution for all platforms, I've presented many arguments 
why a centralized repository would not be well suited for such a task. 
I've also tried to argue that non-portable java software is more common 
than some dicutants assume, and provided lots of examples where pure 
java does not imply portability, some of which have become java folklore 
(double-check-locking). Therefore, my argument goes, in order to have a 
higher chance of working software on a platform, one should not rely on 
download of untested components from a centralized repository, but rely 
on the work of people familiar with that platform that results in tested 
and tried packages for that platform.

This could involve platform-specific repositories. As far as I have 
understood the discussion so far, Maven supports that, which would solve 
a few of the problems.

> What you are asking of us is to relinquish control over the repository
> that Maven users are accustomed to and hand that over to people making
> packages for a specific OS. That simply isn't reasonable because that
> immediately requires us to know about specific OS in order for Maven to
> work the way it does now. That is just not going to happen.

I don't think I ever asked you to give up on ibiblio.org/maven in this 
discussion !?

You, as a Maven *developer*, don't have to know anything about a 
specific OS. That's what the *distributors* (i.e. packagers) are for. 
Different tasks with different roles involve different people with 
different skills.

> After many years of writing Java applications I have not found many
> great difficulties running Java applications on different platforms.
> Most problems have been with platform specific startup scripts.
 >
> Maven having to deal with the innumerable inconsistencies of all the
> existing package managers would make Maven nearly impossible to use in
> my estimation and would lose all of what makes it attractive to use.
>
> I have honestly never used a JDK that comes in a package. I download the
> JDK and use it in the same way on the different platforms I deploy the
> application on.

After many years of *running* Java applications on a variety of 
platforms, I think you can consider yourself very lucky. For example, 
one of current funnies with using the JDK atm seems to be the buggy 
default JAXP parser implementations that come with it, so that it's 
necessary for some applications to use -bootclasspath to override the 
defaults. Not the startup scripts, the core (yay, pure java!) libraries.

Then of course, there is the problem that Sun doesn't really suport any 
Linux distribution beside a handful listed here 
http://java.sun.com/j2se/1.4.2/system-configurations.html so that 
running Sun's JDK on (for example) Mandrake, Debian, Gentoo is not 
supported by Sun. And more often than not, in my experience, the 
download from Sun doesn't work that well on those platforms, i.e. it 
happily crashes. Google for Sun+JVM+NPTL for a lot of recent fun with 
Sun's JDK.

> We don't want native package management, that's the whole point I think
> you're missing here. We do not want to have to deal with the platform at
> all. There would be widespread, immediate and problems if Maven had to
> deal with platform specifics.

I've argued that there are problems when you don't deal with 
platform-specifics, you've argued that there are problems when you do. I 
guess it's a classical 'pick your poison' setup ;)

> How would you propose that we deal with the variances of every platform
> specific packager? Say all of here were Windows users and knew nothing
> about Linux platforms? What are we supposed to do rely on packages to
> make everything?

Maven developers shouldn't have to deal with package management 
specifics at all. Just put the sources for all artifacts in the 
repository along with the binaries and build scripts, so that the 
binaries can be recreated if necessary.

Mind you, some licenses demand that anyway. I've seen that the ibiblio 
repository hosts GPLd artifacts, you may wnat to check clause 3 of the 
GPL for details.

The packaging is the work of distributors. The way I understand the 
maven concept, they could in theory write a Maven plugin for their 
distributions that would interact with the native package management, 
ignore the ibiblio.org repository and everyone would be happy.

> Huh? Maven's repository has all pure Java artifacts. For the number of
> problems that might occur it is not worth interacting with native
> packaging systems in my estimation.

For the people suffering from those problems it would be ;)

>>Take for example any ant-1.5*.jar artifact from Maven on JDK 1.4.2 and 
>>the Javah task will not work, according to the Ant 1.5.4 release 
>>annoucement. No, ant 1.5.4 was not on ibiblio.org/maven today ;)
> 
> 
> The example involves native code does it not? Javah? I don't really find
> that a compelling reason to use native package management systems.

Ant doesn't contain any native code. It calls a specific java class in a 
sun.* package to run Javah. Read the fine announcement ;)

Oh, and it's been biting Maven users: http://java2.5341.com/msg/43973.html

> The platform is the OS for which there is a standard JDK. Period. So I
> don't think you'll find many artifact in ibiblio that aren't usable by
> your typical Java developer.

What is a 'typical' Java developer? A 'standard' JDK?

These are not rehtorical questions, they are there to show you that it 
would be hard to do a good job supporting all possible platforms and 
types of developers from a central repository. You'd need to make 
concessions.

That's OK. I'd only like you to realize that you'd be making 
concessions, and to be clear about that to your users and yourself.

>>Whether the original developers endorse a native binary or not, doesn't 
>>mean that people can't do it, if the licensing terms permit it and are 
>>followed in the process. 
> 
> 
> Of course they can, it's a matter of courtesy to inform the project
> what's been done with their code.

I agree. You didn't mention matters of courtesy before though ;)

>>See http://people.redhat.com/gbenson/naoko/ and 
>>http://sources.redhat.com/rhug/ for examples. That's the beaty of open 
>>source development to me.
>>
>>I'm not aware of any OSI certified open source license that requires me 
>>to report back to the original authors what I'm doing with their code as 
>>long as I follow the license terms. ;)
> 
> 
> Not a requirement, a simply courtesy. As I would not like to see a
> report of Maven not working on platformX and then find out they were
> using a something created with GCJ.

Sure. That's why most distributions have their own bug trackers, where 
the packagers sort bug reports into distribution specific, and general 
problems. The general problems are usually fixed together with the 
upstream (i.e. the original developers), the distribution specific ones 
together with the distribution developers.

So chances are you won't find out about the bug, until it's clear that 
it's a bug in Maven.

> How is assuming the use of a standard JDK on different platforms
> erroneous? You think it's reasonable to use a native package management
> system because sun.* classes don't work on Kaffe?

Because sun.* classes don't work in general. Please read 
http://java.sun.com/products/jdk/faq/faq-sun-packages.html for 
information from Sun about why it's not possible to have a portable 
program while using sun.* classes. I'm not making it up, it's a very 
educational read.

>>You may not realize it, but 
>>maven's ibiblio.org repository is also distributing platform-dependant 
>>code, despite that the code written in java, and not in C.
> 
> 
> What code is that exactly? My assumption is the use of a standard JDK on
> a give platform. I don't consider sun.* classes to be a problem for
> example.

Sun does consider them to be a problem. I believe they have a little 
more weight in saying what constitues the Java API ;)

So any code linking directly to sun.* is unportable, according to Sun.

Since Maven's central repository only distributes binary JARs, I'd have 
a hard time pointing which JARs specifically are unportable. But since 
some Maven developers must have put them there in the first place, I 
believe they are in a much better condition to answer your question than 
I am. ;)

>>Claiming that the JARs in Maven's repository are somehow more suited for 
>>running on a specific platform where they may never have been tested at 
>>all, rather than native packages which have gone through a quality 
>>assurance process by the distributors and have been verified to work, 
>>(or fixed on the specific platform,) doesn't make much sense to me, as a 
>>*user*, and even less, as an *administrator*. 
> 
> 
> This entirely defeats the whole purpose of Java. We rely on JDKs kicked
> out by Sun or IBM where we don't have to worry about these things.

As I've explained, that's not good enough. There is a lot more thought 
necessary to write portable Java code than to expect that using Sun's or 
IBM's JDK (which can differ slightly in their class library 
implemenations, by the way) will make it portable somehow automagically.

> If you could provide seemless integration with the OS specifics then I
> might consider it but I know that's not even a remote possibility given
> the state of packaging mechanism. Who would do the work of assuring the
> that things would work as easily as they do now? I'm telling you now
> that no one would and things would fall into complete disarray. There
> isn't a snowballs chance in hell that volunteers would be able to spare
> the time needed required to do this task. But fortunately for us we
> don't have to worry about this because Maven works the same way on every
> platform that provides a standard JDK and that's the best we can ask
> for.

I thought Maven was a volunteer driven project. If it's not, then my 
compliments for your generous contributions to the world of open source 
software. In my experience, some volunteer based projects can get quite 
far. Others fail. There is no ultimate guarantee Maven will be still 
around next year.

Maven can work the same way, even on the few selected platforms with 
just the Sun JDKs installed, but that doesn't matter if the artifacts, 
which are distributed though it, don't do it due to unportable Java 
code. I've showed you examples, I've showed you a Maven user being 
bitten by an JDK upgrade.

To me, the new idea looks like trying to apply the golden hammer 
anti-pattern. I wish you luck, but I remain reserved that it will work 
that well on any platform other than latest Sun's JDK on Windows XP (or 
whatever platform-runtime combination Maven developers tend to prefer 
over others).

> You're not going to convince of flipping Maven over to using native
> packaging systems but I would be curious to know how you would propose
> we use native packaging systems. How would you go about even maintaining
> the N interfaces we would require to take artifacts from the OS specific
> repository?

I'm not trying to do flip over Maven. Please, let's keep the discussion 
on technical terms, and away from the realms of speculation.

The integration interfaces could be maintained by distributions, since 
they are distribution specific. Basically, Maven's dependency resolution 
mechanism would need to be patched in a distribution specific way to 
fulfill dependencies by mapping them to a distributions' packages, and 
asking the distribution's package manager to install them.

How feasible would that be with a maven plugin?

cheers,
dalibor topic


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: new idea on maven usage?

[Jason van Zyl <jv...@maven.org>]

On Wed, 2004-02-04 at 16:02, Dalibor Topic wrote:

> I fully understand that you have to prioritize your schedule to fix the 
> bugs that affect the most users, like any other OSS project with limited 
> ressources.
> 
> But that clearly shows why Maven wouldn't make for a good software 
> packaging mechanism to me: you'd have to settle for what works for most 
> people. Now, what works for most people will not work for a minority. 
> When they come to you to fix their problems you may not be able to, due 
> to more pressing bugs on more popular platforms. I foresee a lot of 
> 'Just use Sun - but Sun doesn't shine on my platform' flamewars down 
> that road.

I honestly don't get that riled up about it. I fight the fights I can
but I'm not going to spend my life battling Sun. I fight them by
choosing not to use their APIs where I can. As far as Maven goes you can
send us patches and we will apply them to make Maven work with Kaffe. I
personally don't care whether anyone uses Maven or not. Obviously I
would like it if they did but it's no skin off my back. You'll see from
any history of discussions that involve me that I'm not very dogmatic.
If Maven doesn't suit your needs, use whatever you like.

> It's not very clear to me why you'd want to do the work of system 
> integrators and distributors instead of spending that time improving 
> Maven. 

I don't think you really understand what Maven is about. It's about
development in Java for Java developers. Platform OS packaging
mechanisms are irrelavent essentially. 

What you are asking of us is to relinquish control over the repository
that Maven users are accustomed to and hand that over to people making
packages for a specific OS. That simply isn't reasonable because that
immediately requires us to know about specific OS in order for Maven to
work the way it does now. That is just not going to happen.

> Maybe you don't see a difference between software development, 
> software distribution, and software management. I do, so let me try to 
> explain it ;)
> 
> When you look around at UNIX programs as they are shipped in Linux 
> distributions, or BSDs, or commercial UNIX implementations, most of them 
> are customized by the distributors in order to make them fit in better 
> into the platform. Of course there is POSIX, but in the real world, 
> still everyone feels the need to be able to make (often necessary) 
> changes to produce a better package than the original developers did (or 
> can do, in case of small platforms) and they often succeed.
> 
> If I understood your arguments correctly, you seem to think that such 
> platforms-specific adaptations are unnecessary with java applications 
> and libraries. In my experience, that is not true, as soon as you move 
> away from the setup the original developers used for developement and 
> testing, even for java applications. The hidden, unwarrented assumptions 
> only start to show where the code is used in an environment that breaks 
> them.

After many years of writing Java applications I have not found many
great difficulties running Java applications on different platforms.
Most problems have been with platform specific startup scripts.

Maven having to deal with the innumerable inconsistencies of all the
existing package managers would make Maven nearly impossible to use in
my estimation and would lose all of what makes it attractive to use.

I have honestly never used a JDK that comes in a package. I download the
JDK and use it in the same way on the different platforms I deploy the
application on.

> >>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.
> 
> Nothing, if I understand your explanation about how Maven works correctly.
> 
> The thing is, I'd like to (have Maven) pick up the platform specific 
> adaptations and fixes, instead of the generic binary/sources from the 
> upstream. I'd also like versioning of dependencies, integration with 
> native package management, etc. See for example 
> http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/ch-rpm.html
> for a description of what a package management tool can do, and what the 
> design principles behind it are. I see Maven (or actually the POMs) as a 
> tool that might be useful in the package management of Java 
> applications, but not as replacement for native package management.

We don't want native package management, that's the whole point I think
you're missing here. We do not want to have to deal with the platform at
all. There would be widespread, immediate and problems if Maven had to
deal with platform specifics.

How would you propose that we deal with the variances of every platform
specific packager? Say all of here were Windows users and knew nothing
about Linux platforms? What are we supposed to do rely on packages to
make everything?

> > 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 artifact from Maven's repository may not work on the system, so an 
> OS-native replacement may be necessary.

Huh? Maven's repository has all pure Java artifacts. For the number of
problems that might occur it is not worth interacting with native
packaging systems in my estimation.

> Take for example any ant-1.5*.jar artifact from Maven on JDK 1.4.2 and 
> the Javah task will not work, according to the Ant 1.5.4 release 
> annoucement. No, ant 1.5.4 was not on ibiblio.org/maven today ;)

The example involves native code does it not? Javah? I don't really find
that a compelling reason to use native package management systems.

> > 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.
> 
> I think it depends on how you define platform specific. If we can agree 
> that the runtime is a part of the platform description, then I'm quite 
> positive that ibiblio.org/maven distributes quite a few platform 
> specific artifacts.

The platform is the OS for which there is a standard JDK. Period. So I
don't think you'll find many artifact in ibiblio that aren't usable by
your typical Java developer.

> Whether the original developers endorse a native binary or not, doesn't 
> mean that people can't do it, if the licensing terms permit it and are 
> followed in the process. 

Of course they can, it's a matter of courtesy to inform the project
what's been done with their code.

> See http://people.redhat.com/gbenson/naoko/ and 
> http://sources.redhat.com/rhug/ for examples. That's the beaty of open 
> source development to me.
> 
> I'm not aware of any OSI certified open source license that requires me 
> to report back to the original authors what I'm doing with their code as 
> long as I follow the license terms. ;)

Not a requirement, a simply courtesy. As I would not like to see a
report of Maven not working on platformX and then find out they were
using a something created with GCJ.

> > 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.
> 
> That's O.K. I wouldn't ask for that ;)
> 
> The problemaic thing is that, as I've tried to show with quite a few 
> examples that you decided to nip in the bud, is that a lot of supposedly 
> pure java code, is in fact using unwarranted assumptions about its 
> runtime, and the platform it's running on. 

How is assuming the use of a standard JDK on different platforms
erroneous? You think it's reasonable to use a native package management
system because sun.* classes don't work on Kaffe?

> You may not realize it, but 
> maven's ibiblio.org repository is also distributing platform-dependant 
> code, despite that the code written in java, and not in C.

What code is that exactly? My assumption is the use of a standard JDK on
a give platform. I don't consider sun.* classes to be a problem for
example.

> Claiming that the JARs in Maven's repository are somehow more suited for 
> running on a specific platform where they may never have been tested at 
> all, rather than native packages which have gone through a quality 
> assurance process by the distributors and have been verified to work, 
> (or fixed on the specific platform,) doesn't make much sense to me, as a 
> *user*, and even less, as an *administrator*. 

This entirely defeats the whole purpose of Java. We rely on JDKs kicked
out by Sun or IBM where we don't have to worry about these things.

> Maven's concept of 
> centralized distribution of binaries makes sense makes sense to me as a 
> *developer*, though. And of course, it probably works great where 
> developer == administrator == user [1] ;)

We have lots of normal users who aren't administrators. That's the
beauty of Maven. You don't need to know anything about a native package
manager for example. I can take Mr Developer who is used to Windows, put
him on a RedHat box with Maven and he doesn't need to know squat about
RPM. 

If you could provide seemless integration with the OS specifics then I
might consider it but I know that's not even a remote possibility given
the state of packaging mechanism. Who would do the work of assuring the
that things would work as easily as they do now? I'm telling you now
that no one would and things would fall into complete disarray. There
isn't a snowballs chance in hell that volunteers would be able to spare
the time needed required to do this task. But fortunately for us we
don't have to worry about this because Maven works the same way on every
platform that provides a standard JDK and that's the best we can ask
for.

You're not going to convince of flipping Maven over to using native
packaging systems but I would be curious to know how you would propose
we use native packaging systems. How would you go about even maintaining
the N interfaces we would require to take artifacts from the OS specific
repository?

> cheers,
> dalibor topic
> 
> [1] Windows, I guess.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org

-- 
jvz.

Jason van Zyl
jason@maven.org
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: new idea on maven usage?

[Dalibor Topic <ro...@kaffe.org>]

Hi Jason,

Jason van Zyl wrote:
> 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.

As far as I can see it as an outsider, Apache is in a somewhat special 
love-hate relationship with Sun. Neverthless, Apache members have done a 
lot to open the process up, and that's great.

But its still impossible for an OSS project to get a copy of the JDK 
1.4.2 TCK, under non-discriminating terms, for example. If you have 
information to the contrary, I'd be glad to hear about it.

> 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.

Great! Thank you very much! I don't see any comments from you on 
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-1129 though, so 
maybe we should discuss the fix there. Dion explained that my fix broke 
the bootstrap, so I assume yours doesn't ;) Send me an e-mail when it's 
in the CVS so that I can give it a go on kaffe.

Unfortunately, in my experience, I see a lot of code using sun.* 
packages. For example, taking the freshly released ant 1.6.1 beta 1:

bash-2.05a$ grep -r import . | grep sun
./src/main/org/apache/tools/ant/taskdefs/email/UUMailer.java:import 
sun.misc.UUEncoder;
./src/main/org/apache/tools/ant/taskdefs/optional/image/Image.java:import 
com.sun.media.jai.codec.FileSeekableStream;

I can't say how many projects have this sort of problems, but from my 
experience in getting software to run on kaffe, there is a lot of 
unportable java code written by programmers not aware of their 
assumptions out there. I'm currently involved with an effort to clean up 
OpenOffice, and it's no fun. In fact, some Linux distributions ship 
OpenOffice with Java code disabled or ripped out, since it's so heavily 
tied to Sun's JVM.

>>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.

I fully understand that you have to prioritize your schedule to fix the 
bugs that affect the most users, like any other OSS project with limited 
ressources.

But that clearly shows why Maven wouldn't make for a good software 
packaging mechanism to me: you'd have to settle for what works for most 
people. Now, what works for most people will not work for a minority. 
When they come to you to fix their problems you may not be able to, due 
to more pressing bugs on more popular platforms. I foresee a lot of 
'Just use Sun - but Sun doesn't shine on my platform' flamewars down 
that road.

It's not very clear to me why you'd want to do the work of system 
integrators and distributors instead of spending that time improving 
Maven. Maybe you don't see a difference between software development, 
software distribution, and software management. I do, so let me try to 
explain it ;)

When you look around at UNIX programs as they are shipped in Linux 
distributions, or BSDs, or commercial UNIX implementations, most of them 
are customized by the distributors in order to make them fit in better 
into the platform. Of course there is POSIX, but in the real world, 
still everyone feels the need to be able to make (often necessary) 
changes to produce a better package than the original developers did (or 
can do, in case of small platforms) and they often succeed.

If I understood your arguments correctly, you seem to think that such 
platforms-specific adaptations are unnecessary with java applications 
and libraries. In my experience, that is not true, as soon as you move 
away from the setup the original developers used for developement and 
testing, even for java applications. The hidden, unwarrented assumptions 
only start to show where the code is used in an environment that breaks 
them.

>>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.

Nothing, if I understand your explanation about how Maven works correctly.

The thing is, I'd like to (have Maven) pick up the platform specific 
adaptations and fixes, instead of the generic binary/sources from the 
upstream. I'd also like versioning of dependencies, integration with 
native package management, etc. See for example 
http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/ch-rpm.html 
for a description of what a package management tool can do, and what the 
design principles behind it are. I see Maven (or actually the POMs) as a 
tool that might be useful in the package management of Java 
applications, but not as replacement for native package management.

> 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 artifact from Maven's repository may not work on the system, so an 
OS-native replacement may be necessary.

Take for example any ant-1.5*.jar artifact from Maven on JDK 1.4.2 and 
the Javah task will not work, according to the Ant 1.5.4 release 
annoucement. No, ant 1.5.4 was not on ibiblio.org/maven today ;)

> 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.

I think it depends on how you define platform specific. If we can agree 
that the runtime is a part of the platform description, then I'm quite 
positive that ibiblio.org/maven distributes quite a few platform 
specific artifacts.

Whether the original developers endorse a native binary or not, doesn't 
mean that people can't do it, if the licensing terms permit it and are 
followed in the process. See http://people.redhat.com/gbenson/naoko/ and 
http://sources.redhat.com/rhug/ for examples. That's the beaty of open 
source development to me.

I'm not aware of any OSI certified open source license that requires me 
to report back to the original authors what I'm doing with their code as 
long as I follow the license terms. ;)

> 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.

That's O.K. I wouldn't ask for that ;)

The problemaic thing is that, as I've tried to show with quite a few 
examples that you decided to nip in the bud, is that a lot of supposedly 
pure java code, is in fact using unwarranted assumptions about its 
runtime, and the platform it's running on. You may not realize it, but 
maven's ibiblio.org repository is also distributing platform-dependant 
code, despite that the code written in java, and not in C.

Claiming that the JARs in Maven's repository are somehow more suited for 
running on a specific platform where they may never have been tested at 
all, rather than native packages which have gone through a quality 
assurance process by the distributors and have been verified to work, 
(or fixed on the specific platform,) doesn't make much sense to me, as a 
*user*, and even less, as an *administrator*. Maven's concept of 
centralized distribution of binaries makes sense makes sense to me as a 
*developer*, though. And of course, it probably works great where 
developer == administrator == user [1] ;)

cheers,
dalibor topic

[1] Windows, I guess.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: new idea on maven usage?

[Dalibor Topic <ro...@kaffe.org>]

Hi Rafal,

Rafal Krzewski wrote:
> Dalibor Topic wrote:
> 
> 
>>But this is not the proper forum to discuss package management systems.
>>The thread is about using maven for package management, and I'm arguing
>>that it's not suited for it.
> 
> 
> Dude, you keep missing the point! Maven *is not* and does not *pose*
> itself to be a package management system!

Dude, you must have joined late in the thread ;) It's about a 
hypothetical, novel idea to use Maven not just as a build system, but 
also to distribute and manage software. It's not a general criticism of 
Maven.

It starts here 
http://article.gmane.org/gmane.comp.jakarta.turbine.maven.user/10502 and 
evolved into a discussion of how well Maven is suited for software 
distribution and management. The context is that novel idea, not Maven 
as it is.

I'm arguing it's not, that it's an inferior solution compared to native 
package management and in the case of software management and 
distribution it would be beneficial to employ native packages of 
artifacts where available. All within the context of that novel idea.

I see that we agree (though you may have misunderstood my intentions), 
and I pretty much agree with the rest of your post.

I'm not arguing that Maven is concerned with platform-dependencies, nor 
am I arguing that it should be. That's not very necessary in the context 
of Maven as a build tool.

But since the novel idea was about software distribution and management, 
not developement, I'm arguing with a lot of examples that 
platform-dependencies come into play when you deal with software 
distribution and management. I also questioned the implied notion of 
portability employed by some discutants, presenting real-world proof of 
'pure java' not automatically implying being portable across 
platforms/runtimes/architectures.

> It is a tool to build java libraries. And to document them. It is not
> concerned with the fact of the resulting library being specific to a
> single platform/architecture or general.

And from all that I can say from using it, it does the job as a build 
tool very nicely.

> This may be considered unfortunate, but it's not Maven's mission to
> provide remedy for this situation. There is demand in Java community for
> statically assembled applications, and Maven meets this demand.

I fully agree. In that limited context, using Maven for software 
distribution and management makes sense, as all you have are big binary 
blobs. But in the context of general software distribution and 
management system, which was the novel idea, big binary blobs are not a 
great idea. ;)

> I'd certainly love to see Maven running on as many platforms as
> possible, and being as much platform agnostic in the way it operates as
> it is possible.

I agree, and I'm as glad to help with testing, patches and bug reports 
as I'be been before.

cheers,
dalibor topic


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: new idea on maven usage?

[Rafal Krzewski <Ra...@caltha.pl>]

Dalibor Topic wrote:

> But this is not the proper forum to discuss package management systems.
> The thread is about using maven for package management, and I'm arguing
> that it's not suited for it.

Dude, you keep missing the point! Maven *is not* and does not *pose*
itself to be a package management system!

It is a tool to build java libraries. And to document them. It is not
concerned with the fact of the resulting library being specific to a
single platform/architecture or general.

Second, it allows assembling libraries into applications (war, ear,
uber-jar etc). I guess you can compare such an application to a
statically linked C programm.

Chances are such application is not porable across some of the platforms
in existence. It does support safe and easy replacement of bits that
have been released with security fixes, or are available optimized in a
platform specific manner. You have a better chance that with statically
built C executable, but still you can break the application not knowing it.

This may be considered unfortunate, but it's not Maven's mission to
provide remedy for this situation. There is demand in Java community for
statically assembled applications, and Maven meets this demand.

I'd certainly love to see Maven running on as many platforms as
possible, and being as much platform agnostic in the way it operates as
it is possible.

regards,
R.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: new idea on maven usage?

[Dalibor Topic <ro...@kaffe.org>]

Hi John,

John Casey wrote:
> being the BSD's and Debians of the world.  The problem with BSD is that
> they don't even port the JVM quickly enough to be considered relevant.

The BSDs are not supported by Sun.

Sun's JDK code is not open source, so they are not allowed to just take 
it, port it and distribute it. Read the fine license of Sun's source 
code releases ;)

I'll skip the flame-fest invitation of how relevant BSDs are. It doesn't 
matter if they are relevant to you, it matters if they are relevant to 
their users ;) If you don't consider them to be relevant, Maven can 
hardly claim to be truely 'cross-platform and just works out of the 
box'. More like 'cross-platform and just works out of the box (on a few 
selected platforms)' ;)

Which is what I've been saying all along ;)

> If we tried to program strictly for BSD, we'd all still be stuck on JDK
> 1.3. As for Debian, from what I've heard it's a nice system, but you
> can't make sweeping, generalized statements about package managers when
> this is nearly the only relevant example. In short, the result of my
> experience with dependency management in most package management
> software has been increased blood pressure and (I'm sure) a shortened
> life span. Obviously, I'm no expert, but I believe I can take a fair
> crack at representing the masses. ;)

Package management is not meant as a passtime for the masses, but to 
make the work easier for system administrators. ;)

Debian is not the only nice system out there. I've heard very nice 
things about gentoo's 'source only' package management, for example.

But this is not the proper forum to discuss package management systems. 
The thread is about using maven for package management, and I'm arguing 
that it's not suited for it.

> Is maven the right thing to use for managing native code? Probably not,
> at least by itself. 

Definitely not. It may be O.K. for whatever environment Maven developers 
decide to use, but it would fail horribly on others.

Fetch GNU libtool, read the sources, and weep ;) Even building dynamic 
libraries in C and C++ is very painful and platform specific, don't get 
me started about managing different versions of dynamic native libraries 
on the same system. People are building Linux distributions for embedded 
systems that use uClibc insted of GNU libc. Maven would need to host all 
possible combinations of native-library * compiler-version * libc-type * 
libc-version and that's just for starters. I haven't even mentioned the 
different configuration flags available for native libraries at compile 
time. Down that centralized path lies insanity. ;)

> Does it have an appreciable advantage for most users over 99% of the
> dependency management field? OH, Hell yes. 

When 99% of the field has no dependency management at all (i.e. 
Windows), that's hardly that surprising, isn't it ? ;)

I'd be interested in what Maven can offer that a native package manager 
(say dpkg) can not.

cheers,
dalibor topic


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: new idea on maven usage?

[Jason van Zyl <jv...@maven.org>]

On Mon, 2004-02-02 at 12:07, John Casey wrote:
> Just my 2-cents, but...
> 
> I can definitely say that if maven went to an OS-specific repository
> with packages (rpm, etc.) I'd stop using it so fast it would make your
> head spin. 

Which is how I think most would feel. To go from something that we have
full control over, the repository and the mechanism in which the
artifacts are used, to something where we are at the mercy of the OS is
not a reasonable. 

> The current state of packaging software on most projects today seems to
> range from non-existent (Windows) to poor (RedHat, et al) with outliers
> being the BSD's and Debians of the world.  The problem with BSD is that
> they don't even port the JVM quickly enough to be considered relevant.
> If we tried to program strictly for BSD, we'd all still be stuck on JDK
> 1.3. As for Debian, from what I've heard it's a nice system, but you
> can't make sweeping, generalized statements about package managers when
> this is nearly the only relevant example. In short, the result of my
> experience with dependency management in most package management
> software has been increased blood pressure and (I'm sure) a shortened
> life span. Obviously, I'm no expert, but I believe I can take a fair
> crack at representing the masses. ;)

Definitely. Most folks developing with Java do so because they don't
want to have to use anything platform specific. 

> Is maven the right thing to use for managing native code? Probably not,
> at least by itself. 

Right, I think that if you are mixing Java and native code then a plugin
can be written that cooperates with the underlying OS. Or a series of
plugins where each one deals with a particular OS. Or not use Maven at
all if it doesn't suit.

> Does it have an appreciable advantage for most users over 99% of the
> dependency management field? OH, Hell yes. 
> 
> As for its deficiencies, I believe a tiny introduction of execution
> hooks (as in, post-bootstrap, pre-*-execution) would definitely allow
> plugin development to address them all.
> 
> Please, oh please, to anyone in charge who may be listening, don't let
> maven go the way of the RPM. 

Have no fear :-)

> It's too good of a product on its own to
> lose its technology in an uninstallable mess.
> 
> Thanks for listening. :)

-- 
jvz.

Jason van Zyl
jason@maven.org
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: new idea on maven usage?

[John Casey <jd...@commonjava.org>]

Just my 2-cents, but...

I can definitely say that if maven went to an OS-specific repository
with packages (rpm, etc.) I'd stop using it so fast it would make your
head spin. 

The current state of packaging software on most projects today seems to
range from non-existent (Windows) to poor (RedHat, et al) with outliers
being the BSD's and Debians of the world.  The problem with BSD is that
they don't even port the JVM quickly enough to be considered relevant.
If we tried to program strictly for BSD, we'd all still be stuck on JDK
1.3. As for Debian, from what I've heard it's a nice system, but you
can't make sweeping, generalized statements about package managers when
this is nearly the only relevant example. In short, the result of my
experience with dependency management in most package management
software has been increased blood pressure and (I'm sure) a shortened
life span. Obviously, I'm no expert, but I believe I can take a fair
crack at representing the masses. ;)

Is maven the right thing to use for managing native code? Probably not,
at least by itself. 

Does it have an appreciable advantage for most users over 99% of the
dependency management field? OH, Hell yes. 

As for its deficiencies, I believe a tiny introduction of execution
hooks (as in, post-bootstrap, pre-*-execution) would definitely allow
plugin development to address them all.

Please, oh please, to anyone in charge who may be listening, don't let
maven go the way of the RPM. It's too good of a product on its own to
lose its technology in an uninstallable mess.

Thanks for listening. :)

-john


On Mon, 2004-02-02 at 11:19, Jason van Zyl wrote:
> 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.
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: new idea on maven usage?

[Jason van Zyl <jv...@maven.org>]

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
jason@maven.org
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: new idea on maven usage?

[Dalibor Topic <ro...@kaffe.org>]

Hi Jason,

thanks a lot for taking the time to reply so quickly.

Jason van Zyl wrote:
> On Sun, 2004-02-01 at 21:52, Dalibor Topic wrote:

>>In my experience (with getting different programs to run on free 
>>runtimes), things never work out of the box on all platforms, usually. 
>>For example, Maven has an ugly dependency on a sun.* class[1]. Thus 
>>Maven in CVS breaks on java runtimes that don't [2] implement sun.* 
>>classes. A lot of other java code makes unwarranted assumptions about 
>>its runtime [3]. Writing portable java code is probably as hard as 
>>writing portable C code.
> 
> 
> Well, there are certainly can be a few quirks but a comparison between
> free runtimes that are so far behind currently used specifications, or
> not even compliant, and JVMs that most people use isn't really relevant
> in most cases. The unwarranted assumptions you speak of are things that
> are present in non-compliant JVMs. 

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. ;) 
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.

While the free runtimes definitely lack a lot of features found in 
currently used JDKs, a lot of problems I encountered in getting 
applications to run on free runtimes was caused by that sort of sloppy 
programming style. So it can be argued, in my opinion, that getting 
those applications to run on free runtimes, actually results in useful 
bug fixes, and better applications.

> 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.

One of the very frequently reported bugs for a while last autumn for 
Xerces was a hardcoded reference to a sun.* class for character 
conversion. I took part in the discussion of resolving the bug after 
stumbling over it while I was making eXist run with kaffe. It took quite 
a few duplicate bug reports to show Xerces developers that something 
should be done about it, as various people seem to have been quite keen 
on running Xerces with alternative runtimes, but were bitten by this 
bug. Eventually, after a couple of months, it was fixed, afaik. In my 
opinion, Xerces has gained from free runtime users and developers' 
participation in the development process, just like these users and 
developers have gained a working Xerces again for their platforms.

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.

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.

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.

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!

>>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.

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.

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 ;)

A distributor finds a workaround to shut the security hole, by using 
stricter, but unfortunately much slower argument checking in the java 
part of the library. Should it go into Maven's repository anyway?

I'm afraid that the 'one distribution fits all' approach doesn't work up 
to the expectations. But of course, that's highly speculative, and I'd 
love to see a world of 'write once, run anywhere' java applications all 
woven together by maven or a native packaging application.

>>>I agree with you 100% that Java applications that are packaged up should
>>>surely be available in the form of packages that work on various
>>>systems. I mailed the JPackage group long, long ago and gave them a
>>>heads up on what was going on in Maven land and there was no interest.
>>
>>As far as I can tell, there is a lot of interest now between the various 
>>java application packaging projects in the Linux world for cooperation 
>>between each other. It took a while until free java runtimes like kaffe 
>>[4] caught up, and started to become suitable platforms to run current 
>>jakarta [5] (or other) applications [6] on.
> 
> 
> Ok, but I still don't see why Maven would benefit at all from trying to
> use an OS specific repository when we have a non-OS specific repository.

Because the code in the non-OS specific repository may not work on the 
OS due to 'unwarranted assumptions' I cited above, for example. To the 
contrary, the code in the OS specific repository is supposed to be 
tested and audited on the OS. A simple example would be fixing sloppy 
usage of ";" and "\" as separators where an OS distributor could patch 
those, and get the packages working fine, but the patches alone would 
not warrant a new release for the developers of the package, so Maven 
may be stuck with the old, not-working-everywhere version.

>>Then there is a lot more cooking than JPackage. Naoko and RHUG are 
>>RedHat's efforts to use gcj to create very fast native executables and 
>>libraries from java applications and libraries. 
> 
> 
> Costin Manolache here at Apache has played with things like Ant and
> Tomcat to produce binaries with GCJ and unless things have changed
> drastically in the recent past there really wasn't much of a difference
> in speed other than startup time. Not to say that these things aren't
> interesting but the JVMs people typically use are fast enoug.

 From what I can find on the latest benchmarks, gcj seems to come on top 
of Sun's JDK. But I'd assume that's still application specific.

See http://www.mail-archive.com/lucene-dev@jakarta.apache.org/msg04096.html

>>While it's obviosly quite clever to leave the production to the project 
>>;), I have some doubts about deployment. Platform specific constraints 
>>may exist, that a project is not aware of.
> 
> 
> Java developers don't want to care about Platform specific constraints,
> or non-compliant JVMs generally.

Then they'll produce sloppy code that runs by chance on an 
implementation that meets their assumptions, and break on others.

Let me give you a nice example of how sloppy programmers create broken 
code, that fails to work on certified, compliant JVMs: End-Of-Line 
markers. As everyone knows, different OSes use different End-Of-Line 
markers: Unix uses \n, Windows uses \r\n, MacOs(X) uses \r. When Apple 
started shipping java for MacOS, they made sure they got the real thing, 
from Sun, certified, compliant and all that.

They didn't expect to be bitten by sloppy programmers within Sun: some 
of the classes that need to do End-Of-Line parsing would 'read-ahead' 
one character when they encountered \r in order to check if the next 
character is a \n, and push the character back if it wasn't for later 
reading. That's all quite nice, and well, but when such a sloppy 
programmed class tried to read the \n over a socket from an apple 
computer happyly serving its newline (\r) and waiting for input, a 
program using that class would hang forever. That was an annoying, and 
apparently common bug, so that Apple released a TechNote to get Sun to 
fix it: http://developer.apple.com/technotes/tn/tn1157.html .

Java developers may not want to care about such things, but that only 
means they'll write bad code waiting to blow up on another compliant VM. 
Writing good, portable java code is not that different from writing 
good, portable C code: you have to know what's a safe assumption, and 
what's not. Just saying "I don't want to hear it" won't make the 
inherent bugs go away ;)

>>A small example: Debian is one of the huge Linux distributions. It has a 
>>lot of users and a vital developer community. Among other nice things, 
>>Debian has a Social Contract [7] and an associated set of software 
>>guidelines [8]. Those software guidelines make specific requirements on 
>>licensing of software that comes with debian. So some applications may 
>>need to be split into free and non-free parts in order to get into debian.
>>
>>Some Jakarta projects [9], for example, have dependencies on non-free 
>>software that make it quite hard to put them in the form in which they 
>>are released by their developers into debian. They need to be 
>>'sanitized' first.
> 
> 
> Again, these are things that you can suggest projects adhere to but
> these are not things you can force projects to do. 

You're right. Doing a bit of hacking on a free java runtime doesn't give 
me any more power to tell other people what to do with their spare time, 
than hacking on Maven would, i.e. zero Newton. ;) Free runtime 
developers and java software packagers can try to work out a (mutually 
beneficial) compromise/cooperation between projects, but there is no way 
they can pressure projects into 'compliance' with some scheme. If things 
don't work out, everyone takes a deep breath, and simply moves on to the 
next thing on their agenda.

>>This is just a small example of platform-specific adaptations being 
>>necessary. Putting the burden for them on the project is not very 
>>helpful in the short run, I think.
> 
> 
> Again, why are you trying to make Java developers think of platform
> specific issues. These are in fact the things that we want to avoid.

I doubt you can avoid them, or that avoiding them is a good thing to do, 
as I tried to show with my examples of nice failures in this mail.

<pathetic>
I could go on for a while, citing folklore tales of failures of Java 
developers that avoided thinking of platform specific issues. Instead, 
I'll let the Double-Checked locking idiom serve as a monument to that 
lack of thinking: 
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
</pathetic>

;)

Seriously, though, you assume that software written in Java is portable, 
while in my experience, it often enough is not. Sometimes the developers 
misinterpret the API specs, or don't bother reading them and just decide 
to cast Objects to what seems like the right class to cast to because 
it's the class Sun's JDK x.y.z happens to pull out of somewhere.

>>>Could you not leverage the repository to make your platform specific
>>>packages for those that wanted to use platform specific packagers? 
>>
>>Well, there is more to packaging than downloading the binaries ;)
>>
>>You should also want to be able to verify the integrity of the files, to 
>>rebuild the binaries if necessary, to uninstall no longer needed 
>>packages, to update packages, etc.
> 
> 
> Well, why do assume that we don't want the same thing? We in fact do,
> but we want something that is not specifically targeted at one
> particular OS. Having use an OS specific repository might possibly be an
> option but I would never advocate it being the default. That's just not
> going to happen.

An option is good enough, I guess. If necessary, it can still be made 
the default on maven packaged for that OS ;)

I'm glad to see that we want to achieve similar goals, and I hope we can 
learn from each other's efforts.

>>Maven is a useful build tool. It's also a very nice site-generation 
>>system, and probably a few more things that I haven't caught up reading 
>>about yet. OTOH, it's not a replacement for a package management system 
>>like rpm, urpmi, or dpkg, as far as I can tell.
> 
> 
> That's not something we ever tried to solve. And I'm willing to bet it's
> something the vast majority of Java developers don't think about because
> they don't use Java packages bundled up in RPMs or the like.

Which is somewhat sad, as using package management can solve quite a few 
problems with respect to versioning, etc. But you know that already ;)

>>I think there is some room for cooperation (and interesting dialogue) 
>>between the various java packaging projects and Maven developers. They 
>>all try to solve the 'satisfying dependencies' problem, for example.
> 
> 
> Yes, but we are trying to do it in non-platform specific way.

Sure. Nevertheless, you too may have to face platform specific aspects, 
eventually, like slight incompatibilities between Sun's compliant JDK 
implementations, or different file layouts in compliant JDKs, etc. 
Others have started out like that, and got there before ;)

>>Well, one of the things we both can agree upon very easily is that 
>>checking in artifacts into CVS is a bad idea. That's like checking in 
>>object files.
> 
> 
> Yes, but that was generally the practice before Maven came along. No
> large segment of the Java developer population was using native Java
> packages are probably still aren't and probably won't in future I would
> wager.

You have a high probability of being right ;)

But if native packaging efforts suceed in solving the problems they are 
working on, I'd bet on developers of Unix-ish systems using native 
package management rather than a non-intergrated solution. Which would 
turn Maven into another Windows-nieche solution, along with executable 
installers and so on. But it surely is a comfortable nieche ;)

> What benefit is there to general, non-platform specific development in
> using OS specific repositories of Java packages?
> 
> We are obviously coming from different ends of the spectrum but I'm not
> convinced there is any benefit at all. If Maven had to deal with Linux
> type packaging systems, which are numerous, and ports like systems on
> BSD and then Windows and whatever else that would nullify the essential
> benefit of Maven which is to make cross-platform development easier.

Basically, you let the people who understand the peculiar aspects of 
their platform look at the code, and fix it *if necessary*, instead of 
relying on a bunch of guys who may have never heard of the platform to 
fix their java code to run on it ;)

Note the 'if necessary' bit! In an ideal world it would never be 
necessary, but (as I've tried to show in this mail), the world is not 
always very close to the ideal. In those cases, I don't believe that the 
centralized approach can work very well.

Oh, and thank you very much for providing very interesting food for 
thought. I hope you enjoy this discussion as much as I do.

cheers,
dalibor topic


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: new idea on maven usage?

[Jason van Zyl <jv...@maven.org>]

On Sun, 2004-02-01 at 21:52, Dalibor Topic wrote:
> Hi Jason,
> 
> Jason van Zyl wrote:
> 
> > There may one day be a bridge to adapt Maven's repository to native
> > systems for things like distributions but when a project creates a Maven
> > POM they expect it to work for people developing on all platforms. They
> > aren't concerned about platform specifics and this has never really been
> > the concern of Maven insofar as development goes.
> 
> In my experience (with getting different programs to run on free 
> runtimes), things never work out of the box on all platforms, usually. 
> For example, Maven has an ugly dependency on a sun.* class[1]. Thus 
> Maven in CVS breaks on java runtimes that don't [2] implement sun.* 
> classes. A lot of other java code makes unwarranted assumptions about 
> its runtime [3]. Writing portable java code is probably as hard as 
> writing portable C code.

Well, there are certainly can be a few quirks but a comparison between
free runtimes that are so far behind currently used specifications, or
not even compliant, and JVMs that most people use isn't really relevant
in most cases. The unwarranted assumptions you speak of are things that
are present in non-compliant JVMs. 

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.

> > 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.

> As far as I understand the concept, Maven uses JARs and provides a 
> method for downloading them from a central repository. For systems 
> putting a high priority on security, downloading binaries may not be 
> good enough. 

Fair enough, though the policy that we will be instituting will
incorporate a level of security with binaries that most people will be
comfortable with.

> 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?

> > I agree with you 100% that Java applications that are packaged up should
> > surely be available in the form of packages that work on various
> > systems. I mailed the JPackage group long, long ago and gave them a
> > heads up on what was going on in Maven land and there was no interest.
> 
> As far as I can tell, there is a lot of interest now between the various 
> java application packaging projects in the Linux world for cooperation 
> between each other. It took a while until free java runtimes like kaffe 
> [4] caught up, and started to become suitable platforms to run current 
> jakarta [5] (or other) applications [6] on.

Ok, but I still don't see why Maven would benefit at all from trying to
use an OS specific repository when we have a non-OS specific repository.

> Then there is a lot more cooking than JPackage. Naoko and RHUG are 
> RedHat's efforts to use gcj to create very fast native executables and 
> libraries from java applications and libraries. 

Costin Manolache here at Apache has played with things like Ant and
Tomcat to produce binaries with GCJ and unless things have changed
drastically in the recent past there really wasn't much of a difference
in speed other than startup time. Not to say that these things aren't
interesting but the JVMs people typically use are fast enoug.

> Then there is Gentoo 
> Linux, that takes the ability to rebuild from source to the max. And so on.

Building from source is not a problem, all the information you need is
present in the POM.

> I assume that long, long ago people weren't as aware of Maven, as they 
> are now. Maven is getting close to 1.0, after all, and has received some 
> well-deserved attention lately ;)
> 
> > The whole power behind Maven is leaving things up to the project
> > offering their work. Leaving the production and deployment up to the
> > project. 
> 
> While it's obviosly quite clever to leave the production to the project 
> ;), I have some doubts about deployment. Platform specific constraints 
> may exist, that a project is not aware of.

Java developers don't want to care about Platform specific constraints,
or non-compliant JVMs generally.

> A small example: Debian is one of the huge Linux distributions. It has a 
> lot of users and a vital developer community. Among other nice things, 
> Debian has a Social Contract [7] and an associated set of software 
> guidelines [8]. Those software guidelines make specific requirements on 
> licensing of software that comes with debian. So some applications may 
> need to be split into free and non-free parts in order to get into debian.
> 
> Some Jakarta projects [9], for example, have dependencies on non-free 
> software that make it quite hard to put them in the form in which they 
> are released by their developers into debian. They need to be 
> 'sanitized' first.

Again, these are things that you can suggest projects adhere to but
these are not things you can force projects to do. 

> This is just a small example of platform-specific adaptations being 
> necessary. Putting the burden for them on the project is not very 
> helpful in the short run, I think.

Again, why are you trying to make Java developers think of platform
specific issues. These are in fact the things that we want to avoid.

> > Could you not leverage the repository to make your platform specific
> > packages for those that wanted to use platform specific packagers? 
> 
> Well, there is more to packaging than downloading the binaries ;)
> 
> You should also want to be able to verify the integrity of the files, to 
> rebuild the binaries if necessary, to uninstall no longer needed 
> packages, to update packages, etc.

Well, why do assume that we don't want the same thing? We in fact do,
but we want something that is not specifically targeted at one
particular OS. Having use an OS specific repository might possibly be an
option but I would never advocate it being the default. That's just not
going to happen.

> Maven is a useful build tool. It's also a very nice site-generation 
> system, and probably a few more things that I haven't caught up reading 
> about yet. OTOH, it's not a replacement for a package management system 
> like rpm, urpmi, or dpkg, as far as I can tell.

That's not something we ever tried to solve. And I'm willing to bet it's
something the vast majority of Java developers don't think about because
they don't use Java packages bundled up in RPMs or the like.

> I think there is some room for cooperation (and interesting dialogue) 
> between the various java packaging projects and Maven developers. They 
> all try to solve the 'satisfying dependencies' problem, for example.

Yes, but we are trying to do it in non-platform specific way.

> > I only use Linux and I honestly never use JPackage packages. As I
> > mentioned above I doubt many people do simply because Ant doesn't have a
> > repository concept, people usually checked artifacts into CVS.
> 
> Well, one of the things we both can agree upon very easily is that 
> checking in artifacts into CVS is a bad idea. That's like checking in 
> object files.

Yes, but that was generally the practice before Maven came along. No
large segment of the Java developer population was using native Java
packages are probably still aren't and probably won't in future I would
wager.

> Maven is changing that, finally. That's a good thing, and I applaud the 
> Maven developers for that. Though, in my opinion, it could be an even 
> better thing if we could get Maven to leverage the existing package 
> management systems instead of just being a better "Napster for JAR 
> files" ;))

What benefit is there to general, non-platform specific development in
using OS specific repositories of Java packages?

We are obviously coming from different ends of the spectrum but I'm not
convinced there is any benefit at all. If Maven had to deal with Linux
type packaging systems, which are numerous, and ports like systems on
BSD and then Windows and whatever else that would nullify the essential
benefit of Maven which is to make cross-platform development easier.

-- 
jvz.

Jason van Zyl
jason@maven.org
http://maven.apache.org

First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints, 
as nature directs, not breaking any limb in half as a bad carver might.

  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: new idea on maven usage?

[Dalibor Topic <ro...@kaffe.org>]

Hi Jason,

Jason van Zyl wrote:

> There may one day be a bridge to adapt Maven's repository to native
> systems for things like distributions but when a project creates a Maven
> POM they expect it to work for people developing on all platforms. They
> aren't concerned about platform specifics and this has never really been
> the concern of Maven insofar as development goes.

In my experience (with getting different programs to run on free 
runtimes), things never work out of the box on all platforms, usually. 
For example, Maven has an ugly dependency on a sun.* class[1]. Thus 
Maven in CVS breaks on java runtimes that don't [2] implement sun.* 
classes. A lot of other java code makes unwarranted assumptions about 
its runtime [3]. Writing portable java code is probably as hard as 
writing portable C code.

> 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.

As far as I understand the concept, Maven uses JARs and provides a 
method for downloading them from a central repository. For systems 
putting a high priority on security, downloading binaries may not be 
good enough. 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.

> I agree with you 100% that Java applications that are packaged up should
> surely be available in the form of packages that work on various
> systems. I mailed the JPackage group long, long ago and gave them a
> heads up on what was going on in Maven land and there was no interest.

As far as I can tell, there is a lot of interest now between the various 
java application packaging projects in the Linux world for cooperation 
between each other. It took a while until free java runtimes like kaffe 
[4] caught up, and started to become suitable platforms to run current 
jakarta [5] (or other) applications [6] on.

Then there is a lot more cooking than JPackage. Naoko and RHUG are 
RedHat's efforts to use gcj to create very fast native executables and 
libraries from java applications and libraries. Then there is Gentoo 
Linux, that takes the ability to rebuild from source to the max. And so on.

I assume that long, long ago people weren't as aware of Maven, as they 
are now. Maven is getting close to 1.0, after all, and has received some 
well-deserved attention lately ;)

> The whole power behind Maven is leaving things up to the project
> offering their work. Leaving the production and deployment up to the
> project. 

While it's obviosly quite clever to leave the production to the project 
;), I have some doubts about deployment. Platform specific constraints 
may exist, that a project is not aware of.

A small example: Debian is one of the huge Linux distributions. It has a 
lot of users and a vital developer community. Among other nice things, 
Debian has a Social Contract [7] and an associated set of software 
guidelines [8]. Those software guidelines make specific requirements on 
licensing of software that comes with debian. So some applications may 
need to be split into free and non-free parts in order to get into debian.

Some Jakarta projects [9], for example, have dependencies on non-free 
software that make it quite hard to put them in the form in which they 
are released by their developers into debian. They need to be 
'sanitized' first.

This is just a small example of platform-specific adaptations being 
necessary. Putting the burden for them on the project is not very 
helpful in the short run, I think.

> Could you not leverage the repository to make your platform specific
> packages for those that wanted to use platform specific packagers? 

Well, there is more to packaging than downloading the binaries ;)

You should also want to be able to verify the integrity of the files, to 
rebuild the binaries if necessary, to uninstall no longer needed 
packages, to update packages, etc.

Maven is a useful build tool. It's also a very nice site-generation 
system, and probably a few more things that I haven't caught up reading 
about yet. OTOH, it's not a replacement for a package management system 
like rpm, urpmi, or dpkg, as far as I can tell.

I think there is some room for cooperation (and interesting dialogue) 
between the various java packaging projects and Maven developers. They 
all try to solve the 'satisfying dependencies' problem, for example.

> I only use Linux and I honestly never use JPackage packages. As I
> mentioned above I doubt many people do simply because Ant doesn't have a
> repository concept, people usually checked artifacts into CVS.

Well, one of the things we both can agree upon very easily is that 
checking in artifacts into CVS is a bad idea. That's like checking in 
object files.

Maven is changing that, finally. That's a good thing, and I applaud the 
Maven developers for that. Though, in my opinion, it could be an even 
better thing if we could get Maven to leverage the existing package 
management systems instead of just being a better "Napster for JAR 
files" ;))

cheers,
dalibor topic


[1] That I submitted a patch for to JIRA, btw, so if someone could 
review and check it in, I'd be very pleased ;)
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-1129
[2] and can't, since they are undocumented
[3] I'm currently involved with cleaning up OpenOffice. No, you don't 
want to know ... ;)
[4] http://www.kaffe.org
[5] http://www.kaffe.org/~robilad/tomcat-4.1.29-screenshot.png
[6] http://www.kaffe.org/~robilad/jboss-3.2.2-screenshot.png
[7] http://www.debian.org/social_contract
[8] http://www.debian.org/social_contract#guidelines
[9] Hello, FOP! ;) But I now have got Batik and FOP developers to talk 
together about cooperating on some ImageIO functionality, which would 
remove a major blocker (JIMI).


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: new idea on maven usage?

[Jason van Zyl <jv...@maven.org>]

On Sun, 2004-02-01 at 18:59, Dalibor Topic wrote:
> Hi Christian,
> 
> Christian Andersson wrote:
> > well that is one possibility, but that system (building an installation
> > set which have everything) does not take advantage of the fact that I
> > might already have some "libraries" (jar files) installed/downloaded
> >
> > This is where maven comes in, since if I start te application from
> > maven, maven will look in the "local" repository first for the files, if
> > they are not there it will download them, so If a person already has
> > some jar files (ofr the correct version) he does not have to download
> > them and therfore saving perheps precious network bandwidth and time.
> 
> Maven doesn't know about native package management on a platform, afaik. 
> I may have already installed ant, tomcat etc. on my debian system using 
> the debian package manager, for example. But as far as I understand the 
> maven concept, it will still go off fetching ant's jars from the 
> Internet, without caring about the operating system's package 
> management, or its dependencies, and so on.

This has always been the case with Java development as the currently
reigning defacto standard is Ant which has no concept of a repository at
all.

There may one day be a bridge to adapt Maven's repository to native
systems for things like distributions but when a project creates a Maven
POM they expect it to work for people developing on all platforms. They
aren't concerned about platform specifics and this has never really been
the concern of Maven insofar as development goes.

If I understand you correctly, are you saying that for development
purposes Maven should be leveraging platform specific repositories?

I agree with you 100% that Java applications that are packaged up should
surely be available in the form of packages that work on various
systems. I mailed the JPackage group long, long ago and gave them a
heads up on what was going on in Maven land and there was no interest.

The whole power behind Maven is leaving things up to the project
offering their work. Leaving the production and deployment up to the
project. 

Could you not leverage the repository to make your platform specific
packages for those that wanted to use platform specific packagers? 

I only use Linux and I honestly never use JPackage packages. As I
mentioned above I doubt many people do simply because Ant doesn't have a
repository concept, people usually checked artifacts into CVS.

-- 
jvz.

Jason van Zyl
jason@maven.org
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: new idea on maven usage?

[Dalibor Topic <ro...@kaffe.org>]

Hi Christian,

Christian Andersson wrote:
> Hi Dalibor
> I'm sorry for not commenting inline but at the top, but my answers 
> intersect so much that commenting inline would just not look good :-)

That's fine with me. I'm interested in having a good technical 
discussion and learning more about Maven and less in the proper quoting 
style ;)

> Well, it is true that it does not use any OS specific (or distribution 
> specific) package management, but that is what I like, and also what I'm 
> after, I personally do not want to build and debian .deb package, or an 
> Redhat RPM package, or even an madrake rpm package (even though i use 
> mandrake) that would restrict my software to much, since after all I 
> want it to be used on any platform that has java (although, I do need 
> java >= 1.3)

I fully understand that. As a software developer, I don't want to care 
either about the specifics of some platform's software management. The 
good thing is, I don't have to. The packaging work is usually done by 
the people developing those platforms (Cooker for Mandrake), who can try 
out my code on their specific environments, and often report back with 
bugs, suggestions and patches.

For example, on kaffe.org, we only distribute the latest versions of 
kaffe as source code, and leave the packaging work and creation of 
binaries to the distributors. We know best about our code, they know 
best about their platforms. They can actually test my code on those 
platforms, where I often lack access to their platforms. Or when was the 
last time you fixed your software on a Cray? ;)

> and personally I have had a hard time finding java packages that use 
> debian/redhat/mandrake/etc/etc package formats..  most of the time I 
> need to download the jarfiles myself.

Which is what the JPackage, Debian, Gentoo and RedHat java developers & 
packagers want to change, thus our common java packaging effort was 
born, to learn from each other's mistakes and come up with something better.

> I know that Jpackage.org exist and it tries to make those distribution 
> specific packages for us, but they can't make it for all platforms (for 
> example, I do not think they produce installers for windows)
> And I have had other problems with the Jpackage distribution.

Obviously they can't make packages for all platforms, like windows. But 
they are not even trying, or pretending their packages would run 
unmodified on windows.

They are trying to make the best effort for their targetted 
environments, which is Linux distributions using RPM based package 
management. Instead of a 'one-size-fits-all' they make the best effort 
to test, fix and package java applications for their supported 
environments. See 
http://www.rpmfind.net//linux/RPM/mandrake/9.2/contrib/jpackage/SRPMS/ant-1.5.4-2jpp.src.html 
for an example. Since the ant build, for example, builds some parts of 
ant depending on what JDK version it is built on, assuming that one 
ant.jar fits all is simply wrong.

Note also the interesting entry here:
* Mon Mar 10 2003 Henri Gomez <hg...@users.sourceforge.net> 1.5.2-3jp
   - rebuilt with IBM SDK 1.3.1 since there was zip corruption when built
     with jikes 1.18 and IBM SDK 1.4.

Any idea with which JDK and which compiler this 
http://www.ibiblio.org/maven/ant/jars/ant-1.5.2.jar was built? If any 
patches were applied? If it suffers from one of the problems fixed by 
JPackage project?

Don't get me wrong, Maven's centralized repository of common parts is 
very useful in development of java software. But it's of rather limited 
use  for distribution of software, since it would be based on the 
assumption that a central repository fits all.

> You also assume that the packages comes with the distribution, what if 
> they dont? what if they only comes from some other organization, one 
> that for example is not open source, but provides free binaries, what 
> about them? should not they be able to provide it with ease to all java 
> plattforms?

If they don't there is usually a very good reason why they don't, i.e. 
licensing terms. Neither does Maven provide these binaries, try 
downloading JIMI uisng Maven for example. It will tell you to go 
download it from Sun. So much for ease. ;)

Free (as in beer) binaries sometimes come under licensing terms that 
limit their distribution, so they can not legally be distributed to 
third partys without infringing on the rights of the copyright holders.

There are ways around that, JPackage has nosrc packages, debian has 
'installer' packages, etc. All these ways necessarily do the same as 
Maven does in the case where the artifact doesn't exist in the 
respository: they tell you to go somewhere else.

> I came "up" with this idea when reading about zero-install [1], 
> unfourtunally I do not think that zero-conf would work so good with 
> java-applications, however maven does alsmost the same thing as 
> zero-install.

Judging by the zero-install website, their security concept is somewhat 
better, than your proposal ;) But as I'm not familiar with 
zero-install's limitations, I can't comment on how well it would work 
for java applications. In my opinion, though, zero-install tries to 
solve a harder problem wrt software distribution and management, since 
it explicitely wants to handle native code (among other types), whereas, 
if I understand Jason correctly, Maven would be focused on java 
artifacts alone.

> And why should not distributions not use java?  they can you know, and 
> if they do, they will also benifit.

I don't think I ever said distributions should not use Java in this 
thread. I'm actually involved with bringing more Java applications into 
Debian Linux ;)

> If it happens that the project.xml file has dependencies that was NOT 
> installed from the distribution installer (which can happen)  it will 
> gladly download it from the web (which can be the dependencies real 
> webserver, OR the distributions webserver)

See, that's the kind of integration that I'm thinking about. If Maven is 
to be used to distribute and manage software (on Linux), it needs to 
interface with native package management software to see what's already 
there, and request an installation if necessary (where you propose 
straight downloading). We're not that far apart, as you can see.

> This way we get a good package management for java applications that 
> works the same on ALL plattforms, we can even use the exact same package 
> management to build the sources,and I see not problem with that.

That would be a nice thing, for sure. But I'm frankly more interested in 
having good package management on one platform, since I'd consider that 
enough of a challenge already, and doubt that it would work the same on 
all platforms, since a centralized repository could be overwhealmed by 
the work necessary to manage artifacts for all platforms.

Now some people have said 'use a standard JDK', or 'use a standard 
platform', which pretty much proves my point. If it's too much work to 
support all possible platforms, the central Maven repository could only 
support a few, selected platforms. That's O.K., everyone does it, and 
it's all very reasonable.

All I'm trying to do is to get you to realize the limitation of the 
approach you propose: it can not possibly work (untested) on all platforms.

Now if you want tested and tried software, that's part of what 
distributors do.

> AND since the dependencies are calculated and SOLVED when the 
> application starts, there is no problem at all deleting the entire 
> repository to free up space (not so much used java-applications will 
> therefore take no place)  the maven repository can bee seen as the 
> "cache" that exist in zero-install.  as long as the jar-files exist on 
> the internet, you still can run the application even after you delete 
> all the required jar files...

That assumes that resolving dependencies is all there is to software 
distribution ;)

A lot of the hard work involved is in actually testing what you've got 
extensively and fixing the problems you find on the environments you 
support. Quite often, this additional level of quality assurance 
produces better results in those environments, than the original 
software/artifacts produced by the developers, and everyone profits.

> personally I think it is better to resolve the dependencies when running 
> the application then at install time...
> 
> I see no problem in having the distribution to use the maven system for 
> the jar files, only benefits...

Well, the major problem I can see is that it wouldn't integrate at all 
with native package management, so it becomes impossible to manage java 
software using Maven with the native package management tools. That sort 
of setup starts to get really messy when you have 
multiple-programming-language software (eclipse, java-gnome), which 
would on one hand depend on Maven for the java side of things, and on 
the other on native package management software for the native side of 
things (SWT, libgtk). If Maven and native package management don't 
integrate, chances are that you'll end up with a hosed combination that 
doesn't run eventually.

BTW, thanks a lot for keeping the discussion focused on the technical 
aspects.

cheers,
dalibor topic


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: new idea on maven usage?

[Christian Andersson <ca...@ofs.no>]

Hi Dalibor
I'm sorry for not commenting inline but at the top, but my answers 
intersect so much that commenting inline would just not look good :-)

Well, it is true that it does not use any OS specific (or distribution 
specific) package management, but that is what I like, and also what I'm 
after, I personally do not want to build and debian .deb package, or an 
Redhat RPM package, or even an madrake rpm package (even though i use 
mandrake) that would restrict my software to much, since after all I 
want it to be used on any platform that has java (although, I do need 
java >= 1.3)

and personally I have had a hard time finding java packages that use 
debian/redhat/mandrake/etc/etc package formats..  most of the time I 
need to download the jarfiles myself.

I know that Jpackage.org exist and it tries to make those distribution 
specific packages for us, but they can't make it for all platforms (for 
example, I do not think they produce installers for windows)
And I have had other problems with the Jpackage distribution.

You also assume that the packages comes with the distribution, what if 
they dont? what if they only comes from some other organization, one 
that for example is not open source, but provides free binaries, what 
about them? should not they be able to provide it with ease to all java 
plattforms?

I came "up" with this idea when reading about zero-install [1], 
unfourtunally I do not think that zero-conf would work so good with 
java-applications, however maven does alsmost the same thing as 
zero-install.

And why should not distributions not use java?  they can you know, and 
if they do, they will also benifit.

lets say that you have distribution XYZ, you want to install application 
ZYX that comes with the distribution (from the cd) application ZYX is a 
"mavenized" application therefore if maven was not installed maven will 
be installed at the same time.  the installation of the package ZYX will 
then populate the maven repository with the jar files that the package 
need (for this example it depends on no other packages then it's own) it 
will also save down the project.xml file (this one could actually also 
be used to build the package if you have the ZYX-sources installed) and 
finally it will install an startup-script that will run "maven-run 
start" for that particulary project.xml file...

If it happens that the project.xml file has dependencies that was NOT 
installed from the distribution installer (which can happen)  it will 
gladly download it from the web (which can be the dependencies real 
webserver, OR the distributions webserver)

This way we get a good package management for java applications that 
works the same on ALL plattforms, we can even use the exact same package 
management to build the sources,and I see not problem with that.

AND since the dependencies are calculated and SOLVED when the 
application starts, there is no problem at all deleting the entire 
repository to free up space (not so much used java-applications will 
therefore take no place)  the maven repository can bee seen as the 
"cache" that exist in zero-install.  as long as the jar-files exist on 
the internet, you still can run the application even after you delete 
all the required jar files...

personally I think it is better to resolve the dependencies when running 
the application then at install time...

I see no problem in having the distribution to use the maven system for 
the jar files, only benefits...


[1] http://zero-install.sourceforge.net/
/Christian


Dalibor Topic wrote:
> Hi Christian,
> 
> Christian Andersson wrote:
> 
>> well that is one possibility, but that system (building an installation
>> set which have everything) does not take advantage of the fact that I
>> might already have some "libraries" (jar files) installed/downloaded
>>
>> This is where maven comes in, since if I start te application from
>> maven, maven will look in the "local" repository first for the files, if
>> they are not there it will download them, so If a person already has
>> some jar files (ofr the correct version) he does not have to download
>> them and therfore saving perheps precious network bandwidth and time.
> 
> 
> Maven doesn't know about native package management on a platform, afaik. 
> I may have already installed ant, tomcat etc. on my debian system using 
> the debian package manager, for example. But as far as I understand the 
> maven concept, it will still go off fetching ant's jars from the 
> Internet, without caring about the operating system's package 
> management, or its dependencies, and so on.
> 
> Using Maven as a way to circumvent package management on an OS is, to 
> put it simply, a waste of my resources. Of course, for operating systems 
> that have no package management (like Microsoft's products), using Maven 
> to download the dependencies is a way to work around the deficits of the 
> operating system.
> 
> It's still an ugly hack. On systems that do have sane package 
> management, like most Linux distributions, it's a Bad Thing(TM), and 
> leads to hard-to-manage software.

> Let's say, for example, that there is a security bug in some jar file 
> Buggy.jar, that is also distributed with Maven, that only is triggered 
> on a hypothetical MLinux distribution. The distribution's packagers of 
> Buggy.package can fix the problem, update the jar package for their 
> distribution, and have all the applications depending on that jar tested 
> and automatically fixed by upgrading the single package. Maven can not, 
> if the problem and fix is distribution (or operating system) specific. 
> Furthermore, there is no way for Maven to update all project.xml files 
> that use the Buggy.jar, so all the applications relying on Maven for 
> distribution of their jars are vulnerable until their developers release 
> a new package, if they do it at all. On the other hand, packagers of a 
> distribution can do that work.
> 
> The Maven does not, and can not really do the package and operating 
> system specific work of all the packagers on those systems.
> 
>> lets say that I make applications for persons to use, and I use some
>> gui-objects provided from some other company. with maven (provided that
>> the other company has their jar-files versioned and on the web)  I don't
>> have to distribute their jar-file with my application since maven
>> downloads it, I have to do that with an installer or if I use jnlp.
>>
>> The installer version can do some "optimisations based on the
>> plattform,, but IF I use that, I have to make several installers  based
>> on which plattforms I let my application run on, but wirh java, I want
>> them to be run on any plattform.
> 
> 
> That sounds quite nice in theory. In practice, there are differences 
> between platforms that matter, and need to be considered, like typical 
> locations of libraries, where native libs go, how dependencies are 
> resolved, etc. Using Maven to distribute applications is conceptually no 
> different than just statically linking everything in a big binary blob. 
> The only difference in practice is that you have to distribute the big 
> binary blob written in C yourself, whereas if it's written in java Maven 
> would do the fetching and linking of binary blobs for you.
> 
> Big binary blobs are so 80s ;) They don't work that well with modern 
> systems.
> 
>> I can also use the maven approach for starting the application from the
>> init.d  (if I use an unix type of plattform) or from a cron job. that
>> will be hard with webstart/jnlp (but possible with an installer)
> 
> 
> I'd assume that different linux distributions have already found ways to 
> deal with running tomcat, for example, from their startup scripts. The 
> maven approach would seem to circumvent that.
> 
>> also with maven I can do some nifty update handling (similiar to
>> webstart but more functional according to me) since all I have to do is
>> to download the new project-xml file, stopp the application (maven stop)
>> and then start it again (maven start) and it wpuld update ge
>> application. webstart will update every time it starts the application
>> since it checks the jnlp file, but an application that automaticly
>> updates itself are usually discourraged by administrators (who knows
>> what will be installed and when, I like to be able to controll when
>> things gets updated).this is ofcourse also possible with an installer,
>> but now it would be my application that would have to check for new
>> versions etc, I have to "manually" build it inot my application.
> 
> 
> In other words, all I have to do is to use some other tool to manage a 
> part of my system. The tool doesn't know about the specifics of my 
> system, the applications don't know either. That sounds like a recipe 
> for desaster in the long run.
> 
> Let's say I update my java runtime to a new version because of a 
> security problem that only occurs on my platform. I (and everyone else 
> using applications on that platform that use Maven for distribution) 
> have to manually check if all the applications still work. In a sane 
> distribution system, the packager can do that work, and if necessary 
> expose a conflict between an application and an specific runtime in the 
> list of dependencies of the application. In the proposed system, 
> everyone needs to do it all over.
> 
>> So I see many benefits to providing a "maven-execution" system that has
>> the basic maven reopsitory handling and a couple of goals
>> (start,stop,restart,check,....) and these benefits are mainly not
>> covered by an installer or webstart/jnlp)
> 
> 
> Both installers and webstart/jnlp are nieche solutions for distribution 
> that don't meet the needs of modern operating systems. Legacy systems, 
> like Microsoft Windows, that have no concept of package management, 
> *may* profit from a Maven-based distribution system, but it would still 
> be a nieche solution.
> 
> On the other hand, using Maven for distribution makes the job much 
> harder for those that package applications for und use applications on 
> modern operating systems.
> 
> See 
> http://java.debian.net/index.php/What%20is%20required%20from%20upstream 
> for a brief discourse on how to create packager-friendly releases of 
> java software that is supposed to be packaged for linux distributions. 
> It's part of a small wiki created by packagers of java applications for 
> different Linux systems and free java runtime developers in order to 
> find better ways to package java applications on unix systems[1].
> 
> cheers,
> dalibor topic
> 
> [1] http://java.debian.net/index.php/CommonJavaPackaging
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: new idea on maven usage?

[di...@multitask.com.au]

Karl Trygve Kalleberg <ka...@prosalg.no> wrote on 02/02/2004 08:52:29 PM:

> So in summary, Maven is unsuitable for Gentoo, because
> 1) It downloads packages on its own accord at build time, circumventing
>    our packaging system.

Did you look at using the jar override feature of Maven?

> 2) The packages in the Maven repository are missing sources (and
>    build.xml-files).

Some of them don't have a build.xml file to start with. Maven is not ant.

--
dIon Gillard, Multitask Consulting
Blog:      http://blogs.codehaus.org/people/dion/





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: new idea on maven usage?

[Karl Trygve Kalleberg <ka...@prosalg.no>]

As an addendum:

I've looked at how to best integrate Maven with the Gentoo Linux packaging
system, and come to the conclusion that at this point, it is easiest to
circumvent it completely. 

Our current prototype approach is patching the build.xml most maven-based
project supply to not fetch missing packages, and have the ebuild
(Gentoo-specific build script for a given package) manually symlink (or
otherwise resolve) the jar files for these external packages into the
appropriate lib/ dir before starting building. 

However, I must readily confess that I have not put the time into
investigating writing a different package-resolution plugin for Maven (if
that's possible).

At any rate, as the basic premise for Gentoo is to compile everything from
source code at installation, to enable/disable optional features and allow
installation-time patching by the user, we will never avail ourselves of
the pre-built maven repository (on ibiblio), since packages there do not
come with sources (which I find a bit strange; all other relevant
binary-distro systems I've seen, have source packages too). 

So in summary, Maven is unsuitable for Gentoo, because
1) It downloads packages on its own accord at build time, circumventing
   our packaging system.
2) The packages in the Maven repository are missing sources (and
   build.xml-files).

The good thing about maven-enabled projects is that it is easy to figure
out their external dependencies, which eases the job of packaging projects
tremendously. 



Kind regards,

Karl T


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org