james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [JSieve] pom's in stage
Date Mon, 08 Oct 2007 23:04:29 GMT
Robert Burrell Donkin ha scritto:
> On 10/8/07, Stefano Bagnara <apache@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On 10/8/07, Stefano Bagnara <apache@bago.org> wrote:
>>>> The alternative is still the #3 from the original post:
>>>>> 3) change the dependencies groupdIds/artifactIds for the "problematic"
>>>>> artifacts and move them to the new folders. Alter the pom to declare
>>>>> this new dependencies. E.g: move javax.mail/jars/mail-1.4.jar to
>>>>> org.apache.james.dep/jars/mail-1.4.jar or something similar. Even if
>>>>> don't put there the poms mvn will work creating a "standard" pom with
>>>>> dependencies and will deploy to the local repository our own "artifacts"
>>>>> without clashing with official poms/artifacts from central. This is make
>>>>> the offline build to work without placing bad stuff in the local
>>>>> repository but we will declare dependencies on artifacts not existing
>>>>> central.
>>>> opinions?
>>> #3 introduces bad meta-data into the maven repository
>> No, I proposed #3 because it does not put bad meta-data in the
>> repository. It only put there "custom" data. We should only take care to
>> use our own groupIds and no build will be corrupted by our poms.
>> Let's say we add "jsieve" or "james" to the groupId, we can be sure no
>> one else will have references to this artifacts.
> bad meta-data is bad meta-data - whether it's published in the apache
> repository or not

Maybe this depends on the definition of bad metadata. IMHO what is bad
is some metadata that could break something because it is not complete
or different from the right metadata.
Here I propose to create our own metadata for the very purpose to create
something we have the license to redistribute.

The original issue is that we have no license to redistribute that poms,
right? I say let's create our own poms, and doing so we should not reuse
groupIds already used by third party projects that didn't grant us the
needed licensing.

The concrete plan is (replace "org.apache.james.3rdparty" with what you
rename stage/javax.mail to stage/org.apache.james.3rdparty and then
alter the pom from:

At this point we can decide whether to create pom.xml for this
groupId/artifactId. If we don't provide one maven will create a basic
one for us.

>> IMHO the only drawback is that we cannot publish our "jsieve" pom in the
>> maven repository because we have dependencies on artifacts that are not
>> in the repository. But this already happens for james and mailets jars,
>> so I don't think this is a big issue. If we want to publish jsieve in a
>> maven repository we'll have to fix many other problems, first (or to
>> avoid declaring the dependencies).
> i'm confused: which issues in particular?

That james-2.3.1.jar, mailet-2.3.jar and mailet-api-2.3.jar are not
present in a maven repository (and it is not just a matter of addning a
pom and publish them because our ant build didn't add NOTICE/LICENSE to
that jars as we didn't plan to redistribute them outside from our main
zip/tar.gz releases).
So we already declared dependencies on artifacts not existing in the
repositories (our own james server/mailet jars), #3 would simply add
some new artifacts that is only found in the local stage folder.

>>> what would maven do if we just removed all the pom's from the local repository?
>> If we remove the poms and leave the jars under existing
>> groupId/jars/artifactId-version.jar scheme then it will try to lookup
>> the poms online, if it finds the pom it download it, otherwise it
>> creates simple poms with no dependencies (they contains artifactId,
>> groupId and version). This maven-generated poms are the ones that could
>> break any other project depending on the same artifacts and building
>> against the same local repository
> by local respository do you mean the stage directory or ~/.mvn (or
> whatever the path is)?
> - robert

the local repository is ~/.m2/repository.

when maven look for an artifact it looks in the local repository
(~/.m2/repository). If the artifact is not there, yet, then it starts
looking in the remote repositories. We "hacked" our poms so that we add
a "stage folder" that is a "remote repository" for maven but is local to
our project and is checked out with the sources. This is clearly an
hack, because this break some basic maven rule, but this was the only
solution to satisfy the JAMES PMC/AFS policies wrt m2 based releases.
If someone changed his mind about this topic please speak now, otherwise
I think we'll have to stick to that decision.
So when maven will need the org.apache.james:mailet-api:jar:2.3 artifact
it find it in the stage/org.apache.james/jars/mailet-api-2.3.jar file
and then also looks for stage/org.apache.james/poms/mailet-api-2.3.pom.
If it does not find the pom it will first lookup any other remote
repository for the pom and if not found will create a basic pom like
this one:
(as you can see this is only a different representation of the maven
artifact identifier)

I think the only "bad" pom is the one having the same groupId/artifactId
of an already publicly available pom but not declaring the same things
(declare no dependencies or different dependencies).
We can create as many new poms as we like under the groupIds we like and
they are not "bad metadata". They simply are redundant/alternative
metadata. Unfortunately we already accepted poms without license in
central and now we need a fix for this. The only thing we should care
about is to use a groupId that do not clash with possible 3rd party
groupIds (following maven convention we should use org.apache as we
control that domain).


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message