From kwade at redhat.com Wed Sep 3 18:16:53 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Wed, 03 Sep 2008 11:16:53 -0700 Subject: news on JPackage Message-ID: <1220465813.7309.108.camel@calliope.phig.org> We've been hunting down answers on how to work across JPackage and Fedora. The news is mixed with a bright future. Your help now makes the bright future more obtainable. The reality is that while JPackage and Fedora packages are very alike and the packing rules are more closely aligned, there is no automagic to make it easier to maintain one package across both systems. By acting now within both communities, our up front work can help support a goal of minimizing or removing barriers between the two package repositories. Fedora requires everything it needs to build to be entirely in the build system. It cannot rely upon outside repositories. This is a fundamental design decision. That means that nearly the same package from JPackage must be rebuilt in the Fedora system. The goal is to find a way to make moving packages between the systems fully transparent. This cuts down significantly on package maintainers work while allowing JPackage to service the wider RPM audience. Jesse Keating, Fedora Release Engineer, is one person leading this effort. It sounds as if help is still needed within Fedora and JPackage to move this ahead. There are still decisions to be made on how to proceed, we may influence that by acting within both communities. In the meantime, the best process to follow is this: 1. Get Java libraries working in JPackage 2. Once there, import those packages in to Fedora - This will be much faster with most of the work already done from the JPackage review 3. Once forked, you need to update packages in both locations, syncing changes back/forth If we can make a custom of doing these practices, it helps make the infrastructure level changes easier to occur. Let me know your thoughts/questions on this, I'd like to codify this on the wiki as our policy for ISVs. - Karsten -- Karsten Wade, Sr. Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Tue Sep 9 00:10:41 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Mon, 08 Sep 2008 17:10:41 -0700 Subject: dependencies page Message-ID: <1220919041.31147.31.camel@calliope.phig.org> This page is a good example ... https://fedoraproject.org/wiki/Alfresco ... of what we are going to need for all of you. I'm planning to send out an email to the general developers list (fedora-devel-list), inviting packagers who are interested in ISV software to assist with the packaging efforts. They benefit from the dependency list. Getting out this list of dependencies is the first step[1] in getting software packaged. I encourage you to post whatever you have so far to the wiki so that others can read and assist.[2] If you need any assistance with the wiki, please contact me. Using the general format of https://fedoraproject.org/wiki/Vendor_Name is a good place to start gathering content. Let us know when you get something posted! Thanks - Karsten [1] https://fedoraproject.org/wiki/SIGs/ISV#What_next.3F [2] The work on the Alfresco page was a back-and-forth effort between subject matter experts of Alfresco, Fedora, and Java. There is expertise that can help when the details are visible to them. -- Karsten Wade, Sr. Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jhibbets at redhat.com Tue Sep 9 01:41:24 2008 From: jhibbets at redhat.com (Jason Hibbets) Date: Mon, 08 Sep 2008 21:41:24 -0400 Subject: dependencies page In-Reply-To: <1220919041.31147.31.camel@calliope.phig.org> References: <1220919041.31147.31.camel@calliope.phig.org> Message-ID: <48C5D444.2040208@redhat.com> Karsten 'quaid' Wade wrote: > This page is a good example ... > > https://fedoraproject.org/wiki/Alfresco > > ... of what we are going to need for all of you. > > I'm planning to send out an email to the general developers list > (fedora-devel-list), inviting packagers who are interested in ISV > software to assist with the packaging efforts. They benefit from the > dependency list. > > Getting out this list of dependencies is the first step[1] in getting > software packaged. I encourage you to post whatever you have so far to > the wiki so that others can read and assist.[2] > > If you need any assistance with the wiki, please contact me. Using the > general format of https://fedoraproject.org/wiki/Vendor_Name is a good > place to start gathering content. Let us know when you get something > posted! > > Thanks - Karsten > > [1] https://fedoraproject.org/wiki/SIGs/ISV#What_next.3F > > [2] The work on the Alfresco page was a back-and-forth effort between > subject matter experts of Alfresco, Fedora, and Java. There is > expertise that can help when the details are visible to them. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Fedora-isv-sig-list mailing list > Fedora-isv-sig-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-isv-sig-list Karsten and others, This is great work! Can't wait to see more. Jason -- Jason Hibbets, RHCE RHX & ISV Marketing Specialist Office - 919.754.4181 Red Hat :: 1801 Varsity Drive :: Raleigh, NC 27606 IT executives: Red Hat #1 in value. Again. http://www.redhat.com/promo/vendor/ From dhuff at redhat.com Wed Sep 10 15:15:51 2008 From: dhuff at redhat.com (David Huff) Date: Wed, 10 Sep 2008 11:15:51 -0400 Subject: rpmbuilder Message-ID: <48C7E4A7.7080606@redhat.com> I saw this project mentioned on the Fedora-dev list, and found it interesting. This is something the RHX had talked about and thought would be very useful for ISV's. The project seems to be in its infancy and is looking for volunteers. https://fedorahosted.org/rpmbuilder -D From bkearney at redhat.com Tue Sep 16 12:15:30 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 16 Sep 2008 08:15:30 -0400 Subject: Java Packaging and repacking jars Message-ID: <48CFA362.4060908@redhat.com> I know that this issue comes up alot when packaging java apps. There is a discussion [1] over on fedora-java that folks may want to watch or participate in on this. -- bk [1]https://www.redhat.com/archives/fedora-devel-java-list/2008-September/msg00039.html From fnasser at redhat.com Tue Sep 16 20:29:09 2008 From: fnasser at redhat.com (Fernando Nasser) Date: Tue, 16 Sep 2008 16:29:09 -0400 Subject: news on JPackage In-Reply-To: <1220465813.7309.108.camel@calliope.phig.org> References: <1220465813.7309.108.camel@calliope.phig.org> Message-ID: <48D01715.3000606@redhat.com> Karsten 'quaid' Wade wrote: > We've been hunting down answers on how to work across JPackage and > Fedora. The news is mixed with a bright future. Your help now makes > the bright future more obtainable. > > The reality is that while JPackage and Fedora packages are very alike > and the packing rules are more closely aligned, there is no automagic to > make it easier to maintain one package across both systems. By acting > now within both communities, our up front work can help support a goal > of minimizing or removing barriers between the two package repositories. > > Fedora requires everything it needs to build to be entirely in the build > system. It cannot rely upon outside repositories. This is a > fundamental design decision. That means that nearly the same package > from JPackage must be rebuilt in the Fedora system. > > The goal is to find a way to make moving packages between the systems > fully transparent. This cuts down significantly on package maintainers > work while allowing JPackage to service the wider RPM audience. Jesse > Keating, Fedora Release Engineer, is one person leading this effort. It > sounds as if help is still needed within Fedora and JPackage to move > this ahead. There are still decisions to be made on how to proceed, we > may influence that by acting within both communities. > > In the meantime, the best process to follow is this: > > 1. Get Java libraries working in JPackage > > 2. Once there, import those packages in to Fedora > - This will be much faster with most of the work already done > from the JPackage review > > 3. Once forked, you need to update packages in both locations, > syncing changes back/forth > Right. But I would change the 3 to "Fix it on JPackage and merge back into Fedora". We've been doing this for the packages we maintain and it saves some time as we basically do it once. It is the same CVS dist setup, so no problem there. The above process becomes easier if the same person maintains the package in both JPackage and Fedora. JPackage.org has a yet to be announced way to allow "package maintainers" to work on individual packages, but it can be set up for anyone here that wants/needs it. > If we can make a custom of doing these practices, it helps make the > infrastructure level changes easier to occur. > > Let me know your thoughts/questions on this, I'd like to codify this on > the wiki as our policy for ISVs. > That is is agood idea. Cheers, Fernando From fnasser at redhat.com Tue Sep 16 20:52:03 2008 From: fnasser at redhat.com (Fernando Nasser) Date: Tue, 16 Sep 2008 16:52:03 -0400 Subject: "In Fedora" or "For Fedora", or Library versions dependency management Message-ID: <48D01C73.4070600@redhat.com> Hi folks, We are preparing a set of JBoss AS 4.2.x RPMs _for_ Fedora. I say 'for' because we have a huge (hundreds) dependency set and some of the things are not suitable for Fedora. We've been working in reducing this set, solving problems but that will take a couple of years at least, and will probably be for an AS 5 version, never for the 4.2.x as there is no way to influence that upstream at this stage. So we decided to have a separate repository that people can subscribe their systems too and install a jbossas 4.2.x RPM with the dependencies that are not on Fedora etc. Another problem that is hitting us, and this is the main reason of this message, is that the versions of some packages that are in Fedora base are not compatible with ours stuff. An App Server has to pass TCK certification and has too many component interactions end up requiring very specific versions of the libraries. We are having to add some hacks to our package to work around that. Some cases we can solve by upgrading the package in the next Fedora base, *IF* that dosen't break something else that depends on those libraries and is in Fedora already. Some others we will keep bugging JBoss AS maintainers to upgrade in some new release. Some we have a 'versioned' package that installs in parallel. Other just can't be helped. This problem of conflicts of dependency version requirements happens even between our products. We have created a scoreboard with versions of the libraries we need so we could negotiate, among all projects, the versions we will be use in ALL products. But it is not easy, there are cases which are very difficult to solve -- you either break one or the other, backporting is difficult etc. My point is, the more packages we add to the Fedora base the worse it will be for us to agree on the versions of these. So this would indicate that the "for Fedora", as opposed to "in Fedora" approach should be considered by all. On the other hand, each of us having a different set of libraries in our own repositories will make it difficult for people wanting to install more than one. A solution for this would be for us to foresee possible cases where interoperability is desired and work out the dependency problems just between those ISV products involved. Another thing, even if we go to a "in Fedora" as the preferred method, we still can use the "for Fedora" approach as a intermediate state, before all dependencies needed by some product exist in Fedora. One of our possible solutions to make our JBoss AS RPM set available is release it in JPackage.org. They have mirrored repositories and there are distro specific repos, in addition to the generic repos, so our modifications for Fedora can be uploaded to their fedora-9 repo. Of course, if we all decide to make things available from JPackage, the dependency conflict will move there. But JPackage wants to have a 'base' repo with additional (and optional) repos for some major components like App Servers, so one can decide if they want, for instance, JOnAS or JBoss, and get the appropriate dependencies. This added to the yum priority plugin turns in a very flexible setup. The above looks more like a brain dump, sorry. I just came back from vacations and I am traveling for a meeting next week, so time is scarce. Regards to all, Fernando From bkearney at redhat.com Wed Sep 17 12:20:47 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 17 Sep 2008 08:20:47 -0400 Subject: "In Fedora" or "For Fedora", or Library versions dependency management In-Reply-To: <48D01C73.4070600@redhat.com> References: <48D01C73.4070600@redhat.com> Message-ID: <48D0F61F.8040104@redhat.com> Fernando Nasser wrote: > Hi folks, > > We are preparing a set of JBoss AS 4.2.x RPMs _for_ Fedora. I say 'for' > because we have a huge (hundreds) dependency set and some of the things > are not suitable for Fedora. We've been working in reducing this set, > solving problems but that will take a couple of years at least, and will > probably be for an AS 5 version, never for the 4.2.x as there is no way > to influence that upstream at this stage. > > So we decided to have a separate repository that people can subscribe > their systems too and install a jbossas 4.2.x RPM with the dependencies > that are not on Fedora etc. > > Another problem that is hitting us, and this is the main reason of this > message, is that the versions of some packages that are in Fedora base > are not compatible with ours stuff. An App Server has to pass TCK > certification and has too many component interactions end up requiring > very specific versions of the libraries. We are having to add some > hacks to our package to work around that. Some cases we can solve by > upgrading the package in the next Fedora base, *IF* that dosen't break > something else that depends on those libraries and is in Fedora already. > Some others we will keep bugging JBoss AS maintainers to upgrade in > some new release. Some we have a 'versioned' package that installs in > parallel. Other just can't be helped. > > This problem of conflicts of dependency version requirements happens > even between our products. We have created a scoreboard with versions > of the libraries we need so we could negotiate, among all projects, the > versions we will be use in ALL products. But it is not easy, there are > cases which are very difficult to solve -- you either break one or the > other, backporting is difficult etc. > > My point is, the more packages we add to the Fedora base the worse it > will be for us to agree on the versions of these. So this would > indicate that the "for Fedora", as opposed to "in Fedora" approach > should be considered by all. > > On the other hand, each of us having a different set of libraries in our > own repositories will make it difficult for people wanting to install > more than one. A solution for this would be for us to foresee possible > cases where interoperability is desired and work out the dependency > problems just between those ISV products involved. > > Another thing, even if we go to a "in Fedora" as the preferred method, > we still can use the "for Fedora" approach as a intermediate state, > before all dependencies needed by some product exist in Fedora. > > One of our possible solutions to make our JBoss AS RPM set available is > release it in JPackage.org. They have mirrored repositories and there > are distro specific repos, in addition to the generic repos, so our > modifications for Fedora can be uploaded to their fedora-9 repo. > > Of course, if we all decide to make things available from JPackage, the > dependency conflict will move there. But JPackage wants to have a > 'base' repo with additional (and optional) repos for some major > components like App Servers, so one can decide if they want, for > instance, JOnAS or JBoss, and get the appropriate dependencies. This > added to the yum priority plugin turns in a very flexible setup. > > > The above looks more like a brain dump, sorry. I just came back from > vacations and I am traveling for a meeting next week, so time is scarce. This may be a big can-o-worms.. and if so I apologize, but is there a thought to support multi-versions jars? I could see a scenario where xerces 2.8.X is a stream (2.8.1 and 2.8.2) installed at the same time as xerces 2.9. The value being that I guess the issue is over major releases, not minor ones. The downside being I am sure this is verbotes in some fedora packaging way. -- bk -- bk From fnasser at redhat.com Wed Sep 17 14:00:57 2008 From: fnasser at redhat.com (Fernando Nasser) Date: Wed, 17 Sep 2008 10:00:57 -0400 Subject: Multiple versions [Was: "In Fedora" or "For Fedora"...] In-Reply-To: <48D0F61F.8040104@redhat.com> References: <48D01C73.4070600@redhat.com> <48D0F61F.8040104@redhat.com> Message-ID: <48D10D99.9030407@redhat.com> Bryan Kearney wrote: (..) > > This may be a big can-o-worms.. and if so I apologize, but is there a > thought to support multi-versions jars? I could see a scenario where > xerces 2.8.X is a stream (2.8.1 and 2.8.2) installed at the same time as > xerces 2.9. The value being that I guess the issue is over major > releases, not minor ones. The downside being I am sure this is verbotes > in some fedora packaging way. > Hi Bryan, This is an old discussion, so that can of worms has been opened many years ago, don't worry. The whole purpose of a "distribution" (like RHEL, Fedora, Suse, Debian, JPackage, etc.) is to find a set of packages that interoperates, ideally resulting in one version of each. The single version facilitates maintaining, specially security fixing. It also prevents conflicts by accidentally loading two different versions, compiling with one and running with another etc. This said, sometimes exceptions have to be made. Sometimes you'll see a "compatible" library in Linux. Similarly, sometimes JPackage (or RHEL, or Fedora) releases a versioned package to cope with some unsolvable situation. This is treated as exceptional cases and usually done for a limited time (until the dependencies can be moved to the same version). I call these packages "legacy" and "progressive". For instance, if the maistream version of xerces is 4.7.1, our xerces-j2 RPM will be at 2.7.1 and we'd produce a "progressive" xerces-j282 package as a last resource. Please note the "last resource" ;-) In a few cases we have packages that are meant to be installed in parallel, like the tomcat ones as people need to migrate applications between major versions and usually do it a few at a time. So we have "tomcat5" and "tomcat6" at the moment. But this is a service, not a library. Regards, Fernando From bkearney at redhat.com Wed Sep 17 14:55:27 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 17 Sep 2008 10:55:27 -0400 Subject: Multiple versions [Was: "In Fedora" or "For Fedora"...] In-Reply-To: <48D10D99.9030407@redhat.com> References: <48D01C73.4070600@redhat.com> <48D0F61F.8040104@redhat.com> <48D10D99.9030407@redhat.com> Message-ID: <48D11A5F.4080503@redhat.com> Fernando Nasser wrote: > Bryan Kearney wrote: > (..) >> >> This may be a big can-o-worms.. and if so I apologize, but is there a >> thought to support multi-versions jars? I could see a scenario where >> xerces 2.8.X is a stream (2.8.1 and 2.8.2) installed at the same time >> as xerces 2.9. The value being that I guess the issue is over major >> releases, not minor ones. The downside being I am sure this is >> verbotes in some fedora packaging way. >> > > Hi Bryan, > > This is an old discussion, so that can of worms has been opened many > years ago, don't worry. > > The whole purpose of a "distribution" (like RHEL, Fedora, Suse, Debian, > JPackage, etc.) is to find a set of packages that interoperates, ideally > resulting in one version of each. The single version facilitates > maintaining, specially security fixing. It also prevents conflicts by > accidentally loading two different versions, compiling with one and > running with another etc. > > This said, sometimes exceptions have to be made. Sometimes you'll see a > "compatible" library in Linux. Similarly, sometimes JPackage (or RHEL, > or Fedora) releases a versioned package to cope with some unsolvable > situation. This is treated as exceptional cases and usually done for a > limited time (until the dependencies can be moved to the same version). > > I call these packages "legacy" and "progressive". For instance, if the > maistream version of xerces is 4.7.1, our xerces-j2 RPM will be at 2.7.1 > and we'd produce a "progressive" xerces-j282 package as a last resource. > Please note the "last resource" ;-) > > In a few cases we have packages that are meant to be installed in > parallel, like the tomcat ones as people need to migrate applications > between major versions and usually do it a few at a time. So we have > "tomcat5" and "tomcat6" at the moment. But this is a service, not a > library. I figured as much.. but there are always valid cases (e.g. the kernel supports this). It seems like one instance of a library is better then many applications packaging the library. Perhaps the history of Java (and ruby) would warrant a pattern for distributing various versions. -- bk From mdahlman at jaspersoft.com Fri Sep 19 18:28:51 2008 From: mdahlman at jaspersoft.com (Matthew Dahlman) Date: Fri, 19 Sep 2008 11:28:51 -0700 (PDT) Subject: dependencies page In-Reply-To: <1220919041.31147.31.camel@calliope.phig.org> References: <1220919041.31147.31.camel@calliope.phig.org> Message-ID: <7291989EA27545CBBF8CF7E5AF7459D1@mdahlman2t60> Rather than create a second page for JasperServer, I created a page intended to list all of the JAR files we need. This way we can note where multiple projects use overlapping JARs. https://fedoraproject.org/wiki/Java_JAR_dependencies Regards, Matt -----Original Message----- From: fedora-isv-sig-list-bounces at redhat.com [mailto:fedora-isv-sig-list-bounces at redhat.com] On Behalf Of Karsten 'quaid' Wade Sent: Monday, 08 September, 2008 17:11 To: fedora-isv-sig-list Subject: dependencies page This page is a good example ... https://fedoraproject.org/wiki/Alfresco ... of what we are going to need for all of you. I'm planning to send out an email to the general developers list (fedora-devel-list), inviting packagers who are interested in ISV software to assist with the packaging efforts. They benefit from the dependency list. Getting out this list of dependencies is the first step[1] in getting software packaged. I encourage you to post whatever you have so far to the wiki so that others can read and assist.[2] If you need any assistance with the wiki, please contact me. Using the general format of https://fedoraproject.org/wiki/Vendor_Name is a good place to start gathering content. Let us know when you get something posted! Thanks - Karsten [1] https://fedoraproject.org/wiki/SIGs/ISV#What_next.3F [2] The work on the Alfresco page was a back-and-forth effort between subject matter experts of Alfresco, Fedora, and Java. There is expertise that can help when the details are visible to them. -- Karsten Wade, Sr. Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 From fnasser at redhat.com Fri Sep 19 19:42:10 2008 From: fnasser at redhat.com (Fernando Nasser) Date: Fri, 19 Sep 2008 15:42:10 -0400 Subject: dependencies page In-Reply-To: <7291989EA27545CBBF8CF7E5AF7459D1@mdahlman2t60> References: <1220919041.31147.31.camel@calliope.phig.org> <7291989EA27545CBBF8CF7E5AF7459D1@mdahlman2t60> Message-ID: <48D40092.8000500@redhat.com> Matthew Dahlman wrote: > Rather than create a second page for JasperServer, I created a page > intended to list all of the JAR files we need. This way we can note where > multiple projects use overlapping JARs. > > https://fedoraproject.org/wiki/Java_JAR_dependencies > > I could give you (not next week, I will be travelling) the ones we need for JBoss AS too. However, my database does not have versions in the jar names, they are in a separate column. Also, I noticed that 1/2 of the things you list as not in Jpackage are in JPackage 5.0 (the WIP new release). For instance, activation is JAF, any "jaf" package will have it. Same for mail.jar The Spring 2.x is the spring2 package. jsf, jstl, are there, from glassfish-* I am sure we have a full antlr as JBoss AS uses it. AXIS is also complete. It may be a difference in the name of the JARs W.r.t. wsdl4j, xerces and xalan these are just versions mismatches. I'd strongly recommend that JasperSoft would spend the time necessary to update these components as they are using very ancient versions and this makes maintainability very difficult (these communities don't have these under their radar for quite some time). I think I will find a way to create a page for JPackage with a JAR to package mapping, and with a version column. I have to ask our host to create a database instance for me. (note: unversioned JAR file names seems to be the more current practice, Sun likes it and it is compatible with maven, so I will list them that way). Regards to all. See you in one week. Fernando > Regards, > Matt > > -----Original Message----- > From: fedora-isv-sig-list-bounces at redhat.com > [mailto:fedora-isv-sig-list-bounces at redhat.com] On Behalf Of Karsten > 'quaid' Wade > Sent: Monday, 08 September, 2008 17:11 > To: fedora-isv-sig-list > Subject: dependencies page > > This page is a good example ... > > https://fedoraproject.org/wiki/Alfresco > > .. of what we are going to need for all of you. > > I'm planning to send out an email to the general developers list > (fedora-devel-list), inviting packagers who are interested in ISV software > to assist with the packaging efforts. They benefit from the dependency > list. > > Getting out this list of dependencies is the first step[1] in getting > software packaged. I encourage you to post whatever you have so far to > the wiki so that others can read and assist.[2] > > If you need any assistance with the wiki, please contact me. Using the > general format of https://fedoraproject.org/wiki/Vendor_Name is a good > place to start gathering content. Let us know when you get something > posted! > > Thanks - Karsten > > [1] https://fedoraproject.org/wiki/SIGs/ISV#What_next.3F > > [2] The work on the Alfresco page was a back-and-forth effort between > subject matter experts of Alfresco, Fedora, and Java. There is expertise > that can help when the details are visible to them. > > -- > Karsten Wade, Sr. Developer Community Mgr. > Dev Fu : http://developer.redhatmagazine.com > Fedora : http://quaid.fedorapeople.org > gpg key : AD0E0C41 > > _______________________________________________ > Fedora-isv-sig-list mailing list > Fedora-isv-sig-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-isv-sig-list > From mdahlman at jaspersoft.com Fri Sep 19 20:29:46 2008 From: mdahlman at jaspersoft.com (Matthew Dahlman) Date: Fri, 19 Sep 2008 13:29:46 -0700 (PDT) Subject: dependencies page In-Reply-To: <48D40092.8000500@redhat.com> References: <1220919041.31147.31.camel@calliope.phig.org> <7291989EA27545CBBF8CF7E5AF7459D1@mdahlman2t60> <48D40092.8000500@redhat.com> Message-ID: <366AE72A0CFB4AA8922EDC915C27841F@mdahlman2t60> That's great news to hear that many jars are already in JPackage 5.0 (the WIP new release). I didn't notice this possibility as I looked at the JPackage site. I'll update my lists. Regarding the old jars, I agree. In many (most?) cases we can probably just drop in the newer jar and test to make sure JasperServer still works. In the worst case scenario where dropping in the new jar breaks our app, I'm not sure that I'll be able to get JasperServer to update. Allocating resources to fix something that isn't broken is often tough. Anyway, I won't worry about this yet; we've got plenty of bridges to cross before this one. Regards, Matt -----Original Message----- From: Fernando Nasser [mailto:fnasser at redhat.com] Sent: Friday, 19 September, 2008 12:42 To: Matthew Dahlman Cc: 'fedora-isv-sig-list' Subject: Re: dependencies page Matthew Dahlman wrote: > Rather than create a second page for JasperServer, I created a page > intended to list all of the JAR files we need. This way we can note > where multiple projects use overlapping JARs. > > https://fedoraproject.org/wiki/Java_JAR_dependencies > > I could give you (not next week, I will be travelling) the ones we need for JBoss AS too. However, my database does not have versions in the jar names, they are in a separate column. Also, I noticed that 1/2 of the things you list as not in Jpackage are in JPackage 5.0 (the WIP new release). For instance, activation is JAF, any "jaf" package will have it. Same for mail.jar The Spring 2.x is the spring2 package. jsf, jstl, are there, from glassfish-* I am sure we have a full antlr as JBoss AS uses it. AXIS is also complete. It may be a difference in the name of the JARs W.r.t. wsdl4j, xerces and xalan these are just versions mismatches. I'd strongly recommend that JasperSoft would spend the time necessary to update these components as they are using very ancient versions and this makes maintainability very difficult (these communities don't have these under their radar for quite some time). I think I will find a way to create a page for JPackage with a JAR to package mapping, and with a version column. I have to ask our host to create a database instance for me. (note: unversioned JAR file names seems to be the more current practice, Sun likes it and it is compatible with maven, so I will list them that way). Regards to all. See you in one week. Fernando > Regards, > Matt > > -----Original Message----- > From: fedora-isv-sig-list-bounces at redhat.com > [mailto:fedora-isv-sig-list-bounces at redhat.com] On Behalf Of Karsten > 'quaid' Wade > Sent: Monday, 08 September, 2008 17:11 > To: fedora-isv-sig-list > Subject: dependencies page > > This page is a good example ... > > https://fedoraproject.org/wiki/Alfresco > > .. of what we are going to need for all of you. > > I'm planning to send out an email to the general developers list > (fedora-devel-list), inviting packagers who are interested in ISV > software to assist with the packaging efforts. They benefit from the > dependency list. > > Getting out this list of dependencies is the first step[1] in getting > software packaged. I encourage you to post whatever you have so far > to the wiki so that others can read and assist.[2] > > If you need any assistance with the wiki, please contact me. Using > the general format of https://fedoraproject.org/wiki/Vendor_Name is a > good place to start gathering content. Let us know when you get > something posted! > > Thanks - Karsten > > [1] https://fedoraproject.org/wiki/SIGs/ISV#What_next.3F > > [2] The work on the Alfresco page was a back-and-forth effort between > subject matter experts of Alfresco, Fedora, and Java. There is > expertise that can help when the details are visible to them. > > -- > Karsten Wade, Sr. Developer Community Mgr. > Dev Fu : http://developer.redhatmagazine.com > Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 > > _______________________________________________ > Fedora-isv-sig-list mailing list > Fedora-isv-sig-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-isv-sig-list >