users@shoal.java.net

Re: [Shoal-Users] correct JXTA jar for shoal/signing problems?

From: Shreedhar Ganapathy <Shreedhar.Ganapathy_at_Sun.COM>
Date: Fri, 06 Feb 2009 13:56:02 -0800

Thanks for your insights Jim. We can look into following your suggested
route.

Thanks a lot
Shreedhar

Jim Marino wrote:
> Hi Shreedhar,
>
> I'm definitely not a Maven expert but in order to properly Mavenize
> Shoal, it will need to depend on a released version of JXTA (i.e. not
> a snapshot or un-released version). There are a number of things not
> to like about Maven but this feature is arguably a good one as it
> facilitates reproducible builds.
>
> From your description below, it sounds as if a possible solution would
> be to create a branch in the JXTA project. The branch would
> incorporate only the critical fixes for Shoal and could be released
> independently from mainline JXTA development. Shoal could depend on
> that branch, which would be a published Maven artifact. At the
> appropriate time, fixed from branch could be merged into the JXTA
> trunk. This seems as if it would meet the requirements and independent
> release cycles of Shoal as well as the JXTA community. It would also
> provide the following benefits:
>
> - Shoal would be able to rely on released artifacts as opposed to
> special/forked versions
> - JXTA bug fixes and enhancements could be tracked as part of the JXTA
> project rather than as first part of Shoal. This would also provide
> more granular change history.
> - Bug fixes in the JXTA branch could be selectively merged into trunk
> without having to take all fixes from Shoal
> - I imagine merging would also be easier as change history will be in
> one place
>
> This may be slightly more more work on the Maven side but overall it
> may reduce the amount of work. Also, investing in making Shoal
> available as a Maven artifact will make it easier for other projects
> such as ours to use it.
>
> Jim
>
>
> On Feb 6, 2009, at 1:00 PM, Shreedhar Ganapathy wrote:
>
>> Hi Olaf
>> I know that would be very ideal. :)
>>
>> But... say, a critical bug is reported from an upstream project such
>> as GlassFish/Sailfin after a Jxta release and requires us to get a
>> fix in Jxta and thus to not be able to use a released version. And
>> the folks at Jxta cannot do releases for each individual critical fix
>> we need from them. When Shoal is released, we as a result cannot
>> expect Jxta to have a corresponding release or depend on their
>> released version.
>>
>> Same applies to any other external library, for instance, say,
>> JGroups. Or for that matter, a project having external dependencies
>> such as your own project, depending on the external Shoal library :)
>>
>> Its pretty difficult to align these releases when our delivery
>> roadmap is being mainly driven by revenue oriented enterprise
>> software that have their own processes wrt the bugs that need to be
>> fixed, etc. particularly when they are close to a release. While
>> being sensitive to the needs of the community, we have to consider
>> the above factors as well. After all, our salaries are paid for by
>> support revenue from these upstream project so we can keep this
>> project going. :)
>>
>> We have been through a few iterations on this and reducing risk for
>> such high stakes projects wrt fixes coming to an external module such
>> as say Jxta for a problem unrelated to them is unacceptable to the
>> upstream projects.
>>
>> Hence, we decided to have our own Jxta branch to control checkins for
>> only fixes we care about from Shoal perspective. Now the folks at
>> Jxta project cant do a release of this restricted Jxta branch given
>> that other fixes would not make it to the release and their community
>> would not be happy about it. So we do the best we can with available
>> resources.
>>
>> At some point in the near future, we will merge the Jxta branch into
>> mainstream Jxta trunk and move over to their released version but the
>> differential cycle will continue in my expectation.
>>
>> I hope this explanation provides some context on our perspective on
>> the method to this madness :)
>> --Shreedhar
>>
>> Olaf Krische wrote:
>>> Aloha,
>>>
>>> it would be just helpful, if a released shoal jar would depend on
>>> a released jxta jar as well.
>>>
>>> Developer versions can rely on whatever, i dont care. :)
>>>
>>>
>>> On Fri, Feb 06, 2009 at 11:53:43AM -0800, Shreedhar Ganapathy wrote:
>>>
>>>> Hi Jim,
>>>> This is the first time we have heard of a need for publishing to Maven
>>>> repos.
>>>> We'll look into it though to do the needful and get back to y'all.
>>>> Cheers
>>>> Shreedhar
>>>> Jim Marino wrote:
>>>>
>>>> Hi,
>>>>
>>>> It would be really helpful if Shoal could publish updated Maven
>>>> artifacts. We ([1]www.fabric3.org <http://www.fabric3.org>) have the same problem and worked
>>>> around it by creating a Maven module that calls out to an Ant script
>>>> which manually downloads the Shoal artifacts and installs them in a
>>>> local repo. Other modules can depend on the Maven module, which
>>>> guarantees a reproducible build. Here are the modules if you want to
>>>> see how we did this:
>>>>
>>>> [2]http://svn.codehaus.org/fabric3/modules/trunk/federated/fabric3-inst
>>>> all-shoal/
>>>>
>>>> [3]http://svn.codehaus.org/fabric3/modules/trunk/federated/fabric3-fede
>>>> ration-shoal/
>>>>
>>>> HTH
>>>>
>>>> Jim
>>>>
>>>> On Feb 6, 2009, at 11:38 AM, Shreedhar Ganapathy wrote:
>>>>
>>>> Hi Rob
>>>> We typically use a version of Jxta that is 2.5.1+ some low risk bug
>>>> fixes relevant to critical consumers of Shoal such as GlassFish and
>>>> Sailfin Telco appserver. We have not posted versions of Shoal or the
>>>> related Jxta binaries on any maven repository.
>>>> One possible way to workaround this situation is to host Shoal and
>>>> dependent Jxta version binaries in a local maven repository and pulling
>>>> from there. Not ideal but a short term solution.
>>>> Shreedhar
>>>> [4]Rob_Mathews_at_Dell.com wrote:
>>>>
>>>> Hi:
>>>>
>>>> I'm having trouble building with maven. Whenever I run, I get a signing
>>>> exception:
>>>>
>>>> initializing Shoal : java.lang.SecurityException: class
>>>> "net.jxta.platform.NetworkConfigurator"'s signer information does not
>>>> match signer information of other classes in the same package
>>>> at
>>>> java.lang.ClassLoader.checkCerts(ClassLoader.java:775)
>>>> at
>>>> java.lang.ClassLoader.preDefineClass(ClassLoader.java:487)
>>>> at
>>>> java.lang.ClassLoader.defineClass(ClassLoader.java:614)
>>>> at
>>>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
>>>> at
>>>> org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappCl
>>>> assLoader.java:1815)
>>>> at
>>>> org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoade
>>>> r.java:872)
>>>> at
>>>> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoade
>>>> r.java:1325)
>>>> at
>>>> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoade
>>>> r.java:1204)
>>>> at
>>>> java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>>>> at
>>>> com.sun.enterprise.jxtamgmt.NetworkManager.initWPGF(NetworkManager.java
>>>> :571)
>>>>
>>>> My maven setup is this:
>>>>
>>>> JXTA:
>>>> <repository>
>>>> <id>maven2-repository.dev.java.net</id>
>>>> <name>Java.net Repository for Maven</name>
>>>> <url>[5]http://download.java.net/maven/2/</url>
>>>> <layout>default</layout>
>>>> </repository>
>>>> <dependency>
>>>> <groupId>net.jxta</groupId>
>>>> <artifactId>jxta-jxse</artifactId>
>>>> <version>2.5</version>
>>>> </dependency>
>>>> SHOAL:
>>>> <dependency>
>>>> <groupId>com.sun.enterprise.ee.cms</groupId>
>>>> <artifactId>shoal-gms</artifactId>
>>>> <version>1.1_09292008</version>
>>>> </dependency>
>>>>
>>>> Which maven artifact or version of jxta am I supposed to be using?
>>>>
>>>> Rob.
>>>>
>>>> References
>>>>
>>>> 1. http://www.fabric3.org/
>>>> 2. http://svn.codehaus.org/fabric3/modules/trunk/federated/fabric3-install-shoal/
>>>> 3. http://svn.codehaus.org/fabric3/modules/trunk/federated/fabric3-federation-shoal/
>>>> 4. mailto:Rob_Mathews_at_Dell.com
>>>> 5. http://download.java.net/maven/2/
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_shoal.dev.java.net
>>> For additional commands, e-mail: users-help_at_shoal.dev.java.net
>>>
>>>
>