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