BTW, we are announcing final release of Shoal 1.1 next week.
We will have the branched Jxta version in that release though.
Shreedhar Ganapathy wrote:
> 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
>>>>
>>>>
>>