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

Mon Nov 10 11:31:39 EST 2008

> We currently have just one source jar files for each app server module.   
> So for example in the maven repository [1], the j2se module has one jar  
> for all the main class files, one for all the main sources, and a few  
> jars that include a subset of the classes.
>
> [1]  
> http://repository.jboss.org/maven2/org/jboss/jbossas/jboss-as-j2se/5.0.0.CR2/

What i'm missing is a map from AS's jar's to their relevant -sources/-docs  
artifact
so we can map them to the apropriate -sources.jar in eclipse.

/max

> Max Rydahl Andersen wrote:
>> On Mon, 10 Nov 2008 15:27:30 +0100, Paul Gier <pgier at redhat.com> wrote:
>>
>>> Can you clarify a bit what you are asking for?
>>> The maven standard for source jars is just to append "-sources" to the  
>>> name.  So things like the dependency plugin and m2eclipse use that  
>>> convention to find sources that are associated with a particular jar.
>>  I'm asking if we have that for *every* jar in AS so we could use it  
>> when
>> setting up a server in Eclipse ?
>>  /max
>>
>>> Max Rydahl Andersen wrote:
>>>> Note, client api is one thing; the other is server side API and being  
>>>> able to figure out
>>>> which source jar goes with which runtime jar in JBoss AS. Having pom  
>>>> info for that would
>>>> be good...is that doable ?
>>>>  /max
>>>>
>>>>> 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

-- 
/max