Lucene's top-level build.xml has this;

 <target name="generate-maven-artifacts"
depends="maven.ant.tasks-check, package, jar-src, jar-demo-src,
javadocs">
    <sequential>
      <m2-deploy pom.xml="lucene-parent-pom.xml.template"/>
      <m2-deploy pom.xml="lucene-core-pom.xml.template">
        <artifact-attachments>
          <attach file="${build.dir}/${final.name}-src.jar"
                  classifier="sources"/>
          <attach file="${build.dir}/${final.name}-javadoc.jar"
                  classifier="javadoc"/>
        </artifact-attachments>
      </m2-deploy>

     <more follows>
   </target>

lucene-core-pom.xml.template is this;

<project>
  <parent>
    <groupId>org.apache.lucene</groupId>
    <artifactId>lucene-parent</artifactId>
    <version>@version@</version>
  </parent>
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.apache.lucene</groupId>
  <artifactId>lucene-core</artifactId>
  <name>Lucene Core</name>
  <version>@version@</version>
  <description>Apache Lucene Java Core</description>
  <packaging>jar</packaging>
</project>

The maven extension to Ant is pulled in with;

<project xmlns:artifact="antlib:org.apache.maven.artifact.ant">

availability is tested with;

 <available
    property="maven.ant.tasks.present"
    classname="org.apache.maven.artifact.ant.Pom"
  />

and the entire m2-deploy macro is;

  <macrodef name="m2-deploy" description="Builds a Maven artifact">
        <element name="artifact-attachments" optional="yes"/>
    <attribute name="pom.xml" default="${pom.xml}"/>
    <sequential>
      <copy file="@{pom.xml}" tofile="${build.dir}/@{pom.xml}">
        <filterset begintoken="@" endtoken="@">
          <filter token="version" value="${version}"/>
        </filterset>
      </copy>
          <artifact:install-provider artifactId="wagon-ssh"
version="1.0-beta-2"/>

      <artifact:pom id="maven.project" file="${build.dir}/@{pom.xml}" />
      <artifact:deploy file="${build.dir}/${maven.project.build.finalName}.jar">
        <artifact-attachments/>
        <remoteRepository url="${m2.repository.url}">
          <authentication username="${m2.repository.username}"
privateKey="${m2.repository.private.key}"/>
                </remoteRepository>
        <pom refid="maven.project"/>
      </artifact:deploy>
    </sequential>
  </macrodef>

So, you can put Maven shaped artifacts side by side with build.xml and
generate the appropriate artifacts. After that, it's just a question
of getting upload permission to the main repository.

B.

