[jboss-dev] jbossall-client.jar now references external libs

[Max Rydahl Andersen]

if it is not in the EAP it does not exist for users hence non-supported ;)

/max

> The pom is here: https://svn.jboss.org/repos/jbossas/trunk/client/
>
> Galder Zamarreno wrote:
>> Hmmm, strange because I built trunk on Friday and I see no .pom  
>> whatsoever in the client/ directory. Am I missing something?
>>  Paul Gier wrote:
>>> It's in the client directory.  And it's in the maven snapshot  
>>> repository:
>>> http://snapshots.jboss.org/maven2/org/jboss/jbossas/jboss-as-client/5.0.0-SNAPSHOT/  
>>> Galder Zamarreno wrote:
>>>> Where is this client pom?
>>>>
>>>> Paul Gier wrote:
>>>>> I added a new client pom if anyone wants to try it.  There are still  
>>>>> some things I need to work out, because a few of the jars were not  
>>>>> available in the maven repo and it's including a lot of trasitive  
>>>>> jars that probably need to be excluded.
>>>>>
>>>>> Paul Gier wrote:
>>>>>> Since there seems to be a lot of demand for this, I'm going to  
>>>>>> create a new directory in the app server called "client".  And this  
>>>>>> will contain a pom that lists all the jars that are currently in  
>>>>>> the all-client jar manifest.
>>>>>>
>>>>>> This will be deployed to our repository with the release, so it  
>>>>>> should be usable from maven or ivy.
>>>>>>
>>>>>> Max Rydahl Andersen wrote:
>>>>>>> This is what should be done; have a proper managed repository of  
>>>>>>> jars
>>>>>>> that is usable from both Maven and Ivy. Then *a lot* of issues  
>>>>>>> from a
>>>>>>> tooling perspective would be way easier to solve.
>>>>>>>
>>>>>>> /max
>>>>>>>
>>>>>>>> If we produced a proper jbossall-client artifact in the maven
>>>>>>>> repository, i.e. one that specified all its dependencies (the  
>>>>>>>> other
>>>>>>>> client jars).
>>>>>>>> http://repository.jboss.com/maven2/org/jboss/client/jbossall-client/5.0.0.Beta4/jbossall-client-5.0.0.Beta4.pom  
>>>>>>>> NOTE: The one above comes from before the change to use the  
>>>>>>>> manifest.
>>>>>>>>
>>>>>>>> At least people using maven could create their .classpath  
>>>>>>>> correctly.
>>>>>>>>
>>>>>>>> Another option would be to include a dummy eclipse project
>>>>>>>> in the distribution that people could import into their project.
>>>>>>>>
>>>>>>>> On Thu, 2008-11-06 at 10:28 -0600, David M. Lloyd wrote:
>>>>>>>>> Are there mechanisms which Eclipse *will* read?  Like OSGi  
>>>>>>>>> descriptors or
>>>>>>>>> something like that?  Do we have an Eclipse plugin for
>>>>>>>>> jboss-classloading.xml support yet? :-)
>>>>>>>>>
>>>>>>>>> - DML
>>>>>>>>>
>>>>>>>>> On 11/06/2008 09:56 AM, Sacha Labourey wrote:
>>>>>>>>> > I agree, this will be a big usability issue. For the sake of  
>>>>>>>>> making OUR life
>>>>>>>>> > easier (patching), we are going to make EVERYBODY's life more  
>>>>>>>>> difficult,
>>>>>>>>> > that's nonsense. If you need a patching mechanism, write a  
>>>>>>>>> script which will
>>>>>>>>> > just do that, but do not impact user usability.
>>>>>>>>> >
>>>>>>>>> >> -----Original Message-----
>>>>>>>>> >> From: jboss-development-bounces at lists.jboss.org [mailto:jboss-
>>>>>>>>> >> development-bounces at lists.jboss.org] On Behalf Of Galder  
>>>>>>>>> Zamarreno
>>>>>>>>> >> Sent: jeudi, 6 novembre 2008 16:48
>>>>>>>>> >> To: JBoss.org development list
>>>>>>>>> >> Subject: Re: [jboss-dev] jbossall-client.jar now references  
>>>>>>>>> external
>>>>>>>>> >> libs
>>>>>>>>> >>
>>>>>>>>> >> Hmmmm, we're gonna have users screaming about this.
>>>>>>>>> >>
>>>>>>>>> >> In the past, if you're developing a client app in Eclipse,  
>>>>>>>>> you only
>>>>>>>>> >> needed jbossall-client.jar and log4j.jar but this won't be  
>>>>>>>>> the case
>>>>>>>>> >> with
>>>>>>>>> >> AS5 as I've just found out when trying to run a client app  
>>>>>>>>> against
>>>>>>>>> >> trunk. Eclipse for example does not read manifest classpath  
>>>>>>>>> entries:
>>>>>>>>> >>
>>>>>>>>> >> http://forums.bea.com/thread.jspa?threadID=570001075
>>>>>>>>> >>
>>>>>>>>> >> I've just talked to Max who confirmed it. I'll let him  
>>>>>>>>> explain the gory
>>>>>>>>> >> details of Eclipse.
>>>>>>>>> >>
>>>>>>>>> >> Cheers,
>>>>>>>>> >>
>>>>>>>>> >> Dimitris Andreadis wrote:
>>>>>>>>> >>> Yes, they'll need the whole jboss/client dir.
>>>>>>>>> >>>
>>>>>>>>> >>> Max Rydahl Andersen wrote:
>>>>>>>>> >>>> I'm curious how this affects users (and hence tooling).
>>>>>>>>> >>>>
>>>>>>>>> >>>> I assume users now instead of having jbossall-client.jar on  
>>>>>>>>> the
>>>>>>>>> >>>> classpath will need to have an exact
>>>>>>>>> >>>> copy of client/*.jar etc. when running against jboss ?
>>>>>>>>> >>>>
>>>>>>>>> >>>> /max
>>>>>>>>> >>>>
>>>>>>>>> >>>>> Paul changed jbossall-client.jar so now instead of  
>>>>>>>>> embedding the
>>>>>>>>> >>>>> content of the other client
>>>>>>>>> >>>>> libraries, it now references them through MANIFEST.MF  
>>>>>>>>> Class-Path
>>>>>>>>> >> entry.
>>>>>>>>> >>>>> This makes it possible to introduce drop-in replacements  
>>>>>>>>> for client
>>>>>>>>> >>>>> libs, if needed, without
>>>>>>>>> >>>>> worrying about jbossall-client.jar
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> http://jira.jboss.com/jira/browse/JBAS-4355
>>>>>>>>> >>>>> _______________________________________________
>>>>>>>>> >>>>> jboss-development mailing list
>>>>>>>>> >>>>> jboss-development at lists.jboss.org
>>>>>>>>> >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>>> >>>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>> _______________________________________________
>>>>>>>>> >>>> jboss-development mailing list
>>>>>>>>> >>>> jboss-development at lists.jboss.org
>>>>>>>>> >>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>>> >>> _______________________________________________
>>>>>>>>> >>> jboss-development mailing list
>>>>>>>>> >>> jboss-development at lists.jboss.org
>>>>>>>>> >>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>>> >> --
>>>>>>>>> >> Galder Zamarreño
>>>>>>>>> >> Sr. Software Maintenance Engineer
>>>>>>>>> >> JBoss, a division of Red Hat
>>>>>>>>> >> _______________________________________________
>>>>>>>>> >> jboss-development mailing list
>>>>>>>>> >> jboss-development at lists.jboss.org
>>>>>>>>> >> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > _______________________________________________
>>>>>>>>> > jboss-development mailing list
>>>>>>>>> > jboss-development at lists.jboss.org
>>>>>>>>> > https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>>> _______________________________________________
>>>>>>>>> jboss-development mailing list
>>>>>>>>> jboss-development at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> jboss-development mailing list
>>>>>> jboss-development at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>
>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development



-- 
/max