You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Morgan Delagrange <md...@yahoo.com> on 2003/01/03 23:01:57 UTC
[Jelly] GUMPifying taglib builds
Hey all,
In my short experience with requesting updates to the
Maven repository, it seems to take hours if not days.
Therefore I'm hoping to get the taglib builds up and
running on GUMP. I autogenerated build.xml and
gump.xml files for the six existing taglibs. Once the
core build is working, I'd like to hook up these
taglibs to it, plus any other taglib builds we create
in the meantime.
- Morgan
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] GUMPifying taglib builds
Posted by Morgan Delagrange <md...@yahoo.com>.
--- Sam Ruby <ru...@apache.org> wrote:
> Morgan Delagrange wrote:
> >
> > Excellent. Can you give me karma please?
>
> http://jakarta.apache.org/gump/faq.html#8
>
> - Sam Ruby
Ah, just so. You tried to show me that before, and I
thought you were pointing me to the nag email section.
OK, I'm on it.
- Morgan
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] GUMPifying taglib builds
Posted by Sam Ruby <ru...@apache.org>.
Morgan Delagrange wrote:
>
> Excellent. Can you give me karma please?
http://jakarta.apache.org/gump/faq.html#8
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] GUMPifying taglib builds and [gump] plugin
Posted by di...@multitask.com.au.
news <ne...@main.gmane.org> wrote on 04/01/2003 09:18:02 AM:
> My experience with the autogenerated gump descriptors is that they
> require some by hand cleanup. Try generating a gump descriptor for
> jakarta-turbine-fulcrum, and compare it to
>
>
http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-gump/project/jakarta-turbine-fulcrum.xml?rev=1.33&sortby=date
Ok, I will do. I want to make sure the Gump descriptor for maven is a
workable, correct document.
Here are the relevant bits of the diff:
-<module name="fulcrum">
+<module name="jakarta-turbine-fulcrum">
This can be fixed by having a map in the gump plugin of maven project ids
-> gump project id's
- <project name="fulcrum">
+ <project name="jakarta-turbine-fulcrum">
Same story here
- <depend project="avalon-framework">
+ <depend project="jakarta-avalon">
Ditto
- <depend project="log4j">
+ <depend project="jakarta-log4j">
Ditto
- <depend project="logkit">
+ <depend project="jakarta-avalon-logkit">
Ditto
- <depend project="regexp">
+ <depend project="jakarta-regexp">
Ditto
- <depend project="servletapi">
+ <depend project="jakarta-servletapi">
Ditto
- <depend project="stratum">
+ <depend project="jakarta-turbine-stratum">
Ditto
- <depend project="torque">
+ <depend project="jakarta-turbine-torque">
Ditto
- <depend project="velocity">
+ <depend project="jakarta-velocity">
Ditto
- <depend project="velocity-dvsl">
+ <depend project="jakarta-velocity-dvsl">
Ditto
- <depend project="xalan">
+ <depend project="xml-xalan2">
Ditto
- <depend project="xerces">
+ <depend project="xml-xerces">
Ditto
- <depend project="xmlrpc">
+ <depend project="xml-rpc">
Ditto
> If the jelly taglibs descriptors are put into the gump cvs repository,
> I'll gladly get them working.
Can you please let me know what you did to get it working, so we can feed
it back into the gump plugin?
--
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: [maven] maven -> gump project conversion
Posted by Leo Simons <le...@apache.org>.
>>Most of the excalibur "blades" *are* built by gump.
>
> Do you have details? I couldn't find the ones there.
http://cvs.apache.org/viewcvs.cgi/jakarta-avalon-excalibur/project-info.xml
and also
http://cvs.apache.org/viewcvs.cgi/jakarta-gump/project/avalon-sandbox.xml
cheers!
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [maven] maven -> gump project conversion
Posted by di...@multitask.com.au.
Sam Ruby <ru...@intertwingly.net> wrote on 05/01/2003 12:24:50 AM:
> dion@multitask.com.au wrote:
> >
> > I've done what looks like a first attempt at mapping the maven project
ids
> > to gump projects.
> >
> > Could you please check it out, especially the one's I've marked "not
built
> > by gump" and let me know of any others?
> >
> > You can find it here:
> >
> > http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-
> maven/src/plugins-build/gump/maven2gump.properties?rev=1.3&content-
> type=text/vnd.viewcvs-markup
> >
> > With this, the fulcrum descriptor turns out right.
>
> BSF looks problematic. Most still use "bsf" for now. Some use
> "jakarta-bsf". Both are different codebases (renamed packages, for
> starters).
Changed.
> servletapi has a related issue due to versioning. To a smaller extent,
> cactus shares this.
Maven allows various jars on a per 'project' basis. Gump does too. The
difference is that Gump classifies by cvs repository, rather than content,
if I'm reading it right.
> Most of the excalibur "blades" *are* built by gump.
Do you have details? I couldn't find the ones there.
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
Re: [maven] maven -> gump project conversion
Posted by di...@multitask.com.au.
Sam Ruby <ru...@intertwingly.net> wrote on 05/01/2003 12:24:50 AM:
> dion@multitask.com.au wrote:
> >
> > I've done what looks like a first attempt at mapping the maven project
ids
> > to gump projects.
> >
> > Could you please check it out, especially the one's I've marked "not
built
> > by gump" and let me know of any others?
> >
> > You can find it here:
> >
> > http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-
> maven/src/plugins-build/gump/maven2gump.properties?rev=1.3&content-
> type=text/vnd.viewcvs-markup
> >
> > With this, the fulcrum descriptor turns out right.
>
> BSF looks problematic. Most still use "bsf" for now. Some use
> "jakarta-bsf". Both are different codebases (renamed packages, for
> starters).
Changed.
> servletapi has a related issue due to versioning. To a smaller extent,
> cactus shares this.
Maven allows various jars on a per 'project' basis. Gump does too. The
difference is that Gump classifies by cvs repository, rather than content,
if I'm reading it right.
> Most of the excalibur "blades" *are* built by gump.
Do you have details? I couldn't find the ones there.
--
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: [maven] maven -> gump project conversion
Posted by Sam Ruby <ru...@intertwingly.net>.
dion@multitask.com.au wrote:
>
> I've done what looks like a first attempt at mapping the maven project ids
> to gump projects.
>
> Could you please check it out, especially the one's I've marked "not built
> by gump" and let me know of any others?
>
> You can find it here:
>
> http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-maven/src/plugins-build/gump/maven2gump.properties?rev=1.3&content-type=text/vnd.viewcvs-markup
>
> With this, the fulcrum descriptor turns out right.
BSF looks problematic. Most still use "bsf" for now. Some use
"jakarta-bsf". Both are different codebases (renamed packages, for
starters).
servletapi has a related issue due to versioning. To a smaller extent,
cactus shares this.
Most of the excalibur "blades" *are* built by gump.
> Also, is there a naming convention in the gump project names? For Jakarta
> and xml repositories it appears that the repo is prefixed, but for
> sourceforge, werken this doesn't appear to be happening.
Gump typically uses the name one uses to check out the source, for
example, "jakarta-ant" and "werken". For subprojects, the parent is
typically shortened to the last token.
- Sam Ruby
Re: [maven] maven -> gump project conversion
Posted by Sam Ruby <ru...@intertwingly.net>.
dion@multitask.com.au wrote:
>
> I've done what looks like a first attempt at mapping the maven project ids
> to gump projects.
>
> Could you please check it out, especially the one's I've marked "not built
> by gump" and let me know of any others?
>
> You can find it here:
>
> http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-maven/src/plugins-build/gump/maven2gump.properties?rev=1.3&content-type=text/vnd.viewcvs-markup
>
> With this, the fulcrum descriptor turns out right.
BSF looks problematic. Most still use "bsf" for now. Some use
"jakarta-bsf". Both are different codebases (renamed packages, for
starters).
servletapi has a related issue due to versioning. To a smaller extent,
cactus shares this.
Most of the excalibur "blades" *are* built by gump.
> Also, is there a naming convention in the gump project names? For Jakarta
> and xml repositories it appears that the repo is prefixed, but for
> sourceforge, werken this doesn't appear to be happening.
Gump typically uses the name one uses to check out the source, for
example, "jakarta-ant" and "werken". For subprojects, the parent is
typically shortened to the last token.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[maven] maven -> gump project conversion
Posted by di...@multitask.com.au.
news <ne...@main.gmane.org> wrote on 04/01/2003 09:18:02 AM:
> My experience with the autogenerated gump descriptors is that they
> require some by hand cleanup. Try generating a gump descriptor for
> jakarta-turbine-fulcrum, and compare it to
>
> http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-
> gump/project/jakarta-turbine-fulcrum.xml?rev=1.33&sortby=date
Sam,
I've done what looks like a first attempt at mapping the maven project ids
to gump projects.
Could you please check it out, especially the one's I've marked "not built
by gump" and let me know of any others?
You can find it here:
http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-maven/src/plugins-build/gump/maven2gump.properties?rev=1.3&content-type=text/vnd.viewcvs-markup
With this, the fulcrum descriptor turns out right.
Also, is there a naming convention in the gump project names? For Jakarta
and xml repositories it appears that the repo is prefixed, but for
sourceforge, werken this doesn't appear to be happening.
--
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: [Jelly] GUMPifying taglib builds and [gump] plugin
Posted by di...@multitask.com.au.
news <ne...@main.gmane.org> wrote on 04/01/2003 09:18:02 AM:
> My experience with the autogenerated gump descriptors is that they
> require some by hand cleanup. Try generating a gump descriptor for
> jakarta-turbine-fulcrum, and compare it to
>
>
http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-gump/project/jakarta-turbine-fulcrum.xml?rev=1.33&sortby=date
Ok, I will do. I want to make sure the Gump descriptor for maven is a
workable, correct document.
Here are the relevant bits of the diff:
-<module name="fulcrum">
+<module name="jakarta-turbine-fulcrum">
This can be fixed by having a map in the gump plugin of maven project ids
-> gump project id's
- <project name="fulcrum">
+ <project name="jakarta-turbine-fulcrum">
Same story here
- <depend project="avalon-framework">
+ <depend project="jakarta-avalon">
Ditto
- <depend project="log4j">
+ <depend project="jakarta-log4j">
Ditto
- <depend project="logkit">
+ <depend project="jakarta-avalon-logkit">
Ditto
- <depend project="regexp">
+ <depend project="jakarta-regexp">
Ditto
- <depend project="servletapi">
+ <depend project="jakarta-servletapi">
Ditto
- <depend project="stratum">
+ <depend project="jakarta-turbine-stratum">
Ditto
- <depend project="torque">
+ <depend project="jakarta-turbine-torque">
Ditto
- <depend project="velocity">
+ <depend project="jakarta-velocity">
Ditto
- <depend project="velocity-dvsl">
+ <depend project="jakarta-velocity-dvsl">
Ditto
- <depend project="xalan">
+ <depend project="xml-xalan2">
Ditto
- <depend project="xerces">
+ <depend project="xml-xerces">
Ditto
- <depend project="xmlrpc">
+ <depend project="xml-rpc">
Ditto
> If the jelly taglibs descriptors are put into the gump cvs repository,
> I'll gladly get them working.
Can you please let me know what you did to get it working, so we can feed
it back into the gump plugin?
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
Re: [Jelly] GUMPifying taglib builds
Posted by Morgan Delagrange <md...@yahoo.com>.
--- Sam Ruby <ru...@apache.org> wrote:
> Morgan Delagrange wrote:
> > Hey all,
> >
> > In my short experience with requesting updates to
> the
> > Maven repository, it seems to take hours if not
> days.
> > Therefore I'm hoping to get the taglib builds up
> and
> > running on GUMP. I autogenerated build.xml and
> > gump.xml files for the six existing taglibs. Once
> the
> > core build is working, I'd like to hook up these
> > taglibs to it, plus any other taglib builds we
> create
> > in the meantime.
>
> My experience with the autogenerated gump
> descriptors is that they
> require some by hand cleanup. Try generating a gump
> descriptor for
> jakarta-turbine-fulcrum, and compare it to
>
>
http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-gump/project/jakarta-turbine-fulcrum.xml?rev=1.33&sortby=date
>
> If the jelly taglibs descriptors are put into the
> gump cvs repository,
> I'll gladly get them working.
Excellent. Can you give me karma please? Then I'll
clean them up as best I can and move them over. You
want me to do it now or wait until we have a
successful build of the core classes?
- Morgan
> The jars produced by any successful build are
> automatically placed at
>
> http://gump.covalent.net/jars/
>
> - Sam Ruby
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[maven] maven -> gump project conversion
Posted by di...@multitask.com.au.
news <ne...@main.gmane.org> wrote on 04/01/2003 09:18:02 AM:
> My experience with the autogenerated gump descriptors is that they
> require some by hand cleanup. Try generating a gump descriptor for
> jakarta-turbine-fulcrum, and compare it to
>
> http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-
> gump/project/jakarta-turbine-fulcrum.xml?rev=1.33&sortby=date
Sam,
I've done what looks like a first attempt at mapping the maven project ids
to gump projects.
Could you please check it out, especially the one's I've marked "not built
by gump" and let me know of any others?
You can find it here:
http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-maven/src/plugins-build/gump/maven2gump.properties?rev=1.3&content-type=text/vnd.viewcvs-markup
With this, the fulcrum descriptor turns out right.
Also, is there a naming convention in the gump project names? For Jakarta
and xml repositories it appears that the repo is prefixed, but for
sourceforge, werken this doesn't appear to be happening.
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
Re: [Jelly] GUMPifying taglib builds
Posted by Sam Ruby <ru...@apache.org>.
Morgan Delagrange wrote:
> Hey all,
>
> In my short experience with requesting updates to the
> Maven repository, it seems to take hours if not days.
> Therefore I'm hoping to get the taglib builds up and
> running on GUMP. I autogenerated build.xml and
> gump.xml files for the six existing taglibs. Once the
> core build is working, I'd like to hook up these
> taglibs to it, plus any other taglib builds we create
> in the meantime.
My experience with the autogenerated gump descriptors is that they
require some by hand cleanup. Try generating a gump descriptor for
jakarta-turbine-fulcrum, and compare it to
http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-gump/project/jakarta-turbine-fulcrum.xml?rev=1.33&sortby=date
If the jelly taglibs descriptors are put into the gump cvs repository,
I'll gladly get them working.
The jars produced by any successful build are automatically placed at
http://gump.covalent.net/jars/
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] GUMPifying taglib builds
Posted by di...@multitask.com.au.
"James Strachan" <ja...@yahoo.co.uk> wrote on 04/01/2003 08:59:24
PM:
> We do need to make it easier for folks to upload jars to the shared
repo;
Agreed.
> maybe more administrators is the answer. Though a webapp or script to do
it
> would be good.
There are scripts.... in src/admin in the maven repo.
> BTW many thanks to Morgan, Sam and Dion for helping to sort out he gump
> build for jelly! I'll have time next week to dive in and help clear up
any
> loose ends.
Yep, my thanks esp to Morgan for the hard work. We're getting there!
--
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: [Jelly] GUMPifying taglib builds
Posted by James Strachan <ja...@yahoo.co.uk>.
From: <di...@multitask.com.au>
> Morgan Delagrange <md...@yahoo.com> wrote on 04/01/2003 06:28:47 PM:
> > --- dion@multitask.com.au wrote:
> > > Morgan Delagrange <md...@yahoo.com> wrote on
> > > 04/01/2003 09:01:57 AM:
> > >
> > > > Hey all,
> > > >
> > > > In my short experience with requesting updates to
> > > the
> > > > Maven repository, it seems to take hours if not
> > > days.
> > > Owwww....I was asleep!
> > >
> >
> > Boy, you Maven folks are deep sleepers:
> >
> >
> > http://marc.theaimsgroup.com/?l=turbine-maven-dev&m=104155973415577&w=2
> > http://www.ibiblio.org/maven/commons-jelly/jars/
> >
> > Hello, is anybody home?
> Hello, did you give us the jar file in the right format?
>
> > All irony aside, the obvious point is that until we
> > can effect our own immediate Maven repository
> > gratification, Maven's still kind of crappy for
> > refactoring. GUMP, while not immediate, is a definite
> Ah, dump the SNAPSHOT in your *local* repository if you want to refactor
> and test something. It doesn't need to be in the remote repo unless you're
> committing the project descriptor publicly and have tested it.
We do need to make it easier for folks to upload jars to the shared repo;
maybe more administrators is the answer. Though a webapp or script to do it
would be good.
FWIW Morgan if ever uploading a jar is slowing you down, as Dion said you
can just modify your own local repository
e.g. 'maven jar:install' will install your local build of a jar in your
local repository.
or in an emergency you can create your own shared repository area by
defining the property...
maven.repo.remote=http://www.ibiblio.org/maven/,http://www.apache.org/~morga
nd/myrepo
BTW many thanks to Morgan, Sam and Dion for helping to sort out he gump
build for jelly! I'll have time next week to dive in and help clear up any
loose ends.
James
-------
http://radio.weblogs.com/0112098/
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] GUMPifying taglib builds
Posted by di...@multitask.com.au.
Morgan Delagrange <md...@yahoo.com> wrote on 05/01/2003 02:07:15 PM:
> Cool I'll use the jar:snapshot goal from now on when I
> send to the Maven list. It sounds like it's going to
> work better if I just use jar:install, and you can
> update the remote JARs on your own.
I'm happy to get the taglibs built off source from here, so that we have
two verifications it works.
> I'm having trouble getting jar:install to work with
> intra-project dependencies though. I tried using the
> <project_name>+<plugin_name> syntax for the ids of the
> taglibs, like this:
>
> <project>
> <pomVersion>3</pomVersion>
> <name>commons-jelly-tags-ant</name>
> <id>commons-jelly+tags-ant</id>
Yep, use:
<groupId>commons-jelly</groupId>
<id>commons-jelly-tags-ant</id>
> <currentVersion>SNAPSHOT</currentVersion>
Really should be
<currentVersion>1.0-SNAPSHOT</currentVersion>
> Am I doing something wrong, or does the plus syntax
> only work for the id of "dependency" tags? If so,
> does that mean I have to manually copy the libraries
> to my local repository?
Nope, you're not doing anything wrong. Add the groupId and the install
works fine.
But really the groupId should be automatically part of the jar name.
By copy to maven-dev:
Jason,
is this the way we want 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: [Jelly] GUMPifying taglib builds
Posted by di...@multitask.com.au.
Morgan Delagrange <md...@yahoo.com> wrote on 05/01/2003 02:07:15 PM:
> Cool I'll use the jar:snapshot goal from now on when I
> send to the Maven list. It sounds like it's going to
> work better if I just use jar:install, and you can
> update the remote JARs on your own.
I'm happy to get the taglibs built off source from here, so that we have
two verifications it works.
> I'm having trouble getting jar:install to work with
> intra-project dependencies though. I tried using the
> <project_name>+<plugin_name> syntax for the ids of the
> taglibs, like this:
>
> <project>
> <pomVersion>3</pomVersion>
> <name>commons-jelly-tags-ant</name>
> <id>commons-jelly+tags-ant</id>
Yep, use:
<groupId>commons-jelly</groupId>
<id>commons-jelly-tags-ant</id>
> <currentVersion>SNAPSHOT</currentVersion>
Really should be
<currentVersion>1.0-SNAPSHOT</currentVersion>
> Am I doing something wrong, or does the plus syntax
> only work for the id of "dependency" tags? If so,
> does that mean I have to manually copy the libraries
> to my local repository?
Nope, you're not doing anything wrong. Add the groupId and the install
works fine.
But really the groupId should be automatically part of the jar name.
By copy to maven-dev:
Jason,
is this the way we want it?
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
Re: [Jelly] GUMPifying taglib builds
Posted by Morgan Delagrange <md...@yahoo.com>.
--- dion@multitask.com.au wrote:
> Morgan Delagrange <md...@yahoo.com> wrote on
> 05/01/2003 05:28:13 AM:
> > > > Hello, is anybody home?
> > > Hello, did you give us the jar file in the right
> > > format?
> >
> > You mean, besides JAR? I didn't know there was
> one.
> > Point me to the documentation and I'll make sure I
> get
> > it right in the future.
>
> If you want a SNAPSHOT jar to go onto ibiblio, it
> should have this format:
>
> ${project.id}-YYYYMMDD.hhmmss.jar where
> id - taken from the project.xml of the project being
> built , e.g.
> commons-jelly
> YYYYMMDD - The current year in 8 digit format
> hhmmss - the current time in 6 digit format
>
>
> See
>
http://jakarta.apache.org/turbine/maven/reference/plugins/java/goals.html
>
> for more info.
>
Cool I'll use the jar:snapshot goal from now on when I
send to the Maven list. It sounds like it's going to
work better if I just use jar:install, and you can
update the remote JARs on your own.
I'm having trouble getting jar:install to work with
intra-project dependencies though. I tried using the
<project_name>+<plugin_name> syntax for the ids of the
taglibs, like this:
<project>
<pomVersion>3</pomVersion>
<name>commons-jelly-tags-ant</name>
<id>commons-jelly+tags-ant</id>
<currentVersion>SNAPSHOT</currentVersion>
...
but it didn't look produce the output I expected when
I ran jar:install (I expected it to write a jar to
commons-jelly/jars):
java:jar:
[touch] Creating C:\cvsrep\jakarta-commons-
sandbox\jelly\jelly-tags\ant\target\Manifest.mf
[jar] Building jar: C:\cvsrep\jakarta-commons-
sandbox\jelly\jelly-tags\ant\target\commons-
jelly+tags-ant-SNAPSHOT.jar
jar:install:
[copy] Copying 1 file to c:\lib\maven-1.0-beta-7\
repository\commons-jelly+tags-ant\jars
Am I doing something wrong, or does the plus syntax
only work for the id of "dependency" tags? If so,
does that mean I have to manually copy the libraries
to my local repository?
- Morgan
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] GUMPifying taglib builds
Posted by di...@multitask.com.au.
Morgan Delagrange <md...@yahoo.com> wrote on 05/01/2003 05:28:13 AM:
> > > Hello, is anybody home?
> > Hello, did you give us the jar file in the right
> > format?
>
> You mean, besides JAR? I didn't know there was one.
> Point me to the documentation and I'll make sure I get
> it right in the future.
If you want a SNAPSHOT jar to go onto ibiblio, it should have this format:
${project.id}-YYYYMMDD.hhmmss.jar where
id - taken from the project.xml of the project being built , e.g.
commons-jelly
YYYYMMDD - The current year in 8 digit format
hhmmss - the current time in 6 digit format
See
http://jakarta.apache.org/turbine/maven/reference/plugins/java/goals.html
for more info.
> What's a local repository? I'll try that jar:install
> command James mentioned, see what that does.
It's the repository of jars on your hard disk Maven creates. Typically
$MAVEN_HOME/repository.
> > Remember lots of people *need* that jar to be
> > viable.
>
> Four developers are in the midst of refactoring Jelly.
> Sounds viable to me.
A 'SNAPSHOT' jar is downloaded by Maven if it changes in the remote repo
(ibiblio). So if the commons-jelly-SNAPSHOT.jar was screwed, and a maven
user runs a build, they'll get the newer, possibly screwed, version. I'm
just saying we need to be careful about what gets deployed.
> Anyway, I think I've succeeded in lighting a fire
> undeer somebody and getting some information about how
> all this works, so mission accomplished. I'll avoid
> asking for updates to the Maven repository until I
> divine the correct format and write something
> "viable".
Hopefully this helps. I'm ready and willing to answer questions about
maven and ibiblio stuff anytime you need.
I'm in a strange timezone for you though, so bear with me.
I really don't need a fire lit under me, just gentle prodding every now
and again :)
--
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: [Jelly] GUMPifying taglib builds
Posted by Morgan Delagrange <md...@yahoo.com>.
--- dion@multitask.com.au wrote:
> Morgan Delagrange <md...@yahoo.com> wrote on
> 04/01/2003 06:28:47 PM:
>
> >
> > --- dion@multitask.com.au wrote:
> > > Morgan Delagrange <md...@yahoo.com> wrote on
> > > 04/01/2003 09:01:57 AM:
> > >
> > > > Hey all,
> > > >
> > > > In my short experience with requesting updates
> to
> > > the
> > > > Maven repository, it seems to take hours if
> not
> > > days.
> > > Owwww....I was asleep!
> > >
> >
> > Boy, you Maven folks are deep sleepers:
> >
> >
> >
>
http://marc.theaimsgroup.com/?l=turbine-maven-dev&m=104155973415577&w=2
> > http://www.ibiblio.org/maven/commons-jelly/jars/
> >
> > Hello, is anybody home?
> Hello, did you give us the jar file in the right
> format?
You mean, besides JAR? I didn't know there was one.
Point me to the documentation and I'll make sure I get
it right in the future.
> > All irony aside, the obvious point is that until
> we
> > can effect our own immediate Maven repository
> > gratification, Maven's still kind of crappy for
> > refactoring. GUMP, while not immediate, is a
> definite
> Ah, dump the SNAPSHOT in your *local* repository if
> you want to refactor
> and test something. It doesn't need to be in the
> remote repo unless you're
> committing the project descriptor publicly and have
> tested it.
What's a local repository? I'll try that jar:install
command James mentioned, see what that does.
> Remember lots of people *need* that jar to be
> viable.
Four developers are in the midst of refactoring Jelly.
Sounds viable to me.
> > improvement and has the added benefit of catching
> > problems in the HEAD versions of dependencies. As
> far
> > as Maven is concerned, betwixt, html, http, jeez,
> > jetty, and swing are all still in the core Jelly
> > library. Therefore it's quite possible that there
> are
> > as-yet undiagnosed problems in my refactoring.
> Why are they still there?
Because they're undiagnosed? If they were diagnosed,
I would try to fix them.
Anyway, I think I've succeeded in lighting a fire
undeer somebody and getting some information about how
all this works, so mission accomplished. I'll avoid
asking for updates to the Maven repository until I
divine the correct format and write something
"viable".
- Morgan
> --
> 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>
>
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] GUMPifying taglib builds
Posted by di...@multitask.com.au.
Morgan Delagrange <md...@yahoo.com> wrote on 04/01/2003 06:28:47 PM:
>
> --- dion@multitask.com.au wrote:
> > Morgan Delagrange <md...@yahoo.com> wrote on
> > 04/01/2003 09:01:57 AM:
> >
> > > Hey all,
> > >
> > > In my short experience with requesting updates to
> > the
> > > Maven repository, it seems to take hours if not
> > days.
> > Owwww....I was asleep!
> >
>
> Boy, you Maven folks are deep sleepers:
>
>
> http://marc.theaimsgroup.com/?l=turbine-maven-dev&m=104155973415577&w=2
> http://www.ibiblio.org/maven/commons-jelly/jars/
>
> Hello, is anybody home?
Hello, did you give us the jar file in the right format?
> All irony aside, the obvious point is that until we
> can effect our own immediate Maven repository
> gratification, Maven's still kind of crappy for
> refactoring. GUMP, while not immediate, is a definite
Ah, dump the SNAPSHOT in your *local* repository if you want to refactor
and test something. It doesn't need to be in the remote repo unless you're
committing the project descriptor publicly and have tested it.
Remember lots of people *need* that jar to be viable.
> improvement and has the added benefit of catching
> problems in the HEAD versions of dependencies. As far
> as Maven is concerned, betwixt, html, http, jeez,
> jetty, and swing are all still in the core Jelly
> library. Therefore it's quite possible that there are
> as-yet undiagnosed problems in my refactoring.
Why are they still there?
--
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: [Jelly] GUMPifying taglib builds
Posted by Morgan Delagrange <md...@yahoo.com>.
--- dion@multitask.com.au wrote:
> Morgan Delagrange <md...@yahoo.com> wrote on
> 04/01/2003 09:01:57 AM:
>
> > Hey all,
> >
> > In my short experience with requesting updates to
> the
> > Maven repository, it seems to take hours if not
> days.
> Owwww....I was asleep!
>
Boy, you Maven folks are deep sleepers:
http://marc.theaimsgroup.com/?l=turbine-maven-dev&m=104155973415577&w=2
http://www.ibiblio.org/maven/commons-jelly/jars/
Hello, is anybody home?
All irony aside, the obvious point is that until we
can effect our own immediate Maven repository
gratification, Maven's still kind of crappy for
refactoring. GUMP, while not immediate, is a definite
improvement and has the added benefit of catching
problems in the HEAD versions of dependencies. As far
as Maven is concerned, betwixt, html, http, jeez,
jetty, and swing are all still in the core Jelly
library. Therefore it's quite possible that there are
as-yet undiagnosed problems in my refactoring.
- Morgan
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jelly] GUMPifying taglib builds
Posted by di...@multitask.com.au.
Morgan Delagrange <md...@yahoo.com> wrote on 04/01/2003 09:01:57 AM:
> Hey all,
>
> In my short experience with requesting updates to the
> Maven repository, it seems to take hours if not days.
Owwww....I was asleep!
> Therefore I'm hoping to get the taglib builds up and
> running on GUMP. I autogenerated build.xml and
> gump.xml files for the six existing taglibs. Once the
> core build is working, I'd like to hook up these
> taglibs to it, plus any other taglib builds we create
> in the meantime.
+1. Sounds good to me.
--
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>