On Mon, 10 Nov 2008 17:34:46 +0100, Adrian Brock <abrock(a)redhat.com> wrote:
On Mon, 2008-11-10 at 17:31 +0100, Max Rydahl Andersen wrote:
> > 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....
>
> 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.
>
For the sources, run:
mvn dependency:sources eclipse:eclipse
This will download the source jars into your maven repository
then create a .classpath file that references them.
That gives me a .classpath for *building* AS based on the local maven
repository
...what I need is a classpath/source/javadoc map for the jars inside AS
when it is being *used*
/max
I imagine there is something similar for javadocs???
> /max
>
> > Max Rydahl Andersen wrote:
> >> On Mon, 10 Nov 2008 15:27:30 +0100, Paul Gier <pgier(a)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...
> >>>>>>> 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(a)lists.jboss.org
> [mailto:jboss-
> >>>>>>>> >> development-bounces(a)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(a)lists.jboss.org
> >>>>>>>> >>>>>
>
https://lists.jboss.org/mailman/listinfo/jboss-development
> >>>>>>>> >>>>>
> >>>>>>>> >>>>
> >>>>>>>> >>>>
> >>>>>>>> >>>>
_______________________________________________
> >>>>>>>> >>>> jboss-development mailing list
> >>>>>>>> >>>> jboss-development(a)lists.jboss.org
> >>>>>>>> >>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
> >>>>>>>> >>>
_______________________________________________
> >>>>>>>> >>> jboss-development mailing list
> >>>>>>>> >>> jboss-development(a)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(a)lists.jboss.org
> >>>>>>>> >>
https://lists.jboss.org/mailman/listinfo/jboss-development
> >>>>>>>> >
> >>>>>>>> >
> >>>>>>>> >
_______________________________________________
> >>>>>>>> > jboss-development mailing list
> >>>>>>>> > jboss-development(a)lists.jboss.org
> >>>>>>>> >
https://lists.jboss.org/mailman/listinfo/jboss-development
> >>>>>>>> _______________________________________________
> >>>>>>>> jboss-development mailing list
> >>>>>>>> jboss-development(a)lists.jboss.org
> >>>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
> >>>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> jboss-development mailing list
> >>>>> jboss-development(a)lists.jboss.org
> >>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
> >>>>
> >>>
> >>> _______________________________________________
> >>> jboss-development mailing list
> >>> jboss-development(a)lists.jboss.org
> >>>
https://lists.jboss.org/mailman/listinfo/jboss-development
> >>
> >
> > _______________________________________________
> > jboss-development mailing list
> > jboss-development(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/jboss-development
>
>
>