You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Steve Cohen <sc...@javactivity.org> on 2005/11/22 04:24:33 UTC
[vote][net] Release commons-net 1.4.1?
It has been discovered that 1.4.0 is inadvertently incompatible with jdk
1.3. Please vote on a release of a fixed version.
I'll start it off
+1
I will also volunteer to do the release but it won't be until next week
at the earliest.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by Dion Gillard <di...@gmail.com>.
+1
On 11/22/05, Steve Cohen <sc...@javactivity.org> wrote:
> It has been discovered that 1.4.0 is inadvertently incompatible with jdk
> 1.3. Please vote on a release of a fixed version.
>
> I'll start it off
> +1
>
> I will also volunteer to do the release but it won't be until next week
> at the earliest.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
http://www.multitask.com.au/people/dion/
"You are going to let the fear of poverty govern your life and your
reward will be that you will eat, but you will not live." - George
Bernard Shaw
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Mon, 2005-11-21 at 21:24 -0600, Steve Cohen wrote:
> It has been discovered that 1.4.0 is inadvertently incompatible with jdk
> 1.3. Please vote on a release of a fixed version.
+1
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
+1
Steve Cohen wrote:
> It has been discovered that 1.4.0 is inadvertently incompatible with jdk
> 1.3. Please vote on a release of a fixed version.
>
> I'll start it off
> +1
>
> I will also volunteer to do the release but it won't be until next week
> at the earliest.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
http://www.bloglines.com/blog/jbrekke ekkerbj@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by Dion Gillard <di...@gmail.com>.
[snip]
> As I have little time now, I propose the following. 1.4.1 will be just
> 1.4.0 with whatever changes are needed to reverse the dependency on jdk
> 1.4.x. No other bug fixes will be included.
>
> Re-vote
>
> +1 [yes]
> -1 [no]
+1.
--
http://www.multitask.com.au/people/dion/
"You are going to let the fear of poverty govern your life and your
reward will be that you will eat, but you will not live." - George
Bernard Shaw
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Sharing maven setup [was Re: HELP!]
Posted by Torsten Curdt <tc...@apache.org>.
>> I have in my mind that what we need is a commons maven plugin. It
>> would:
>
> +1
>
> I was thinking the exact same thing.
Same here :-)
cheers
--
Torsten
Re: [all] Sharing maven setup [was Re: HELP!]
Posted by Henri Yandell <fl...@gmail.com>.
On 12/5/05, Stephen Colebourne <sc...@btopenworld.com> wrote:
> >>I don't much like the idea of adding dependencies to each of the
> >>individual POMs, but understand that this makes the dependency
> >>explicit, which is a good thing. So I guess I am +0 for this
> >>approach. Actually +1 as in "will help" if others agree we should go
> >>this route instead of the updatePlugins approach.
> >
> > I'm more than happy with the updatePlugins approach. It's KISS at its best.
> > ;-)
> >
> > I remain -1 on reverting to extending the commons-build POM
>
> I agree that we should not extend the commons-build POM. However we
> could do with a way to share stuff.
>
> I have in my mind that what we need is a commons maven plugin. It would:
+1
I was thinking the exact same thing.
Maybe we can find some time to hack on it at the ApacheCon.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Sharing maven setup [was Re: HELP!]
Posted by Dennis Lundberg <de...@mdh.se>.
Phil Steitz wrote:
> Dennis,
>
> Thanks!! +1 for the commons-plugin. See comments interspersed. One
> thing to keep in mind is to try to keep it as simple as possible. I
> think we got a little too complicated in the site generation stuff and
> it has been a pain to maintain. Other nice-to-haves are ease of
> migration to maven 2 and reusability outside of commons (group of
> related, but independent projects wanting to share some common
> resources).
>
> On 12/5/05, Dennis Lundberg <de...@mdh.se> wrote:
> <snip>
>>>> I remain -1 on reverting to extending the commons-build POM
>>> I agree that we should not extend the commons-build POM. However we
>>> could do with a way to share stuff.
>
> Yes, the trick is how to do this while keeping projects self-contained.
Exactly.
>>> I have in my mind that what we need is a commons maven plugin. It would:
>>> - create target/commons
>>> - download commons-build within target/commons
>>> - update the local maven installation
>>> - merge the latest mandatory POM settings
>>> - merge the latest mandatory POM properties
>>> - merge the latest mandatory xdocs
>>>
>>> Thus, to push a site or release out you do:
>>> maven commons
>>> then any other command:
>>> maven ...
>>>
>>> This is probably a pipedream though, as I doubt anyone has the time to
>>> write this (ie. I don't!)
>> Yes, of course! A plugin is the way to go.
>>
>> Most people seems to agree that extending commons-build is a bad thing,
>> so we need to figure out a way to make each commons component
>> self-supporting.
>>
>> Imagine this directory structure in the commons component of your choice:
>>
>> /
>> +- commons-<component>/
>> +- site/
>> | +- menus/
>> | | +- ...
>> | +- parts/
>> | | +- ...
>> | +- commons-site.jsl
>> | +- cvsusage.xml
>> | +- ...
>> +- project.properties
>> +- project.xml
>> +- project-parent.xml
>>
>> First we make sure that every commons-component extends the *local*
>> project-parent.xml, see directory-structure above. This would be a
>> one-time job.
>>
>> If we then create a plugin that does the following, it might just work:
>>
>> - Download commons-build/project-parent.xml via anonymous SVN to
>> commons-<component>/project-parent.xml
>> - We would probably need to do something similar for project.properties,
>> I'm not sure how that would work though
>> - Download commons-build/site/menus/ , commons-build/site/parts/ et al
>> via anonymous SVN to commons-<component>/site/
>>
>> This way we don't have to think about merging xml documents and other
>> fancy stuff - just download some files from SVN.
>>
>> Does this sound at all possible?
>
> Definitiely sounds doable and reasonable to me; with the exception of
> the POM inheritance bit. I am not yet 100% convinced of the need for
> project-parent and I am not sure about the consequences of this from a
> maven repo standpoint. I don't know if you can inherit from an
> "abstract" POM or even if such a thing exists - i.e., IIUC your
> project-parent would have to have a groupID/artifactID and the local
> repo (and eventually apache/ibiblio) might get corrupted/confused, as
> this could change over time. The latter actually is the core of the
> issue - in order for the releases to be really self-contained, either
> we have to tag and version the common stuff with each component
> release, or they need to be able to essentially fork it (as they more
> or less do now).
My idea was to actually check in all of the common bits and pieces into
each and every commons-component. The job of keeping these bits updated
would be handled by the plugin. That way the tagging would be solved by
each component. It would mean a lot of copies of these common files, but
I don't see that as a problem.
We would need to add a mandatory step in the release cycle to run the
commons-plugin and check in the common files that have changed.
<snip/>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Sharing maven setup [was Re: HELP!]
Posted by Phil Steitz <ph...@gmail.com>.
Dennis,
Thanks!! +1 for the commons-plugin. See comments interspersed. One
thing to keep in mind is to try to keep it as simple as possible. I
think we got a little too complicated in the site generation stuff and
it has been a pain to maintain. Other nice-to-haves are ease of
migration to maven 2 and reusability outside of commons (group of
related, but independent projects wanting to share some common
resources).
On 12/5/05, Dennis Lundberg <de...@mdh.se> wrote:
<snip>
> >> I remain -1 on reverting to extending the commons-build POM
> >
> > I agree that we should not extend the commons-build POM. However we
> > could do with a way to share stuff.
Yes, the trick is how to do this while keeping projects self-contained.
> >
> > I have in my mind that what we need is a commons maven plugin. It would:
> > - create target/commons
> > - download commons-build within target/commons
> > - update the local maven installation
> > - merge the latest mandatory POM settings
> > - merge the latest mandatory POM properties
> > - merge the latest mandatory xdocs
> >
> > Thus, to push a site or release out you do:
> > maven commons
> > then any other command:
> > maven ...
> >
> > This is probably a pipedream though, as I doubt anyone has the time to
> > write this (ie. I don't!)
>
> Yes, of course! A plugin is the way to go.
>
> Most people seems to agree that extending commons-build is a bad thing,
> so we need to figure out a way to make each commons component
> self-supporting.
>
> Imagine this directory structure in the commons component of your choice:
>
> /
> +- commons-<component>/
> +- site/
> | +- menus/
> | | +- ...
> | +- parts/
> | | +- ...
> | +- commons-site.jsl
> | +- cvsusage.xml
> | +- ...
> +- project.properties
> +- project.xml
> +- project-parent.xml
>
> First we make sure that every commons-component extends the *local*
> project-parent.xml, see directory-structure above. This would be a
> one-time job.
>
> If we then create a plugin that does the following, it might just work:
>
> - Download commons-build/project-parent.xml via anonymous SVN to
> commons-<component>/project-parent.xml
> - We would probably need to do something similar for project.properties,
> I'm not sure how that would work though
> - Download commons-build/site/menus/ , commons-build/site/parts/ et al
> via anonymous SVN to commons-<component>/site/
>
> This way we don't have to think about merging xml documents and other
> fancy stuff - just download some files from SVN.
>
> Does this sound at all possible?
Definitiely sounds doable and reasonable to me; with the exception of
the POM inheritance bit. I am not yet 100% convinced of the need for
project-parent and I am not sure about the consequences of this from a
maven repo standpoint. I don't know if you can inherit from an
"abstract" POM or even if such a thing exists - i.e., IIUC your
project-parent would have to have a groupID/artifactID and the local
repo (and eventually apache/ibiblio) might get corrupted/confused, as
this could change over time. The latter actually is the core of the
issue - in order for the releases to be really self-contained, either
we have to tag and version the common stuff with each component
release, or they need to be able to essentially fork it (as they more
or less do now).
I do like the idea of copying in the commons-build pieces at build
time using the scm plugin or somesuch. That can help us untangle the
current navigation mess, among other things. To get around the
tagging / versioning problem, I have thought about suggesting in the
past that we check local copies into release branches and tag these as
part of releases. So, when working in trunk you do something like
what you have described above, but then when cutting a release, you
create an svn release branch that includes the local copies. These
then go into the release tag and you can later duplicate the release
from the tag. The plugin could support a branch goal that would
create the release branch with the local stuff in it.
>
> Should I have go at it? I have not made a plugin before, but there's a
> first time for everything...
>
Agree with Robert's comments below. I will chime in as time and
knowledge permits :-)
Have a look at the jdiff and changelog plugins for examples of how to
use the scm stuff.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Sharing maven setup [was Re: HELP!]
Posted by Dennis Lundberg <de...@mdh.se>.
robert burrell donkin wrote:
<snip/>
>> Does this sound at all possible?
>
> dunno :)
>
> probably a good idea to hook up with brett and the rest of the maveneers
> on IRC (if you can).
Will try to do that.
Can you recommend a good IRV client for Windows?
>> Should I have go at it? I have not made a plugin before, but there's a
>> first time for everything...
>
> +1
>
> but don't waste too much energy: better to let folks take a look at a
> quick proof of concept early.
Noted.
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Sharing maven setup [was Re: HELP!]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Mon, 2005-12-05 at 23:04 +0100, Dennis Lundberg wrote:
> Stephen Colebourne wrote:
> >>> I don't much like the idea of adding dependencies to each of the
> >>> individual POMs, but understand that this makes the dependency
> >>> explicit, which is a good thing. So I guess I am +0 for this
> >>> approach. Actually +1 as in "will help" if others agree we should go
> >>> this route instead of the updatePlugins approach.
> >>
> >> I'm more than happy with the updatePlugins approach. It's KISS at its
> >> best.
> >> ;-)
> >>
> >> I remain -1 on reverting to extending the commons-build POM
> >
> > I agree that we should not extend the commons-build POM. However we
> > could do with a way to share stuff.
> >
> > I have in my mind that what we need is a commons maven plugin. It would:
> > - create target/commons
> > - download commons-build within target/commons
> > - update the local maven installation
> > - merge the latest mandatory POM settings
> > - merge the latest mandatory POM properties
> > - merge the latest mandatory xdocs
> >
> > Thus, to push a site or release out you do:
> > maven commons
> > then any other command:
> > maven ...
> >
> > This is probably a pipedream though, as I doubt anyone has the time to
> > write this (ie. I don't!)
>
> Yes, of course! A plugin is the way to go.
+1
> Most people seems to agree that extending commons-build is a bad thing,
> so we need to figure out a way to make each commons component
> self-supporting.
i suspect that the opinion that this was a bad thing took hold in the
early days of maven after problems which didn't get fixed easily.
> Imagine this directory structure in the commons component of your choice:
>
> /
> +- commons-<component>/
> +- site/
> | +- menus/
> | | +- ...
> | +- parts/
> | | +- ...
> | +- commons-site.jsl
> | +- cvsusage.xml
> | +- ...
> +- project.properties
> +- project.xml
> +- project-parent.xml
>
> First we make sure that every commons-component extends the *local*
> project-parent.xml, see directory-structure above. This would be a
> one-time job.
partly due to my ISP losing the plot during this last week, i've been
playing around with the better ways to build modular projects using
maven and subversion. svn:external is very useful and powerful (in
combination with maven) but only works on directories. other folks (such
as axis2) use an etc directory.
so you might find:
+- commons-<component>/
+- site/
...
+- project.properties
+- project.xml
+- etc
+- project-parent.xml
works a little better
> If we then create a plugin that does the following, it might just work:
>
> - Download commons-build/project-parent.xml via anonymous SVN to
> commons-<component>/project-parent.xml
> - We would probably need to do something similar for project.properties,
> I'm not sure how that would work though
> - Download commons-build/site/menus/ , commons-build/site/parts/ et al
> via anonymous SVN to commons-<component>/site/
>
> This way we don't have to think about merging xml documents and other
> fancy stuff - just download some files from SVN.
>
> Does this sound at all possible?
dunno :)
probably a good idea to hook up with brett and the rest of the maveneers
on IRC (if you can).
> Should I have go at it? I have not made a plugin before, but there's a
> first time for everything...
+1
but don't waste too much energy: better to let folks take a look at a
quick proof of concept early.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Sharing maven setup [was Re: HELP!]
Posted by Dennis Lundberg <de...@mdh.se>.
Stephen Colebourne wrote:
>>> I don't much like the idea of adding dependencies to each of the
>>> individual POMs, but understand that this makes the dependency
>>> explicit, which is a good thing. So I guess I am +0 for this
>>> approach. Actually +1 as in "will help" if others agree we should go
>>> this route instead of the updatePlugins approach.
>>
>> I'm more than happy with the updatePlugins approach. It's KISS at its
>> best.
>> ;-)
>>
>> I remain -1 on reverting to extending the commons-build POM
>
> I agree that we should not extend the commons-build POM. However we
> could do with a way to share stuff.
>
> I have in my mind that what we need is a commons maven plugin. It would:
> - create target/commons
> - download commons-build within target/commons
> - update the local maven installation
> - merge the latest mandatory POM settings
> - merge the latest mandatory POM properties
> - merge the latest mandatory xdocs
>
> Thus, to push a site or release out you do:
> maven commons
> then any other command:
> maven ...
>
> This is probably a pipedream though, as I doubt anyone has the time to
> write this (ie. I don't!)
Yes, of course! A plugin is the way to go.
Most people seems to agree that extending commons-build is a bad thing,
so we need to figure out a way to make each commons component
self-supporting.
Imagine this directory structure in the commons component of your choice:
/
+- commons-<component>/
+- site/
| +- menus/
| | +- ...
| +- parts/
| | +- ...
| +- commons-site.jsl
| +- cvsusage.xml
| +- ...
+- project.properties
+- project.xml
+- project-parent.xml
First we make sure that every commons-component extends the *local*
project-parent.xml, see directory-structure above. This would be a
one-time job.
If we then create a plugin that does the following, it might just work:
- Download commons-build/project-parent.xml via anonymous SVN to
commons-<component>/project-parent.xml
- We would probably need to do something similar for project.properties,
I'm not sure how that would work though
- Download commons-build/site/menus/ , commons-build/site/parts/ et al
via anonymous SVN to commons-<component>/site/
This way we don't have to think about merging xml documents and other
fancy stuff - just download some files from SVN.
Does this sound at all possible?
Should I have go at it? I have not made a plugin before, but there's a
first time for everything...
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[all] Sharing maven setup [was Re: HELP!]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
>>I don't much like the idea of adding dependencies to each of the
>>individual POMs, but understand that this makes the dependency
>>explicit, which is a good thing. So I guess I am +0 for this
>>approach. Actually +1 as in "will help" if others agree we should go
>>this route instead of the updatePlugins approach.
>
> I'm more than happy with the updatePlugins approach. It's KISS at its best.
> ;-)
>
> I remain -1 on reverting to extending the commons-build POM
I agree that we should not extend the commons-build POM. However we
could do with a way to share stuff.
I have in my mind that what we need is a commons maven plugin. It would:
- create target/commons
- download commons-build within target/commons
- update the local maven installation
- merge the latest mandatory POM settings
- merge the latest mandatory POM properties
- merge the latest mandatory xdocs
Thus, to push a site or release out you do:
maven commons
then any other command:
maven ...
This is probably a pipedream though, as I doubt anyone has the time to
write this (ie. I don't!)
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Martin Cooper <ma...@apache.org>.
On 12/5/05, Phil Steitz <ph...@gmail.com> wrote:
>
> Thanks for your help figuring out what the options are, Dennis. See
> comments interspersed.
>
> On 12/5/05, Dennis Lundberg <de...@mdh.se> wrote:
> > Phil Steitz wrote:
> > > On 12/4/05, Brett Porter <br...@apache.org> wrote:
> > >> Dennis Lundberg wrote:
> > >>> Brett said that this *should* work, so I decided to try it myself. I
> > >>> received the same results as you did Phil, regarding maven --info,
> but I
> > >>> think I understand what is going on now. I have posted a question
> about
> > >>> this on the maven-users list to see if I can get some confirmation.
> > >>>
> > >> Sorry this went over my head earlier, but Dennis' analysis on the
> usres
> > >> list is correct. Maven --info doesn't reflect the difference as it
> > >> reports what's installed. Plugin dependencies are only used for the
> life
> > >> of the project's build, not installed.
> > >>
> > >> So the dependency should work regardless of what maven --info says.
> Is
> > >> that the case?
> > >
> > > Then the solution to add the necessary dependencies to commons-build
> > > won't work and what we need to do is something like pluginUpdate
> > > (bunch of explicit plugin installs from the command line). Correct?
> >
> > No, as I will elaborate on further down, it will work nicely. I'll leave
> > aside for a moment the discussion whether or not it's a good idea to
> > extend project.xml from commons-build in other components.
> >
> > Setting up dependencies for a specific version of a Maven plugin, i.e.
> > the xdoc and site plugins, works the way we want them to. I have tried
> > this and it's easy to set it up. Here's what needs to be added in
> > commons-build/project.xml for site generation:
> >
> > <dependencies>
> > <dependency>
> > <groupId>maven</groupId>
> > <artifactId>maven-site-plugin</artifactId>
> > <version>1.6.1</version>
> > <type>plugin</type>
> > </dependency>
> > <dependency>
> > <groupId>maven</groupId>
> > <artifactId>maven-xdoc-plugin</artifactId>
> > <version>1.9.2</version>
> > <type>plugin</type>
> > </dependency>
> > </dependencies>
> >
> > This will ensure that building the web site for commons-build will
> > always use these versions of the plugins, regardless of what the user
> > has installed on his or her system. So far all is good. Now on to the
> > "to extend or not extend" discussion...
> >
> So will only work for the main commons site, IIUC, which is not good
> enough. We need the individual sites to build without pain for RMs /
> maintainers. If just running a clean target in commons-build does not
> effectively update them, then above strategy will not work, unless you
> are talking about adding the dependencies to each individual POM, or
> reverting to extending commons-build, or I am not understanding
> something.
>
> > If commons component A extends the project.xml file from commons-build
> > these dependencies are transfered to that component, meaning that
> > component A doesn't have to worry about dependencies for site
> generation.
> >
> > However, if commons component B does *not* extend the project.xml file
> > from commons-build these dependencies will have to be repeated in the
> > project.xml file for component B. Hopefully these dependencies would not
> > change all that often, meaning that little work would have to be done in
> > order to keep this working, once it has been set up properly.
> >
> > Either way I think there is a big win including these dependencies in
> > commons-build and all commons components. What do you think?
> >
> I don't much like the idea of adding dependencies to each of the
> individual POMs, but understand that this makes the dependency
> explicit, which is a good thing. So I guess I am +0 for this
> approach. Actually +1 as in "will help" if others agree we should go
> this route instead of the updatePlugins approach.
I'm more than happy with the updatePlugins approach. It's KISS at its best.
;-)
I remain -1 on reverting to extending the commons-build POM
Ditto.
--
Martin Cooper
because
> this makes individual releases depend on something not shipped (or
> even release managed) with them and forces users to have commons-build
> checked out to compile/jar under maven. I know we are still partially
> broken in this way now, as most projects require commons-build to be
> checked out for site generation. I view this as less of an issue,
> though, because we ship the docs with the releases. We should find a
> way to copy and adjust references to all of the required stuff as
> (automated, of course ;-) part of the dist build so the releases are
> 100% self-contained and can be reproduced fully from svn tags.
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Phil Steitz <ph...@gmail.com>.
Thanks for your help figuring out what the options are, Dennis. See
comments interspersed.
On 12/5/05, Dennis Lundberg <de...@mdh.se> wrote:
> Phil Steitz wrote:
> > On 12/4/05, Brett Porter <br...@apache.org> wrote:
> >> Dennis Lundberg wrote:
> >>> Brett said that this *should* work, so I decided to try it myself. I
> >>> received the same results as you did Phil, regarding maven --info, but I
> >>> think I understand what is going on now. I have posted a question about
> >>> this on the maven-users list to see if I can get some confirmation.
> >>>
> >> Sorry this went over my head earlier, but Dennis' analysis on the usres
> >> list is correct. Maven --info doesn't reflect the difference as it
> >> reports what's installed. Plugin dependencies are only used for the life
> >> of the project's build, not installed.
> >>
> >> So the dependency should work regardless of what maven --info says. Is
> >> that the case?
> >
> > Then the solution to add the necessary dependencies to commons-build
> > won't work and what we need to do is something like pluginUpdate
> > (bunch of explicit plugin installs from the command line). Correct?
>
> No, as I will elaborate on further down, it will work nicely. I'll leave
> aside for a moment the discussion whether or not it's a good idea to
> extend project.xml from commons-build in other components.
>
> Setting up dependencies for a specific version of a Maven plugin, i.e.
> the xdoc and site plugins, works the way we want them to. I have tried
> this and it's easy to set it up. Here's what needs to be added in
> commons-build/project.xml for site generation:
>
> <dependencies>
> <dependency>
> <groupId>maven</groupId>
> <artifactId>maven-site-plugin</artifactId>
> <version>1.6.1</version>
> <type>plugin</type>
> </dependency>
> <dependency>
> <groupId>maven</groupId>
> <artifactId>maven-xdoc-plugin</artifactId>
> <version>1.9.2</version>
> <type>plugin</type>
> </dependency>
> </dependencies>
>
> This will ensure that building the web site for commons-build will
> always use these versions of the plugins, regardless of what the user
> has installed on his or her system. So far all is good. Now on to the
> "to extend or not extend" discussion...
>
So will only work for the main commons site, IIUC, which is not good
enough. We need the individual sites to build without pain for RMs /
maintainers. If just running a clean target in commons-build does not
effectively update them, then above strategy will not work, unless you
are talking about adding the dependencies to each individual POM, or
reverting to extending commons-build, or I am not understanding
something.
> If commons component A extends the project.xml file from commons-build
> these dependencies are transfered to that component, meaning that
> component A doesn't have to worry about dependencies for site generation.
>
> However, if commons component B does *not* extend the project.xml file
> from commons-build these dependencies will have to be repeated in the
> project.xml file for component B. Hopefully these dependencies would not
> change all that often, meaning that little work would have to be done in
> order to keep this working, once it has been set up properly.
>
> Either way I think there is a big win including these dependencies in
> commons-build and all commons components. What do you think?
>
I don't much like the idea of adding dependencies to each of the
individual POMs, but understand that this makes the dependency
explicit, which is a good thing. So I guess I am +0 for this
approach. Actually +1 as in "will help" if others agree we should go
this route instead of the updatePlugins approach.
I remain -1 on reverting to extending the commons-build POM because
this makes individual releases depend on something not shipped (or
even release managed) with them and forces users to have commons-build
checked out to compile/jar under maven. I know we are still partially
broken in this way now, as most projects require commons-build to be
checked out for site generation. I view this as less of an issue,
though, because we ship the docs with the releases. We should find a
way to copy and adjust references to all of the required stuff as
(automated, of course ;-) part of the dist build so the releases are
100% self-contained and can be reproduced fully from svn tags.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Dennis Lundberg <de...@mdh.se>.
Phil Steitz wrote:
> On 12/4/05, Brett Porter <br...@apache.org> wrote:
>> Dennis Lundberg wrote:
>>> Brett said that this *should* work, so I decided to try it myself. I
>>> received the same results as you did Phil, regarding maven --info, but I
>>> think I understand what is going on now. I have posted a question about
>>> this on the maven-users list to see if I can get some confirmation.
>>>
>> Sorry this went over my head earlier, but Dennis' analysis on the usres
>> list is correct. Maven --info doesn't reflect the difference as it
>> reports what's installed. Plugin dependencies are only used for the life
>> of the project's build, not installed.
>>
>> So the dependency should work regardless of what maven --info says. Is
>> that the case?
>
> Then the solution to add the necessary dependencies to commons-build
> won't work and what we need to do is something like pluginUpdate
> (bunch of explicit plugin installs from the command line). Correct?
No, as I will elaborate on further down, it will work nicely. I'll leave
aside for a moment the discussion whether or not it's a good idea to
extend project.xml from commons-build in other components.
Setting up dependencies for a specific version of a Maven plugin, i.e.
the xdoc and site plugins, works the way we want them to. I have tried
this and it's easy to set it up. Here's what needs to be added in
commons-build/project.xml for site generation:
<dependencies>
<dependency>
<groupId>maven</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>1.6.1</version>
<type>plugin</type>
</dependency>
<dependency>
<groupId>maven</groupId>
<artifactId>maven-xdoc-plugin</artifactId>
<version>1.9.2</version>
<type>plugin</type>
</dependency>
</dependencies>
This will ensure that building the web site for commons-build will
always use these versions of the plugins, regardless of what the user
has installed on his or her system. So far all is good. Now on to the
"to extend or not extend" discussion...
If commons component A extends the project.xml file from commons-build
these dependencies are transfered to that component, meaning that
component A doesn't have to worry about dependencies for site generation.
However, if commons component B does *not* extend the project.xml file
from commons-build these dependencies will have to be repeated in the
project.xml file for component B. Hopefully these dependencies would not
change all that often, meaning that little work would have to be done in
order to keep this working, once it has been set up properly.
Either way I think there is a big win including these dependencies in
commons-build and all commons components. What do you think?
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Phil Steitz <ph...@gmail.com>.
On 12/4/05, Martin Cooper <ma...@apache.org> wrote:
> On 12/4/05, Brett Porter <br...@apache.org> wrote:
> >
> > Phil Steitz wrote:
> > > On 12/4/05, Brett Porter <br...@apache.org> wrote:
> > >> Dennis Lundberg wrote:
> > >>> Brett said that this *should* work, so I decided to try it myself. I
> > >>> received the same results as you did Phil, regarding maven --info, but
> > I
> > >>> think I understand what is going on now. I have posted a question
> > about
> > >>> this on the maven-users list to see if I can get some confirmation.
> > >>>
> > >> Sorry this went over my head earlier, but Dennis' analysis on the usres
> > >> list is correct. Maven --info doesn't reflect the difference as it
> > >> reports what's installed. Plugin dependencies are only used for the
> > life
> > >> of the project's build, not installed.
> > >>
> > >> So the dependency should work regardless of what maven --info says. Is
> > >> that the case?
> > >
> > > Then the solution to add the necessary dependencies to commons-build
> > > won't work and what we need to do is something like pluginUpdate
> > > (bunch of explicit plugin installs from the command line). Correct?
> >
> > No, I think it should work - unless I missed something. The problem is,
> > I thought, that a lot of the projects don't extend commons-build?
>
>
> Right. At first they didn't, then they did, and now they don't again. Please
> let's not flip-flop this again. ;-)
+1
Extending commons-build means you can't even jar or test without
checking that out and individual releases are not fully determined by
what ships with them. What we need is a reliable way to make sure
that we all have current enough versions of the plugins installed so
that the common site generation (and recommendations in the docs) work
properly. IIUC, the only way to do that is to keep a list of required
plugin versions and have people install them manually. The
pluginUpdate.txt file does both of these. Since we are also at this
point requiring maven 1.0.2, some of the items on that list can likely
be eliminated, since I think some ship with that.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Martin Cooper <ma...@apache.org>.
On 12/4/05, Brett Porter <br...@apache.org> wrote:
>
> Phil Steitz wrote:
> > On 12/4/05, Brett Porter <br...@apache.org> wrote:
> >> Dennis Lundberg wrote:
> >>> Brett said that this *should* work, so I decided to try it myself. I
> >>> received the same results as you did Phil, regarding maven --info, but
> I
> >>> think I understand what is going on now. I have posted a question
> about
> >>> this on the maven-users list to see if I can get some confirmation.
> >>>
> >> Sorry this went over my head earlier, but Dennis' analysis on the usres
> >> list is correct. Maven --info doesn't reflect the difference as it
> >> reports what's installed. Plugin dependencies are only used for the
> life
> >> of the project's build, not installed.
> >>
> >> So the dependency should work regardless of what maven --info says. Is
> >> that the case?
> >
> > Then the solution to add the necessary dependencies to commons-build
> > won't work and what we need to do is something like pluginUpdate
> > (bunch of explicit plugin installs from the command line). Correct?
>
> No, I think it should work - unless I missed something. The problem is,
> I thought, that a lot of the projects don't extend commons-build?
Right. At first they didn't, then they did, and now they don't again. Please
let's not flip-flop this again. ;-)
--
Martin Cooper
What happens when a project that extends commons-build has the plugin
> dependency? I know maven --info is "incorrect", but does running xdoc
> actually do what you expect?
>
> - Brett
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Brett Porter <br...@apache.org>.
Phil Steitz wrote:
> On 12/4/05, Brett Porter <br...@apache.org> wrote:
>> Dennis Lundberg wrote:
>>> Brett said that this *should* work, so I decided to try it myself. I
>>> received the same results as you did Phil, regarding maven --info, but I
>>> think I understand what is going on now. I have posted a question about
>>> this on the maven-users list to see if I can get some confirmation.
>>>
>> Sorry this went over my head earlier, but Dennis' analysis on the usres
>> list is correct. Maven --info doesn't reflect the difference as it
>> reports what's installed. Plugin dependencies are only used for the life
>> of the project's build, not installed.
>>
>> So the dependency should work regardless of what maven --info says. Is
>> that the case?
>
> Then the solution to add the necessary dependencies to commons-build
> won't work and what we need to do is something like pluginUpdate
> (bunch of explicit plugin installs from the command line). Correct?
No, I think it should work - unless I missed something. The problem is,
I thought, that a lot of the projects don't extend commons-build?
What happens when a project that extends commons-build has the plugin
dependency? I know maven --info is "incorrect", but does running xdoc
actually do what you expect?
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Phil Steitz <ph...@gmail.com>.
On 12/4/05, Brett Porter <br...@apache.org> wrote:
> Dennis Lundberg wrote:
> >
> > Brett said that this *should* work, so I decided to try it myself. I
> > received the same results as you did Phil, regarding maven --info, but I
> > think I understand what is going on now. I have posted a question about
> > this on the maven-users list to see if I can get some confirmation.
> >
>
> Sorry this went over my head earlier, but Dennis' analysis on the usres
> list is correct. Maven --info doesn't reflect the difference as it
> reports what's installed. Plugin dependencies are only used for the life
> of the project's build, not installed.
>
> So the dependency should work regardless of what maven --info says. Is
> that the case?
Then the solution to add the necessary dependencies to commons-build
won't work and what we need to do is something like pluginUpdate
(bunch of explicit plugin installs from the command line). Correct?
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Phil Steitz <ph...@gmail.com>.
On 12/3/05, Phil Steitz <ph...@gmail.com> wrote:
> On 12/3/05, Martin Cooper <ma...@apache.org> wrote:
> > On 12/3/05, Phil Steitz <ph...@gmail.com> wrote:
> > >
> > > On 12/3/05, Martin Cooper <ma...@apache.org> wrote:
> > > > On 12/3/05, Phil Steitz <ph...@gmail.com> wrote:
> > > > >
> > > > > On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
> > > > > > Nope, 1.6.
> > > > > >
> > > > > > This is sort of what I meant when I said it's harder to do these
> > > > > > releases. How is one supposed to KNOW what versions of these 30 or
> > > 40
> > > > > > plugins you have to have in order to build a release?
> > > > > >
> > > > > > Does Jakarta or Jakarta-commons have a page that tells you the
> > > minimum
> > > > > > maven setup needed to do a site release? If not, it probably should
> > > > > > have. I know this is a dynamic process, but this is nuts.
> > > > >
> > > > > Good point. Right now http://jakarta.apache.org/commons/building.html
> > > > > just contains the statement "Be sure to follow the instructions for
> > > > > upgrading the plugins to the latest releases."
> > > >
> > > >
> > > > Is it just me going blind, or are those instructions missing? All I see
> > > is a
> > > > link to a page that has a big list of plugins. I don't see instructions
> > > on
> > > > upgrading my plugins. ;-(
> > > >
> > >
> > >
> > >
> > > > We could either doc
> > > > > the full set there or check in the output of maven --info as a text
> > > > > file in commons-build, making changes to that as necessary. I would
> > > > > recommend the second option, with a link on the "building" page. I
> > > > > will do that if no one beats me to it.
> > > >
> > > >
> > > > +1 to the second option. +1000 to a script that will automatically
> > > update my
> > > > Maven installation with those versions of the plugins. ;-)
> > >
> > > hmmm...I have a bash script ;-)
> > >
> > > It just consists of a bunch of lines like this:
> > >
> > > maven plugin:download -DgroupId=maven -DartifactId=maven-ant-plugin
> > > -Dversion=1.9
> > > maven plugin:download -DgroupId=maven
> > > -DartifactId=maven-artifact-plugin -Dversion=1.5.2
> >
> >
> > What I was thinking of was some kind of script (language TBD ;) that would
> > take the 'maven --info' file that you mentioned earlier, and use that to
> > update my plugins. That way, when someone updates the info file, I just need
> > to run the script to get all the required updates.
>
> I think what I am doing now to the commons-build pom will do that.
> You will just have to execute any target in commons-build and the
> plugins will get updated appropriately. We can also use the
> commons-build POM dependencies section as the place where we maintain
> the list of required dependency versions. Unless someone sees a
> problem with this, I will go ahead and commit the change to the
> commons-build pom.
Aaargh! Spoke too soon. This does seem to get maven to download the
specified versions, but I am not seeing maven --info reflect the
changes, so I am afraid that this may not be fully effective. Unless
a maven expert chimes in and says this can work, we will have to go
back to the independent script. I will check in a file with the
commands in it to commons-build. This could be wrapped in a bash
script or dos batch file.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Phil Steitz <ph...@gmail.com>.
Sorry, thought you were...
Phil
On 12/4/05, Rahul Akolkar <ra...@gmail.com> wrote:
> On 12/4/05, Phil Steitz <ph...@gmail.com> wrote:
> > >
> > > My attempt to help the next person in line avoid the same confusion
> > > (by updating step 12) is available as 37779 [1].
> > >
> > > -Rahul
> > >
> > > [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=37779
> >
> > Applied. You know, you can do this yourself ;-) Any commons
> > committer can update commons-build and publish the site. just build
> > locally first, check, then commit, then maven site:sshdeploy to
> > republish.
> >
> <snip/>
>
> Am sure, but I'm not a Commons committer ;-)
>
> -Rahul
>
>
> >
> > Phil
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/4/05, Phil Steitz <ph...@gmail.com> wrote:
> >
> > My attempt to help the next person in line avoid the same confusion
> > (by updating step 12) is available as 37779 [1].
> >
> > -Rahul
> >
> > [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=37779
>
> Applied. You know, you can do this yourself ;-) Any commons
> committer can update commons-build and publish the site. just build
> locally first, check, then commit, then maven site:sshdeploy to
> republish.
>
<snip/>
Am sure, but I'm not a Commons committer ;-)
-Rahul
>
> Phil
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Martin Cooper <ma...@apache.org>.
On 12/4/05, Phil Steitz <ph...@gmail.com> wrote:
>
> On 12/4/05, Dion Gillard <di...@gmail.com> wrote:
> > On 12/4/05, Phil Steitz <ph...@gmail.com> wrote:
> > > On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
> > > > Nope, 1.6.
> > > >
> > > > This is sort of what I meant when I said it's harder to do these
> > > > releases. How is one supposed to KNOW what versions of these 30 or
> 40
> > > > plugins you have to have in order to build a release?
> > > >
> > > > Does Jakarta or Jakarta-commons have a page that tells you the
> minimum
> > > > maven setup needed to do a site release? If not, it probably should
> > > > have. I know this is a dynamic process, but this is nuts.
> > >
> > > Good point. Right now http://jakarta.apache.org/commons/building.html
> > > just contains the statement "Be sure to follow the instructions for
> > > upgrading the plugins to the latest releases." We could either doc
> > > the full set there or check in the output of maven --info as a text
> > > file in commons-build, making changes to that as necessary. I would
> > > recommend the second option, with a link on the "building" page. I
> > > will do that if no one beats me to it.
> >
> > If we really do *have to have* a specific release of a plugin, it
> > should be a dependency of the project.
> >
> > Noone should be forced to remember it.
> >
> > Worst case, we should provide a link to suggested upgrades and details
> > about what to expect if you don't.
> >
> Agreed. I tried yesterday to add plugin version dependencies to the
> commons-build POM (the most logical choice). This got maven to
> download the updated versions when necessary, but I did not get
> consistent results from maven --info afterwards, so I did not commit
> the change. It could be that my local setup got messed up due to
> removing / updating plugins during testing.
>
> I added a script to install all of the versions (probably more than we
> need) to commons-build root, called pluginUpdate.txt. Dennis provided
> a patch for the "building" page mentioning the xdoc 1.9+ dependency.
> It would probably be a good idea to add a "troubleshooting" section
> describing commons problems due to wrong plugin / maven versions, etc.
> Any other suggestions / patches / updates welcome.
FYI, I ran pluginUpdate.txt as a batch file, and 'maven --info' after that
gave me the list I expected to see. This seems like as good a way as any to
keep up to date, for Windows users at least.
--
Martin Cooper
Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Brett Porter <br...@apache.org>.
Dennis Lundberg wrote:
>
> Brett said that this *should* work, so I decided to try it myself. I
> received the same results as you did Phil, regarding maven --info, but I
> think I understand what is going on now. I have posted a question about
> this on the maven-users list to see if I can get some confirmation.
>
Sorry this went over my head earlier, but Dennis' analysis on the usres
list is correct. Maven --info doesn't reflect the difference as it
reports what's installed. Plugin dependencies are only used for the life
of the project's build, not installed.
So the dependency should work regardless of what maven --info says. Is
that the case?
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Dennis Lundberg <de...@mdh.se>.
Phil Steitz wrote:
> On 12/4/05, Dion Gillard <di...@gmail.com> wrote:
>> On 12/4/05, Phil Steitz <ph...@gmail.com> wrote:
>>> On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
>>>> Nope, 1.6.
>>>>
>>>> This is sort of what I meant when I said it's harder to do these
>>>> releases. How is one supposed to KNOW what versions of these 30 or 40
>>>> plugins you have to have in order to build a release?
>>>>
>>>> Does Jakarta or Jakarta-commons have a page that tells you the minimum
>>>> maven setup needed to do a site release? If not, it probably should
>>>> have. I know this is a dynamic process, but this is nuts.
>>> Good point. Right now http://jakarta.apache.org/commons/building.html
>>> just contains the statement "Be sure to follow the instructions for
>>> upgrading the plugins to the latest releases." We could either doc
>>> the full set there or check in the output of maven --info as a text
>>> file in commons-build, making changes to that as necessary. I would
>>> recommend the second option, with a link on the "building" page. I
>>> will do that if no one beats me to it.
>> If we really do *have to have* a specific release of a plugin, it
>> should be a dependency of the project.
>>
>> Noone should be forced to remember it.
>>
>> Worst case, we should provide a link to suggested upgrades and details
>> about what to expect if you don't.
>>
> Agreed. I tried yesterday to add plugin version dependencies to the
> commons-build POM (the most logical choice). This got maven to
> download the updated versions when necessary, but I did not get
> consistent results from maven --info afterwards, so I did not commit
> the change. It could be that my local setup got messed up due to
> removing / updating plugins during testing.
Brett said that this *should* work, so I decided to try it myself. I
received the same results as you did Phil, regarding maven --info, but I
think I understand what is going on now. I have posted a question about
this on the maven-users list to see if I can get some confirmation.
> I added a script to install all of the versions (probably more than we
> need) to commons-build root, called pluginUpdate.txt. Dennis provided
> a patch for the "building" page mentioning the xdoc 1.9+ dependency.
> It would probably be a good idea to add a "troubleshooting" section
> describing commons problems due to wrong plugin / maven versions, etc.
> Any other suggestions / patches / updates welcome.
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Phil Steitz <ph...@gmail.com>.
On 12/4/05, Dion Gillard <di...@gmail.com> wrote:
> On 12/4/05, Phil Steitz <ph...@gmail.com> wrote:
> > On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
> > > Nope, 1.6.
> > >
> > > This is sort of what I meant when I said it's harder to do these
> > > releases. How is one supposed to KNOW what versions of these 30 or 40
> > > plugins you have to have in order to build a release?
> > >
> > > Does Jakarta or Jakarta-commons have a page that tells you the minimum
> > > maven setup needed to do a site release? If not, it probably should
> > > have. I know this is a dynamic process, but this is nuts.
> >
> > Good point. Right now http://jakarta.apache.org/commons/building.html
> > just contains the statement "Be sure to follow the instructions for
> > upgrading the plugins to the latest releases." We could either doc
> > the full set there or check in the output of maven --info as a text
> > file in commons-build, making changes to that as necessary. I would
> > recommend the second option, with a link on the "building" page. I
> > will do that if no one beats me to it.
>
> If we really do *have to have* a specific release of a plugin, it
> should be a dependency of the project.
>
> Noone should be forced to remember it.
>
> Worst case, we should provide a link to suggested upgrades and details
> about what to expect if you don't.
>
Agreed. I tried yesterday to add plugin version dependencies to the
commons-build POM (the most logical choice). This got maven to
download the updated versions when necessary, but I did not get
consistent results from maven --info afterwards, so I did not commit
the change. It could be that my local setup got messed up due to
removing / updating plugins during testing.
I added a script to install all of the versions (probably more than we
need) to commons-build root, called pluginUpdate.txt. Dennis provided
a patch for the "building" page mentioning the xdoc 1.9+ dependency.
It would probably be a good idea to add a "troubleshooting" section
describing commons problems due to wrong plugin / maven versions, etc.
Any other suggestions / patches / updates welcome.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Wendy!
> :::sigh::: Never mind. LICENSE.txt is working fine... it's NOTICE.txt
> that isn't getting included in the .jar file automatically. Thanks
> for the confirmation. :)
>
I've seen this on the myfaces mailing list a while ago and already
answered how we in commons-dev do this:
http://www.mail-archive.com/dev%40myfaces.apache.org/msg08107.html
Maybe you have overlooked it? Or wasnt it much of help?
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Wendy Smoak <ws...@gmail.com>.
On 12/4/05, Phil Steitz <ph...@gmail.com> wrote:
> NOTICE.txt still needs to be added explicity as a jar resource, IIRC.
:::sigh::: Never mind. LICENSE.txt is working fine... it's NOTICE.txt
that isn't getting included in the .jar file automatically. Thanks
for the confirmation. :)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by "Brian K. Wallace" <br...@transmorphix.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Phil Steitz wrote:
> On 12/3/05, Martin Cooper <ma...@apache.org> wrote:
>> On 12/3/05, Phil Steitz <ph...@gmail.com> wrote:
>>> On 12/3/05, Martin Cooper <ma...@apache.org> wrote:
>>>> On 12/3/05, Phil Steitz <ph...@gmail.com> wrote:
>>>>> On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
>>>>>> Nope, 1.6.
>>>>>>
>>>>>> This is sort of what I meant when I said it's harder to do these
>>>>>> releases. How is one supposed to KNOW what versions of these 30 or
>>> 40
>>>>>> plugins you have to have in order to build a release?
>>>>>>
>>>>>> Does Jakarta or Jakarta-commons have a page that tells you the
>>> minimum
>>>>>> maven setup needed to do a site release? If not, it probably should
>>>>>> have. I know this is a dynamic process, but this is nuts.
>>>>> Good point. Right now http://jakarta.apache.org/commons/building.html
>>>>> just contains the statement "Be sure to follow the instructions for
>>>>> upgrading the plugins to the latest releases."
>>>>
>>>> Is it just me going blind, or are those instructions missing? All I see
>>> is a
>>>> link to a page that has a big list of plugins. I don't see instructions
>>> on
>>>> upgrading my plugins. ;-(
>>>>
>>>
>>>
>>>> We could either doc
>>>>> the full set there or check in the output of maven --info as a text
>>>>> file in commons-build, making changes to that as necessary. I would
>>>>> recommend the second option, with a link on the "building" page. I
>>>>> will do that if no one beats me to it.
>>>>
>>>> +1 to the second option. +1000 to a script that will automatically
>>> update my
>>>> Maven installation with those versions of the plugins. ;-)
>>> hmmm...I have a bash script ;-)
>>>
>>> It just consists of a bunch of lines like this:
>>>
>>> maven plugin:download -DgroupId=maven -DartifactId=maven-ant-plugin
>>> -Dversion=1.9
>>> maven plugin:download -DgroupId=maven
>>> -DartifactId=maven-artifact-plugin -Dversion=1.5.2
>>
>> What I was thinking of was some kind of script (language TBD ;) that would
>> take the 'maven --info' file that you mentioned earlier, and use that to
>> update my plugins. That way, when someone updates the info file, I just need
>> to run the script to get all the required updates.
>
> I think what I am doing now to the commons-build pom will do that.
> You will just have to execute any target in commons-build and the
> plugins will get updated appropriately. We can also use the
> commons-build POM dependencies section as the place where we maintain
> the list of required dependency versions. Unless someone sees a
> problem with this, I will go ahead and commit the change to the
> commons-build pom.
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
I've been watching the flurry of 'maven-centric' messages floating
around as it deals with [net] and commons in general. Perhaps when going
outside the [net] scope (with commons-build), it might be beneficial to
move the conversation out to [all] (which is where the other main thread
is occurring).
Just a thought. (and nothing like the previous thought of "what was so
bad about ant" ;-) )
Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFDkjRqaCoPKRow/gARAvDFAJ0Zjmb7n91jpfRKE7YDs8j1ZXvHoQCfWd12
7euyf9uih6wKVxso0+eMkD0=
=dZhp
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Phil Steitz <ph...@gmail.com>.
On 12/3/05, Martin Cooper <ma...@apache.org> wrote:
> On 12/3/05, Phil Steitz <ph...@gmail.com> wrote:
> >
> > On 12/3/05, Martin Cooper <ma...@apache.org> wrote:
> > > On 12/3/05, Phil Steitz <ph...@gmail.com> wrote:
> > > >
> > > > On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
> > > > > Nope, 1.6.
> > > > >
> > > > > This is sort of what I meant when I said it's harder to do these
> > > > > releases. How is one supposed to KNOW what versions of these 30 or
> > 40
> > > > > plugins you have to have in order to build a release?
> > > > >
> > > > > Does Jakarta or Jakarta-commons have a page that tells you the
> > minimum
> > > > > maven setup needed to do a site release? If not, it probably should
> > > > > have. I know this is a dynamic process, but this is nuts.
> > > >
> > > > Good point. Right now http://jakarta.apache.org/commons/building.html
> > > > just contains the statement "Be sure to follow the instructions for
> > > > upgrading the plugins to the latest releases."
> > >
> > >
> > > Is it just me going blind, or are those instructions missing? All I see
> > is a
> > > link to a page that has a big list of plugins. I don't see instructions
> > on
> > > upgrading my plugins. ;-(
> > >
> >
> >
> >
> > > We could either doc
> > > > the full set there or check in the output of maven --info as a text
> > > > file in commons-build, making changes to that as necessary. I would
> > > > recommend the second option, with a link on the "building" page. I
> > > > will do that if no one beats me to it.
> > >
> > >
> > > +1 to the second option. +1000 to a script that will automatically
> > update my
> > > Maven installation with those versions of the plugins. ;-)
> >
> > hmmm...I have a bash script ;-)
> >
> > It just consists of a bunch of lines like this:
> >
> > maven plugin:download -DgroupId=maven -DartifactId=maven-ant-plugin
> > -Dversion=1.9
> > maven plugin:download -DgroupId=maven
> > -DartifactId=maven-artifact-plugin -Dversion=1.5.2
>
>
> What I was thinking of was some kind of script (language TBD ;) that would
> take the 'maven --info' file that you mentioned earlier, and use that to
> update my plugins. That way, when someone updates the info file, I just need
> to run the script to get all the required updates.
I think what I am doing now to the commons-build pom will do that.
You will just have to execute any target in commons-build and the
plugins will get updated appropriately. We can also use the
commons-build POM dependencies section as the place where we maintain
the list of required dependency versions. Unless someone sees a
problem with this, I will go ahead and commit the change to the
commons-build pom.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Martin Cooper <ma...@apache.org>.
On 12/3/05, Phil Steitz <ph...@gmail.com> wrote:
>
> On 12/3/05, Martin Cooper <ma...@apache.org> wrote:
> > On 12/3/05, Phil Steitz <ph...@gmail.com> wrote:
> > >
> > > On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
> > > > Nope, 1.6.
> > > >
> > > > This is sort of what I meant when I said it's harder to do these
> > > > releases. How is one supposed to KNOW what versions of these 30 or
> 40
> > > > plugins you have to have in order to build a release?
> > > >
> > > > Does Jakarta or Jakarta-commons have a page that tells you the
> minimum
> > > > maven setup needed to do a site release? If not, it probably should
> > > > have. I know this is a dynamic process, but this is nuts.
> > >
> > > Good point. Right now http://jakarta.apache.org/commons/building.html
> > > just contains the statement "Be sure to follow the instructions for
> > > upgrading the plugins to the latest releases."
> >
> >
> > Is it just me going blind, or are those instructions missing? All I see
> is a
> > link to a page that has a big list of plugins. I don't see instructions
> on
> > upgrading my plugins. ;-(
> >
>
>
>
> > We could either doc
> > > the full set there or check in the output of maven --info as a text
> > > file in commons-build, making changes to that as necessary. I would
> > > recommend the second option, with a link on the "building" page. I
> > > will do that if no one beats me to it.
> >
> >
> > +1 to the second option. +1000 to a script that will automatically
> update my
> > Maven installation with those versions of the plugins. ;-)
>
> hmmm...I have a bash script ;-)
>
> It just consists of a bunch of lines like this:
>
> maven plugin:download -DgroupId=maven -DartifactId=maven-ant-plugin
> -Dversion=1.9
> maven plugin:download -DgroupId=maven
> -DartifactId=maven-artifact-plugin -Dversion=1.5.2
What I was thinking of was some kind of script (language TBD ;) that would
take the 'maven --info' file that you mentioned earlier, and use that to
update my plugins. That way, when someone updates the info file, I just need
to run the script to get all the required updates.
Hey, maybe there should be a Maven plugin for that! Building it as a Maven
plugin would at least solve the language problem. Hmm...
--
Martin Cooper
...
>
> Another thing that might work would be to add explicit dependencies to
> the required versions in commons-build's project.xml. Then executing
> even the clean target there would make maven download and install them
> all. I will play with this and if it works, just commit the change
> there and change the docs to recommend this.
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
Yes, thanks, fixed it now.
Rahul Akolkar wrote:
> On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
>
>>Pls disregard. I figured it out.
>
> <snip/>
>
> Yup, noticed that as I clicked send to the earlier email. I think
> you've a typo, the id for the net 1.4.1 news item should be 20051203.1
> (instead of 2005203.1)
>
> -Rahul
>
>
>
>
>>Steve Cohen wrote:
>>
>>>okay, made it down to step 12 now.
>>>
>
> <snap/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
> Pls disregard. I figured it out.
<snip/>
Yup, noticed that as I clicked send to the earlier email. I think
you've a typo, the id for the net 1.4.1 news item should be 20051203.1
(instead of 2005203.1)
-Rahul
> Steve Cohen wrote:
> > okay, made it down to step 12 now.
> >
<snap/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Phil Steitz <ph...@gmail.com>.
>
> My attempt to help the next person in line avoid the same confusion
> (by updating step 12) is available as 37779 [1].
>
> -Rahul
>
> [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=37779
Applied. You know, you can do this yourself ;-) Any commons
committer can update commons-build and publish the site. just build
locally first, check, then commit, then maven site:sshdeploy to
republish.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/3/05, Rahul Akolkar <ra...@gmail.com> wrote:
> On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
> > okay, made it down to step 12 now.
> >
<snip/>
> >
> > However, there is no such file since 2nd quarter of 2005, and the
> > index.xml mentions that this has now been retired, and the apache site
> > now asks you to subscribe to a mailing list for Apache news. Am I right
> > then in thinking that the second part of section 12 (quoted above) is
> > now null and void?
> >
> <snip/>
>
> You're almost home. Section 12 needs to be updated, I might propose a
> patch if I find cycles tomorrow. But I wouldn't recommend disregarding
> it.
>
<snap/>
Steve (or anyone else) -
My attempt to help the next person in line avoid the same confusion
(by updating step 12) is available as 37779 [1].
-Rahul
[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=37779
> You're looking for this news.xml file [1].
>
> The background on the change not yet reflected in the Commons docs is
> in this thread on general@ [2].
>
> -Rahul
>
> [1] http://svn.apache.org/repos/asf/jakarta/site/news.xml
> [2] http://marc.theaimsgroup.com/?l=jakarta-general&m=112957612119868&w=2
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Phil Steitz <ph...@gmail.com>.
On 12/3/05, Dennis Lundberg <de...@mdh.se> wrote:
> Phil Steitz wrote:
<snip>
> > Another thing that might work would be to add explicit dependencies to
> > the required versions in commons-build's project.xml. Then executing
> > even the clean target there would make maven download and install them
> > all. I will play with this and if it works, just commit the change
> > there and change the docs to recommend this.
>
> Not sure if putting a dependency on a plugin works in Maven 1, I know it
> works in Maven 2. It would be great if it does though.
Actually, it does seem to work. I will take a stab at specifying all
of the relevant ones and commit a change to the commons-build POM for
this.
>
> I'm putting together a patch for
> http://jakarta.apache.org/commons/building.html on how to install
> plugins manually.
Great! Include a recommendation to execute the clean target or build
the commons web site from commons-build to get the plugins specified
there. No harm in also repeating the maven instructions as well. Pls
also add make any other improvements you see fit.
Phil
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
Wow, who would have thought the smallest of releases would produce this
much email traffic???
Dennis Lundberg wrote:
> Phil Steitz wrote:
>
>> On 12/3/05, Martin Cooper <ma...@apache.org> wrote:
>>
>>> On 12/3/05, Phil Steitz <ph...@gmail.com> wrote:
>>>
>>>> On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
>>>>
>>>>> Nope, 1.6.
>>>>>
>>>>> This is sort of what I meant when I said it's harder to do these
>>>>> releases. How is one supposed to KNOW what versions of these 30 or 40
>>>>> plugins you have to have in order to build a release?
>>>>>
>>>>> Does Jakarta or Jakarta-commons have a page that tells you the minimum
>>>>> maven setup needed to do a site release? If not, it probably should
>>>>> have. I know this is a dynamic process, but this is nuts.
>>>>
>>>> Good point. Right now http://jakarta.apache.org/commons/building.html
>>>> just contains the statement "Be sure to follow the instructions for
>>>> upgrading the plugins to the latest releases."
>>>
>>>
>>> Is it just me going blind, or are those instructions missing? All I
>>> see is a
>>> link to a page that has a big list of plugins. I don't see
>>> instructions on
>>> upgrading my plugins. ;-(
>>>
>>
>>
>>
>>> We could either doc
>>>
>>>> the full set there or check in the output of maven --info as a text
>>>> file in commons-build, making changes to that as necessary. I would
>>>> recommend the second option, with a link on the "building" page. I
>>>> will do that if no one beats me to it.
>>>
>>>
>>> +1 to the second option. +1000 to a script that will automatically
>>> update my
>>> Maven installation with those versions of the plugins. ;-)
>>
>>
>> hmmm...I have a bash script ;-)
>>
>> It just consists of a bunch of lines like this:
>>
>> maven plugin:download -DgroupId=maven -DartifactId=maven-ant-plugin
>> -Dversion=1.9
>> maven plugin:download -DgroupId=maven
>> -DartifactId=maven-artifact-plugin -Dversion=1.5.2
>> ...
>>
>> Another thing that might work would be to add explicit dependencies to
>> the required versions in commons-build's project.xml. Then executing
>> even the clean target there would make maven download and install them
>> all. I will play with this and if it works, just commit the change
>> there and change the docs to recommend this.
>
>
> Not sure if putting a dependency on a plugin works in Maven 1, I know it
> works in Maven 2. It would be great if it does though.
>
> I'm putting together a patch for
> http://jakarta.apache.org/commons/building.html on how to install
> plugins manually.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Dennis Lundberg <de...@mdh.se>.
Dennis Lundberg wrote:
> Phil Steitz wrote:
>> On 12/3/05, Martin Cooper <ma...@apache.org> wrote:
>>> On 12/3/05, Phil Steitz <ph...@gmail.com> wrote:
>>>> On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
>>>>> Nope, 1.6.
>>>>>
>>>>> This is sort of what I meant when I said it's harder to do these
>>>>> releases. How is one supposed to KNOW what versions of these 30 or 40
>>>>> plugins you have to have in order to build a release?
>>>>>
>>>>> Does Jakarta or Jakarta-commons have a page that tells you the minimum
>>>>> maven setup needed to do a site release? If not, it probably should
>>>>> have. I know this is a dynamic process, but this is nuts.
>>>> Good point. Right now http://jakarta.apache.org/commons/building.html
>>>> just contains the statement "Be sure to follow the instructions for
>>>> upgrading the plugins to the latest releases."
>>>
>>> Is it just me going blind, or are those instructions missing? All I
>>> see is a
>>> link to a page that has a big list of plugins. I don't see
>>> instructions on
>>> upgrading my plugins. ;-(
>>>
>>
>>
>>
>>> We could either doc
>>>> the full set there or check in the output of maven --info as a text
>>>> file in commons-build, making changes to that as necessary. I would
>>>> recommend the second option, with a link on the "building" page. I
>>>> will do that if no one beats me to it.
>>>
>>> +1 to the second option. +1000 to a script that will automatically
>>> update my
>>> Maven installation with those versions of the plugins. ;-)
>>
>> hmmm...I have a bash script ;-)
>>
>> It just consists of a bunch of lines like this:
>>
>> maven plugin:download -DgroupId=maven -DartifactId=maven-ant-plugin
>> -Dversion=1.9
>> maven plugin:download -DgroupId=maven
>> -DartifactId=maven-artifact-plugin -Dversion=1.5.2
>> ...
>>
>> Another thing that might work would be to add explicit dependencies to
>> the required versions in commons-build's project.xml. Then executing
>> even the clean target there would make maven download and install them
>> all. I will play with this and if it works, just commit the change
>> there and change the docs to recommend this.
>
> Not sure if putting a dependency on a plugin works in Maven 1, I know it
> works in Maven 2. It would be great if it does though.
>
> I'm putting together a patch for
> http://jakarta.apache.org/commons/building.html on how to install
> plugins manually.
Patch submitted to Bugzilla:
http://issues.apache.org/bugzilla/show_bug.cgi?id=37772
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Dennis Lundberg <de...@mdh.se>.
Phil Steitz wrote:
> On 12/3/05, Martin Cooper <ma...@apache.org> wrote:
>> On 12/3/05, Phil Steitz <ph...@gmail.com> wrote:
>>> On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
>>>> Nope, 1.6.
>>>>
>>>> This is sort of what I meant when I said it's harder to do these
>>>> releases. How is one supposed to KNOW what versions of these 30 or 40
>>>> plugins you have to have in order to build a release?
>>>>
>>>> Does Jakarta or Jakarta-commons have a page that tells you the minimum
>>>> maven setup needed to do a site release? If not, it probably should
>>>> have. I know this is a dynamic process, but this is nuts.
>>> Good point. Right now http://jakarta.apache.org/commons/building.html
>>> just contains the statement "Be sure to follow the instructions for
>>> upgrading the plugins to the latest releases."
>>
>> Is it just me going blind, or are those instructions missing? All I see is a
>> link to a page that has a big list of plugins. I don't see instructions on
>> upgrading my plugins. ;-(
>>
>
>
>
>> We could either doc
>>> the full set there or check in the output of maven --info as a text
>>> file in commons-build, making changes to that as necessary. I would
>>> recommend the second option, with a link on the "building" page. I
>>> will do that if no one beats me to it.
>>
>> +1 to the second option. +1000 to a script that will automatically update my
>> Maven installation with those versions of the plugins. ;-)
>
> hmmm...I have a bash script ;-)
>
> It just consists of a bunch of lines like this:
>
> maven plugin:download -DgroupId=maven -DartifactId=maven-ant-plugin
> -Dversion=1.9
> maven plugin:download -DgroupId=maven
> -DartifactId=maven-artifact-plugin -Dversion=1.5.2
> ...
>
> Another thing that might work would be to add explicit dependencies to
> the required versions in commons-build's project.xml. Then executing
> even the clean target there would make maven download and install them
> all. I will play with this and if it works, just commit the change
> there and change the docs to recommend this.
Not sure if putting a dependency on a plugin works in Maven 1, I know it
works in Maven 2. It would be great if it does though.
I'm putting together a patch for
http://jakarta.apache.org/commons/building.html on how to install
plugins manually.
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
Phil Steitz wrote:
> On 12/3/05, Martin Cooper <ma...@apache.org> wrote:
>
>>On 12/3/05, Phil Steitz <ph...@gmail.com> wrote:
>>
>>>On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
>>>
>>>>Nope, 1.6.
>>>>
>>>>This is sort of what I meant when I said it's harder to do these
>>>>releases. How is one supposed to KNOW what versions of these 30 or 40
>>>>plugins you have to have in order to build a release?
>>>>
>>>>Does Jakarta or Jakarta-commons have a page that tells you the minimum
>>>>maven setup needed to do a site release? If not, it probably should
>>>>have. I know this is a dynamic process, but this is nuts.
>>>
>>>Good point. Right now http://jakarta.apache.org/commons/building.html
>>>just contains the statement "Be sure to follow the instructions for
>>>upgrading the plugins to the latest releases."
>>
>>
>>Is it just me going blind, or are those instructions missing? All I see is a
>>link to a page that has a big list of plugins. I don't see instructions on
>>upgrading my plugins. ;-(
>>
>
>
>
>
>>We could either doc
>>
>>>the full set there or check in the output of maven --info as a text
>>>file in commons-build, making changes to that as necessary. I would
>>>recommend the second option, with a link on the "building" page. I
>>>will do that if no one beats me to it.
>>
>>
>>+1 to the second option. +1000 to a script that will automatically update my
>>Maven installation with those versions of the plugins. ;-)
>
>
> hmmm...I have a bash script ;-)
>
> It just consists of a bunch of lines like this:
>
> maven plugin:download -DgroupId=maven -DartifactId=maven-ant-plugin
> -Dversion=1.9
> maven plugin:download -DgroupId=maven
> -DartifactId=maven-artifact-plugin -Dversion=1.5.2
> ...
>
> Another thing that might work would be to add explicit dependencies to
> the required versions in commons-build's project.xml. Then executing
> even the clean target there would make maven download and install them
> all. I will play with this and if it works, just commit the change
> there and change the docs to recommend this.
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
that would be a big help, thank you very much.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Phil Steitz <ph...@gmail.com>.
On 12/3/05, Martin Cooper <ma...@apache.org> wrote:
> On 12/3/05, Phil Steitz <ph...@gmail.com> wrote:
> >
> > On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
> > > Nope, 1.6.
> > >
> > > This is sort of what I meant when I said it's harder to do these
> > > releases. How is one supposed to KNOW what versions of these 30 or 40
> > > plugins you have to have in order to build a release?
> > >
> > > Does Jakarta or Jakarta-commons have a page that tells you the minimum
> > > maven setup needed to do a site release? If not, it probably should
> > > have. I know this is a dynamic process, but this is nuts.
> >
> > Good point. Right now http://jakarta.apache.org/commons/building.html
> > just contains the statement "Be sure to follow the instructions for
> > upgrading the plugins to the latest releases."
>
>
> Is it just me going blind, or are those instructions missing? All I see is a
> link to a page that has a big list of plugins. I don't see instructions on
> upgrading my plugins. ;-(
>
> We could either doc
> > the full set there or check in the output of maven --info as a text
> > file in commons-build, making changes to that as necessary. I would
> > recommend the second option, with a link on the "building" page. I
> > will do that if no one beats me to it.
>
>
> +1 to the second option. +1000 to a script that will automatically update my
> Maven installation with those versions of the plugins. ;-)
hmmm...I have a bash script ;-)
It just consists of a bunch of lines like this:
maven plugin:download -DgroupId=maven -DartifactId=maven-ant-plugin
-Dversion=1.9
maven plugin:download -DgroupId=maven
-DartifactId=maven-artifact-plugin -Dversion=1.5.2
...
Another thing that might work would be to add explicit dependencies to
the required versions in commons-build's project.xml. Then executing
even the clean target there would make maven download and install them
all. I will play with this and if it works, just commit the change
there and change the docs to recommend this.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Phil Steitz <ph...@gmail.com>.
On 12/4/05, Martin Cooper <ma...@apache.org> wrote:
> On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
> >
> > Martin Cooper wrote:
> > > On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
> > >
> > >>Phil Steitz wrote:
> > >>
> > >>>On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
> > >>>
> > >>>
> > >>>>Henri Yandell wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>>>I turn the navigation off on Maven projects. Can't stand the
> > >>>>>project-reports, project-info roll-ups that make it harder to find
> > >>>>>javadocs etc.
> > >>>>
> > >>>>Hear hear! Javadocs are not a "project report" for anyone who uses
> > >>>>these sites. This one we can't blame on Maven, though, can we? I
> > >>>>always assumed it was our setup of Maven.
> > >>>>
> > >>>
> > >>>What exactly is broken here?
> > >>>Sites that follow the instructions here
> > >>>http://jakarta.apache.org/commons/building.html
> > >>>or start with the sample nav here
> > >>>
> > >>
> > >>
> > http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/navigation.xml.sample
> > >>
> > >>>will link to current and previous release javadoc from the top level
> > >>>nav. Pretty much all maven-generated commons sites do this now.
> > >>>
> > >>>The real challenge is what Stephen mentioned and Brett responed to,
> > >>>which is how to maintain javadoc for past releases. Now these files
> > >>>have to be manually pushed out and links custom coded in
> > >>>navigation.xml.
> > >>>
> > >>>Phil
> > >>>
> > >>>---------------------------------------------------------------------
> > >>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > >>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >>>
> > >>>
> > >>>
> > >>
> > >>You're missing the point here, Phil. It's working as someone intended,
> > >>I'm sure, but the location of Javadocs buried under "Project Reports" is
> > >>bad from an end-user usability perspective. Granted, consistency is a
> > >>good thing and frequent users may eventually learn, but it would be
> > >>better for javadocs to be a top-level menu item. The "Javadoc Report"
> > >>is a report and is in the right place but the Javadocs themselves are
> > >>misplaced.
> > >
> > >
> > >
> > > It's trivial to just add a link to them in your navigation.xml file. See
> > the
> > > FileUpload, IO or Validator sites for examples.
> > >
> > > --
> > > Martin Cooper
> > >
> > >
> > > ---------------------------------------------------------------------
> > >
> > >>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >>
> > >>
> > >
> > >
> > Not quite so trivial. The commons-io site evidently pushes two sets of
> > javadocs, one for "SVN latest" and another for the last official
> > release. Net only has one and the one it has, although it's location is
> > named analogously to io's "SVN latest", actually points to net's last
> > official release. So I suspect there's also some maven magic going on
> > here as well.
>
>
> I wasn't trying to solve the multiple Javadoc versions problem here (and I
> didn't do IO ;). If you look at FileUpload, all that has is an additional
> link in navigation.xml that points to the same Javadoc location as the
> Javadoc link under Project Reports. That's all I was suggesting.
>
Exactly, just as suggested in the example nav linked above.
Commons sites should be using that pattern, including the xml entities
for the common menus. This is explained in the "Generating the site"
section of http://jakarta.apache.org/commons/building.html
I agree that javadoc should be prominent for commons components, but I
can understand why maven does not put it at the top level by default,
as lots of maven projects aren't libraries. In any case, you can do
pretty much anything you want in navigation.xml.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Martin Cooper <ma...@apache.org>.
On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
>
> Martin Cooper wrote:
> > On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
> >
> >>Phil Steitz wrote:
> >>
> >>>On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
> >>>
> >>>
> >>>>Henri Yandell wrote:
> >>>>
> >>>>
> >>>>
> >>>>>I turn the navigation off on Maven projects. Can't stand the
> >>>>>project-reports, project-info roll-ups that make it harder to find
> >>>>>javadocs etc.
> >>>>
> >>>>Hear hear! Javadocs are not a "project report" for anyone who uses
> >>>>these sites. This one we can't blame on Maven, though, can we? I
> >>>>always assumed it was our setup of Maven.
> >>>>
> >>>
> >>>What exactly is broken here?
> >>>Sites that follow the instructions here
> >>>http://jakarta.apache.org/commons/building.html
> >>>or start with the sample nav here
> >>>
> >>
> >>
> http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/navigation.xml.sample
> >>
> >>>will link to current and previous release javadoc from the top level
> >>>nav. Pretty much all maven-generated commons sites do this now.
> >>>
> >>>The real challenge is what Stephen mentioned and Brett responed to,
> >>>which is how to maintain javadoc for past releases. Now these files
> >>>have to be manually pushed out and links custom coded in
> >>>navigation.xml.
> >>>
> >>>Phil
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>>
> >>>
> >>>
> >>
> >>You're missing the point here, Phil. It's working as someone intended,
> >>I'm sure, but the location of Javadocs buried under "Project Reports" is
> >>bad from an end-user usability perspective. Granted, consistency is a
> >>good thing and frequent users may eventually learn, but it would be
> >>better for javadocs to be a top-level menu item. The "Javadoc Report"
> >>is a report and is in the right place but the Javadocs themselves are
> >>misplaced.
> >
> >
> >
> > It's trivial to just add a link to them in your navigation.xml file. See
> the
> > FileUpload, IO or Validator sites for examples.
> >
> > --
> > Martin Cooper
> >
> >
> > ---------------------------------------------------------------------
> >
> >>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> Not quite so trivial. The commons-io site evidently pushes two sets of
> javadocs, one for "SVN latest" and another for the last official
> release. Net only has one and the one it has, although it's location is
> named analogously to io's "SVN latest", actually points to net's last
> official release. So I suspect there's also some maven magic going on
> here as well.
I wasn't trying to solve the multiple Javadoc versions problem here (and I
didn't do IO ;). If you look at FileUpload, all that has is an additional
link in navigation.xml that points to the same Javadoc location as the
Javadoc link under Project Reports. That's all I was suggesting.
--
Martin Cooper
This is a nice feature, the way you have it in IO. Shouldn't this be
> part of the standard commons maven process?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [all] Multi-version javadoc
Posted by Henri Yandell <fl...@gmail.com>.
On 12/4/05, Stephen Colebourne <sc...@btopenworld.com> wrote:
> Steve Cohen wrote:
> > Not quite so trivial. The commons-io site evidently pushes two sets of
> > javadocs, one for "SVN latest" and another for the last official
> > release. Net only has one and the one it has, although it's location is
> > named analogously to io's "SVN latest", actually points to net's last
> > official release. So I suspect there's also some maven magic going on
> > here as well.
> >
> > This is a nice feature, the way you have it in IO. Shouldn't this be
> > part of the standard commons maven process?
>
> I did [io]. Do achieve the effect you have to do it manually.
I use the download archives to do:
http://people.apache.org/~bayard/multidoc-jnr/ (ignore the wrong branding)
Working with a friend on a rewrite of the jardiff bit so it isn't
quite so slow, then I can figure out why it doesn't find the other
components/versions.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Multi-version javadoc
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Steve Cohen wrote:
> Not quite so trivial. The commons-io site evidently pushes two sets of
> javadocs, one for "SVN latest" and another for the last official
> release. Net only has one and the one it has, although it's location is
> named analogously to io's "SVN latest", actually points to net's last
> official release. So I suspect there's also some maven magic going on
> here as well.
>
> This is a nice feature, the way you have it in IO. Shouldn't this be
> part of the standard commons maven process?
I did [io]. Do achieve the effect you have to do it manually.
1) maven clean
2) Checkout v1.0
3) maven javadoc
4) rename target/docs/apidocs to api-1.0
5) repeat for v1.1, v1.2 etc
6) maven site:sshdeploy
7) ssh to the site directory and link api-release to the latest release
You don't need to do this with every release, as the javadoc just
accumulates and doesn't get deleted by subsequent uploads. Note that
target/docs/apidocs is reserved for the SVN latest javadoc.
To use the javadoc you then customise navigation.xml as per [io].
This is probably all scriptable in maven, but I tried it once with
[collections], and found that scripting wasn't worth the effort - a
manual process was quicker.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Steve Cohen <sc...@javactivity.org>.
Martin Cooper wrote:
> On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
>
>>Phil Steitz wrote:
>>
>>>On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
>>>
>>>
>>>>Henri Yandell wrote:
>>>>
>>>>
>>>>
>>>>>I turn the navigation off on Maven projects. Can't stand the
>>>>>project-reports, project-info roll-ups that make it harder to find
>>>>>javadocs etc.
>>>>
>>>>Hear hear! Javadocs are not a "project report" for anyone who uses
>>>>these sites. This one we can't blame on Maven, though, can we? I
>>>>always assumed it was our setup of Maven.
>>>>
>>>
>>>What exactly is broken here?
>>>Sites that follow the instructions here
>>>http://jakarta.apache.org/commons/building.html
>>>or start with the sample nav here
>>>
>>
>>http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/navigation.xml.sample
>>
>>>will link to current and previous release javadoc from the top level
>>>nav. Pretty much all maven-generated commons sites do this now.
>>>
>>>The real challenge is what Stephen mentioned and Brett responed to,
>>>which is how to maintain javadoc for past releases. Now these files
>>>have to be manually pushed out and links custom coded in
>>>navigation.xml.
>>>
>>>Phil
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>
>>You're missing the point here, Phil. It's working as someone intended,
>>I'm sure, but the location of Javadocs buried under "Project Reports" is
>>bad from an end-user usability perspective. Granted, consistency is a
>>good thing and frequent users may eventually learn, but it would be
>>better for javadocs to be a top-level menu item. The "Javadoc Report"
>>is a report and is in the right place but the Javadocs themselves are
>>misplaced.
>
>
>
> It's trivial to just add a link to them in your navigation.xml file. See the
> FileUpload, IO or Validator sites for examples.
>
> --
> Martin Cooper
>
>
> ---------------------------------------------------------------------
>
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
>
Not quite so trivial. The commons-io site evidently pushes two sets of
javadocs, one for "SVN latest" and another for the last official
release. Net only has one and the one it has, although it's location is
named analogously to io's "SVN latest", actually points to net's last
official release. So I suspect there's also some maven magic going on
here as well.
This is a nice feature, the way you have it in IO. Shouldn't this be
part of the standard commons maven process?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Martin Cooper <ma...@apache.org>.
On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
>
> Phil Steitz wrote:
> > On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
> >
> >>Henri Yandell wrote:
> >>
> >>
> >>>I turn the navigation off on Maven projects. Can't stand the
> >>>project-reports, project-info roll-ups that make it harder to find
> >>>javadocs etc.
> >>
> >>Hear hear! Javadocs are not a "project report" for anyone who uses
> >>these sites. This one we can't blame on Maven, though, can we? I
> >>always assumed it was our setup of Maven.
> >>
> >
> > What exactly is broken here?
> > Sites that follow the instructions here
> > http://jakarta.apache.org/commons/building.html
> > or start with the sample nav here
> >
> http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/navigation.xml.sample
> > will link to current and previous release javadoc from the top level
> > nav. Pretty much all maven-generated commons sites do this now.
> >
> > The real challenge is what Stephen mentioned and Brett responed to,
> > which is how to maintain javadoc for past releases. Now these files
> > have to be manually pushed out and links custom coded in
> > navigation.xml.
> >
> > Phil
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
> You're missing the point here, Phil. It's working as someone intended,
> I'm sure, but the location of Javadocs buried under "Project Reports" is
> bad from an end-user usability perspective. Granted, consistency is a
> good thing and frequent users may eventually learn, but it would be
> better for javadocs to be a top-level menu item. The "Javadoc Report"
> is a report and is in the right place but the Javadocs themselves are
> misplaced.
It's trivial to just add a link to them in your navigation.xml file. See the
FileUpload, IO or Validator sites for examples.
--
Martin Cooper
---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [all] Maven, help or hinderance?
Posted by Steve Cohen <sc...@javactivity.org>.
Phil Steitz wrote:
> On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
>
>>Henri Yandell wrote:
>>
>>
>>>I turn the navigation off on Maven projects. Can't stand the
>>>project-reports, project-info roll-ups that make it harder to find
>>>javadocs etc.
>>
>>Hear hear! Javadocs are not a "project report" for anyone who uses
>>these sites. This one we can't blame on Maven, though, can we? I
>>always assumed it was our setup of Maven.
>>
>
> What exactly is broken here?
> Sites that follow the instructions here
> http://jakarta.apache.org/commons/building.html
> or start with the sample nav here
> http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/navigation.xml.sample
> will link to current and previous release javadoc from the top level
> nav. Pretty much all maven-generated commons sites do this now.
>
> The real challenge is what Stephen mentioned and Brett responed to,
> which is how to maintain javadoc for past releases. Now these files
> have to be manually pushed out and links custom coded in
> navigation.xml.
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
You're missing the point here, Phil. It's working as someone intended,
I'm sure, but the location of Javadocs buried under "Project Reports" is
bad from an end-user usability perspective. Granted, consistency is a
good thing and frequent users may eventually learn, but it would be
better for javadocs to be a top-level menu item. The "Javadoc Report"
is a report and is in the right place but the Javadocs themselves are
misplaced.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Phil Steitz <ph...@gmail.com>.
On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
> Henri Yandell wrote:
>
> > I turn the navigation off on Maven projects. Can't stand the
> > project-reports, project-info roll-ups that make it harder to find
> > javadocs etc.
>
> Hear hear! Javadocs are not a "project report" for anyone who uses
> these sites. This one we can't blame on Maven, though, can we? I
> always assumed it was our setup of Maven.
>
What exactly is broken here?
Sites that follow the instructions here
http://jakarta.apache.org/commons/building.html
or start with the sample nav here
http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/navigation.xml.sample
will link to current and previous release javadoc from the top level
nav. Pretty much all maven-generated commons sites do this now.
The real challenge is what Stephen mentioned and Brett responed to,
which is how to maintain javadoc for past releases. Now these files
have to be manually pushed out and links custom coded in
navigation.xml.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Henri Yandell <fl...@gmail.com>.
On 12/3/05, Henri Yandell <fl...@gmail.com> wrote:
> On 12/3/05, Stephen Colebourne <sc...@btopenworld.com> wrote:
> > >>Hate to be an "old fart" here but was ant really all that bad?
> >
> > Well it is a question isn't it? I suppose this is a flame thread, but I
> > have to ask, have we over the last two years or so actually got the
> > benefits that maven promised? And do we believe that maven2 will help?
Oh, forgot this bit.
If we do move back to Ant; I think we absolutely have to be looking
into the new features that let us standardise things. Moving back to a
time when each component had its own large build.xml that had to be
grokked to work on it is a definite step backwards.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
> okay, made it down to step 12 now.
>
> * Update Jakarta News Page Add a standard news item announcing
> the release to the current Jakarta news page. Look for the page whose
> name covers today's date in the site/xdocs/site/news directory. For
> example, the news for a release created in July 2004 should go into
> news-2004-2ndHalf.xml. This should be similar to the announcement you'll
> post later to email lists. Please remember to include a description of
> your component. Please also add a reminder about verifying signature.
> * Jakarta Welcome Page News items on the Jakarta welcome page are
> now automatically generated when you run "ant" to build the HTML files.
>
> However, there is no such file since 2nd quarter of 2005, and the
> index.xml mentions that this has now been retired, and the apache site
> now asks you to subscribe to a mailing list for Apache news. Am I right
> then in thinking that the second part of section 12 (quoted above) is
> now null and void?
>
<snip/>
You're almost home. Section 12 needs to be updated, I might propose a
patch if I find cycles tomorrow. But I wouldn't recommend disregarding
it.
You're looking for this news.xml file [1].
The background on the change not yet reflected in the Commons docs is
in this thread on general@ [2].
-Rahul
[1] http://svn.apache.org/repos/asf/jakarta/site/news.xml
[2] http://marc.theaimsgroup.com/?l=jakarta-general&m=112957612119868&w=2
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Martin Cooper <ma...@apache.org>.
On 12/3/05, Phil Steitz <ph...@gmail.com> wrote:
>
> On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
> > Nope, 1.6.
> >
> > This is sort of what I meant when I said it's harder to do these
> > releases. How is one supposed to KNOW what versions of these 30 or 40
> > plugins you have to have in order to build a release?
> >
> > Does Jakarta or Jakarta-commons have a page that tells you the minimum
> > maven setup needed to do a site release? If not, it probably should
> > have. I know this is a dynamic process, but this is nuts.
>
> Good point. Right now http://jakarta.apache.org/commons/building.html
> just contains the statement "Be sure to follow the instructions for
> upgrading the plugins to the latest releases."
Is it just me going blind, or are those instructions missing? All I see is a
link to a page that has a big list of plugins. I don't see instructions on
upgrading my plugins. ;-(
We could either doc
> the full set there or check in the output of maven --info as a text
> file in commons-build, making changes to that as necessary. I would
> recommend the second option, with a link on the "building" page. I
> will do that if no one beats me to it.
+1 to the second option. +1000 to a script that will automatically update my
Maven installation with those versions of the plugins. ;-)
--
Martin Cooper
>
> > And then the other direction. I shudder to think what would have
> > happened if I had tried maven 2.0.
> >
> Would have failed (because of POM spec and lots of other
> incompatibilities), as would the 1.1 beta. I agree we need to make
> version dependency clear.
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [all] Maven, help or hinderance?
Posted by Phil Steitz <ph...@gmail.com>.
On 12/4/05, Wendy Smoak <ws...@gmail.com> wrote:
> On 12/3/05, Phil Steitz <ph...@gmail.com> wrote:
>
> > You can get multiple jars by creating a multiproject. When it comes
> > to "non-standard" contents, again the answer is that if you want it,
> > probably some others do too, so opening tickets and submitting patches
> > is the right thing to do. That's how we got LICENSE.txt included
> > automatically, for example.
>
> Phil, this caught my eye because we (Struts with a Maven 1 build, and
> Sean Schofield working on a Maven 2 build for MyFaces) are _not_
> seeing LICENSE.txt get included automatically.
>
> Is it a recent addition that's not yet released? I looked around in
> JIRA but didn't find a relevant ticket. Was there one?
>
I can't now find the (old) tickets. Could be I am senile, but in any
case this should work with current released versions of the plugins.
Are you having trouble getting the LICENSE into the jar or the dist,
or both? Is it in the top level directory? Is it a multiproject?
NOTICE.txt still needs to be added explicity as a jar resource, IIRC.
OK...I *am* senile. Just found the ticket that I had in mind:
http://jira.codehaus.org/browse/MPANT-23
This was for the ant plugin (ironic in this thread ;-)
In any case, you should be getting LICENSE.txt in both the jar and
distros with nothing special required. Probably should take this to
maven user.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Martin Cooper <ma...@apache.org>.
On 12/3/05, Henri Yandell <fl...@gmail.com> wrote:
>
> On 12/3/05, Stephen Colebourne <sc...@btopenworld.com> wrote:
> > >>Hate to be an "old fart" here but was ant really all that bad?
> >
> > Well it is a question isn't it? I suppose this is a flame thread, but I
> > have to ask, have we over the last two years or so actually got the
> > benefits that maven promised? And do we believe that maven2 will help?
>
> It got simpler and easier, but then we started to push and it got
> harder. Then we noticed that there were problems (such as building for
> 1.2) and it got much harder.
>
> > When I think of maven, I see the POM as a good idea, raising the
> > abstraction level. The problem has always been what it does with the
> > POM.
>
> POMs are nice. Standardisation is nice, especially in the workplace,
> but also in something like Commons.
>
> Maven's been a huge plus in my dayjob because my colleagues have not
> needed to know Ant. They've also not needed to know Maven; we stay
> within the lines and it becomes a shiny red button. Helps that we
> don't have to release sites for each release too.
>
> Commons components like to colour outside the lines though, and our
> Maven usage is less cozy I think (and I say that as a Maven fan who
> often doesn't even have Ant installed on a development machine).
I'm really not sure what that paragraph means. ;-} "colour outside the
lines"? "less cozy"? Now that I'm used to it, I'm quite happy with Maven for
the components I work on (and Struts).
> I have a feeling that maven should have just been a set of ant
> > tasks that used the POM for info. Anyway, that design wasn't chosen.
>
> Was at first, but Ant proved to be too painful to use for the things
> they were trying to do, thus Jelly. Which bizarrely I've actually come
> to quite like :)
>
> > So what works well with maven?
>
> Standardisation of commands, pom, dependencies. I think the remote
> dependencies works really well, and I'm quite happy that I don't have
> to mess with build.properties files and putting jars in the right
> place on the dev box.
Huge +1 on that.
However, there are lots of things in Ant that do that now.
>
> > Well the end result site can be quite
> > reasonable. You still have to put in effort though, to fix
> > navigation.xml, cvs-usage.xml, issue-tracking.xml, add decent links to
> > each of the reports, manage the history of javadocs...
>
> I turn the navigation off on Maven projects. Can't stand the
> project-reports, project-info roll-ups that make it harder to find
> javadocs etc.
It's quite easy to leave them where they are (so that people who are used to
Maven sites know exactly where to find them) as well as add links to (some
of) them from elsewhere. The latest updates to the IO, Validator and
FileUpload sites do that, and I think the combination works well.
> Building has always seemed to be a nightmare though. I have no faith
> > that the jar or dist built by maven is the jar/dist that I want (I
> > always want something non-standard). And one output jar per project is
> > just crazy (see collections-testframework for example). And we still
> > don't have a cast-iron way to build a 1.2 compatible release using
> maven.
>
> I've not had problems, but I stay within the lines. At work we only
> use 1.4.x, so less worry about JDK versions and for osjava.org I let
> the JDK pain hit the small number of (elite) users :)
>
> Our need to release for Java 1.2 is a definite roadblock for Maven
> usage. I like the one output jar per project, it keeps them as honest
> components :) ie) no commons-collections-primitives without us
> deciding we want it. It also keeps it very standard; no worries about
> what the output of the component is, it's always
> groupId-artifactId-version.jar. So nice to do macro-Commons things
> like nightly builds.
>
> > So, are we holding on to maven because we feel we should? Are the
> > claimed benfits really there? And if I'm already using ant for releases,
> > why shouldn't we do as Hen suggests and generate our reports outside
> > maven too?
>
> And do we need that many reports :) Personally I think reports are the
> job of the nightly build system; the site is about links to released
> artifacts.
If the site-dev@ thing ever gets off the ground, the sites could be
refreshed on a daily basis, at which point, having the reports as part of
the site would be really nice.
Online javadocs for version 0.7 of a component are essential. Maybe
> the source xreference, but after that it gets less interesting.
>
> Not that I'm suggesting generating the reports outside of Maven as
> Stephen thought. I'm suggesting that we handcraft
> (Forrest/xdoc/xml/something) our website and use Maven to generate
> artifacts to be distributed and linked to, not the site itself.
No thanks. I'm happy using Maven for that, and very much dislike the
prospect of having to install, learn and use some other custom-built doodad.
--
Martin Cooper
Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [all] Maven, help or hinderance?
Posted by Phil Steitz <ph...@gmail.com>.
Links to maven tickets. Patches welcome!
>
> - crlf fix (sorry for all the noise, will be configurable to just fix
> the crlf part)
http://jira.codehaus.org/browse/MPDIST-28 (patched)
> - user.name not recognized by the jar plugin
http://jira.codehaus.org/browse/MPJAR-50
> - incorrect jdk reported in manifest when maven.compile.executable is used
http://jira.codehaus.org/browse/MPJAR-49
>
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Wendy Smoak <ws...@gmail.com>.
On 12/3/05, Phil Steitz <ph...@gmail.com> wrote:
> You can get multiple jars by creating a multiproject. When it comes
> to "non-standard" contents, again the answer is that if you want it,
> probably some others do too, so opening tickets and submitting patches
> is the right thing to do. That's how we got LICENSE.txt included
> automatically, for example.
Phil, this caught my eye because we (Struts with a Maven 1 build, and
Sean Schofield working on a Maven 2 build for MyFaces) are _not_
seeing LICENSE.txt get included automatically.
Is it a recent addition that's not yet released? I looked around in
JIRA but didn't find a relevant ticket. Was there one?
Thanks,
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Dennis Lundberg <de...@mdh.se>.
Phil Steitz wrote:
> On 12/18/05, Henri Yandell <fl...@gmail.com> wrote:
>> On 12/18/05, James Carman <ja...@carmanconsulting.com> wrote:
>>> Well, I think it's pretty obvious that we need to start a new maven plugin
>>> project for commons. So, why don't we just get started? Do we have to vote
>> +1 get started :)
>>
>>> on something like that? Are we going to make it a Maven2 or Maven1 plugin?
>> Nope, I think it's pretty clear that there's consensus to look into a plugin.
>>
>> Maven-1 makes sense, the work on a plugin is more about figuring out
>> what to put in there and not the technical difficulty of creating the
>> plugin. Unless it turns out that Maven-2 support makes it a lot
>> easier, or that's just the itch someone wants to scratch.
>>
>>> Do we want to make everyone upgrade their POMs?
>> We should be able to script it, as you suggest below. Given that
>> maven-2 can live side by side with maven-1, it just needs someone to
>> either go ahead and make a pom.xml for all of commons
I have started to look into this. I have a basic pom.xml for commons.
Not everything is working yet (notably gump and site deploy), but the
basics are there.
> I would need some convincing that introducing logical dependency on a
> top-level POM is a good thing. Could be this is a good idea - I just
> dont see it yet.
>
> , or to make a
>> list of the changes needed.
>>
> We should decide the version question "soon." Playing around a little
> with both 1 and 2 to see what would be involved in getting something
> to work is probably a good idea. In terms of "what goes in" we have a
> good start on the Wiki page
> http://wiki.apache.org/jakarta-commons/ReleaseShoppingList.
>
> One way to start thinking about the pros and cons of 1 vs 2 is to look
> at the release and site generation requirements (we might want to pull
> the second out into a separate Wiki page) and think through how "big"
> the new plugin(s) would have to be in each case and how much can be
> accomplished by patching exisiting plugins. We should try to keep the
> custom code base as small and simple as possible.
I think it is a good idea to separate the shopping list into two
sections: site and dist. Shall I have a go at it?
>>> Where will the code for the plugin live?
>> +1 for commons/proper/trunk/commons-plugin
>>
> Or .../commons-build/commons-plugin
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Henri Yandell <fl...@gmail.com>.
On 12/18/05, Phil Steitz <ph...@gmail.com> wrote:
> On 12/18/05, Henri Yandell <fl...@gmail.com> wrote:
> > maven-2 can live side by side with maven-1, it just needs someone to
> > either go ahead and make a pom.xml for all of commons
>
> I would need some convincing that introducing logical dependency on a
> top-level POM is a good thing. Could be this is a good idea - I just
> dont see it yet.
Sorry, I meant: make a pom.xml for each of commons. ie) many of them.
Mainly a reminder that we're all Commons coders, and no one is going
to kick up a fuss if someone makes a pom.xml for each component in
Commons.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Phil Steitz <ph...@gmail.com>.
On 12/18/05, Henri Yandell <fl...@gmail.com> wrote:
> On 12/18/05, James Carman <ja...@carmanconsulting.com> wrote:
> > Well, I think it's pretty obvious that we need to start a new maven plugin
> > project for commons. So, why don't we just get started? Do we have to vote
>
> +1 get started :)
>
> > on something like that? Are we going to make it a Maven2 or Maven1 plugin?
>
> Nope, I think it's pretty clear that there's consensus to look into a plugin.
>
> Maven-1 makes sense, the work on a plugin is more about figuring out
> what to put in there and not the technical difficulty of creating the
> plugin. Unless it turns out that Maven-2 support makes it a lot
> easier, or that's just the itch someone wants to scratch.
>
> > Do we want to make everyone upgrade their POMs?
>
> We should be able to script it, as you suggest below. Given that
> maven-2 can live side by side with maven-1, it just needs someone to
> either go ahead and make a pom.xml for all of commons
I would need some convincing that introducing logical dependency on a
top-level POM is a good thing. Could be this is a good idea - I just
dont see it yet.
, or to make a
> list of the changes needed.
>
We should decide the version question "soon." Playing around a little
with both 1 and 2 to see what would be involved in getting something
to work is probably a good idea. In terms of "what goes in" we have a
good start on the Wiki page
http://wiki.apache.org/jakarta-commons/ReleaseShoppingList.
One way to start thinking about the pros and cons of 1 vs 2 is to look
at the release and site generation requirements (we might want to pull
the second out into a separate Wiki page) and think through how "big"
the new plugin(s) would have to be in each case and how much can be
accomplished by patching exisiting plugins. We should try to keep the
custom code base as small and simple as possible.
> > Where will the code for the plugin live?
>
> +1 for commons/proper/trunk/commons-plugin
>
Or .../commons-build/commons-plugin
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Torsten Curdt <tc...@apache.org>.
>> Well, I think it's pretty obvious that we need to start a new
>> maven plugin
>> project for commons. So, why don't we just get started? Do we
>> have to vote
>
> +1 get started :)
;)
>> on something like that? Are we going to make it a Maven2 or
>> Maven1 plugin?
>
> Nope, I think it's pretty clear that there's consensus to look into
> a plugin.
>
> Maven-1 makes sense, the work on a plugin is more about figuring out
> what to put in there and not the technical difficulty of creating the
> plugin. Unless it turns out that Maven-2 support makes it a lot
> easier, or that's just the itch someone wants to scratch.
If possible we should encapsulate the plugin code
into a pojo. Then we can add a jelly wrapper around
it in maven1 and can also use it from maven2 ...at
least in theory :)
>> Do we want to make everyone upgrade their POMs?
>
> We should be able to script it, as you suggest below. Given that
> maven-2 can live side by side with maven-1, it just needs someone to
> either go ahead and make a pom.xml for all of commons, or to make a
> list of the changes needed.
I've already a very basic pom.xml for jci ...but
still need to figure out the details.
cheers
--
Torsten
Re: [all] Maven, help or hinderance?
Posted by Henri Yandell <fl...@gmail.com>.
On 12/18/05, James Carman <ja...@carmanconsulting.com> wrote:
> Well, I think it's pretty obvious that we need to start a new maven plugin
> project for commons. So, why don't we just get started? Do we have to vote
+1 get started :)
> on something like that? Are we going to make it a Maven2 or Maven1 plugin?
Nope, I think it's pretty clear that there's consensus to look into a plugin.
Maven-1 makes sense, the work on a plugin is more about figuring out
what to put in there and not the technical difficulty of creating the
plugin. Unless it turns out that Maven-2 support makes it a lot
easier, or that's just the itch someone wants to scratch.
> Do we want to make everyone upgrade their POMs?
We should be able to script it, as you suggest below. Given that
maven-2 can live side by side with maven-1, it just needs someone to
either go ahead and make a pom.xml for all of commons, or to make a
list of the changes needed.
> Where will the code for the plugin live?
+1 for commons/proper/trunk/commons-plugin
> One a side note, why isn't there an XSLT stylesheet for translating old POMs
> to new ones?
Dunno :) Definitely on my list of todo's. (well, it was going to be a
perl script or regexp list, but xslt makes sense).
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Henri Yandell <fl...@gmail.com>.
On 12/18/05, Dennis Lundberg <de...@mdh.se> wrote:
> Phil Steitz wrote:
> > On 12/18/05, Henri Yandell <fl...@gmail.com> wrote:
> >> +1. We need to start yelling at maven to fix/add them and dealing with
> >> the lower quality in the meantime instead of hacking them ourselves.
> >> Increasingly this'll mean being on maven2, so we should be trying to
> >> get there soon.
> >>
> > I would not use the term "yelling" since my experience has been that
> > the maven community is pretty responsive.
>
> That is my experience as well. I'm sure that patches from the commons
> community regarding best practices would be most welcome by the maven
> community. With a little help from Brett, I'm sure that this will work
> smoothly.
*grin* Yeah yeah, I'll watch my language :)
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Dennis Lundberg <de...@mdh.se>.
Phil Steitz wrote:
> On 12/18/05, Henri Yandell <fl...@gmail.com> wrote:
<snip/>
>> The plugin should solve this, along with scripts etc. Basically we
>> need to keep a focus on developer simplicity. The lower the barrier to
>> entry/momentum, the easier it'll be for us to develop.
>>
>>> in the past, we haven't been very effective (as we might) at feeding
>>> through these emerging best practises to maven. it's pretty much been
>> +1. We need to start yelling at maven to fix/add them and dealing with
>> the lower quality in the meantime instead of hacking them ourselves.
>> Increasingly this'll mean being on maven2, so we should be trying to
>> get there soon.
>>
> I would not use the term "yelling" since my experience has been that
> the maven community is pretty responsive.
That is my experience as well. I'm sure that patches from the commons
community regarding best practices would be most welcome by the maven
community. With a little help from Brett, I'm sure that this will work
smoothly.
>>> only phil. i'm going to try to be more active (and hope others will do
>>> the same). however, it is clear that one problem we have is that the
>>> feedback cycle is too inefficient: we can't afford to wait a month or
>>> two for new plugin releases and we're finding it hard to ensure everyone
>>> has the required versions. perhaps managing our plugin would made this
>>> easier.
>> Perhaps, though I think we can afford to wait a month or two. Years
>> maybe not, but it's not the end of the world if we knowlingly
>> distribute a few more jars without the Vendor-Distribution-Id for
>> example (or whatever that property name was).
>>
> See other response. We need to think through the options carefully:
>
> 1) patch maven 1 site, jar, dist plugins to do everything we need
> 2) patch above plugins to do most of what we need and tie together
> with a pair of lightweight commons plugins (say commons-site and
> commons-dist)
> 3) = 2) - 1)
> 4) = 1) recast in maven 2 setup (different base plugin structure)
> 5) = 3) recast in maven 2
>
> I agree with Hen that time delay getting maven plugin releases cranked
> should not be a big consideration. As I said above, the maven team is
> pretty responsive. What I think *is* a big consideration is the size
> and complexity of the plugin code that we will be taking on. I think
> we definitiely need something, but we need to KISS. The custom site
> jsl and nav stuff in commons-build is already a pain to maintain and
> lets face it, we would all rather spend our hacking time on the "real
> code" in the components.
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Phil Steitz <ph...@gmail.com>.
On 12/18/05, Henri Yandell <fl...@gmail.com> wrote:
<snip/>
> > there are another set of needs which fall under best practise. over the
> > last year (or two), the commons has started to come under intense
> > scrutiny. we are now the establishment and any times that we fall short
> > of the highest standards, we can expect to be held up as examples of bad
> > practise throughout the java community. i agree with stephen that our
> > releases now need to be of the highest possible standard. i'm no longer
> > to willing to accept lower quality releases as a result of using maven.
> > so again, these are not negotiable.
>
> Depends. Highest possible standard makes it harder for development
> momentum to happen. That's a given. If the level of quality is
> damaging to the momentum of the community, then I'm +1 for releasing a
> lower quality, keeping developer momentum is more important than code
> quality.
Sorry, but have to disagree with that. Of course, there is no
"technical tradeoff" here - i.e., if we get the right tools in place
we can have both, or at least have component code quality the only
thing that we need to worry about.
>
> The plugin should solve this, along with scripts etc. Basically we
> need to keep a focus on developer simplicity. The lower the barrier to
> entry/momentum, the easier it'll be for us to develop.
>
> > in the past, we haven't been very effective (as we might) at feeding
> > through these emerging best practises to maven. it's pretty much been
>
> +1. We need to start yelling at maven to fix/add them and dealing with
> the lower quality in the meantime instead of hacking them ourselves.
> Increasingly this'll mean being on maven2, so we should be trying to
> get there soon.
>
I would not use the term "yelling" since my experience has been that
the maven community is pretty responsive.
> > only phil. i'm going to try to be more active (and hope others will do
> > the same). however, it is clear that one problem we have is that the
> > feedback cycle is too inefficient: we can't afford to wait a month or
> > two for new plugin releases and we're finding it hard to ensure everyone
> > has the required versions. perhaps managing our plugin would made this
> > easier.
>
> Perhaps, though I think we can afford to wait a month or two. Years
> maybe not, but it's not the end of the world if we knowlingly
> distribute a few more jars without the Vendor-Distribution-Id for
> example (or whatever that property name was).
>
See other response. We need to think through the options carefully:
1) patch maven 1 site, jar, dist plugins to do everything we need
2) patch above plugins to do most of what we need and tie together
with a pair of lightweight commons plugins (say commons-site and
commons-dist)
3) = 2) - 1)
4) = 1) recast in maven 2 setup (different base plugin structure)
5) = 3) recast in maven 2
I agree with Hen that time delay getting maven plugin releases cranked
should not be a big consideration. As I said above, the maven team is
pretty responsive. What I think *is* a big consideration is the size
and complexity of the plugin code that we will be taking on. I think
we definitiely need something, but we need to KISS. The custom site
jsl and nav stuff in commons-build is already a pain to maintain and
lets face it, we would all rather spend our hacking time on the "real
code" in the components.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Henri Yandell <fl...@gmail.com>.
On 12/18/05, robert burrell donkin <ro...@blueyonder.co.uk> wrote:
> i think that there are two different kinds of specific need here. IMO
> both are not negotiable (for different reasons).
>
> the ASF has a few specific needs which maven either does not provide at
> the moment (for example, NOTICE.xml) or which maven should not provide
> since they are too specific to the ASF (for example, the symlink build
> structure). these needs are non-negotiable.
>
> i think that these needs are best satisfied by the creation of a jakarta
> or apache plug-in as suggested by brett.
Somewhat. Things like being on a weird set of plugin versions just
needs to be rolled back to the known version, unless it's transparent
to the user due to the commons-plugin dependencies.
> there are another set of needs which fall under best practise. over the
> last year (or two), the commons has started to come under intense
> scrutiny. we are now the establishment and any times that we fall short
> of the highest standards, we can expect to be held up as examples of bad
> practise throughout the java community. i agree with stephen that our
> releases now need to be of the highest possible standard. i'm no longer
> to willing to accept lower quality releases as a result of using maven.
> so again, these are not negotiable.
Depends. Highest possible standard makes it harder for development
momentum to happen. That's a given. If the level of quality is
damaging to the momentum of the community, then I'm +1 for releasing a
lower quality, keeping developer momentum is more important than code
quality.
The plugin should solve this, along with scripts etc. Basically we
need to keep a focus on developer simplicity. The lower the barrier to
entry/momentum, the easier it'll be for us to develop.
> in the past, we haven't been very effective (as we might) at feeding
> through these emerging best practises to maven. it's pretty much been
+1. We need to start yelling at maven to fix/add them and dealing with
the lower quality in the meantime instead of hacking them ourselves.
Increasingly this'll mean being on maven2, so we should be trying to
get there soon.
> only phil. i'm going to try to be more active (and hope others will do
> the same). however, it is clear that one problem we have is that the
> feedback cycle is too inefficient: we can't afford to wait a month or
> two for new plugin releases and we're finding it hard to ensure everyone
> has the required versions. perhaps managing our plugin would made this
> easier.
Perhaps, though I think we can afford to wait a month or two. Years
maybe not, but it's not the end of the world if we knowlingly
distribute a few more jars without the Vendor-Distribution-Id for
example (or whatever that property name was).
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Dennis Lundberg <de...@mdh.se>.
James Carman wrote:
> Well, I think it's pretty obvious that we need to start a new maven plugin
> project for commons. So, why don't we just get started? Do we have to vote
> on something like that? Are we going to make it a Maven2 or Maven1 plugin?
This is something that we need to decide before we get started. The
plugin architecture is quite different between maven 1 and 2.
> Do we want to make everyone upgrade their POMs? Where will the code for the
> plugin live?
>
> One a side note, why isn't there an XSLT stylesheet for translating old POMs
> to new ones? You'd think that'd be pretty easy to do to at least get one
> that runs in Maven2. Anyway, that's just my rant from my experience trying
> to Maven2-ize commons-proxy at one time. Now, back to our normally
> scheduled programming. :-)
There is work being done on some sort of conversion utility over in
maven land.
> -----Original Message-----
> From: robert burrell donkin [mailto:robertburrelldonkin@blueyonder.co.uk]
> Sent: Sunday, December 18, 2005 4:52 AM
> To: Jakarta Commons Developers List
> Subject: Re: [all] Maven, help or hinderance?
>
> On Sat, 2005-12-17 at 01:16 -0500, Henri Yandell wrote:
>> I just got coding on Commons stuff again after a bit of an absence.
>> UGH! I don't mean to diss the good work that people have put in on
>> adapting maven to fit what we want, but given that I use maven daily
>> at work and with osjava hacking, it's amazing how complex this seems.
>>
>> As I said, it's not the fault of those making the impossible possible,
>> rather I think it's that we need to give up some of our desires and
>> simplify our usage of Maven. ie) our very specific needs need to be
>> challenged and made to justify themselves.
>>
>> Maybe I'm being a bit harsh :)
>
> i think that there are two different kinds of specific need here. IMO
> both are not negotiable (for different reasons).
>
> the ASF has a few specific needs which maven either does not provide at
> the moment (for example, NOTICE.xml) or which maven should not provide
> since they are too specific to the ASF (for example, the symlink build
> structure). these needs are non-negotiable.
>
> i think that these needs are best satisfied by the creation of a jakarta
> or apache plug-in as suggested by brett.
>
> there are another set of needs which fall under best practise. over the
> last year (or two), the commons has started to come under intense
> scrutiny. we are now the establishment and any times that we fall short
> of the highest standards, we can expect to be held up as examples of bad
> practise throughout the java community. i agree with stephen that our
> releases now need to be of the highest possible standard. i'm no longer
> to willing to accept lower quality releases as a result of using maven.
> so again, these are not negotiable.
>
> in the past, we haven't been very effective (as we might) at feeding
> through these emerging best practises to maven. it's pretty much been
> only phil. i'm going to try to be more active (and hope others will do
> the same). however, it is clear that one problem we have is that the
> feedback cycle is too inefficient: we can't afford to wait a month or
> two for new plugin releases and we're finding it hard to ensure everyone
> has the required versions. perhaps managing our plugin would made this
> easier.
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [all] Maven, help or hinderance?
Posted by James Carman <ja...@carmanconsulting.com>.
Well, I think it's pretty obvious that we need to start a new maven plugin
project for commons. So, why don't we just get started? Do we have to vote
on something like that? Are we going to make it a Maven2 or Maven1 plugin?
Do we want to make everyone upgrade their POMs? Where will the code for the
plugin live?
One a side note, why isn't there an XSLT stylesheet for translating old POMs
to new ones? You'd think that'd be pretty easy to do to at least get one
that runs in Maven2. Anyway, that's just my rant from my experience trying
to Maven2-ize commons-proxy at one time. Now, back to our normally
scheduled programming. :-)
-----Original Message-----
From: robert burrell donkin [mailto:robertburrelldonkin@blueyonder.co.uk]
Sent: Sunday, December 18, 2005 4:52 AM
To: Jakarta Commons Developers List
Subject: Re: [all] Maven, help or hinderance?
On Sat, 2005-12-17 at 01:16 -0500, Henri Yandell wrote:
> I just got coding on Commons stuff again after a bit of an absence.
> UGH! I don't mean to diss the good work that people have put in on
> adapting maven to fit what we want, but given that I use maven daily
> at work and with osjava hacking, it's amazing how complex this seems.
>
> As I said, it's not the fault of those making the impossible possible,
> rather I think it's that we need to give up some of our desires and
> simplify our usage of Maven. ie) our very specific needs need to be
> challenged and made to justify themselves.
>
> Maybe I'm being a bit harsh :)
i think that there are two different kinds of specific need here. IMO
both are not negotiable (for different reasons).
the ASF has a few specific needs which maven either does not provide at
the moment (for example, NOTICE.xml) or which maven should not provide
since they are too specific to the ASF (for example, the symlink build
structure). these needs are non-negotiable.
i think that these needs are best satisfied by the creation of a jakarta
or apache plug-in as suggested by brett.
there are another set of needs which fall under best practise. over the
last year (or two), the commons has started to come under intense
scrutiny. we are now the establishment and any times that we fall short
of the highest standards, we can expect to be held up as examples of bad
practise throughout the java community. i agree with stephen that our
releases now need to be of the highest possible standard. i'm no longer
to willing to accept lower quality releases as a result of using maven.
so again, these are not negotiable.
in the past, we haven't been very effective (as we might) at feeding
through these emerging best practises to maven. it's pretty much been
only phil. i'm going to try to be more active (and hope others will do
the same). however, it is clear that one problem we have is that the
feedback cycle is too inefficient: we can't afford to wait a month or
two for new plugin releases and we're finding it hard to ensure everyone
has the required versions. perhaps managing our plugin would made this
easier.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sat, 2005-12-17 at 01:16 -0500, Henri Yandell wrote:
> I just got coding on Commons stuff again after a bit of an absence.
> UGH! I don't mean to diss the good work that people have put in on
> adapting maven to fit what we want, but given that I use maven daily
> at work and with osjava hacking, it's amazing how complex this seems.
>
> As I said, it's not the fault of those making the impossible possible,
> rather I think it's that we need to give up some of our desires and
> simplify our usage of Maven. ie) our very specific needs need to be
> challenged and made to justify themselves.
>
> Maybe I'm being a bit harsh :)
i think that there are two different kinds of specific need here. IMO
both are not negotiable (for different reasons).
the ASF has a few specific needs which maven either does not provide at
the moment (for example, NOTICE.xml) or which maven should not provide
since they are too specific to the ASF (for example, the symlink build
structure). these needs are non-negotiable.
i think that these needs are best satisfied by the creation of a jakarta
or apache plug-in as suggested by brett.
there are another set of needs which fall under best practise. over the
last year (or two), the commons has started to come under intense
scrutiny. we are now the establishment and any times that we fall short
of the highest standards, we can expect to be held up as examples of bad
practise throughout the java community. i agree with stephen that our
releases now need to be of the highest possible standard. i'm no longer
to willing to accept lower quality releases as a result of using maven.
so again, these are not negotiable.
in the past, we haven't been very effective (as we might) at feeding
through these emerging best practises to maven. it's pretty much been
only phil. i'm going to try to be more active (and hope others will do
the same). however, it is clear that one problem we have is that the
feedback cycle is too inefficient: we can't afford to wait a month or
two for new plugin releases and we're finding it hard to ensure everyone
has the required versions. perhaps managing our plugin would made this
easier.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Henri Yandell <fl...@gmail.com>.
I just got coding on Commons stuff again after a bit of an absence.
UGH! I don't mean to diss the good work that people have put in on
adapting maven to fit what we want, but given that I use maven daily
at work and with osjava hacking, it's amazing how complex this seems.
As I said, it's not the fault of those making the impossible possible,
rather I think it's that we need to give up some of our desires and
simplify our usage of Maven. ie) our very specific needs need to be
challenged and made to justify themselves.
Maybe I'm being a bit harsh :)
Hen
On 12/11/05, Dion Gillard <di...@gmail.com> wrote:
> From what I've seen of maven2, our site and dist problems will still
> exist in m2.
> We have very specific needs for both of these issues, and I feel a
> better solution in either m1 or m2 would be to codify the needs into
> one or more plugins.
>
> The release process definitely fits into this category.
>
> We definitely need to make it easier to get new people involved. I'm
> not sure using a brand new product (maven2) will help here.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Dion Gillard <di...@gmail.com>.
On 12/12/05, Phil Steitz <ph...@gmail.com> wrote:
> On 12/11/05, Brett Porter <br...@apache.org> wrote:
> > robert burrell donkin wrote:
> > > IMO the critical issues are releases and the site. look's like hen's on
> > > top of the site issue but i'd like to pick up on the releases issue.
> > >
> > > i've never been happy with the maven dist and try to avoid using it. the
> > > commons has ended up with lots of shared customization. this is now
> > > getting too much. ensuring that commons releases are up to the required
> > > standard is taking far too much energy. i think that this needs to
> > > change: we need a new strategy. we need to invest time in automation to
> > > save time later and maven is a good match for this problem.
> >
> > I totally agree. The Maven2 assembly plugin allows simpler customisation
> > of the distribution goals, and the other manual steps like signing the
> > release are being addressed (see commons-openpgp).
> >
> > I'm happy to use commons as a test case for both site and release
> > improvements.
> >
> > > in theory, it would be better to work by feeding back our requirements
> > > into maven.
> >
> > +1
> >
>
> +1 from me as well. We have had very good success, IMHO, getting
> enhancements into maven to support commons needs over the past couple
> of years and I see no signs that it is getting more difficult for us.
> Just like here, the key is to invest some in creating tickets and
> ideally patches and follow up a little.
>
> > >>I think the main reason not to move to Maven 2 yet is that it would
> > >>fragment commons, which would be an issue. At the least there should be
> > >>parallel builds.
> > >
> > >
> > > could you expand on this a little?
> >
> > I just expected that people would not like to have different ways to
> > build different components, so introducing parallel builds might be the
> > best way to start introducing m2. But as far as what commons needs,
> > Maven 2 should cover more than what m1 does now.
> >
>
> Can you expand a little more on this, Brett? If maven 2 will cleanly
> solve our site and dist problems, it might be best to bite the bullett
> and put our energies there. Specifically, we need to be able to do
> "maven dist" and meet all the requirments here:
> http://wiki.apache.org/jakarta-commons/ReleaseChecking
> and we need "maven site" to generate a site with the common l & f
> currently kludged together in commons-build. Everything beyond that
> is gravy ;-)
>From what I've seen of maven2, our site and dist problems will still
exist in m2.
We have very specific needs for both of these issues, and I feel a
better solution in either m1 or m2 would be to codify the needs into
one or more plugins.
The release process definitely fits into this category.
We definitely need to make it easier to get new people involved. I'm
not sure using a brand new product (maven2) will help here.
--
http://www.multitask.com.au/people/dion/
"You are going to let the fear of poverty govern your life and your
reward will be that you will eat, but you will not live." - George
Bernard Shaw
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2005-12-11 at 11:16 -0700, Phil Steitz wrote:
> On 12/11/05, Brett Porter <br...@apache.org> wrote:
> > robert burrell donkin wrote:
<snip>
> > >>I think the main reason not to move to Maven 2 yet is that it would
> > >>fragment commons, which would be an issue. At the least there should be
> > >>parallel builds.
> > >
> > >
> > > could you expand on this a little?
> >
> > I just expected that people would not like to have different ways to
> > build different components, so introducing parallel builds might be the
> > best way to start introducing m2. But as far as what commons needs,
> > Maven 2 should cover more than what m1 does now.
> >
>
> Can you expand a little more on this, Brett? If maven 2 will cleanly
> solve our site and dist problems, it might be best to bite the bullett
> and put our energies there. Specifically, we need to be able to do
> "maven dist" and meet all the requirments here:
> http://wiki.apache.org/jakarta-commons/ReleaseChecking
> and we need "maven site" to generate a site with the common l & f
> currently kludged together in commons-build. Everything beyond that
> is gravy ;-)
+1
we've reached a bit of a critical point now
we can't scaling: we rely on a small number of people who understand how
to create good releases and maintain the site build but we really need
to add new committers and expand the community.
it's easy to reorganize short term priorities if we can see that we be
able to solve some of the problems which have been sapping our energy
and enthusiasm. maintain two builds (though) will just become yet
another chore.
in a way, commons is easy since we insist that the component websites
are built in a particular fashion. as for releases, we've had so many
releases in recent times take months and months for technical reasons
which could be addressed by a tool i think that any solution would have
a big take up.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Brett Porter <br...@apache.org>.
Phil Steitz wrote:
> Can you expand a little more on this, Brett? If maven 2 will cleanly
> solve our site and dist problems, it might be best to bite the bullett
> and put our energies there. Specifically, we need to be able to do
> "maven dist" and meet all the requirments here:
> http://wiki.apache.org/jakarta-commons/ReleaseChecking
> and we need "maven site" to generate a site with the common l & f
> currently kludged together in commons-build. Everything beyond that
> is gravy ;-)
:)
There'll still be some things to straighten out, but its certainly
acheivable.
I've started filling out more details here:
* http://wiki.apache.org/jakarta-commons/ReleaseShoppingList
* http://docs.codehaus.org/display/MAVEN/Sites+and+Inheritence
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Phil Steitz <ph...@gmail.com>.
On 12/11/05, Brett Porter <br...@apache.org> wrote:
> robert burrell donkin wrote:
> > IMO the critical issues are releases and the site. look's like hen's on
> > top of the site issue but i'd like to pick up on the releases issue.
> >
> > i've never been happy with the maven dist and try to avoid using it. the
> > commons has ended up with lots of shared customization. this is now
> > getting too much. ensuring that commons releases are up to the required
> > standard is taking far too much energy. i think that this needs to
> > change: we need a new strategy. we need to invest time in automation to
> > save time later and maven is a good match for this problem.
>
> I totally agree. The Maven2 assembly plugin allows simpler customisation
> of the distribution goals, and the other manual steps like signing the
> release are being addressed (see commons-openpgp).
>
> I'm happy to use commons as a test case for both site and release
> improvements.
>
> > in theory, it would be better to work by feeding back our requirements
> > into maven.
>
> +1
>
+1 from me as well. We have had very good success, IMHO, getting
enhancements into maven to support commons needs over the past couple
of years and I see no signs that it is getting more difficult for us.
Just like here, the key is to invest some in creating tickets and
ideally patches and follow up a little.
> >>I think the main reason not to move to Maven 2 yet is that it would
> >>fragment commons, which would be an issue. At the least there should be
> >>parallel builds.
> >
> >
> > could you expand on this a little?
>
> I just expected that people would not like to have different ways to
> build different components, so introducing parallel builds might be the
> best way to start introducing m2. But as far as what commons needs,
> Maven 2 should cover more than what m1 does now.
>
Can you expand a little more on this, Brett? If maven 2 will cleanly
solve our site and dist problems, it might be best to bite the bullett
and put our energies there. Specifically, we need to be able to do
"maven dist" and meet all the requirments here:
http://wiki.apache.org/jakarta-commons/ReleaseChecking
and we need "maven site" to generate a site with the common l & f
currently kludged together in commons-build. Everything beyond that
is gravy ;-)
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Brett Porter <br...@apache.org>.
robert burrell donkin wrote:
> IMO the critical issues are releases and the site. look's like hen's on
> top of the site issue but i'd like to pick up on the releases issue.
>
> i've never been happy with the maven dist and try to avoid using it. the
> commons has ended up with lots of shared customization. this is now
> getting too much. ensuring that commons releases are up to the required
> standard is taking far too much energy. i think that this needs to
> change: we need a new strategy. we need to invest time in automation to
> save time later and maven is a good match for this problem.
I totally agree. The Maven2 assembly plugin allows simpler customisation
of the distribution goals, and the other manual steps like signing the
release are being addressed (see commons-openpgp).
I'm happy to use commons as a test case for both site and release
improvements.
> in theory, it would be better to work by feeding back our requirements
> into maven.
+1
>>I think the main reason not to move to Maven 2 yet is that it would
>>fragment commons, which would be an issue. At the least there should be
>>parallel builds.
>
>
> could you expand on this a little?
I just expected that people would not like to have different ways to
build different components, so introducing parallel builds might be the
best way to start introducing m2. But as far as what commons needs,
Maven 2 should cover more than what m1 does now.
> i've been wondering recently whether it's time to use svn:external to
> copy the directories required. would this change be helpful?
Maven 2 has solved the inheritence problem by using the repository as an
intermediatary, while still being able to discover local changes without
having to constantly publish there.
I'm not inclined to make svn:externals essential for anything. Its a
great convenience, but I think too limited for that sort of use.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2005-12-04 at 17:34 +1100, Brett Porter wrote:
> :)
>
> Phil Steitz wrote:
> > On 12/3/05, Stephen Colebourne <sc...@btopenworld.com> wrote:
> >> >>Hate to be an "old fart" here but was ant really all that bad?
ant's very good
the problem is standardisation: it's a PITA to have to change the build
scripts for lots of simple components.
> I had to laugh seeing this topic crop up. The problems were with site
> generation, as mentioned in another thread - something that wouldn't
> exist in Ant without another tool that would likely come with its own
> set of problems.
+1
the real question is: can we work more productively with maven in the
future than by switching to some other platform. IMHO this comes down to
communities. i don't think that we can go forward with the same
relationship that we've had in the past but there seems to be enough
good will (on both sides) to give it a chance.
IMO the critical issues are releases and the site. look's like hen's on
top of the site issue but i'd like to pick up on the releases issue.
i've never been happy with the maven dist and try to avoid using it. the
commons has ended up with lots of shared customization. this is now
getting too much. ensuring that commons releases are up to the required
standard is taking far too much energy. i think that this needs to
change: we need a new strategy. we need to invest time in automation to
save time later and maven is a good match for this problem.
we're increasingly finding that we have quite exacting requirements for
both the site and (especially) for releases. these requirements are
becoming less and less negotiable.
in theory, it would be better to work by feeding back our requirements
into maven. in practise, this hasn't been all that effective so far. i
suppose that the question is whether the maven community would be
willing to accept patches to allow dist to do what we need it to do or
whether it would make more sense for a jakarta-dist to be created. we're
also likely to need quick release cycles or ask that people build from
source and install locally.
opinions?
> > I would not recommend a wholesale move to maven 2 at this time, as the
> > plugins are still getting completed and I am afraid the frustration
> > level would actually get worse if we started going there immediately.
> > I think that if we solve a few simple problems with maven 1 and update
> > the docs, we can make things easy enough for RMs and volunteers both.
>
> I think the main reason not to move to Maven 2 yet is that it would
> fragment commons, which would be an issue. At the least there should be
> parallel builds.
could you expand on this a little?
> > At apachecon, Brett and I are going to work on finding a better way to
> > share navigation structures across sites. The current XML entities
> > approach is going to break in maven 1.1 and is also a bit confusing.
> > All are welcome to join us, or obviously to post ideas on how to do
> > this.
+1
at the time, entities seemed like a quick and cheap way of achieving our
goals. maven was in flux and it would have been a big political and
personal commitment to change maven to meet our goals.
but times change and the time seems right to adopt a more permanent
solution. we're probably also at the stage where we're going to need to
be a bit more prescriptive so that the process can be documented and
disseminated more easily.
> Indeed. I was actually going to discuss with relation to Maven 2.0,
> though, as its a much better platform for achieving the goals. I was
> already thinking I'd use commons as the test platform for multiproject
> site support. Hopefully this will also give me the chance to inject some
> effort into site-dev.
>
> As for nightly builds and site publishing - I'm more than happy to drop
> any commons builds that don't extend commons-build into continuum on our
> zone and publish jars and/or sites, and grant access to people who are
> interested in working with it. I hadn't extended that offer yet as I'm
> still waiting on an official answer on the permanency of the zone setup
> - but I think that AC will see that come to pass too.
i've been wondering recently whether it's time to use svn:external to
copy the directories required. would this change be helpful?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Brett Porter <br...@apache.org>.
:)
Phil Steitz wrote:
> On 12/3/05, Stephen Colebourne <sc...@btopenworld.com> wrote:
>> >>Hate to be an "old fart" here but was ant really all that bad?
I had to laugh seeing this topic crop up. The problems were with site
generation, as mentioned in another thread - something that wouldn't
exist in Ant without another tool that would likely come with its own
set of problems.
I agree that old releases should be reproducible and its an issue that
its not here (at least when it comes to site generation). I can assure
you we took this into consideration for Maven 2.
Maven 1.0 *should* be able to use plugin dependencies - I haven't looked
into why it wasn't working for Phil.
I'm not sure what the best solution is to reproducing a build that was
in CVS at the time, that is now in SVN.
Anyway, I'm too biased to participate in a flame thread, but I'll add
something constructive...
> I would not recommend a wholesale move to maven 2 at this time, as the
> plugins are still getting completed and I am afraid the frustration
> level would actually get worse if we started going there immediately.
> I think that if we solve a few simple problems with maven 1 and update
> the docs, we can make things easy enough for RMs and volunteers both.
I think the main reason not to move to Maven 2 yet is that it would
fragment commons, which would be an issue. At the least there should be
parallel builds.
>
> At apachecon, Brett and I are going to work on finding a better way to
> share navigation structures across sites. The current XML entities
> approach is going to break in maven 1.1 and is also a bit confusing.
> All are welcome to join us, or obviously to post ideas on how to do
> this.
>
Indeed. I was actually going to discuss with relation to Maven 2.0,
though, as its a much better platform for achieving the goals. I was
already thinking I'd use commons as the test platform for multiproject
site support. Hopefully this will also give me the chance to inject some
effort into site-dev.
As for nightly builds and site publishing - I'm more than happy to drop
any commons builds that don't extend commons-build into continuum on our
zone and publish jars and/or sites, and grant access to people who are
interested in working with it. I hadn't extended that offer yet as I'm
still waiting on an official answer on the permanency of the zone setup
- but I think that AC will see that come to pass too.
Hope this helps.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Phil Steitz <ph...@gmail.com>.
On 12/3/05, Stephen Colebourne <sc...@btopenworld.com> wrote:
> >>Hate to be an "old fart" here but was ant really all that bad?
>
> Well it is a question isn't it? I suppose this is a flame thread, but I
> have to ask, have we over the last two years or so actually got the
> benefits that maven promised? And do we believe that maven2 will help?
>
Good question and good time to ask it, as maven 2 has just been
released and there is no denying that the current site generation is
creaking and painful.
> When I think of maven, I see the POM as a good idea, raising the
> abstraction level. The problem has always been what it does with the
> POM. I have a feeling that maven should have just been a set of ant
> tasks that used the POM for info. Anyway, that design wasn't chosen.
>
Well, one could argue that that is more or less what was implemented
in maven 1, with the tasks scripted using jelly. Have a look at the
sources for the dist plugin, for example, and you will see lots of ant
tasks scripted in jelly.
> So what works well with maven? Well the end result site can be quite
> reasonable. You still have to put in effort though, to fix
> navigation.xml, cvs-usage.xml, issue-tracking.xml, add decent links to
> each of the reports, manage the history of javadocs...
>
This is all true, but we can fairly easily share the results of this
effort. Sure, we may need to copy and modify the templates, but if
you commit examples to commons-build that will make it easier. The
maven community is also *very* open to applying patches to support new
requirements - both for maven 2 and maven 1.
> Building has always seemed to be a nightmare though. I have no faith
> that the jar or dist built by maven is the jar/dist that I want (I
> always want something non-standard). And one output jar per project is
> just crazy (see collections-testframework for example). And we still
> don't have a cast-iron way to build a 1.2 compatible release using maven.
You can get multiple jars by creating a multiproject. When it comes
to "non-standard" contents, again the answer is that if you want it,
probably some others do too, so opening tickets and submitting patches
is the right thing to do. That's how we got LICENSE.txt included
automatically, for example. Just opening the ticket helps, even if you
have no interest in working on the patch. I am now working on three
patches to support commons in maven 1 now
- crlf fix (sorry for all the noise, will be configurable to just fix
the crlf part)
- user.name not recognized by the jar plugin
- incorrect jdk reported in manifest when maven.compile.executable is used
It will be easier if we get these things fixed in maven rather than
duplicating the work all over the place in custom ant scripts, IMHO.
>
> So, are we holding on to maven because we feel we should? Are the
> claimed benfits really there? And if I'm already using ant for releases,
> why shouldn't we do as Hen suggests and generate our reports outside
> maven too?
Way too much work, IMHO and a PITA even worse than we currently have
to maintain it. To me, maven does a great job handling dependencies,
generating reports and web sites, and making release distros.
Admittedly, we are still not where we need to be in commons on the
last items; but I see less work getting maven to work than starting
from scratch with Ant and Velocity / XSLT. I also like the sshDeploy
and jar deploy capabilities.
I would not recommend a wholesale move to maven 2 at this time, as the
plugins are still getting completed and I am afraid the frustration
level would actually get worse if we started going there immediately.
I think that if we solve a few simple problems with maven 1 and update
the docs, we can make things easy enough for RMs and volunteers both.
At apachecon, Brett and I are going to work on finding a better way to
share navigation structures across sites. The current XML entities
approach is going to break in maven 1.1 and is also a bit confusing.
All are welcome to join us, or obviously to post ideas on how to do
this.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Steve Cohen <sc...@javactivity.org>.
Henri Yandell wrote:
> I turn the navigation off on Maven projects. Can't stand the
> project-reports, project-info roll-ups that make it harder to find
> javadocs etc.
Hear hear! Javadocs are not a "project report" for anyone who uses
these sites. This one we can't blame on Maven, though, can we? I
always assumed it was our setup of Maven.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Henri Yandell <fl...@gmail.com>.
On 12/3/05, Stephen Colebourne <sc...@btopenworld.com> wrote:
> >>Hate to be an "old fart" here but was ant really all that bad?
>
> Well it is a question isn't it? I suppose this is a flame thread, but I
> have to ask, have we over the last two years or so actually got the
> benefits that maven promised? And do we believe that maven2 will help?
It got simpler and easier, but then we started to push and it got
harder. Then we noticed that there were problems (such as building for
1.2) and it got much harder.
> When I think of maven, I see the POM as a good idea, raising the
> abstraction level. The problem has always been what it does with the
> POM.
POMs are nice. Standardisation is nice, especially in the workplace,
but also in something like Commons.
Maven's been a huge plus in my dayjob because my colleagues have not
needed to know Ant. They've also not needed to know Maven; we stay
within the lines and it becomes a shiny red button. Helps that we
don't have to release sites for each release too.
Commons components like to colour outside the lines though, and our
Maven usage is less cozy I think (and I say that as a Maven fan who
often doesn't even have Ant installed on a development machine).
> I have a feeling that maven should have just been a set of ant
> tasks that used the POM for info. Anyway, that design wasn't chosen.
Was at first, but Ant proved to be too painful to use for the things
they were trying to do, thus Jelly. Which bizarrely I've actually come
to quite like :)
> So what works well with maven?
Standardisation of commands, pom, dependencies. I think the remote
dependencies works really well, and I'm quite happy that I don't have
to mess with build.properties files and putting jars in the right
place on the dev box.
However, there are lots of things in Ant that do that now.
> Well the end result site can be quite
> reasonable. You still have to put in effort though, to fix
> navigation.xml, cvs-usage.xml, issue-tracking.xml, add decent links to
> each of the reports, manage the history of javadocs...
I turn the navigation off on Maven projects. Can't stand the
project-reports, project-info roll-ups that make it harder to find
javadocs etc.
> Building has always seemed to be a nightmare though. I have no faith
> that the jar or dist built by maven is the jar/dist that I want (I
> always want something non-standard). And one output jar per project is
> just crazy (see collections-testframework for example). And we still
> don't have a cast-iron way to build a 1.2 compatible release using maven.
I've not had problems, but I stay within the lines. At work we only
use 1.4.x, so less worry about JDK versions and for osjava.org I let
the JDK pain hit the small number of (elite) users :)
Our need to release for Java 1.2 is a definite roadblock for Maven
usage. I like the one output jar per project, it keeps them as honest
components :) ie) no commons-collections-primitives without us
deciding we want it. It also keeps it very standard; no worries about
what the output of the component is, it's always
groupId-artifactId-version.jar. So nice to do macro-Commons things
like nightly builds.
> So, are we holding on to maven because we feel we should? Are the
> claimed benfits really there? And if I'm already using ant for releases,
> why shouldn't we do as Hen suggests and generate our reports outside
> maven too?
And do we need that many reports :) Personally I think reports are the
job of the nightly build system; the site is about links to released
artifacts.
Online javadocs for version 0.7 of a component are essential. Maybe
the source xreference, but after that it gets less interesting.
Not that I'm suggesting generating the reports outside of Maven as
Stephen thought. I'm suggesting that we handcraft
(Forrest/xdoc/xml/something) our website and use Maven to generate
artifacts to be distributed and linked to, not the site itself.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/5/05, Steve Cohen <sc...@javactivity.org> wrote:
<snip/>
> Logging on via ssh -1 works.
>
> Does apache accept protocol 2 ssh keys?
>
<snap/>
Atleast the RSA one, AFAICT.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Phil Steitz <ph...@gmail.com>.
On 12/5/05, Phil Steitz <ph...@gmail.com> wrote:
> <snip>
> >
> > Thanks for all your help. These last suggestions worked.
> >
> > I built the site, tested my changes, then pushed the site.
> >
> > I DON'T have my key set up. where do I do this, it's a pain to keep
> > typing in my password, but doable.
>
> As indicated on the "building" page, you should follow the
> instructions on the bottom of this page:
> http://www.apache.org/dev/cvs-on-unix.html
>
I see now that the link in section 8 of the "releasing" page to
instructions for this is broken. I think there used to be a
"how-to" which has moved or been deleted. We should fix that link -
just change to above - in any case.
Another thing that we should think about, given the comments about
automation, is moving the content in 16 up higher and making Windows
batch files to do the same thing as the shell scripts referenced
there. These scripts automate much of the drudgery in sections 2-4
and 7. I guess we could also try to get the dist plugin to do the 2-4
stuff, but IIRC there are problems integrating with the native OS
stuff required to handle keys and create sigs.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
Phil Steitz wrote:
> <snip>
>
>>Thanks for all your help. These last suggestions worked.
>>
>>I built the site, tested my changes, then pushed the site.
>>
>>I DON'T have my key set up. where do I do this, it's a pain to keep
>>typing in my password, but doable.
>
>
> As indicated on the "building" page, you should follow the
> instructions on the bottom of this page:
> http://www.apache.org/dev/cvs-on-unix.html
Right, I'd had this set up before. What I'd forgotten was I'd joined
another site that required protocol 2, and my config was set up that
way. But I'd only stored my protocol 1 key on apache.
Logging on via ssh -1 works.
Does apache accept protocol 2 ssh keys?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Phil Steitz <ph...@gmail.com>.
<snip>
>
> Thanks for all your help. These last suggestions worked.
>
> I built the site, tested my changes, then pushed the site.
>
> I DON'T have my key set up. where do I do this, it's a pain to keep
> typing in my password, but doable.
As indicated on the "building" page, you should follow the
instructions on the bottom of this page:
http://www.apache.org/dev/cvs-on-unix.html
>
> Also, fyi, in my pushing of the site, I saw gobs of
>
> [exec] chmod: some/file: Operation not permitted
>
> Is this something not set up properly in my account or an expected
> glitch? In any case somebody might want to check the chmod settings of
> the site now.
>
Can't check this now, perhaps someone else can and also recall what
causes this error message.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
Phil Steitz wrote:
> On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
>
>>Phil Steitz wrote:
>>
>>>On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
>>>
>>>
>>>>Martin Cooper wrote:
>>>>
>>>>
>>>>>On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Phil Steitz wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
>>>>>>
>>>>>>>>This is another inaccuracy in the instructions. Step 14 says the
>>>>>>>>dependencies are listed in STATUS.html. Net, at least doesn't have a
>>>>>>>>STATUS.html. These seem to be generated from project.xml.
>>>>>>>
>>>>>>>
>>>>>>>Good point. Patch / update welcome. It would be great if you could
>>>>>>>bundle up any other issues that you ran into into a patch or direct
>>>>>>>update for the building/releasing docs.
>>>>>>>
>>>>>>>Phil
>>>>>>>
>>>>>>
>>>>>>I will, Phil. But is the non-existence of STATUS.html common to all of
>>>>>>commons? If so, I will make the revisions myself. Incidentally, these
>>>>>>items are all handled now prior to cutting the release, not as post
>>>>>>release items.
>>>>>
>>>>>
>>>>>
>>>>>The STATUS files are a hold-over from the pre-Maven days. They were required
>>>>>because there was no POM / project.xml file in which the committer list
>>>>>could be maintained. Now that all of the components are using Maven, the
>>>>>STATUS files are pretty much obsolete.
>>>>>
>>>>>--
>>>>>Martin Cooper
>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>Thanks, Martin. I'll be happy to update the files myself, but where are
>>>>they? I see some files that look like old versions of the site in
>>>>commons-build's xdocs but they don't match what's on the site now.
>>>>
>>>>I've glanced all over the repository and haven't found the right place yet.
>>>
>>>
>>>The relevant files are in
>>>http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/xdocs/releases/
>>>maven site from /commons-build should generate the site locally for
>>>you, then maven site:sshdeploy to publish (assuming you have key set
>>>up)
>>>Make sure to check changes in before updating the site.
>>>
>>>Thanks!
>>>
>>>Phil
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>
>>Alas and alack.
>>More maven problems.
>>
>>Couldn't run maven site on commons-build
>>
>>Downloaded maven 1.0.2
>>Reinstalled the maven xdoc plugin 1.9.2
>>
>>get this:
>>
>>xdoc:jelly-transform:
>> [echo] en
>> [echo] The current Locale is the default one
>> [echo] Scanning '/home/scohen/commons-build/target/generated-xdocs'...
>> [echo] Generating
>>/home/scohen/commons-build/target/docs/license.html from
>>/home/scohen/commons-build/target/generated-xdocs/license.xml
>>
>>BUILD FAILED
>>File...... /home/scohen/.maven/cache/maven-xdoc-plugin-1.9.2/plugin.jelly
>>Element... j:include
>>Line...... 479
>>Column.... 58
>>file:/home/scohen/.maven/cache/maven-xdoc-plugin-1.9.2/plugin-resources/site.jsl:33:17:
>><jsl:stylesheet>
>>file:/home/scohen/.maven/cache/maven-xdoc-plugin-1.9.2/plugin-resources/site.jsl:156:57:
>><jsl:applyTemplates>
>>file:/home/scohen/.maven/cache/maven-xdoc-plugin-1.9.2/plugin-resources/site.jsl:240:105:
>><maven:property> You must define an attribute called 'defaultValue' for
>>this tag.
>>Total time: 10 seconds
>>Finished at: Sun Dec 04 22:09:51 CST 2005
>>
>>:-(
>>
>
> Are you sure you are executing maven from the the right directory -
> i.e., not above trunk?
>
> Also, you need the top-level directory to be named "commons-build"
>
> The second requirement can probably be removed by changing
>
> maven.xdoc.jsl=../commons-build/commons-site.jsl
> to
> maven.xdoc.jsl=commons-site.jsl
>
> In project.properties.
>
> Phil
>
Thanks for all your help. These last suggestions worked.
I built the site, tested my changes, then pushed the site.
I DON'T have my key set up. where do I do this, it's a pain to keep
typing in my password, but doable.
Also, fyi, in my pushing of the site, I saw gobs of
[exec] chmod: some/file: Operation not permitted
Is this something not set up properly in my account or an expected
glitch? In any case somebody might want to check the chmod settings of
the site now.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Phil Steitz <ph...@gmail.com>.
On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
> Phil Steitz wrote:
> > On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
> >
> >>Martin Cooper wrote:
> >>
> >>>On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
> >>>
> >>>
> >>>>Phil Steitz wrote:
> >>>>
> >>>>
> >>>>>On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
> >>>>
> >>>>>>This is another inaccuracy in the instructions. Step 14 says the
> >>>>>>dependencies are listed in STATUS.html. Net, at least doesn't have a
> >>>>>>STATUS.html. These seem to be generated from project.xml.
> >>>>>
> >>>>>
> >>>>>Good point. Patch / update welcome. It would be great if you could
> >>>>>bundle up any other issues that you ran into into a patch or direct
> >>>>>update for the building/releasing docs.
> >>>>>
> >>>>>Phil
> >>>>>
> >>>>
> >>>>I will, Phil. But is the non-existence of STATUS.html common to all of
> >>>>commons? If so, I will make the revisions myself. Incidentally, these
> >>>>items are all handled now prior to cutting the release, not as post
> >>>>release items.
> >>>
> >>>
> >>>
> >>>The STATUS files are a hold-over from the pre-Maven days. They were required
> >>>because there was no POM / project.xml file in which the committer list
> >>>could be maintained. Now that all of the components are using Maven, the
> >>>STATUS files are pretty much obsolete.
> >>>
> >>>--
> >>>Martin Cooper
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>
> >>>
> >>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>Thanks, Martin. I'll be happy to update the files myself, but where are
> >>they? I see some files that look like old versions of the site in
> >>commons-build's xdocs but they don't match what's on the site now.
> >>
> >>I've glanced all over the repository and haven't found the right place yet.
> >
> >
> > The relevant files are in
> > http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/xdocs/releases/
> > maven site from /commons-build should generate the site locally for
> > you, then maven site:sshdeploy to publish (assuming you have key set
> > up)
> > Make sure to check changes in before updating the site.
> >
> > Thanks!
> >
> > Phil
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
> Alas and alack.
> More maven problems.
>
> Couldn't run maven site on commons-build
>
> Downloaded maven 1.0.2
> Reinstalled the maven xdoc plugin 1.9.2
>
> get this:
>
> xdoc:jelly-transform:
> [echo] en
> [echo] The current Locale is the default one
> [echo] Scanning '/home/scohen/commons-build/target/generated-xdocs'...
> [echo] Generating
> /home/scohen/commons-build/target/docs/license.html from
> /home/scohen/commons-build/target/generated-xdocs/license.xml
>
> BUILD FAILED
> File...... /home/scohen/.maven/cache/maven-xdoc-plugin-1.9.2/plugin.jelly
> Element... j:include
> Line...... 479
> Column.... 58
> file:/home/scohen/.maven/cache/maven-xdoc-plugin-1.9.2/plugin-resources/site.jsl:33:17:
> <jsl:stylesheet>
> file:/home/scohen/.maven/cache/maven-xdoc-plugin-1.9.2/plugin-resources/site.jsl:156:57:
> <jsl:applyTemplates>
> file:/home/scohen/.maven/cache/maven-xdoc-plugin-1.9.2/plugin-resources/site.jsl:240:105:
> <maven:property> You must define an attribute called 'defaultValue' for
> this tag.
> Total time: 10 seconds
> Finished at: Sun Dec 04 22:09:51 CST 2005
>
> :-(
>
Are you sure you are executing maven from the the right directory -
i.e., not above trunk?
Also, you need the top-level directory to be named "commons-build"
The second requirement can probably be removed by changing
maven.xdoc.jsl=../commons-build/commons-site.jsl
to
maven.xdoc.jsl=commons-site.jsl
In project.properties.
Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
Phil Steitz wrote:
> On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
>
>>Martin Cooper wrote:
>>
>>>On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
>>>
>>>
>>>>Phil Steitz wrote:
>>>>
>>>>
>>>>>On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
>>>>
>>>>>>This is another inaccuracy in the instructions. Step 14 says the
>>>>>>dependencies are listed in STATUS.html. Net, at least doesn't have a
>>>>>>STATUS.html. These seem to be generated from project.xml.
>>>>>
>>>>>
>>>>>Good point. Patch / update welcome. It would be great if you could
>>>>>bundle up any other issues that you ran into into a patch or direct
>>>>>update for the building/releasing docs.
>>>>>
>>>>>Phil
>>>>>
>>>>
>>>>I will, Phil. But is the non-existence of STATUS.html common to all of
>>>>commons? If so, I will make the revisions myself. Incidentally, these
>>>>items are all handled now prior to cutting the release, not as post
>>>>release items.
>>>
>>>
>>>
>>>The STATUS files are a hold-over from the pre-Maven days. They were required
>>>because there was no POM / project.xml file in which the committer list
>>>could be maintained. Now that all of the components are using Maven, the
>>>STATUS files are pretty much obsolete.
>>>
>>>--
>>>Martin Cooper
>>>
>>>
>>>---------------------------------------------------------------------
>>>
>>>
>>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>Thanks, Martin. I'll be happy to update the files myself, but where are
>>they? I see some files that look like old versions of the site in
>>commons-build's xdocs but they don't match what's on the site now.
>>
>>I've glanced all over the repository and haven't found the right place yet.
>
>
> The relevant files are in
> http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/xdocs/releases/
> maven site from /commons-build should generate the site locally for
> you, then maven site:sshdeploy to publish (assuming you have key set
> up)
> Make sure to check changes in before updating the site.
>
> Thanks!
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
Alas and alack.
More maven problems.
Couldn't run maven site on commons-build
Downloaded maven 1.0.2
Reinstalled the maven xdoc plugin 1.9.2
get this:
xdoc:jelly-transform:
[echo] en
[echo] The current Locale is the default one
[echo] Scanning '/home/scohen/commons-build/target/generated-xdocs'...
[echo] Generating
/home/scohen/commons-build/target/docs/license.html from
/home/scohen/commons-build/target/generated-xdocs/license.xml
BUILD FAILED
File...... /home/scohen/.maven/cache/maven-xdoc-plugin-1.9.2/plugin.jelly
Element... j:include
Line...... 479
Column.... 58
file:/home/scohen/.maven/cache/maven-xdoc-plugin-1.9.2/plugin-resources/site.jsl:33:17:
<jsl:stylesheet>
file:/home/scohen/.maven/cache/maven-xdoc-plugin-1.9.2/plugin-resources/site.jsl:156:57:
<jsl:applyTemplates>
file:/home/scohen/.maven/cache/maven-xdoc-plugin-1.9.2/plugin-resources/site.jsl:240:105:
<maven:property> You must define an attribute called 'defaultValue' for
this tag.
Total time: 10 seconds
Finished at: Sun Dec 04 22:09:51 CST 2005
:-(
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Phil Steitz <ph...@gmail.com>.
On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
> Martin Cooper wrote:
> > On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
> >
> >>Phil Steitz wrote:
> >>
> >>>On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
> >>
> >>>>This is another inaccuracy in the instructions. Step 14 says the
> >>>>dependencies are listed in STATUS.html. Net, at least doesn't have a
> >>>>STATUS.html. These seem to be generated from project.xml.
> >>>
> >>>
> >>>Good point. Patch / update welcome. It would be great if you could
> >>>bundle up any other issues that you ran into into a patch or direct
> >>>update for the building/releasing docs.
> >>>
> >>>Phil
> >>>
> >>
> >>I will, Phil. But is the non-existence of STATUS.html common to all of
> >>commons? If so, I will make the revisions myself. Incidentally, these
> >>items are all handled now prior to cutting the release, not as post
> >>release items.
> >
> >
> >
> > The STATUS files are a hold-over from the pre-Maven days. They were required
> > because there was no POM / project.xml file in which the committer list
> > could be maintained. Now that all of the components are using Maven, the
> > STATUS files are pretty much obsolete.
> >
> > --
> > Martin Cooper
> >
> >
> > ---------------------------------------------------------------------
> >
> >>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> Thanks, Martin. I'll be happy to update the files myself, but where are
> they? I see some files that look like old versions of the site in
> commons-build's xdocs but they don't match what's on the site now.
>
> I've glanced all over the repository and haven't found the right place yet.
The relevant files are in
http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/xdocs/releases/
maven site from /commons-build should generate the site locally for
you, then maven site:sshdeploy to publish (assuming you have key set
up)
Make sure to check changes in before updating the site.
Thanks!
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
Martin Cooper wrote:
> On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
>
>>Phil Steitz wrote:
>>
>>>On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
>>
>>>>This is another inaccuracy in the instructions. Step 14 says the
>>>>dependencies are listed in STATUS.html. Net, at least doesn't have a
>>>>STATUS.html. These seem to be generated from project.xml.
>>>
>>>
>>>Good point. Patch / update welcome. It would be great if you could
>>>bundle up any other issues that you ran into into a patch or direct
>>>update for the building/releasing docs.
>>>
>>>Phil
>>>
>>
>>I will, Phil. But is the non-existence of STATUS.html common to all of
>>commons? If so, I will make the revisions myself. Incidentally, these
>>items are all handled now prior to cutting the release, not as post
>>release items.
>
>
>
> The STATUS files are a hold-over from the pre-Maven days. They were required
> because there was no POM / project.xml file in which the committer list
> could be maintained. Now that all of the components are using Maven, the
> STATUS files are pretty much obsolete.
>
> --
> Martin Cooper
>
>
> ---------------------------------------------------------------------
>
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
>
Thanks, Martin. I'll be happy to update the files myself, but where are
they? I see some files that look like old versions of the site in
commons-build's xdocs but they don't match what's on the site now.
I've glanced all over the repository and haven't found the right place yet.
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Martin Cooper <ma...@apache.org>.
On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
>
> Phil Steitz wrote:
> > On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
>
> >
> >>This is another inaccuracy in the instructions. Step 14 says the
> >>dependencies are listed in STATUS.html. Net, at least doesn't have a
> >>STATUS.html. These seem to be generated from project.xml.
> >
> >
> > Good point. Patch / update welcome. It would be great if you could
> > bundle up any other issues that you ran into into a patch or direct
> > update for the building/releasing docs.
> >
> > Phil
> >
> I will, Phil. But is the non-existence of STATUS.html common to all of
> commons? If so, I will make the revisions myself. Incidentally, these
> items are all handled now prior to cutting the release, not as post
> release items.
The STATUS files are a hold-over from the pre-Maven days. They were required
because there was no POM / project.xml file in which the committer list
could be maintained. Now that all of the components are using Maven, the
STATUS files are pretty much obsolete.
--
Martin Cooper
---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
Phil Steitz wrote:
> On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
>
>>This is another inaccuracy in the instructions. Step 14 says the
>>dependencies are listed in STATUS.html. Net, at least doesn't have a
>>STATUS.html. These seem to be generated from project.xml.
>
>
> Good point. Patch / update welcome. It would be great if you could
> bundle up any other issues that you ran into into a patch or direct
> update for the building/releasing docs.
>
> Phil
>
I will, Phil. But is the non-existence of STATUS.html common to all of
commons? If so, I will make the revisions myself. Incidentally, these
items are all handled now prior to cutting the release, not as post
release items.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Phil Steitz <ph...@gmail.com>.
On 12/4/05, Steve Cohen <sc...@javactivity.org> wrote:
> Dion Gillard wrote:
>
> >
> > If we really do *have to have* a specific release of a plugin, it
> > should be a dependency of the project.
> >
> > Noone should be forced to remember it.
> >
> > Worst case, we should provide a link to suggested upgrades and details
> > about what to expect if you don't.
> >
> >
> Which brings me to my next question:
>
> The only dependency of this sort that NET includes in the dependency
> list ISN'T a dependency anymore. It's the statcvs module that we've
> just dropped (see earlier thread).
Yes, that should have been removed by whoever was maintaining [net]
when we moved off of cvs.
The xdoc 1.9.2 dependency is for all commons sites, since it is
required for commons-site.jsl to work.
>
> Looks like I removed it from the "reports" section but not the
> dependencies section. I guess I can't do anything about that without
> redoing the release. Which I'm not about to do.
Yes, sorry I missed that. Should have been removed from the POM.
>
> This is another inaccuracy in the instructions. Step 14 says the
> dependencies are listed in STATUS.html. Net, at least doesn't have a
> STATUS.html. These seem to be generated from project.xml.
Good point. Patch / update welcome. It would be great if you could
bundle up any other issues that you ran into into a patch or direct
update for the building/releasing docs.
Phil
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
Dion Gillard wrote:
>
> If we really do *have to have* a specific release of a plugin, it
> should be a dependency of the project.
>
> Noone should be forced to remember it.
>
> Worst case, we should provide a link to suggested upgrades and details
> about what to expect if you don't.
>
>
Which brings me to my next question:
The only dependency of this sort that NET includes in the dependency
list ISN'T a dependency anymore. It's the statcvs module that we've
just dropped (see earlier thread).
Looks like I removed it from the "reports" section but not the
dependencies section. I guess I can't do anything about that without
redoing the release. Which I'm not about to do.
This is another inaccuracy in the instructions. Step 14 says the
dependencies are listed in STATUS.html. Net, at least doesn't have a
STATUS.html. These seem to be generated from project.xml.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Dion Gillard <di...@gmail.com>.
On 12/4/05, Phil Steitz <ph...@gmail.com> wrote:
> On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
> > Nope, 1.6.
> >
> > This is sort of what I meant when I said it's harder to do these
> > releases. How is one supposed to KNOW what versions of these 30 or 40
> > plugins you have to have in order to build a release?
> >
> > Does Jakarta or Jakarta-commons have a page that tells you the minimum
> > maven setup needed to do a site release? If not, it probably should
> > have. I know this is a dynamic process, but this is nuts.
>
> Good point. Right now http://jakarta.apache.org/commons/building.html
> just contains the statement "Be sure to follow the instructions for
> upgrading the plugins to the latest releases." We could either doc
> the full set there or check in the output of maven --info as a text
> file in commons-build, making changes to that as necessary. I would
> recommend the second option, with a link on the "building" page. I
> will do that if no one beats me to it.
If we really do *have to have* a specific release of a plugin, it
should be a dependency of the project.
Noone should be forced to remember it.
Worst case, we should provide a link to suggested upgrades and details
about what to expect if you don't.
>
> >
> > And then the other direction. I shudder to think what would have
> > happened if I had tried maven 2.0.
> >
> Would have failed (because of POM spec and lots of other
> incompatibilities), as would the 1.1 beta. I agree we need to make
> version dependency clear.
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
http://www.multitask.com.au/people/dion/
"You are going to let the fear of poverty govern your life and your
reward will be that you will eat, but you will not live." - George
Bernard Shaw
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Dennis Lundberg <de...@mdh.se>.
Stephen Colebourne wrote:
> >>Hate to be an "old fart" here but was ant really all that bad?
>
> Well it is a question isn't it? I suppose this is a flame thread, but I
> have to ask, have we over the last two years or so actually got the
> benefits that maven promised? And do we believe that maven2 will help?
Although I haven't used it all that much yet, it promises to fix most of
the thing that were hard/difficult in Maven 1.
> When I think of maven, I see the POM as a good idea, raising the
> abstraction level. The problem has always been what it does with the
> POM. I have a feeling that maven should have just been a set of ant
> tasks that used the POM for info. Anyway, that design wasn't chosen.
>
> So what works well with maven? Well the end result site can be quite
> reasonable. You still have to put in effort though, to fix
> navigation.xml, cvs-usage.xml, issue-tracking.xml, add decent links to
> each of the reports, manage the history of javadocs...
There seems to be some sort of templating feature in Maven 2 that could
take the misery out of keeping copies of beefed-up cvs-usage.xml files
for every component.
> Building has always seemed to be a nightmare though. I have no faith
> that the jar or dist built by maven is the jar/dist that I want (I
> always want something non-standard). And one output jar per project is
> just crazy (see collections-testframework for example). And we still
> don't have a cast-iron way to build a 1.2 compatible release using maven.
Agreed.
> So, are we holding on to maven because we feel we should? Are the
> claimed benfits really there? And if I'm already using ant for releases,
> why shouldn't we do as Hen suggests and generate our reports outside
> maven too?
In my opinion, site generation and dependency management is where the
benefit of Maven is. There are ant-tasks available that makes use of
Maven's dependency management. I've been meaning to try them out, but
haven't found the time...
We really should start looking at Maven 2 for commons sites. I have
started to fiddle with a pom.xml for commons-build, but it's far from
finished. Need to rework the whole navigation stuff, since it has
changed. Not sure how the current setup with entities is supposed to
work. Are the entities supposed to be used in the (common) commons site
or in each component's site or both?
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Thomas Dudziak <to...@gmail.com>.
On 12/5/05, Stephen Colebourne <sc...@btopenworld.com> wrote:
> > All I have to say: dependency management plus the reports are just
> > enough for me to never want to switch back to ant again. Even from
> > m1! Worst case I was always able to come up with some non-standard
> > goals-magic to do what I wanted.
>
> Its clear that many here like maven enough to want to keep it.
> Personally, it drives me up the wall.
>
> For example, ATM, I am trying to use clirr with maven. I've had it
> working before, but now it deosn't. It tries to download the jar even
> though its in the local repository, and thus fails. There is no rhyme
> nor reason about why it fails now when I've had it work previously. I've
> already wasted an hour on it, so now I shall just do what I always do -
> run ant instead.
>
> At least there seems to be some discussion about trying to simplify life
> here at commons.
Mhm, that makes me wonder whether Ant + Ivy (for dependencies)
wouldn't be a better (simpler) choice, or perhaps Maven 2 (havn't used
it yet).
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Martin van den Bemt <ml...@mvdb.net>.
>
> This is how this starts: Someone comes up with a neat idea and adds a
> manual step to the process to do that. Often, but not always, this gets
> documented. Better yet would be if it could get automated.
>
Automation is definitely worthwhile with so many components...
Mvgr,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Torsten Curdt <tc...@apache.org>.
> That wasn't Stephen Colebourne's comment, it was originally mine :-)
Sorry, Stephen ...snipped the wrong header :)
<snip/>
> My real thoughts are that it is now time to tighten up the jakarta-
> commons standard and documentation for maven use so that there are
> fewer of these manual extra steps that need to be done for every
> release.
Ok
> This is how this starts: Someone comes up with a neat idea and
> adds a manual step to the process to do that. Often, but not
> always, this gets documented. Better yet would be if it could get
> automated.
Sure
cheers
--
Torsten
Re: [all] Maven, help or hinderance?
Posted by Steve Cohen <sc...@javactivity.org>.
Torsten Curdt wrote:
>
> On 04.12.2005, at 02:17, Stephen Colebourne wrote:
>
>> >>Hate to be an "old fart" here but was ant really all that bad?
>
>
> Oh ...please don't!
>
> All I have to say: dependency management plus the reports are just
> enough for me to never want to switch back to ant again. Even from
> m1! Worst case I was always able to come up with some non-standard
> goals-magic to do what I wanted.
>
> My 2 cents
> --
> Torsten
That wasn't Stephen Colebourne's comment, it was originally mine :-) I
just did a release, my first in over a year, and man, was it annoying.
But I wasn't completely serious. Maven allows us to produce a much
nicer site with more functionality - no doubt about it. However, there
are more steps now, more things to keep track of, more things to go
wrong. And my comment sparked quite a lot of thread. My real thoughts
are that it is now time to tighten up the jakarta-commons standard and
documentation for maven use so that there are fewer of these manual
extra steps that need to be done for every release.
This is how this starts: Someone comes up with a neat idea and adds a
manual step to the process to do that. Often, but not always, this gets
documented. Better yet would be if it could get automated.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Torsten Curdt wrote:
> On 04.12.2005, at 02:17, Stephen Colebourne wrote:
>> >>Hate to be an "old fart" here but was ant really all that bad?
>
> Oh ...please don't!
;-)
> All I have to say: dependency management plus the reports are just
> enough for me to never want to switch back to ant again. Even from
> m1! Worst case I was always able to come up with some non-standard
> goals-magic to do what I wanted.
Its clear that many here like maven enough to want to keep it.
Personally, it drives me up the wall.
For example, ATM, I am trying to use clirr with maven. I've had it
working before, but now it deosn't. It tries to download the jar even
though its in the local repository, and thus fails. There is no rhyme
nor reason about why it fails now when I've had it work previously. I've
already wasted an hour on it, so now I shall just do what I always do -
run ant instead.
At least there seems to be some discussion about trying to simplify life
here at commons.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Maven, help or hinderance?
Posted by Torsten Curdt <tc...@apache.org>.
On 04.12.2005, at 02:17, Stephen Colebourne wrote:
> >>Hate to be an "old fart" here but was ant really all that bad?
Oh ...please don't!
All I have to say: dependency management plus the reports are just
enough for me to never want to switch back to ant again. Even from
m1! Worst case I was always able to come up with some non-standard
goals-magic to do what I wanted.
My 2 cents
--
Torsten
[all] Maven, help or hinderance?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
>>Hate to be an "old fart" here but was ant really all that bad?
Well it is a question isn't it? I suppose this is a flame thread, but I
have to ask, have we over the last two years or so actually got the
benefits that maven promised? And do we believe that maven2 will help?
When I think of maven, I see the POM as a good idea, raising the
abstraction level. The problem has always been what it does with the
POM. I have a feeling that maven should have just been a set of ant
tasks that used the POM for info. Anyway, that design wasn't chosen.
So what works well with maven? Well the end result site can be quite
reasonable. You still have to put in effort though, to fix
navigation.xml, cvs-usage.xml, issue-tracking.xml, add decent links to
each of the reports, manage the history of javadocs...
Building has always seemed to be a nightmare though. I have no faith
that the jar or dist built by maven is the jar/dist that I want (I
always want something non-standard). And one output jar per project is
just crazy (see collections-testframework for example). And we still
don't have a cast-iron way to build a 1.2 compatible release using maven.
So, are we holding on to maven because we feel we should? Are the
claimed benfits really there? And if I'm already using ant for releases,
why shouldn't we do as Hen suggests and generate our reports outside
maven too?
Stephen
Henri Yandell wrote:
> On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
>>This is sort of what I meant when I said it's harder to do these
>>releases. How is one supposed to KNOW what versions of these 30 or 40
>>plugins you have to have in order to build a release?
>
>
> and what if one doesn't want to be on a weird mismash version of Maven
> for other projects :)
>
>
>>Does Jakarta or Jakarta-commons have a page that tells you the minimum
>>maven setup needed to do a site release? If not, it probably should
>>have. I know this is a dynamic process, but this is nuts.
>>
>>And then the other direction. I shudder to think what would have
>>happened if I had tried maven 2.0.
>
>
> Somewhere a volcano would have erupted.
>
>
>>Hate to be an "old fart" here but was ant really all that bad?
>
>
> Being a "stupid fart", does Maven have to be this bad? :) I suspect it
> does, because we're trying to use it as a power-tool when Maven works
> best as a standardisation tool.
>
> Increasingly thinking that we should decouple the site from the
> components. Reports would then be tied to builds, so as part of this
> release, Net would be building a small number of Reports and putting
> them under a versioned space. The site would then link into them much
> the same way it does the downloads.
>
>
>>Anyway, the site is deployed. It's gradually pushing itself out to all
>>the servers.
>
>
> Just the one server I think :) The site is rsync'd every hour or two
> to 'ajax' in Europe. The distributables however are mirrored.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Henri Yandell <fl...@gmail.com>.
On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
> Nope, 1.6.
>
> This is sort of what I meant when I said it's harder to do these
> releases. How is one supposed to KNOW what versions of these 30 or 40
> plugins you have to have in order to build a release?
and what if one doesn't want to be on a weird mismash version of Maven
for other projects :)
> Does Jakarta or Jakarta-commons have a page that tells you the minimum
> maven setup needed to do a site release? If not, it probably should
> have. I know this is a dynamic process, but this is nuts.
>
> And then the other direction. I shudder to think what would have
> happened if I had tried maven 2.0.
Somewhere a volcano would have erupted.
> Hate to be an "old fart" here but was ant really all that bad?
Being a "stupid fart", does Maven have to be this bad? :) I suspect it
does, because we're trying to use it as a power-tool when Maven works
best as a standardisation tool.
Increasingly thinking that we should decouple the site from the
components. Reports would then be tied to builds, so as part of this
release, Net would be building a small number of Reports and putting
them under a versioned space. The site would then link into them much
the same way it does the downloads.
> Anyway, the site is deployed. It's gradually pushing itself out to all
> the servers.
Just the one server I think :) The site is rsync'd every hour or two
to 'ajax' in Europe. The distributables however are mirrored.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Phil Steitz <ph...@gmail.com>.
On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
> Nope, 1.6.
>
> This is sort of what I meant when I said it's harder to do these
> releases. How is one supposed to KNOW what versions of these 30 or 40
> plugins you have to have in order to build a release?
>
> Does Jakarta or Jakarta-commons have a page that tells you the minimum
> maven setup needed to do a site release? If not, it probably should
> have. I know this is a dynamic process, but this is nuts.
Good point. Right now http://jakarta.apache.org/commons/building.html
just contains the statement "Be sure to follow the instructions for
upgrading the plugins to the latest releases." We could either doc
the full set there or check in the output of maven --info as a text
file in commons-build, making changes to that as necessary. I would
recommend the second option, with a link on the "building" page. I
will do that if no one beats me to it.
>
> And then the other direction. I shudder to think what would have
> happened if I had tried maven 2.0.
>
Would have failed (because of POM spec and lots of other
incompatibilities), as would the 1.1 beta. I agree we need to make
version dependency clear.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
Pls disregard. I figured it out.
Steve Cohen wrote:
> okay, made it down to step 12 now.
>
> * Update Jakarta News Page Add a standard news item announcing the
> release to the current Jakarta news page. Look for the page whose name
> covers today's date in the site/xdocs/site/news directory. For example,
> the news for a release created in July 2004 should go into
> news-2004-2ndHalf.xml. This should be similar to the announcement you'll
> post later to email lists. Please remember to include a description of
> your component. Please also add a reminder about verifying signature.
> * Jakarta Welcome Page News items on the Jakarta welcome page are
> now automatically generated when you run "ant" to build the HTML files.
>
> However, there is no such file since 2nd quarter of 2005, and the
> index.xml mentions that this has now been retired, and the apache site
> now asks you to subscribe to a mailing list for Apache news. Am I right
> then in thinking that the second part of section 12 (quoted above) is
> now null and void?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
okay, made it down to step 12 now.
* Update Jakarta News Page Add a standard news item announcing
the release to the current Jakarta news page. Look for the page whose
name covers today's date in the site/xdocs/site/news directory. For
example, the news for a release created in July 2004 should go into
news-2004-2ndHalf.xml. This should be similar to the announcement you'll
post later to email lists. Please remember to include a description of
your component. Please also add a reminder about verifying signature.
* Jakarta Welcome Page News items on the Jakarta welcome page are
now automatically generated when you run "ant" to build the HTML files.
However, there is no such file since 2nd quarter of 2005, and the
index.xml mentions that this has now been retired, and the apache site
now asks you to subscribe to a mailing list for Apache news. Am I right
then in thinking that the second part of section 12 (quoted above) is
now null and void?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
Nope, 1.6.
This is sort of what I meant when I said it's harder to do these
releases. How is one supposed to KNOW what versions of these 30 or 40
plugins you have to have in order to build a release?
Does Jakarta or Jakarta-commons have a page that tells you the minimum
maven setup needed to do a site release? If not, it probably should
have. I know this is a dynamic process, but this is nuts.
And then the other direction. I shudder to think what would have
happened if I had tried maven 2.0.
Hate to be an "old fart" here but was ant really all that bad?
Anyway, the site is deployed. It's gradually pushing itself out to all
the servers.
Phil Steitz wrote:
> You need to make sure you are running version 1.9.2 of the maven xdoc plugin.
>
> maven plugin:install
> maven
> maven-xdoc-plugin
> 1.9.2
>
> Phil
>
> On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
>
>>Thanks guys. statcvs gone. Past that hurdle.
>>
>>Now this one:
>>
>>
>>
>>xdoc:jelly-transform:
>> [echo] Generating
>>/home/scohen/commons-net/branches/NET_1_4_1/target/docs/javadoc.html
>>from
>>/home/scohen/commons-net/branches/NET_1_4_1/target/generated-xdocs/javadoc.xml
>>Could not find the class: org.apache.commons.jelly.tags.fmt.FmtTagLibrary
>>java.lang.ClassNotFoundException:
>>org.apache.commons.jelly.tags.fmt.FmtTagLibrary
>>...
>>
>>What's up with that?
>>
>>Phil Steitz wrote:
>>
>>>Yes, remove the reference to the statcvs report from the <reports>
>>>element. You should obviously also check in the change so the project
>>>builds correctly from svn sources.
>>>
>>>You should have no problem building from branches, tags, etc., as long
>>>as commons-build is checked out as a peer.
>>>
>>>Phil
>>>
>>>On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
>>>
>>>
>>>>Rory Winston wrote:
>>>>
>>>>
>>>>>statcvs and svn dont work together (yet)...
>>>>>
>>>>>http://www.researchkitchen.co.uk/blog/archives/13
>>>>>
>>>>>I just turned off the statcvs report last time.
>>>>>
>>>>>
>>>>>
>>>>
>>>>where do you do that? Project.xml?
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Phil Steitz <ph...@gmail.com>.
You need to make sure you are running version 1.9.2 of the maven xdoc plugin.
maven plugin:install
maven
maven-xdoc-plugin
1.9.2
Phil
On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
> Thanks guys. statcvs gone. Past that hurdle.
>
> Now this one:
>
>
>
> xdoc:jelly-transform:
> [echo] Generating
> /home/scohen/commons-net/branches/NET_1_4_1/target/docs/javadoc.html
> from
> /home/scohen/commons-net/branches/NET_1_4_1/target/generated-xdocs/javadoc.xml
> Could not find the class: org.apache.commons.jelly.tags.fmt.FmtTagLibrary
> java.lang.ClassNotFoundException:
> org.apache.commons.jelly.tags.fmt.FmtTagLibrary
> ...
>
> What's up with that?
>
> Phil Steitz wrote:
> > Yes, remove the reference to the statcvs report from the <reports>
> > element. You should obviously also check in the change so the project
> > builds correctly from svn sources.
> >
> > You should have no problem building from branches, tags, etc., as long
> > as commons-build is checked out as a peer.
> >
> > Phil
> >
> > On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
> >
> >>Rory Winston wrote:
> >>
> >>>statcvs and svn dont work together (yet)...
> >>>
> >>>http://www.researchkitchen.co.uk/blog/archives/13
> >>>
> >>>I just turned off the statcvs report last time.
> >>>
> >>>
> >>>
> >>
> >>where do you do that? Project.xml?
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
Thanks guys. statcvs gone. Past that hurdle.
Now this one:
xdoc:jelly-transform:
[echo] Generating
/home/scohen/commons-net/branches/NET_1_4_1/target/docs/javadoc.html
from
/home/scohen/commons-net/branches/NET_1_4_1/target/generated-xdocs/javadoc.xml
Could not find the class: org.apache.commons.jelly.tags.fmt.FmtTagLibrary
java.lang.ClassNotFoundException:
org.apache.commons.jelly.tags.fmt.FmtTagLibrary
...
What's up with that?
Phil Steitz wrote:
> Yes, remove the reference to the statcvs report from the <reports>
> element. You should obviously also check in the change so the project
> builds correctly from svn sources.
>
> You should have no problem building from branches, tags, etc., as long
> as commons-build is checked out as a peer.
>
> Phil
>
> On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
>
>>Rory Winston wrote:
>>
>>>statcvs and svn dont work together (yet)...
>>>
>>>http://www.researchkitchen.co.uk/blog/archives/13
>>>
>>>I just turned off the statcvs report last time.
>>>
>>>
>>>
>>
>>where do you do that? Project.xml?
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Phil Steitz <ph...@gmail.com>.
Yes, remove the reference to the statcvs report from the <reports>
element. You should obviously also check in the change so the project
builds correctly from svn sources.
You should have no problem building from branches, tags, etc., as long
as commons-build is checked out as a peer.
Phil
On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
> Rory Winston wrote:
> > statcvs and svn dont work together (yet)...
> >
> > http://www.researchkitchen.co.uk/blog/archives/13
> >
> > I just turned off the statcvs report last time.
> >
> >
> >
> where do you do that? Project.xml?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
> Rory Winston wrote:
> > statcvs and svn dont work together (yet)...
> >
> > http://www.researchkitchen.co.uk/blog/archives/13
> >
> > I just turned off the statcvs report last time.
> >
> >
> >
> where do you do that? Project.xml?
<snip/>
Yup, for this project.xml [1], comment out the following report:
<report>maven-statcvs-plugin</report>
When you post the POM to the java repository, you might want to remove
the maven-statcvs-plugin dependency as well as the simian report.
-Rahul
[1] http://svn.apache.org/repos/asf/jakarta/commons/proper/net/branches/NET_1_4_1/project.xml
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
Rory Winston wrote:
> statcvs and svn dont work together (yet)...
>
> http://www.researchkitchen.co.uk/blog/archives/13
>
> I just turned off the statcvs report last time.
>
>
>
where do you do that? Project.xml?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Rory Winston <rw...@eircom.net>.
statcvs and svn dont work together (yet)...
http://www.researchkitchen.co.uk/blog/archives/13
I just turned off the statcvs report last time.
Steve Cohen wrote:
> Sheesh, the release process has gotten much hairier since I last did it!
> 5 hours and I'm still not all the way there. And this was supposed to
> be a simple release.
>
> Phooey.
>
> I decided that that easiest way to do this "simple" release fixing
> ONLY the 1.3 compatibility problem would be to work from a branch cut
> at 1_4_0. And that is how I built it.
>
> Now however, I get to step 10 Publish updated website and maven is
> failing. Can this even work when deploying from a branch and not the
> trunk?
>
>
>
> $ /opt/maven/bin/maven -Dmaven.username=scohen site:deploy
> __ __
> | \/ |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
> |_| |_\__,_|\_/\___|_||_| v. 1.0-rc2
>
> Attempting to download commons-net-1.1.0.jar.
> ......................................................................................................
>
> .
> Attempting to download vdoclet-20020711.jar.
> .....................................................
> .
> Attempting to download qdox-current.jar.
> ...........................
> .
> Attempting to download commons-collections-2.1.jar.
> ......................................................................................................................
>
> .
> Attempting to download logkit-1.0.1.jar.
> ...............................................
> .
> Attempting to download statcvs-xml-0.9.4.jar.
> ......................................................................................................................................................
>
> Attempting to download jdom-b10.jar.
> .........................................................................................................
>
> .
> Attempting to download jfreechart-0.9.20.jar.
> .....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
>
> .
> Attempting to download jcommon-0.9.5.jar.
> .......................................................................................................................................................................................................................................
>
> .
> Attempting to download commons-jexl-1.0-beta-1.jar.
> ...........................................................................
>
> .
> Attempting to download jdepend-2.5.jar.
> .......................................................
> .
> Attempting to download checkstyle-3.3.jar.
> .............................................................................................................................................................................................................................................................................................................................................
>
> .
> Attempting to download checkstyle-optional-3.3.jar.
> .................................................................................................
>
> .
> Attempting to download regexp-1.3.jar.
> ...................
> .
> Attempting to download commons-beanutils-1.6.1.jar.
> .....................................................................................
>
> .
> Attempting to download simian-1.9.1.jar.
> ................................................
> .
> Attempting to download ant-1.6.jar.
> ........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
>
> .
> build:start:
>
> site:deploy:
> site:
> xdoc:register-reports:
> maven-changes-plugin:register:
>
> maven-tasklist-plugin:register:
>
> statcvs:init:
>
> maven-statcvs-plugin:register:
>
> maven-junit-report-plugin:register:
>
> maven-jdepend-plugin:register:
>
> maven-jcoverage-plugin:register:
>
> maven-checkstyle-plugin:register:
>
> maven-simian-plugin:register:
>
> maven-javadoc-plugin:register:
>
> maven-jxr-plugin:register:
>
> maven-license-plugin:register:
>
>
> site:run-reports:
> [echo] Generating the Changes...
> changes:report:
>
> [echo] Generating the Task List...
> xdoc:init:
>
> maven-tasklist-plugin:report:
> [echo] Generating tasklist ...
>
> [echo] Generating the StatCvs Report...
> statcvs:init:
>
> statcvs:generate:
> statcvs:init-variables:
> statcvs:parse-connection:
> [echo] Using connection:
> scm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/net/trunk
>
> BUILD FAILED
> File......
> file:/home/scohen/.maven/plugins/maven-statcvs-plugin-2.5/plugin.jelly
> Element... ant:fail
> Line...... 103
> Column.... 19
> Unknown SCM method: 'svn'
> Total time: 19 seconds
> Finished at: Sat Dec 03 12:34:56 CST 2005
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/3/05, Steve Cohen <sc...@javactivity.org> wrote:
> Sheesh, the release process has gotten much hairier since I last did it!
> 5 hours and I'm still not all the way there. And this was supposed to
> be a simple release.
>
> Phooey.
>
> I decided that that easiest way to do this "simple" release fixing ONLY
> the 1.3 compatibility problem would be to work from a branch cut at
> 1_4_0. And that is how I built it.
>
> Now however, I get to step 10 Publish updated website and maven is
> failing. Can this even work when deploying from a branch and not the trunk?
>
<snip/>
>
> [echo] Generating the StatCvs Report...
> statcvs:init:
>
> statcvs:generate:
> statcvs:init-variables:
> statcvs:parse-connection:
> [echo] Using connection:
> scm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/net/trunk
>
> BUILD FAILED
> File......
> file:/home/scohen/.maven/plugins/maven-statcvs-plugin-2.5/plugin.jelly
> Element... ant:fail
> Line...... 103
> Column.... 19
> Unknown SCM method: 'svn'
> Total time: 19 seconds
> Finished at: Sat Dec 03 12:34:56 CST 2005
>
<snap/>
Sorry, I can't pinpoint whats going on, though I have two suggestions:
1) Turn off the statcvs report (the trunk doesn't have it anyway, and
the error message seems to come out of there)
2) If you can generate the site locally (maven site) but can't deploy
it -- while you sort it out -- a clearly suboptimal solution that you
could consider is to tar/zip the generated site (maven site) and
manually expand in the siteDirectory (to avoid undue delay in the
releasing process).
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Henri Yandell <fl...@gmail.com>.
On 12/3/05, Stephen Colebourne <sc...@btopenworld.com> wrote:
> You'll ned maven 1.0.2 plus the latest release of any plugin that barfs.
> Plus you'll need various project properties set. See commons-io for a
> recent working example.
>
> And yes you are right, releasing with svn and maven at ASF is a right
> royal pain.
Been a while since I did a release. What makes it painful?
It was always the PGP juggling for me.
Maven/svn releases at osjava.org are pretty painless. Probably because
they have lower goals:
http://wiki.osjava.org/confluence/display/IDEAS/OSJava+release+process
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
You'll ned maven 1.0.2 plus the latest release of any plugin that barfs.
Plus you'll need various project properties set. See commons-io for a
recent working example.
And yes you are right, releasing with svn and maven at ASF is a right
royal pain.
Stephen
Steve Cohen wrote:
> Sheesh, the release process has gotten much hairier since I last did it!
> 5 hours and I'm still not all the way there. And this was supposed to
> be a simple release.
>
> Phooey.
>
> I decided that that easiest way to do this "simple" release fixing ONLY
> the 1.3 compatibility problem would be to work from a branch cut at
> 1_4_0. And that is how I built it.
>
> Now however, I get to step 10 Publish updated website and maven is
> failing. Can this even work when deploying from a branch and not the
> trunk?
>
>
>
> $ /opt/maven/bin/maven -Dmaven.username=scohen site:deploy
> __ __
> | \/ |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
> |_| |_\__,_|\_/\___|_||_| v. 1.0-rc2
>
> Attempting to download commons-net-1.1.0.jar.
> ......................................................................................................
>
> .
> Attempting to download vdoclet-20020711.jar.
> .....................................................
> .
> Attempting to download qdox-current.jar.
> ...........................
> .
> Attempting to download commons-collections-2.1.jar.
> ......................................................................................................................
>
> .
> Attempting to download logkit-1.0.1.jar.
> ...............................................
> .
> Attempting to download statcvs-xml-0.9.4.jar.
> ......................................................................................................................................................
>
> Attempting to download jdom-b10.jar.
> .........................................................................................................
>
> .
> Attempting to download jfreechart-0.9.20.jar.
> .....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
>
> .
> Attempting to download jcommon-0.9.5.jar.
> .......................................................................................................................................................................................................................................
>
> .
> Attempting to download commons-jexl-1.0-beta-1.jar.
> ...........................................................................
> .
> Attempting to download jdepend-2.5.jar.
> .......................................................
> .
> Attempting to download checkstyle-3.3.jar.
> .............................................................................................................................................................................................................................................................................................................................................
>
> .
> Attempting to download checkstyle-optional-3.3.jar.
> .................................................................................................
>
> .
> Attempting to download regexp-1.3.jar.
> ...................
> .
> Attempting to download commons-beanutils-1.6.1.jar.
> .....................................................................................
>
> .
> Attempting to download simian-1.9.1.jar.
> ................................................
> .
> Attempting to download ant-1.6.jar.
> ........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
>
> .
> build:start:
>
> site:deploy:
> site:
> xdoc:register-reports:
> maven-changes-plugin:register:
>
> maven-tasklist-plugin:register:
>
> statcvs:init:
>
> maven-statcvs-plugin:register:
>
> maven-junit-report-plugin:register:
>
> maven-jdepend-plugin:register:
>
> maven-jcoverage-plugin:register:
>
> maven-checkstyle-plugin:register:
>
> maven-simian-plugin:register:
>
> maven-javadoc-plugin:register:
>
> maven-jxr-plugin:register:
>
> maven-license-plugin:register:
>
>
> site:run-reports:
> [echo] Generating the Changes...
> changes:report:
>
> [echo] Generating the Task List...
> xdoc:init:
>
> maven-tasklist-plugin:report:
> [echo] Generating tasklist ...
>
> [echo] Generating the StatCvs Report...
> statcvs:init:
>
> statcvs:generate:
> statcvs:init-variables:
> statcvs:parse-connection:
> [echo] Using connection:
> scm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/net/trunk
>
> BUILD FAILED
> File......
> file:/home/scohen/.maven/plugins/maven-statcvs-plugin-2.5/plugin.jelly
> Element... ant:fail
> Line...... 103
> Column.... 19
> Unknown SCM method: 'svn'
> Total time: 19 seconds
> Finished at: Sat Dec 03 12:34:56 CST 2005
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
Sheesh, the release process has gotten much hairier since I last did it!
5 hours and I'm still not all the way there. And this was supposed to
be a simple release.
Phooey.
I decided that that easiest way to do this "simple" release fixing ONLY
the 1.3 compatibility problem would be to work from a branch cut at
1_4_0. And that is how I built it.
Now however, I get to step 10 Publish updated website and maven is
failing. Can this even work when deploying from a branch and not the trunk?
$ /opt/maven/bin/maven -Dmaven.username=scohen site:deploy
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0-rc2
Attempting to download commons-net-1.1.0.jar.
......................................................................................................
.
Attempting to download vdoclet-20020711.jar.
.....................................................
.
Attempting to download qdox-current.jar.
...........................
.
Attempting to download commons-collections-2.1.jar.
......................................................................................................................
.
Attempting to download logkit-1.0.1.jar.
...............................................
.
Attempting to download statcvs-xml-0.9.4.jar.
......................................................................................................................................................
Attempting to download jdom-b10.jar.
.........................................................................................................
.
Attempting to download jfreechart-0.9.20.jar.
.....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
.
Attempting to download jcommon-0.9.5.jar.
.......................................................................................................................................................................................................................................
.
Attempting to download commons-jexl-1.0-beta-1.jar.
...........................................................................
.
Attempting to download jdepend-2.5.jar.
.......................................................
.
Attempting to download checkstyle-3.3.jar.
.............................................................................................................................................................................................................................................................................................................................................
.
Attempting to download checkstyle-optional-3.3.jar.
.................................................................................................
.
Attempting to download regexp-1.3.jar.
...................
.
Attempting to download commons-beanutils-1.6.1.jar.
.....................................................................................
.
Attempting to download simian-1.9.1.jar.
................................................
.
Attempting to download ant-1.6.jar.
........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
.
build:start:
site:deploy:
site:
xdoc:register-reports:
maven-changes-plugin:register:
maven-tasklist-plugin:register:
statcvs:init:
maven-statcvs-plugin:register:
maven-junit-report-plugin:register:
maven-jdepend-plugin:register:
maven-jcoverage-plugin:register:
maven-checkstyle-plugin:register:
maven-simian-plugin:register:
maven-javadoc-plugin:register:
maven-jxr-plugin:register:
maven-license-plugin:register:
site:run-reports:
[echo] Generating the Changes...
changes:report:
[echo] Generating the Task List...
xdoc:init:
maven-tasklist-plugin:report:
[echo] Generating tasklist ...
[echo] Generating the StatCvs Report...
statcvs:init:
statcvs:generate:
statcvs:init-variables:
statcvs:parse-connection:
[echo] Using connection:
scm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/net/trunk
BUILD FAILED
File......
file:/home/scohen/.maven/plugins/maven-statcvs-plugin-2.5/plugin.jelly
Element... ant:fail
Line...... 103
Column.... 19
Unknown SCM method: 'svn'
Total time: 19 seconds
Finished at: Sat Dec 03 12:34:56 CST 2005
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
Steve Cohen wrote:
> Steve Cohen wrote:
>
>> Mario Ivankovits wrote:
>>
>>> Steve Cohen wrote:
>>>
>>>> It has been discovered that 1.4.0 is inadvertently incompatible with
>>>> jdk 1.3. Please vote on a release of a fixed version.
>>>
>>>
>>>
>>> Checked VFS using "net svn head" and it works.
>>>
>>> So here is my +1
>>>
>>>
>>> BTW: maven builds a 1.5.0 version instead of 1.4.1. Do you plan to
>>> release svn head or a patched/rebuild 1.4.0?
>>>
>>> ---
>>> Mario
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>>
>> Please disregard my earlier reply. I realize that I misunderstood
>> you. You are, I presume, talking about the version number of net that
>> maven currently builds. This will have to be changed of course.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
> As I have little time now, I propose the following. 1.4.1 will be just
> 1.4.0 with whatever changes are needed to reverse the dependency on jdk
> 1.4.x. No other bug fixes will be included.
>
> Re-vote
>
> +1 [yes]
> -1 [no]
>
> I vote +1.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
The following people voted on release commons-net 1.4.1:
Steve Cohen +1
Stefan Bodewig +1
Dion Gilliard +1
Mario Ivankovits +1
Henri Yandell +1
(implied - said if code had already been released, +1, otherwise hold
off. Code was in fact in 1.4.0 so +1)
robert burrell donkin +1
( on 12/2 after being -1 on 12/1 and being satisfied with Rory
Winston's response to copyright question)
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by Henri Yandell <fl...@gmail.com>.
On 12/2/05, Steve Cohen <sc...@javactivity.org> wrote:
>
> To get back to the original subject matter:
> It looks as though Rory was pretty well able to resolve the questions
> about the provenance of his code, although, I understand the lawyers may
> still want to look a little closer. Do you have any idea when this
> cloudlet might be lifted and we can contemplate a release?
Has the code already been in a release?
As long as it has, I don't see any harm in continuing. It just adds
another distributable in which we'd have to fix the problem; which is
just to make sure we get the original author's official permission,
instead of the unofficial permission.
If it hasn't been in a release, we should hold off until we can.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
Henri Yandell wrote:
> On 12/2/05, robert burrell donkin <ro...@blueyonder.co.uk> wrote:
>
>
>>this culture needs to change: there are still too few people nominating
>>new pmc'ers. IMHO it is an important part of the responsibility that
>>comes with nominating someone as a committer that you will guide them
>>through the first few weeks or months as a committer and (when they are
>>ready) nominate them for the pmc.
>>
>>the progression from committers to pmc'er should be natural and
>>relatively quick. definitely, all release managers should be pmc'ers.
>>anyone who knows enough about apache to manage a release should be on
>>the pmc.
>
>
> It's the wrong list, ie) should be on general@, but I'm thinking that
> we should just set in stone a date at which point a new committer is
> listed on the pmc list and asked if they should be on the pmc (to the
> person nominating them as committers).
>
> So let's say Robert becomes a committer today. This would be noted in
> a file. In 6->9 months time (ie when the chair does the report), any 6
> month old committers would involve a question to the person nominating
> them as committers as to why they shouldn't be nominated.
>
> So culture change. One in which people are challenged to exclude, not
> expected to remember to include.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
Hen:
This is a valuable discussion but perhaps we need a different subject
for the thread?
To get back to the original subject matter:
It looks as though Rory was pretty well able to resolve the questions
about the provenance of his code, although, I understand the lawyers may
still want to look a little closer. Do you have any idea when this
cloudlet might be lifted and we can contemplate a release?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by Henri Yandell <fl...@gmail.com>.
On 12/2/05, robert burrell donkin <ro...@blueyonder.co.uk> wrote:
> this culture needs to change: there are still too few people nominating
> new pmc'ers. IMHO it is an important part of the responsibility that
> comes with nominating someone as a committer that you will guide them
> through the first few weeks or months as a committer and (when they are
> ready) nominate them for the pmc.
>
> the progression from committers to pmc'er should be natural and
> relatively quick. definitely, all release managers should be pmc'ers.
> anyone who knows enough about apache to manage a release should be on
> the pmc.
It's the wrong list, ie) should be on general@, but I'm thinking that
we should just set in stone a date at which point a new committer is
listed on the pmc list and asked if they should be on the pmc (to the
person nominating them as committers).
So let's say Robert becomes a committer today. This would be noted in
a file. In 6->9 months time (ie when the chair does the report), any 6
month old committers would involve a question to the person nominating
them as committers as to why they shouldn't be nominated.
So culture change. One in which people are challenged to exclude, not
expected to remember to include.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Fri, 2005-12-02 at 08:08 +0100, Mario Ivankovits wrote:
> Hi!
> > Any active committer should be on the PMC, unless they've only
> > recently joined, so if you're active kick away and one of us will
> > gladly nominate you.
> >
> I wasnt aware that we (the committers) are allowed to be on the PMC list.
they aren't but all active committers should really be nominated for the
pmc. i didn't realise before that you and rory were not or i would have
nominated you before :-/
only those on the pmc are legally entitled to cast binding votes for
official ASF decisions and the ASF cannot help those who are not on the
pmc. so, it's crucially important that committers who make any sort of
sustained contribution are nominated for the pmc.
> I thought it need some time until a committer can become a PMC.
this culture needs to change: there are still too few people nominating
new pmc'ers. IMHO it is an important part of the responsibility that
comes with nominating someone as a committer that you will guide them
through the first few weeks or months as a committer and (when they are
ready) nominate them for the pmc.
the progression from committers to pmc'er should be natural and
relatively quick. definitely, all release managers should be pmc'ers.
anyone who knows enough about apache to manage a release should be on
the pmc.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by Rory Winston <rw...@eircom.net>.
Me too, if possible.
I havent received the CC: yet, so if someone who is on the PMC can
forward a copy of the email to me, I would appreciate it.
Mario Ivankovits wrote:
> Hi!
>> Any active committer should be on the PMC, unless they've only
>> recently joined, so if you're active kick away and one of us will
>> gladly nominate you.
>>
> I wasnt aware that we (the committers) are allowed to be on the PMC list.
> I thought it need some time until a committer can become a PMC.
>
> Though, if possible I would like to join the mailinglist!
>
> ---
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> Any active committer should be on the PMC, unless they've only
> recently joined, so if you're active kick away and one of us will
> gladly nominate you.
>
I wasnt aware that we (the committers) are allowed to be on the PMC list.
I thought it need some time until a committer can become a PMC.
Though, if possible I would like to join the mailinglist!
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thu, 2005-12-01 at 21:02 -0500, Henri Yandell wrote:
> For the thread's info; Robert's cc'd Rory on the pmc email.
>
> This is legal shit and irritatingly it seems there are increased
> liability issues when you talk publically.
+1
for some folks, copyright is a criminal matter (not just civil). please
respect the need for some confidentially in these matters.
> Any active committer should be on the PMC, unless they've only
> recently joined, so if you're active kick away and one of us will
> gladly nominate you.
+1
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by Henri Yandell <fl...@gmail.com>.
For the thread's info; Robert's cc'd Rory on the pmc email.
This is legal shit and irritatingly it seems there are increased
liability issues when you talk publically.
Any active committer should be on the PMC, unless they've only
recently joined, so if you're active kick away and one of us will
gladly nominate you.
--
Stephen: I'm guessing you didn't get my reply when you asked about not
getting mail from the list a while back. scolebourne@apache.org is
subscribed, which forwards to scolebourne@joda.org. Is that still
active?
Hen
On 12/1/05, Rory Winston <rw...@eircom.net> wrote:
> Can you just summarize what your objections are instead of referencing
> some location that most people don't have access to?
>
> robert burrell donkin wrote:
> > -1 to any commons-net new release. see pmc thread for details (if any
> > committers aren't on the pmc please shout and i'll nominate you)
> >
> > - robert
> >
> > On Thu, 2005-12-01 at 07:47 +0100, Mario Ivankovits wrote:
> >
> >> Steve Cohen wrote:
> >>
> >>> As I have little time now, I propose the following. 1.4.1 will be
> >>> just 1.4.0 with whatever changes are needed to reverse the dependency
> >>> on jdk 1.4.x. No other bug fixes will be included.
> >>>
> >>> Re-vote
> >>>
> >>> +1 [yes]
> >>> -1 [no]
> >>>
> >> +1
> >>
> >> ---
> >> Mario
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by Rory Winston <rw...@eircom.net>.
Can you just summarize what your objections are instead of referencing
some location that most people don't have access to?
robert burrell donkin wrote:
> -1 to any commons-net new release. see pmc thread for details (if any
> committers aren't on the pmc please shout and i'll nominate you)
>
> - robert
>
> On Thu, 2005-12-01 at 07:47 +0100, Mario Ivankovits wrote:
>
>> Steve Cohen wrote:
>>
>>> As I have little time now, I propose the following. 1.4.1 will be
>>> just 1.4.0 with whatever changes are needed to reverse the dependency
>>> on jdk 1.4.x. No other bug fixes will be included.
>>>
>>> Re-vote
>>>
>>> +1 [yes]
>>> -1 [no]
>>>
>> +1
>>
>> ---
>> Mario
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
robert burrell donkin wrote:
> -1 to any commons-net new release. see pmc thread for details (if any
> committers aren't on the pmc please shout and i'll nominate you)
I am on the PMC but haven't got mails for a long time :-/
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] Minimum jdk/jvm version for net ( future ) ( was: Re: [vote][net]
Release commons-net 1.4.1? )
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
Mario Ivankovits wrote:
> Steve Cohen wrote:
>
>> We need to discuss this further.
>> Mario Ivankovits VFS is a client of Net and he has users still on 1.3
>> who are complaining that Net 1.4 breaks VFS.
>
> And not only my users constantly complain about it. AFAIK this is also
> true for other commons components.
> Though, there is an end of live for jdk1.3 and so we sould also to
> define such a point in the future.
Understood, I thought we discussed at some point development would move
towards using 1.4+ features and just support a 1.3 version ( bug fixes
only ). So in that case VFS would lock into the 1.3-compat version and
not move forward until it could shake the 1.3 dependency?
> Personally I see this point reached in 6 months, but understand if we
> have to stick on 1.3 for the next year.
>
> Then we should jump to jdk 1.5 (with jdk 1.4 api) and use retroweaver to
> provide the jdk 1.4 version.
> Our releases should then contain jars for both (1.5 and 1.4)
> I know there are the same issues with api compatibility, but if we run
> our tests against both jdks we should be fine, also it might be possible
> to have an api checker which will check the generated classes against
> the classpath.
> Whatever, we might find a way to archive this.
>
> I know, this is somehow radical, but our code starts to smell and become
> spider webs if we have to stick on 1.3 for the time being ;-)
Yes, and we can't make use of newer features ( nio in this case I
believe ). There hasn't been much new development in net wrt nio so I
guess it isn't an immediate concern. I was just wondering if there was
a min/max jdk/jvm version imposed by Jakarta Commons.
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
http://www.bloglines.com/blog/jbrekke ekkerbj@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] Minimum jdk/jvm version for net ( future ) ( was: Re: [vote][net]
Release commons-net 1.4.1? )
Posted by Mario Ivankovits <ma...@ops.co.at>.
Steve Cohen wrote:
> We need to discuss this further.
> Mario Ivankovits VFS is a client of Net and he has users still on 1.3
> who are complaining that Net 1.4 breaks VFS.
And not only my users constantly complain about it. AFAIK this is also
true for other commons components.
Though, there is an end of live for jdk1.3 and so we sould also to
define such a point in the future.
Personally I see this point reached in 6 months, but understand if we
have to stick on 1.3 for the next year.
Then we should jump to jdk 1.5 (with jdk 1.4 api) and use retroweaver to
provide the jdk 1.4 version.
Our releases should then contain jars for both (1.5 and 1.4)
I know there are the same issues with api compatibility, but if we run
our tests against both jdks we should be fine, also it might be possible
to have an api checker which will check the generated classes against
the classpath.
Whatever, we might find a way to archive this.
I know, this is somehow radical, but our code starts to smell and become
spider webs if we have to stick on 1.3 for the time being ;-)
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] Minimum jdk/jvm version for net ( future ) ( was: Re: [vote][net]
Release commons-net 1.4.1? )
Posted by Steve Cohen <sc...@javactivity.org>.
We need to discuss this further.
Mario Ivankovits VFS is a client of Net and he has users still on 1.3
who are complaining that Net 1.4 breaks VFS.
Jeffrey D. Brekke wrote:
> I understand the issues involved with pending release of vfs and
> compatibility with net, but I thought we discussed during the last
> release or so of net that we cut a 1.2/1.3 compatible release and from
> that release forward we were using 1.4 stuff ( nio I believe was the
> issue ). So projects that wanted to use net, but required older
> jvm/class compatibility would use the old version.
>
> Maybe I am mistaken though, did we just discuss this and never implement
> it? Just wondering about the future releases. Is there now a min or
> max jdk version for all commons projects?
>
> Steve Cohen wrote:
> [SNIPPED]
>
>>>> Which is just as well. Because I have another issue. I don't
>>>> understand the maven.compile.target property. Working from the net
>>>> 1.4.0 tag, I change only project.properties to set
>>>> maven.compile.target back to 1.2. Since there are a few places in
>>>> 1.4.0 that depend on jdk 1.4, my expectation was that changing the
>>>> project properties would cause the compile to break on those
>>>> places. But it did not. It compiled successfully.
>>>
>>>
>>>
>>> The jdk1.4 compiler creates a class file suitable to run under an
>>> earlier JVM, this works as long as you do not use any new api. Then
>>> you'll get the NoSuchMethod Exception.
>>
>>
>>
>> Of course, we did use new APIs, so for the purpose I had in mind, this
>> property is useless.
>>
>>> This is the reason why we should use the least possible compiler and
>>> not only the target attribute. You didnt notice if you use any new
>>> api call at compile time.
>>
>>
>>
>> I'll have to dig out a 1.3.1 compiler then. I don't even think 1.2.x
>> is available anymore.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[net] Minimum jdk/jvm version for net ( future ) ( was: Re: [vote][net]
Release commons-net 1.4.1? )
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
I understand the issues involved with pending release of vfs and
compatibility with net, but I thought we discussed during the last
release or so of net that we cut a 1.2/1.3 compatible release and from
that release forward we were using 1.4 stuff ( nio I believe was the
issue ). So projects that wanted to use net, but required older
jvm/class compatibility would use the old version.
Maybe I am mistaken though, did we just discuss this and never implement
it? Just wondering about the future releases. Is there now a min or
max jdk version for all commons projects?
Steve Cohen wrote:
[SNIPPED]
>>> Which is just as well. Because I have another issue. I don't
>>> understand the maven.compile.target property. Working from the net
>>> 1.4.0 tag, I change only project.properties to set
>>> maven.compile.target back to 1.2. Since there are a few places in
>>> 1.4.0 that depend on jdk 1.4, my expectation was that changing the
>>> project properties would cause the compile to break on those places.
>>> But it did not. It compiled successfully.
>>
>>
>> The jdk1.4 compiler creates a class file suitable to run under an
>> earlier JVM, this works as long as you do not use any new api. Then
>> you'll get the NoSuchMethod Exception.
>
>
> Of course, we did use new APIs, so for the purpose I had in mind, this
> property is useless.
>
>> This is the reason why we should use the least possible compiler and
>> not only the target attribute. You didnt notice if you use any new api
>> call at compile time.
>
>
> I'll have to dig out a 1.3.1 compiler then. I don't even think 1.2.x is
> available anymore.
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
http://www.bloglines.com/blog/jbrekke/ ekkerbj@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
Mario Ivankovits wrote:
> Steve Cohen wrote:
>
>>
>> The thread Robert refers to has the subject
>>
>> "Re: Does Apache have agreement to use other open source code outside
>> of Apache?"
>
> Has this something to do with an email from IBM in the last few days
> asking me if I am really was the creator of my contributions?
> Not that I made any mistake (I guess this was a mail to all commons-net
> developers), but I was a little bit irritated.
Hmm. Sounds like it. Although I got no such email myself, I only saw
it on the PMC Mailing List.
>
>> Which is just as well. Because I have another issue. I don't
>> understand the maven.compile.target property. Working from the net
>> 1.4.0 tag, I change only project.properties to set
>> maven.compile.target back to 1.2. Since there are a few places in
>> 1.4.0 that depend on jdk 1.4, my expectation was that changing the
>> project properties would cause the compile to break on those places.
>> But it did not. It compiled successfully.
>
> The jdk1.4 compiler creates a class file suitable to run under an
> earlier JVM, this works as long as you do not use any new api. Then
> you'll get the NoSuchMethod Exception.
Of course, we did use new APIs, so for the purpose I had in mind, this
property is useless.
> This is the reason why we should use the least possible compiler and not
> only the target attribute. You didnt notice if you use any new api call
> at compile time.
I'll have to dig out a 1.3.1 compiler then. I don't even think 1.2.x is
available anymore.
>
>
> ---
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by Dion Gillard <di...@gmail.com>.
On 12/2/05, Mario Ivankovits <ma...@ops.co.at> wrote:
> Steve Cohen wrote:
> >
> > The thread Robert refers to has the subject
> >
> > "Re: Does Apache have agreement to use other open source code outside
> > of Apache?"
> Has this something to do with an email from IBM in the last few days
> asking me if I am really was the creator of my contributions?
> Not that I made any mistake (I guess this was a mail to all commons-net
> developers), but I was a little bit irritated.
Probably. The commons-net copyright question was raised by an IBM email.
If you do get those questions, please make sure they get copied to
pmc@jakarta.apache.org. The PMC should be the one responsible for
answering questions about our code.
> > Which is just as well. Because I have another issue. I don't
> > understand the maven.compile.target property. Working from the net
> > 1.4.0 tag, I change only project.properties to set
> > maven.compile.target back to 1.2. Since there are a few places in
> > 1.4.0 that depend on jdk 1.4, my expectation was that changing the
> > project properties would cause the compile to break on those places.
> > But it did not. It compiled successfully.
> The jdk1.4 compiler creates a class file suitable to run under an
> earlier JVM, this works as long as you do not use any new api. Then
> you'll get the NoSuchMethod Exception.
> This is the reason why we should use the least possible compiler and not
> only the target attribute. You didnt notice if you use any new api call
> at compile time.
>
>
> ---
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
http://www.multitask.com.au/people/dion/
"You are going to let the fear of poverty govern your life and your
reward will be that you will eat, but you will not live." - George
Bernard Shaw
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by Mario Ivankovits <ma...@ops.co.at>.
Steve Cohen wrote:
>
> The thread Robert refers to has the subject
>
> "Re: Does Apache have agreement to use other open source code outside
> of Apache?"
Has this something to do with an email from IBM in the last few days
asking me if I am really was the creator of my contributions?
Not that I made any mistake (I guess this was a mail to all commons-net
developers), but I was a little bit irritated.
> Which is just as well. Because I have another issue. I don't
> understand the maven.compile.target property. Working from the net
> 1.4.0 tag, I change only project.properties to set
> maven.compile.target back to 1.2. Since there are a few places in
> 1.4.0 that depend on jdk 1.4, my expectation was that changing the
> project properties would cause the compile to break on those places.
> But it did not. It compiled successfully.
The jdk1.4 compiler creates a class file suitable to run under an
earlier JVM, this works as long as you do not use any new api. Then
you'll get the NoSuchMethod Exception.
This is the reason why we should use the least possible compiler and not
only the target attribute. You didnt notice if you use any new api call
at compile time.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
robert burrell donkin wrote:
> -1 to any commons-net new release. see pmc thread for details (if any
> committers aren't on the pmc please shout and i'll nominate you)
>
> - robert
>
> On Thu, 2005-12-01 at 07:47 +0100, Mario Ivankovits wrote:
>
>>Steve Cohen wrote:
>>
>>>As I have little time now, I propose the following. 1.4.1 will be
>>>just 1.4.0 with whatever changes are needed to reverse the dependency
>>>on jdk 1.4.x. No other bug fixes will be included.
>>>
>>>Re-vote
>>>
>>>+1 [yes]
>>>-1 [no]
>>
>>+1
>>
>>---
>>Mario
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
OK. Robert is referring to a serious issue here. It's prudent to wait.
There are questions about copyright on one of our classes.
The thread Robert refers to has the subject
"Re: Does Apache have agreement to use other open source code outside of
Apache?"
and it's all in the last couple of days.
So we have to wait.
Which is just as well. Because I have another issue. I don't
understand the maven.compile.target property. Working from the net
1.4.0 tag, I change only project.properties to set maven.compile.target
back to 1.2. Since there are a few places in 1.4.0 that depend on jdk
1.4, my expectation was that changing the project properties would cause
the compile to break on those places. But it did not. It compiled
successfully.
Why wouldn't it break?
Can someone explain how this works?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sat, 2005-12-03 at 17:53 +0000, Rory Winston wrote:
> Shouldn't that be "no substantive issues"? ;-)
LOL 8-)
+1
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by Rory Winston <rw...@eircom.net>.
Shouldn't that be "no substantive issues"? ;-)
robert burrell donkin wrote:
> i'm now +1
>
> i'd like to thanks rory for his quick response. i'm now satisfied that
> there are substantive issues with the net code and so i'm happy to
> change my -1 to a +1.
>
> - robert
>
> On Thu, 2005-12-01 at 22:08 +0000, robert burrell donkin wrote:
>
>> -1 to any commons-net new release. see pmc thread for details (if any
>> committers aren't on the pmc please shout and i'll nominate you)
>>
>> - robert
>>
>> On Thu, 2005-12-01 at 07:47 +0100, Mario Ivankovits wrote:
>>
>>> Steve Cohen wrote:
>>>
>>>> As I have little time now, I propose the following. 1.4.1 will be
>>>> just 1.4.0 with whatever changes are needed to reverse the dependency
>>>> on jdk 1.4.x. No other bug fixes will be included.
>>>>
>>>> Re-vote
>>>>
>>>> +1 [yes]
>>>> -1 [no]
>>>>
>>> +1
>>>
>>> ---
>>> Mario
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by robert burrell donkin <rd...@apache.org>.
i'm now +1
i'd like to thanks rory for his quick response. i'm now satisfied that
there are substantive issues with the net code and so i'm happy to
change my -1 to a +1.
- robert
On Thu, 2005-12-01 at 22:08 +0000, robert burrell donkin wrote:
> -1 to any commons-net new release. see pmc thread for details (if any
> committers aren't on the pmc please shout and i'll nominate you)
>
> - robert
>
> On Thu, 2005-12-01 at 07:47 +0100, Mario Ivankovits wrote:
> > Steve Cohen wrote:
> > > As I have little time now, I propose the following. 1.4.1 will be
> > > just 1.4.0 with whatever changes are needed to reverse the dependency
> > > on jdk 1.4.x. No other bug fixes will be included.
> > >
> > > Re-vote
> > >
> > > +1 [yes]
> > > -1 [no]
> > +1
> >
> > ---
> > Mario
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
Re: [vote][net] Release commons-net 1.4.1?
Posted by robert burrell donkin <rd...@apache.org>.
-1 to any commons-net new release. see pmc thread for details (if any
committers aren't on the pmc please shout and i'll nominate you)
- robert
On Thu, 2005-12-01 at 07:47 +0100, Mario Ivankovits wrote:
> Steve Cohen wrote:
> > As I have little time now, I propose the following. 1.4.1 will be
> > just 1.4.0 with whatever changes are needed to reverse the dependency
> > on jdk 1.4.x. No other bug fixes will be included.
> >
> > Re-vote
> >
> > +1 [yes]
> > -1 [no]
> +1
>
> ---
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [vote][net] Release commons-net 1.4.1?
Posted by Mario Ivankovits <ma...@ops.co.at>.
Steve Cohen wrote:
> As I have little time now, I propose the following. 1.4.1 will be
> just 1.4.0 with whatever changes are needed to reverse the dependency
> on jdk 1.4.x. No other bug fixes will be included.
>
> Re-vote
>
> +1 [yes]
> -1 [no]
+1
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 30 Nov 2005, Steve Cohen <sc...@javactivity.org> wrote:
> As I have little time now, I propose the following. 1.4.1 will be
> just 1.4.0 with whatever changes are needed to reverse the
> dependency on jdk 1.4.x. No other bug fixes will be included.
>
> Re-vote
>
> +1 [yes]
> -1 [no]
+1
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
Steve Cohen wrote:
> Mario Ivankovits wrote:
>
>> Steve Cohen wrote:
>>
>>> It has been discovered that 1.4.0 is inadvertently incompatible with
>>> jdk 1.3. Please vote on a release of a fixed version.
>>
>>
>> Checked VFS using "net svn head" and it works.
>>
>> So here is my +1
>>
>>
>> BTW: maven builds a 1.5.0 version instead of 1.4.1. Do you plan to
>> release svn head or a patched/rebuild 1.4.0?
>>
>> ---
>> Mario
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
> Please disregard my earlier reply. I realize that I misunderstood you.
> You are, I presume, talking about the version number of net that maven
> currently builds. This will have to be changed of course.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
As I have little time now, I propose the following. 1.4.1 will be just
1.4.0 with whatever changes are needed to reverse the dependency on jdk
1.4.x. No other bug fixes will be included.
Re-vote
+1 [yes]
-1 [no]
I vote +1.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
Mario Ivankovits wrote:
> Steve Cohen wrote:
>
>> It has been discovered that 1.4.0 is inadvertently incompatible with
>> jdk 1.3. Please vote on a release of a fixed version.
>
> Checked VFS using "net svn head" and it works.
>
> So here is my +1
>
>
> BTW: maven builds a 1.5.0 version instead of 1.4.1. Do you plan to
> release svn head or a patched/rebuild 1.4.0?
>
> ---
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
Please disregard my earlier reply. I realize that I misunderstood you.
You are, I presume, talking about the version number of net that maven
currently builds. This will have to be changed of course.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by Steve Cohen <sc...@javactivity.org>.
Mario Ivankovits wrote:
> Steve Cohen wrote:
>
>> It has been discovered that 1.4.0 is inadvertently incompatible with
>> jdk 1.3. Please vote on a release of a fixed version.
>
> Checked VFS using "net svn head" and it works.
>
> So here is my +1
>
>
> BTW: maven builds a 1.5.0 version instead of 1.4.1. Do you plan to
> release svn head or a patched/rebuild 1.4.0?
>
> ---
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
I suppose a head release. There are a few bugs fixed.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote][net] Release commons-net 1.4.1?
Posted by Mario Ivankovits <ma...@ops.co.at>.
Steve Cohen wrote:
> It has been discovered that 1.4.0 is inadvertently incompatible with
> jdk 1.3. Please vote on a release of a fixed version.
Checked VFS using "net svn head" and it works.
So here is my +1
BTW: maven builds a 1.5.0 version instead of 1.4.1. Do you plan to
release svn head or a patched/rebuild 1.4.0?
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org