You are viewing a plain text version of this content. The canonical link for it is here.
Posted to alexandria-dev@jakarta.apache.org by di...@multitask.com.au on 2003/01/02 01:10:50 UTC
NSUML and bootstrapping
Sam Writes:
> dion@apache.org wrote:
>
> + <depend project="nsuml">
>
> For this to work, we need a descriptor for nsuml. As a suggestion, it
generally is a good idea to run the "gen" target of jakarta-gump's
build.xml. The only
> prereqs to run this is JDK 1.4 and Ant. Or a prior version of the JDK
and Xerces and Xalan or equivalent. Building the gen target runs in well
under a
> minute on my laptop.
I know there's no descriptor for nsuml, but I thought it better to get
graph in and work on the next thing, rather than do it all at once.
I've been running gump on my laptop as well, but you'll notice from posts
that it's been a little problematic.
> I also note that the nsuml project is LGPL. Given that java has no
concept that corresponds to a link as defined by this license, a
conservative reading of
> the license would make this equivalent to GPL, and require all code that
is distributed with it to be licensed under a compatible license.
And hence we don't distribute it with either graph or maven. It is
available for download from ibiblio, as the other maven jars are.
> P.S. I'm pleased to see you diving in like this!
Now I can actually change things and get them working, it's a lot easier.
But it kinda makes me wonder why we are trying to get a gump descriptor
generated for maven projects that runs ant, rather than gump bootstrapping
maven and adding a 'maven' tag to the project definition.
comments?
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: NSUML and bootstrapping
Posted by Sam Ruby <ru...@intertwingly.net>.
dion@multitask.com.au wrote:
>
> Bootstrapping maven is fairly lean. It just uses ant and jaxp. The
> bootstrap process does download the jars needed to compile and build maven
> though. How does ant get built? xml-commons produces JAXP, and there's a
> circular dependency between it and ant, right?
These days, there is a version of jaxp in the JDK. So Ant should only
depend on the JDK.
I don't want to verify that maven builds against the version of its
dependencies that it choses to download, I want to verify that maven can
be built against the version of the dependencies I have built. So, in
other words, I want to employ the "jar override feature" that you
describe below during the bootstrap process itself.
> This is known as the jar override feature. If maven.jar.override is set to
> true, then maven looks for a property that tells it the location of that
> jar file. i.e. if maven.jar.override=true and maven is looking for 'ant',
> it gets the absolute location for the ant jar from the value of the
> property 'maven.jar.ant'. We'd need a mapping between gump's project id
> and maven's.
>
> Though, it should be easy enough to get gump to set up properties for the
> various jars :)
Sounds doable.
>>3) there also is the issue of ordering maven builds. Between Maven and
>>Gump, somebody would need to understand enough of maven's project
>>descriptors to order the compilations of projects.
>
> I figure between the two of us we should be able to do it.
+1
- Sam Ruby
Re: NSUML and bootstrapping
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 2 Jan 2003, <di...@multitask.com.au> wrote:
> How does ant get built? xml-commons produces JAXP, and there's a
> circular dependency between it and ant, right?
This is why we have the bootstrap-ant project. This one only depends
on a pre-installed JAXP (which shouldn't be necessary any longer, now
that we are all running JDK 1.4).
xml-commons depends on this bootstrapped version. jakarta-ant in turn
depends on bootstrap-ant and xml-commons and this is the version of
Ant all (well, most) other projects depend upon.
Stefan
Re: NSUML and bootstrapping
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 2 Jan 2003, <di...@multitask.com.au> wrote:
> How does ant get built? xml-commons produces JAXP, and there's a
> circular dependency between it and ant, right?
This is why we have the bootstrap-ant project. This one only depends
on a pre-installed JAXP (which shouldn't be necessary any longer, now
that we are all running JDK 1.4).
xml-commons depends on this bootstrapped version. jakarta-ant in turn
depends on bootstrap-ant and xml-commons and this is the version of
Ant all (well, most) other projects depend upon.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: NSUML and bootstrapping
Posted by Sam Ruby <ru...@intertwingly.net>.
dion@multitask.com.au wrote:
>
> Bootstrapping maven is fairly lean. It just uses ant and jaxp. The
> bootstrap process does download the jars needed to compile and build maven
> though. How does ant get built? xml-commons produces JAXP, and there's a
> circular dependency between it and ant, right?
These days, there is a version of jaxp in the JDK. So Ant should only
depend on the JDK.
I don't want to verify that maven builds against the version of its
dependencies that it choses to download, I want to verify that maven can
be built against the version of the dependencies I have built. So, in
other words, I want to employ the "jar override feature" that you
describe below during the bootstrap process itself.
> This is known as the jar override feature. If maven.jar.override is set to
> true, then maven looks for a property that tells it the location of that
> jar file. i.e. if maven.jar.override=true and maven is looking for 'ant',
> it gets the absolute location for the ant jar from the value of the
> property 'maven.jar.ant'. We'd need a mapping between gump's project id
> and maven's.
>
> Though, it should be easy enough to get gump to set up properties for the
> various jars :)
Sounds doable.
>>3) there also is the issue of ordering maven builds. Between Maven and
>>Gump, somebody would need to understand enough of maven's project
>>descriptors to order the compilations of projects.
>
> I figure between the two of us we should be able to do it.
+1
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: NSUML and bootstrapping
Posted by di...@multitask.com.au.
Sam Ruby <ru...@intertwingly.net> wrote on 02/01/2003 12:50:03 PM:
> dion@multitask.com.au wrote:
> >
> > I know there's no descriptor for nsuml, but I thought it better to get
> > graph in and work on the next thing, rather than do it all at once.
> > I've been running gump on my laptop as well, but you'll notice from
posts
> > that it's been a little problematic.
>
> Putting in a descriptor with an unresolved dependency means that that
> component is not built.
Yep, but since the descriptor wasn't there before, does it hurt? It would
be better, I thought, to have the descriptor there at least and once we
get nsuml added, away it goes. Is there some reason I've missed for not
putting the descriptor there?
> 1) first we need maven itself to be built successfully. Just like we
> bootstrap ant itself and then use that version of ant for the rest of
> the builds, I'd like to always use the latest maven.
>
> 1a) as a corrolary to (1), it would be nice to have a lean core version
> of maven. As it stands now, maven depends on an awful lot, which means
> that those things it depends on directly or indirectly would need to
> have static descriptors.
Bootstrapping maven is fairly lean. It just uses ant and jaxp. The
bootstrap process does download the jars needed to compile and build maven
though. How does ant get built? xml-commons produces JAXP, and there's a
circular dependency between it and ant, right?
> 2) maven has its own ideas of what versions of dependencies are to be
> used. There needs to be a way to specify to maven to never use the jars
> provided or to download jars. All other maven functions, however, can
> work as is.
This is known as the jar override feature. If maven.jar.override is set to
true, then maven looks for a property that tells it the location of that
jar file. i.e. if maven.jar.override=true and maven is looking for 'ant',
it gets the absolute location for the ant jar from the value of the
property 'maven.jar.ant'. We'd need a mapping between gump's project id
and maven's.
Though, it should be easy enough to get gump to set up properties for the
various jars :)
> 3) there also is the issue of ordering maven builds. Between Maven and
> Gump, somebody would need to understand enough of maven's project
> descriptors to order the compilations of projects.
I figure between the two of us we should be able to do it.
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: NSUML and bootstrapping
Posted by di...@multitask.com.au.
Sam Ruby <ru...@intertwingly.net> wrote on 02/01/2003 12:50:03 PM:
> dion@multitask.com.au wrote:
> >
> > I know there's no descriptor for nsuml, but I thought it better to get
> > graph in and work on the next thing, rather than do it all at once.
> > I've been running gump on my laptop as well, but you'll notice from
posts
> > that it's been a little problematic.
>
> Putting in a descriptor with an unresolved dependency means that that
> component is not built.
Yep, but since the descriptor wasn't there before, does it hurt? It would
be better, I thought, to have the descriptor there at least and once we
get nsuml added, away it goes. Is there some reason I've missed for not
putting the descriptor there?
> 1) first we need maven itself to be built successfully. Just like we
> bootstrap ant itself and then use that version of ant for the rest of
> the builds, I'd like to always use the latest maven.
>
> 1a) as a corrolary to (1), it would be nice to have a lean core version
> of maven. As it stands now, maven depends on an awful lot, which means
> that those things it depends on directly or indirectly would need to
> have static descriptors.
Bootstrapping maven is fairly lean. It just uses ant and jaxp. The
bootstrap process does download the jars needed to compile and build maven
though. How does ant get built? xml-commons produces JAXP, and there's a
circular dependency between it and ant, right?
> 2) maven has its own ideas of what versions of dependencies are to be
> used. There needs to be a way to specify to maven to never use the jars
> provided or to download jars. All other maven functions, however, can
> work as is.
This is known as the jar override feature. If maven.jar.override is set to
true, then maven looks for a property that tells it the location of that
jar file. i.e. if maven.jar.override=true and maven is looking for 'ant',
it gets the absolute location for the ant jar from the value of the
property 'maven.jar.ant'. We'd need a mapping between gump's project id
and maven's.
Though, it should be easy enough to get gump to set up properties for the
various jars :)
> 3) there also is the issue of ordering maven builds. Between Maven and
> Gump, somebody would need to understand enough of maven's project
> descriptors to order the compilations of projects.
I figure between the two of us we should be able to do it.
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
Re: NSUML and bootstrapping
Posted by Sam Ruby <ru...@intertwingly.net>.
dion@multitask.com.au wrote:
>
> I know there's no descriptor for nsuml, but I thought it better to get
> graph in and work on the next thing, rather than do it all at once.
> I've been running gump on my laptop as well, but you'll notice from posts
> that it's been a little problematic.
Putting in a descriptor with an unresolved dependency means that that
component is not built.
> But it kinda makes me wonder why we are trying to get a gump descriptor
> generated for maven projects that runs ant, rather than gump bootstrapping
>
> maven and adding a 'maven' tag to the project definition.
>
> comments?
That would be an excellent goal. A few things to work on...
1) first we need maven itself to be built successfully. Just like we
bootstrap ant itself and then use that version of ant for the rest of
the builds, I'd like to always use the latest maven.
1a) as a corrolary to (1), it would be nice to have a lean core version
of maven. As it stands now, maven depends on an awful lot, which means
that those things it depends on directly or indirectly would need to
have static descriptors.
2) maven has its own ideas of what versions of dependencies are to be
used. There needs to be a way to specify to maven to never use the jars
provided or to download jars. All other maven functions, however, can
work as is.
3) there also is the issue of ordering maven builds. Between Maven and
Gump, somebody would need to understand enough of maven's project
descriptors to order the compilations of projects.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: NSUML and bootstrapping
Posted by Sam Ruby <ru...@intertwingly.net>.
dion@multitask.com.au wrote:
>
> I know there's no descriptor for nsuml, but I thought it better to get
> graph in and work on the next thing, rather than do it all at once.
> I've been running gump on my laptop as well, but you'll notice from posts
> that it's been a little problematic.
Putting in a descriptor with an unresolved dependency means that that
component is not built.
> But it kinda makes me wonder why we are trying to get a gump descriptor
> generated for maven projects that runs ant, rather than gump bootstrapping
>
> maven and adding a 'maven' tag to the project definition.
>
> comments?
That would be an excellent goal. A few things to work on...
1) first we need maven itself to be built successfully. Just like we
bootstrap ant itself and then use that version of ant for the rest of
the builds, I'd like to always use the latest maven.
1a) as a corrolary to (1), it would be nice to have a lean core version
of maven. As it stands now, maven depends on an awful lot, which means
that those things it depends on directly or indirectly would need to
have static descriptors.
2) maven has its own ideas of what versions of dependencies are to be
used. There needs to be a way to specify to maven to never use the jars
provided or to download jars. All other maven functions, however, can
work as is.
3) there also is the issue of ordering maven builds. Between Maven and
Gump, somebody would need to understand enough of maven's project
descriptors to order the compilations of projects.
- Sam Ruby