Hi,
No need to switch from Ant to Maven to automate the maven jar upload.
You can add the distribution of xalan's jars to MC via nexus.a.o in Ant
script (the ant script will use/call maven for upload, so need maven on
the build machine but no need pom.xml).
You can see a sample in JMeter project before v5.1.1 (after the project
have been move from ant to maven and Subversion to Git)
See : http://svn.apache.org/repos/asf/jmeter/trunk/ (build.xml file)
On targets _dist_maven / maven_upload in build.xml
I can help if need.
Milamber
==== Some notes on the settings of Maven on build machine ====
Maven must be installed on machine
$ cat genpass.sh
mvn -ep "your_asf_password"
$ sh genpass.sh
{zupqrxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxneQBEe} <===
Your_Encrypted_Password
If you want to try out the Maven targets, update workspace and build
(ant package)
Note: Environnement variable M2_HOME must be set.
(In Eclipse, External Tools Configurations box > Ant Build maven task >
Environment tab)
(In command-line, declare an enviromment variable with "export
M2_HOME=/path/to/maven_home")
Then create the poms/jars:
ant _dist_maven -Djmeter.version=2.6-SNAPSHOT
[might add this to the distribution target later]
Then
ant maven_upload
will create the a local repo under target/deploy.
If that works OK, then it is picking up Maven.
You can then try uploading to the snapshots repo:
If needed, add or modify your $HOME/.m2/settings.xml with this lines :
<settings>
[...]
<servers>
<server>
<id>apache.snapshots.https</id> <!-- For Snapshots -->
<username>ASF_Login</username>
<password>{Your_Encrypted_Password}</password>
</server>
<server>
<id>apache.releases.https</id> <!-- For Releases -->
<username>ASF_Login</username>
<password>{Your_Encrypted_Password}</password>
</server>
</servers>
[...]
</settings>
ant maven_upload -DrepoType=snapshots
For signing target which can loop through all the dist artifacts
(archives, poms, jars). That will need GPG installed, preferably GPG 2.x
Ref.
http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-encrypting-passwords/
===================================================
On 10/04/2023 21:07, Gary Gregory wrote:
I think the best path forward would be to switch the build to Maven
but that's probably a non-trivial amount of work. Or add a pom.xml to
the project and make that a 2.7.4 release.
Gary
On Mon, Apr 10, 2023, 10:10 Eric J. Schwarzenbach
<eric.schwarzenb...@wrycan.com <mailto:eric.schwarzenb...@wrycan.com>>
wrote:
Hi Mukul,
This isn't about what is used to build Xalan, but about what Xalan's
users use to build their projects and ensure they use Xalan with
correct
dependencies. Maven is what a large chunk of Java users use for
dependency management, and they typically expect to be able to
pull the
dependency definitions from Maven central. Of course they can each
individually set this up locally instead, but it is more ideal to
have
central source of correct information. Maven central serves that role
and contains such definitions for previous versions of Xalan.
Of course the Xalan devs do not necessarily have to be the ones
submitting this to maven central, some Xalan user more familiar with
maven, like Richard or myself, could probably step up and do this.
However it would be helpful for a Xalan dev to chime in regarding the
correct / necessary versions of dependencies. I posted a query for
clarification about one such dependency version recently
(xml-apis.jar)
to this list but have not as yet seen a reply. Perhaps it will
help to
give more context, if you are not a maven user yourself.
Typically when a Maven user sets up the maven dependency
definitions for
a new version of something, they will start with the previous
versions
definitions as a starting point. The definitions in maven central for
Xalan 2.7.2, declares two (compile) dependencies: xercesImpl 2.9.1
and
serializer 2.7.2. Note that such dependency declarations will cause a
user's project build to pull in these dependencies automatically,
so a
projecting declaring xalan 2.7.2 will get xercesImpl 2.9.1
automatically. Some users like myself, have project that also
depend on
xerces directly and realize that newer versions of xerces have
come out
and define their project to reference a newer version of xerces like
2.12.2.
xercesImpl in turn has a maven definition that declares a
dependency on
xml-apis. xercesImpl 2.12.2 specifies xml-apis 1.4.01. The is the
latest
version of xml-apis appearing in Maven central (ignoring the versions
2.0.0 and 2.0.2 which are actually older than 1.4.01...I forget the
story there.)
To reiterate my earlier query, I notice that the jars included
with the
xalan 2.7.3 download include an xml-apis that seems to be version
1.4.02. Is it necessary or in some way desirable to use xalan
2.7.3 with
that version of xml-apis rather than to let the xercesImpl dependency
pull in xms-apis 1.4.01? If so, maybe we need to declare that as
direct
dependency of the xalan maven definition, and load that artifact to
maven central also. But where does it come from? What project manages
and produces this jar?
Any advice here would be much appreciated by maven users, either for
setting up their own local maven dependency definitions, or
(preferably)
for someone to submit a canonical definition to maven central.
Thanks,
Eric
On 4/7/23 02:40, Mukul Gandhi wrote:
> Hi Richard,
>
> On Thu, Apr 6, 2023 at 5:08 PM Richard Atkins
<richatk...@atlassian.com <mailto:richatk...@atlassian.com>> wrote:
>
>> I'm so happy to see that 2.7.3 is finally released, and
available for download from xalan.apache.org
<http://xalan.apache.org>. One question though: will you be
publishing this to maven any time soon? It looks like the
xalan-java repo doesn't have any ivy.xml configuration, so it
would need to be configured following the docs in
https://infra.apache.org/publishing-maven-artifacts.html . And it
would be a good idea for the release docs to be updated to
reference it too.
> The Apache project release process, allows apache projects to
follow a
> Maven or Ant based build process. XalanJ currently has a build
> process, based on Ant, because of which we build XalanJ via Ant
build
> tooling. XalanJ releases, its builds as stand-alone jars (packaged
> within a .zip or tar.gz files), which can be downloaded and used by
> users.
>
> I believe, XalanJ users can fairly easily, locally configure their
> Maven builds to use the Apache released XalanJ.
>
>
