Re: Managing versions of Apache Jakarta software
Ainsi parlait Andrus Adamchik : [..] > Task of a package creator is harder. (Here is a link with detailed > information : http://www.rpm.org/max-rpm/ ). In short (in reality it is > rather hard) package creators need to get sources, convert > "configure-make-make install" into a special RPM spec for a target > platform, build it into RPM. And also keep track of dependency developpers didn't explicitly provided, discard binary files and look for sources everywhere on the net, find a global coherency among hundreds of different practices, adapt to platform-specific standards, deal with license nightmare, cope with crazy archive formats, etc... Curiously in java world, packager work is generaly is at best misunderstood, often ignored, or even seen with some hostility from developpers. But the result is here: jpackage project covers today more than a hundred of different java projects. See http://jpackage.sourceforge.net for complete list. -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: License issue (the come back)
Ainsi parlait [EMAIL PROTECTED] : > On Thu, 14 Mar 2002, GOMEZ Henri wrote: > > >Ok, I didn't know that - and I bet many other people are in the same > > >situation. > > > > > >If anyone can confirm this with a professional, then I think it should > > >be displayed pretty clearly on a visible page, and we should find > > >alternative open standards to use. > > > > jpackage need this kind of information to determine what could be > > freely present in its rpm distribution and what should be dropped. > > Yes, and it's important to find out which packages are indeed based > on open standards and remove the others imediately. > > Not only because it's required by the licence, but because packaging > them might get people to use them, and that's bad. That what we initially attempted to do , provide only free software, but we had to quickly adopt a less strict policy in order to have something to package... > If a package is based on an open standard and a clean room > implementation exists and is comparable with the reference and > has better license - I think the choice should be clear too. Sure, but that choice depends of developpers, not of packagers... And the current question is: what to do when no alternative exists ? >From current discussion, it seems everyone agrees main problem comes from BCL itself, and not additional software-specific clauses. There are actually two problems: 1) the "bundled as part of your software" clause 2) the "US export laws compliance" clause My personal understanding of the BCL allows me to consider distributing javamail in its own package ad part of a whole distribution project comply with 1). And the technical issue of 2) make me thinks it is pointless anyway. Now if someone can demonstrate me i'm wrong in either of those points, i'd be happy to revert to our old practice of distributing spec files only, and let final users build their own packages themselves. -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: License issue (the come back)
Ainsi parlait Santiago Gala : [..] > FYI: Some time ago, I was forbidden to download a java package because > my ISP did not have reverse DNS address mapping properly setup, even > though I'm in Spain, not a "free world enemy", AFAIK. The message I got > was something like "we could not assess your origin country > satisfactorily, consult technical support". So, Sun is/was using > technical mappings between IP block ownership and country to enforce > such provisions. I don't know the current status. > > I had to ssh to a machine that was granted the permission, download from > there, and then put it in my machine from there. I was not breaking any > law, since I'm allowed to download it. > > In a sense, they do the following: if the machine used to download the > code is in an allowed country, it is not considered export, so they > allow it, and transfer the export responsibility further down the chain. (sorry for this late answer) I know they use such kind of filtering based on your domain name. It also means just using a private indirection, as you did, or public redirect service as anonymiser.com bypass it easily. So we can say that Sun attempts to fulfill this clause, but not that they actually comply to. We could also have a banner saying "if you're a evil guy (as defined by US state department), please do not click here" with the same efficiency. -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: License issue (the come back)
Ainsi parlait GOMEZ Henri : > >We have setup [EMAIL PROTECTED] for that reason (this is > >also commonly > >discussed on [EMAIL PROTECTED] and [EMAIL PROTECTED]) and > > both list are not available to basic commiters ? But the first one is: try [EMAIL PROTECTED] -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: License issue (the come back)
Ainsi parlait [EMAIL PROTECTED] : > > The BCL states that you cannot make a distribution of the .jar file > > outside of your product. In other words, if you want to distribute the > > single .jar file, you can't do that. > > > > "(i) distribute the Software complete and unmodified and only bundled as > > part of your Programs" Well, the very reason that we package this proprietary stuff is precisely that they are needed by other packages (otherwise we wouldn't provide them). So even if included in separate files, they are actually distributed as dependencies of other softwares. If "our program" is our complete set of packages, we could consider them as bundled inside. [..] > BTW, the clause 'complete and unmodified' is very interesting - does it > refers to the jar or the whole binary package ( most people refer to the > whole downloaded package as 'software', and the jar is a piece of it ). > If so, tomcat and most other packages that include it are breaking > the licences, since they repackage and include only the jar. > 'Software' is previously defined as 'accompanying software > and documentation and any error corrections provided by Sun (collectively > "Software") Right, and providing them in full packages with documentation, license and other original files, as we do, is more respectful in this regard. -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: License issue (the come back)
Ainsi parlait Jon Scott Stevens :
> on 3/12/02 7:05 AM, "Guillaume Rousse" <[EMAIL PROTECTED]> wrote:
> > So we did, and here is the result
>
> You didn't find licenses for a lot of software that has licenses...instead
> of saying 'no license' which implies that it does not have a license, you
> should have stated ('could not find a license')...
>
> I went through the java.sun.com website and in about 30 seconds found the
> licenses for the first 3 'no license' items below...you can do the rest of
> the work...
As stated in my original mail :
no license means "in current package" only
Real problem is not to have exhaustive list, but to discuss the correct
behaviour to adopt regarding a given license combination.
--
Guillaume Rousse <[EMAIL PROTECTED]>
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
License issue (the come back)
re complete and
unmodified; (ii) do not distribute additional software
intended to supersede any component(s) of the Software;
(iii) do not remove or alter any proprietary
legends or notices contained in or on the Software; and
(iv) only distribute the Software pursuant to a license
agreement that protects Sun's interests consistent with the
terms contained in this Agreement, and provides that Sun is
a third party beneficiary to such license agreement. If you
distribute the Software pursuant to this paragraph, you
must include the following statement as part of product
documentation (whether hard copy or electronic), as a
part of a copyright page or proprietary rights notice
page, in an "About" box or in any other form reasonably
designed to make the statement visible to users of the
Software: "This product includes code licensed from
RSA Data Security".
LDR
3. License to Distribute Redistributables. Subject to the terms and
conditions of this Agreement, including but not limited to Section 4 (Java
Technology Restrictions) of these Supplemental Terms, Sun grants you a
non-exclusive, non-transferable, limited license to reproduce and
distribute the binary form of those files specifically identified as
redistributable in the Software "README" file ("Redistributables") provided
that: (i) you distribute the Redistributables complete and unmodified
(unless otherwise specified in the applicable README file), and only
bundled as part of Programs, (ii) you do not distribute additional software
intended to supersede any component(s) of the Redistributables, (iii) you
do not remove or alter any proprietary legends or notices contained in or
on the Redistributables, (iv) you only distribute the Redistributables
pursuant to a license agreement that protects Sun's interests consistent
with the terms contained in the Agreement, and (v) you agree to defend and
indemnify Sun and its licensors from and against any damages, costs,
liabilities, settlement amounts and/or expenses (including attorneys' fees)
incurred in connection with any claim, lawsuit or action by any third party
that arises or results from the use or distribution of any and all Programs
and/or Software.
BCL export regulation clause
7. Export Regulations. All Software and technical data
delivered under this Agreement are subject to US export
control laws and may be subject to export or import
regulations in other countries. You agree to comply
strictly with all such laws and regulations and acknowledge
that you have the responsibility to obtain such licenses to
export, re-export, or import as may be required after
delivery to you.
--
Guillaume Rousse <[EMAIL PROTECTED]>
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: The Complete Server Platform?
Ainsi parlait GOMEZ Henri : > >> One small extra: if a RedHat style toolkit distribution were > > > >available, > >the > > > >> number of independent consultants who could offer their > > > >support services > > > >> would exceed the number available to BEA, for example, > > > >eliminating that > > > >> argument that 'I buy where I can depend on getting support'. > > > >Well, we can > > > >> dream, anyway. > > That's one of the goal of jpackage project, providing > a coherent set of java software packages for RPM enabled systems : > > http://www.jpackage.org And Mandrake is planning inclusion of several of these packages into next release, now that the biggest work (harmonisation and cross-dependencies computing) is done. -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: URGENT: 3rd Party jar's in apache CVS need immediate action.
Ainsi parlait Kimbro Staken : > On Thursday, January 31, 2002, at 08:46 AM, Guillaume Rousse wrote: > > I don't think this is really a *benefit* of Java software. Nothing > > prevent a > > native software to provide staticaly-linked binaries of make for every > > existing platforms in CVS. The fact that one only ant binary for Java > > software is enough doesn't make it an acceptable practice. > > This is absolutely a benefit of Java software. While it was technically > possible to do this for C projects it was practically infeasible. In Java > it is entirely feasible and works just fine in the majority of cases. Perl is also multi-platforms, and doesn't rely on blind code duplication everyhwere, AFAK. Instead, they use dependencies. > > Keeping track of dependencies is the task of a package management system, > > which only exist for Unix AFAK, while Java is multi-platform. But when > > this > > means 'propagating nasty platforms-specific constraints everywhere', i > > think > > we reach limits of cross-platform possibilities :-) > > The issue raised was not a technical one, it was legal. Trying to put in a > complex technical solution for it is overkill. The current mechanism works > just fine in almost all cases. It may not be ideal, but so what; It still > removes a lot more headaches then it creates. The current system is simple and functionnal, right, but it is ugly. And it is *really* a nightmare for people wanting to have a proper packaging policy, as Linux distribution for instance. > > Users relying on packaged software just have to use apt-get (for debian > > packages) or uprmi (for rpms packages) to have automated dependencies > > resolution, remote package fetching, and so on. > > What about the 99% of the world that uses a platform that isn't Linux? In open-source world this is usually *a bit* more. And there have been proposition recently of extending rpm use to any Unix. See http://www.openpkg.org > > Ensuring a consistent set of jars is not the task of developpers IHMO, > > but of > > packagers and distributers. Moreover, unless you are strictly > > self-dependant, > > So how is an Apache project not a packager and distributer? The > perspective that open source should only be concerned with the perspective > of the developer is not a good one. Apache project is only a distributer for apache project software. Java world is not limited to ASF :-) > Plus, developers are not the only people who pull the code from CVS. I > cringe at the thought of having to ensure that everybody who uses our CVS > tree also needs to manually update dependencies as the software evolves. Why manually ? You have ant task for this... > In the current mechanism the system always works. If the source changes > such that it depends on an updated jar a simple CVS update will bring not > only the source change but the updated jar as well. You always know that > the software is supposed to build out of the box and that if it doesn't > then someone is on the hook for breaking the build. To say that this isn't > a unique benefit of Java is simply not true. The current mechanism also force you sometimes to use out-dated software, just because developpers were not aware of compatibility breaks. It happened recently with ArgoUML, which could not work with xerces-j > 1.2., which was a nightmare to figure. This is clearly a developper task, not a user task. Projects as gump try to achieve the same result. > > If a dependency becomes unavailable, i think there is a reason behind > > (obsolescence, upgrade, security hole, etc). By short-circuiting the > > effect, > > you prevent normal evolution to takes place. > > Or it could simply be a network failure or server crash or maybe the > software moved or maybe the person who made it available changed their > mind and pulled it. Regardless of the reason you still have the dependency > and the software is now useless to the user trying to install it. > > > Jpackage project (http://package.org) try to provide such a consistent > > set of > > java software for rpm world. Debian java project > > Heh heh, as I write this, this site is down. :-) My fault, it's http://www.jpackage.org, or http://jpackage.sourceforge.net > > (http://people.debian.org/~tora/java/packagelist.html) provide the same > > service for debian world. Both try also to enforce nomal Unix conventions > > (FHS, etc...) and establish cross-project packaging policies. We all know > > this only adress a subset of java realm, so we don't ask for dropping > > other > > platforms support. We just ask to make it an optional additional layer, > > not > > make it m
Re: URGENT: 3rd Party jar's in apache CVS need immediate action.
Ainsi parlait Stefano Mazzocchi : [..] > Don't get me wrong, I'm not against this. But the above are words, I > need something that works and jars in CVS (with the license and > description of where they were from attached) work best for me. As a kind of shamefuly self-publicity, jpackage project used initially package-management-system independent xml software descriptors, that you could find in project CVS here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jpackage/xml-spec As we produced initially different rpms for different Linux distributions, we produced them from the same stem. This could easily have been extended to other packaging system, with something as [.. system independant software description .. ] [.. instruction for building rpm for this software .. ] [.. instruction for building deb for this software.. ] [ .. instruction for building an auto-installable archive.. ] -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: URGENT: 3rd Party jar's in apache CVS need immediate action.
Ainsi parlait Guillaume Rousse : [..] > Jpackage project (http://package.org) try to provide such a consistent set > of java software for rpm world. Debian java project > (http://people.debian.org/~tora/java/packagelist.html) provide the same > service for debian world. Both try also to enforce nomal Unix conventions > (FHS, etc...) and establish cross-project packaging policies. We all know > this only adress a subset of java realm, so we don't ask for dropping other > platforms support. We just ask to make it an optional additional layer, not > make it mandatory as it is currently... Something i forgot to say: all package provided at http://jpackage.sourceforge.net/packages.php are build by first deleting all jar present in the archive, and relying on other packages which are build from source also. Yes, it is a lot of work, but it is possible... -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: URGENT: 3rd Party jar's in apache CVS need immediate action.
Ainsi parlait Kimbro Staken : > On Tuesday, January 29, 2002, at 01:36 PM, Guillaume Rousse wrote: > > Don't import any jar back into the cvs, but fills a complete and exact > > dependency list -) > > > > Ok, not exactly what you're looking for, but at least it could open the > > debate. Outside of java world, i never saw any binary in CVS. Instead > > there > > are README files telling: you need libfoo-x.y.z and libbar-x.y.z to build > > this soft. > > And this is one of the great benefits of Java software. Having to track > down all the dependencies is a major PITA for the user of the software. A > lot of this stuff is hard enough to get going, why introduce more pain. > This just seems like the wrong solution for a problem that is primarily a > legal rather then technical issue. I don't think this is really a *benefit* of Java software. Nothing prevent a native software to provide staticaly-linked binaries of make for every existing platforms in CVS. The fact that one only ant binary for Java software is enough doesn't make it an acceptable practice. Keeping track of dependencies is the task of a package management system, which only exist for Unix AFAK, while Java is multi-platform. But when this means 'propagating nasty platforms-specific constraints everywhere', i think we reach limits of cross-platform possibilities :-) > > Putting dependencies in CVS is nasty because: > > - you make release tarballs biggers > > - you end up with lots of duplicated files on your box > > - you give headache to external people wanting to package the soft > > properly > > for computing exact dependencies (but what version of foobar is this > > foobar.jar exactly ?) > > - you can't follow external dependencies evolutions, as you use a static > > one > > Some arguments against it. > - You increase the pain for users significantly, it might be ok for > developers who are going to have lots of jars and know where they are, but > an end user won't want to deal with that. Java enables the problem to be > solved in a way that was very difficult to accomplish with C. Users relying on packaged software just have to use apt-get (for debian packages) or uprmi (for rpms packages) to have automated dependencies resolution, remote package fetching, and so on. > - Increased pain for users means decreased usage of the software. > - Since many developers start out as users, fewer users means fewer > developers. > - Not shipping a consistent set of jars increases the support headache > significantly. Ensuring a consistent set of jars is not the task of developpers IHMO, but of packagers and distributers. Moreover, unless you are strictly self-dependant, as some peoples propose it, this consistency will concern only other software part of the same project, unless you want to duplicate everything outside of ASF. > - You run the risk of a required dependency becoming unavailable which > makes the software unusable. If a dependency becomes unavailable, i think there is a reason behind (obsolescence, upgrade, security hole, etc). By short-circuiting the effect, you prevent normal evolution to takes place. Jpackage project (http://package.org) try to provide such a consistent set of java software for rpm world. Debian java project (http://people.debian.org/~tora/java/packagelist.html) provide the same service for debian world. Both try also to enforce nomal Unix conventions (FHS, etc...) and establish cross-project packaging policies. We all know this only adress a subset of java realm, so we don't ask for dropping other platforms support. We just ask to make it an optional additional layer, not make it mandatory as it is currently... -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: URGENT: 3rd Party jar's in apache CVS need immediate action.
Ainsi parlait Dirk-Willem van Gulik : [..] > The next step - fixing things can take more time: > > 2.Getting our code to work again. > > Option 1.1 > Each project put's their jar's back in - but > according to the guidelines below. > > Option 2.2 > We create a 'xml-third-party' repository for > all the third party jar's. Following the > guide lines below. > > So we keep all 3rd party and alien code in > one place. Option 2.3: Don't import any jar back into the cvs, but fills a complete and exact dependency list -) Ok, not exactly what you're looking for, but at least it could open the debate. Outside of java world, i never saw any binary in CVS. Instead there are README files telling: you need libfoo-x.y.z and libbar-x.y.z to build this soft. Putting dependencies in CVS is nasty because: - you make release tarballs biggers - you end up with lots of duplicated files on your box - you give headache to external people wanting to package the soft properly for computing exact dependencies (but what version of foobar is this foobar.jar exactly ?) - you can't follow external dependencies evolutions, as you use a static one So, why not profit of the big CVS clean-up to adopt more coherent practice ? -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: jakarta source code documentation
Ainsi parlait Walentiny Carlo : > Second: > > ... You are offering free use of your tool to open > > source > > > developers, but what about the rest of our > > community? > > > They get to use crippleware? > > Is netbeans crippleware, compared to forte? Your comparaison is not fair: NetBeans is free software, not just a free-of-charge demo of Forte. -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [xerces2] info about some packaging changes
Ainsi parlait Guillaume Rousse : > thus the need to include version in jar names, the same as libraries do in > real world (at least of unix world, of course). Oops ! I meant 'native' here :-( -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [xerces2] info about some packaging changes
Ainsi parlait [EMAIL PROTECTED] : > you Guillaume Rousse <[EMAIL PROTECTED]> wrote > > > If a 'full' xml api jar is provided, could we hope some consistent naming > > convention with the servlet api, which is currently provided into > > servlet.jar? > > > Something such as: > > xml.jar/servlet.jar > > xmlapi.jar/servletapi.jar > > xml-api.jar/servlet-api.jar > > Hmmm - I'm not quite sure what the connection is - who's servlet.jar are > you talking about - I'm presuming Sun's? Now that Tomcat is servlet specification reference implementation, it's more jakarta's jar than sun's jar. The connexion is: as they are both standard java extension api (javax hierarchy), having similar naming scheme would have been useful. > Also, we already hashed out the naming issue here on general@xml, and at > this point it's really a deliverable from the xml-commons project so they > should be the 'owners' of the apache version of this. I don't remember the > difference between xmlapis.jar and xml-apis.jar, but I do remember that we > specifically avoided xml.jar since there are a number of old files named > 'xml.jar' that have outdated DOM, etc. versions and it's too much of a > headache to use the same name. thus the need to include version in jar names, the same as libraries do in real world (at least of unix world, of course). -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [xerces2] info about some packaging changes
Ainsi parlait Davanum Srinivas : > Shane, Edwin, > > #1: I think xml-apis.jar should contain the same thing whether it is built > by Xalan project or Xerces Project. If a 'full' xml api jar is provided, could we hope some consistent naming convention with the servlet api, which is currently provided into servlet.jar ? Something such as: xml.jar/servlet.jar xmlapi.jar/servletapi.jar xml-api.jar/servlet-api.jar -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Is there any list of Java1 compliant apps available ?
Hello all. I saw most jakarta/xml projects are very attached to keeping java1 compatibility, but is there any list of which one actually are ? Also, does anyone also tested compatibility with free JVM, such as kaffee or japhar ? Having such compatibility ensurance would allow to include application directly into linux distributions having a strict open-source policy. -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Distributing the JSSE
Ainsi parlait Kasper Nielsen : > > > so this is an US export law issue and not a Sun License issue? > > > > I think so. It would be possible to distribute it but it would take a lot > > of > > > work to get all paper work done and I think there was other conditions > > (ie must be us citizen, must get the connections from embargoed countries > > blocked > > > etc) > > thats strange on http://java.sun.com/products/jsse/index-102.html they have > a link to > > Download JSSE 1.0.2 global software and documentation with support for > strong encryption. > > and a Download JSSE 1.0.2 domestic (US/Canada) software and documentation > with support for strong encryption > > Don't know what the difference is, but I would imagine its legal to > distribute something that is allready allowed to be globally distributed? Sofar no one answered this mail... Does US crytopgraphy export restrictions apply to both version of JSSE, or only to domestic version ? And do these restictions apply everywhere, or only for US-based download location ? Said otherwise, can jpackage project (jpackage.sourceforge.net) provide JSSE global version packages, as any other Sun java API packages, eventually only on non-US mirrors, or is it a special case ? -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: what is org.apache.log package ?
Ainsi parlait Eung-ju Park : > Hi. > See http://jakarta.apache.org/avalon/logkit/index.html Thanks ! -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
what is org.apache.log package ?
I already asked this on velocity dev mailing list, but no one seems to care. Maybe someone else here will know from where comes this strange org.apache.log package, found in velocity lib directory in a log.jar. -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standardizing build.xml files
Ainsi parlait Berin Loritsch :
[..]
> I propose we borrow a number of conventions from the GNU
> "make" utility manual
> (http://www.gnu.org/manual/make-3.79.1/html_chapter/make_14.html).
Some other GNU conventions (not specilay related to make) that would be very
useful concerns naming.
It makes you sure version x.y.z of foo program is contained in a
foo-x.y.z.tar.gz archive, that will expand in a foo-x.y.z top-level directory.
Currently jakarta and xml individual projects use a mixture of version number
vs cvs tag (x.y.z vs x_y_z), of project vs group-project name (foo vs
jakarta-foo), of complete name vs shortname (xerces vs xerces-j), and case
(Xerces-J vs xalan-j) that make final users and packagers crazy.
Why not just state all archives should be named after the following
conventions:
project-version-bin.tar.gz (or .zip) for binary releases
project-version-src.tar.gz (or .zip) for source releases
project-version.tar.gz (or .zip) for mixed source-binary releases
And all should expand in a project-version top-level dir ?
It also concerns jar naming. Some projects use a main project.jar archive,
some other a project-version.jar. Additional jars case is worst: some use a
something.jar (ant optional.jar), some use projectSomething.jar
(xercesSamples.jar), some use project-something.jar. All these names are
either hard-coded directly in jar task, or set a property. Again, this is a
mess.
I would suggest to always use property for specifying jar names, using the
following conventions:
main.jar=${name}-${version}
optional.jar=${name}-${optional}-${version}
sample.jar=${name}-${sample}-${version}
etc...
Of course, i fully agree with initial proposition :-)
--
Guillaume Rousse <[EMAIL PROTECTED]>
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
