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