Hi,
I have created some maven POM files which can be used to build and deploy ABCL with maven. There have been a few modifications to these over the past few days and there is probably room for improvement but these make it possible to build and depoy ABCL with the normal maven lifecycle.
Included are the following
pom.xml => abcl\pom.xml (abcl-parent) main-pom.xml => abcl\main\pom.xml (abcl) contrib-pom.xml => abcl\contrib\pom.xml (abcl-contrib)
Note: Filenames are relative to the trunk so they include the abcl prefix.
These have been posted as a gist on github at https://gist.github.com/rritoch/70f9f211c523499b794a
I have tested by deploying to my localrepo and the abcl artifact is functional.
Additional work may be needed on the abcl-contrib artifact POM because I'm unsure how to test it. The file size is similar to the one generated by ant so it may be correct.
Best Regards, Ralph Ritoch
On 2015/7/21 19:27, Ralph Ritoch wrote:
Hi,
I have created some maven POM files which can be used to build and deploy ABCL with maven. There have been a few modifications to these over the past few days and there is probably room for improvement but these make it possible to build and depoy ABCL with the normal maven lifecycle.
Thanks!
A couple questions:
1) Is it possible to merge the new main/pom.xml into top-level POM? Creating a new directory just to separate the main ABCL build instructions seems a little wrong to me.
2) Why not use the Ant instructions for building the actual abcl.jar artifact? It would be better for future maintenance not to have two sets of instructions for constructing deployment artifacts.
3) Can we make the GPG signing optional for the 'install' target?
Mark,
To answer your questions as best I can.
1) Is it possible to merge the new main/pom.xml into top-level POM? Creating a new directory just to separate the main ABCL build instructions seems a little wrong to me.
This was done because there's no need for the abcl artifact to include the contents of the abcl-contrib artifact, or vice-versa. It may be possible but it isn't something I know how to do. Typically the sources for abcl would be included in the main/ (abcl) module directory, so the wrongness is that the file structure of ABCL was not designed for maven.
2) Why not use the Ant instructions for building the actual abcl.jar artifact? It would be better for future maintenance not to have two sets of instructions for constructing deployment artifacts.
If ant builds the jar I don't believe maven will pick it up. The abcl-contrib that is deployed by maven isn't the one that is built by ant, and is ignored. It is the one built by maven that's deployed. The ant compiling process is dumping all of the compiled lisp files where maven knows to find them for building the jar, and that is how it works. I don't believe maven will pick up a jar generated by a third party process when using the install or deploy targets.
3) Can we make the GPG signing optional for the 'install' target?
Maven does provide the ability to create profiles so yes, a profile could be created which contains the GPG signing so that only builds with that profile would include the GPG signing.
I am not a maven expert, but this is what I was able to come up with in a short time-span. I do expect these will be improved so if you want to modify them and re-submit with improvements I have no objections. The gpg signing is required for submission to sonatype/central, and that is the primary reason it is included.
Best Regards, Ralph Ritoch
On Fri, Jul 24, 2015 at 2:44 PM, Mark Evenson evenson@panix.com wrote:
On 2015/7/21 19:27, Ralph Ritoch wrote:
Hi,
I have created some maven POM files which can be used to build and deploy ABCL with maven. There have been a few modifications to these over the
past
few days and there is probably room for improvement but these make it possible to build and depoy ABCL with the normal maven lifecycle.
Thanks!
A couple questions:
- Is it possible to merge the new main/pom.xml into top-level POM?
Creating a new directory just to separate the main ABCL build instructions seems a little wrong to me.
- Why not use the Ant instructions for building the actual abcl.jar
artifact? It would be better for future maintenance not to have two sets of instructions for constructing deployment artifacts.
- Can we make the GPG signing optional for the 'install' target?
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Mark,
I have added a separate build profile for deployment to maven central. When the "default" profile is used the source release and javadoc aren't generated, and the gpg signing isn't executed. To use this new full profile, such as for deploying to maven central, you must append -Dbuild=full to your command line. For example, mvn install -Dbuild=full , if you don't include this extra argument the javadocs and source releases aren't generated and the gpg signing isn't applied. These new pom's are on git.
https://github.com/rritoch/abcl/blob/master/abcl/pom.xml https://github.com/rritoch/abcl/blob/master/abcl/main/pom.xml https://github.com/rritoch/abcl/blob/master/abcl/contrib/pom.xml
My next project will be to attempt to release version 1.3.2 to a maven central repository which will likely require some additional changes to these pom files.
Best Regards, Ralph Ritoch
On Fri, Jul 24, 2015 at 2:44 PM, Mark Evenson evenson@panix.com wrote:
On 2015/7/21 19:27, Ralph Ritoch wrote:
Hi,
I have created some maven POM files which can be used to build and deploy ABCL with maven. There have been a few modifications to these over the
past
few days and there is probably room for improvement but these make it possible to build and depoy ABCL with the normal maven lifecycle.
Thanks!
A couple questions:
- Is it possible to merge the new main/pom.xml into top-level POM?
Creating a new directory just to separate the main ABCL build instructions seems a little wrong to me.
- Why not use the Ant instructions for building the actual abcl.jar
artifact? It would be better for future maintenance not to have two sets of instructions for constructing deployment artifacts.
- Can we make the GPG signing optional for the 'install' target?
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Mark,
These maven pom files have all been updated and tested on sonatype using my own groupId. A small number of changes were required and it turns out that in a multi-module project the parent module can't produce a jar. This re-iterates the requirement for the main/pom.xml file. I attempted to do without the main/pom.xml file but it wouldn't produce the an abcl package that way.The release was made with the code on a 1.3.2-maven git branch located at https://github.com/rritoch/abcl/tree/1.3.2-maven . I have updated the pom.xml files on my master branch to reflect the required changes to be fully compatible with sonatype's deployment process.
The deployment process with these pom files is as follows.
1. Change all version numbers in abcl/pom.xml , abcl/contrib/pom.xml, and abcl/main/pom.xml to an absolute version number without the -SNAPSHOT extension.
2. Execute mvn deploy -Dbuild=full
3. Login to oss sonatype, locate the staging repository in Build Promotion
Staging Repositories (in the left menu), close the repository, and
finally release the repository.
This is MUCH easier, and more efficient than the current process. Deployment to localrepo is as simple as just typing mvn install and I believe it no longer requires the gpg signing process. These will continue to work without maintenance as long as the ant build targets aren't renamed or significantly changed.
The artifacts I deployed are accessible with the following dependencies. I left in the original group-id commented out since this isn't an official release.
<dependency> <!-- <groupId>org.armedbear.lisp</groupId> --> <groupId>com.vnetpublishing.abcl</groupId> <artifactId>abcl</artifactId> <version>1.3.2</version> </dependency>
<dependency> <!-- <groupId>org.armedbear.lisp</groupId> --> <groupId>com.vnetpublishing.abcl</groupId> <artifactId>abcl-contrib</artifactId> <version>1.3.2</version> </dependency>
Best Regards, Ralph Ritoch
On Mon, Aug 3, 2015 at 12:58 PM, Ralph Ritoch rritoch@gmail.com wrote:
Mark,
I have added a separate build profile for deployment to maven central.
When the "default" profile is used the source release and javadoc aren't generated, and the gpg signing isn't executed. To use this new full profile, such as for deploying to maven central, you must append -Dbuild=full to your command line. For example, mvn install -Dbuild=full , if you don't include this extra argument the javadocs and source releases aren't generated and the gpg signing isn't applied. These new pom's are on git.
https://github.com/rritoch/abcl/blob/master/abcl/pom.xml https://github.com/rritoch/abcl/blob/master/abcl/main/pom.xml https://github.com/rritoch/abcl/blob/master/abcl/contrib/pom.xml
My next project will be to attempt to release version 1.3.2 to a maven central repository which will likely require some additional changes to these pom files.
Best Regards, Ralph Ritoch
On Fri, Jul 24, 2015 at 2:44 PM, Mark Evenson evenson@panix.com wrote:
On 2015/7/21 19:27, Ralph Ritoch wrote:
Hi,
I have created some maven POM files which can be used to build and
deploy
ABCL with maven. There have been a few modifications to these over the
past
few days and there is probably room for improvement but these make it possible to build and depoy ABCL with the normal maven lifecycle.
Thanks!
A couple questions:
- Is it possible to merge the new main/pom.xml into top-level POM?
Creating a new directory just to separate the main ABCL build instructions seems a little wrong to me.
- Why not use the Ant instructions for building the actual abcl.jar
artifact? It would be better for future maintenance not to have two sets of instructions for constructing deployment artifacts.
- Can we make the GPG signing optional for the 'install' target?
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
armedbear-devel@common-lisp.net