Re: 3.0 release (and maven)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Nick, On Wed, 25 Apr 2007, Joerg Hohwiller wrote: But from what I see in your subversion, you still need to replace issueTrackingUrl with issueManagement. Done I also went through your ant build and have seen that you do not modify the root tag metadata. The also needs to be changed to project, what might be the major reason for the bugzialla issue about the POM file. Done Since you have 3 artifacts (jar-files): poi, poi-contrib, poi-scratchpad you will need 3 individual pom.xml files. Closer inspection of the build process shows that's not true. For the main release, we do have 3 different jar files. However, we build a different jar file for pushing out to the maven repository. The maven jar file (and source jar file) contains all of main, contrib and scratchpad, rolled into one. So, we do only need the one pom file after all. As far as I can see this has been done additionally to the 3 individual artifacts as you can see here: http://repo1.maven.org/maven2/poi/ Who ever did this, I dont know... Guess that makes things simpler, shame I didn't remember earlier! okay, however this will be the way you want to go with 3.0 if I got you right... Then you would have a version. I would suggest to call the version 3.0. - From your suggesstion above the version would be 3.0-final. If maven needs to compare the version with another one to decide which one is newer, it would be better and more straight forward to use 3.0. The official version is 3.0-final though, not 3.0. It's hardly an unusual naming convention, so I'd be surprised if maven couldn't tell that 3.0-final is newer than 3.0-alpha3. If not, I'm sure they take patches :) It will surely work without patch. The artifacts would be located in the repository like this: org/apache/poi/poi-contrib/3.0/poi-contrib-3.0.pom org/apache/poi/poi-contrib/3.0/poi-contrib-3.0.jar org/apache/poi/poi-contrib/3.0/poi-contrib-3.0-sources.jar It looks like the apache thing is to put poms in one directory under m1-ibiblio-rsync-repository, and jars in another. I guess the ibiblio sync script does the right thing with that When I do rc4, I'll also do a maven pom, and jar + source jar. I'll sling them on people.apache.org as usual, so it'd be great if you could check they look fine. Jep, I will double check this. Let me know when its out... Cheers for all the maven help. No worries - thanks for taking care of the maven users. Not sure you've won too many converts to maven though... I am not an evangelist. I like it but feel free to do what ever you like ;) Nick Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGNnILmPuec2Dcv/8RAqYGAJ9snlEiZgFU2YdZeR/tnthSntCeDwCfdwCK jQImQWYEyyLVnlt5WBaj9a4= =s3TW -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List: http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta Poi Project: http://jakarta.apache.org/poi/
Re: 3.0 release (and maven)
On Wed, 25 Apr 2007, Joerg Hohwiller wrote: But from what I see in your subversion, you still need to replace issueTrackingUrl with issueManagement. Done I also went through your ant build and have seen that you do not modify the root tag metadata. The also needs to be changed to project, what might be the major reason for the bugzialla issue about the POM file. Done Since you have 3 artifacts (jar-files): poi, poi-contrib, poi-scratchpad you will need 3 individual pom.xml files. Closer inspection of the build process shows that's not true. For the main release, we do have 3 different jar files. However, we build a different jar file for pushing out to the maven repository. The maven jar file (and source jar file) contains all of main, contrib and scratchpad, rolled into one. So, we do only need the one pom file after all. Guess that makes things simpler, shame I didn't remember earlier! Then you would have a version. I would suggest to call the version 3.0. - From your suggesstion above the version would be 3.0-final. If maven needs to compare the version with another one to decide which one is newer, it would be better and more straight forward to use 3.0. The official version is 3.0-final though, not 3.0. It's hardly an unusual naming convention, so I'd be surprised if maven couldn't tell that 3.0-final is newer than 3.0-alpha3. If not, I'm sure they take patches :) The artifacts would be located in the repository like this: org/apache/poi/poi-contrib/3.0/poi-contrib-3.0.pom org/apache/poi/poi-contrib/3.0/poi-contrib-3.0.jar org/apache/poi/poi-contrib/3.0/poi-contrib-3.0-sources.jar It looks like the apache thing is to put poms in one directory under m1-ibiblio-rsync-repository, and jars in another. I guess the ibiblio sync script does the right thing with that When I do rc4, I'll also do a maven pom, and jar + source jar. I'll sling them on people.apache.org as usual, so it'd be great if you could check they look fine. Cheers for all the maven help. Not sure you've won too many converts to maven though... Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List: http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta Poi Project: http://jakarta.apache.org/poi/
Re: 3.0 release (and maven)
On Tue, 24 Apr 2007, Joerg Hohwiller wrote: issueManagement systembugzilla/system urlhttp://issues.apache.org/bugzilla//url /issueManagement Thanks, I've updated that BTW: I assume that we are just talking about maven2 here and NOT about maven1. Since that seems to be the version most people use, I guess so. As I said, I'm not a maven user myself, and I normally end up with a headache whenever I try and learn Since you have 3 artifacts (jar-files): poi, poi-contrib, poi-scratchpad you will need 3 individual pom.xml files. The poi-contrib and poi-scratchpad also need dependencies. Further you could think about creating an additional pom file to keep the parent metadata (licnese, scm, issueManagement, etc.) out of the other pom's and avoid redundancies. But since you named the main artifact poi and not e.g. poi-core this might not fit here. I don't think it'd be too hard to have the ant build file spit out three poms from the same template. That would also save us the faff of deciding what needs to get split into a parent pom, what doesn't etc. For contrib and scratchpad, I guess we want to call the output pom something like poi-scratchpad-3.0-final.pom. Is the artificatId then poi-scratchpad? Is the dependency groupId=org.apache.poi, artificatId=poi, and version=(same version) ? If you want I could create the three POM files for you and attach them to the bugzilla issue. If it's just the scratchpad and contrib poms that need updating (the main one now being fine), could you do a version for one of them? I can then work it into the ant build file. Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List: http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta Poi Project: http://jakarta.apache.org/poi/
Re: 3.0 release (and maven)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Nick,
On Tue, 24 Apr 2007, Joerg Hohwiller wrote:
issueManagement
systembugzilla/system
urlhttp://issues.apache.org/bugzilla//url
/issueManagement
Thanks, I've updated that
okay.
But from what I see in your subversion, you still need to replace
issueTrackingUrl with issueManagement.
I also went through your ant build and have seen that you do not modify the root
tag metadata. The also needs to be changed to project, what might be the
major reason for the bugzialla issue about the POM file.
BTW: I assume that we are just talking about maven2 here and NOT about
maven1.
Since that seems to be the version most people use, I guess so.
Since maven1 does NOT support transitive dependencies the POMs are
not too relevant for the users. Maybe the maven guyz create maven1
artifacts automatically if maven2 artifacts are added - I do not know...
As I said, I'm not a maven user myself, and I normally end up with a headache
whenever I try and learn
Since you have 3 artifacts (jar-files): poi, poi-contrib,
poi-scratchpad you will need 3 individual pom.xml files. The
poi-contrib and poi-scratchpad also need dependencies. Further you
could think about creating an additional pom file to keep the parent
metadata (licnese, scm, issueManagement, etc.) out of the other pom's
and avoid redundancies. But since you named the main artifact poi
and not e.g. poi-core this might not fit here.
I don't think it'd be too hard to have the ant build file spit out three
poms from the same template. That would also save us the faff of
deciding what needs to get split into a parent pom, what doesn't etc.
Yep, I think the best thing would be to have one template per POM.
For contrib and scratchpad, I guess we want to call the output pom
something like poi-scratchpad-3.0-final.pom. Is the artificatId then
poi-scratchpad? Is the dependency groupId=org.apache.poi,
artificatId=poi, and version=(same version) ?
The groupId should be the same for all of your artifacts (JAR files and
according POMs). As we discussed earlier it would make sense to use
org.apache.poi.
The artifactId is the major part of the name of the JAR file.
So you would have the artifact IDs
poi, poi-contrib, and poi-scratchpad.
Then you would have a version. I would suggest to call the version 3.0.
- From your suggesstion above the version would be 3.0-final.
If maven needs to compare the version with another one to decide which one is
newer, it would be better and more straight forward to use 3.0.
So for
groupIdorg.apache.poi/groupId
artifactIdpoi-contrib/artifactId
version3.0/version
The artifacts would be located in the repository like this:
org/apache/poi/poi-contrib/3.0/poi-contrib-3.0.pom
org/apache/poi/poi-contrib/3.0/poi-contrib-3.0.jar
org/apache/poi/poi-contrib/3.0/poi-contrib-3.0-sources.jar
The general pattern is:
groupId.replace('.', '/')/artifactId/version/artifactId-version*
The *-sources.jar is not required, but if you supply it and someone
uses maven to configure its IDE (e.g. eclipse, netbeans, intelliJ)
then the sources are automatically attached and can be browsed in
your IDE what is very handy.
If you want I could create the three POM files for you and attach them
to the bugzilla issue.
If it's just the scratchpad and contrib poms that need updating (the
main one now being fine), could you do a version for one of them? I can
then work it into the ant build file.
project
modelVersion4.0.0/modelVersion
groupIdorg.apache.poi/groupId
artifactIdpoi-contrib/artifactId
version@VERSION@/version
packagingjar/packaging
nameJakarta POI Contrib/name
urlhttp://jakarta.apache.org/poi//url
descriptionJakarta POI Contrib - TODO/description
dependencies
dependency
groupIdorg.apache.poi/groupId
artifactIdpoi/artifactId
version@VERSION@/version
/dependency
/dependencies
licenses
license
nameThe Apache Software License, Version 2.0/name
urlhttp://www.apache.org/licenses/LICENSE-2.0.txt/url
distributionrepo/distribution
/license
/licenses
/project
Feel free to add some of the extra tags (scm, ...) from the other template if
you want to. The dependency says that I someone wants to use poi-contrib,
then he will also needs poi.
If you wanted to create a parent pom then you would need to set packaging to
pom there (instead of jar) and use
groupIdorg.apache.poi/groupId
artifactIdpoi-parent/artifactId
version1.0/version
Since you would not need to change the parent pom with a new release, the
version could be independend of the release version.
In the other three poms you would inherit from that by adding
parent
groupIdorg.apache.poi/groupId
artifactIdpoi-parent/artifactId
version1.0/version
/parent
Then you can remove all the tags (license, scm, issueManagement) from the other
3 poms and only keep them together in the parent pom.
(A more convenient naming scheme
Re: 3.0 release (and maven)
No you clarified that Maven is an even more convoluted clusterfsck than
I remembered.
Joerg Hohwiller wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Nick,
On Tue, 24 Apr 2007, Joerg Hohwiller wrote:
issueManagement
systembugzilla/system
urlhttp://issues.apache.org/bugzilla//url
/issueManagement
Thanks, I've updated that
okay.
But from what I see in your subversion, you still need to replace
issueTrackingUrl with issueManagement.
I also went through your ant build and have seen that you do not modify the root
tag metadata. The also needs to be changed to project, what might be the
major reason for the bugzialla issue about the POM file.
BTW: I assume that we are just talking about maven2 here and NOT about
maven1.
Since that seems to be the version most people use, I guess so.
Since maven1 does NOT support transitive dependencies the POMs are
not too relevant for the users. Maybe the maven guyz create maven1
artifacts automatically if maven2 artifacts are added - I do not know...
As I said, I'm not a maven user myself, and I normally end up with a headache
whenever I try and learn
Since you have 3 artifacts (jar-files): poi, poi-contrib,
poi-scratchpad you will need 3 individual pom.xml files. The
poi-contrib and poi-scratchpad also need dependencies. Further you
could think about creating an additional pom file to keep the parent
metadata (licnese, scm, issueManagement, etc.) out of the other pom's
and avoid redundancies. But since you named the main artifact poi
and not e.g. poi-core this might not fit here.
I don't think it'd be too hard to have the ant build file spit out three
poms from the same template. That would also save us the faff of
deciding what needs to get split into a parent pom, what doesn't etc.
Yep, I think the best thing would be to have one template per POM.
For contrib and scratchpad, I guess we want to call the output pom
something like poi-scratchpad-3.0-final.pom. Is the artificatId then
poi-scratchpad? Is the dependency groupId=org.apache.poi,
artificatId=poi, and version=(same version) ?
The groupId should be the same for all of your artifacts (JAR files and
according POMs). As we discussed earlier it would make sense to use
org.apache.poi.
The artifactId is the major part of the name of the JAR file.
So you would have the artifact IDs
poi, poi-contrib, and poi-scratchpad.
Then you would have a version. I would suggest to call the version 3.0.
- From your suggesstion above the version would be 3.0-final.
If maven needs to compare the version with another one to decide which one is
newer, it would be better and more straight forward to use 3.0.
So for
groupIdorg.apache.poi/groupId
artifactIdpoi-contrib/artifactId
version3.0/version
The artifacts would be located in the repository like this:
org/apache/poi/poi-contrib/3.0/poi-contrib-3.0.pom
org/apache/poi/poi-contrib/3.0/poi-contrib-3.0.jar
org/apache/poi/poi-contrib/3.0/poi-contrib-3.0-sources.jar
The general pattern is:
groupId.replace('.', '/')/artifactId/version/artifactId-version*
The *-sources.jar is not required, but if you supply it and someone
uses maven to configure its IDE (e.g. eclipse, netbeans, intelliJ)
then the sources are automatically attached and can be browsed in
your IDE what is very handy.
If you want I could create the three POM files for you and attach them
to the bugzilla issue.
If it's just the scratchpad and contrib poms that need updating (the
main one now being fine), could you do a version for one of them? I can
then work it into the ant build file.
project
modelVersion4.0.0/modelVersion
groupIdorg.apache.poi/groupId
artifactIdpoi-contrib/artifactId
version@VERSION@/version
packagingjar/packaging
nameJakarta POI Contrib/name
urlhttp://jakarta.apache.org/poi//url
descriptionJakarta POI Contrib - TODO/description
dependencies
dependency
groupIdorg.apache.poi/groupId
artifactIdpoi/artifactId
version@VERSION@/version
/dependency
/dependencies
licenses
license
nameThe Apache Software License, Version 2.0/name
urlhttp://www.apache.org/licenses/LICENSE-2.0.txt/url
distributionrepo/distribution
/license
/licenses
/project
Feel free to add some of the extra tags (scm, ...) from the other template if
you want to. The dependency says that I someone wants to use poi-contrib,
then he will also needs poi.
If you wanted to create a parent pom then you would need to set packaging to
pom there (instead of jar) and use
groupIdorg.apache.poi/groupId
artifactIdpoi-parent/artifactId
version1.0/version
Since you would not need to change the parent pom with a new release, the
version could be independend of the release version.
In the other three poms you would inherit from that by adding
parent
groupIdorg.apache.poi/groupId
artifactIdpoi-parent/artifactId
version1.0/version
/parent
Then
Re: 3.0 release (and maven)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Nick, So bug #39977 is not an issue anymore? The groupId bit isn't. Now we understand what it should be, we can use the java package, and all will be fine. Comment #2 (http://issues.apache.org/bugzilla/show_bug.cgi?id=39977#c2) still needs looking at, by someone who understands what's up with the pom. If we are talking about this: http://svn.apache.org/repos/asf/jakarta/poi/trunk/poi.pom I can tell you that the line issueTrackingUrlhttp://issues.apache.org/bugzilla//issueTrackingUrl should be issueManagement systembugzilla/system urlhttp://issues.apache.org/bugzilla//url /issueManagement instead. I think that was maven1 and does NOT work for maven2 and modelVersion 4.0.0. BTW: I assume that we are just talking about maven2 here and NOT about maven1. For a complete reference see: http://maven.apache.org/maven-model/maven.html Since you have 3 artifacts (jar-files): poi, poi-contrib, poi-scratchpad you will need 3 individual pom.xml files. The poi-contrib and poi-scratchpad also need dependencies. Further you could think about creating an additional pom file to keep the parent metadata (licnese, scm, issueManagement, etc.) out of the other pom's and avoid redundancies. But since you named the main artifact poi and not e.g. poi-core this might not fit here. If you want I could create the three POM files for you and attach them to the bugzilla issue. Then you can see how to adjust your templates and ant build to have such outcome. Whenever you think about switching from ant to maven for the build just let me know, too ;) Actually the groupId should be compliant to the package name. OK, I've fixed it in svn. The next build will use org.apache.poi as the groupId okay. Also, as well as changing the group id, should I put the files under /poi/, or under /org.apache.poi/ ? It looks like most apache projects just use their short name, but a few use org.apache.name . We currently use /poi/. The shorthand comes from the maven1 times where nobody cared about it. But its ugly and also causes that browsing the repository at top-level produces a really long list. There is quite a reasonable load on the server... Anyways it is the same for java-packages. If you do NOT use it properly it might clush with another project and causes big trouble. Anyways its up to you how to decide... Well, we've used it for ages without complaint from users or server operators, so I don't see the need to change it right now. I'll try to have a chat with some of the Mavern guys at apachecon EU in a couple of weeks, and see what they think we should do about the distribution directory name. Its always a good idea to ask several people before making a decision ;) If anyone does have any thoughts on the poi pom file (eg values we should add, or current ones to update), do drop an email to poi-dev saying what we should fix and why :) Well if you do NOT use maven for the build and you also do NOT want to have the overhead of an additional parent POM then you could think about kicking out the scm and issueManagement sections. The url points to the website and everything is there. Having the license in the pom as well is a good decision and should NOT be changed. Nick Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLnOhmPuec2Dcv/8RAgw8AJ9ttCYkWDRh9FyTo/xKRDaEk/tapACeICEb 9+NP9CwZAWs5LHZ1ZTMGBTs= =BnfS -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List: http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta Poi Project: http://jakarta.apache.org/poi/
Re: 3.0 release (and maven)
On Thu, 19 Apr 2007, Joerg Hohwiller wrote: So bug #39977 is not an issue anymore? The groupId bit isn't. Now we understand what it should be, we can use the java package, and all will be fine. Comment #2 (http://issues.apache.org/bugzilla/show_bug.cgi?id=39977#c2) still needs looking at, by someone who understands what's up with the pom. Actually the groupId should be compliant to the package name. OK, I've fixed it in svn. The next build will use org.apache.poi as the groupId Also, as well as changing the group id, should I put the files under /poi/, or under /org.apache.poi/ ? It looks like most apache projects just use their short name, but a few use org.apache.name . We currently use /poi/. The shorthand comes from the maven1 times where nobody cared about it. But its ugly and also causes that browsing the repository at top-level produces a really long list. There is quite a reasonable load on the server... Anyways it is the same for java-packages. If you do NOT use it properly it might clush with another project and causes big trouble. Anyways its up to you how to decide... Well, we've used it for ages without complaint from users or server operators, so I don't see the need to change it right now. I'll try to have a chat with some of the Mavern guys at apachecon EU in a couple of weeks, and see what they think we should do about the distribution directory name. If anyone does have any thoughts on the poi pom file (eg values we should add, or current ones to update), do drop an email to poi-dev saying what we should fix and why :) Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List: http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta Poi Project: http://jakarta.apache.org/poi/
Re: 3.0 release (and maven)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Nick, Are you planning to put the 3.0 release into the maven repository as soon as it is out? As part of the release process, I'll copy them onto people.apache.org, as per http://www.apache.org/dev/release-publishing.html#repository-guide . Apparently, the files then appear on the ibiblio mirrors, and all is good. So bug #39977 is not an issue anymore? Is there something to discuss, that could be done now rather than after the release has been pulled out? E.g. if the goupId should change from poi to org.apache.poi what would make sense (lucene did do this too). Given that our java package is org.apache.poi, I don't think that should be an issue to change. However, I don't use maven, so I have no idea what sort of an effect that sort of change would have. Actually the groupId should be compliant to the package name. Cite from http://maven.apache.org/guides/getting-started/index.html groupId This element indicates the unique identifier of the organization or group that created the project. The groupId is one of the key identifiers of a project and is typically based on the fully qualified domain name of your organization. For example org.apache.maven.plugins is the designated groupId for all Maven plug-ins. Any maven users care to comment? Also, as David said, any help with the pom files appreciated :) I would like to help. Where is help needed? Issue #39977 or something else? I Will make a review on your POM templates. Also, as well as changing the group id, should I put the files under /poi/, or under /org.apache.poi/ ? It looks like most apache projects just use their short name, but a few use org.apache.name . We currently use /poi/. The shorthand comes from the maven1 times where nobody cared about it. But its ugly and also causes that browsing the repository at top-level produces a really long list. There is quite a reasonable load on the server... Anyways it is the same for java-packages. If you do NOT use it properly it might clush with another project and causes big trouble. Anyways its up to you how to decide... Nick Best Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJ+XGmPuec2Dcv/8RAr3XAJ0RyEvTFjAiMGUyJu+eZUUU1s3b+ACgh7ae bosfso/hml4Bv+6TeVvYggE= =EeIc -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List: http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta Poi Project: http://jakarta.apache.org/poi/
Re: 3.0 release (and maven)
On Tue, 17 Apr 2007, Joerg Hohwiller wrote: Are you planning to put the 3.0 release into the maven repository as soon as it is out? As part of the release process, I'll copy them onto people.apache.org, as per http://www.apache.org/dev/release-publishing.html#repository-guide . Apparently, the files then appear on the ibiblio mirrors, and all is good. Is there something to discuss, that could be done now rather than after the release has been pulled out? E.g. if the goupId should change from poi to org.apache.poi what would make sense (lucene did do this too). Given that our java package is org.apache.poi, I don't think that should be an issue to change. However, I don't use maven, so I have no idea what sort of an effect that sort of change would have. Any maven users care to comment? Also, as David said, any help with the pom files appreciated :) Also, as well as changing the group id, should I put the files under /poi/, or under /org.apache.poi/ ? It looks like most apache projects just use their short name, but a few use org.apache.name . We currently use /poi/. Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List: http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta Poi Project: http://jakarta.apache.org/poi/
3.0 release (and maven)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, everybody is waiting for the 3.0 release and everything in head is better than an almost 3 years old release. Anyways take the time you need to have a release that you are happy with. I already migrated my project from 2.5.1-final-20040804 to 3.0-rc3 with good results. I did not see the point for binary incompatibility of HSSF (was it UnicodeString instead of String as return-type? cant remember) but that does not matter for me. The WordExtractor is also very useful and will allow me to kick out tm-extractors. Are you planning to put the 3.0 release into the maven repository as soon as it is out? I would be very pleased if this could happen quickly. If I can help anyhow on this task, just let me know. Is there something to discuss, that could be done now rather than after the release has been pulled out? E.g. if the goupId should change from poi to org.apache.poi what would make sense (lucene did do this too). Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJSAgmPuec2Dcv/8RAsU3AJ9dTh0Q1E7iiqnKrRriaq8MjHQe2wCgj+H7 cm5icKwYfePhr10EafiM6Ww= =bMdG -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List: http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta Poi Project: http://jakarta.apache.org/poi/
Re: 3.0 release (and maven)
Hi Jörg, I'm replying this to the poi-dev list as well as poi-user. It seems that Nick (who is building the current POI 3.0 RC candidates) could use some help with Maven. http://issues.apache.org/bugzilla/show_bug.cgi?id=39977 --- Additional Comments From [EMAIL PROTECTED] 2007-04-10 02:50 --- What do we need to change to fix this? (I'm not a maven user myself) The pom file is auto-generated by the maven-dist ant task, based on a template that's in svn. Any patches to build.xml or the template poi.pom appreciated :) Are the guy? I hope so. A release would be sweet! BTW - I would be helpful to the guys clearing bugs before release if anyone who has submitted a bug in bugzilla would test against RC3 and provide a result. If your bug is still there, and you have not already done so, please provide a test case. I expect that large HSSF / lower memory impact is an RFE for 3,X or 4.0. I have an idea (I'm sure that there are a few others) but I'm not talking about it until the 3.0 release is DONE! Best Regards, Dave On Apr 17, 2007, at 2:29 PM, Jörg Hohwiller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, everybody is waiting for the 3.0 release and everything in head is better than an almost 3 years old release. Anyways take the time you need to have a release that you are happy with. I already migrated my project from 2.5.1-final-20040804 to 3.0-rc3 with good results. I did not see the point for binary incompatibility of HSSF (was it UnicodeString instead of String as return-type? cant remember) but that does not matter for me. The WordExtractor is also very useful and will allow me to kick out tm-extractors. Are you planning to put the 3.0 release into the maven repository as soon as it is out? I would be very pleased if this could happen quickly. If I can help anyhow on this task, just let me know. Is there something to discuss, that could be done now rather than after the release has been pulled out? E.g. if the goupId should change from poi to org.apache.poi what would make sense (lucene did do this too). Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJSAgmPuec2Dcv/8RAsU3AJ9dTh0Q1E7iiqnKrRriaq8MjHQe2wCgj+H7 cm5icKwYfePhr10EafiM6Ww= =bMdG -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List: http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta Poi Project: http://jakarta.apache.org/poi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] Mailing List: http://jakarta.apache.org/site/mail2.html#poi The Apache Jakarta Poi Project: http://jakarta.apache.org/poi/