On Thu, Nov 6, 2008 at 2:47 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> Robert Newson wrote:
>>
>> However, for those of us, myself included, that do use Maven, could
>> Maven artifacts be deployed to the main repository as part of the
>> release cycle? That is the binary jar, source jar and javadoc jar?
>> It's not necessary to use Maven to do so (though it is easier); the
>> Lucene team push releases and they 'still' use Ant.
>
> Any idea what it takes to do this? I noticed that Ivy just pushed a new v2
> release candidate to apache-announce, is that necessary (ivy) or will
> straight ant work? From the ZK release management perspective how much
> additional work is required?
> http://ant.apache.org/ivy/download.cgi
>
> Patrick
>
>>
>> On Wed, Nov 5, 2008 at 10:00 PM, Jake Thompson <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Hi Hiram,
>>> I actually am just a user of zookeeper, I am not a "member" as of yet.  I
>>> am
>>> also a user of maven and ant and have been using both for many years.
>>>
>>> So while I would say it is never a bad decision to move to maven, it
>>> isn't
>>> always a needed decision.
>>>
>>> A standard build structure makes sense if you were building zookeeper
>>> yourself, but I don't beleive you would be doing that.  So that leaves
>>> the
>>> creation and building of your own projects like an ear, war, JBI, etc.
>>>  The
>>> problem with zookeeper is that there is no required project structure.
>>> There is no zar that is to say.
>>>
>>> I personally have a mavenized war project that I am using zookeeper in
>>> and I
>>> also have a hand rolled CL java program that uses it and is build with
>>> ant.
>>> For both of these I just needed to copy one jar into my lib.
>>> As far as dependency management, since zookeeper is so simple the only
>>> requirement is log4j, not really needing any complex dependency tools
>>> there.
>>>
>>> As far as modularity, again I see zookeeper being part of larger modules,
>>> so
>>> I don't know if we can draw a common modular zookeeper application
>>> structure.
>>>
>>> Maven is a great tool and can help alot, but I personally don't see it as
>>> synonymous with modern java development.
>>>
>>> -Jake
>>> On Wed, Nov 5, 2008 at 9:28 PM, Hiram Chirino
>>> <[EMAIL PROTECTED]>wrote:
>>>
>>>> It would help new developers work with your project.  Maven provides a
>>>> a broad set of tools that lots of java developers have come to expect
>>>> out of a build system.  Incorporating those tools manually into an Ant
>>>> based build would be very time consuming and make the build complex to
>>>> maintain.
>>>>
>>>> For example, in addition the standard build and package aspects of
>>>> build, folks expect the build system to:
>>>> - support generating the IDE integration files (Idea, eclipse, etc.).
>>>> - Run static analysis tools like find bugs
>>>> - Run test coverage reports
>>>> - Deployment to central servers
>>>> - License Checking
>>>> - Artifact signing
>>>>
>>>> And most importantly, they want a standard way of doing all that.
>>>>
>>>> Maven also encourages modularity in the architecture by making it easy
>>>> build multiple modules/jar files and easily describing the
>>>> dependencies between then.  And once you go modular, you will see how
>>>> folks start contributing alternative implementations of existing
>>>> modules.  Copying a module and it's build setup is easy to do with
>>>> maven..  A bit harder with something like ant since it's kinda
>>>> monolithic.
>>>>
>>>> Ant was a great tool so if you guys want to stick to your guns that's
>>>> cool.  But in this day and age, using a ant based open source project
>>>> is kinda like it was when we used make several years back to build
>>>> java projects.  Works fine, but dated.
>>>>
>>>>
>>>>
>>>> On Wed, Nov 5, 2008 at 1:11 PM, Jake Thompson <[EMAIL PROTECTED]>
>>>> wrote:
>>>>>
>>>>> It is quiet around here, I am new, could you please explain why you
>>>>> feel
>>>>
>>>> a
>>>>>
>>>>> Maven build structure is needed?
>>>>>
>>>>> Thanks,
>>>>> Jake
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Nov 5, 2008 at 1:05 PM, Hiram Chirino <[EMAIL PROTECTED]
>>>>> wrote:
>>>>>
>>>>>> Anyone out there?
>>>>>>
>>>>>> On Mon, Nov 3, 2008 at 9:23 AM, Hiram Chirino <[EMAIL PROTECTED]>
>>>>>> wrote:
>>>>>>>
>>>>>>> Congrats on the release.  Now that has been completed, I'd like to
>>>>>>> see
>>>>>>> if you guys are willing to revisit the issue of a maven based build.
>>>>>>> If yes, I'd be happy to assist making that happen.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Hiram
>>>>>>>
>>>>>>> On Mon, Oct 27, 2008 at 10:35 PM, Patrick Hunt <[EMAIL PROTECTED]>
>>>>
>>>> wrote:
>>>>>>>>
>>>>>>>> Our first official Apache release has shipped and I'm already
>>>>>>>> looking
>>>>>>>> forward to 3.1.0. ;-)
>>>>>>>>
>>>>>>>> In particular I believe we should look at the following for 3.1.0:
>>>>>>>>
>>>>>>>> 1) there are a number of issues that we're targeted to 3.1.0 during
>>>>
>>>> the
>>>>>>>>
>>>>>>>> 3.0.0 cycle. We need to review and address these.
>>>>>>>>
>>>>>>>> 2) system test. During 3.0.0 we made significant improvements to our
>>>>>>
>>>>>> test
>>>>>>>>
>>>>>>>> environment. However we still lack a large(r) scale system test
>>>>>>
>>>>>> environment.
>>>>>>>>
>>>>>>>> It would be great if we could simulate large scale use over 10s or
>>>>
>>>> 100s
>>>>>>
>>>>>> of
>>>>>>>>
>>>>>>>> machines (ensemble + clients). We need some sort of framework for
>>>>
>>>> this,
>>>>>>
>>>>>> and
>>>>>>>>
>>>>>>>> of course tests.
>>>>>>>>
>>>>>>>> 3) operations documentation. In general docs were greatly improved
>>>>>>>> in
>>>>>>
>>>>>> 3.x
>>>>>>>>
>>>>>>>> over 2.x. One area we are still lacking is operations docs for
>>>>>>>> design/management of a ZK cluster.
>>>>>>>> see https://issues.apache.org/jira/browse/ZOOKEEPER-160
>>>>>>>>
>>>>>>>> 4) JMX. Documentation needs to be written & the code
>>>>
>>>> reviewed/improved.
>>>>>>>>
>>>>>>>> Moving to Java6 should (afaik) allow us to take advantage of
>>>>>>>> improved
>>>>>>
>>>>>> JMX
>>>>>>>>
>>>>>>>> spec not available in 5. We should also consider making JMX the
>>>>
>>>> default
>>>>>>>>
>>>>>>>> rather than optional (ie you get JMX by default when ZK server is
>>>>>>
>>>>>> started).
>>>>>>>>
>>>>>>>> We need to ensure that ops can monitor/admin ZK using JMX.
>>>>>>>>
>>>>>>>> 5) (begin) multi-tenancy support. A number of users have expressed
>>>>>>
>>>>>> interest
>>>>>>>>
>>>>>>>> in being able to deploy ZK as a service in a cloud. Multi-tenancy
>>>>>>
>>>>>> support
>>>>>>>>
>>>>>>>> would be a huge benefit (quota, qos, namespace partitioning of
>>>>>>>> nodes,
>>>>>>>> billing, etc...)
>>>>>>>>
>>>>>>>> Of course ZooKeeper is open to submissions in that aren't on this
>>>>
>>>> list.
>>>>>>
>>>>>> If
>>>>>>>>
>>>>>>>> you have any suggestions please feel free to enter a JIRA or submit
>>>>>>>> a
>>>>>>
>>>>>> patch.
>>>>>>>>
>>>>>>>> Additionally I'd like to see us move to an 8 week release cycle.
>>>>>>>> I've
>>>>>>>> updated the JIRA version list to reflect this. Due to the holiday
>>>>
>>>> season
>>>>>>>>
>>>>>>>> approaching I've listed 3.1.0 with a ship date of Jan 19th. (see the
>>>>>>
>>>>>> roadmap
>>>>>>>>
>>>>>>>> on the JIRA).
>>>>>>>>
>>>>>>>> If you have any questions/comments please reply to this email.
>>>>>>>>
>>>>>>>> Patrick
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Hiram
>>>>>>>
>>>>>>> Blog: http://hiramchirino.com
>>>>>>>
>>>>>>> Open Source SOA
>>>>>>> http://open.iona.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Hiram
>>>>>>
>>>>>> Blog: http://hiramchirino.com
>>>>>>
>>>>>> Open Source SOA
>>>>>> http://open.iona.com
>>>>>>
>>>>
>>>>
>>>> --
>>>>  Regards,
>>>> Hiram
>>>>
>>>> Blog: http://hiramchirino.com
>>>>
>>>> Open Source SOA
>>>> http://open.iona.com
>>>>
>

Reply via email to